5명의 인원으로 12개의 앱을 운영하는 문서화되지 않은 플레이북

월요일 아침. 5명 규모의 스튜디오에서 12개의 프로덕트를 라이브 운영 중입니다. 3개는 언젠가 확인해야 할 크래시 알림을 쏟아내고 있습니다. 2개는 주말에 배포된 경쟁사 앱 업데이트로 인해 리텐션이 떨어지고 있습니다. 1개는 금요일까지 스토어 등록정보를 갱신하지 않으면 피처드 슬롯에서 밀려납니다. 47개의 고객 리뷰가 대기 중입니다. Game 4의 광고 지출은 어째서인지 30% 급증했습니다. Burak은 로드맵 회의 일정을 묻고 있습니다. 팀원 중 한 명은 Game 7에 대해 묻고 있습니다. 8분 뒤면 이번 주 업무가 시작됩니다.

이것이 바로 그 포트폴리오 운영현실입니다. 그 누구도 이를 위한 플레이북을 작성하지 않았습니다.

대부분의 운영 조언은 잘못된 형태를 전제로 쓰였습니다

기존 운영의 정석(도서, 스레드, LinkedIn 포스트 등)은 하나의 제품만 운영한다고 가정합니다. 그로스 리드를 채용하라. 퍼널 대시보드를 구축하라. 매주 프로덕트 위원회를 열어라. 북극성 지표를 정하라.

포트폴리오 비즈니스에 직면하는 순간, 이 중 어느 것도 살아남지 못합니다.

12개 제품을 운영하는 5인 스튜디오는 소규모 엔터프라이즈가 아닙니다. 스케일업 스타트업도 아닙니다. 완전히 다른 운영 형태입니다. 적은 인원, 많은 제품 수, 제품별로는 얕은 맥락, 교차 제품 간에는 풍부한 맥락. 인력 구조상 제품마다 그로스 리드를 둘 수 없습니다. 제품 수 구조상 제품마다 매주 프로덕트 위원회를 열 수도 없습니다. 기존 형태에 맞춰진 플레이북은 과부하가 걸려 무너집니다.

대부분의 스튜디오는 다섯 번째 제품 즈음에 이를 깨닫습니다. 처음 세 개는 감당할 만했습니다. 네 번째는 버거웠습니다. 다섯 번째에서 명확해집니다. 여기까지 오게 해 준 프레임워크로는 열 개까지 갈 수 없다는 사실을요.

이러한 형태는 아직 정립된 명칭이 없습니다. 어떤 운영자는 포트폴리오라고 부르고, 어떤 운영자는 지주회사(holdco)라고 부릅니다. 대부분은 그저 "이것저것 많이 운영한다"고 말합니다. 뭐라고 부르든, 운영 원칙은 그 자체로 독자적인 영역이며 (포트폴리오 운영), 기록할 여유가 없는 운영자들의 머릿속에만 존재하기에 대부분은 불문율로 남아 있습니다.

이 글은 이를 기록으로 남기기 위한 시도입니다. 구체적으로, 단일 제품 플레이북이 멀티 프로덕트 스튜디오에서 무너지는 5가지 지점과, 그 대신 취해야 할 방법을 다룹니다.

5가지 실패 패턴

1. 수동 모니터링이 월요일 아침을 집어삼킨다

첫 번째 실패는 발견하기는 가장 쉽지만 해결하기는 가장 어렵습니다. 매일 아침 팀원 누군가가 모든 제품을 일일이 확인합니다. 크래시 대시보드. 앱 스토어 리뷰. 지출 리포트. 인게이지먼트 패널. 고객 지원 인박스.

첫 번째 프로덕트에서는 창업자의 일이며 30분이면 끝납니다. 다섯 번째 프로덕트에서도 여전히 창업자의 일이지만 3시간이 걸립니다. 열두 번째 프로덕트에 이르면 더 이상 이루어지지 않으며, 스튜디오는 고객 티켓을 보고서야 진짜 문제가 터졌음을 알게 됩니다.

수동 포트폴리오 모니터링은 확장될 수 없습니다. 운영자의 능력이 부족해서가 아니라, 업무량이 제품 수에 비례해 선형적으로 증가하는데 운영자는 한 사람이기 때문입니다. 대시보드로 시간을 조금 벌 수는 있지만, 12개 제품의 알림 중 진짜 중요한 것이 무엇인지 가려내야 하는 문제를 대시보드만으로 해결할 수는 없습니다.

정작 필요한 작업은 바로 시그널 트리아지이며, 이는 운영자가 대시보드를 연 후가 아니라 열기 전에 이루어져야 합니다.

2. 제품 간에 학습한 교훈이 유실됩니다

여러 프로덕트를 운영한 지 3개월이 지나면 똑같은 뼈아픈 대화를 두 번 겪게 됩니다. 팀원 중 누군가가 Game 4의 문제를 제기하면, 오래 근무한 팀원이 "작년 3월에 App 2에서 그거 해결했잖아"라고 말합니다. 그리고는 아무도 실제 해결책이 무엇이었는지 기억하지 못한다는 사실을 깨닫게 됩니다.

단일 프로덕트 조직은 위키와 런북으로 이를 해결합니다. 포트폴리오 스튜디오는 그럴 수 없습니다. 관련 교훈이 다른 프로덕트의 맥락 속에 묻혀 있기 때문입니다. Game 4의 런북에는 없고, App 2의 런북에는 있지만 App 2 담당자만 그 런북을 읽습니다. 프로덕트 간을 넘나드는 기억은 그 누구의 머릿속에도 온전히 남아 있지 않습니다.

해결책은 더 방대한 위키가 아닙니다. 진정한 해결책은 조직의 기억(institutional memory) 프로덕트별로 구조화되어 있으면서도 프로덕트 전반에서 읽을 수 있어야 합니다. Game 4의 문제와 App 2의 해결책은 누군가 서식을 재가공하지 않아도 기본적으로 같은 형태, 같은 장소에 있어야 합니다.

3. 결정의 타이밍을 놓칩니다

모든 멀티 프로덕트 스튜디오는 동일한 백로그를 안고 있습니다. 바로 지난주 화요일에 내려졌어야 했지만 미뤄진 결정들입니다. 몇 주 전에 조정했어야 할 Game 4의 최소 입찰가, App 7의 스토어 등록정보 갱신, 아무도 분기(fork)해 둘 생각을 못 한 Game 11의 리텐션 테스트 같은 것들입니다.

스튜디오에 판단력이 부족한 것이 아닙니다. 판단할 '순간'이 부족한 것입니다. 맥락이 준비되어 있다면 10분이면 끝날 결정이 2시간의 사전 준비를 요구하기에 계속 미뤄집니다. 충분히 미뤄지다 보면 결국 흐지부지되고 맙니다.

필요한 것은 바로 의사결정 케이던스: 각 제품별로 특정 결정들이 이미 준비된 컨텍스트와 함께 예측 가능한 리듬에 맞춰 이루어지도록 보장하는 것입니다. 단순한 회의 일정이 아니라, 결정의 순간이 완벽히 준비된 상태로 찾아온다는 약속입니다.

4. 직능 간 컨텍스트가 파편화됩니다

소규모 스튜디오에서 "크로스펑셔널(cross-functional)"은 서로 다른 팀을 의미하지 않습니다. 동일한 3명의 인원이 각자 3개의 역할을 맡고 있음을 의미합니다. 광고를 집행하는 사람이 스토어 등록정보도 관리하고 라이브 운영(live-ops)도 맡습니다. 팀원 간의 싱크가 맞지 않는 게 아니라, 자기 자신과의 싱크가 어긋나 있는 것입니다.

문제는 운영 환경(operating surface)입니다. 광고 지출은 한 도구에, 스토어 등록정보는 다른 도구에, 라이브 운영 문서는 또 다른 도구에 존재합니다. 각 도구는 같은 날, 동일한 프로덕트에 대해 서로 다른 이야기를 합니다. 그것들이 같은 프로덕트라는 사실을 인지하고 있는 존재는 운영자뿐입니다.

교차 기능 컨텍스트 포트폴리오 스튜디오에서 중요한 것은 더 나은 미팅이 아닙니다. 한 사람이 세 가지 역할을 오가며 읽을 수 있는 프로덕트별 단일 기록입니다. "오늘 Game 4에 무슨 일이 일어나고 있지?"라는 질문에 대해, 세 가지 정보를 취합할 필요 없이 바로 읽을 수 있는 단 하나의 답변이 있어야 합니다.

5. 그로스 루프가 소리 없이 쇠퇴합니다

포트폴리오 운영에서 가장 큰 대가를 치르는 실패는 아무도 눈치채지 못하는 실패입니다. 그로스 루프를 배포해 2주 동안 잘 작동하다가 서서히 어긋납니다. 첫 번째 코호트 이후 분기하기로 했던 리텐션 테스트는 끝내 분기되지 않습니다. 3월에 튜닝했던 수익화 곡선은 6월이 되면 기본값으로 되돌아갑니다. 누구의 탓도 아니며, 잘못한 사람도 없습니다. 그저 루프가 유지 관리되지 않았을 뿐입니다.

단일 제품 운영에서는 창업자가 이를 기억합니다. 하지만 포트폴리오 운영에서는 창업자에게 기억해야 할 일이 11가지나 더 있습니다.

하나의 자율 실행 그로스 루프 은 시스템이 지속적으로 인지하고 있는 상태입니다. 루프가 약화되거나, 전제 조건이 바뀌거나, 분기가 필요할 때 이를 수면 위로 끌어올립니다. 결정은 여전히 운영자가 내립니다. 시스템은 결정해야 할 순간을 놓치지 않도록 보장합니다.

실제로 효과가 있는 방식

다섯 가지 실패 모드에 대한 해결책은 다섯 개의 개별 도구가 아닙니다. 서로 다른 영역에 적용된 동일한 근본적 전환입니다. 12개 이상의 프로덕트를 운영하며 살아남은 대부분의 멀티 프로덕트 스튜디오는 보통 뼈아픈 경험을 통해 이를 스스로 터득했습니다. 이를 요약하면 다음과 같습니다.

1. 단위는 회사가 아니라 제품입니다.

대부분의 운영 툴은 기본 설정이 회사 단위의 워크스페이스로 되어 있습니다. 하나의 지식 베이스, 하나의 채널, 하나의 대시보드 구조입니다. 멀티 제품 스튜디오에게 이는 잘못된 기본값입니다. 기억의 표준 단위는 반드시 제품이어야 합니다. Game 4는 자체적인 결정 기록, 자체적인 시그널 로그, 자체적인 컨텍스트 저장소를 가져야 합니다. 포트폴리오는 필요할 때 이를 교차 조회하지만, 기본 단위는 언제나 제품입니다.

이것이 바로 그 프로덕트별 메모리. 당연한 소리처럼 들리지만, 시중에 나온 기성 툴 중 이를 기본값으로 지원하는 툴은 거의 없습니다.

2. 결정은 문서가 아니라 일급 객체(first-class)입니다.

대부분의 도구는 무엇이 만들어졌는지를 기록합니다. 정작 필요한 것은 왜 만들어졌는지, 어떤 신호가 그 결정을 촉발했는지, 무엇을 검토하고 기각했는지입니다. 제대로 된 의사결정 기록 은(는) 단순한 문서가 아닙니다. 운영자가 잊어버려도 살아남는 구조화된 아티팩트입니다.

검증 기준: 지금부터 3개월 후, 새로 합류한 팀원이 Game 4의 기록을 읽고 당시 결정을 내렸던 운영자의 사고 과정을 재구성할 수 있는가? 가능하다면 그 기록은 제 역할을 다한 것입니다. 불가능하다면 스튜디오는 같은 교훈을 두 번 되풀이해 겪게 될 것입니다.

3. 역량보다 케이던스.

채용을 늘린다고 포트폴리오 운영 문제가 해결되지는 않습니다. 스튜디오가 지속할 수 있는 리듬에 맞춰 필요한 의사결정이 실행되도록 해야 해결됩니다. 의사결정 주기 이(가) 곧 계약입니다. 스튜디오가 할 일은 이를 준수하는 것입니다.

4. 범용 어시스턴트가 아닌 전문 에이전트.

AI 도구가 등장했을 때의 유혹은 하나의 범용 어시스턴트에게 모든 것을 물어보는 것이었습니다. 하지만 이는 실제 스튜디오의 월요일 아침을 버텨내지 못했습니다. 실제로 효과가 있는 것은 전문 에이전트가입니다. 즉, 운영 기능마다 하나씩 할당되어 한정된 메모리와 단 하나의 업무를 수행하는 방식입니다. 크래시 리포트를 모니터링하는 AI는 카피를 쓰려 하지 않고, 스토어 등록정보를 모니터링하는 AI는 수익화 변경을 제안하지 않습니다.

명확한 범위가 곧 신뢰의 메커니즘입니다. 한 가지 기능의 모든 메모리를 가진 전문 에이전트는 감사하고, 조율하고, 결정을 되돌릴 수 있습니다. 모든 것을 다루는 범용 에이전트는 그렇게 할 수 없습니다.

5. 포트폴리오 전체를 관통하는 하나의 운영 마인드.

위의 다섯 가지는 모두 한곳에 모여 있어야만 비로소 작동합니다. 그렇지 않으면 그저 12개의 대시보드를 조금 더 나은 12개로 바꾼 것에 불과합니다. 이 작업의 핵심은 하나의 운영 두뇌입니다. 동일한 브레인이 모든 프로덕트를 읽고, 동일한 에이전트가 모든 라인에서 실행하며, 운영자가 더 이상 유일한 통합 레이어로 남지 않게 하는 것입니다.

Qualia에 대하여

이것이 바로 우리가 Qualia를 만들며 따르고 있는 플레이북입니다. 이 프로덕트는 AI COO 입니다. 3~20개의 라이브 게임이나 앱을 운영하는 2~10인 규모의 소규모 스튜디오, 즉 포트폴리오 운영자를 위한 제품입니다. 아키텍처는 프로덕트별 메모리, 전문 에이전트, 그리고 공유형 포트폴리오 brain의 결합입니다. 기본값은 인간 개입(human-in-the-loop)입니다. 우리가 스스로를 평가하는 기준은 바로 운영자의 지루함입니다. 창업자가 Qualia 화면을 보며 하품을 한다면, 그 화면은 잘못된 것입니다.

저희는 이제 시작 단계입니다. 고객사는 2곳, 설정은 30분. 멀티 프로덕트 스튜디오를 운영 중이며 위와 같은 문제들로 일주일을 허비하고 계신다면, 대화를 나눠보고 싶습니다. 데모 예약하기.

이 플레이북이 어디에도 쓰여 있지 않은 이유

대부분의 플레이북은 단일 프로덕트의 확장을 전제로 합니다. 하지만 포트폴리오 운영자는 다양성을 다루며 확장해야 합니다. 프로덕트는 늘어나고, 인원은 그대로이며, 프로덕트별 여유는 없습니다. 일하는 방식이 다릅니다. 그렇다면 도구도 달라져야 합니다. 플레이북 역시 마찬가지입니다.

저희가 놓친 또 다른 사례를 발견하셨다면, 꼭 들려주세요.