게임과 앱 개발이 정반대의 본능을 요구하는 이유

아무도 묻지 않는 질문

게임 스튜디오와 SaaS 회사 양쪽에서 시간을 보내봤다면, 아마 이상한 점 하나를 눈치챘을 것이다. 한쪽에서 훌륭하게 통하는 제품 관리 조언이 다른 쪽에서는 처참하게 실패한다.

"사용자와 이야기하세요." "통증 포인트를 찾으세요." "만들기 전에 검증하세요." 이것은 SaaS의 복음이다. 그래야 마땅하다 — 이 원칙들 덕분에 역사상 가장 성공적인 소프트웨어 회사들 일부가 탄생했다. 하지만 게임 스튜디오에 들어가서 같은 방식으로 제품 발견(product discovery)을 진행하려 하면 멍한 시선만 돌아온다. 게임 개발자들이 덜 엄밀해서가 아니라, 그들이 만드는 것의 근본적인 성격이 다르기 때문이다.

앱과 웹 서비스는 **수요 주도적(demand-driven)**이다. 사용자에게 문제가 있고, 제품이 그것을 해결하기 때문에 존재한다. 게임은 **공급 주도적(supply-driven)**이다. 창작자가 경험을 상상하고, 만들고, 사람들 앞에 내놓아 반향을 일으키는지 확인하기 때문에 존재한다.

이것은 단순한 철학적 구분이 아니다. 무엇을 만들지 발견하는 방법, 성공을 측정하는 방법, 반복하는 방법, 언제 완성인지 결정하는 방법 — 모든 것이 달라진다.

graph LR
    subgraph "Demand-Driven (Apps/SaaS)"
        A["User Has Problem"] --> B["Research & Validate"]
        B --> C["Build Solution"]
        C --> D["Measure Adoption"]
        D -->|"Feedback Loop"| B
    end
    subgraph "Supply-Driven (Games)"
        E["Creator Has Vision"] --> F["Prototype & Playtest"]
        F --> G["Ship Experience"]
        G --> H["Market Reacts"]
        H -->|"Creative Iteration"| F
    end

수요 주도: 사람들이 필요로 하는 것을 만들기

현대 SaaS 플레이북은 본질적으로 하나의 질문에 대한 공식화된 답이다. 사용자에게는 어떤 문제가 있고, 대안보다 어떻게 더 잘 해결할 수 있는가?

프로세스는 잘 정리돼 있다. 사용자 리서치로 시작한다. 통증 포인트를 파악한다. 그 통증이 제품을 정당화할 만큼 실재하고 빈번한지 검증한다. MVP를 만들고, 도입률을 측정하고, 피드백에 따라 반복하고, 리텐션을 최적화한다. 문제-해결 적합성에서 제품-시장 적합성을 거쳐 성장에 이르는 전체 파이프라인은 관찰 가능한 수요가 이끈다.

이것이 작동하는 이유는 실용적인 제품들이 기능적 목표를 충족하기 때문이다. 프로젝트 관리 툴은 시간을 절약한다. 회계 앱은 오류를 방지한다. 커뮤니케이션 플랫폼은 마찰을 줄인다. 사용자들은 해결책의 부재를 구체적인 문제로 경험하기 때문에 자신에게 무엇이 필요한지 표현할 수 있다. "나는 매주 두 시간을 상태 업데이트에 낭비한다"는 것은 실제로 만들 수 있는 통증 포인트다.

지표들은 자연스럽게 따라온다. NPS는 만족도를 측정한다. 건강한 B2B SaaS의 연간 이탈률은 3~5%이며, 상위 업체의 순 수익 리텐션은 110% 이상이다. 활성화율은 신규 사용자가 가치를 찾는지 측정한다. 고객 건강 점수는 갱신을 예측한다. 모든 것이 월간 또는 연간 주기로 운영되고, 모든 지표는 하나로 수렴한다. 이 제품은 해결을 약속한 문제를 실제로 해결하고 있는가?

제품 주도 성장(PLG)은 수요 주도 사고의 논리적 종착점이다. 제품이 진정으로 문제를 해결한다면, 사용자들은 그것을 채택하고, 동료를 초대하고, 사용을 확대할 것이다 — 영업 팀의 압박 없이도. 수요가 이미 있기 때문에 제품 자체가 성장 엔진이다.

공급 주도: 사람들이 원한다는 걸 몰랐던 것을 만들기

게임은 이렇게 작동하지 않는다. 아무도 아침에 일어나서 "이탈리아 배관공이 버섯을 밟고 뛰어다니는 플랫포머로만 해결할 수 있는 문제가 있다"고 생각하지 않는다. 슈퍼 마리오 브라더스에 대한 기존 수요는 없다. 수요는 경험 자체가 만들어냈다.

Sid Meier는 게임을 "흥미로운 결정들의 연속"이라고 유명하게 정의했다. 해결된 문제들의 연속이 아니다. 검증된 통증 포인트들의 연속도 아니다. 결정들 — 정서적 반응을 만들어내는 주체성, 긴장, 결과의 순간들. 게임의 제품 발견 프로세스는 "문제를 찾아라"가 아니다 — **"재미를 찾아라"**다. 스튜디오는 빠르게 프로토타입을 만들고, 플레이테스트에 집착하고, 핵심 메카닉이 올바르게 느껴질 때까지 반복한다. 이것은 근본적으로 발산적 사고(창의적 공간 탐색)이지, 수렴적 사고(해결책으로의 좁히기)가 아니다.

Nintendo의 전설적인 디자이너 Shigeru Miyamoto는 자신의 프로세스에 대해 솔직하게 말해왔다. 그는 자신이 직접 하고 싶은 게임을 만들려 하고, 자신이 재미있다면 다른 사람들도 그럴 것이라고 믿는다. 그의 디자인 캔버스는 화면이 아니다 — 플레이어의 인터랙티브 경험이고, 컨트롤러를 집어 들고 올바르게 느껴지는 무언가를 탐색하는 느낌이다. 그가 말한 것처럼 "게임 디자이너는 창의적인 마음을 가져야 하고, 마케팅 사람들에 맞서 설 수 있어야 한다 — 그렇지 않으면 창의적일 수 없다." 이것은 수요 발견이 아니다. 현실에 대해 테스트된 창의적 비전이다.

Steve Jobs는 기술 산업의 반대편에서 같은 철학을 표현했다. "많은 경우, 사람들은 당신이 보여주기 전까지 자신이 무엇을 원하는지 모른다." 그는 시장 조사를 무시한 것이 아니라, 특정 범주의 제품들에서는 전통적인 수요 주도 접근 방식에 한계가 있다고 지적한 것이다. iPhone에 이르는 방법은 설문 조사로 찾을 수 없다. 고객들은 더 좋은 블랙베리를 묘사할 것이지, 주머니 속의 터치스크린 컴퓨터를 묘사하지 않을 것이기 때문이다.

게임 산업의 이 인사이트 버전은 더 극명하다. 게임 사용자 리서치에서 연구자의 역할은 플레이어에게 무엇을 원하는지 묻는 것이 아니라 — 플레이어의 정서적 반응이 디자이너의 의도와 일치하는지 관찰하는 것이다. 공포 게임이 플레이테스터를 무서워하게 만들지 못한다면, 그것은 디자인 문제다. 하지만 애초에 공포 게임을 만들기로 한 결정? 그것은 사용자 수요가 아닌 창의적 비전에서 비롯됐다.

Nintendo의 Wii에 관한 블루 오션 전략은 대표적인 사례다. 처리 성능으로 Sony와 Microsoft와 경쟁하는 대신 — 기존 게이머들이 원하던 수요 — Nintendo는 완전히 다른 질문을 던졌다. 게임을 하지 않는 사람들을 위한 콘솔을 만들면 어떨까? 기존 게이머들과의 사용자 리서치는 이 방향을 결코 도출해내지 못했을 것이다. Wii는 존재하지 않던 경험을 제공함으로써 수요를 만들었다. 할머니와 아이들이 함께 즐길 수 있는 모션 컨트롤 게임.

그리고 지표들은 이 완전히 다른 세계를 반영한다. SaaS가 월간, 연간 주기로 측정하는 반면, 게임은 매일 측정한다. Day 1 리텐션은 평균 26~28%다. Day 7이면 약 8%로 떨어진다. Day 30이 되면 종종 3% 아래다. 수익은 MRR이 아닌 ARPDAU(일별 활성 사용자당 평균 수익)로 추적한다. 시간 지평, 수익 모델, 성공 신호는 SaaS 프레임워크와 구조적으로 호환되지 않는다 — 하나가 더 나아서가 아니라, 제품과 사용자 사이의 근본적인 관계가 다르기 때문이다.

프레임워크가 무너지는 곳

문제는 수요 주도나 공급 주도 접근 방식이 틀렸다는 것이 아니다. 잘못된 제품에 잘못된 것을 적용하는 것이 문제다.

SaaS적 사고가 게임 개발을 침범할 때

게임 스튜디오가 SaaS에서 차용한 데이터 주도 방법론에 지나치게 의존하면, 결과는 예측 가능하다. 획일화. 모든 모바일 게임에 배틀 패스가 생긴다. 모든 라이브 서비스 게임에 리텐션에 최적화된 일일 퀘스트가 생긴다. 모든 디자인 결정이 A/B 테스트를 거친다. 게임은 기술적으로 최적화되지만 창의적으로 공허해진다.

한 업계 분석이 지적했듯, 배틀 패스, 일일 퀘스트, 끊임없는 플레이어 리텐션 메카닉의 확산은 데이터 주도 집착에서 비롯된 것으로, 단기적으로는 인게이지먼트를 높이지만 획일화된 게임 환경을 만들어낸다. 지표는 개선되지만 영혼은 사라진다.

이것이 공급 주도 제품을 수요 주도로 다룰 때 일어나는 일이다. 처음에 사람들이 신경 쓰게 만든 측정 불가능한 것을 희생하면서 측정 가능한 인게이지먼트를 최적화한다. 예술적 방향, 톤, 서사적 주제, 핵심 창의적 비전은 분석에 포착되지 않는다. 데이터는 플레이어가 레벨 3에서 이탈한다고 말할 수 있지만, 게임이 재미있어야 하는지 진지해야 하는지, 스타일리시해야 하는지 사실적이어야 하는지, 접근성을 높여야 하는지 하드코어해야 하는지는 말할 수 없다.

그 대조는 지속적인 운영 방식에서 가장 명확하게 드러난다.

graph TD
    subgraph "SaaS Product Manager"
        A1["User Feedback"] --> A2["Prioritize Problems"]
        A2 --> A3["Ship Features / Fixes"]
        A3 --> A4["Measure Impact"]
        A4 -->|"Converge"| A1
    end
    subgraph "Game LiveOps Manager"
        B1["Creative Vision"] --> B2["Design Events / Seasons"]
        B2 --> B3["Ship Content / Experiences"]
        B3 --> B4["Observe Player Response"]
        B4 -->|"Diverge"| B1
    end

SaaS 제품 관리자는 "다음으로 해결해야 할 문제는 무엇인가?"를 묻고 기능 업데이트, 통합, 버그 수정을 배포한다. 게임 라이브옵스 매니저는 "다음으로 만들어야 할 경험은 무엇인가?"를 묻고 이벤트, 시즌, 콘텐츠 드롭, 배틀 패스를 배포한다. 같은 리듬, 반대 방향. SaaS PM은 사용자 니즈로 수렴한다. 라이브옵스 매니저는 창의적 가능성으로 발산한다.

권장되는 업계 접근 방식은 데이터 참고(data-informed)이지 데이터 주도(data-driven)가 아니다 — 창의적 비전을 유지하면서 분석을 아이디어 검증과 문제 식별에 사용하는 것. 하지만 이 구분은 창의적 비전이 먼저이고 데이터가 그것을 섬기는 것이지, 그 반대가 아니라는 전제를 받아들일 때만 의미가 있다.

게임적 사고가 SaaS를 침범할 때

역방향 실패는 더 드물지만 똑같이 파괴적이다. 실제 사용자 니즈에 대해 검증하기를 거부하는 "비전적인" 제품 아이디어를 가진 SaaS 창업자는 실패한 스타트업의 전형이다. "만들면 올 것이다"는 수요가 경험 자체에 의해 만들어지는 엔터테인먼트 제품에는 유효한 전략이다. B2B 워크플로 툴에는 200만 달러를 아무도 원하지 않는 것에 태우는 방법이다.

통계는 냉혹하다. SaaS 제품의 상당수는 형편없는 실행 때문이 아니라 사용자의 문제를 진정으로 이해하지 못한 채 만들어졌기 때문에 실패한다. 창업자들은 고객의 문제 대신 자신의 아이디어에 반한다. 수요 주도 맥락에서 이것은 치명적이다. 수요가 먼저 있어야 한다.

스펙트럼: 이진법이 아니다

물론 실제 제품들이 항상 하나의 범주에 딱 떨어지는 것은 아니다.

소셜 미디어는 중간에 자리한다. Facebook은 수요 주도로 시작했다(대학생들은 디렉토리를 원했다). 하지만 인게이지먼트와 성장은 공급 주도 메카닉이 이끌었다 — 뉴스피드, 알고리즘 발견, 아무도 요청하지 않았지만 멈출 수 없는 기능들. TikTok은 거의 순수하게 공급 주도다. 아무도 짧은 세로형 영상을 요청하지 않았지만, 경험이 너무 compelling해서 그것이 자체적인 수요를 만들어냈다.

창작 툴은 수요 주도에 가깝지만(디자이너는 디자인해야 한다) 최고의 기능들은 종종 공급 주도다. 아무도 Adobe에 생성형 채우기를 요청하지 않았다. Figma의 멀티플레이어 커서는 명시된 문제를 해결하지 않았다. 이 기능들은 사용자들이 원하는지 몰랐던 새로운 워크플로를 만들어냈다.

Duolingo 같은 게임화된 앱은 두 접근 방식을 의도적으로 혼합한다. 핵심 제품은 수요 주도다(사람들은 언어를 배우길 원한다). 하지만 리텐션과 인게이지먼트는 공급 주도 게임 메카닉 — 스트릭, 리더보드, 캐릭터 서사 — 이 이끄는데, 이것들은 요구된 것이 아니라 설계된 것이다.

graph LR
    A["🔧 Pure Utility"] --- B["Accounting\nSaaS"]
    B --- C["Figma\nNotion"]
    C --- D["Duolingo\nTikTok"]
    D --- E["Mobile\nF2P Games"]
    E --- F["🎮 Pure Entertainment"]

    style A fill:#3b82f6,color:#fff
    style B fill:#60a5fa,color:#fff
    style C fill:#a78bfa,color:#fff
    style D fill:#c084fc,color:#fff
    style E fill:#f472b6,color:#fff
    style F fill:#ef4444,color:#fff

핵심은 당신의 제품이 이 스펙트럼의 어디에 있는지 알고, 그에 맞게 접근 방식을 조정하는 것이다.

만드는 사람들을 위한 실용적 함의

제품을 만들고 있다면, 이 구분이 실제로 의미하는 것은 이렇다.

수요 주도 제품을 위해 (앱, SaaS, 툴)

• 해결책이 아닌 문제에서 시작하라. 사용자 리서치는 선택 사항이 아니다 — 기반이다.
• 만들기 전에 검증하라. 사용자가 통증을 표현하지 못한다면, 수요가 없을 수 있다.
• 중요한 것을 측정하라. NPS, 이탈률, 활성화, 리텐션은 문제-해결 적합성에 직접 매핑된다.
• 피드백에 기반해 반복하라. 사용자들은 문제를 매일 경험하기 때문에 무엇이 잘못됐는지 안다.
• 창의적 비전을 의심하라. 당신의 영리한 아이디어는 대안보다 실제 문제를 더 잘 해결하는지보다 덜 중요하다.

공급 주도 제품을 위해 (게임, 엔터테인먼트, 창의적 경험)

• 시장이 아닌 경험에서 시작하라. 어떤 느낌이나 순간을 만들려 하는가?
• 핵심 경험을 일찍 프로토타입하라. 재미 찾기 — 핵심 메카닉이 올바르게 느껴질 때까지 반복하는 과정 — 가 당신의 문제-해결 적합성 등가물이다.
• 데이터로 결정하지 말고 세밀하게 다듬어라. 분석은 플레이어가 당신이 의도한 경험을 하고 있는지 말해줘야 한다. 어떤 경험을 만들지는 아니다.
• 창의적 비전을 보호하라. 당신의 제품을 특별하게 만드는 것은 아마 측정할 수 없는 것이다.
• 더 큰 분산을 받아들여라. 공급 주도 제품에는 더 큰 히트작과 더 큰 실패작이 있다. 그것이 창의적 리스크의 본질이다.

중간 어딘가에 있는 제품을 위해

• 어느 부분이 수요 주도이고 어느 부분이 공급 주도인지 알아라. SaaS 제품의 핵심 가치 제안은 수요 검증을 받아야 한다. 인게이지먼트 메카닉은 창의적으로 설계될 수 있다.
• 한 접근 방식이 다른 것을 지배하게 두지 마라. 게임화 레이어가 핵심 유틸리티를 압도해서는 안 된다. 사용자 리서치가 창의적 기능을 죽여서도 안 된다.

지금 이것이 중요한 이유

이 구분은 점점 더 중요해지고 있다. AI 툴들 덕분에 앱과 게임 모두를 만드는 비용이 낮아지면서 진입 장벽이 전반적으로 낮아진다. 누구나 빠르게 제품을 출시할 수 있을 때, 무엇을 만들 것인지라는 질문이 어떻게 만들 것인지보다 더 중요해진다.

실용적인 제품들에서, AI 보조 개발은 검증 주기를 빠르게 한다. 수개월이 아닌 수일 만에 프로토타입을 만들고 실제 사용자 니즈에 대해 테스트할 수 있다. 수요 주도 플레이북은 달라지지 않고 더 빨라진다.

창의적인 제품들에서, AI는 콘텐츠 생산의 경제학을 바꾸지만 근본적인 도전은 바꾸지 않는다. 누군가는 여전히 창의적 비전을 가져야 한다. AI는 실행을 도울 수 있지만, 어떤 경험이 만들 가치가 있는지는 말할 수 없다. 오히려 AI 생성 콘텐츠의 홍수는 강력한 창의적 방향을 더 적게가 아니라 더 소중하게 만든다.

자신이 어느 게임을 하고 있는지 — 수요 주도인지 공급 주도인지 — 이해하는 만드는 사람들이 더 나은 제품을 만들 것이다. 잘못된 플레이북을 맹목적으로 적용하는 사람들은 계속 "모범 사례"가 왜 효과가 없는지 궁금해할 것이다.

불편한 진실

제품 관리에서 아무도 큰 소리로 인정하고 싶지 않은 것이 있다. 훌륭한 제품을 만드는 보편적인 프레임워크는 없다. 수요 주도 플레이북과 공급 주도 플레이북은 단순히 다른 전략이 아니라 — 창작자와 사용자 사이의 근본적으로 다른 관계를 반영한다.

수요 주도 제품에서 사용자가 권위다. 그들에게 문제가 있다. 당신이 해결책을 찾는다. 사용자 니즈 앞에서의 겸손이 기본 덕목이다.

공급 주도 제품에서 창작자가 권위다. 그들에게 비전이 있다. 사용자가 그것이 반향을 일으키는지 발견한다. 창의적 확신이 기본 덕목이다.

동시에 겸손하고 비전적이려는 것은 계몽된 것이 아니라 — 혼란스러운 것이다. 당신의 제품이 무엇을 요구하는지 알고, 그것에 헌신하라. 최악의 제품은 결정할 수 없는 제품들이다.