해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 18 - Platform Engineering Is Not About Tech
1. 플랫폼 엔지니어링이란?
플랫폼 엔지니어링의 본질은 특정 기술 스택을 구축하는 것이 아니라, 조직 전체의 소프트웨어 개발과 개발 문화을 개선하는 활동이다.
플랫폼은 단순히 도구의 집합이 아니라, '사람들이 가치를 공유하는 공통된 공간'이다.
이는 개발자, 프로덕트 오너, 비즈니스 기술 전문가 등 조직의 모든 구성원들이 디지털 제품을 더 효율적으로 시장에 출시하기 위해 협력하는 기반을 의미한다.
플랫폼 엔지니어링의 최종 목표는 '마찰 없는 셀프서비스 개발자 경험'을 제공하는 것이다.
이는 개발자들이 인프라 구성이나 반복적인 작업에 드는 시간을 최소화하고, 자율적으로 가치 있는 소프트웨어를 생산하는 데 집중할 수 있는 환경을 만들어주는 것을 의미한다.
이처럼 플랫폼 엔지니어링이 단순한 기술 도입이 아닌 조직 문화 개선 활동인 이유는 '콘웨이의 법칙'으로 설명할 수 있다.
콘웨이의 법칙
"시스템의 설계는 그것을 만드는 조직의 의사소통 구조를 그대로 복제한다."
따라서, 중앙화되고 통합된 '플랫폼'이라는 시스템 설계를 원한다면, 기술 도입에 앞서 조직 내 사람들이 소통하고 협업하는 방식 또한 그에 맞게 변화시키려는 노력이 중요하다.
2. 왜 70%의 플랫폼이 실패하는가?
발표자는 2025년까지 70%의 플랫폼이 실패할 것이라 예측한다.
그 원인이 기술 역량 부족이 아닌 잘못된 접근 방식에 존재한다고 주장한다.
-
과도한 기술 중심주의: 플랫폼 구축 프로젝트가 시작되면, 대부분의 대화는 "어떤 CI/CD 도구(ArgoCD, FluxCD 등)를 쓸까?", "인프라는 어떻게 구성할까?"와 같은 기술적인 선택에만 집중된다. 하지만, 이러한 기술적 결정은 플랫폼이 실패하는 결정적인 지점이 아니다.
-
사용자(개발자)의 부재: 기술 논의에 매몰되는 동안, 플랫폼을 실제로 사용해야 할 개발자들의 필요, 고충, 현재의 작업 방식 등은 무시된다.이는 결국 아무도 사용하지 않거나, 사용을 꺼리는 플랫폼을 만드는 결과로 이어진다.
-
비기술적 요소 간과: 플랫폼을 하나의 내부 제품으로 인식하지 못하고, 성공적인 제품에 필수적인 사용자 경험(UX), 마케팅, 변화 관리 등의 비기술적 요소를 간과한다. 기술만 완벽하게 구축하면 사람들이 알아서 쓸 것이라고 착각하는 것이 가장 큰 실패 요인이다.
즉, "기술에만 투자하면 조직, 문화, 프로세스는 저절로 따라올 것"이라는 안일한 믿음이 70%의 플랫폼을 실패로 이끄는 핵심 원인이라고 강조한다.
3. 플랫폼이 실패하는 8가지 함정
발표자는 플랫폼이 기술적 문제보다 비기술적인 함정에 빠져 실패하는 경우가 많다며, 경험을 통해 발견한 8가지 주요 원인을 제시한다.
1. 불분명한 미션 (Unclear Mission)
"현재 방식은 지속 불가능하다", "무언가 자동화해야 한다"는 막연한 문제 인식만으로 프로젝트를 시작하는 경우이다.
이는 명확한 목적, 범위, 미션이 설계된 '제품 이니셔티브'가 아니라, 단순히 현장에 나가 일단 공을 차고 보는 식의 접근 방식이다.
플랫폼도 하나의 제품임에도 불구하고, 해결해야 할 명확한 비전과 전략 없이 시작하여 결국 방향성을 잃고 실패하게 된다.
2. 정치적 자본 부족 (Lack of Political Capital)
새로운 플랫폼 팀이 MVP (최소 실행 가능 제품)로 작게 시작하는 전략은 좋지만, 이는 곧 한계에 부딪힌다.
플랫폼을 더 넓은 범위로 확장하기 위해서는 조직 내 영향력, 즉 '정치적 자본'이 필수적이다.
하지만 초기 팀은 아직 큰 성과를 내지 못했기 때문에 정치적 자본이 부족하며, 다른 팀의 참여를 이끌어내기 위해 훨씬 더 많은 노력을 기울여야 하는 어려움에 직면한다.
3. 개발자 기대치 불일치 (Doesn't Match Developer Expectations)
플랫폼이 개발자의 기대를 충족시키지 못하는 문제는 단순히 개발자의 요구를 제대로 파악하지 못해서만 발생하는 것이 아니다.
플랫폼 팀이 과도한 열정으로 자신들의 제품을 홍보하는 과정에서 발생하는 '소통의 불일치'가 더 큰 원인이다.
"달을 보여주겠다"고 약속했지만, 초기 버전에서는 작은 기능만 제공될 경우, 개발자들은 큰 실망을 느끼게 되며 플랫폼에 대한 부정적 인식이 형성된다.
4. 내부 경쟁 (Internal Competition)
조직 내 팀들이 플랫폼을 중심으로 협력하기보다 경쟁하는 구도가 형성된다.
이는 "우리 팀이 더 낫다"는 식의 태도에서 비롯되기도 하지만, 선의의 경우에도 발생한다.
특히 규모가 큰 기업에서는 여러 팀이 각자의 필요에 따라 개발자 도구를 만들게 되고, 시간이 지나면서 이 도구들의 기능이 서로 중복되어 의도치 않은 경쟁 관계가 만들어지기도 한다.
5. 혁신과 안정성의 불균형 (Innovation vs. Stability Imbalance)
개발자들은 항상 최신 기술을 도입하여 혁신하고 싶어 하지만, 플랫폼은 사용자들에게 예측 가능하고 신뢰할 수 있는 '안정성'을 제공해야 하는 책임이 있다.
플랫폼 팀은 이러한 혁신에 대한 요구와 안정성 유지 사이에서 균형을 맞추지 못하고, 플랫폼이 충분한 성숙도에 도달하기 전에 잦은 변화를 시도하다가 사용자의 신뢰를 잃게 된다.
6. 유지보수 비용 간과 (Cost of Maintenance)
클라우드 네이티브와 같이 기술 발전 속도가 매우 빠른 환경에서 플랫폼을 지속적으로 유지하고 혁신하는 데 드는 막대한 장기적 비용을 간과한다.
오늘의 최신 플랫폼이 내일의 레거시가 되는 것을 막기 위한 노력은 생각보다 큰 비용을 요구하며, 이는 장기적으로 조직이 감당할 수 없는 수준이 될 수 있다.
7. 내부 소통 능력 부족 (Poor Internal Communication Skills)
플랫폼 실패의 가장 결정적인 원인 중 하나로, 플랫폼 주변의 공감대를 형성하는 데 실패하는 것이다.
플랫폼 팀은 개발자, 엔지니어, 운영팀 등 모든 잠재적 사용자와 적극적으로 대화하여 그들의 실제 업무 방식, 원하는 목표, 플랫폼이 그들의 일상을 어떻게 개선해 줄 수 있는지 파악해야 하지만, 이러한 근본적인 소통 노력을 소홀히 한다.
8. 변화 관리의 숨겨진 비용 (Hidden Cost of Change Management)
플랫폼 도입의 최종 목표는 조직 구성원들의 일하는 '습관'을 바꾸는 것이다.
하지만 사람들의 습관은 그것이 비효율적이어서가 아니라, 오히려 '자신들의 업무를 가장 효율적으로 만들어주기 때문에' 형성된 것이다.
이처럼 타당한 이유를 가진 개인과 조직의 습관을 바꾸는 것은 매우 복잡하고 어려운 일이며, 여기에 수반되는 막대한 '변화 관리'의 비용과 노력을 대부분의 플랫폼 팀이 과소평가한다.
4. 성공을 위한 전략과 사례
발표자는 앞서 언급한 함정들을 피하고 성공적으로 플랫폼을 구축한 세 가지 사례를 공유한다.
이 사례들은 각기 다른 상황에서 어떻게 비기술적 요소에 집중하여 성공을 이끌어냈는지 보여준다.
사례 1: MVP (최소 실행 가능 플랫폼) 접근법
-
대상: 에너지 분야의 한 스케일업(약 40명 규모)
-
전략: 모든 팀을 위한 거대한 플랫폼 대신, 협업이 가장 시급했던 두 팀 (데이터 제품팀, 앱 개발팀)의 공유된 요구사항에 집중
-
성공 요인:
플랫폼이 처음부터 실질적인 비즈니스 가치(팀 간 협업 활성화)를 즉각적으로 제공했기 때문에, 경영진과 현업으로부터 강력한 지지를 얻을 수 있었음. -> 이 초기 성공을 통해 형성된 "플랫폼이 실제로 우리 업무에 도움이 된다"는 공감대는 이후 플랫폼의 기능을 조직 전체로 확장해 나가는 데 중요한 동력이 되었음.
사례 2: 사람에 대한 투자 (교육 및 참여 유도)
-
대상:전 세계 1,000명 이상의 엔지니어를 둔 글로벌 제조 대기업
-
전략: C레벨의 강력한 지원을 바탕으로, 예산의 상당 부분을 기술 개발이 아닌 전 세계 개발자들을 위한 교육과 참여 유도에 투자
-
성공 요인: 기술 도입에 앞서 사람과 문화의 변화에 먼저 투자함으로써, 거대하고 복잡한 글로벌 조직임에도 불구하고 구성원들의 저항을 최소화하고 성공적으로 플랫폼을 안착시킬 수 있었음.
사례 3: 가장 얇은 실행 가능 플랫폼 (Thinnest Viable Platform) 접근법
-
대상:다국적 시스템 통합(SI) 기업.
-
전략: 초기에 구축했던 복잡한 플랫폼을 과감히 폐기하고, 핵심 가치에만 집중한 더 작고 가벼운 플랫폼을 새로 구축. 시간이 지나며 상품화되거나 덜 중요해진 기능은 과감히 제거하거나 외부 솔루션으로 대체하여 플랫폼을 항상 '얇게' 유지하는 전략 사용
-
성공 요인: 플랫폼을 지속적으로 가볍고 핵심적인 상태로 유지하려는 노력이 성공 요인
이러한 성공 전략 및 사례를 통해, 성공적인 플랫폼 전략의 핵심은 작고 구체적인 문제 해결로 시작하여 즉각적인 가치를 증명하고, 기술 도입에 앞서 사람과 문화의 변화에 우선적으로 투자하며, 장기적인 관점에서 플랫폼을 항상 가볍고 핵심적인 상태로 유지하는 것이 중요한 요소임을 알 수 있다.
5. 결론
플랫폼의 최종 목표는 '기술 도입'이 아닌, '더 나은 개발자 경험'이다. 이는 모든 노력이 개발자의 생산성과 자율성을 높이는 데 집중되어야 함을 의미한다.
이러한 목표는 기술을 넘어 '조직 문화의 변화'를 요구한다. 콘웨이의 법칙에 따라, 기술 아키텍처를 바꾸려면 반드시 조직의 소통과 협업 방식도 함께 개선되어야 한다.
따라서, 플랫폼의 가장 큰 도전은 '기술'이 아니라, '사람들의 습관을 바꾸는 것'이다. 플랫폼팀은 기술적 문제 해결보다 기존의 작업 방식을 고수하려는 조직 구성원들의 변화 관리가 훨씬 더 중요하고 어려운 과제임을 인지해야 한다.
진정한 성공은 플랫폼을 '구축'하는 것이 아니라, 개발자들이 '채택하고 사랑하게 만드는 것'에 달려 있다. 단순히 플랫폼을 제공하는 것에서 그치지 않고, 사용자들이 자발적으로 사용하고 싶어 할 만큼의 가치와 경험을 제공하는 것이 최종 목표임을 인지해야한다.
