AI 제품 개발 전략: PostHog가 12개월 Max AI로 검증한 9가지 실전 공식

AI 기능 붙였더니 제품이 더 안 좋아졌어요.

의외로 많이 듣는 말이다. 런치할 때만 잠깐 화제가 됐다가, 한 달 뒤에는 사용률 1% 미만으로 가라앉는 AI 기능이 흔하다. 어떤 팀은 LLM 호출 비용만 늘었고, 어떤 팀은 사용자 환각 신고에 매주 시달린다.

같은 시기에 PostHog는 정반대 결과를 만들었다. 12개월 동안 Max AI를 붙여 SDK 설치 시간을 10분에서 90초로 줄였고, AI 어시스턴트가 제품의 코어 가치를 강화하는 자리에 들어앉았다. 차이는 어디서 왔을까. 답은 화려한 모델이 아니라 AI 제품 개발 전략 자체였다.

AI라는 이유만으로 새 기능을 덜 엄격하게 판단해서는 안 됩니다.

PostHog의 Ian Vanagas가 1년의 회고를 정리하며 남긴 한 줄이다(PostHog Newsletter). 이 글은 그 회고에서 검증된 9가지 교훈을, 한국 SaaS·1인 개발팀이 그대로 옮겨 쓸 수 있는 형태로 다시 짠 정리본이다. PostHog가 비싸게 배운 길을 짧게 따라가자.

대시보드 위에 떠 있는 AI 어시스턴트는 제품 가치를 더하기보다 흐릿하게 만들기도 한다

선택의 단계: 어떤 AI 기능을 만들 것인가

가장 흔한 실수는 만들 수 있는 것부터 시작한다는 점이다. 제대로 된 AI 제품 개발 전략은 정반대 순서로 간다. 사용자가 매일 부딪히는 마찰을 먼저 본다.

1. 검증된 3가지 패턴 안에서 시작한다

PostHog가 1년 동안 결론으로 좁힌 패턴은 단 세 가지다.

데이터 대화(Conversational Data): Intercom Fin, Mintlify 챗봇처럼 방대한 정보를 자연어로 검색·요약. 도구가 데이터를 가지고 있을 때 가장 강력하다
생성기(Generator): 코드·문서·SQL·이미지를 만들어준다. Lovable, Bolt.new 같은 앱 빌더, Notion·Figma의 글·디자인 생성 기능이 여기에 속한다
도구 활용(Tool Use): AI가 정의된 도구를 호출해 워크플로우를 자동화. MCP 서버 표준이 이 패턴을 가속한다

Anthropic이 2024년 말 공개해 2026년 들어 사실상의 업계 가이드가 된 ‘Building Effective AI Agents’ 문서도 같은 줄을 그어둔다(Anthropic, 2026). 워크플로우와 에이전트를 구분하고, 가능한 가장 단순한 패턴부터 시작하라는 원칙이다. 처음부터 멀티 에이전트 오케스트레이션을 짜는 팀은 거의 모두 다시 단순화 단계로 돌아온다.

Max AI는 이 셋을 모두 쓰지만, 시작은 한 가지였다. 자연어 SQL 쿼리 생성. 가장 작은 가치 단위에서 출발해 점차 결합을 늘렸다.

2. ‘AI가 풀 만한 진짜 문제’의 3가지 신호

PostHog는 AI를 붙일 후보 작업을 다음 세 가지 신호로 골랐다.

30초 이상 걸리는 명확한 단일 작업 (긴 양식, 수동 입력, SDK 설치)
사용자가 이해하지 못하는 언어·UI를 요구하는 작업 (SQL, 복잡한 필터)
20회 이상 반복하는 작업 (요약 작성, 항목 생성)

incident.io 창업자 Stephen Whitworth의 말이 정수다.

AI가 할 수 있는 멋진 새것보다, 사용자가 하루 100번 하는 일을 AI가 더 잘 만들 수 있는 곳에 집중하라.

실제로 incident.io는 이 원칙으로 인시던트 요약의 75%가 AI 생성으로 돌아가게 만들었다.

3. 가치 없는 문제에 검증된 패턴을 얹지 않는다

가장 비싼 함정 두 가지다.

첫째, 가치 없는 문제에 트렌드 패턴을 얹는 것.: 초기 단계 단순한 제품에 “문서와 대화” 챗봇을 붙이면 핵심 사용성 문제를 가린다.
둘째, 너무 큰 문제를 한 번에 해결하려는 것.: PostHog 초기 Max는 “수익을 어떻게 늘릴까” 같은 광범위한 질문에 답하려 했고, 빠르게 실패했다.

같은 함정에 빠지는 스타트업의 패턴은 혁신적인 스타트업이 실패하는 이유: 문제 정의의 함정에서 짚은 “거대한 가짜 문제 정의”와 정확히 겹친다. AI를 붙이는 순서도 같다. 좁은 문제를 먼저 풀고, 점진적으로 컨텍스트를 키운다.

구현의 단계: AI 기능을 실제로 작동하게 만드는 요소

기능 후보를 골랐다면 이제 구현이다. 여기서 “OpenAI API 호출 = AI 기능”이라는 착각이 가장 비싸다.

4. 차별화는 모델이 아니라 컨텍스트와 상태에서 온다

같은 GPT-5 API를 써도 결과는 천차만별이다. 차이를 만드는 건 앱이 가진 고유한 컨텍스트다.

Max가 “지난주 가입이 감소한 이유” 라는 질문을 받으면, API 호출에는 다음이 함께 실린다.

현재 페이지 정보: 대시보드 이름, 표시된 인사이트, 적용된 필터, 사용자 역할
데이터 스키마: 사용 가능한 이벤트, 이벤트 속성, 사람 속성
계정 정보: 조직 티어, 시간대, 보존 기간

여기에 상태(state) 관리가 더해진다. 메시지 히스토리, 중간 단계, 계획, 현재 쿼리, 시각화 결과. 대화가 길어져도 컨텍스트가 끊기지 않게 모든 워크플로우 단위에서 상태를 저장·전달한다. 한국에서 빠르게 이름이 굳어진 컨텍스트 엔지니어링: 바이브 코딩 너머의 AI 개발 패러다임이 바로 이 영역을 다룬다. 모델 미세조정보다 컨텍스트 최적화가 비용 대비 효과가 훨씬 크다는 결론은 두 글이 같은 방향에서 맞닿는다.

5. 자유 방임 대신 쿼리 계획과 조건부 라우팅

AI를 자유롭게 두면 예상 못 한 행동을 한다. PostHog는 단계를 명시적으로 오케스트레이션한다.

사용자 질문
   ↓
[Router] 인사이트? 문서 검색? 청구?
   ↓
[Planner] 어떤 데이터, 어떤 도구가 필요한가
   ↓
[Executor] SQL 실행, 도구 호출, 시각화 생성
   ↓
[Validator] 결과 포맷 점검, 누락 데이터 확인

이 구조는 Anthropic이 분류한 워크플로우 패턴과 정확히 일치한다. 에이전트가 자유롭게 추론하는 구조보다, 라우터가 작업을 분기하고 각 노드가 자기 책임을 갖는 구조가 운영 안정성에서 한 단계 위다. 멋있어 보이는 자율 에이전트보다, 예측 가능한 워크플로우가 매출을 만든다.

6. 가드레일은 4겹으로 깐다

AI는 결국 한계에 부딪힌다. PostHog는 가드레일을 4단계로 분리했다.

모니터링: 프로덕션 트레이스 수집은 첫날부터. 하루 1,000건의 대화는 사람이 검토 불가능하지만, 트레이스 기반 자동 분류는 가능하다
환각 방지: 모델이 환각할 수 있는 모든 항목에 명시적 규칙. PostHog의 AI 설치 마법사는 *”API 키 환각 금지”*, *”플레이스홀더 주석 금지”*, *”기존 비즈니스 로직 수정 금지”*, *”새 패키지 임포트 금지”*를 시스템 프롬프트에 못 박는다
사용자 가드레일: 빈 입력창은 사용자도 멈추게 한다. 시작 제안 3~5개를 항상 노출
오류 처리: 재시도, 속도 제한, 폴백 응답. 워크플로우는 반드시 깨진다는 전제

가드레일의 효과는 데이터로 입증된다. 2026년 업계 분석은 RAG·가드레일·HITL을 결합한 스택에서 환각률을 40~96%까지 감소시킬 수 있다고 보고했다(Blockchain Council, 2026). 모델 자체의 베이스라인 환각률이 작업에 따라 3~20%인 것을 감안하면, 가드레일은 선택이 아니다.

운영의 단계: AI 기능을 진짜로 살리는 것

런치는 출발선이다. 운영이 진짜 게임이다.

7. ‘AI 담당자 한 명’ 구조를 깬다

가장 흔한 실패는 ‘AI는 AI팀의 일’이라는 분리다. PostHog의 처방은 세 가지다.

프리미티브 구축: 프롬프트, 스트리밍, 동의, eval, 분석을 공통 라이브러리로. 매번 재발명하지 않는다
일관된 UX 패턴: 앱 전체에 ‘Max’라는 단일 페르소나. 위젯이 수천 개 흩어지는 카오스를 방지
AI 전문가의 일시 배치: 한 사람이 한 팀에 2~4주씩 들어가서 패턴을 이식하고 빠진다

AI 기능은 제품팀 모두의 책임이 되어야 한다. 디자이너·PM·엔지니어가 모두 LLM 호출의 비용 구조와 에러 패턴을 안다는 전제 위에서만, 통합 깊이가 만들어진다. AI와 협업해 일하는 방식의 큰 그림은 AI 협업 최적화 전략에서 다뤘다.

8. 속도는 기능이 아니라 기능 자체다

AI 기능의 가장 큰 경쟁자는 다른 AI 도구가 아니다. 사용자가 직접 처리하는 5초다. 5초 vs 12초 LLM 응답이면 사용자는 직접 한다.

PostHog의 속도 전략은 세 갈래다.

모델 벤치마크 추적: 새 모델이 나오면 24시간 안에 후보 큐에 올린다
빠른/느린 모델 혼용: 제목 생성·세션 필터·설문 요약은 mini/nano 클래스, 스키마 생성·대화 관리는 풀 모델
비동기 처리: 세션 요약·패턴 추출 같은 무거운 작업은 Temporal 워크플로우로 백그라운드 실행

Superhuman 창업자 Rahul Vohra의 *”속도가 승리한다”*는 단순한 경구가 아니다. Gmail·Outlook의 답장 자동 생성 기능이 사용자를 잡지 못한 이유는 요청 시 생성하기 때문이다. Superhuman은 같은 결과를 사전 계산해 즉시 띄운다. 같은 기능, 다른 UX, 다른 결과다.

9. eval은 처음부터, 비교는 끝까지

신기능이 ‘AI’라는 이유로 평가 기준이 느슨해지면 제품은 망한다. PostHog가 운영에서 굳힌 5가지 평가 루프다.

초기 eval 도입: 작은 골든 데이터셋(50~200개)만 있어도 일반 개발 주기 대비 큰 성능 향상
A/B 테스트: AI 기능 vs 비AI 경험, 다른 프롬프트, 다른 컨텍스트
고객 유형별 사용률 모니터링: PostHog는 이상 ICP였던 제품 엔지니어보다 PM·마케터가 Max를 더 자주 쓴다는 걸 발견하고 로드맵을 다시 짰다
인라인 피드백: 각 응답에 좋음/나쁨 + 나쁘게 평가 시 후속 질문
AI 사용자 vs 비AI 사용자 코호트 비교: 활성화·유지율로 AI의 진짜 영향 측정

이 다섯이 함께 돌아가야 의미 있는 eval이 된다. AWS의 ‘Evaluating AI agents’ 사례 연구도 같은 결론을 짚는다. 단일 정확도 지표가 아니라 품질·성능·책임·비용을 동시에 보는 4축 평가 프레임워크가 프로덕션 표준이다(AWS, 2026). Datadog의 LLM 평가 프레임워크 가이드는 이 흐름을 운영 환경에 어떻게 박아 넣는지 단계별로 보여준다(Datadog).

한국 SaaS·1인 개발팀이 오늘 적용할 5가지

PostHog는 직원 100명 이상의 회사다. 한국 SaaS나 1인 개발팀에 그대로 옮기기는 무리다. 다음 5가지로 압축하면 그대로 쓸 수 있다.

첫 AI 기능은 30초 이상 걸리는 단일 작업 한 가지로 한정한다 (예: 자연어 → 검색 필터)
앱 컨텍스트 3종 세트(현재 화면, 데이터 스키마, 계정 정보)를 시스템 프롬프트에 항상 주입
시스템 프롬프트에 환각 금지 규칙 4개를 명시한다 (예: “DB 스키마에 없는 필드 사용 금지” 등)
빠른/느린 모델 분리. 요약·제목·태그는 작은 모델, 핵심 추론은 큰 모델
eval 골든 셋 50개를 깃 리포에 보관하고, 모델·프롬프트 변경 시 자동 회귀 테스트

이 5개만 박아두면 출시 후 한 달 운영 안정성이 다른 차원으로 올라간다. 가장 흔한 사고는 4번을 안 해서 GPT 토큰 비용이 폭증하거나, 5번을 안 해서 모델 업데이트 후 응답이 미묘하게 망가지는 경우다.

AI는 결국 제품을 위한 도구다

마지막 한 줄이 가장 중요하다. 9가지 교훈은 독립이 아니라 하나의 시스템이다. 끝의 eval만 잘하면 좋은 제품이 나온다는 생각, 멋진 모델만 붙이면 사용자가 알아본다는 생각은 둘 다 같은 종류의 착각이다.

훌륭한 제품을 만드는 원칙은 AI 시대에도 그대로다. 사용자와 대화하고, 빠르게 출시하고, 실험을 돌리고, 반복한다. PostHog의 회고가 결국 강조하는 것도 이 한 줄이다.

AI라고 해서 사용자가 자동으로 가치를 찾아주지 않는다.

같은 시기, 산업 전반의 AI 에이전트 도입 사례를 풍부하게 다룬 500개 AI 에이전트 프로젝트로 본 산업 혁신 실전 가이드도 함께 읽으면, AI 제품 개발 전략의 큰 지도가 더 또렷해진다. 같은 패턴을 다른 업종이 어떻게 변형해 적용했는지 한눈에 보인다.

오늘 한 가지만 바꾸자. 만들고 있는 AI 기능 후보 옆에 “사용자가 하루에 몇 번 하는 작업인가”를 적어보자. 답이 0회나 1회라면, 그 기능은 보류하는 게 옳다. 진짜 가치는 100번 반복되는 작업의 경계에서 만들어진다.

참고 자료

PostHog Newsletter, “What we’ve learned about building AI-powered features”
Anthropic, “Building Effective AI Agents”
PostHog AI Docs, “Your copilot for PostHog data and insights”
AWS Machine Learning Blog, “Evaluating AI agents: Real-world lessons from building agentic systems at Amazon”
Datadog, “Building an LLM evaluation framework: best practices”
Blockchain Council, “Reducing AI Hallucination in Production: RAG, Guardrails, Evaluation, HITL”