{
  "title": "AI 앱을 위한 강점 중심 MVP",
  "excerpt": "AI 애플리케이션에서 최소 기능 제품(MVP)의 개념을 탐구하며, 사용자의 요구사항을 효과적으로 이해하고 해결함으로써 가치를 전달하는 방법에 초점을 맞춥니다.",
  "content_html": "<p>최소 기능 제품(MVP)은 초기 고객이 사용할 수 있을 만큼의 기능만을 갖춘 제품 버전으로, 이를 통해 향후 제품 개발을 위한 피드백을 받을 수 있습니다.</p>\n\n<p>오늘은 AI 애플리케이션을 출시할 때 이것이 어떤 모습인지에 초점을 맞추고자 합니다. 이를 위해 우리는 4가지만 이해하면 됩니다.</p>\n<ul>\n<li>80%는 실제로 무엇을 의미하는가?</li>\n<li>우리가 잘 서비스할 수 있는 세그먼트는 무엇인가?</li>\n<li>우리가 집중할 수 있는가?</li>\n<li>우리가 잘 서비스하지 못하는 세그먼트에 대해 사용자를 교육할 수 있는가?</li>\n</ul>\n\n<p>80/20 법칙으로도 알려진 파레토 원칙은 여전히 적용되지만, 여러분이 생각하는 것과는 다른 방식으로 적용됩니다.</p>\n\n<h3>MVP란 무엇인가?</h3>\n<p>이 개념을 이해하는 데 도움이 되도록 제가 자주 사용하는 비유는 다음과 같습니다: A 지점에서 B 지점으로 이동하는 데 도움이 되는 무언가가 필요합니다. 비전은 자동차를 갖는 것일 수 있습니다. 하지만 MVP는 바퀴나 엔진이 없는 섀시가 아닙니다. 대신 스케이트보드처럼 보일 수 있습니다. 출시하고 나면 제품에 브레이크나 조향 장치가 필요하다는 것을 깨닫게 됩니다. 그래서 스쿠터를 출시합니다. 그 후 스쿠터에 더 많은 레버리지가 필요하다는 것을 알게 되어 더 큰 바퀴를 추가하고 자전거를 만들게 됩니다. 인간으로서 가할 수 있는 힘의 한계로 인해 모터에 대해 생각하기 시작하고 모페드, 전기 자전거, 오토바이로 분기할 수 있습니다. 그리고 언젠가 자동차를 출시합니다.</p>\n\n<h3>80/20 법칙을 고려하라</h3>\n<p>무언가가 80% 완료되었거나 80% 준비되었다고 말할 때, 이는 보통 머신러닝 관점에서입니다. 이 맥락에서 각 구성 요소는 결정론적이며, 이는 80%가 10개 기능 중 8개가 완료되었음을 의미합니다. 나머지 2개 기능이 준비되면 제품을 출시할 수 있습니다. 하지만 80/20 법칙을 따르고 싶다면, 80%의 기능으로 제품을 출시하고 나중에 나머지 20%를 추가할 수 있습니다. 라디오나 에어컨이 없는 자동차처럼 말이죠. 그러나 80%의 의미는 크게 다를 수 있으며, 이 정의는 AI 기반 애플리케이션에는 적용되지 않을 수 있습니다.</p>\n\n<p><strong>요약 통계의 문제</strong></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의 예시입니다. 거의 동일한 단순 기술 통계를 가지고 있지만 매우 다른 분포와 외관을 가진 4개의 데이터셋입니다. 이는 요약 통계가 오해를 불러일으킬 수 있는 이유에 대한 고전적인 설명입니다.</p>\n\n<p>다음 예시를 고려해보세요:</p>\n\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\n<p>평균 점수는 0.58입니다. 하지만 세그먼트 내에서 쿼리를 분석하면, 대부분의 쿼리를 매우 잘 서비스하고 있다는 것을 발견할 수 있습니다!</p>\n\n<blockquote>\n<p><strong>자신이 못하는 것을 인정하기</strong></p>\n<p>자신이 못하는 것에 대해 솔직한 것은 사용자와 신뢰를 구축하는 좋은 방법입니다. 무언가가 제대로 작동하지 않을 때를 정확하게 식별하고 자신 있게 거부할 수 있다면, 애플리케이션의 한계에 대해 사용자를 교육하면서 훌륭한 제품을 출시할 준비가 된 것입니다.</p>\n</blockquote>\n\n<p>시스템의 한계를 이해하고 요약 통계를 넘어 시스템의 특성을 자신 있게 이해하는 것이 매우 중요합니다. 모든 시스템이 동일하게 만들어지는 것은 아니기 때문입니다. 확률적 시스템의 동작은 이전 예시와 매우 다를 수 있습니다. 다음 데이터셋을 고려해보세요:</p>\n\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\n<h3>거절하는 법 배우기</h3>\n<p>쿼리의 상당 부분이 타임라인 쿼리에 관한 RAG 애플리케이션을 고려해보세요. 검색 엔진이 이 시간 제약을 지원하지 않는다면, 우리는 좋은 성능을 발휘할 수 없을 것입니다.</p>\n\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\n<p>출시가 급하다면, 이러한 질문이 타임라인 질문인지 여부를 감지하는 분류 모델을 구축하고 경고를 표시할 수 있습니다. 알고리즘이 더 나아지도록 지속적으로 노력하는 대신, 제품을 설계하는 방식을 변경하여 사용자를 교육할 수 있습니다.</p>\n\n<blockquote>\n<p><strong>세그먼트 감지</strong></p>\n<p>이러한 세그먼트를 감지하는 것은 다양한 방법으로 수행될 수 있습니다. 분류기를 구축하거나 언어 모델을 사용하여 범주화할 수 있습니다. 또한 임베딩과 함께 클러스터링 알고리즘을 활용하여 공통 그룹을 식별하고 각 그룹 내의 평균 점수를 분석할 수 있습니다. 유일한 목표는 특정 하위 그룹 내의 활동에 대한 이해를 향상시킬 수 있는 세그먼트를 식별하는 것입니다.</p>\n</blockquote>\n\n<p>할 수 있는 최악의 일 중 하나는 사용자 기반의 더 중요한 세그먼트를 무시하면서 생산성을 조금만 향상시키는 기능을 구축하는 데 몇 달을 보내는 것입니다.</p>\n\n<p>애플리케이션을 재설계하고 한계를 인식함으로써, 거부할 수 있는 작업 유형을 식별하여 특정 조건에서 성능을 잠재적으로 향상시킬 수 있습니다. 이 세그먼트 데이터를 시스템 내 관찰 가능성에 넣을 수 있다면, 거부되는 질문의 비율을 안전하게 모니터링하고 커버리지를 최대화하기 위해 작업의 우선순위를 정할 수 있습니다.</p>\n\n<h3>실제로 무엇을 하려는지 파악한 후에 실행하라</h3>\n<p>스타트업과 일하면서 제가 발견한 위험한 것 중 하나는 우리가 종종 AI가 전혀 작동한다고 생각한다는 것입니다... 그 결과, 우리가 정확히 무엇을 달성하고자 하는지에 대한 깊은 생각 없이 대규모 일반 애플리케이션을 제공할 수 있기를 원합니다.</p>\n\n<p>제 생각에는 이러한 회사들의 대부분이 한두 가지 중요한 영역에 집중하고 타겟팅할 좋은 틈새 시장을 식별하려고 노력해야 합니다. 앱이 한두 가지 작업을 잘한다면, 애플리케이션을 테스트하고 빠르게 피드백을 받을 수 있는 백 명 또는 이백 명의 사용자를 찾지 못할 리가 없습니다. 반면에 애플리케이션이 아무것도 잘하지 못한다면, 기억에 남고 반복적으로 사용할 수 있는 무언가를 제공하기 어려울 것입니다. 약간의 바이럴리티를 얻을 수 있지만, 매우 빠르게 사용자의 신뢰를 잃고 이탈을 줄이려는 상황에 처하게 될 것입니다.</p>\n\n<p>GPT-4를 사용하여 예측을 수행할 수 있는 능력이 선행되면, 피드백까지의 시간이 매우 중요합니다. 빠르게 피드백을 받을 수 있다면 빠르게 반복할 수 있습니다. 빠르게 반복할 수 있다면 더 나은 제품을 만들 수 있습니다.</p>\n\n<h3>최종 생각</h3>\n<p>AI 애플리케이션의 MVP는 80%의 기능으로 제품을 출시하는 것만큼 간단하지 않습니다. 대신, 잘 서비스할 수 있는 사용자 세그먼트에 대한 깊은 이해와 잘 서비스하지 못하는 세그먼트에 대해 사용자를 교육할 수 있는 능력이 필요합니다. 시스템의 한계를 이해하고 틈새 시장을 공략함으로써, 기억에 남고 반복적으로 사용할 수 있는 무언가를 제공하는 제품을 만들 수 있습니다. 이를 통해 빠르게 피드백을 받고 빠르게 반복할 수 있으며, 궁극적으로 강점을 식별함으로써 더 나은 제품으로 이어질 것입니다.</p>",
  "source_hash": "sha256:628188f6afb27695d03e01274d59eb0b52134258149bbac07bab13c678413b93",
  "model": "claude-sonnet-4-5-20250929",
  "generated_at": "2026-01-15T20:09:04.870576+00:00"
}