제품팀은 사업적으로 충분히 타당한 요청을 들고 플랫폼 조직을 수시로 찾는다. 새로운 시장에 진출하는 제품팀은 지역별 결제 처리기 연동이 필요하고, 새로운 할인 전략을 시험하는 제품팀은 새로운 인센티브 구조를 요구한다. 엔터프라이즈용 제품을 개발하는 또 다른 제품팀은 맞춤형 청구 기능이 필요하다. 이런 요청은 범위가 명확하고, 사업적 가치도 분명하다. 그럼에도 플랫폼팀은 이를 거절해야 하는 경우가 잦다. 요청의 타당성 때문이 아니라, 플랫폼 로드맵이 이미 더 높은 우선순위를 가진 기능과 역량으로 가득 차 있기 때문이다.
반면 제품팀이 처한 제약 조건은 전혀 다르다. 매출 목표는 플랫폼의 처리 가능 역량에 맞춰 조정되지 않는다. 출시 일정은 이미 몇 달 전에 확정돼 있다. 핵심 지표를 움직일 수 있는 가격 실험 역시 플랫폼의 우선순위 조정을 기다리며 두 분기나 미룰 수는 없다.
이처럼 익숙한 교착 상태는 혁신을 가로막고 제품팀을 비용 부담이 큰 중복 개발로 내몰며, 비즈니스 우선순위와 엔지니어링 현실을 정면으로 충돌하게 만든다. 팀 토폴로지(Team Topology)에서 상호작용 방식을 설명하는 협업 모델이나 플랫폼 전문가를 제품팀에 내재화하는 방식 등 다양한 대안이 존재하지만, 이들 접근법은 플랫폼팀이 해당 작업을 우선 처리할 여력이 있거나, 그렇지 않다면 제품팀이 독립적으로 진행해야 한다는 전제를 깔고 있다.
어웨이 티밍(Away Teaming)은 다른 해법을 제시한다. 제품팀이 플랫폼의 가이드 아래 엔지니어를 일시적으로 투입해, 자신들이 필요한 기능을 재사용 가능한 플랫폼 역량으로 직접 구축하는 방식이다. 이는 추가 자원을 투입하지 않고도 가능한 접근법으로, 제로섬 게임에 빠진 현재 상황에서 벗어날 수 있는 현실적인 출구다.
기존 접근법이 실패하는 이유
플랫폼팀은 애초에 균형이 맞지 않는 자원 방정식에 놓여 있다. 수요는 항상 처리 가능한 역량을 크게 웃돈다. 플랫폼 엔지니어링 책임자의 입장에서 보면, 매 분기마다 팀이 실제로 수행할 수 있는 양의 3~5배에 달하는 요청이 쏟아진다.
통상적인 대응 방식은 대부분 좋지 않은 결과로 이어진다.
제품팀은 기다린다. 그 사이 출시 시점을 놓치고, 경쟁사는 먼저 제품을 출시한다. 치밀하게 준비했던 시장 진입 전략은 타이밍이 어긋나며 의미를 잃는다.
제품팀이 독자적으로 개발에 나서는 경우도 있다. 몇 달이 지나면 조직 내부에는 중복된 작업이 쌓인다. 서로 호환되지 않는 여러 가지 가격 로직 구현, 포맷이 제각각인 보고서를 만들어내는 맞춤형 청구 시스템, 그리고 결국 플랫폼팀이 초기 비용의 세 배를 들여 정리해야 할 기술 부채의 그물망이 형성된다.
플랫폼팀이 모든 요청을 수용하는 선택 역시 문제를 낳는다. 핵심 로드맵 작업도, 제품팀의 요청도 모두 제대로 완수하지 못한다. 엔지니어는 소진되고, 기술 부채는 눈덩이처럼 불어난다. 급하게 구현된 기능이 누적되면서 플랫폼은 점점 더 취약한 상태가 된다.
플랫폼 우선순위와 제품팀의 요구를 맞서는 제로섬 구도로 바라보는 한, 누군가는 반드시 손해를 볼 수밖에 없다.
어웨이 티밍이 문제를 재구성하는 방식
어웨이 티밍은 기존 모델을 뒤집는다. 플랫폼 엔지니어가 전문성을 제공하기 위해 제품팀에 합류하는 대신, 제품팀 엔지니어가 일정 기간 플랫폼팀에 참여해 플랫폼의 가이드 아래 필요한 역량을 구축한다.
이는 팀 토폴로지에서 설명하는 기존 협업 패턴이나 일반적인 플랫폼 협업 모델과는 본질적으로 다르다. ‘서비스형(X-as-a-Service)’ 방식은 플랫폼팀이 서비스를 기획하고 구축할 수 있는 역량을 갖추고 있다는 전제를 깔고 있고, ‘퍼실리테이팅(Facilitating)’ 방식은 코칭을 제공할 여력이 있다고 가정한다. 반면 어웨이 티밍은 새로운 기능 개발을 맡을 플랫폼팀의 여력이 사실상 전무하지만, 거버넌스와 가이드를 제공할 최소한의 역량은 남아 있는 상황을 전제로 한다.
엔터프라이즈 제품팀이 맞춤형 청구 기능을 요청한 상황을 가정해 보자. 플랫폼팀은 이 작업을 우선순위에 올릴 수 없었다. 대신 제품팀 소속 엔지니어 2명이 8주 동안 플랫폼팀에 합류했다. 이들은 플랫폼의 가이드 아래 범용적으로 사용할 수 있는 청구 서비스를 구축했다. 그 결과 제품팀은 일정에 맞춰 엔터프라이즈 청구 기능을 확보했고, 플랫폼은 재사용 가능한 청구 역량을 얻었다. 이후 4달 뒤 또 다른 제품팀이 청구 기능을 필요로 했을 때, 동일한 청구 서비스를 그대로 활용할 수 있었다. 원래라면 각각 따로 구현됐을 작업이 여러 제품을 지원하는 단일 플랫폼 역량으로 통합된 셈이다.
새로운 자원 방정식
제품팀은 보통 6~8주로 정해진 기간 동안 엔지니어를 배정한다. 이들 엔지니어는 플랫폼 코드베이스에서 작업하고, 플랫폼 스탠드업 미팅에 참여하며, 플랫폼의 코딩 표준을 따르고 플랫폼 엔지니어로부터 가이드를 받는다.
제품팀은 이미 각자의 이니셔티브를 위해 예산을 확보한 상태다. 어웨이 티밍은 이 투자를 특정 제품만을 위한 개별 솔루션 개발이 아니라, 재사용 가능한 플랫폼 역량을 구축하는 방향으로 전환한다.
플랫폼팀 입장에서는 인력을 늘리지 않고도 실질적인 처리 역량을 확장할 수 있다. 플랫폼 엔지니어는 설계 검토를 진행하고 질문에 답하며, 코드 리뷰를 수행한다. 구현 작업에 직접 매달리지 않으면서도 전문성을 효과적으로 활용하는 셈이다. 그 결과 플랫폼은 품질 기준과 일관성을 유지한 채, 자체적으로는 예산을 배정하기 어려웠던 역량을 새롭게 확보할 수 있다.
어웨이 티밍을 위한 선행 조건
어웨이 티밍은 단순한 협업 기법이 아니다. 이 방식이 효과적으로 작동하려면 특정한 조직적 조건이 뒷받침돼야 한다.
1. 경영진의 정렬
이 모델은 플랫폼팀 단독 이니셔티브로는 성공할 수 없다. 제품 조직과 플랫폼 조직의 리더십이 공동으로 이 방식에 대한 의지를 분명히 해야 한다.
어웨이 티밍으로 인해 엔지니어가 자리를 비우면서 제품팀이 OKR을 달성하지 못하는 상황이 발생할 수 있다. 이때 제품 부문 부사장은 이를 실패가 아니라 감내할 수 있는 트레이드오프로 받아들여야 한다. 제품 부문 부사장이 이 모델을 공개적으로 지지하지 않는다면, 제품 관리자들은 어웨이 티밍을 전략적 투자가 아니라 단순한 자원 유출로 인식하게 된다. 그 결과 엔지니어를 붙잡아 두려는 행동이 강화되고, 이 모델은 명시적인 반대 없이도 참여 부족으로 자연스럽게 사라지게 된다.
이를 제품 조직 리더에게 설득하려면, 엔지니어 투입으로 인한 ‘자원 손실’을 일시적인 비용이 아니라 기술적 리스크를 줄이기 위한 전략적 투자로 설명해야 한다. 재사용 가능한 플랫폼 역량에 일시적으로 자금을 투입함으로써, 제품팀이 독자적으로 구현했을 때 발생하는 3배 수준의 정리 비용과 고위험 기술 부채를 사전에 제거할 수 있다는 점을 강조하는 것이다. 이는 조직 전체 차원에서 향후 개발 속도와 제품 안정성을 보호하는 효과로 이어진다.
2. 커리어 개발 관점의 인식
제품팀 엔지니어는 어웨이 티밍을 희생이 아니라 성장의 기회로 인식해야 한다.
단순한 지원 업무가 아니라 시스템 전반을 바라보는 사고력을 키우고 아키텍처에 대한 이해를 심화시키는 플랫폼 엔지니어링 경험으로 명확히 정의할 필요가 있다. 이 접근을 잘 실행하는 조직은 어웨이 티밍 참여 이력이 시니어 엔지니어 승진 과정에서 중요한 이정표로 받아들인다. 이는 조직이 개별 제품의 개발 속도보다, 여러 팀에 걸쳐 재사용 가능한 시스템을 구축하는 역량을 더 높이 평가한다는 신호이기도 하다.
3. 명확한 거버넌스
어떤 요청을 어웨이 티밍 과제로 전환할지 판단할 주체가 반드시 필요하다. 이를 위해 플랫폼 조직과 제품 조직이 함께 참여하는 공동 검토 프로세스를 마련하고, 다음과 같은 명확한 기준에 따라 요청을 평가해야 한다.
- - 해당 역량이 향후 여러 제품에 활용될 수 있는가?
- - 플랫폼팀이 실질적인 가이드와 지원을 제공할 수 있는가?
- - 제품팀이 참여 기간 동안 개발 속도 저하를 감수할 의지가 있는가?
이런 선행 조건은 선택 사항이 아니다. 먼저 경영진의 명확한 동의를 확보해야 하며, 이후의 모든 실행은 이 동의 여부에 달려 있다.
어웨이 티밍을 운영하는 가이드
어웨이 티밍은 제품팀 리드와 플랫폼팀 리드, 그리고 실제 작업을 수행할 엔지니어가 모두 참여하는 범위 정의 논의에서 출발해야 한다. 이 과정에서 다음 3가지 요소를 명확히 문서화해야 한다.
- - 제품팀이 반드시 달성해야 할 사업적 가치
- - 해당 작업이 충족해야 할 플랫폼 표준
- - 플랫폼팀이 제공할 지원의 범위와 내용
이 3가지 중 어느 하나라도 명확하게 정의할 수 없다면 해당 과제는 어웨이 티밍에 적합하지 않다.
임시적 팀 소속
어웨이 티밍에 참여한 구성원은 운영 측면에서 플랫폼팀에 합류한다. 플랫폼 스탠드업 미팅에 참여하고, 플랫폼 코드베이스에서 작업하며, 다른 플랫폼 작업과 동일한 수준의 엄격한 코드 리뷰를 받는다. 이는 외주나 계약 관계가 아니라, 일정 기간 동안의 임시적 팀 소속이다.
다만 원소속 팀과의 연결은 유지된다. 제품 조직 리더십과의 정기적인 동기화 과정을 통해, 진행 중인 작업이 실제 요구 사항을 정확히 반영하고 있는지 지속적으로 점검한다.
프로젝트 관리가 아닌 가이드 제공
플랫폼팀의 역할은 프로젝트 관리가 아니라 가이드 제공이다. 플랫폼 엔지니어는 서비스 경계 설정과 시스템 설계에 대한 질문에 답하고 설계 검토를 수행하며, 복잡한 과제에 대해서는 페어 프로그래밍으로 지원한다. 대신 작업 단위를 추적하거나 스프린트 계획을 관리하지는 않는다.
이러한 가이드는 실제로 상당한 시간을 요구한다. 익숙하지 않은 엔지니어의 코드를 리뷰하는 데는 더 많은 시간이 소요된다. 동시에 두 개의 어웨이 티밍 과제를 지원하는 플랫폼팀이라면, 시니어 엔지니어 기준으로 주당 약 10~15시간 정도를 가이드에 투입해야 한다. 이것이 바로 이 모델을 작동하게 만드는 핵심 투자다.
지식 이전은 필수
어웨이 티밍 과제가 종료되기 전, 최소 한 명의 플랫폼 엔지니어가 해당 코드의 지속적인 책임자가 돼야 한다. 이를 위해 다음 요소가 반드시 갖춰져야 한다.
- - 대안 검토 과정과 선택의 이유, 트레이드오프를 설명하는 문서
- - 충분한 수준의 테스트 커버리지
- - 운영 환경에서 문제가 발생했을 때 대응할 수 있는 운영 런북
어웨이 티밍에 참여한 구성원은 보통 자신들이 수행한 작업을 플랫폼 조직 전체에 공유한다. 이를 통해 플랫폼팀은 이후 직접 유지·운영해야 할 코드와 기능을 실제로 이해하게 된다.
성과와 책임 : 성공을 측정하고 실패에서 배우기
어웨이 티밍이 신뢰를 확보하려면 명확한 측정 지표가 필요하다.
먼저 역량 재사용 여부를 추적해야 한다. 구축된 플랫폼 역량이 생성 후 6개월 이내에 최초 요청 제품팀을 넘어 최소 두 개의 다른 제품에서 활용되는 것을 목표로 삼아야 한다. 만약 해당 역량이 원래의 제품팀에서만 사용된다면, 범용화를 위한 시도는 실패한 것으로 봐야 한다.
제품팀의 개발 속도에 미치는 영향도 함께 점검해야 한다. 엔지니어 두 명이 8주간 빠지는 경우, 산출물은 약 15~20% 정도 감소하는 것이 일반적이다. 이보다 영향이 크게 나타난다면, 어웨이 티밍에 투입된 엔지니어의 중요도가 예상보다 높았거나 해당 제품팀이 구조적으로 인력이 부족하다는 신호일 수 있다.
어웨이 티밍 과제의 성과도 체계적으로 관리해야 한다. 플랫폼 표준을 충족하는 정상적인 역량을 실제로 제공한 어웨이 티밍 과제의 비율이 어느 정도인지 확인해야 한다. 이 비율이 80% 아래로 떨어진다면, 기술적 깊이 부족이나 플랫폼팀의 지원 미흡 등 반복적으로 나타나는 실패 요인을 점검할 필요가 있다.
어웨이 티밍이 실패했을 때는 이를 빠르게 인정해야 한다. 모든 과제가 성공할 수는 없다. 실패한 사례 역시 무엇이 효과적이었고 무엇이 작동하지 않았는지를 보여주는 중요한 학습 자산이 된다.
어웨이 티밍이 적용되지 않는 경우
모든 역량을 위임할 수 있는 것은 아니다. 모든 거래에 영향을 미치는 핵심 결제 처리 기능이나, 규제 요건을 충족해야 하는 기본 가격 모델과 매출 인식 로직처럼 근간이 되는 영역은 다른 작업이 지연되더라도 플랫폼팀이 직접 소유하고 책임져야 한다.
어웨이 티밍은 중간 지대에 있는 역량에서 가장 효과적으로 작동한다. 즉, 당장 플랫폼 로드맵의 최우선 과제로 삼기에는 다소 제품 특화적이지만, 향후 다른 제품에서도 재사용할 수 있을 만큼 범용성이 있는 경우다.
또한 어웨이 티밍에는 규모상의 한계가 있다. 플랫폼팀은 동시에 두 개 정도의 어웨이 티밍 과제를 효과적으로 지원할 수 있지만, 이를 넘어서면 가이드를 제공할 수 있는 역량에 부담이 생기기 시작한다.
누적되는 효과
직접적인 효과는 분명하다. 자체적으로 예산을 배정하기 어려웠던 플랫폼 역량이 실제로 구축된다. 그러나 어웨이 티밍의 가치는 여기서 그치지 않는다. 부수적인 효과가 오히려 더 큰 가치를 만들어내는 경우가 많다.
먼저 플랫폼 옹호자가 자연스럽게 생겨난다. 어웨이 티밍을 경험한 제품팀 엔지니어는 아키텍처상의 트레이드오프를 이해하게 되고, 플랫폼의 제약을 설득력 있게 설명할 수 있게 된다. 이는 팀 간 긴장과 불필요한 마찰을 줄이는 데 기여한다.
역량의 분산 효과도 나타난다. 어웨이 티밍에 참여했던 엔지니어는 소속 제품팀이 플랫폼 역량을 효과적으로 활용하도록 돕고, 향후 플랫폼 확장이 필요한 지점을 포착하며, 플랫폼 서비스와 자연스럽게 연계되는 기능을 설계하는 데 기여한다.
역량은 시간이 지날수록 누적된다. 어웨이 티밍을 통해 구축된 각종 역량, 예를 들어 맞춤형 청구 기능이나 프로모션 할인 엔진은 이후 출시되는 제품에서도 그대로 활용될 수 있다. 그만큼 플랫폼 전체의 효용은 지속적으로 증폭된다.
이 과정에서도 플랫폼팀은 핵심적인 기반 작업에 집중할 수 있다. 그 결과 직접적인 자금 투입만으로는 달성하기 어려웠던 수준까지 플랫폼의 전체 역량이 크게 확장된다.
어웨이 티밍 시작하기
어웨이 티밍을 도입하려는 조직은 하나의 파일럿 프로젝트로 출발하는 것이 바람직하다. 플랫폼에 대한 명확한 요구가 있고, 협업에 열린 태도를 가진 제품팀을 선택해야 한다. 이 과정에서 운영 방식과 양측의 역할과 책임, 성공을 어떻게 측정할 것인지를 문서로 정리해야 한다. 또한 플랫폼 조직과 제품 조직 모두에서 경영진의 명확한 후원을 확보하는 것이 필수적이다.
이렇게 접근하면 제품팀과의 대화는 즉각적으로 달라진다.
플랫폼팀은 “이 작업은 우선순위에 올릴 수 없다”라고 말하는 대신, “플랫폼 예산으로는 이 역량을 구축할 수 없지만, 제품팀이 투자할 수는 있다. 일정 기간 엔지니어 투입을 감수할 만큼 이 일이 중요한가?”라고 제안하게 된다.
이는 플랫폼 의존성을 단순한 장애물에서, 제품팀이 자신의 우선순위에 따라 판단할 수 있는 현실적인 투자 결정으로 전환시킨다.
대부분의 플랫폼 조직이 받아들이기 어려워하는 현실이 있다. 모든 것을 만들 수 있을 만큼 충분한 인력을 갖추는 일은 결코 불가능하다는 점이다. 어웨이 티밍은 타협안이 아니다. 이는 자원 제약을 분산되고 재사용할 수 있는 역량 성장을 촉진하는 동력으로 전환하는 자금 조달 모델이다. 플랫폼 조직이 품질과 일관성을 유지하면서도 규모의 성장을 달성할 수 있는 방식이다.
dl-itworldkorea@foundryco.com
Pratik Gupta editor@itworld.co.kr
저작권자 Foundry & ITWorld, 무단 전재 및 재배포 금지
이 기사의 카테고리는 언론사의 분류를 따릅니다.