AI 제품 감각 구축: 제품 매니저를 위한 완벽 실전 가이드

핵심 요약

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

올바른 응답으로 개선하기

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

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

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

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

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

배울 점

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

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

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

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

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

실제 테스트 (NotebookLM 활용)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

예시 워크플로우

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

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

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

MVQ란 무엇인가?

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

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

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

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

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

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

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

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

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

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

허용 가능한 기준:

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

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

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

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

출시 불가 기준:

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

실제 테스트 시나리오

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

배경 소음 테스트: 두 사람이 서로 말을 주고받는 동안 배경에서 비디오를 재생하고, 비서가 "죄송합니다, 다시 말씀해 주시겠어요?"라고 묻지 않고도 여전히 올바르게 응답하는지 확인
오후 6시 주방 테스트: 식기세척기가 돌아가고, 아이들이 이야기하고, 개가 짖는 상황에서도 스마트 스피커는 여전히 당신을 인식하고 "음성을 인식할 수 없습니다"라는 방해 없이 개인화된 응답을 제공
명령 도중 수정 테스트: "타이머를 10분으로 설정해 줘... 아니, 5분으로 해 줘"라고 말하면, 원래 지시를 고수하지 않고 올바르게 업데이트

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

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

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

1. 기능의 임무 중요성

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

2. 실패의 비용

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

3. 경쟁 환경

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

4. 출시 전략

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

5. 비즈니스 목표와 예산

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

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

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

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

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

비용 범위의 정의

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

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

비용 범위 추정 단계

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

호출당 모델 비용 은 (대략) 얼마입니까?
사용자가 하루/한 달에 얼마나 자주 이를 트리거할까요?
최악의 시나리오 는 무엇입니까? (헤비 사용자, 예외 사례)
캐싱, 더 작은 모델 또는 증류(distillation) 를 통해 이 비용을 낮출 수 있을까요?
사용량이 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가지 형태

프롬프트 기반 가드레일
- 시스템 프롬프트에 명시적 규칙 추가
- 예: "명확하지 않으면 정보 부족이라고 말하세요"
UX 기반 가드레일
- 사용자에게 선택지 제공
- 예: "누구를 위해 요약할까요?" (드롭다운)
- 모호성을 사전에 제거
행동 기반 가드레일
- 모델이 특정 조건을 만족하지 않으면 대체 동작 실행
- 예: "소유자를 할당할 수 없으면, 대신 사용자 검토용으로 표시"

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

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

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

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

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

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

목요일: MVQ와 비용 정의

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

금요일: 가드레일 설계

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

결과

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

결론

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

AI 제품 감각의 본질:

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

시작하는 방법:

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

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

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

Original source: Building AI product sense, part 2

powered by osmu.app

(Lenny's Newsletter) AI 제품 감각 구축: PM이 15분에 배우는 실전 가이드