* 이 글은 Wanted Con. Product & Strategy 영상을 보고 내용을 정리한 글입니다. 보다 자세한 내용은 원티드콘 영상을 참조하세요.
개발자로서 기업의 업무 프로세스나 개발 문화에 대하여 관심이 많은 편입니다. 원티드에서 다양한 온라인 컨퍼런스를 활발히 진행중인데, 시청해보고 실질적인 경험을 바탕으로 많은 정보나 인사이트를 얻을 수 있었습니다. 그중에서, 뱅크샐러드의 PO 조직 도입기에 대한 부분을 정리해 봤습니다.
#0. PO 조직 도입 이전
스타트업으로서 리소스 부족 대비 빠르게 시장의 요구사항을 충족하고자 게릴라 방식 (분기별 TF 조직) 으로 운영 되었습니다. 그로 인해 제품에 대한 오너십 부재 + 제품 전체의 일관성 부족으로 비효율이 적체됨에 따라 스케일업이 어려운 문제에 부딫혔습니다.
이에 따라 제품 조직이 최대한의 출력을 낼 수 있는 환경에 대한 고민의 결과로 PO중심의 전사적 조직 구조 개편 및 제도 도입, 인프라 구축 작업이 시작되었습니다. 이를 통해 달성하고자 하는 가치는 아래와 같습니다.
- 고객 중심
- 명확한 boundary가 있는 오너십
- 자율성
- 회사 방향과의 alignment
- 파편화 문제 해결
- 실행 기반의 빠른 학습 사이클
#1. 전사적 조직 개편 : 고객을 중심으로 3-layer 조직으로 조직 개편
이전에는 5개의 TF 로 구성되어있던 조직을 3-layer 의 조직 구성으로 변경되었습니다. 각 레이어는 Squard, Foundation, Division 으로, 성과는 고객으로부터의 평가이며 제품, 고객, 역할을 레이어 별로 정리되었습니다. 각 레이어의 고객을 정의한 것이 인상 깊었습니다.
그리고 이 조직구성이 잘 운용되기 위하여 OKR을 통한 Vision Alignment / Data driven culture 가 수반되어야 한다고 이야기 하고 있습니다.
- Squard > 고객 = 유저
고객과의 최접점에서 제품을 만들어가는 조직으로, 4~7명의 다양한 직무로 구성, 자율적으로 팀 운영 및 새롭게 팀원을 채용도 할 수 있습니다. 단, 인원을 추가 채용한다는 것은 그만큼 비용이 지출되기 때문에 지출 코스트 대비 임팩트 정도 또한 PO가 따져서 운영해야 한다고 말합니다. 그만큼 자유와 권한을 주어져있으며, 그 비용에 대한 고민도 스쿼드의 몫이므로 생각보다 스쿼드 운영이 어렵다고 합니다.- Foundation > 고객 = 스쿼드
각 스쿼드가 더 빨리 실험하고 학습할 수 있도록 지원하는 조직으로, 개별 스쿼드의 boundary 를 넘어서는 케이스 - 전사적 인프라에 영향이 가거나 정책 결정 등 - 에는 직접 개발에도 참여하는 조직입니다. Engineering, Product, Data, CX Foundation 등으로 구성되어 각 파운데이션의 역할을 수행합니다.#2. 데이터 기반 의사결정 기반 구축
서로 설득하고, 설득되면서 더 나은 방향으로 갈 수 있는 challenge 문화는 결국 더 옳은 방향으로 갈 확률이 크고, 조직 성장에 맞다고 판단하고 있습니다. Data Driven Culture 가 가능하면 사용자에게 빠르게 가치 전달이 가능하다고 이야기 합니다.
- 더 빠른 설득 + 더 빠른 합의점 + 더 빠른 실행 = 더 빠른 유저 임팩트
Data Foundation 에서는 이를 위하여 커뮤니케이션 시 사용되는 공통 용어 정리, Query Tool (정보 투명 공개), 자체 실험 플랫폼 구축, 활발한 내부 데이터 활용 교육 등을 수행하고 있다고 합니다.
#3. 제품의 일관성을 지켜갈 수 있는 인프라 구축
UI 파편화로 인해 서비스 경험 일관성이 지켜지지 않는 이슈로 인해, Product / Engineering Foundation 에서 BPL 도입 사례를 소개하고 있습니다. (Banksalad Product Language — 디자인 시스템과 유사하다고 이해했습니다.)
이를 통해 아래와 같은 도입 효과를 가져갈 수 있었다고 합니다.
- 개발자 — 뷰 구현에 우선순위를 두지 않고, 로직에만 좀 더 집중해서 고민
- 디자이너 — 제품의 룩앤필을 일관되기 지키고 UX 에 더 집중할 수 있게 됨
- PO — 빠르게 프로토타이핑 및 실험할 수 있음
Note) BPL과 관련된 이야기는 뱅크샐러드 블로그 > BPL iOS 도입기 포스트에서 자세히 이야기 하고 있습니다.
#4. 제품 개발 프로세스 정리
문서화는 여러 사람들의 피드백을 모으고 합의에 이르기 위한 좋은 도구라고 이야기 합니다. 합의된 최종 결과물의 전파, 개선 등에 활용한다고 합니다.
PO는 역할에 있어 모호성이 있습니다. 문서화는 그 역할과 기대수준을 명확하게 정의하며, 문서를 템플릿화하여 PO와 일하는 협업자들이 업무에 익숙해지는 것이 아니라 업무 순환이 가능해 질 수 있게 만들었습니다. 문서화는 그냥 꼭 지켜져야 하는 것들 이라고 이야기 합니다.
#5 요약
회사 마다 가장 좋은 방식은 모두 다를 것이고, 결국 중요한 것은 사람입니다. 그런데 시스템도 중요하다는 것으로 마무리 됩니다.
아직 PO 역할이 생소하고, PO 조직을 도입한지 얼마 안되는 업무 프로세스에 계신 분들이나 제품의 개발 속도와 의사결정과정을 모두 잡기 위한 고민을 하는 분들께 꼭 추천드리고 싶습니다.
