[PGF 1기-김장호] 인스파이어드 사전 과제
작성자
- 김장호김
과제
제출
모임
참석
아젠다
1.
PO/PM의 R&R
: 현재 자신이 속한 조직에서 부여된 PO/PM의 역할과 책임을(R&R) 설명해 주세요. 그리고 인스파이어드에서 정의한 이상적인 PO/PM의 R&R과는 어떤 차이가 있나요? 이 차이가 발생하는 원인이 무엇 때문이라 생각하는지 의견을 남겨주세요
→ 의견:
저는 게임 개발 회사에 재직 중이지만, 게임 개발 조직이 아닌 사내 프로젝트 관리 도구를 만드는 인터널 제품팀에 속해 있습니다. 사내 프로필 상 제 직무명은 'Service Design'이고 주요 업무 및 활동으로는 사용자 조사 및 분석, 경쟁사 분석, UI/UX 설계, 상세 기획, 서비스 관리 등이 있습니다.
사실 저는 아직까지도 프로덕트 매니저(PM), 프로덕트 오너(PO)와 같은 직무명이 실무에서 정확히 어떻게 구분되는지 명확하게 체감하지는 못하고 있습니다. 아마 제가 속한 조직(= 회사)의 구조와 관련이 있는 것 같은데요. 저희 회사에서 PM은 게임 개발 프로젝트에서의 '프로젝트 매니저'를 의미하고, 보통 게임 개발 프로젝트 매니저는 제품의 방향이나 문제 정의보다는 게임 개발 일정 관리 및 리소스 관리에 초점이 맞춰져 있습니다.
그리고 회사 내에 프로덕트 오너(PO)라는 직무는 존재하지 않고, 프로그램/아트/사운드/프로듀싱 등 게임 개발을 총괄하는 프로듀서(PD)가 있습니다. 이러한 환경 속에서 우리가 흔히 이야기하는 소프트웨어 개발 조직의 '프로덕트 매니저'라는 역할을 수행하고 있는 케이스는 많지 않은 것 같습니다.
그래서 저는 직무명보다는 제가 실제로 하고 있는 일을 기준으로 제 역할을 이야기해보려합니다.
현재 저희 팀은 사내 프로젝트 관리 도구를 만들고 있으며, 기존의 레거시 툴에서 신규 툴 로 사용자를 마이그레이션하는 프로젝트를 진행 중입니다. 저는 레거시 툴에서 노후화된 기술 스택으로 인해 그동안 구현하지 못했던 기능 개선 사항들을 정리하고 기획하며, 마이그레이션 일정을 조율하는 역할을 맡고 있습니다.
동시에 유저 피드백을 대응하며 서비스 운영을 챙기고, 필수 기능과 신규 아이디어 사이에서 우선순위를 조정하고, 기능 명세서를 작성하며 배포 일정을 관리하는 등 제품 관리 전반을 담당하고 있습니다.
이런 구조 속에서 저는 '우리 제품이 사용자에게 어떤 본질적인 가치를 줄 수 있을까'를 고민하기보다는, 당장의 구현 일정과 리소스 제약을 계산하는데 하루 일과의 대부분을 쓰고 있습니다. "기존 레거시 툴의 이 기능은 얼마나 쓰이고 있지?", "우리팀 개발자 4명의 리소스로 이번 달 안에 어디까지 가능할까?" 같은 질문에 스스로 답하며 기능을 쳐내고 조정하다 보면, 어느 순간 저는 문제를 정의하는 사람이라기보다 주어진 조건 안에서 최대한 효율적으로 작업을 실행하는 오퍼레이터가 된 것 같은 기분이 들 때가 많습니다.
인스파이어드를 읽으며 제가 다시 떠올리게 된 이상적인 프로덕트 매니저의 모습은 이렇습니다. 누군가의 요구사항을 받아 정리하고 전달하는 데 그치거나, 반복되는 스프린트 속에서 백로그를 구성하고 진행 현황을 관리하는 역할이 아닌, 이 제품이 사용자에게 줄 수 있는 본질적인 가치를 지속적으로 고민하며 팀 안에서 한발 더 앞서서 목소리를 내는 사람이라고 생각했습니다. 그리고 나아가 그 고민을 통해 제품의 비전과 방향을 조금씩 빚어내는 역할이라고 느꼈습니다.
또한 팀 운영 측면에서도, 기획자/디자이너/개발자 등 팀 구성원이 각자의 직무에 갇힌 구조가 아니라, 모두가 하나의 빌더(Builder)로서 문제 해결에 참여하는 팀을 이끄는 사람이 이상적인 PO/PM의 모습에 가깝다고 생각이 들었습니다.
하지만 현실은 이 이상적인 그림을 그대로 도입하기 쉽지 않은 부분이 많은 것 같습니다.
회사에는 분명한 직급과 권한 체계가 있고, 연간/분기/주간 단위의 계획과 보고가 반복됩니다. 이 과정에서 장기적인 비전이나 문제의 본질을 설득 하기보다는, 당장의 요구사항을 빠르게 반영해 가시적인 성과로 증명하는 일이 팀 운영에 더 유리하게 여겨지는 것이 어느 정도 자리 잡고 있다고 느끼고 있습니다.
팀의 일하는 방식 역시 마찬가지입니다. 이미 '요구사항 수집 - 기획 - 디자인 - 개발'이라는 흐름에 익숙해진 상황에서, "이제 유저 스토리 중심으로, 자율적으로 일해봅시다"라고 제안하는 것은 이상적으로는 맞는 말일지 몰라도, 현실적으로는 당장의 팀 생산성을 떨어뜨리는 무책임한 제안처럼 느껴지기도 합니다. 나아가 프로덕트 매니저에게 그런 결정 권한이 없다면 더욱더 이러한 방식을 도입하기는 어려운 부분이 많습니다.
결국 이런 구조적인 문제는 개인의 의지만으로 해결하기 어렵고, 흔히 말하는 팀장이나 실장급의 조직 리더의 방향성이 중요한 것 같습니다. 다만, 그 리더 역시 조직 안에서 역할과 책임을 지고 있는 한, 기존의 조직 관성에서 완전히 자유롭기는 쉽지 않다는 점도 이해가 됩니다.
그럼에도 불구하고 인스파이어드를 읽으며 제가 느낀 것은, 지금 당장 조직을 바꿀 수는 없더라도 최소한 제 개인이 스스로 통제할 수 있는 영역에서는 여러 선택을 해볼 수 있지 않을까하는 생각이 들었습니다.
기능을 정의할 때 "이 기능이 해결하려는 사용자의 문제는 무엇인가?"를 한 번 더 묻고, 스펙 문서 안에라도 그 맥락을 남기는 시도를 해봐야겠다는 생각이 들었습니다.
제품 비전이라는 거창한 느낌은 아니더라도, 작은 문제 정의부터 놓치지 않고 사소한 영역에서라도 본질적인 의미를 계속해서 찾으려는 시도들 그 자체가 가시적인 성과와는 별개로 지금 제 자리에서 할 수 있는 의미 있는 시도가 아닐까하는 생각이 듭니다.
2.
PMF 검증을 위한 MVP
: 진행했던 프로젝트 중 아이디어 검증 과정을 통해 PMF를 목표로 MVP를 정의해 구축 출시 후 단계별로 제품을 성장시켜 본 적이 있다면 그 과정과 결과를 공유해 주세요. 만약 PMF와 MVP를 적용해 본 적이 없다면, 어떻게 아이디어를 검증하고, 출시 스펙을 결정했는지, 그리고 그 결과는 어떠했는지 공유해 주세요.
→ 의견:
사내 제품을 만드는 입장에서 제가 정의한 PMF(Product Market Fit)는 비교적 명확했습니다.
사내 동료들이 기존 레거시 툴에서 우리 팀이 만들고 있는 신규 툴로 옮겨왔을 때, 기존의 워크플로우를 막힘없이 유지하면서도 최신 기술 스택을 기반으로 한 새로운 편의 기능을 자연스럽게 누릴 수 있는 상태를 만드는 것이었습니다.
이를 위해서 저는 초기 방향을 세 가지로 설정했습니다.
•
첫째, 반드시 필요한 필수 기능은 유지하고
•
둘째, 실제로 거의 사용되지 않았던 불필요한 기능은 과감히 제거하며
•
셋째, 사용자의 자발적인 마이그레이션을 유도할 수 있는 추가적인 개선 기능을 제공하는 것이었습니다.
이 방향을 검증하기 위한 첫 단계로, 저는 각 게임 개발 조직의 PM(Project Manager)들을 직접 찾아다니며 마이그레이션 사전 인터뷰를 진행했습니다. 현재 어떤 방식으로 일하고 있는지, 기존 레거시 툴에서 주로 사용하는 기능은 무엇인지, 그리고 평소 업무 과정에서 느끼는 불편함은 있었는지 하나씩 질문하고 정리했습니다.
주로 PM(Project Manager)을 찾아다니며 인터뷰를 진행했던 이유는 보통 프로젝트 관리 도구의 도입과 활용 여부를 각 팀의 PM이 결정하는 구조였기 때문도 있었고, 당시에는 입사 초기라 사내 인맥이나 소통 채널이 거의 없던 상황에서 좀 무식하지만(?) 직접 찾아가서 이야기하는게 제가 선택할 수 있는 가장 확실한 방법이었던 것 같습니다.
이렇게 수집한 정보를 바탕으로, 저는 기존 레거시 툴을 사용하는 조직을 세 가지 레벨로 구분했습니다.
•
레벨 1: 필수 기능만으로도 즉시 이전이 가능한 조직
•
레벨 2: 보다 고도화된 기능이 필요한 조직
•
레벨 3: 툴 마이그레이션이 회사 매출이나 라이브 서비스에 직접적인 영향을 줄 수 있는 민감한 조직(라이브 게임 부서)
MVP는 우선 레벨 1 조직이 문제없이 이전할 수 있는 수준을 기준으로 정의했고, 이후 단계적으로 레벨 2와 3까지 확장하는 것을 목표로 삼았습니다.
현재까지의 결과를 보면, 10~20명 규모의 공통 조직에 해당하는 레벨 1은 비교적 순조롭게 이전을 완료했습니다. 반면, 50명에서 많게는 400명에 이르는 게임 개발 조직인 레벨 2와 3은 여러 차례 접촉을 시도했음에도 상당히 보수적인 반응인 상태입니다. 실무에 필요하다고 판단한 기능들을 지속적으로 반영해왔다고 생각했지만, 마이그레이션에 대한 결정을 이끌어내기에는 여전히 부족한 부분들이 많은 것 같습니다.
위와 같은 과정과 그에 따른 현재 결과를 통해서 제가 느낀 부분은 우선 조직 규모가 클수록 프로젝트 관리자가 사용하는 기능과 실제 실무자가 사용하는 기능 사이의 간극이 컸다는 점입니다. 미팅이나 인터뷰에서는 쉽게 드러나지 않는 숨은 요구사항이 매우 많다는 점을 체감했습니다.
하지만 모든 구성원을 대상으로 미팅을 진행하는 것도 현실적으로 어렵고, 설문 조사 역시 실무자 참여도가 높지 않아서 "무엇이 필요한지 알고 싶지만, 말을 들을 수 없는" 상황이었기 때문에 어떻게 이 문제를 해결해야 할까는 아직까지도 여전히 고민으로 남아있는 부분입니다.
무엇보다 정말 가장 큰 장벽은 심리적인 저항감이었습니다. 매일같이 접속해서 이미 손에 익은 툴을 굳이 바꿔야 할 이유에 대해 충분히 설득하지 못했고, 기존 레거시툴 대비 우리 신규 툴이 주는 가치가 그들의 익숙함을 포기할 만큼 크다고 느끼게 만들지 못했던 것 같습니다.
특히 매주 업데이트가 이루어지는 라이브 게임 프로젝트 팀에게는 단기간 내 완전한 툴 이전 자체가 지나치게 큰 리스크인 부분도 있었습니다. 이 케이스에서는 단순히 기능을 더 잘 만드는 것, 더 많은 기능을 제공하는 것만으로는 해결할 수 없는 한계가 있다는 느낌을 받았습니다.
무엇보다 이 과정을 다시 처음으로 되돌린다고 해도, "이렇게 하면 된다"라고 명확하게 말할 수 있는 해답이 떠오르지는 않는게 조금 답답한 것 같습니다. 이미 일부 조직은 신규 툴로 마이그레이션이 완료된 상태라 다시 레거시 도구로 되돌리는 것도 현실적인 선택지는 아니고, 그렇다고 남은 모든 조직이 자연스럽게 넘어오도록 만들 수 있는 뚜렷한 방법이 있는지도 잘 모르겠습니다. 그만큼 지금은 되돌릴 수도, 밀어붙일 수도 없는 애매한 지점에 서 있다는 느낌을 자주 받습니다.
그럼에도 불구하고 지난주 함께 일하는 동료가 "달리는 마차에서 바퀴를 갈아 끼우는 일은 원래 쉽지 않다"는 말을 해주었습니다. 조금씩이지만 실제로 이전을 완료한 조직이 생기고 있고, 그 자체로 이미 충분히 잘하고 있다는 이야기를 들으며 마음을 다잡아 보고 있습니다.
결과적으로 지금 제가 할 수 있는 일은 단기간에 모든 조직을 설득하려 애쓰기보다는, 묵묵히 기능을 개선하고 무엇이 필요할지를 계속 고민하며, 다시 미팅을 다니고 의견을 듣는 과정을 반복하는 것 같습니다. 그렇게 시간이 쌓이다 보면 언젠가는 지금보다 더 나아진 서비스의 가치를 느끼고, 실무 조직에서 먼저 전환을 결심하는 순간이 오지 않을까 기대해봅니다.
3.
프로덕트 구축/개선 프로세스
: 현재 조직의 프로덕트를 구축/개선하는 과정과 인스파이어드에서 소개하는 이상적인 과정과 어떤 차이가 있나요? 애자일 방법론을 경험해 보신적이 있다면 어떤 장점과 단점이 있었는지 공유해 주세요.
+(옵션) 회사의 제품 구축 프로세스와 체계를 구축하는 시점은 언제부터 필요할까요?
→ 의견:
인스파이어드에서는 제품이나 기능을 개발하는 과정에서 무엇을 만들 것인가보다 먼저, 해결해야 할 문제를 발견하고 검증하는 Product Discovery 과정을 특히 강조했습니다. 그 문제가 정말 중요한지, 우리가 제안하는 해결책이 효과적인지에 대해 제품팀이 함께 실험하고 학습하는 과정이 핵심이라고 했습니다. 특히 가치 검증을 위한 다양한 프로토타입과 빠른 학습의 중요성을 강조한 부분도 기억에 남습니다.
반면 저희 팀에서는 요구사항이 어느 정도 정리되면, 그 범위 안에서 빠르게 구현하고 배포하는 데 초점이 맞춰지는 경우가 많은 편입니다. 사내 제품이라는 특성상, 게임 개발 조직의 업무 효율 개선을 위해 "A 기능이 필요하다"는 이야기가 나오면, 그 자체로 문제 정의를 어느 정도 마무리하고 별도의 검증 과정 없이 바로 기능 개발로 이어지는 경우도 적지 않습니다.
이 지점이 인스파이어드에서 이야기하는 이상적인 프로덕트 개발 과정과 저희 팀의 현재 방식 사이에서 느낀 가장 큰 차이였습니다. 문제 발견과 검증이 독립적인 단계로 충분히 다뤄지기보다는, 기능 개발 과정에 자연스럽게 흡수되거나 생략되는 구조에 가깝다고 느꼈습니다.
이런 차이가 생기는 이유를 생각해보면, 사내 제품이라는 특성이 많은 부분 작용하는 것 같았습니다. 저희 제품의 경우 성공 여부가 데이터 지표나 장기적인 사용자 가치보다는, 요청한 조직이 실제로 쓰고 만족하는지에 더 가깝게 평가되는 경우가 많습니다. 그리고 사내 프로덕트의 가장 큰 장점 자체가, 외부 소프트웨어보다 기능 요청 조직의 니즈에 맞는 기능을 빠르게 제공할 수 있다는 점도 있습니다.
그래서 "이 기능이 불편해요", "이게 있으면 좋겠어요" 같은 요청이 들어오면, 그 안에 있는 본질적인 문제를 깊게 파고들기보다는, 일단 표면적으로 드러난 요구사항을 빠르게 해결해주는 쪽으로 방향성이 설정되는 것 같습니다.
이러한 흐름에서 현재 저희 팀은 요구사항 수집 → 기획 → 디자인 → 개발 → QA → 배포의 흐름으로 프로덕트를 구축하고 개선하고 있으며, 2주 단위의 스프린트를 운영하고 있습니다. 운영 이슈나 사용자 요청을 중심으로 백로그를 정리하고, 이를 스프린트 단위의 개발 작업으로 쪼개어 진행하고 있습니다. 스크럼 미팅은 별도로 진행하지 않고, 주간 단위로 각자의 할 일을 공유하면서 필요할 때마다 수시로 조정하는 방식으로 운영하고 있습니다.
그리고 스프린트가 끝나면 리뷰 미팅을 통해 해당 기간 동안 진행한 작업을 정리하고 공유하고 있습니다. 형식만 놓고 보면 애자일 요소를 일부 적용하고 있지만, 실제 체감 상 짧은 주기로 반복되는 미니 워터폴 방식에 가까운 것 같습니다.
장점은 2주 단위의 스프린트를 통해 짧은 주기로 결과물을 확인할 수 있고, 실제 사용 가능한 산출물을 빠르게 만들어낼 수 있다는 점은 팀 운영 측면에서 큰 장점으로 느껴집니다. 팀원들 역시 현재 진행 상황이 비교적 가시적으로 공유되고, 일정한 리듬 속에서 일이 진행된다는 점을 긍정적으로 느끼고 있는 것 같습니다.
반면 단점은 앞서 이야기한 문제 정의와 관련된 구조적인 한계와 맞물려 있는 것 같습니다. 요구사항이 어느 정도 정리된 상태에서 바로 스프린트로 들어가다 보니, 우리가 풀고 있는 문제가 정말로 적절하게 정의된 문제인지 다시 한 번 돌아볼 여유가 점점 줄어드는 느낌을 받았습니다. 짧은 주기로 결과물을 만들어야 한다는 리듬 속에서, 자연스럽게 "사용자가 느낀 문제를 더 면밀히 살펴볼까?"보다는 "일단 만들고 보자"는 선택이 반복되는 구조가 만들어지는 것 같습니다.
인스파이어드를 읽으면서, 지금의 방식이 틀렸다고 느끼기보다는 우리 팀이 왜 이런 방식으로 일하고 있는지를 다시 한 번 돌아볼 수 있었습니다.
우리 팀의 방식이 빠르게 만들어 제공하는 것이 강점인 것은 분명하지만, 그 안에서도 표면적으로 드러난 요구사항을 그대로 기능으로 옮기기보다는 이 요구가 왜 발생했는지부터 한 번 더 들여다보는 과정의 비중이 지금보다는 조금 더 필요하지 않을까 하는 생각이 들었습니다.
그래서 앞으로는 요청한 내용을 그대로 반영하는 것이 정말 최선의 해결책인지, 혹은 다른 방식으로 문제를 풀 수 있는 여지는 없는지 고민해보고, 그리고 이런 질문들을 혼자만의 생각으로 남기기보다는 팀 안에서도 함께 공유하며 이야기해볼 수 있는 흐름을 어떻게 만들어갈 수 있을지를 고민해보려 합니다.