플랫폼 vs 기능 의사결정 프레임워크(Platform vs Feature Decision Framework)

플랫폼을 만들어야 할까, 아니면 그냥 기능만 빨리 내야 할까?

2015년 전후로 모든 제품팀이 모든 것을 "플랫폼"이라고 부르기 시작했습니다. 알림 시스템은 "messaging platform"이 되었고, 설정 페이지는 "configuration platform"이 되었고, 내부 대시보드는 "analytics platform"이 되었습니다. 단어의 의미가 흐려졌습니다.

하지만 그 아래에 있는 의사결정은 실제로 중요하고, 결과도 큽니다. 인앱 메시징, 추천 엔진, 인증 시스템처럼 새로운 capability가 필요할 때 팀 앞에는 세 가지 길이 있습니다. 기능으로 직접 만들기, 서드파티 도구를 사서 붙이기, 혹은 다른 소비자도 확장할 수 있는 플랫폼으로 만들기입니다. 대부분의 팀은 대안을 엄격하게 평가하지 않은 채 build를 기본값으로 선택합니다. 그 기본값은 비쌉니다.

모든 것을 직접 만드는 숨은 비용

enterprise software의 build-vs-buy 결정을 다룬 2023년 Forrester 연구에 따르면, in-house build를 기본값으로 택한 회사는 전략적으로 build와 buy를 섞어 쓰는 회사보다 5년 동안 평균 3.2배 더 많이 지출합니다. 초기 개발 비용은 빙산의 일각일 뿐입니다. 유지보수, on-call, 보안 패치, 업그레이드, 문서화 비용이 계속 복리처럼 쌓입니다.

플랫폼 질문은 더 어렵습니다. Amazon의 2002년 API mandate, 즉 모든 팀이 자신들의 기능을 서비스 인터페이스로 노출해야 한다는 Jeff Bezos의 지시는 종종 "모든 것은 플랫폼으로 만들어야 한다"는 증거처럼 인용됩니다. 하지만 그 맥락을 놓치면 안 됩니다. Amazon은 수천 명의 엔지니어, 거대한 규모, 그리고 클라우드 사업자가 되겠다는 전략적 비전을 갖고 있었습니다. 15명짜리 스타트업의 계산식은 전혀 다릅니다.

기능으로 내야 할 것을 플랫폼으로 만드는 것은 가장 흔한 과잉설계의 형태 중 하나입니다. 미래를 위한 투자처럼 느껴지지만, 실제로는 아무도 요구하지 않은 추상화 계층을 붙인 채 6개월 늦게 출시하는 경우가 많습니다. 그 사이 경쟁사는 6주 만에 기능을 내고 실제 피드백으로 반복 개선을 하고 있을 수 있습니다. Ben Thompson도 여러 차례 설명했듯, 플랫폼은 여러 소비자가 확장성을 요구한다는 분명한 수요가 있을 때 의미가 있습니다. 당신이 유일한 소비자라면, 그건 복잡성만 추가된 기능일 가능성이 큽니다.

이 프롬프트가 돕는 방식

이 프롬프트는 기능을 직접 만들지, 서드파티 도구를 구매할지, 확장 가능한 플랫폼을 구축할지 평가할 수 있는 구조화된 의사결정 프레임워크를 제공합니다. 유지보수 비용을 포함한 cost modeling, risk analysis, strategic alignment, team capability assessment를 차례로 검토합니다. 특정 옵션에 편향되지 않고, 사는 것이 맞으면 buy를, 직접 만드는 것이 맞으면 build를 추천합니다.

결과물은 엔지니어링 리더십과 이해관계자에게 그대로 설명할 수 있는 명시적 근거가 붙은 recommendation입니다.

언제 사용할까

• 엔지니어링이 내부 플랫폼을 만들고 싶어 하는데, 그 투자가 정당화되는지 평가해야 할 때
• 핵심 capability를 두고 third-party vendor와 in-house solution 사이에서 고민할 때
• 여러 제품에서 같은 기능을 반복 구현하고 있어서 shared platform 제안이 나온 상황일 때
• 비용과 일정 영향이 큰 build-vs-buy 결정을 내려야 할 때
• 새로운 요구사항이 생겼고, 이것이 기능인지 제품인지 플랫폼 플레이인지 판단해야 할 때

좋은 결과물의 모습

좋은 platform-vs-feature 분석은 각 옵션에 대해 5년 총소유비용(TCO)을 제시합니다. 단순한 build cost가 아니라 vendor dependency, team capability gap, maintenance burden까지 반영한 risk matrix가 포함되어야 합니다. 또한 지금 내린 결정을 언제 다시 검토해야 하는지에 대한 명확한 기준도 있어야 합니다. 가장 좋은 분석은 "반대 옵션이 이기려면 무엇이 사실이어야 하는가"까지 정의합니다. 그래야 양쪽을 진짜로 검토했다는 신뢰가 생깁니다.

참고 자료

• Build vs. Buy: The Real Cost of Enterprise Software Decisions — Forrester
• The Bezos API Mandate and Platform Thinking — Stratechery (Ben Thompson)
• When to Build a Platform vs a Feature — The Pragmatic Engineer