팀이 많은 엔지니어링 조직에서는 일관성과 개발 속도를 위해 공통 문제에 대한 솔루션을 표준화할 필요가 생긴다. 이러한 공유 솔루션을 전담하는 ‘플랫폼 팀’을 도입하면 해당 프로젝트의 유지보수와 방향성에 관한 문제를 해결하는 데 도움이 될 수 있지만, 동시에 새로운 도전 과제도 뒤따른다.

왜 플랫폼 팀을 만들어야 할까?

인프라부터 애플리케이션 개발에 이르기까지 개발 팀은 다양한 공통 과제에 직면한다. 생산성을 높이고 일관성을 확보하려면 이러한 문제들에 대한 솔루션을 표준화하는 것이 필수적이다. 이렇게 하면 개발 속도가 빨라지고 유지보수 비용이 줄어들며, 팀 간 이동이 용이해지고 UI 브랜딩이나 GDPR 준수 같은 비즈니스 요구사항도 뒷받침할 수 있다.

초기에는 이러한 솔루션들이 대개 임시방편으로 공유된다. 코드를 복사하거나 공유 라이브러리를 도입하거나 다른 팀의 API를 연동하는 식이다. 하지만 전체적인 방향성도, 장기적인 유지보수에 대한 책임도, 명확한 지식 전달도 없이 이런 시스템들이 유기적으로 커지도록 두면 다루는 데 시간이 많이 들게 되고 심지어 사용 자체가 불가능해지기도 한다. 이러한 솔루션을 책임지는 팀, 흔히 ‘플랫폼 팀’이라 불리는 팀을 구성하면 이 문제를 해결하는 데 도움이 될 수 있지만, 새로운 도전 과제들을 안게 된다.

우선순위 정하기

새로 생긴 플랫폼 팀이 초기에 마주하는 문제 중 하나는 우선순위다. 플랫폼에 의존하는 엔지니어링 팀이 많다 보니, 팀은 쉽게 여러 방향으로 끌려 다니게 된다. 핵심 질문은 이것이다. 무엇을 먼저 해야 할지 어떻게 정할 것인가?

Product Owner는 엔지니어링 팀, 특히 Scrum을 따르는 팀에게는 매우 중요하다. 하지만 플랫폼 팀 안에서 이 역할을 맡을 적임자를 찾는 일은 쉽지 않다. 엔지니어들의 요청을 기술적으로 잘 이해하면서도 비즈니스 우선순위에 대해서도 잘 알아야 여러 비즈니스 이니셔티브 사이에서 효과적으로 우선순위를 정할 수 있기 때문이다. 현실적으로는 이 역할을 수행하면서 동시에 충분한 시간을 낼 수 있는 사람을 찾기가 어려운 경우가 많다.

한 가지 방법은 상위 수준의 우선순위 결정을 내리는 위원회를 구성하는 것이다. 시니어 엔지니어, 아키텍트, 프로덕트 매니저, 경영진이 포함될 수 있다. 하지만 이 그룹은 자주 모이기 어렵고, 결국 일상적인 우선순위와 작업 범위에 대한 결정을 내릴 권한을 가진 사람이 여전히 필요하다. 팀과 긴밀하게 일하는 시니어 엔지니어나 매니저가 그 역할을 맡게 될 것이다.

일정 관리

우선순위를 정해 두었더라도 플랫폼 팀은 여전히 프로젝트 딜리버리의 병목이자 단일 실패 지점이 될 수 있다. 플랫폼 팀 때문에 프로젝트가 막혔다는 말을 계속 듣는 것은 사기를 떨어뜨리고 해로운 일이다. 플랫폼의 가장 중요한 목표는 딜리버리 속도를 높이는 것인데, 팀 간 의존성을 잘못 관리하면 오히려 속도가 느려질 수 있다.

유용한 방법 중 하나는 Basecamp의 Shape Up에서처럼 “고정 기간 프로젝트”를 활용하는 것이다. 기간을 고정하고 범위를 제한한 프로젝트를 약속하면 짧은 스프린트보다 더 긴 기간 동안 팀이 무엇을 하고 무엇을 하지 않을지에 대한 명확성을 확보하는 데 도움이 된다. ‘Betting Table’이라는 아이디어 역시 우선순위 위원회 방식과 잘 어울린다.

플랫폼 팀이 항상 여러 이니셔티브에 허덕이고 있다면 방식을 재고할 때다. 좋은 플랫폼은 엔지니어의 발목을 잡는 것이 아니라 속도를 높여줘야 한다. 유연성이 핵심이다! 자주 들어오는 요청은 명확한 문서와 함께 셀프서비스가 가능하도록 만들자. 플랫폼 팀은 모든 일을 떠맡기보다 시스템 설계나 코드 리뷰를 통해 다른 팀을 돕는 든든한 ‘컨설턴트’ 같은 역할을 할 수도 있다.

새로운 기능 요청에만 계속 수동적으로 대응하는 데 갇히지 말자. 다른 엔지니어링 팀이 쉽게 변경할 수 있도록 만드는 데 집중하자. 그들이 당신이 제공하는 도구와 프레임워크를 활용해 과제를 해결하도록 하라. 그렇게 하면 플랫폼 팀의 업무 대부분은 결국 중요한 신규 추가나 변경 같은 일에 집중될 수 있다.

사람들이 실제로 쓰는 것 만들기

플랫폼 팀으로서 가장 중요한 미션은 다른 팀이 문제를 해결하도록 돕는 것이어야 한다. 하지만 별도의 팀으로 구성되면 다른 엔지니어링 팀이 실제로 겪고 있는 어려움으로부터 동떨어지기 쉽다.

Product Owner 역할을 맡을 사람이 있다면 큰 차이가 생긴다. 지원하는 팀이 실제로 원하지 않는 솔루션으로 문제를 해결하는 데 몰두하지 않도록 하자. 그들의 유스케이스에 맞지 않아서든, 그 문제가 그들에게 우선순위가 아니어서든 말이다.

플랫폼은 하나의 프로덕트이며, 다른 엔지니어링 팀은 당신의 고객임을 기억하자. 그들이 강요에 의해서가 아니라 원해서 그리고 스스로 선택해서 플랫폼을 사용하도록 만드는 것을 목표로 하자. 고객 중심으로 움직일 방법을 찾고, “표준을 강제”할 방법을 고민하기 전에 도입률이 낮다면 먼저 솔루션을 재평가하라.

너무 이른 공유

플랫폼 팀이 생기면 다양한 사람들이 ‘범용 솔루션’이라며 밀어붙이고 싶은 멋진 아이디어들이 모두 모일 곳이 생긴다. 너무 일찍 공유하고 싶은 유혹을 참아내자!

하나의 탄탄한 유스케이스만으로 공유 시스템에 알맞은 추상화 수준을 잡아내는 것은 불가능하다. 너무 일찍 공유 구현에 커밋하면 새로운 요구사항이 생길 때마다 옵션이 덧붙여져 혼란스러운 API가 되기 쉽다. 여러 컨슈머가 있는 상태에서 브레이킹 체인지를 만드는 데는 큰 비용이 든다.

새로운 플랫폼 기능이 추가될 가능성을 일찍 인지하는 것은 좋지만, 나중에 플랫폼 수준의 솔루션이 될 가능성이 있더라도 엔지니어링 팀이 스스로 문제를 해결할 수 있는 자율성은 보장해 주자.

나는 솔루션의 플랫폼 편입 여부를 결정할 때 따를 가이드라인으로 세 번의 법칙이 유용하다는 것을 알게 되었다. “재사용 가능한 컴포넌트는 재사용 라이브러리에 포함될 만큼 충분히 일반화되기 전에 세 개의 서로 다른 애플리케이션에서 시험되어야 한다”는 것이다.

• 첫 번째 요청: 그냥 스스로 해결한다
• 두 번째 요청: 기존 솔루션을 함께 살펴보고 시스템 설계를 협업하되, 구현은 여전히 직접 한다
• 세 번째 요청: 세 가지 유스케이스를 모두 지원하는 플랫폼 수준의 솔루션을 구현한다

레거시 교체

플랫폼 팀을 구성했다면, 아마도 유기적으로 발전해 오면서 오너십과 시스템 설계, 유지보수 부재의 희생양이 된 공유 솔루션들이 어느 정도 있기 때문일 것이다. 이런 시스템들은 다루기 악몽 같고, 문서도 부실하며, 지원이 종료된 소프트웨어 버전에서 돌아가고 있을지도 모른다. 모든 것을 허물고 처음부터 다시 쓰자는 유혹은 엄청나게 강렬하다… 그리고 위험하다!

완전히 새로 만든 것이 반드시 더 낫다는 보장은 없으며, 특히 사용자의 관점에서는 더욱 그렇다. 지저분해 보여도 오랜 시간 실전에서 검증된 프로덕션 솔루션에는 시간이 지나며 쌓인 복잡한 비즈니스 요구사항이 녹아 있기 마련이다.

더 나쁜 경우, 특히 여러 곳에서 사용되고 있다면 기존 시스템을 완전히 대체하지 못할 가능성도 크다. 새로운 시스템으로 마이그레이션하는 것은 다른 팀에게 작업과 리스크를 안긴다. 부분적으로만 마이그레이션된다면 이제 유지보수 부담이 두 배가 된다. 하나의 시스템 대신 두 개를 지원해야 하고, 둘 사이의 기능 차이까지 관리해야 하기 때문이다.

이상적인 솔루션이 무엇인지는 분명히 파악하되, 기존 시스템을 점진적으로 개선하는 데 집중하자. 재작성 프로젝트가 제안되면 경계해야 한다. 현재 시스템을 더 잘 이해하고, 철저히 문서화하며, 변경에 대한 팀의 자신감을 높일 수 있도록 자동화된 테스트를 만들자.

물론 때로는 대규모 교체가 불가피하고 정당화될 때도 있다. 하지만 작업 범위를 정할 때는 신중해야 한다. 구현 단계 그 너머의 모든 것, 즉 마이그레이션 지원, 제대로 된 검증, 문서화, 그리고 다른 팀이 전환을 우선순위에 두도록 설득하는 일까지 고려해야 한다. 탄탄한 계획 없이 재작성에 뛰어들지 말자. 점진적인 개선이 나중의 불필요한 골칫거리를 막아줄 수도 있다!

지식 사일로가 되기

다른 팀이 플랫폼을 사용하며 겪는 일상적인 문제로부터 단절된 사일로가 되기도 매우 쉽다. 팀을 정의하면 공통의 목표를 가진 그룹이 모이게 되지만, 동시에 우리와 그들 사이에 선을 긋게 되어 갈등을 낳을 수도 있다.

사람들과 계속 대화하고 다가가서 그들의 문제를 듣는 것이 중요하다. 엔지니어들은 막히는 것을 원하지 않으며, 관계를 쌓아 두지 않았다면 당신의 솔루션에 문제가 있어도 이야기하기보다 우회 방법을 찾기 일쑤다.

관계를 만드는 일은 매우 중요하다. 열린 소통을 장려하고 다른 사람들이 쉽게 다가올 수 있게 하자. 효과적인 방법 중 하나는 엔지니어 로테이션을 통해 플랫폼 지식을 공유하는 것이다. 팀원이 이동하면 이전 경험에서 얻은 신선한 관점과 귀중한 인사이트를 가져오게 된다.

조직 전반의 코드 기여를 환영함으로써 협업 문화를 조성하자. 사용자는 개선을 위한 독특한 관점과 귀중한 인풋을 제공할 수 있다. 플랫폼 팀이 솔루션을 책임지고 있을지라도, 조직 전체의 엔지니어들은 충분히 그 성장에 기여할 역량을 갖추고 있음을 기억하자.

결국 협업과 열린 대화가 더 강하고 효과적인 플랫폼 팀을 만든다. 지속적인 개선을 위해 공유된 지식과 관점의 힘을 받아들이자.

결론

플랫폼 팀을 도입하는 것은 공유 솔루션에 대한 명확한 오너십을 확립하는 좋은 방법이지만, 그만의 독특한 도전 과제들도 함께 따른다.

성공하려면 플랫폼을 내부 프로덕트처럼 다루는 것이 중요하다. 프로덕트 오너 역할을 맡을 적임자를 찾는 것은 원활한 운영을 위해 필수적이다. 다른 팀과 협업하여 엔지니어들이 진심으로 쓰고 싶어 하는 플랫폼을 만들자.

구현 자체만큼이나, 어쩌면 그보다 더 중요한 것이 문서화임을 기억하자. API 설계를 올바르게 하는 것을 우선순위에 두고 신속하게 구현한 뒤, 상세하고 포괄적인 문서를 만드는 데 집중하자.