플랫폼 팀의 딜레마: 만들었는데 아무도 안 쓴다
플랫폼 팀이 수개월을 투자해 정교한 내부 도구를 만들었는데, 정작 개발자들이 사용하지 않는 상황은 놀랍도록 흔하다. 이는 기술적 완성도의 문제가 아니다. 플랫폼의 존재 이유를 조직 내 이해관계자들에게 납득시키지 못하고, 실제 사용자인 개발자들의 고통(pain point)을 제대로 파악하지 못한 데서 비롯된다. 결국 플랫폼 팀의 성패는 기술력만큼이나 커뮤니케이션과 가시성 확보에 달려 있다.
경영진에게 먼저 보여라
플랫폼 팀이 자주 범하는 실수는 좋은 도구를 만들면 자연스럽게 채택될 것이라고 가정하는 것이다. 하지만 조직 내에서 플랫폼이 지속적으로 지원받으려면, 경영진이 그 가치를 인식해야 한다. 이를 위해 플랫폼의 활동과 성과를 꾸준히 가시화하는 노력이 필요하다.
핵심은 추상적인 설명 대신 측정 가능한 지표로 말하는 것이다. DORA(DevOps Research and Assessment) 메트릭은 이 맥락에서 특히 유용하다. 배포 빈도, 변경 실패율, 복구 시간 같은 지표를 플랫폼 도입 전후로 비교하면, 경영진이 직관적으로 이해할 수 있는 언어로 가치를 전달할 수 있다.
// DORA 메트릭 예시: 배포 빈도 추적 로그
DeploymentEvent event = DeploymentEvent.builder()
.service("order-service")
.deployedAt(Instant.now())
.result(DeployResult.SUCCESS)
.build();
metricsRepository.save(event);
이해관계자와 지속적으로 대화하라
플랫폼이 채택되지 않는 또 다른 이유는 팀이 스스로 문제를 정의하고, 스스로 해결책을 만들기 때문이다. 실제 개발자들이 무엇 때문에 불편한지를 직접 듣지 않으면, 아무리 잘 만들어진 플랫폼도 현실과 어긋나기 쉽다.
이해관계자와의 소통은 일회성 인터뷰가 아닌 지속적인 피드백 루프로 운영되어야 한다. 정기적인 개발자 설문, 팀별 리뷰 세션, 슬랙 채널 등을 통해 현장의 목소리를 수집하고, 이를 플랫폼 로드맵에 반영하는 구조를 만드는 것이 중요하다. 플랫폼 팀이 "우리가 만들고 싶은 것"이 아니라 "개발자들이 실제로 필요한 것"을 중심으로 움직여야 한다.
숨겨진 고통을 내러티브로 가시화하라
개발자들이 매일 겪는 불편함은 대부분 조직 차원에서 보이지 않는다. 로컬 환경 세팅에 반나절을 날리거나, 배포 파이프라인 오류를 추적하느라 몇 시간을 소비하는 일들은 개인의 고통으로 남을 뿐, 조직적 문제로 인식되지 않는다.
이러한 숨겨진 비용을 수치와 스토리로 드러내는 것이 플랫폼 팀의 역할이다. "개발자 1인당 주당 평균 3시간을 환경 설정에 소모한다"는 수치와 함께, 실제 팀이 겪은 구체적인 사례를 내러티브로 구성하면, 경영진과 타 부서가 문제를 피부로 느낄 수 있다. 공감이 생겨야 예산과 지원도 따라온다.
정리
- 플랫폼의 가치는 DORA 메트릭처럼 측정 가능한 지표로 경영진에게 증명해야 한다
- 이해관계자와 지속적으로 대화하며 실제 개발자 고통을 플랫폼 방향에 반영해야 한다
- 숨겨진 비용을 구체적인 수치와 내러티브로 가시화해야 조직의 공감과 지원을 얻을 수 있다