안녕하세요, 에디터 요니입니다.

4월에 오리진 에디터가 IT 기획자에 관한 일의 일기(기획자: "수정 사항이 있는데요, 가능할까요?")를 발행했었죠. 근본적으로 서비스 기획자와 PO가 하는 일이 크게 다르지 않습니다. 다만 조직 구조와 일을 하는 방식에 차이가 있다고 이해해 보면 좋을 것 같습니다.

IT 기획에 관심이 있는 사람이라면 PO라는 직군 명칭은 낯설지 않으실 거예요. PO는 주로 자체 소프트웨어 서비스를 운영하는 IT 기업, 특히나 애자일 개발 방식을 따르는 조직에 존재하는 직무입니다.

애자일 방식은 기획부터 디자인, 테스트, 리뷰, 배포까지를 계속 반복하는 소프트웨어 개발 방법론이에요. 이 순환 구조를 만들기 위해 서비스의 기능을 잘게 쪼개어 전시, 검색, 프라이싱, 결제, 배송, 클레임 등 작은 단위로 나누고 이를 ‘프로덕트’라고 부릅니다. 각 프로덕트를 담당하는 사람이 바로 PO예요.

이 구조를 큰 조직에 맞게 구현한 것이 스쿼드(Squad)입니다. 스쿼드는 글로벌 음악 서비스 스포티파이가 고안한 애자일 조직 구조로, 그 백서는 많은 IT 기업에서 성경처럼 읽히기도 했습니다.

간단히 설명하자면 이렇습니다. 기획팀, 디자인팀, 개발팀으로 나뉘어 있는 기능 조직 안에서, 각 기능 담당자를 묶어 ‘프로덕트 스쿼드’로 그룹화하는 방식이에요. 이렇게 모인 그룹이 하나의 프로덕트를 함께 기획하고, 디자인하고, 테스트하고, 배포하는 사이클을 빠르게 돌리게 됩니다.

이 프로덕트가 어디로 가야 할지 방향타를 잡는 것이 PO인 저의 역할입니다. 기본적으로 사용자 데이터를 항상 들여다보고, 고객의 목소리와 유관 비즈니스 부서의 의견을 수집해 고객 니즈와 프로덕트의 방향성에 맞는 기획으로 녹여냅니다.

디자이너와 개발자가 스쿼드에 함께 소속되어 있기 때문에 어떤 개선이 필요한지에 따라 기획 초기 단계부터 디자이너 또는 개발자와 함께 논의를 시작하게 돼요. 사용성, 개발 안정성, 데이터의 정합성까지 기획 단계부터 검토가 필요하기 때문이에요. 게다가 스쿼드의 디자이너와 개발자도 저처럼 이 프로덕트에 기여하고 그 성과를 자신의 성과로 가져가는 사람들이기도 합니다. 그래서 PO는 프로덕트의 비전과 가야 할 길을 계속 설득해야 해요. 일방적으로 지시하는 것이 아니라, 함께 움직이게 만드는 것이 PO의 일인 거죠.

애자일 조직에서는 보통 2주를 하나의 단위인 '스프린트'로 부릅니다. 스프린트마다 어느 정도의 기능을 개발해 배포할지 계획하고 일정을 관리하며, 규모가 큰 과제는 프로젝트화해서 긴 호흡으로 운영하기도 해요. 우선순위와 리소스를 고려해 배포 사이클 전략을 정하는 것도 PO의 몫입니다.

서비스 기획, 기술 검토, 일정 관리가 분업화되어 있던 이전 회사와 달리, 지금은 담당 프로덕트의 성장과 성과에 관한 것이라면 뭐든 제가 챙기게 됩니다. 그게 달라진 일하는 방식의 핵심이에요.

1년 정도는 PO라는 새로운 역할에 적응하기만 하는 데도 정신없이 바빴습니다. 거기에 1년 더, 조직이 돌아가는 풀 사이클을 두 번 경험하고 보니 이런 조직 구조의 문제가 슬슬 눈에 보이기 시작했죠.

첫 번째, 수직적 의사결정 구조가 지속되는 것이 문제였습니다. 애자일 개발 방법론과 스쿼드 조직 구조는 도입되었지만 의사결정 방식은 여전히 기능 조직 중심이었습니다. 스쿼드에서 실무자끼리 아무리 합의가 되어도, 디자인 팀장이나 CTO가 실행 자체나 방법에 동의하지 않으면 앞으로 나아갈 수 없었어요. 프로덕트를 책임지는 오너라는 뜻의 PO임에도 불구하고 기능 조직 리더들의 눈치를 봐야 했던 것이죠. 그러다 보면 상위 의사결정권자에게 승인받기 위해서 보고 라인을 거치느라 속도가 느려지는 일이 생기기도 했어요. 그때마다 “대체 이게 무슨 애자일?”이라는 물음표가 머릿속에 둥둥 떠다녔습니다.

스쿼드 모델을 만든 스포티파이에서도 이 체제가 실패했다고 고백한 문서가 발표되었는데요(한국어 요약), 구체적인 실패 원인 중 하나가 바로 의사결정 구조였습니다. 기술팀 내부에서 이견이 생기면 PO가 모든 엔지니어와 일일이 협상하거나 여러 단계의 매니저에게 에스컬레이션해야 했다고 해요. 제가 겪었던 일과 거의 유사합니다. 적어도 저만 답답했던 것이 아니라는 사실에 위안이 되기도 했습니다.

이런 문제를 해결하기 위해 원래 Apple의 스티브 잡스가 고안하고, 토스가 자사 문화로 도입한 DRI(Directly Responsible Individual)라는 개념이 있습니다. 프로덕트의 의사결정에 책임을 지는 단 한 사람을 정하고, 그 사람의 결정에 모두가 따라야 한다는 원칙이에요. 토스에서는 CEO도 PO의 결정에 조언자 역할에 머무는 경우가 많다고 해요. DRI를 가진 사람의 판단이 그만큼 존중받는 문화인 거죠.

토스는 대표도 PO라고 주장하는 강력한 PO 중심의 조직이기 때문에 가능했겠지만, 다른 조직에도 이러한 방식을 적용할 수 있을지는 회의적으로 느껴지기는 합니다. 의사결정 문화가 전통적인 조직 구조에 기반해 있다면, 스쿼드라는 포장지만 바뀐 채 위계 구조는 그대로 답습하게 됩니다. 구성원 개개인이 책임을 온전히 가져가려는 문화가 먼저 자리 잡지 않는 한, 구조만으로는 한계가 있어 보입니다.

두 번째, 수많은 스쿼드 간의 경계를 넘나들기 어렵다는 것입니다. 앞서 설명했듯 PO는 잘게 쪼개진 프로덕트 단위를 담당합니다. 스쿼드가 각자의 성과를 만들어내야 하다 보니 자연스럽게 경계가 생기고, 내 영역 밖의 일은 우선순위에서 밀려나게 됩니다.

아무리 프로덕트를 잘 나눴다고 하더라도 각자의 프로젝트를 수행하는 과정에서 다른 프로덕트 영역에서의 동반 개선이 필요한 일이 항상 생겨납니다. 예를 들어 상품 가격 노출 정책이 바뀌면, 그 변경 사항은 장바구니와 주문서에도 함께 반영이 되어야 합니다. 그런데 각 영역을 담당하는 스쿼드가 다를 경우, 변경의 우선순위는 각 스쿼드의 미션과 일정에 따라 제각각이 됩니다. 스쿼드가 자기 미션에 집중할수록, 경계 밖의 일은 역설적으로 더 느려지는 거죠. 심지어 다른 스쿼드에서 이미 개발한 것을 비효율적으로 다시 개발하는 상황이 벌어지기도 합니다. 전체 서비스 관점의 효율을 오히려 저해하는 방향으로 흘러가는 거예요.

이러한 경험을 통해 저는 애자일과 스쿼드 체제의 시행착오를 있는 그대로 마주할 수 있게 되었습니다. 조직 구조에 더 좋거나 우월한 것이 있는 게 아니라, 각 회사의 특징과 산업, 상황에 맞는 구조가 각자 다르다는 것도요.

환상은 깨졌지만, 그럼에도 불구하고 저는 지금 조직에서 해보고 싶은 일이 많고, 해 볼 수 있는 일이 많다고 생각하고 있습니다. 그건 바로 AI가 우리의 일터에도 지대한 영향을 미치고 있기 때문이에요.

애자일과 스쿼드 방식에는 앞서 이야기한 여러 문제가 있습니다. 하지만 그 조직 구성 방식 덕분에 AI 시대에 맞는 업무 수행 방식을 빠르게 실험해 볼 수 있다는 것은 분명한 장점이에요. PO의 책임을 맡고 연차가 쌓이면서, 기획뿐 아니라 디자인, 개발, 데이터, 그로스까지 다양한 분야에서 성과를 내야 하는 상황이 됐습니다. 예전이라면 "나는 기획자니까 개발은 몰라도 돼"라고 말할 수 있었겠지만, 지금은 그렇지 않아요. AI의 도움을 받아 내가 잘 모르는 분야에도 ‘고객 이해와 프로덕트에 대한 뾰족한 비전'이라는 무기를 들고 빠르게 접근할 수 있게 됐거든요.

I자형, T자형에서 한 발 더 나아간 개념으로 X자형 인재가 있습니다. X자형은 전문성의 깊이(수직)와 인접 분야로의 넓이(수평)를 갖춘 T자형을 넘어서, 분야 간 인사이트를 종합하고 연결해 새로운 가치를 만드는 사람을 뜻해요. 여기서 핵심은 '연결'입니다. 단순히 여러 분야를 아는 게 아니라, 그 사이의 경계에서 새로운 것을 만들어내는 능력이요.

디자인 리더십 전문가 태시 윌콕스(Tash Willcocks)는 여기서 한 발 더 나아가, X자형의 네 번째 축으로 소프트 스킬과 자기인식을 꼽기도 했습니다. 기술적 깊이나 넓이만큼이나, 공감·호기심·경청·협업 능력이 X자형을 완성하는 요소라는 거예요.

애자일 개발 방법을 기반으로 한 스쿼드 구조는 그 연습을 일상적으로 하게 만드는 환경입니다. 매일 디자이너, 개발자, 비즈니스 담당자와 함께 일하면서 서로의 언어를 배우고, 경계를 넘나드는 것이 자연스러워지는 곳이니까요.

실제로 저는 요즘 이런 일들을 하고 있어요. 에러 메세지가 슬랙 채널에 도착하면 Claude의 도움을 받아 에러 현황을 파악하고 개발자와 개선 방향을 논의합니다. 프로덕트 개선을 위해 디자이너와 함께 리서치를 계획하고 사용자를 직접 만나기도 하며, 대량 데이터 분석과 업계 레퍼런스 리서치에 AI를 적극 활용하고 있어요. 마케팅 관점에서 시도해 보고 싶은 것이 있다면 프로덕트에서 어떻게 시너지를 낼 수 있을지도 조언을 구해가며 실험합니다. 이 모든 경험이 PO에게 부여되는 오너십 덕분에 ‘선 넘는다’가 아닌 ‘제 역할을 한다’라고 인식될 수 있다는 것도 이 구조의 매력이에요.

물론 아직 AI 전환의 시작 단계에 있는 조직인지라 이 모든 일들을 해내기 위해서 새로운 데이터도 쌓아야 하고 컨텍스트도 새롭게 만들어 나가야 하는 일이 많습니다. 하지만 그 필요성을 느끼고 쌓아나가는 과정마저도 배움과 성장의 과정이라고 긍정 회로를 돌리고 있습니다.

어디선가 이런 말을 들은 적이 있어요. "경험은 환상을 제거하는 일이다." 애자일 조직으로의 이직은 저에게 딱 그런 과정이었습니다. 멋있어 보였던 말들의 실체를 직접 마주하고, 기대와 현실 사이의 간극을 직접 겪었죠. 환상이 사라진 자리에는 이런 구조를 만들고 운영하는 것이 왜 어려운지, 그럼에도 왜 필요한가에 대한 저만의 이해가 남았습니다.

이번 레터를 쓰면서 1년 전에 발행했던 레터를 다시 읽어보았는데요, 그때 제가 이런 말을 남겼더라고요.

요즘 가장 많이 하는 고민은, 기획을 잘하는 사람을 넘어서 질문을 잘 던지고 문제를 해결할 수 있는 사람으로 어떻게 성장할까 하는 거예요. 연차가 쌓이고 기대치가 높아지면서, 단순히 답을 찾는 것보다 새로운 해결책을 발견하고 실행에까지 옮기는 능력이 중요해지는 순간들이 오더라고요.

1년이 지난 지금, 그 질문에 대한 답이 조금씩 보이는 것 같아요. 사업 개발, 기능 개선, 마케팅, 운영까지 프로덕트를 여러 방면에서 키워야 하는 PO라는 역할은, 결국 질문을 잘 던지고 경계를 넘나드는 연습을 매일 하게 만드는 자리더라고요.

아직 해야 할 일이 훨씬 많은 PO이지만 주어진 환경에서 기회를 발견하고 레버리지를 일으킬 줄 아는 사람이 되려고 열심히 노력하고 있습니다. 함께 고민하는 모든 PO와 기획자 여러분을 응원합니다.