{
  "title": "AI 앱을 위한 강점 기반 MVP",
  "excerpt": "AI 애플리케이션의 최소 기능 제품(MVP) 개념을 탐구하며, 사용자의 니즈를 효과적으로 이해하고 충족시킴으로써 가치를 전달하는 데 초점을 맞춥니다.",
  "content_html": "<p>최소 기능 제품(MVP)은 초기 고객이 사용할 수 있을 만큼 충분한 기능만을 갖춘 제품 버전으로, 이를 통해 고객이 향후 제품 개발에 대한 피드백을 제공할 수 있습니다.</p>\n<p>오늘은 AI 애플리케이션을 출시할 때 MVP가 어떤 모습이어야 하는지에 집중하고 싶습니다. 이를 위해서는 단 4가지만 이해하면 됩니다.</p>\n<ul>\n<li>80%이 실제로 무엇을 의미하는가?</li>\n<li>어떤 세그먼트를 잘 서비스할 수 있는가?</li>\n<li>집중 투자할 수 있는가?</li>\n<li>잘 서비스하지 못하는 세그먼트에 대해 사용자를 교육할 수 있는가?</li>\n</ul>\n<p>파레토 법칙, 즉 80/20 법칙은 여전히 적용되지만, 여러분이 생각하는 것과는 조금 다른 방식으로 적용됩니다.</p>\n<h3>MVP란 무엇인가?</h3>\n<p>이 개념을 이해하는 데 자주 사용하는 비유는 다음과 같습니다. A 지점에서 B 지점으로 이동할 수 있는 무언가가 필요합니다. 비전은 자동차를 갖는 것일 수도 있습니다. 하지만 MVP는 바퀴나 엔진이 없는 섀시가 아닙니다. 대신, 그것은 스케이트보드와 같은 모습일 수 있습니다. 출시한 후 제품에 브레이크나 조향 장치가 필요하다는 것을 깨닫게 됩니다. 그래서 스쿠터를 출시합니다. 이후 스쿠터에 더 많은 지렛대 효과가 필요하다는 것을 알게 되어 더 큰 바퀴를 달고 자전거를 만들게 됩니다. 인간이 가할 수 있는 힘에 한계가 있으므로, 모터에 대해 생각하기 시작하고 모페드, 전기 자전거, 오토바이로 분기할 수 있습니다. 그리고 언젠가, 자동차를 출시하는 것입니다.</p>\n<h3>80/20 법칙 고려하기</h3>\n<p>무언가가 80% 완료되었다거나 80% 준비되었다고 이야기할 때, 이는 보통 머신러닝적 의미에서입니다. 이 맥락에서 각 컴포넌트는 결정론적(deterministic)이며, 이는 80%가 10개 기능 중 8개가 완료되었음을 의미합니다. 나머지 2개 기능이 준비되면 제품을 출시할 수 있습니다. 하지만 80/20 법칙을 따르려면, 80%의 기능만으로 제품을 출시하고 나중에 나머지 20%를 추가할 수도 있습니다. 라디오나 에어컨이 없는 자동차처럼 말이죠. 하지만 80%의 의미는 상황에 따라 크게 달라질 수 있으며, 이러한 정의가 AI 기반 애플리케이션에 적용되지 않을 수도 있습니다.</p>\n<p>요약 통계의 문제점</p>\n<img src=\"/assets/images/anscombes_quartet.png\" alt=\"Anscombe's quartet\" class=\"post-img\" width=\"1200\" height=\"873\" />\n<p>위 이미지는 앤스콤의 콰르텟(Anscombe's quartet)의 예시입니다. 이는 거의 동일한 단순 기술 통계를 가지지만 매우 다른 분포와 외관을 보이는 네 개의 데이터셋입니다. 이는 요약 통계가 왜 오해를 불러일으킬 수 있는지에 대한 전형적인 설명입니다.</p>\n<p>다음 예시를 살펴보겠습니다:</p>\n<table>\n    <thead>\n        <tr>\n            <th>Query_id</th>\n            <th>score</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td>1</td>\n            <td>0.9</td>\n        </tr>\n        <tr>\n            <td>2</td>\n            <td>0.8</td>\n        </tr>\n        <tr>\n            <td>3</td>\n            <td>0.9</td>\n        </tr>\n        <tr>\n            <td>4</td>\n            <td>0.9</td>\n        </tr>\n        <tr>\n            <td>5</td>\n            <td>0.0</td>\n        </tr>\n        <tr>\n            <td>6</td>\n            <td>0.0</td>\n        </tr>\n    </tbody>\n</table>\n<p>평균 점수는 0.58입니다. 하지만 세그먼트별로 쿼리를 분석하면, 대다수의 쿼리를 매우 잘 서비스하고 있다는 것을 발견할 수도 있습니다!</p>\n<blockquote>\n<p><strong>자신이 약한 부분을 인정하기</strong></p>\n<p>자신이 약한 부분에 대해 솔직한 것은 사용자와의 신뢰를 구축하는 좋은 방법입니다. 무언가가 잘 작동하지 않을 때를 정확히 식별하고 자신 있게 거부할 수 있다면, 애플리케이션의 한계에 대해 사용자를 교육하면서 훌륭한 제품을 출시할 준비가 된 것일 수 있습니다.</p>\n</blockquote>\n<p>시스템의 한계를 이해하고 요약 통계를 넘어서 시스템의 특성을 자신 있게 파악할 수 있는 것이 매우 중요합니다. 모든 시스템이 동일하게 만들어지는 것은 아니기 때문입니다. 확률적 시스템의 동작은 이전 예시와 매우 다를 수 있습니다. 다음 데이터셋을 살펴보겠습니다:</p>\n<table>\n    <thead>\n        <tr>\n            <th>Query_id</th>\n            <th>Score</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td>1</td>\n            <td>.59</td>\n        </tr>\n        <tr>\n            <td>2</td>\n            <td>.58</td>\n        </tr>\n        <tr>\n            <td>3</td>\n            <td>.59</td>\n        </tr>\n        <tr>\n            <td>4</td>\n            <td>.57</td>\n        </tr>\n    </tbody>\n</table>\n<p>이러한 시스템도 평균 점수가 0.58로 동일하지만, 어떤 요청 부분집합도 거부하기가 쉽지 않습니다...</p>\n<h3>'아니오'라고 말하는 법 배우기</h3>\n<p>타임라인 쿼리에 관한 질문이 큰 비중을 차지하는 RAG 애플리케이션을 생각해 보겠습니다. 검색 엔진이 이러한 시간 제약을 지원하지 않는다면, 우리는 제대로 수행하지 못할 가능성이 높습니다.</p>\n<table>\n    <thead>\n        <tr>\n            <th>Query_id</th>\n            <th>Score</th>\n            <th>Query Type</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td>1</td>\n            <td>0.9</td>\n            <td>text search</td>\n        </tr>\n        <tr>\n            <td>2</td>\n            <td>0.8</td>\n            <td>text search</td>\n        </tr>\n        <tr>\n            <td>3</td>\n            <td>0.9</td>\n            <td>news search</td>\n        </tr>\n        <tr>\n            <td>4</td>\n            <td>0.9</td>\n            <td>news search</td>\n        </tr>\n        <tr>\n            <td>5</td>\n            <td>0.0</td>\n            <td>timeline</td>\n        </tr>\n        <tr>\n            <td>6</td>\n            <td>0.0</td>\n            <td>timeline</td>\n        </tr>\n    </tbody>\n</table>\n<p>출시가 급하다면, 타임라인 질문인지 아닌지를 감지하는 분류 모델을 간단히 만들어 경고를 표시할 수 있습니다. 알고리즘이 더 잘하도록 끊임없이 밀어붙이는 대신, 사용자를 교육하고 제품을 설계하는 방식을 바꿈으로써 사용자를 교육할 수 있습니다.</p>\n<blockquote>\n<p><strong>세그먼트 감지하기</strong></p>\n<p>이러한 세그먼트를 감지하는 것은 다양한 방법으로 수행할 수 있습니다. 분류기를 구축하거나 언어 모델을 활용하여 카테고리화할 수 있습니다. 또한 임베딩과 함께 클러스터링 알고리즘을 활용하여 공통 그룹을 식별하고, 각 그룹 내 평균 점수를 분석할 수도 있습니다. 유일한 목표는 특정 하위 그룹 내 활동에 대한 이해를 높일 수 있는 세그먼트를 식별하는 것입니다.</p>\n</blockquote>\n<p>가장 하면 안 되는 일 중 하나는, 사용자층의 더 중요한 세그먼트를 무시한 채 몇 달 동안 생산성을 조금밖에 높여주지 않는 기능을 개발하는 것입니다.</p>\n<p>애플리케이션을 재설계하고 한계를 인식함으로써, 우리가 거부할 수 있는 작업 유형을 식별하여 특정 조건에서 성능을 잠재적으로 개선할 수 있습니다. 이러한 세그먼트 데이터를 In-System Observability에 넣을 수 있다면, 거부되는 질문의 비율을 안전하게 모니터링하고 커버리지를 극대화하도록 작업의 우선순위를 정할 수 있습니다.</p>\n<h3>하기 전에 실제로 무엇을 하려 하는지 파악하라</h3>\n<p>스타트업에서 일하면서 느낀 위험한 점 중 하나는, 우리가 종종 AI가 그냥 잘 작동한다고 생각한다는 것입니다... 그 결과, 우리는 정확히 무엇을 성취하고 싶은지에 대해 별다른 생각 없이 대규모 범용 애플리케이션을 서비스하고 싶어 합니다.</p>\n<p>제 의견으로는, 이러한 대부분의 회사들은 한두 개의 중요한 영역에 집중하고 공략할 좋은 틈새 시장(niche)을 찾아야 합니다. 앱이 한두 가지 작업에 능하다면, 애플리케이션을 테스트하고 빠르게 피드백을 받을 수 있는 100명이나 200명의 사용자를 찾지 못할 리가 없습니다. 반면, 애플리케이션이 아무것도 잘하지 못한다면, 기억에 남고 반복적으로 사용할 가치를 제공하기 어려울 것입니다. 일시적인 바이럴(virality)을 얻을 수는 있겠지만, 매우 빠르게 사용자의 신뢰를 잃고 이탈률(churn)을 줄이려 애쓰는 처지에 빠지게 될 것입니다.</p>\n<p>초기 단계에서 GPT-4를 사용하여 예측을 하고 피드백까지의 시간이 매우 중요합니다. 빠르게 피드백을 받을 수 있다면, 빠르게 반복(iterate)할 수 있습니다. 빠르게 반복할 수 있다면, 더 나은 제품을 만들 수 있습니다.</p>\n<h3>마무리</h3>\n<p>AI 애플리케이션의 MVP는 80%의 기능만 갖춘 제품을 출시하는 것만큼 단순하지 않습니다. 대신, 잘 서비스할 수 있는 사용자 세그먼트에 대한 깊은 이해와 잘 서비스하지 못하는 세그먼트에 대해 사용자를 교육할 수 있는 능력이 필요합니다. 시스템의 한계를 이해하고 틈새 시장(niche)에 집중함으로써, 기억에 남고 반복적으로 사용할 가치를 제공하는 제품을 만들 수 있습니다. 이를 통해 빠르게 피드백을 받고 빠르게 반복할 수 있으며, 궁극적으로 자신의 강점(feats of strength)을 파악함으로써 더 나은 제품에 이르게 될 것입니다.</p>",
  "source_hash": "sha256:145f757651a7540ac4d35b4afde9a79f337936029ace5840b1ff7b5d56b0fce6",
  "model": "moonshotai/kimi-k2.6",
  "generated_at": "2026-08-07T05:35:25.840492+00:00"
}