플랫폼은 만드는 것이 아니라 쓰이는 것이다
백엔드 개발 조직이 성숙해질수록 자연스럽게 내부 플랫폼을 구축하게 된다. 공통 인증 모듈, 배포 파이프라인, 공유 라이브러리, 내부 API 게이트웨이 등이 그 예다. 문제는 이런 플랫폼들이 기술적으로 완성도가 높음에도 불구하고 실제로 다른 팀에서 잘 사용되지 않는 경우가 많다는 점이다. "우리가 만들었으니 써야 한다"는 논리는 내부 사용자에게도 통하지 않는다.
플랫폼 개발의 함정은 기능 delivery 자체를 완료 기준으로 삼는 데 있다. PR이 머지되고, 배포가 완료되고, 문서가 작성되었다고 해서 그 기능이 "완성"된 것은 아니다. 진정한 완료 기준은 다른 팀이 해당 기능을 신뢰성 있게 사용할 수 있는 상태여야 한다. 이 관점의 전환이 플랫폼 팀과 사용 팀 사이의 단절을 줄이는 출발점이 된다.
채택률과 마찰 감소를 지표로 삼아야 하는 이유
플랫폼의 성공을 측정하는 두 가지 핵심 질문이 있다.
- "이 기능이 실제로 사용되고 있는가?" — 사용률 지표는 단순하지만 강력하다. 내부 플랫폼이라도 사용 현황을 추적하지 않으면 어떤 기능이 가치 있는지 판단할 수 없다.
- "사용자의 마찰을 줄였는가?" — 온보딩 시간, 반복 문의 건수, 통합에 걸리는 시간 등을 측정하면 플랫폼이 실제로 개발자 경험을 개선하고 있는지 알 수 있다.
예를 들어, 공통 인증 모듈을 배포했다면 아래와 같은 방식으로 채택 여부를 코드 레벨에서도 추적할 수 있다.
// 플랫폼 팀이 제공하는 공통 인증 필터 사용 여부 모니터링
@Bean
public FilterRegistrationBean<AuthFilter> authFilterRegistration() {
FilterRegistrationBean<AuthFilter> registration = new FilterRegistrationBean<>();
registration.setFilter(new AuthFilter(metricsRegistry)); // 사용 시 메트릭 기록
registration.addUrlPatterns("/api/*");
return registration;
}
이처럼 플랫폼 컴포넌트 자체에 사용 메트릭을 내재화하면, 별도의 설문 없이도 채택률 데이터를 수집할 수 있다.
제품 사고방식으로 내부 플랫폼을 바라보기
4년차 이상의 개발자라면 기술 역량만큼이나 내부 고객(다른 개발팀)의 요구를 이해하고 반영하는 역량이 중요해진다. 플랫폼 팀이 제품 팀처럼 사고한다는 것은, 기능 로드맵을 내부 사용자의 페인포인트로부터 도출하고, 출시 후 피드백 루프를 운영하며, 사용 데이터를 기반으로 다음 우선순위를 결정하는 것을 의미한다.
실무에서 이를 적용하려면 플랫폼 기능을 릴리즈할 때 단순히 기술 문서만 작성하는 것을 넘어서야 한다. 사용 예시, 마이그레이션 가이드, 온보딩 체크리스트를 함께 제공하고, 초기 도입 팀과 직접 협업하며 마찰 포인트를 조기에 식별하는 과정이 필요하다. "왜 안 쓰는가?"를 묻는 것이 "왜 못 만들었는가?"를 묻는 것만큼 중요한 질문이 된다.
정리
- 플랫폼 기능의 완료 기준은 배포가 아니라 다른 팀이 신뢰성 있게 사용 가능한 상태로 정의해야 한다.
- 채택률과 마찰 감소를 핵심 지표로 삼아 개발 방향을 사용자 가치 중심으로 정렬하라.
- 내부 플랫폼도 제품처럼 운영하라 — 사용 데이터 수집, 피드백 루프, 온보딩 경험 개선이 기술 완성도만큼 중요하다.