사이드 프로젝트를 프로덕트처럼 운영하는 PM의 실험 습관

사이드 프로젝트를 프로덕트처럼 운영하는 PM의 실험 습관

프로덕트를 만들다 보면 이런 순간이 옵니다. “이 기능, 정말 사용자가 원하는 걸까?” 확신이 없지만 일정은 정해져 있고, 스테이크홀더의 기대는 높습니다. 가설을 세우고 검증하는 과정이 중요하다는 건 모든 PM이 알고 있지만, 현실에서 그 근육을 단련할 기회는 의외로 드뭅니다. 이미 정해진 로드맵, 제한된 실험 예산, 복잡한 이해관계 — 회사의 프로덕트에서 마음껏 실험하기란 쉽지 않습니다.

그래서 오늘은 조금 다른 관점을 제안해보려 합니다. 사이드 프로젝트를 단순한 ‘취미’가 아니라, PM으로서의 실험 역량을 키우는 프로덕트 실험실로 운영하는 방법에 대해서요.

왜 사이드 프로젝트인가 — 의도적 연습의 관점

K. 안데르스 에릭슨이 1993년 Psychological Review에 발표한 의도적 연습 이론은 흥미로운 통찰을 제공합니다. 전문성은 단순한 경험의 축적이 아니라, 구조화된 연습과 즉각적인 피드백 루프를 통해 형성된다는 것입니다. 10년차 PM이 1년차보다 반드시 더 나은 의사결정을 하지는 않습니다. 핵심은 경력의 길이가 아니라, 그 시간 동안 얼마나 의도적으로 자신의 판단을 검증해왔느냐에 있습니다.

문제는 회사의 프로덕트에서는 이런 의도적 연습이 구조적으로 어렵다는 점입니다. 실험 주기가 길고, 변수가 많고, 실패의 비용이 큽니다. 반면 사이드 프로젝트는 다릅니다. 빠른 피드백, 낮은 실패 비용, 온전한 의사결정권 — 의도적 연습의 조건이 자연스럽게 갖춰집니다.

존 듀이는 『경험과 교육』(1938)에서 “교육은 삶 자체이지, 삶을 위한 준비가 아니다”라고 했습니다. 사이드 프로젝트에 프로덕트 사고를 적용하는 것은 ‘언젠가 쓸 스킬을 미리 연습하는 것’이 아닙니다. 그 자체가 이미 프로덕트를 만드는 행위이고, 그 과정에서 얻는 배움은 어떤 강의보다 깊습니다.

프레임워크: 사이드 프로젝트에 적용하는 프로덕트 디스커버리

테레사 토레스는 Continuous Discovery Habits(2021)에서 기회 솔루션 트리(Opportunity Solution Tree)라는 프레임워크를 제안합니다. 비즈니스 성과 → 기회 → 솔루션 → 실험이라는 네 단계로 사고를 구조화하는 방법인데요. 이것을 사이드 프로젝트에 적용하면 어떻게 될까요?

관점을 바꿔보겠습니다. 대부분의 PM이 사이드 프로젝트를 시작할 때 “이런 기능을 만들어보고 싶다”에서 출발합니다. 하지만 토레스의 프레임워크를 적용하면, 출발점이 달라집니다.

일반적 접근프로덕트 사고 접근
”이런 앱을 만들어볼까""이 사용자의 어떤 문제를 해결할까”
기능 목록 작성기회 공간 탐색
바로 개발 착수가장 위험한 가정 식별
완성 후 공개가정 검증 실험 먼저

에릭 리스가 『린 스타트업』(2011)에서 강조한 것도 같은 맥락입니다. “모든 프로젝트는 하나의 거대한 실험이다. ‘이것을 만들 수 있는가’가 아니라 ‘이것을 만들어야 하는가’를 묻는 실험.” 사이드 프로젝트야말로 이 질문을 가장 순수하게 던질 수 있는 공간입니다.

구체적으로, 사이드 프로젝트에서 실천할 수 있는 디스커버리 습관은 세 가지입니다.

첫째, 주 1회 사용자 접점을 만드세요. 토레스가 강조하는 ‘주간 고객 터치포인트’를 사이드 프로젝트에서 실험해보는 겁니다. 5명의 지인에게 프로토타입을 보여주고 반응을 관찰하는 것만으로도 충분합니다.

둘째, 가정 맵을 먼저 그리세요. “이 프로젝트가 성공하려면 무엇이 사실이어야 하는가”를 목록으로 만들고, 가장 위험한 가정부터 검증합니다. 코드 한 줄 없이도 검증할 수 있는 가정이 놀랍도록 많습니다.

셋째, 학습 목표를 정의하세요. “이번 주에 무엇을 만들까”가 아니라 “이번 주에 무엇을 알아낼까”를 기준으로 스프린트를 설계합니다.

실험실에서 배운 것들 — 현장의 이야기

몇 년 전, 개인적으로 소규모 교육 서비스를 기획하고 운영해본 경험이 있습니다. 처음에는 단순히 “이런 서비스가 있으면 좋겠다”는 생각에서 출발했는데, 의식적으로 프로덕트 디스커버리 프로세스를 적용해보기로 했습니다. 학습 커리큘럼 설계, 사용자 인터페이스, 콘텐츠 관리 기능을 하나씩 설계하면서, 매주 실제 사용자 5명과 짧은 인터뷰를 진행했습니다. 약 2개월 만에 4천 명의 사용자가 모였는데, 돌이켜보면 그 성장의 원동력은 기능의 완성도가 아니라 매주 갱신되는 가설 목록이었습니다.

또 다른 경험이 있습니다. B2B2C 플랫폼의 피드 사용성을 개선하는 프로젝트에서, 100여 개 기관의 이용 데이터를 분석하고 20명의 이탈 사용자를 직접 인터뷰한 적이 있습니다. 이 프로젝트에서 가장 값진 배움은, 이탈의 원인이 기능 부재가 아니라 기존 기능의 발견 불가능성에 있었다는 점이었습니다. 이런 종류의 인사이트는 데스크 리서치로는 절대 나오지 않습니다. 사용자를 직접 만나야만 보이는 것들이 있고, 사이드 프로젝트는 그 연습을 가장 안전하게 할 수 있는 공간입니다.

마티 케이건은 최고의 프로덕트 팀이 주당 15건 이상의 실험을 수행한다고 말합니다(Empowered, 2020). 회사에서 이 수준의 실험 빈도를 확보하기 어렵다면, 사이드 프로젝트가 그 간극을 메워줄 수 있습니다.

PM을 위한 실험 습관 설계

도널드 쇤은 『성찰적 실천가』(1983)에서 행위 중 성찰(reflection-in-action)이라는 개념을 제안합니다. 전문가는 행동하면서 동시에 사고하고, 그 과정에서 즉석 실험을 수행하며, 새로운 이해를 만들어낸다는 것입니다. 이것은 PM이 사이드 프로젝트에서 길러야 할 핵심 역량과 정확히 겹칩니다.

캐롤 드웩의 성장 마인드셋 연구(2006)도 같은 방향을 가리킵니다. 실패를 두려워하지 않는 아이들은 “자신이 배우고 있다고 생각할 뿐”이었다는 그녀의 발견은, 사이드 프로젝트의 가장 큰 이점을 설명합니다. 실패해도 됩니다. 아니, 실패해야 합니다. 그것이 학습이니까요.

사이드 프로젝트를 프로덕트 실험실로 운영하기 위한 실무적 체크리스트를 정리하면 다음과 같습니다.

결론

결국 좋은 PM의 역량은 ‘무엇을 아는가’가 아니라 ‘얼마나 빠르게 배우는가’에 있다고 생각합니다. 사이드 프로젝트는 그 학습 속도를 극적으로 높여주는 안전한 실험실입니다. Gmail, Slack, Trello 같은 서비스들이 모두 사이드 프로젝트에서 시작되었다는 사실은 우연이 아닙니다. 누군가의 ‘작은 실험’이 세상을 바꾸는 프로덕트가 된 것입니다.

여러분의 사이드 프로젝트에 작은 실험 하나를 추가해보시는 건 어떨까요? “이번 주에 무엇을 알아낼까”라는 질문 하나만으로도, 그 프로젝트는 전혀 다른 의미를 갖게 됩니다.


참고 자료

포트폴리오, 막막하신가요? 커리어노트가 함께 만들어 드립니다

커리어노트 무료로 시작하기

관련 글