티스토리 뷰
플랫폼 엔지니어링은 기존의 데브옵스와 신뢰성 엔지니어링과 비교하면 그 특징이 확연히 드러남
과거의 온프레미스 환경: 개발 조직과 운영 조직이 분리되어 있는 경우가 많았음
클라우드가 대세가 되면서 개발한 사람이 운영도 하는 데브옵스 환경 도입
각 데브옵스 기반 개발팀이 좀 더 신뢰성 있는 서비스를 운영할 수 있도록
모니터링 같은 부분만 빼서 공통 운영 조직을 만드는 것이 바로 SRE 조직
플랫폼엔지니어링은 여기서 좀 더 나아가서, 공통 인프라 세팅, 보안 규정 준수 같은
중복되는 영역을 완전히 빼서 사내 개발자 도구를 만들어주는 것이
세 가지 방법은 어는 것이 더 나은 게 아니라 조직에 따라 선택할 수 있는 것
플랫폼엔지니어링은 규모가 큰 조직에서 클라우드 복잡성이 커졌을 때 채택하면 좋음
애플리케이션 운영 관점에서 보면 데브옵스는 내가 만들고 내가 실행한다
각 애플리케이션이 자유롭게 개발 플랫폼을 선택하고 직접 문서화를 할 수 있음
플랫폼엔지니어링은 내가 만들고 함께 실행한다
각 앱은 플랫폼 팀이 만들어 준 가드레일을 기준으로 개발 플랫폼을 선택할 수 있음
초기 학습 비용을 줄이고 사내 규정도 준수할 수 있음
ex Intuit 중소기업,회계사,개인을 위해 재무 회계 및 세금 보고 소프트웨어 제작 회사
-> AWS 운영, 자체 플랫폼팀에서는 미리 쿠버네티스 기반의 개발팀용 앱 청사진 블루프린트를 만들어서 공유 플랫폼으로 만듬
개발팀은 이를 선택해서 몇 가지 선택만 하며 2~3분 안에 완료되서 DB 스토리지 같은 신규 개발 자산들을 배포하게 됨
-> 멀티 어카운트 기반으로 팀별 계정에 자산이 디플로이 되지만 플랫폼에서는 배포와 옵저빌리티, 로깅, 추적을 위한 중앙 도구들 제공
Liberty Mutua(세계에서 6번째로 큰 보험사) - 사내 서버리스 플랫폼 사례
클라우드 기반으로 민첩하고 고객 중심적인 기업으로 변모하기 위해서 서버리스 퍼스트 전략 구사
금융 회사로 규모가 크다 보니 많은 개발팀이 서버리스 기반으로 애플리케이션을 만드는데 학습 비용이 많았음
2019년 "소프트웨어 엑셀레이터" 사내 도구 제작
-> 사내 규정을 준수하면서도 서버리스 패턴을 제공해서 개발자들이 손쉽게 서버리스 앱을 구성할 수 있게 함
-> 2021년도에 3500개 이상의 서버리스 앱을 배포
-> 자유도가 높은 서버리스 아키텍처에서도 플랫폼 엔지니어링을 잘 활용하면 경우에 따라서 좋은결과를 내게 됨
플랫폼 엔지니어링을 쉽게 구현할 수 있는 AWS 도구
거버넌스 관점: 2가지 서비스
AWS 컨트롤 타워: 기업의 보안 및 규정 준수 요구사항 관리
AWS 오가나이제이션: 기업 내 계정 관리, 손쉽게 AWS 계정 추가 및 기업 내 팀들이 사용할 수 있도록 할당 가능
-> 계정 또는 그룹에 거버넌스 정책 적용 가능
애플리케이션 배포 관점
AWS Proton 서비스: 셀프 서비스 인프라 템플릿과 프로비저닝 자동화 도구를 통해 빠르게 애플리케이션 배포 제공
인프라 관리자 / 개발자 두 고객의 관점에서 현대적 앱의 배포 및 운영 방법을 살펴보도록 함
1. 관리자 관점
-> 인프라, CI/CD 파이프라인, 모니터링 도구를 설정할 수 있는 셀프서비스 템플릿 및 프로비저닝 자동화 도구 제공해서
2. 개발자 관점
- 개발자들은 관리자가 만들어 놓은 배포 템플릿을 활용해서 서비스를 배포만 하면 됨
- Proton은 엔터프라이즈 기업이나 규모가 큰 기업에서 개발팀과 인프라팀 사이의 책임과 역할이 분리되어 있는 회사에서 유용
인프라 관리팀은 AWS Proton에서 애플리케이션 환경 템플릿을 만들고 등록
-> 이러한 템플릿을 사용해서 여러 계정에서 알파, 베타, 프로덕션 등 개발팀이 바료 사용할 수 있는 환경을 만들 수 있음
-> 환경 템플릿(인프라와 스키마, 생성할 인프라 설정이 담긴 cloudformation 템플릿과 설정 파일 등이 있음)과
서비스 템플릿(Fargate와 Lambda 서비스를 실행할 수 있는 템플릿을 설정할 수 있음)을 만들 수 있음
플랫폼 운영을 위한 모범 사례
AWS에서는 Well-architect라는 클라우드 모범 사례로부터 다양한 운영 패턴 및 솔루션을 제공하고 있음
AWS 솔루션 라이브러리
-> AWS 및 AWS 파트너가 구축한 검증된 솔루션과 아키텍처 지침 제공하고
AWS Cloud Development Kit: 클라우드 인프라를 코드로 관리
-> CDK 패턴 모음집은 프로그램 언어를 가지고 아키텍처를 구성할 수 있는 코드 샘플을 제공
-> Constructs Hub에는 CDK를 활용할 수 있는 다양한 오픈 소스 라이브러리를 검색해 볼 수 있음
Amazon EKS: AWS의 관리형 쿠버네티스 서비스
-> EKS를 통해서 클러스터 구성 및 관리가 좀 쉽지가 않음
-> 쿠버네티스를 잘 모르는 사람들도 빠르게 구성하고 운영할 수 있는
Amazon EKS Blueprints 솔루션
EKS 클러스터를 구성하고 배포하는데 도움이 되는 오픈소스 IaC(Infrastructure as Code) 모듈
거버넌스, 배포 도구, 모범 사례를 따라서 AWS가 제공하는 서비스를 잘 구성하면 사내 플랫폼을 쉽게 만들수 있고
이를 기반으로 개발팀은 각자의 앱 개발 및 배포에만 집중할 수 있는 환경이 구성
플랫폼 엔지니어링이란?
비즈니스 가치를 실현하는 주체인 개발자 경험을 위한 개발 환경의 지속적 개선
- 추상화된 클라우드 네이이트 개발 환경
- 개발자 인지부하의 저감
개발자가 개발 비즈니스 자체에 집중할 수 있도록 해주자
- PaaS에서 이야기하는 본질적인 목표와 같음
- 과거의 PaaS는 제품을 잘 선택해서 가져다가 사용하면 되었음
- 가져다 쓸수 있는게 아니라 회사마다 개발자들의 수준이 다르다 보니까 개발자들이 어디까지 자기가 직접 할거인지
플랫폼팀에서 추상화시킬 것이냐 하나의 활동이 되었음
개발자 경험(Developer eXpereience)
기획 -> 설계 -> 구현 -> 운영
어디까지 익숙하냐
익숙하지 않은 부분에 경험 개선을 위한 도구들이 필요하다
개발자들의 경험 지속 관리하면서 개선하자
플랫폼 엔지니어링의 성공요인
(PaaS / DevOps 와의 차이점)
- Thinnest Viable Platform
우리조직에 필요한 만큼의 PaaS/DevOps 수준에 맞춘 최소한의 플랫폼 제공
- Demand-Driven
고객 요구에 따른 Value stream(비즈니스 가치)을 창출 할 수 있는 도구들로 구성
- Platform as a Product
플랫폼 엔지니어링 팀에 의하여 개발자의 요구사항에 맞추어 지속적으로 지원되고 개선
- Paved Roads (Golden Path)
개발자에게는 꽃길만 걷게 하라 포장 도로
개발자 포탈 애플리케이션 리스팅이 되고 연결된 인프라 관련된 MSA의 연결점 조망 / 개발자들의 성과 등 모니터링 인프라 사용량
개발자들이 주로 하는 활동들이 한곳에 모여서 쉽게 팀워크가 되는 IDP 포탈(오픈소스: Spotify 인하우스 Backstage: CNCF)
일종의 빌더(오픈소스들을 쉽게 가져다가 npm build - react -argocd - gitlab 클릭 클릭해서 빌드를 시키면 회사 포탈이 만들어짐)
CI/CD 파이프라인 / IaC / Observility 등을 개발자에게 제공하는 툴 체인
최근에 인프라 관련 트렌드 플랫폼 엔지니어링 언급이 되고 있는 상황
인프라에 대한 어떤 변화나 이제 움직임들을 하실 때 좀 이해를 돕고자
플랫폼 엔지니어링닷컴이라는 사이트를 보면 이렇게 정의가 되어 있는데 거 이제 번역기를 돌렸습니다
클라우드 네이티브 시대의 소프트웨어 엔지니어 조직이 셀프서비스 기능을 사용할 수 있도록 툴 체인과
워크플로를 설계하고 구축하는 분야 입니다 플랫폼 엔지니어는 어플리케이션에 전체 생명 주기에
필요한 운영 요구사 사항을 포괄하는 내부 개발자 플랫폼을 제공한다
그냥 들어서는 어 그게 무슨 말이야라는 생각이 좀 드실거라고 생각을 해요
가트너에서 작년에 조사한 이제 이머징 테크를 보면 이제 최근 2년에서 5년 내에 이제 어 떠오르고 있는 이제 한 기술로
이제 플랫폼 엔지니어 분야가 이제 선정되어 걸 볼 수 있고 물론 여기에는 이제 수많은 기술들이 이제 나와 있죠
그런 조사이 그래서 이제 뭐 여기 있다고 뭐 크게 뭐 뭔가 증명되는 건 아니지만 그래도 업계 해서
요런 플랫폼 엔진 용어를 이제 주게 보고 있다 정도로 보실 수
그럼이 플랫폼 엔진이 도대체 뭐냐 뭘 얘기하는 거냐 그 얘기하려면 어 저는 데브옵스가
뭔지부터 얘기해야 된다고 생각을 하고 있습니다 결국 그 시작에는 데브옵스가 있다고 생각을 하고 있고요 데브옵스는
데브와 옵스를 합치 있다는 말이죠네 그래서 이거는 2009년 오리에 벨로시티 어 벨로시티 컨퍼런스에서
이제 플리커는 회사네 지금 야후에 인수됐고 서비스죠 요즘은 잘 안 써요
잘 안 쓰는데 플레라 서비스에서 어 대부와 옵스의 협업으로 하루에 번 배포하기 발표가 있고이 발표가 데브옵스가 시작되는 역사적인
발표가 됩니다네요 플리커에 두 직업 대부에 한 명 옵스에 한 명이 나와서 발표를
하는데 어이 준비하면서 다시 봤는데 지금 막 봐도 꽤 재밌는 어 발표라고
생각합니다이 발표를 보고 이제 패트릭 드라는 사람이 이제 집에 돌아가서 어
데스 데이라는 컴퍼스를 만들면서 이제 데부 스라는 용어가 어 처음
만들어지게 되고 이게 지금까지 저희가 사용하고 있는 이제 데부 옵스의 기원이 됩니다이 패트릭 두부는
오른쪽에 저 번역서로 나온 데스 핸드북이라는 책의 이제 공동 저자 중
한 명이고네 2009년에 그래서 이렇게 만들어지고 대부 옵스 그러니까
대부와 오스를 합치 있다는 거는 그 전에는 대부와 오스가 어 따로 떨어져
있었다는 의미가 되는 거죠네 그러니까 합친다고 하겠죠 이제 어 원래부터 합쳐져 있었으면 굳이 합친다는 말을
안 할 텐데 합치 있다는 말을 했다는 건 이제 떨어져 있다는 거고 이제 대부 팀과 그 개발을 하는 데부 팀과
운영하는 이제 옵스 팀이 별도의 팀으로 이제 일로로 어 조직되어
있었다는 의미가 됩니다 그 전까지는 근데이 두 조직은 기본적으로
하려는 일이 다르고 이제 성향이 달라요 개발 팀은 이제 빠른 변경을
하고 다양한 시도를 계속 하기를 원하고 운영팀은 아무도 으로 운하는게
가장 큰 목적이다 보니까 안정적으로 운영하기 위해서 적은 변경 변경을 가하더라도 전진적으로 하고 좀 천천히
했으면 하는 이제 기본적인 입장 차이가 발생을 하고 그러다 보니까 둘간에 이제 뭐 안 좋게는 사이가
많이 나빠질 수도 있고 어 기본적으로 소유에 대한 불만이 쌓여가고 어 하는 문제가 발생을 했습니다 그래서 이제
어 지금은 이런 식으로 일을 많이는 안 하기 때문에 어 이게 잘 상상이
안 가실 수도 있지만 이제 팀에서 소프트웨어를 만들고 운영팀에 넘기면 운영팀이 그 서비스를 운영한다는 거죠
이제 두 개가 이제 완전히 따로 움직인다는 얘기를 하는 거고 이거를 이제 어 담장 위로 던진다는 얘기
표현을 보통 쓰죠네 그래서 개발 팀이 소프트웨어를 만든 다음에 담장 너어 소프트웨어를
던지면 운영팀이 어 그걸 받아서 어떻게 개발했는지 잘 모르지만 그
소프트웨어를 받은 다음에 이제 운영에 올려서 이제 서비스를 운영을 하고 또 운영팀은 담장 넘어에서 이제 개발팀이
이 뭘 하는지 잘 모르는 어 그런 형태를 이제 이렇게 표현을 합니다
결국이 문제를 해결하기 위해서 이제 데브옵스가 등장을 했고 데부 옵스의 가장 핵심적인 부분은 피드백 루프라고 저는 생각을 합니다 그래서 어 계획을 하고 만들고 배포하고
구성한 다음에 모니터링하고이 사이클을 계속 돌 돌려서 이제 개발팀은 운영에서 뭐가 문제 되는지 뭐 로깅을
어떻게 남기고 어 어떤 부분을 해야 성능이 더 좋은지 이런 부분을 이제 운영의 경험을 가지고 다시 개발에
녹아들고 개발이 어떻게 했는지에 따라서 맞춰서 이제 운영이 마치는 이제 서로 피드백 루프를 계속 돌려서
만들어야 더 좋은 SW를 만들고 더 안정적이고 더 잘 만들 수 있다라고 하는게 이제 데브옵스 철학
기본적으로 담겨 있는 생각이라고 어 생각합니다 그리고 아까 말씀드렸듯이
2009년에이 단어가 만들어졌다고 했는데 어 꽤 인기를 얻어서 이제
업계에도 많이 도이 된 거 거같아요 아마 대부분 대부 스라는 얘기를 많이 너무 익숙하게 들어보셨을 거고 많은
조직들이 이미 대부 스를 어 도입했다고 어 생각하고 있을 가능성이 저는 높다고 생각합니다
최근에 뭐 한 10년 이내에 개발을 시작하셨다면 데브옵습 아닌게 뭐야라고 생각하는데 한 10년이 지난 시점에
과연 그 대부 흡수가 좋다는 건 알겠는데 많은 책에서 좋다고 하고 실제로 편한가 예 이렇게 개발하니 진짜 편하고 좋은 세트 만들기가 너무
좋고 어 뭔가 걸리적거리는 거 없이 쉽게 배포할 수 있고 잘 되는가라고 생각을 하면
어 꽤 의문이 있을 거 같아요 저도 여기에 대한 많은 의문이 있고
실제로 우리가 지금 잘하고 있는가라는 고민을 할 수 있고 이것도 이제 가트너에서
2019년에 예측한 글인데 2022년까지 대부 옵스 이니셔티브의 75% 조직 학습과 변화와 관련된 문제로 기대치를 충족하지 못할 것이다
그니까 잘 안 될 거라고 예측을 한 거죠 물론 지금은 2023년이 때문에이 가은 어의 예측이 지금 맞았냐 아니냐는 좀 어
어려울 수 있는데 어렵지 않고 이제 지난 과거 이미 근데 이제 그 결과가 실제로 어때 있는지에 대한
따로 보고서는 없기는 하더라고요 제가 찾지는 못했고 실제로 많은 조직을 봐도 그 각 조직에서 데브옵스를 하지만 이제 조직에 제대로 되고 있는가 각
팀에서 데브옵습 팀이 따로 있는 조직도 있고 여러 조직이 있지만 잘 되고 있는가는 이제 어 고민해볼 필요는 있다고 생각합니다
그리고 많은 조직이 데브옵스가 제대로 잘 안 된다고 어
문제를 얘기하고 있다고 생각하고 글을 찾아봐도 이제 그런 내용을 많이 볼 수 있는데 그러면 대수가 이렇게 어
앞에서 좀 좋은 방 방향이라고 설명을 했는데 왜 잘 조직에 도입이 안 되나라는 가장 크게 지적하는 문제는
높은인지부하 좋다는 건 알겠는데 데브옵스를 하고 싶은데 실제로 현실에서 하려면 각 서비스 개발팀 엔지니어들의 인지 부화가 너무 높은
거죠 그래서이 계획하고 개발하고 뭐 테스트하고 이렇게 스피드백 루프를 도는 가운데 뭐 버전 컨트롤도 알아야
되고 테스트 자동화도 해야 고 CI/CD 구성도 해야 되고 뭐 모니터링도 하고 인프라 뭐 프로비저닝 하고 컨테이너
화도 하고 뭐 로그도 남기고 뭐 별별걸 다 해야만 이제 이거를 제대로 돌릴 수 있는데 그걸 각자가 하기가
어 너무 어려운 거죠 왜냐하면 여기서 이제 인프라 관점에서만 얘기를 하고 있지만 실제로 각 팀은 이제 데드
비즈니스 데드라인 지켜야 되고 어 서비스 사용자가 원하는 기능을 만드는 원래 그 서비스 개발팀이 하는 본연의 일들이 있죠
그일 위해서 이것까지 추가로 해야 되기 때문에 이게 좋다는 걸 알아도 현실에서 실제로 잘 해내기가 쉽지 않습니다
그리고 최근에 인프라스트럭처 이제 클라우드가 되고 클라우드 네이티브 시대가 되면서 훨씬 더 빠르게 복잡해지고 있어요
훨씬 많은 도구들이 나오고 예 지금 보시는 화면은 이제 cncf 클라우드 네이티브 랜드스케이프 그림인데 어 그냥 봐도 엄청 복잡하죠
물론이 기술을 다 쓰진 않아요 어떤 조직도 다 쓰진 않고 각 카테고리 뭐 많이 써도 각 카테고리별 뭐 뭐 하나씩 정도 쓸 테고
여기 있는 것 중에 아주 일부만 쓰시는 조직도 많고 꼭 여기 있는 걸 써야 클라우드 네이티브라고 할 수 있는 건 아니지만
실제로 최근에 기술 클라우드 관련 기술들이 엄청 복잡해지고 계속 새로운게 나오면서 알아야 될 것들이 어 많아지고 있는 건 이제 사실이라고
생각을 합니다 물론 저도 이렇게 복잡해지는게 정말 맞나 우리가 제대로 가는 거 맞나라는 고민을 하고는 있지만
물론 각 개별 도구를 보면 그 도구들이 다 나온 이유가 있고 해결하는 문제가 있어서 어쩔 수없는 부분인 거 같기도 합니다
결국 이렇게 복잡도가 높아지면 인지 부하도 같이 높아질 수밖에 없어요
복잡도 어떻 보면 당연한 얘기죠 코그니티브 로드가 인지 부하를 얘기하는 건데
각 엔지니어들이 인지 부하가 많이 높아지고 어 그거에 가장 큰 건 이제 복잡도
때문에 오는 거죠
이거는 엔지니어링 플랫폼 엔지니어링 10이라는 발표에서 가져온 이제 장 데 이제 최근 한 10년 사이에 뭐 테라폼 인프라 코드도
등장하고 뭐 마이크로 서비스도 가속화되고 쿠버네티스 뭐 쿠버네티스 가장 큰 역할을 하는 거 같기도 한데
쿠버네티스 등장하면서 이제 어 복잡도가 엄청 커지고 그에 따라 인지 부하가 어 많이 높아지고 있는게 어 현실이고요
이 높은인지 부하는 결국 이제 서비스 쪽을 만드는 소프트웨어 엔지니어들에게 이제 업무부 와 기존 하는 일들에 이제 추가로 알아야 될 것들 뭐 원래 안 쓰고 있었는데 우리
회사가 이제 쿠버네티스를 도입한다고 하면 이제 컨테이너를 알아야 되고 쿠버네티스를 알아야 되고 뭐 프로메테우스가 뭔지도 배워야 되고 뭐
기존에 몰랐던 것들 계속 배우고 익혀가야 되는 뭐 프로메스 변 되는 것도 아니죠 뭐
프롬 큐도 짜야 되고 뭐 뭐 제대로 모니터링 하려면 알야 될게 많고 결국 그 결과는 이제 번화 웃으로 이어질
가능성이 아주 높다고 생각을 합니다 그리고 아까 이제 대부 스를
통해서음 데브와 옵스를 가이함으로써 이제 피드백 루프를 돌린다고 했는데
실제 현실에서는 이제 섀도 오퍼레이션이 많이 발생이 합니다이 섀도 오퍼레이션이 말하는 건 어 이제
회사에서 전 조직적으로 보면 운영 팀을 없앴는데 각 팀에서 그 팀에 이제 뭐 인프라에 관심이 많거나 인프라에 대한 경험이 많은 사람이
그 팀이나 그 프로젝트의 운영을 담당해서 처리를 하는 거죠 그럼 실제로 내부적으로 보면 운영이 따로 있는 거죠
전체 조직으로 봤을 때는 옵스팀이 없기 때문에 마치 대부 흡수를 하는 것처럼 보이지만
멀리서 보면 그 팀과 프로젝트의 내부에 들어가면 한 명이나 소수의 인원이 오퍼레이션을 담당하고 있고 트러블 슈팅을 담당하고 있어서
이거를 이제 보통 섀도우 오퍼레이션이 아고 부릅니다 결과적으로 어 물론 조직 내에 가깝게 있으니까 어느 정도 대부의 옵스의 목적을
달성할 수 있지만 기본적으로 원래 하려던 그 데브옵습의 가치에서는 좀 뭐 벌어지는 현상이라고 생각을 할
수 있습니다 결국 이런 문제 현실적인 문제들로 인해서 데부 옵스는 그 좋은 가치에도 불구하고 많은 조직이 이제 제대로 활용하거나
이제 도입하는데 좀 실패를 하고 있고 요런 문제를 이제 해결하려고 어 해결하려는 하나의 조건이 이제 플랫폼 엔지니어라고 할 수 있는데 물론
플랫폼 엔지니어링은 갑자기 등장한게 아니라 수많은 빅테크 기업들은 이미 수년간이 데브 옵스를 도입하고
어 문제를 해결해 가는 어 해결해 하는 가운데 많이 시도하고 이미 해결했던 문제라고 생각하고 그런 경험을 가지고 빅테크
밖으로 업계에서 나오고 있는게 어 플랫폼 엔지니어라고 저는 생각을 하고 있습니다 예를들어 넷플릭스는 이제 몇
년 전에 몇 년 전도 몇 년 전에이 풀사이클 디벨로퍼는 글을 썼어요 예
오퍼레이트 왓유 빌드라고 되어 있는데 이제 만든 거를 운영하라는 거죠 당신이 만든 걸 운영하세요 같은
말인데 결국 그 말을 해석하면 데브옵스가 얘기한 거와 같은 거죠 만들고 운영하는 걸 이제 합쳐 놓은 거니까
이제 여기서 풀 사이클이란 걸 그냥 간단히 생각하면 아까 보여 드린 데브옵스의 그 피드백 루프 그 사이클을 전체 사이클을 다 돌리는 개발자라는 의미가 됩니다
그고 데브옵스가 얘기하는 거를 이제 똑같은 얘기를 이제 다른 용어로 넷플릭스에서 쓰고 있는 거죠 근데 여기서 이제
넷플릭스가 얘기한 건이 풀 사이클을 돌리려면 각 단계에서 필요한 도구들이 있는데 그
도구들을 이제 만들어 주는 사람들이 있어야 된다는 거죠 그거를 각 팀에서 모든 팀이 다 베포 도구를 만들고
모든 팀이 다 모니터링을 세팅하고 예 모든 팀이 로깅을 구현하고 이럴 수 없기 때문에 어떤 팀에서 각 도구를 만들어서 제공해 주고 그 도구를
사용해서 그니까 회사가 제공하는 거죠 회사가 제공한 도구를 사용하면 훨씬 더 쉽게 낮은인지 부하를 가지고 풀 사이클을 돌릴 수 있게 하겠다
라는게 이제 넷플릭스의 접근이고 어 뭐 이런 결과로 이제 뭐 넷플릭스가 공개한 뭐 스피네이커 뭐 콘솔 미나 이제 수많은 이제 오픈 소스를 이용한
이제 내부 플랫폼들이 이제 공개되어 있고 이제 많은 발표에도 나와 있습니다
구글은 10여년 전에 이제 sre 이라는 직종을 어 발표를 했죠 지금은 구글이 만들었지만 어 업계에도
많이 정착이 돼서 어 다른 조직에서도 많이 sre 쓰고 있고 저도 현재 지금 sre 역할로 회사에서 업무를 하고 있습니다
구글의 그 책의 정의에 따르면 sre는 이제 운영 팀을 위한 소프트웨어 엔지니어라고 말하고 있어요
운영을 운영의 그 성격상 기존에 이제 사람들이 많이 어 휴먼 리소스를 투입해 가지고 이제 수동으로 하던 일들이었는데
이 문제를 이제 소프트웨어 엔지니어를 투입해서 소프트웨어로 풀겠다는게 어 제가 이해하고 있는 구글의 sre 주 목적
물론 sre 영역이 엄청 넓기 때문에 딱 뭐 한마디로 정의하기는 좀 어렵지만 어 그런 접근이라고 생각을 하고 있고
sre 워크 북에서 얘기 하는 것은 이제 운영은 잘하는 것은 소프트웨어의 문제다
그니까 이거를 소프트웨어로 풀어야 운영을 잘할 수 있다로 이제 얘기를 하고 있습니다
이런 접근을 통해서 이제 구글도 내부적으로 많은 서비스와 플랫폼 그니까 사내에서만 쓸 수 있는 그런
것들을 많이 새로 개발해서 쓰고 있고 뭐 쿠버네티스 같은 경우도 어 결국은 구글에서 만들어져서 업계로 튀어나온 거죠
그래서 이런 그 빅테크들의 이제 많은 시도와 경험과 뭐 그 가운데 실패도 있겠죠 그런 것들이 이제 업계로 다시 경험으로 나오면서
그거를 정의한 말이 이제 플랫폼 엔지니어라고 생각을 하고 있습니다
용어는 좀 너무 광범위 한 거 같아요 제가 느끼기에는 왜냐하면 어 딱히
새로운 용어도 아니고 오해하기 좀 쉽고 약간 근데 용어를 정의할 때는 이제 아무래도 넓게 정의해야 너도
플랫폼 엔지니어이고 플랫폼을 이렇게 하는 욕심이 좀 있는 거 같아서 이런 용어를 채택하지 않았을까라고 생각을
하고 있습니다
플랫폼 엔지니어링의 정의
클라우드 네이티브시대에 소프트웨어 엔지니어링 조직이 셀프서비스 기능을 사용할 수 있도록 툴 체인과 워크플로우를
설계하고 구축하는 분야
플랫폼 엔지니어는 애플리케이션의 전체 생명 주기에 필요한 운영 요구 사항을 포괄하는 내부 개발자 플랫폼을 제공
인프라 팀이 있다면 소프트웨어 엔지니어가 인프라 팀에 어떤 인프라가 필요할 때 요청을 보내고
인프라 팀은 이제 뭐 베어메탈 IDC 있는 서버일 수도 있고 aws Azure gcp 같은 클라우드 위에 작업을 하게 됨
인프라팀에서 작업을 해서 구성이 완료되면 인프라 자원을 다시 소프트웨어 엔지니어에게 제공을 하겠죠
이 부분을 좀 더 체계적으로 하기 위해서 일반적으로 이제 요청을 받을 때는 이제 티켓으로 해서 이제 작업 내용을 공유하고
히스토리에 쌓이게 하고 인프라 팀은이 작업을 하다 보니까 이게 맨날 비슷한 일을 반복적으로 하네라는 생각을 하면서
이 작업 부분을 이제 자동화를 하게 됩니다
최근에는 이제 뭐 테라폼 같은 인프라스트럭처 에즈 코드의 도구를 이제 많이 사용하고 꼭
그런 도구를 쓰지 않더라도 뭐 쉘 스크립트나 뭐 파이썬 등의 언어를 써서 어 간단한 프로그램으로 자동화를 할 수 있을 것 같아요
자동화를 하면 그 좀 오래 걸리던 작업들을 이제 되게 빠르게 할 수 있고 이제 인프라 팀도 사람이 한 명이 아니고 여러 명이니까
누가 해도 이제 똑같은 결과물 항상 같은 결과물이 나올 수 있게 하기 위해서 이제 자동화를 시도하는 거죠
그리고 여태까지 이제 수년간 인프라 쪽에서 많은 관심을 가졌던 건이 뒷부분에 자동 작업을 자동화하는 부분에 신경을 많이 썼다고 생각을 하고 있어요
플랫폼 엔지니어링에서 말하는 이제 내부 개발자 플랫폼 idp는 사람 대신 플랫폼을 제공
노파심에 말씀드리면 뭐 이 부분으로 이제 모든 인프라의 문제를 다 해결하겠다는 것은 아니고
셀프서비스로 더 잘 해결할 수 있는 문제를 해결하자
소프트웨어 엔지니어가 인프라팀에 요청을 해서 결과를 받는게 아니라 플랫폼에 들어가서
정보를 몇개 입력하고 버튼을 클릭하면 이 플랫폼이 뒤에 있는 인프라를 그 사내 정책에 맞게 추상화해서 가지고 있고 기능을
제공한다는 거죠
간단히는 뭐 AWS E2 서버를 생성한다 하면 어 사람이 그걸 만들어서 주는게 아니라
IDP에서 어떤 기능을 가지고 있고 소프트웨어 엔지니어가 이제 버튼을 누르면 몇 분 뒤에 서버가 만들어서 이제 제공되고
IP가 뭐고 주소가 뭐고 어떤 스펙으로 되어 있는지를 이제 바로 알 수 있게 된다는게 이제 어 꼭 이것만 플랫폼 엔지니어링은 아니지만 이제 간단하게 그렇게 예를 들 수 있음
플랫폼 엔지니어링팀은이 내부 개발자 플랫폼을 구축하는 역할
소프트웨어 엔지니어들이 사내 엔지니어들이 필요한 기능을 만들어서 제공하고 뒤에 인프라를 추상화하는 그 역할
복잡도가 올라가면서 인지 부하가 높아가는데 어떤 일정 수준 그 팀이 감당할 수 있고 선호할 수 있는 어떤 그 인지부하 정도 레벨로 이제 뒷부분 복잡도를 추상화시킨 거죠
추상화를 한다는 건 결국 복잡도를 감추고 일정 수준으로 복잡도를 제외하겠다는 의미
이제 뒷부분에 소프트웨어 엔지니어들이 굳이 알지 않아도 되는 내부 정책이나 설정들은 감추고
소프트웨어 엔지니어들이 알아 알아야 되는 부분
여기서 보면 이제 롤백 설정 같은 것도 있죠
롤백 설정을 이제 소프트들이 직접해야 좋고 직접하게 선호할테니까 그런 부분은 노출시켜 주고 그렇지 않은 분들은 감춰 줌으로써 소프트웨어 엔지니어들이 일정 수준의 인지 부하 내에서 업무를 할 수 있게 하겠다
결국 이 문제도 저희 개발자들이 여태까지 계속 해오던 문제를 이제 소프트웨어로 해결하겠다의 그 연장선에 있다고 생각
저희가 항상 하는 거죠 뭐 스타트업에서 하고 뭐 코딩을 할 때 결국 어떤 문제를 보고 그 문제를 이제 푸는 과정에 있고
그거를 이제 플랫폼으로 풀겠다는 얘기를 하는게 이제 플랫폼 엔지니어링이라고 생각합니다
그래서 플랫폼 엔지니어링을 좀 찾아보다 보다 보면 이런 글들을 종종 보실 수 있어요
어 그럼 데브옵스 이제 끝났나 데브옵스 끝나고 이제 플랫폼 엔지니어링의 시대야 뭐 이런 얘기 글
이거는 저는 동의는 하지 않고요
결국 플랫폼 엔지니어링이란 건 데브옵스의 연장선에 있고 그래서 플랫폼 엔지니어링을 통해서 하려는 목적은
데브옵스를 더 잘할 수 있게 사내의 소프트웨어 엔지니어들이 진짜 데브옵습를 통해서 어 피드백 루프를
돌릴 수 있게 하는게 그 플랫폼 엔진의 주 목적이고 결국 이게 잘 되지 않으면 플랫폼 엔지니어링의 가치는 떨어지고
의미도 없어질 거라고 생각
우리가 데브옵스를 해서 이 피드백 루프를 돌리는 이유는 결국은 더 좋은 소프트웨어를 어 더 빠른 시간 내에 잘 만들기 위함
결국 이 목석이 달성이 돼야만 이 모든 어 과정이 의미가 있고 계속 그 플랫폼을 만든다고 하더라도이 가치를 정말 주고 있는가
이걸 우리가 더 잘 알고 있는가라는 거를 계속 돌아봐야 될 거라고 생각
그래서 결국 이제 데브와 옵스의 경험을 함께 가져가야 소프트웨어를 잘 만들 수 있다는 거고
이제 추상화 플랫폼으로 추상화를 할 때 어떤 부분을 엔지니어들에게 노출하고 어떤 부분을 감출지에 대한 고민의 그 기준이
결국 대부 옵스의 경험 그 피드백 루프를 가져가는 져가야 할 때 도움이 되는 정보와 도움이 되는 정보가 아닌 것을 이제
구분 어디를 추상하고 어디를 추상하는 계속 고민해서 을 만들어야 된다고
물론 이거는 각 조직마다 조직의 뭐 비즈니스 모델이나 조직 구도 뭐 형태에 따라서 아주 다를 거라고 생각해요
정해진 그 추상화의 적정 레벨이라 건 없을 거고 그 팀의 규모와 이제 상황에 따라 맞게 계속 고민해야 되지만
판단 기준은 저는 어 이상적으로는 여기야 된다고 생각을 하고 있습니다
이거는 시드 파라스 아는 어떤 사람이 쓴 트윗에서 가져온 글인데 어 어 이제 뒤에서는 또 잘 보이실 것 같긴 한데
맨 아래에 이제 어 파스 펑션 에저 서비스 이제 보통 서버리 있죠 서버리스 있고 플랫폼 에지 서비스 있고 메지드 쿠버네티스 그 이야스 그리고 베어메탈 서버들 단계로 있는데 당연히 우측으로 갈수록 어 복잡도가 높아지죠
그래서 데부 옵스에 대한 노력도 많이 들고 어 대신 우측으로 갈수록 훨씬 제어권을 많이 가지고 있죠
서버 리스는 사실 그냥 뭐 코드만 배포하는 거지 실제로 뭐 추가로 뭐 할 수 있는게 없잖아요 하고 싶어도
예 그래서 재건이 이제 서버리스 쪽에 없고 베어메탈 쪽에는 이제 훨씬 커스터마이즈 할 수 있는 영역이 높습니다
근데 개발자들이 이제 컴포트존 이제 편안하게 느끼는 영역은 이제 어 한 플랫폼 애즈 어 서비스부터 서비스에서 쿠버네티스의 약간 걸친 정도까지
쿠버네티스 이제 다 알고 싶어하진 않는 거죠 거기까지가 이제 보통 개발자들이 이제 편안하게 느낀다라는 얘기를 하고
저도 꽤 동의하는 거 같아요 한요 정도까지가 한계선 여기서 더 넘어오면 아마 어 저는 별로 여기까지 하고 싶지 않은데요
라는 얘기를 아마들을 가능성이 높을 거라고 생각하고
이 IDP라는 인터널 디벨로퍼 플랫폼이란 건이 우측에 있는 그 복잡도 개발자들이 편안하지 않게 어 느끼는
영역을 플랫폼을 통해서 편안한 영역으로 이제 가져오는게 아 가장 중요한 목표라고 생각을 합니다
그래서 어 아까 말대로 이런 어 목적을 가지고 내부 개발자 플랫폼을 만드는 거고요 내부 개발자 플랫폼을 통해서 제공하는 가치는 또 하나 있는데 아까 정의에도 나왔듯이 이제 개발자 셀프 서비스입니다 예 개발자들이 직접 셀프서비스로 뭔가 할 수 있게 하겠다는 거고 여기기 뭐 그림에 넣은 것처럼 이제 키오스크 같은 걸 상상해 보시면 될 거 같아요
물론 대한민국에서는 키오스크라는 경험이 너무 사용자 경험이 너무 안 좋기 때문에 이 키오스크를 하면 오히려 별로 확 와닿지 않을 수 있는데
뭐 굳이 예를 들면 뭐 스타벅스 사이렌 오더 같은 거를 생각할 수 있을 것 같아요 뭐 점원의 시간이나 점원이
얼마나 바쁜지 기다릴 필요 없이 내가 필요한 시간에 바로 요청을 하면 내가 원하는 걸 얻어낼 수 있는 이제 직접 하게 하겠다는 거죠
이제 플랫폼을 통해서 이런 거를 하겠다는 거고 결국이 셀프서비스를 하려면 게이트 키퍼에서 가드레일로 개념을 바꿔야 된다고 생각하고 있어요 이전에 많은 인프라 조직은 게이트키퍼 역할을 하고 있어요
티켓을 요청을 받고 내용을 검하고 어 여기에 이제 문제가 무엇인지 뭘 바꿨으면 좋겠는지 왜 이런게 필요한지를 이제 질문하고 확인한 후에 이상이 없으면 이제 만들어 주는 거죠 그렇다 보니까 결국 사람에 의존할 수밖에 없어요 담당자가 휴가 가면 어 딜레이가 되기도 하고 아니면 인프라 팀에 업무가 너무 많아서 다른 업무에 밀리면 나는 이제 빨리 받았으면 좋겠는데 안 되는 경우도 있고 이런 것 때문에 이제 갈등도 많이 생기죠
작업을 하다가 내일 배포 나가야 되는데 아 인프라 뭐 프로덕션 설정 안 했네 하면서
티켓 요청하고 죄송한데 내일까지 꼭 해주시면 안 될까요 하면 이제 인프라팀도 짜증내고 그럼 미리 요청하시지
이제 와서 이거를 해달라고 하시나요 이런 얘기를 하면서 이제 갈등이 생기고 뭐 앞으로 저희는
일주일 전에 미리 알려 주세요라고 하지만 일부러 한게 기 때문에 일부러 전날 요청한게 아니잖아요
그러다 보니까 다음에도 잘 해결이 안 되고 계속 갈등은 깊어지고 이렇게 됩니다
하지만 이제 플랫폼을 제공을 하면 어 그 안에 이제 보통 코드로 짜겠죠
인프라 팀이 원하는 정책 아니면 뭐 예를 들어 뭐 서버를 예를 들면 EC2를 올리는데 어떤 서브넷을 설정해서 나가야 되는지
서비스는 이런 것들을 이제 다 일일이 검토하는게 아니라 그냥 그거를 이제
어 뭐 그 서비스 성격에 맞게 아니면 뭐 셀렉트 박스로 뭘 고르면 알아서 세팅 되게 해서 나갈 수 있다면
새벽 2시에도 그 소프트웨어 엔지니어가 뭐 새벽 시까지 일하는게 좋은 건 아닙니다만
새벽 2시에 이제 코딩을 하다가 아 나 서버 필요하지 그러면 이제 버튼 누르면 바로 내가 SRE 팀이 다 자고 인프라 팀이 다 자고 있어도 내가 서버를 받아서 추가 작업을 할 수 있고 이렇게 하겠다는게 이제 셀프 서비스 개념이라고 생각하고 있고
이렇게 하려면 이제 가드레일을 제공해서 왜냐면 다 풀어 놓은 면 엉망진창이 될테니까
가드레일이 건 어 지킨 거를 따르기만 하면 도로만 따라가면 내가 길을 벗어나지 않고 목적지에 갈 수 있다는 의미가 있는 거죠
그래서 이런 식으로 바꿔서 셀프서비스를 해야 더 생산성을 높이고 원하는 목적에 이룰 수 있다고 생각합니다 좀 예를 들어 볼게요
인프라스트럭처의 코드는 어 아주 중요한 개념이죠 결국 이것도 인프라스트럭처 이제 운영 관점에 인프라 관리를 이제 수년 수십년간 싸워왔던
소프트웨어의 경험 코드로 만들어서 히스토리를 쌓고 어 변경 사항을 이제 적용하고 하는 식의 개념을 이렇게 넣은게 이제
인프라처 코드죠대표적으로 이제 테라폼이란 좋아하고 수많은 조직이 저희 조직도 그렇고 인프라 관리를 이제 테라폼으로 관리를 하게 됩니다
테라폼 관리 인프라 세즈 코드를 안 쓰면 결국 웹 콘솔 같은 데서 할 수밖에 없기 때문에 히스토리도 남지 않고 누가 언제 뭘 바꿨는지도 모르고
관리가 안 되기 때문에 결국 이런 도구를 쓸 수밖에 없다고 생각합니다 그래서 근데 이제 뭐 테라폼 자체의 문제는 아니지만
테라폼 쓰고 관리를 하는데 우리는 각 조직의 모든 엔지니어가 테라폼 코드를 짜서를 PR을 올립니다라고 했을 때
이걸 이제 셀프 서비스라고 할 수 있 까라고 생각을 해보자는 거죠 어떻게 보면 셀프 서비스죠
엔지니어들이 자기가 필요한 어 인스턴스를 다 테라폼 정의해서 들고 올라오면 물론 완전히 자동화는 되어 있지 않고
인프라 팀이 한번 리뷰를 하고 승인을 해야 어플라이를 하겠지만 뭐 그런 부분도 뭐 자동화는 할 수도 있으니까
그렇게 하면 셀프 서비스인가 이게 플랫폼 엔지니어링이 아까 말하던 거에 어 부합하는가 생각을 해 볼 수 있는데
어 이건 뭐 이제 테라폼이란 얘기 하는 거 아닙니다 테라폼의 가치는 여전하지만 저는 실제로 이게 좋은가 편한가라고
생각했을 때는 고민해 볼 여지가 많다고 생각하고 어 플랫폼 엔지어링 관점에서 더 잘할 수 있는 부분이 있다고 생각을 합니다
결국 테라폼 이런 식으로 셀프서비스를 하겠다는 건 셀프 서비스가 되기는 하지만
결국 모든 엔지니어가 테라폼이란 도구를 배워야 되고 뭐 테라폼 써 보신 분들은 알겠지만 테라폼으로 코드를 짜려면
hcl이라는 구성 언어도 이해를 어느 정도 작성할 수 있어야 되고 hcl 정의를 하려면
뭐 얘들 aws 작성하려면 aws 다 이해하고 있어야 되거든요 22가 어떻게 정의되는지
네트워크 인터페이스는 뭐고 뭐 EBS 어떻게 설정되는 이걸 다 이해하고 있지만 세팅할 수 없고 내가 이걸
가져다 써야 되는 시큐리티 그룹과 서브넷이 도대체 뭔지 이런 거를 다 하지 않으면 작성하지 못하기 때문에
결국 인지 부하가 엄청 높아진다는 거죠 그러면 원래 하려던 가치
그소프트웨어를 이제 사용자한테 제공 하는게 이제 대부분의 회사의 목표였죠 그 가치를 달성하는데 결국 그 사내 엔지니어들이 이거를 다 아는게
어 아까 말씀드린 맥락에서 설명드리면 데브옵스 관점에서 도움이 되는가라는 고민을 해 볼 수 있다고 생각해요 어떤 조직은 도움이 될 수 있다고
생각해요 그 사내 그 솔루션이나 어 제품에 따라서 우리는 다 알아야 알아야 제대로 만들 수 있어라는 조직도 있을 거고 아닐 수도 있지만
저는 이런 고민을 해 볼 수 있다는 얘기를 어 하고 있습니다
그래서 이제 어 플랫폼 엔지니어링에서 어 목표로 할 때 큰 부분은 이제 로우 스레스 홀드와 하이 셀링이 두 가지라고 생각을 하고 있습니다
예 로우 스레스 홀드는이 진입점을 낮추겠다는 거죠 진입점을 낮추고 하이 셀링을 이제 높은 천장을 얘기하는 겁니다
그래서 사내 구성원이 수많은 사람들이 있을 건데 엔지니어들 다 인프라에 대한 이해도가 다 다를 거예요 엄청 낮은 사람도 있고
관심이 전혀 없는 사람도 있고 거의 뭐 인프라 팀에 와도 될 정도로 아주 이해도가 높은 사람도 있고 다양하게 있죠
결국 이거를 플랫폼으로 제공하겠다는 거는 일정 수준 그 인프라 팀이 원하는 수준 뭐 대충 생각하면 한 80% 정도까지 다 끌어
올리겠다는 거죠 플랫폼으로 다 균일 하고 다 똑같이 맞춰서 우리는이 플랫폼으로 만든 서버는 보완도 규칙
보안 보안 정책도 적 어 적용되고 우리 산내에서 정한 뭐 컴플라이언스 뭐 정책 같은 것도 다 적용돼서 나간다는 걸로 다 끌어올리게 어제 입사에서
아니면 이제 막 개발을 시식한 신입이라서 아무것도 모르는 사람도 사고를 어 실수를 하지 않게 만드는게 결국이 플랫폼으로 하게 하는 의도라고
생각하고 이게 아까 말씀드린 이제 로우 스레스 홀드하고 생각을 합니다 쉽게 만들고 어 편리하게 만들어 만들면서 이제 퀄리티를 높인다는 거죠
예 물론 이렇게 하면 저 위에서 가로로 있는 선 위에 있는 사람들은 자유도를 좀 자연히 뺏길 수밖에 없어요
왜냐하면 규격화를 하고 플랫폼화 했기 때문이죠 왜냐면 자유도가 떨어지니까 어 나는 어 뭐 쿠버네티스를 예를 들면 쿠버네티 이런 설정 새로 들어왔다는데 이것도 쓰고 싶은데 하는데 이제
쓰기가 어려운 상황이 발생을 하고 아까 보여 드린 로우 스트레스와 하이 세일링에서 그 부분은 이제 하이
세일링이 담당해야 될 부분 이제 플랫폼을 만들면서 그런 자유도를 얼마나 줄 것이고 어떻게 줄 것인가는
이제 추가로 고민을 해서 해결해야 될 부분이라고 생각을 합니다
근데 1차적인 목표는 이제 로 스레스 홀드에 큰 방점이 있다고 생각하고 이 부분을 먼저 해결해야 그 하이 셀링 부분에 대한 고민도 할 수 있다고 생각하고 있음
그래서 결국 플랫폼엔지니어링 팀이 어 사내 플랫폼을 만들겠다는 건 사내 엔지니어가 고객이라는 의미가 된다
이건 기존의 인프라팀도 마찬가지긴 하죠 기존에 있던 사내 엔지니어가 고객이고 이거는 플랫폼을 만들기 때문에 스타트업 제품을 만들듯이 고민을 해야 된다고 생각합니다
우리의 고객이 뭘 원하고 때로는 고객이 원하는 거를 다 만들어 준다고 꼭 좋은 제품이 만들어지는 건 아님
네 그런 B2C 서비스나 아니면 B2B 서비스를 만들어 보시면 어 어느 정도는 뭐 공감하시는 분도 있을 거라고 생각하는데
요구 상황을 다 받아줘서 만들면 오히려 엉망이 되는 경우도 있고
어쩔 때는 이제 고객을 가이드해 더 좋은 방향으로 가게이 방법이 더 편하고 좋은 방법이에요라고
가이드해 줄 필요도 있는 있기 때문에
실제로 그냥 고객이 원하는 걸 다 만들어 주는 플랫폼이 아니라 그 데브옵스라는 목적
더 좋은 소프트웨어를 만들기 위한 목적에 가기 위해서 어떤 부분을 기능으로 제공하고 해야 될지
이 플랫폼이 어떤 형태가 돼야 될지를 이제 계속 고민해서 어 만들어야 된다고 생각
1-2년 정도 이런 고민을 계속 해왔고 인프라 팀의 특성상 제공자의 함정에 빠지기가 쉬운 것 같음
기본적으로 사내 엔지니어들이 고객이고 인프라 팀이 내일부터는 이거 쓰세요 하면 보통 불만을 가지고 사용함
그래서 실제로 사내 엔지니어의 사용 경험이 편한지 아닌지 모를 수가 있음
일반 B2C 서비스는 우리 서비스가 안 편하고 매력적이 아니면 안 쓰겠죠
고객이 안 오니까 그걸로 바로 피드백을 받을 수 있는데 이건 사내기 때문에 어 그렇지 않고 제공자의 함정에 빠질 수 있어요
단순하게 이거는 전에는 안 되던 건데 새로운 기능을 만들어서 자동화가 되게 만들어주면 좋겠지 기존보다 나아졌지?
라는 고민을 충분히 할 수 있는데 이런 생각을 하면 사실 좀 함정에 빠질 가능성이 높고 실제로는 양쪽의 이야기를 들어봐야함
인프라팀은 고생을 했는데 고객들은 그렇게 만족하지 못하는 사실 뭐 그러다 보면 빠져나가기도 하는데 그럴 수 있기 때문에
정리
1. 제공자의 함정에 빠지지 않는지 계속 신경을 써야함
2. 개발자 경험이 실제로 얼마나 좋은지
3. 우리 사내 엔지니어가 우리 플랫폼을 쓰면서 어떤 부분이 불편한지
4. 지금보다 더 좋은 경험을 제공해줄 수 없는지 신경써야함
it 회사들 소프트웨어 비즈니스라는 건 회사보다 더 경쟁력 있는 소프트웨어를 만드는 것
이제 플랫폼 엔지니어링 인프라 팀의 관점에서는 사내 서비스 엔지니어들이 그 일을 더 잘할 수 있게 서포트하는게 목적
결국 그 사람들이 그 일을 잘하기 위해서 사용자 경험이 충분히 좋은지 더 따 회사보다 더 압도적으로 좋을 수 없는지 고민 해야함
플랫폼 엔지니어링은 레버리지가 되게 높은 작업
조직 규모가 너무 작으면 레버리지가 그렇게 높지 않을 수도 있지만 예를 들어 사내 개발자가 엔지니어인데 CI/CD 보안 거버넌스
플랫폼을 제공해서 개발자들의 시간을 5분만이라 조금이라도 줄여줄수 있으면 100명이라고 하면 엄청 시간을 줄여줄수 있음
조직에서도 지원이 필요하지만 사내개발자들의 생상선을 높이는데 훨씬 빠르게 끌어올릴 수 있는 레버리지가 높은 작업이라고 생각을 하고 앞으로도 좀 주의깊게 볼 분야
참고 플랫폼 엔지니어링(Platform Engineering)이란 무엇인가?
해당 블로그 글은 AWS 윤석찬님의 강의와 uEngine에서 제공한 소개영상 2. 플랫폼엔지니어링이란?
3. 인프콘 2023 당근 변정훈님
4.AWS Summit 2024 Day 2 기조 연설
의 강연을 보고 정리한 내용입니다.
https://www.youtube.com/watch?v=9JXoZQn80Fs
https://www.youtube.com/watch?v=cBf3iBFktlE
https://www.youtube.com/watch?v=Vz1Je07gl5A&t=1556s