Minbook
EN
AI 제품은 다르게 만들어야 합니다 — 실리콘밸리 20인의 반직관적 조언과 실전 체크리스트
딥다이브 MMU

AI 제품은 다르게 만들어야 합니다 — 실리콘밸리 20인의 반직관적 조언과 실전 체크리스트

MJ · · 6 분 소요

AI 제품은 기존 소프트웨어와 근본적으로 다릅니다. Lenny Rachitsky 뉴스레터에서 추출한 20인의 반직관적 조언, CC/CD 프레임워크, Eval 시스템 3단계를 정리하고, 실전 체크리스트로 연결합니다.

왜 AI 제품은 기존과 다른가

전통 소프트웨어는 결정론적(deterministic)입니다. 코드가 동작하거나 안 하거나. AI 제품은 확률론적(probabilistic)입니다. 같은 입력에 다른 출력이 나옵니다. 이 차이가 제품 개발의 모든 가정을 뒤집습니다.

Emergence Capital 조사에 따르면 60%의 기업이 이미 생성형 AI를 제품에 통합했고, 24%가 로드맵에 올려놓았습니다. 그런데 5개 중 2개 AI 제품은 아직 매출이 0원입니다. 수백만, 수억 달러를 쓰고도.

“AI 시스템은 전통 소프트웨어의 가정을 근본적으로 깨뜨립니다.” — Aishwarya Reganti & Kiriti Badam, OpenAI/Google/Amazon 등 50+ AI 구현 경험

이 글은 Lenny Rachitsky 뉴스레터의 3개 핵심 글에서 추출한 프레임워크를 정리합니다:

소스핵심 주제
Counterintuitive Advice for Building AI Products (2024.07)20개 회사 빌더의 반직관적 교훈 12가지
Why Your AI Product Needs a Different Development Lifecycle (2025.08)CC/CD 프레임워크
Building Eval Systems That Improve Your AI Product (2025.09)Eval 3단계 구축법

12가지 반직관적 교훈

기존 소프트웨어 개발에서 당연하게 여기던 것들이 AI에서는 통하지 않습니다. Adobe, GitHub, Intercom, Perplexity, Canva, Runway 등 20개 회사의 빌더들이 공유한 교훈을 정리합니다.

”사용자 니즈부터” 가 아니라 “기술적으로 가능한 것부터”

전통적 PM 방법론은 “사용자 문제를 먼저 이해하고, 솔루션을 설계하고, 빌드하라”입니다.

“지난 10년간 대부분의 회사에서, 만들고 싶은 것은 대체로 쉽게 만들 수 있다고 가정했습니다. AI는 다릅니다. AI에서는 무언가를 만들 수 있는지 자체가 불확실합니다. 만들었더라도 좋은지 알기 어렵습니다. 최선의 시작점은 ‘기술적으로 무엇이 가능한가?‘를 묻고 프로토타이핑하는 것입니다.” — Paul Adams, Intercom CPO

10년 경력 PM이라도 이 마인드셋 전환이 필요합니다.

데모 가치 =/= 사용자 가치

“멋진 AI 데모를 만들었다고 고객이 사랑하는 유용한 제품이 있는 것은 아닙니다.” — Joshua Xu, HeyGen 공동창업자/CEO

이것이 AI의 “Phantom PMF” 현상입니다. 신기함(novelty)이 사라지면 급격한 이탈이 옵니다. WHOOP의 Hilary Gridley는 이를 검증하기 위한 3가지 테스트를 제안합니다:

  1. Longitudinal validation — 신기함이 사라진 후에도 engagement가 유지되는가?
  2. High-touch testing — 사용자 태도 변화를 매일 가까이 관찰하고 있는가?
  3. Attitudinal segmentation — AI 수용자와 AI 회의론자 모두를 테스트에 포함하는가?

모델 품질보다 중요한 것들

“대부분의 사람들은 AI 서비스를 모델 품질 관점에서 생각하지만, 모델 품질은 전체 제품의 아주 작은 부분입니다. 후처리 필터, 계약적 보장, 데이터 프라이버시, 피드백 루프, 관찰 가능한 인간 영향 등이 훨씬 더 중요합니다. AI 제품을 만드는 것은 결국 제품을 만드는 것과 많이 닮았습니다.” — Ryan J. Salva, GitHub VP of Product

GitHub Copilot의 acceptance rate는 **35%**입니다. 개발자가 Copilot 제안의 35%를 코드에 커밋합니다. 이 수치를 올리는 건 모델 교체가 아니라 UX와 컨텍스트 최적화였습니다.

나머지 교훈 한눈에 보기

#통념반직관적 진실출처
1사용자 니즈부터 시작”기술적으로 뭐가 가능한가?”부터Paul Adams, Intercom
2데모 = 제품Phantom PMF 조심Joshua Xu, HeyGen
3모델 품질이 핵심UX, 프라이버시, 후처리가 더 중요Ryan J. Salva, GitHub
4”AI” 라벨은 불필요AI 브랜딩이 engagement + 이해도 모두 높임James Evans, CommandBar
5대형 AI 기능을 만들라작고 보이지 않는 AI가 팬 favoriteClaire Vo, LaunchDarkly
6앱 체류 시간 = 성공최고의 AI는 체류 시간을 줄임Gaurav Misra, Captions
7쉬운 문제부터 시작스타트업은 오히려 어려운 문제가 안전Sarah Guo, Conviction
8새 기능 개발이 답프롬프트 개선만으로도 충분한 경우 많음Sherif Mansour, Atlassian
9속도보다 품질속도가 곧 경쟁력 (pre-compute > on-demand)Rahul Vohra, Superhuman
10모델 위에 로직을 쌓아라과도한 scaffolding보다 fine-tuning이 효과적Henri Liriani, Tome
11커스텀은 나중에사용자는 처음부터 커스터마이징을 원함Johnny Ho, Perplexity
12데이터는 보조데이터와 인터페이스가 모델보다 중요Scott Belsky, Adobe

CC/CD 프레임워크 — AI 제품의 개발 라이프사이클

기존 소프트웨어의 CI/CD(Continuous Integration/Deployment)로는 AI 제품을 관리할 수 없습니다. AI 제품에는 **CC/CD(Continuous Calibration/Continuous Development)**가 필요합니다.

왜 다른 라이프사이클이 필요한가

AI 제품은 양쪽 끝에서 비결정론적입니다:

  • 입력 측: 사용자가 어떻게 상호작용할지 예측 불가
  • 출력 측: 시스템이 어떻게 응답할지 예측 불가

그리고 모든 AI 제품은 Agency vs Control 트레이드오프를 협상해야 합니다.

“AI 시스템에 더 많은 자율성(Agency)을 줄 때마다, 통제력(Control)을 포기하게 됩니다.”

graph TB
    subgraph CD["Continuous Development"]
        CD1["CD 1: 역량 범위 정의 + 데이터 큐레이션"]
        CD2["CD 2: 애플리케이션 설정"]
        CD3["CD 3: Eval 설계"]
        CD1 --> CD2 --> CD3
    end

    CD3 --> DEPLOY["배포"]

    subgraph CC["Continuous Calibration"]
        CC4["CC 4: Eval 실행"]
        CC5["CC 5: 행동 분석 + 에러 패턴 발견"]
        CC6["CC 6: 수정 적용"]
        CC4 --> CC5 --> CC6
    end

    DEPLOY --> CC4
    CC6 -->|"반복"| CC4
    CC6 -->|"큰 변경 필요"| CD1

Agency는 단계적으로 부여한다

“대부분의 팀이 저지르는 실수는, 시스템이 실패했을 때 무슨 일이 일어나는지 테스트하기 전에 전체 자율성으로 점프하는 것입니다.”

비유: AI에 자율성을 부여하는 것은 새 팀원 온보딩과 같습니다. 아무리 뛰어나도 첫날부터 최고 난이도 프로젝트를 맡기지 않습니다.

버전통제 수준자율 수준마케팅 어시스턴트 예시
v1높음낮음프롬프트에서 이메일/광고 카피 초안
v2중간중간멀티스텝 캠페인 구성 + 실행
v3낮음높음캠페인 론칭 + A/B 테스트 + 자동 최적화

핵심 원칙:

“기술로 시작하지 마세요. 문제, Eval, 데이터가 다음에 무엇을 추가할지 안내하게 하세요. 그것이 AI 제품의 비결정성을 통제하는 방법입니다.”

Eval 시스템 3단계 — AI 제품의 품질 관리

Eval은 AI 시대의 QA입니다. 그런데 대부분 잘못 하고 있습니다.

Hamel Husain과 Shreya Shankar는 Maven에서 1위 매출 코스를 운영하며 500+ 기업의 2,000+ PM/엔지니어를 교육했습니다. Anthropic과 OpenAI의 CPO 모두 “Eval이 제품 빌더의 가장 중요한 새 스킬”이라고 말합니다.

Phase 1: 현실에 기반한 에러 분석

“가장 흔한 실수는 ‘환각(hallucination)‘이나 ‘독성(toxicity)’ 같은 기성 메트릭을 먼저 측정하는 것입니다. 이 접근은 사용자가 실제로 겪는 문제와 상관없는 점수를 추적하게 만듭니다.” — Hamel Husain

올바른 시작: 약 100개의 실제 AI 인터랙션을 무작위 샘플링해서 직접 봅니다.

“1등 함정은 ‘우리는 AI 시대에 산다. AI가 알아서 eval 하면 안 되나?‘입니다. 안 됩니다. ChatGPT에 넣고 ‘에러 있어?‘라고 물으면 ‘없습니다, 잘했어요’라고 답할 겁니다.” — Hamel Husain

Benevolent Dictator 모델: 위원회가 아닌, 단일 도메인 전문가(정신건강 챗봇이면 심리학자, 법률 도구면 변호사)를 품질의 최종 결정자로 지정합니다.

Phase 2: Eval Suite 구축

두 가지 유형의 평가자:

유형용도특성
Code-based객관적, 규칙 기반 실패빠름, 저렴, 결정론적
LLM-as-a-Judge주관적 판단 (톤, 관련성, 추론 품질)느리지만 유연

핵심 인사이트 — Binary가 Likert보다 낫습니다:

“많은 팀이 1~5점 Likert 척도를 쓰면 더 세밀한 판단이 가능하다고 믿습니다. 이것은 함정입니다. ‘3점’과 ‘4점’의 구분은 주관적이고 일관되지 않습니다. Binary 결정은 명확함을 강제합니다.”

그리고 정확도(Accuracy) 대신 TPR/TNR을 측정하세요:

“99% 성공하는 AI 시스템을 상상해보세요. 항상 ‘pass’라고 예측하는 심판은 99% 정확하지만, 실패를 단 하나도 잡지 못합니다.”

  • TPR(True Positive Rate): 실제 성공 중 심판이 정확히 “성공”이라 판단한 비율
  • TNR(True Negative Rate): 실제 실패 중 심판이 정확히 “실패”라 판단한 비율

Phase 3: 운영화

graph LR
    A["모니터링"] --> B["분석"]
    B --> C["개선"]
    C --> D["배포"]
    D --> A

    E["Safety Net: CI 파이프라인 + Golden Dataset"]
    F["Discovery Engine: 프로덕션 LLM-as-Judge (비동기)"]

두 가지 컴포넌트:

  1. Safety Net — Golden Dataset 기반 CI 파이프라인. 리그레션 방지
  2. Discovery Engine — 프로덕션에서 비동기로 LLM-as-Judge 실행. 알려지지 않은 실패 발견

“프롬프팅은 훌륭한 AI 제품을 만드는 것의 아주 작은 부분입니다. 진짜 경쟁 우위는 견고한 Eval 라이프사이클을 통해 시스템 실패를 깊이 이해하는 데서 옵니다.”

실전 적용: AI 제품 론칭 체크리스트

위 프레임워크들이 실제 빌드에서 어떻게 적용되는지 정리합니다.

기본 체크리스트

Make Me Unicorn의 AI Product Blueprint에서 핵심 항목을 추출하면:

카테고리체크 포인트근거
모델 통합API 키 env vars 저장, 클라이언트 코드에 노출 금지기본 보안
비용 통제사용자별 일/월 토큰 한도 설정비용 폭발 방지
비용 통제비용 알림 임계값 설정예측 불가 spend 관리
프롬프트시스템 프롬프트 인젝션 취약점 점검Lesson #3 — 모델 외 보안이 중요
UXAI 생성 중 로딩 인디케이터 (스켈레톤/스트리밍)Lesson #9 — 속도가 경쟁력
UX”재생성” 버튼 제공Lesson #8 — 불완전성 대비
UX사용자 피드백 메커니즘 (thumbs up/down)Eval Phase 1 데이터 수집
데이터프라이버시 정책에 AI API 사용 고지Lesson #3 — 프라이버시
모니터링AI API 지연/에러율 별도 모니터링CC/CD Phase CC4
Eval100개 인터랙션 수동 리뷰 완료Phase 1 기본선

기존 시리즈에서 다룬 관련 주제:

# AI 제품 체크리스트 전체를 CLI로 확인하려면:
pip install make-me-unicorn
mmu init && mmu scan
# docs/blueprints/industry/ai-product.md에서 45+ 항목 확인

정리

AI 제품 개발의 3가지 축:

graph TB
    A["반직관적 사고<br/>12 Lessons"]
    B["CC/CD 라이프사이클<br/>Agency를 단계적으로 부여"]
    C["Eval 시스템<br/>수동 분석 → Suite → 운영화"]

    A --> D["AI 제품<br/>품질 = 경쟁 우위"]
    B --> D
    C --> D
통념현실
모델이 좋으면 된다UX, 프라이버시, 후처리가 더 중요
AI가 Eval을 하면 된다수동 분석이 필수, LLM 자동화는 함정
큰 AI 기능이 차별점작은 AI 마법이 팬 favorite
빠르게 전체 자율성 부여Agency는 단계적으로 earn
Likert 척도가 세밀Binary가 명확하고 효과적

AI 제품은 다르게 만들어야 합니다. 그런데 그 “다름”의 핵심은 더 화려한 기술이 아니라, 더 체계적인 검증과 더 겸손한 출발입니다.

출처

  • Lenny Rachitsky & Kyle Poyar, “Counterintuitive advice for building AI products,” Lenny’s Newsletter, 2024-07-02
  • Aishwarya Reganti & Kiriti Badam, “Why your AI product needs a different development lifecycle,” Lenny’s Newsletter, 2025-08-19
  • Hamel Husain & Shreya Shankar, “Building eval systems that improve your AI product,” Lenny’s Newsletter, 2025-09-09
#AI 프로덕트 #AI PM #제품 개발 #eval #Lenny Rachitsky #스타트업 전략 #SaaS
공유

관련 글