플랫폼 엔지니어링 이란: 개발 팀의 효율을 바꾸는 방법
요약
플랫폼 엔지니어링 이란 내부 개발자 플랫폼을 통해 팀이 셀프서비스로 서비스를 만들고 배포하게 하는 일입니다. DevOps와 SRE와 다르게, 개발 속도를 주 지표로 삼습니다. 20-30팀 이상일 때 가치가 있고, 골든 패스라는 권장 기본값을 제공합니다. 올바르게 시작하려면 한 가지 고통을 해결하는 최소 버전부터 만들고, 팀에게 선택권을 줘야 합니다.
지금 밤 10시 10분이다. 새로 입사한 개발자가 스테이징 환경을 받으려고 이틀을 꼬박 보냈다. 티켓 3개를 올렸고, 같은 Terraform 에러를 Slack에 두 번이나 붙여넣었는데도, 네 개의 CI 템플릿 중 어느 것이 정식인지 여전히 모른다. 바로 이 장면이 "플랫폼 엔지니어링 이란 무엇인가"에 대한 전부다. 누구도 혼자 정글을 헤치게 하지 않으려고 내부 포장도로를 닦는 일이고, 그 도로를 사용자가 있는 상품처럼 다루는 것이다.
실제로 플랫폼 팀이 만드는 것은 내부 개발자 플랫폼(IDP)이다. 다른 개발자들이 서비스를 만들고 배포하고 실행 상황을 보는 동안 누군가를 기다리지 않도록 하는 셀프서비스 도구들이다. 여기가 끊어질 때 벌어지는 일: 모든 팀이 배포를 다시 만들고, 그 지식은 3명의 머리 속에만 산다.
플랫폼 엔지니어링 이란: 유행어 빼고 본질만
가장 명확한 정의는 platformengineering.org 커뮤니티에서 나온다. 팀이 반복되는 일들을 셀프서비스로 할 수 있는 능력을 주는 플랫폼을 설계하고 만드는 일이다. 유행어를 빼면 움직이는 부분은 세 가지다.
첫째, 내부 개발자 플랫폼이다. 사는 상품 하나가 아니다. 이미 실행 중인 도구 위에 앉는 얇은 템플릿, 파이프라인, API, 문서 계층이다. 날카로운 모서리를 숨긴다.
둘째, 플랫폼 팀이다. 고객이 다른 엔지니어들인 작은 엔지니어 그룹이다. 그들의 산출물은 최종 사용자를 위한 기능이 아니다. 다른 모든 사람이 얼마나 빨리 배포할 수 있는가다.
셋째, 상품 마인드셋이다. 플랫폼이 사용자를 가지고, 백로그를 가지고, 채택 수치를 가지고, 온콜 로테이션을 가진다. 아무도 쓰지 않으면 실패한 것이다. 아키텍처가 얼마나 우아한지는 상관없다.
Gartner는 2026년까지 대규모 소프트웨어 엔지니어링 조직의 80%가 플랫폼 팀을 갖출 것이라고 예측했다. 2022년의 45%에서 올라간 것이다. 이것을 약속가 아닌 추세 신호로 보자. 업계 소문은 그런 팀의 상당수가 실제 효과를 보여주지 못한다는 것인데, 정확히 이것이 이 글에서 뭐가 잘못되는지에 시간을 쓰는 이유다.
DevOps, SRE와는 어떻게 다른가
짧게: DevOps는 문화, SRE는 신뢰성 규칙, 플랫폼 엔지니어링은 둘 다를 상품화하는 팀 형태다.
DevOps는 개발자와 운영 팀이 실행 중인 소프트웨어 소유권을 함께해야 한다고 말했다. 좋은 생각이다. 15명 회사에서는 모두가 모든 것을 볼 수 있어서 된다. 300명 회사에서는 조용히 "모든 팀이 동시에 Kubernetes 전문가가 되어야 한다"로 변한다. 아무도 이걸 원하지 않았다.
SRE는 신뢰성 목표에 집중한다. 에러 예산, 인시던트 대응, 용량 계획 같은 것들이다. 플랫폼 팀도 신뢰성을 신경 쓰지만 주 지표가 다르다. "내가 서비스 아이디어를 냈을 때부터 로그와 알림이 있는 프로덕션에 떠 있을 때까지" 얼마나 기다리는지 측정한다.
플랫폼 엔지니어링은 DevOps가 남긴 인지 부하의 답이다. 모든 개발자에게 전체 도구 체인을 배우라고 할 대신, 지원하는 기본값을 주고 전문 지식은 플랫폼 안에 둔다. 할 이유 세 가지, 안 할 이유 한 가지: 팀 수나 서비스 수가 충분히 커서 중복이 아플 때만 갚혀진다. 그 문턱은 아래에서 본다.
플랫폼 팀이 실제로 배포하는 것
아키텍처 다이어그램은 잊자. 보통 화요일 플랫폼 팀 백로그는 이렇다.
서비스 템플릿이다. 한 줄의 명령어 아니면 포털의 버튼 하나로 리포지토리가 생기는데, 여기엔 동작하는 파이프라인, Dockerfile, 헬스 체크, 로깅 셋업, 기본 대시보드가 들어있다. 개발자는 비즈니스 로직만 바꾼다. 배관은 아니다.
배포 경로다. main으로 push하면 테스트가 돌고, 아티팩트가 빌드되고, 매번 같은 단계로 환경을 타고 올라간다. 팀마다 다른 설정 같은 게 없다.
온디맨드 환경이다. 풀 리퀘스트마다 프리뷰 환경이 생기고, 자동으로 없어진다. 이게 개발자들이 고마워하는 기능이다.
보안과 접근이다. 단기 자격증, 요청할 한 곳, 감시 추적이다. 재미없지만, 보안 감사에서 구해주는 것이다.
기본으로 관찰성이다. 템플릿에서 만든 모든 서비스는 누군가 연결하지 않아도 메트릭, 로그, 추적이 나간다. Grafana 같은 스택이 이 계층 뒤에 있고, 무료 등급과 오픈소스 옵션이 작은 팀에 맞다.
리스트에 없는 것 주목: 세 달 로드맵이 있는 커스텀 포털이다. 포털은 마지막에 더한다. 첫 것이 아니다.
골든 패스: 나머지가 작동하게 만드는 아이디어
골든 패스는 흔한 일을 하는 지원되는, 의견이 있는 방법이다. 수동으로 하는 것보다 빠르고 즉흥적으로 하는 것보다 안전하다. 결정적으로, 선택이다. 개발자는 이유가 있으면 길을 떠날 수 있다. 그리고 책임을 진다.
Octopus의 포장 대 골든 패스 글에 쓸 만한 구별이 있다. 포장 도로는 넓고 잘 유지되는 표면이고, 골든 패스는 주어진 일에 권장하는 특정 경로다. 내 경험으로 차이는 원칙 아래보다 덜 중요하다. 올바른 방법을 쉬운 방법으로 만들어서 이긴다. 다른 방법을 금지하진 않는다.
가장 작은 골든 패스는 이렇다. 개발자가 한 번 치는 단일 스캐폴드 명령이다.
platform new service payments-api \\
--template node-api \\
--env preview,staging,prod \\
--owner team-checkout그 한 줄 뒤에 리포, 파이프라인, DNS, 데이터베이스 스텁, 알림, 소유권 기록이 앉아있다. 명령은 자명하다. 어려운 부분은 "node-api"가 뭐를 의미하는지 동의하는 데 6개월, 그리고 Node가 바뀌거나 기본 이미지가 바뀌거나 클라우드 제공자가 바뀔 때 최신 상태로 유지하는 것이다.
테스트됨, 최적 아님, 그리고 우리가 그 이유: 80%의 팀이 쓰는 평범한 골든 패스가 10%가 채택하는 완벽한 패스를 이긴다. 첫 번째 것은 한 번에 모든 것을 개선할 레버리지를 준다.
가치 있을 때, 산만할 때
이 섹션은 많은 글이 건너뛴다. 플랫폼 엔지니어링은 무료가 아니고, 많은 팀에 틀린 이동이다.
platformengineer.org 개요는 조직이 대개 20~30명의 플랫폼 사용자를 지나쳐야 이득을 보기 시작한다고 한다. 나는 이것을 규칙이 아닌 대략적 바닥으로 읽는다. 그 아래, 공유 README 하나, 좋은 CI 템플릿, 신경 쓸 한 명이 공식 플랫폼 팀보다 할 일이 많다.
가치 있을 때:
팀이 여럿인데, 각각 배포 파이프라인을 다시 만들었다.
신입이 주를 버틸 수 없는 시간 대신 하루가 걸려서 첫 변경을 배포한다.
같은 인시던트 유형이 반복되는데, 각 서비스가 자기 알림을 달았다.
보안이나 컴플라이언스가 요청한 일관성을 물어봤을 때는 할 수 있지만, 친하게 물어봐서는 할 수 없다.
건너뛸 때:
너 한 팀 5명이다. 플랫폼을 만들지 말고 스크립트를 만들자.
서비스가 뭘 보일지 아직 모른다. 너무 일찍 정규화하면 틀린 결정을 얼린다.
제안이 "포털을 만들자"인데 어떤 고통을 없앨 목록이 없다.
혼자 만드는 빌더와 작은 사이드 프로젝트 팀, 정직한 결론은 더 간단하다. 플랫폼 팀이 필요 없지만, 습관이 필요하다. 반복할 배포 스크립트 하나, 새 프로젝트 템플릿 하나, 확인할 대시보드 하나. 그것이 플랫폼 오브 원이고, 달마다 주말 하나를 구해준다.
사람들이 정말 모으는 도구
플랫폼 엔지니어링 상품 하나는 없다. 팀이 스택을 조립하고, 조각들은 몇 가지 통에 떨어진다.
포털과 카탈로그는 많은 팀이 Backstage를 쓰거나 호스팅 대체, 검색 가능한 서비스, 소유자와 문서 목록을 준다. 배포는 Terraform이나 OpenTofu 더하기 Argo CD나 Flux 같은 GitOps 도구다. CI와 배포는 이미 가진 것, 공유 템플릿으로 싸인다.
두 통이 주의 깊게 보기를 받을 자격이 있다. 플랫폼이 신뢰할 만한지 결정하기 때문이다.
관찰성이다. 개발자가 자기 서비스가 뭐 하는지 못 보면, 그 플랫폼을 신뢰하지 않을 것이다. Datadog은 인프라, APM, 로그 전체에 광택 나는 단일 창을 주고, 호스트당 가격으로 빠르게 커진다. Grafana의 오픈소스 스택은 라이선스 비용 대신 운영 시간을 들인다. 부족한 자원이 돈인지 주의인지에 따라 고르자.
문서와 품질이다. 좋은 문서 없는 플랫폼은 티켓 대기열이라는 사실이다. 코드 같은 문서 도구는 설명하는 리포 옆에 가이드를 두고, CI의 코드 품질 게이트는 템플릿을 정직하게 한다.
이것들 중 요구되는 것은 없다. 플랫폼 팀이 시간을 쓰는 계층의 예다. 기본값을 고르고 템플릿에 연결하고 업그레이드 경로를 소유한다.
틀린 것을 만들지 않고 시작하기
대부분 실패하는 플랫폼 노력은 같은 패턴을 나눈다. 너무 크게 시작하고, 한 팀이 닿기 전에 달을 만들고, 로드맵 슬라이드를 위해 최적화한다. 고칠 것은 멋이 없다.
일반적이고 아픈 작업 하나를 고르자. "새 서비스 만들기"와 "프리뷰 환경 받기"가 보통 우승자다. 3명의 개발자를 인터뷰하고 그들이 하는 것을 본다. 단계와 분을 센다.
대부분의 고통을 없애는 가장 얇은 판을 만들자. 템플릿 리포와 공유 파이프라인 파일이 센다. 한 친절한 팀에 주고, 그들이 쓸 때 옆에 앉자. 부러지는 것을 고치고, 두 번째 팀에 제안하자.
두 수를 추적하자. "새 서비스"에서 "프로덕션에서 실행"까지 걸린 시간과, 몇 팀이 자발적으로 경로를 쓰는지다. 두 번째 수가 평탄하면 플랫폼이 위임이고, 위임은 부패한다.
상품 팀처럼 스태프하자. 플랫폼 엔지니어는 새 이름을 가진 DevOps가 아니다. platformengineering.org 자료는 플랫폼 엔지니어가 DevOps 프로였던 것보다 약 27% 더 번다고 한다. 그것은 시장이 상품-그리고-엔지니어링 믹스를 구별되고, 더 어려운 일로 본다는 것을 말한다.
한 가지 더 이유는 지금이다. 최신 주름은 플랫폼의 "사용자"가 더 이상 인간만 아니라는 것이다. 코딩 에이전트는 풀 리퀘스트를 열고, 테스트를 실행하고, 환경을 물어본다. 깨끗한 템플릿, 명확한 허가, 머신 읽기 가능한 문서를 가진 플랫폼이 눈송이 리포의 더미보다 에이전트가 일하기 훨씬 더 안전한 곳이다.
단기 자격증, 프리뷰 환경, 일관된 파이프라인이 에이전트의 실수를 버려지는 가지에 묶어둔다. 플랫폼이 인간 배포와 자동화된 것을 말할 수 없으면, 다른 것을 더하기 전에 그것을 더하자.
다음에 뭘 만들어야 할까
30명 개발자 팀을 이끈다면, 모든 분대가 자기 파이프라인을 가졌다면, 한 골든 패스를 가진 작은 플랫폼 팀이 아마 최고 레버리지 고용이다. 혼자 3가지 사이드 프로젝트가 있는 개발자라면, 가장 좋은 프로젝트의 파이프라인을 이번 주말 템플릿 리포에 복사하고 끝이라고 부르자.
어느 쪽이든, 다음 계획 회의에 데려갈 질문이 구체적이다: 개발자가 가장 반복하는 일은 뭔데, 그걸 한 명령 일로 만드는 데 뭐가 걸릴까?