4. 플랫폼 엔지니어링
정의
플랫폼 엔지니어링은 팀 간 사회적 상호작용과 자동화·셀프서비스·반복가능성의 기술적 측면이 교차하는 사회기술적(sociotechnical) 규율입니다. 흔히 내부 개발자 플랫폼(Internal Developer Platform) 이라 불리는 툴체인·워크플로를 설계·구축해, 개발팀이 애플리케이션을 안전·신뢰·규정 준수 방식으로 쉽게 빌드·테스트·배포하도록 골든 패스를 제공합니다.
인프라 티켓 모음이 아니라 개발자를 위한 내부 제품으로 이해해야 합니다. 2025년 기준 도입은 거의 보편화되어 90%의 조직이 내부 개발자 플랫폼을 사용하고 76%가 전담 플랫폼 팀을 두고 있습니다.
DORA 연구: 플랫폼 품질이 높으면 AI 도입의 조직 성과 효과가 강하고 긍정적이며, 낮으면 효과가 미미합니다.
AI 관점
AI는 증폭기입니다. 조직은 개별 개발자에게 AI 도구를 쥐여주는 데 속도를 내고 있지만, DORA 데이터는 개별 생산성 향상이 "하류의 무질서(downstream disorder)"에 삼켜지는 위험을 보여줍니다. 코딩 속도 향상은 테스트·보안 리뷰·복잡한 배포의 병목에 흡수됩니다.
고품질 플랫폼은 AI의 배포·거버넌스 계층 역할을 합니다. AI 생성 코드를 일관되게 테스트·보안·배포함으로써, 안정성을 희생하지 않고 AI의 속도를 조직적 성과로 전환합니다.
구현 방법
- 제품 관리 마인드셋 채택. 플랫폼은 내부 제품, 개발자는 고객. 제품 관리자를 배정해 DevEx와 로드맵에 집중하고, 핵심 사용자 여정("새 서비스 띄우기", "프로덕션 이슈 디버깅")을 매핑해 마찰을 제거한다.
- 인지 부하를 적극적으로 "shift down". 개발자가 Kubernetes·네트워킹·보안 정책 전문가가 되도록 강요하지 말고, 복잡성을 플랫폼으로 내린다. 2024년 연구: 개발자 독립성(지원 팀(enabling team)에 의존하지 않고 작업을 수행하는 능력)은 팀·개인 생산성을 5% 높였다.
- "최소 기능 플랫폼(MVP)"으로 시작. 가장 흔한 워크플로의 골든 패스를 만들고, 그 여정만 확실히 개선한다.
- 확장성 있게 설계. 중앙 플랫폼 팀이 모든 것을 만들 수 없다. 명확한 API·기여 모델로 다른 팀이 표준 방식으로 기여하게 한다.
- 명확한 피드백 우선. 2025년 데이터: 긍정적 사용자 경험과 가장 상관 높은 플랫폼 역량은 "내 작업 결과에 대한 명확한 피드백" 이다.
흔한 함정
- "만들면 올 것이다" 함정: 사용자 리서치 없이 가정으로 플랫폼을 만든다 → 낮은 채택.
- "상아탑" 접근: 중앙 팀이 협업 없이 표준을 강요 → 섀도 IT 우회.
- "티켓 옵스" 함정: 셀프서비스가 아닌 반응형 인프라 자판기 → 병목.
- "빅뱅" 릴리스: 완벽한 플랫폼을 한 번에 구축하려는 고위험 접근.
- "일률적" 사고: 데이터 과학·모바일 등 다양한 니즈를 무시하는 경직된 "황금 새장".
측정 방법
DORA 연구에 따르면 플랫폼은 생산성과 조직 성과를 높이지만, 신중하게 관리하지 않으면 처리량과 변경 안정성이 떨어질 수 있습니다. 따라서 아래 지표를 균형 있게 함께 봐야 합니다(balanced scorecard).
소프트웨어 딜리버리 성과: 변경 리드 타임, 배포 빈도, 실패 배포 복구 시간, 변경 실패율, 배포 재작업률. 플랫폼 팀은 이를 자기 성과 측정에, 애플리케이션 팀은 플랫폼이 노출하는 지표로 활용한다.
개발자 만족도(DevEx): CSAT·NPS로 정기 설문.
채택·유지: H.E.A.R.T. 프레임워크로 신규 팀 온보딩률·지속 사용률.
작업 성공: 플랫폼에서 핵심 워크플로 완료의 효율·효과.
주의: J-커브
플랫폼 엔지니어링은 J-커브를 따릅니다. 초기 성과 후 복잡성 증가로 하락했다가, 성숙하며 더 높은 수준에서 회복·안정됩니다. 기대치를 관리하세요.
출처
이 글은 DORA의 Platform engineering을 요약한 것입니다. 원문 © Google LLC, CC BY 4.0.