# AI 제품 감각 구축: PM이 15분에 배우는 실전 가이드

> 2026-02-18 · Lenny Rachitsky · 큐레이션 김태우
> https://challengekim.com/insights/lennysnewsletter-building-ai-product-sense-part-2-4-ko
> 원문: https://www.lennysnewsletter.com/p/building-ai-product-sense-part-2

## 핵심 요약

- **AI 제품 감각** 은 모델의 능력과 한계를 이해하고, 이 범위 내에서 사람들이 사랑하는 제품을 구축하는 능력
- **실패 모드 매핑**, **MVQ(최소 실행 가능 품질) 정의**, **가드레일 설계** 3가지 의식으로 15분 내에 AI 제품 감각 개발 가능
- 모델은 불확실성에 직면하면 자신감 있게 거짓 정보(환각)를 생성하는 경향이 있으며, 제품 설계로 이를 방지해야 함
- 의미론적 취약성 파악으로 사용자 의도와 모델 이해 간의 격차를 미리 예방 가능
- **비용 범위 추정** 으로 AI 기능의 비즈니스 타당성을 먼저 검증해야 함

## 15분 내 AI 제품 감각을 개발하는 3가지 의식

AI 제품 감각이라는 근육이 발달하면, 다음과 같은 구체적인 차원에서 제품을 평가할 수 있어야 합니다:

- 모호한 상황에서 모델이 어떻게 동작하는지
- 사용자가 실패를 어떻게 경험하는지
- 신뢰가 어디에서 얻어지거나 잃어지는지
- 규모에 따라 비용이 어떻게 변하는지

이를 위해 **매주 15분 미만의 시간** 으로 다음 3가지 의식을 실행할 수 있습니다:

### 1. 혼란에서 모델의 거짓 신뢰 패턴 발견하기

**목표:** 모델이 혼돈에 구조를 강요하는 경향을 이해하기

모든 PM이 매일 다루는 **혼란스럽고, 반쯤 형성되었으며, 감정적으로 일관성 없는 데이터** 를 모델에게 제공해 보세요. 예를 들어:

- Slack 스레드
- 회의록
- Jira 댓글
- 이메일 체인

그리고 모델에게 "여기서 전략적 결정을 추출해 달라"고 요청하세요.

**핵심 발견:** 혼란에 직면하면, 모델은 **자신감 있게 구조를 만들어냅니다.**

### 실제 예시: 지저분한 Slack 스레드

```
앨리스: "Stripe가 EU 사용자들에게 또 오류가 나나요?"
벤: "모르겠어요, 웹훅 문제일까요?"
사라: "ㅋㅋㅋ 온보딩 모달 이름 또 바꾸지 말까요?"
카일: "다크 모드는 아직 어떻게 해야 할지 모르겠어요"
앨리스: "목요일까지 온보딩을 내보내야 해요"
벤: "잠깐, 모바일에서 배너가 아직도 깨져있나요???"
사라: "카피는 나중에 수정할 수 있어요"
```

이 스레드에서 "전략적 제품 결정"을 추출하도록 모델에게 요청하면, 모델은:

- 로드맵을 **환각**(만들어냄)하고
- 잘못된 담당자를 지정하며
- 즉흥적인 댓글을 약속으로 전환합니다

**결과는 권위 있고, 깔끔하며, 구조화되어 보입니다. 하지만 완전히 틀렸습니다.**

### 올바른 응답으로 개선하기

동일한 Slack 스레드에 명시적인 지침을 추가하세요:

> "스레드에 명시적으로 언급된 항목만 포함하세요. 누락된 것이 있다면 '정보 부족'이라고 말하세요."

이제 모델의 응답이 달라집니다:

- 명확한 결정의 부재를 인정함
- 명확한 질문을 제시함
- 사실을 지어내지 않음
- 불확실성을 숨기기보다 강조함

**이 대조를 통해 AI 제품 감각이 가장 빠르게 날카로워집니다.**

### 배울 점

이 의식에서 발견해야 할 것:

- **무엇이 바뀌었나?** (프롬프트의 어떤 부분이 차이를 만들었는가)
- **어떤 가드레일이 환각을 고쳤나?** (모델이 멈춘 이유가 무엇인가)
- **모델이 안정적으로 작동하려면 무엇이 필요한가?** (명시적 제약? 더 나은 맥락? 더 엄격한 범위?)
- **"좋은" 버전이 출시 가능한 수준인가?** (여전히 취약한 부분이 있는가)
- **각 버전에서 사용자 경험은 어떠한가?**

### 2. 의미론적 취약성 찾기: 모호성에서의 실패

**목표:** 모델의 의미론적 취약성 이해하기

**모호성** 은 확률론적 시스템의 치명적인 약점입니다. 모델이 사용자의 의도를 완전히 이해하지 못하면, **최선의 추측(즉, 환각, 잘못된 아이디어)** 으로 그 공백을 채웁니다. 바로 이 지점에서 사용자 신뢰가 무너지기 시작합니다.

### 실제 테스트 (NotebookLM 활용)

1. **NotebookLM 열기** → 새 노트북 생성
2. **PRD(Product Requirements Document) 업로드** (Google Docs나 PDF)
3. **다음과 같이 질문:** "경영진을 위해 요약하고 상위 5가지 위험과 미해결 질문을 나열해 주세요."

모델이 다음을 수행하는지 관찰하세요:

- **과도하게 요약하는가?** (중요한 세부사항 누락)
- **관련 없는 한 가지 세부사항에 집착하는가?** (우선순위 오류)
- **주의사항을 무시하는가?** (명시적 지침 무시)
- **잘못된 대상을 가정하는가?** (맥락 오해)

**이 지점에서 발견되는 실패가 의미론적 취약성입니다.**

### 모호한 프롬프트와 다양한 해석

다음은 시도할 수 있는 모호한 프롬프트와 명시적으로 테스트해야 할 다양한 해석입니다:

| 모호한 프롬프트 | 가능한 해석 1 | 가능한 해석 2 | 가능한 해석 3 |
|---|---|---|---|
| "이 PRD를 요약해 줘" | 경영진용 (1페이지) | 엔지니어용 (기술 세부사항) | 고객 지원팀용 (FAQ 형식) |
| "핵심 위험을 파악해 줘" | 기술 위험 | 비즈니스 위험 | 사용자 경험 위험 |
| "다음 단계는?" | 개발 다음 단계 | 조직 다음 단계 | 마케팅 다음 단계 |

**배울 점:** 모델이 혼란스러워하는 지점이 바로 **제품이 개입하여 모호성을 줄여야 하는 지점** 입니다.

이는 다음을 의미할 수 있습니다:

- 사용자에게 목표를 선택하도록 요청 ("누구를 위해 요약할까요?")
- 모델에 더 많은 맥락 제공
- 모델이 엉뚱한 방향으로 가지 않도록 행동 제한

**목표는 모델을 "속이려는" 것이 아니라, 의사소통이 단절되는 지점을 이해하여 디자인을 통해 오해를 방지하는 것입니다.**

### 3. 모델의 첫 번째 실패 지점 파악하기

**목표:** 제품에 구조적 가드레일이 필요한 정확한 지점 파악하기

인간 PM에게는 간단하게 느껴지지만 모델의 **추론, 맥락, 또는 판단력** 을 압박하는 작업을 하나 선택하세요.

**중요:** 모델을 철저하게 테스트하려는 것이 아닙니다. **어디서부터 문제가 발생하는지 파악** 하여 제품에 조직적인 구조가 필요한 지점을 알아내려는 것입니다.

### 예시 워크플로우

1. **정상 작업 시도:** "이 지저분한 Slack 스레드에서 행동 항목을 추출해 줘"
2. **실패 지점 관찰:** 모델이 언제 신뢰할 수 없는 결과를 생성하는가?
3. **의도된 동작 정의:** "올바른 응답은 어떻게 보여야 하는가?"
4. **제품 설계로 해결:** 프롬프트, UX, 또는 대체 동작을 조정

**이 지점이 바로 가드레일을 설계하거나, 입력을 제한하거나, 작업을 더 작은 단계로 분할해야 하는 곳입니다.**

## AI 제품 감각을 위한 필수 개념 1: 최소 실행 가능 품질(MVQ)

### MVQ란 무엇인가?

모델의 실패 모드를 이해하고 이를 고려하여 설계했더라도, **AI 기능이 실제 환경에 적용되었을 때 어떻게 작동할지 완전히 예측하는 것은 거의 불가능합니다.**

통제된 개발 환경을 벗어나면 성능은 거의 항상 저하됩니다. 얼마나, 어떻게 저하될지 알 수 없으므로, **처음부터 높은 기준을 유지하는 가장 좋은 방법 중 하나는 MVQ(Minimum Viable Quality)를 정의하고 개발 과정 내내 제품과 비교하여 확인하는 것** 입니다.

**최소 실행 가능 품질(MVQ)** 은 세 가지 기준점을 명확하게 정의합니다:

1. **허용 가능한 기준:** 실제 사용자에게 충분히 좋은 수준
2. **만족스러운 기준:** 기능이 마법처럼 느껴지는 수준
3. **출시 불가 기준:** 신뢰를 깨뜨릴 수 있는 용납할 수 없는 실패율

### MVQ의 구체적인 예시: 음성 인식 기능

저는 수년간 **음성 인식 및 화자 식별** 분야에서 일했는데, 이 분야는 **실험실 정확도와 실제 환경 정확도 간의 격차가 고통스러울 정도로 확연히 드러나는 영역** 입니다.

통제된 테스트에서 모델이 90% 이상의 정확도를 기록했지만, 실제 가정에서 처음 시도했을 때 완전히 무너졌던 경험이 있습니다:

- 짖는 개
- 작동 중인 식기세척기
- 방 건너편에서 말하는 사람
- 동시에 말하는 여러 명

갑자기 "훌륭했던" 모델이 고장 난 것처럼 느껴졌습니다. **사용자 관점에서는 실제로 고장 난 것이었습니다.**

### 스마트 스피커용 화자 식별 MVQ

**허용 가능한 기준:**

- 일반적인 가정 환경에서 x%의 확률로 화자를 정확히 식별
- 확실하지 않을 때 우아하게 복구 ("누가 말하는지 잘 모르겠어요. 당신의 프로필을 사용할까요, 아니면 게스트로 계속할까요?")

**만족스러운 기준 (신호):**

- 사용자가 반복하거나 명령을 바꿔 말하는 것을 멈춤
- "아니요, 제 말은..."과 같은 수정이 급격히 감소

**경험상:** 현실적인 조건에서 **10번 중 8\~9번의 시도가 재시도 없이 성공** 하면 마법처럼 느껴집니다. **5번 중 1번이 재시도를 필요** 로 하면 신뢰는 빠르게 무너집니다.

**출시 불가 기준:**

- 중요한 흐름(구매, 메시지, 개인화된 작업)에서 화자를 y% 이상 잘못 식별
- 인식되기 위해 사용자가 여러 번 반복하도록 강요

### 실제 테스트 시나리오

음성 인식 기능의 만족도를 평가하기 위한 구체적인 테스트:

1. **배경 소음 테스트:** 두 사람이 서로 말을 주고받는 동안 배경에서 비디오를 재생하고, 비서가 "죄송합니다, 다시 말씀해 주시겠어요?"라고 묻지 않고도 여전히 올바르게 응답하는지 확인

2. **오후 6시 주방 테스트:** 식기세척기가 돌아가고, 아이들이 이야기하고, 개가 짖는 상황에서도 스마트 스피커는 여전히 당신을 인식하고 "음성을 인식할 수 없습니다"라는 방해 없이 개인화된 응답을 제공

3. **명령 도중 수정 테스트:** "타이머를 10분으로 설정해 줘... 아니, 5분으로 해 줘"라고 말하면, 원래 지시를 고수하지 않고 올바르게 업데이트

### MVQ 기준 설정에 영향을 미치는 5가지 전략적 요소

특정 임계값이 고정되어 있지 않은 이유는 **MVQ가 귀사의 전략적 맥락에 크게 좌우되기 때문** 입니다.

다음은 해당 기준이 어디에 설정되어야 하는지를 가장 자주 결정하는 5가지 요소입니다:

### 1. 기능의 임무 중요성

- **높음:** 의료, 금융, 보안 (더 높은 기준 필요)
- **중간:** 생산성, 학습
- **낮음:** 엔터테인먼트, 보조 기능

### 2. 실패의 비용

- **높음 비용:** 신뢰 손상, 법적 책임, 보안 위험 (더 높은 품질 필요)
- **낮은 비용:** 단순한 재시도 가능, 사용자 용인 가능

### 3. 경쟁 환경

- **높은 경쟁:** 경쟁 제품보다 나은 기준 필요
- **낮은 경쟁:** 시장 수용 가능 수준으로 충분

### 4. 출시 전략

- **비공개 베타:** 낮은 기준 (사용자가 반복적 개선 기대)
- **광범위한 출시:** 높은 기준 (동일한 실패 모드가 고장 난 것처럼 느껴짐)

### 5. 비즈니스 목표와 예산

- 사용자 유지율 향상이 주 목표라면, 품질이 가장 중요
- 새로운 사용자 확보가 목표라면, 기본 기능이 충분할 수 있음

## AI 제품 감각을 위한 필수 개념 2: 비용 범위 추정

### AI 기능의 재정적 실행 가능성 검증

새로운 AI PM들이 저지르는 **가장 흔한 실수 중 하나** 는 **재정적으로 실행 가능한지 확인하지 않고 마법 같은 AI 데모에 매료되는 것** 입니다.

그렇기 때문에 AI 제품 또는 기능의 **비용 범위를 조기에 추정하는 것이 중요** 합니다.

### 비용 범위의 정의

**비용 범위 = 이 기능이 사용자에게 대규모로 실행될 때 드는 대략적인 비용**

완벽한 숫자가 필요한 것은 아니지만, **대략적인 추정치는 필수** 입니다.

### 비용 범위 추정 단계

다음 질문부터 시작하세요:

1. **호출당 모델 비용** 은 (대략) 얼마입니까?
2. 사용자가 **하루/한 달에 얼마나 자주** 이를 트리거할까요?
3. **최악의 시나리오** 는 무엇입니까? (헤비 사용자, 예외 사례)
4. **캐싱, 더 작은 모델 또는 증류(distillation)** 를 통해 이 비용을 낮출 수 있을까요?
5. 사용량이 **10배 증가** 해도 계산이 여전히 유효할까요?

### 실제 예시: 회의 요약 기능

다음은 실제 회의 요약 AI 기능의 비용 범위 계산입니다:

**호출당 비용:** 30분 분량의 스크립트를 처리하는 데 약 **$0.02**

**평균 사용량:**

- 사용자당 월 20회 회의 → 사용자당 월 약 **$0.40**

**헤비 사용자:**

- 월 100회 회의 → 사용자당 월 약 **$2.00**

**최적화 후:**

- 캐싱과 "부담이 적은" 회의를 위한 더 작은 모델 사용
- 평균적으로 사용자당 월 약 **$0.25–$0.30** 으로 낮춤

### 비용 기반 비즈니스 의사결정

이제 실질적인 대화를 나눌 수 있습니다:

| 월 사용자당 비용 | 상황 | 의사결정 |
|---|---|---|
| **$0.30** | 비용이 낮고 사용자 유지율을 높임 | ✅ 당연히 도입 |
| **$2.00** | 헤비 사용자에게 높은 비용 | ⚠️ 사용 패턴별 차등 가격 필요 |
| **$5.00** | 높은 비용 + 영향 불분명 | ❌ 비즈니스 문제, 재검토 필요 |
| **$10.00+** | 매우 높은 비용 | ❌ 모델 최적화 또는 기능 재설계 필요 |

**핵심 질문:** "우리가 제안하는 것이 실제로 비즈니스에 합당한가?"

## AI 제품 감각을 위한 필수 개념 3: 가드레일 설계

### 가드레일의 목적

모델의 동작이 어디에서 실패하는지, 그리고 출시를 승인하기 위해 무엇을 찾아야 하는지 이해했다면, **이제 몇 가지 안전장치를 명문화하고 제품에 설계할 시간** 입니다.

**좋은 가드레일은 모델이 한계에 도달했을 때 제품이 무엇을 해야 할지 결정하여**, 사용자가 다음을 경험하지 않도록 합니다:

- 혼란스러움
- 잘못된 정보
- 신뢰 손상

**실제로 가드레일은 사용자가 모델의 실패 모드를 경험하지 않도록 보호합니다.**

### 실제 예시: Slack 요약 기능의 소유자 할당 문제

제가 협력하고 있는 한 스타트업에서 팀 생산성을 높이기 위한 AI 기능을 구축했습니다. 이 기능은 **긴 Slack 스레드를 "결정 사항 및 실행 항목"으로 요약** 해 주었습니다.

**테스트에서의 성과:** 완벽하게 작동했습니다.

**출시 후의 문제:**

- 실행 항목에 소유자를 할당하기 시작함
- 때로는 심지어 **엉뚱한 사람을 지목** 하기도 함
- 팀은 이를 알아채고 수동으로 수정해야 함
- 신뢰 문제 발생

### 가드레일 솔루션: 단 하나의 제약 조건

팀이 **AI 제품 감각을 개발했기 때문에**, 해결책은 **다른 기반 모델이 아니라 제품 내의 새로운 가드레일** 이라는 것을 알아냈습니다.

**시스템 프롬프트에 추가한 규칙 (단 한 줄):**

> "누군가 명시적으로 자원하거나 직접 요청받아 확인한 경우에만 소유자를 할당하세요. 그렇지 않은 경우, 주제를 제시하고 사용자에게 다음에 무엇을 할지 물어보세요."

**결과:** 이 단 하나의 제약 조건이 가장 큰 신뢰 문제를 **거의 즉시 해결했습니다.**

### 효과적인 가드레일의 3가지 형태

1. **프롬프트 기반 가드레일**
   - 시스템 프롬프트에 명시적 규칙 추가
   - 예: "명확하지 않으면 정보 부족이라고 말하세요"

2. **UX 기반 가드레일**
   - 사용자에게 선택지 제공
   - 예: "누구를 위해 요약할까요?" (드롭다운)
   - 모호성을 사전에 제거

3. **행동 기반 가드레일**
   - 모델이 특정 조건을 만족하지 않으면 대체 동작 실행
   - 예: "소유자를 할당할 수 없으면, 대신 사용자 검토용으로 표시"

## 실전 적용: 마릴리의 주간 루틴 정리

지금까지 배운 내용을 한 주 동안 어떻게 적용하는지 정리하면:

### 월요일: 현재 구축 중인 AI 워크플로 파악

- 이번 주에 집중할 AI 기능 1가지 선택
- 해당 기능의 주요 실패 모드가 무엇인지 생각해 보기

### 화요일-수요일: 3가지 의식 실행

- **1번 의식 (5분):** 혼란한 입력으로 환각 테스트
- **2번 의식 (5분):** 모호한 프롬프트로 의미론적 취약성 파악
- **3번 의식 (5분):** 첫 번째 실패 지점 파악

### 목요일: MVQ와 비용 정의

- 이 기능의 허용 가능 / 만족 / 출시 불가 기준 정의
- 비용 범위 추정 (호출 비용 × 사용 빈도)

### 금요일: 가드레일 설계

- 발견된 실패 모드를 방지하는 가드레일 설계
- 프롬프트 / UX / 행동 중 어느 것이 가장 효과적인지 결정

### 결과

- **소요 시간:** 15분 미만
- **가치:** 몇 주 후에 프로덕션에서 나타날 수 있는 문제들을 일관되게 사전 발견

## 결론

AI 제품 감각은 더 이상 선택이 아닙니다. 메타를 포함한 주요 기술 회사들이 이를 핵심 역량으로 평가하기 시작했습니다.

**AI 제품 감각의 본질:**

- 모델이 무엇을 할 수 있고 어디에서 실패하는지 이해하기
- 이러한 제약 조건 내에서 사람들이 사랑하는 제품을 구축하기
- 불확실성에 어떻게 대처하고, 올바른 질문을 하고, 명확한 제품 결정을 내리기

**시작하는 방법:**

1. 이번 주에 당신이 구축 중인 AI 기능 하나를 선택하세요
2. 월요일 아침 회의 전 15분을 투자하세요
3. 혼란에서의 환각, 모호성에서의 오류, 첫 번째 실패 지점을 파악하세요
4. MVQ와 비용 범위를 정의하세요
5. 가드레일을 설계하세요

이 간단하지만 강력한 루틴은 모델 동작에 대한 초기 피드백을 제공하여, 사용자들이 어려운 방식으로 가르쳐주기 전에 당신의 AI 제품이 현실과 접촉했을 때 살아남을 수 있는지 확인하도록 강제합니다.

당신의 AI 제품을 더 견고하게, 더 신뢰할 수 있게 만들 준비가 되셨나요? 이 주간 루틴부터 시작하세요.

---

원문을 바탕으로 AI 가 한국어로 요약·재구성한 글입니다. 인용·수치는 원문 링크에서 확인해 주세요. [원문 링크](https://www.lennysnewsletter.com/p/building-ai-product-sense-part-2)