AI-Powered 기능을 구축하며 배운 것들

(newsletter.posthog.com)

10P by neo 1일전 | ★ favorite | 댓글과 토론

PostHog가 12개월간 AI 기능 Max AI를 개발하며 얻은 실전 경험을 바탕으로, 올바른 기능 선택부터 구현, 개선까지의 전체 프로세스를 체계화한 가이드
AI 기능은 느리거나 신뢰할 수 없거나 무의미한 문제를 해결할 경우 제품을 오히려 악화시킬 수 있으며, 검증된 패턴(데이터 검색/요약, 생성기, 도구 사용)을 활용해야 함
구현 단계에서는 앱의 컨텍스트와 상태 관리가 핵심이며, 쿼리 계획과 조건부 라우팅으로 AI를 올바른 방향으로 유도하고, 모니터링과 가드레일로 실패에 대비할 것
속도 최적화를 위해 모델 벤치마크를 지속적으로 추적하고, 작업에 따라 빠른 모델과 느린 모델을 혼합 사용하며, 비동기 처리를 활용해야 함
지속적인 평가와 개선을 위해 초기 단계부터 eval을 추가하고, A/B 테스트를 실행하며, AI 지식의 사일로화를 방지하고 팀 전체에 AI 전문성을 분산시켜야 함

무엇을 구축할지 선택하기

AI가 제품을 악화시킬 수 있음을 인식하고, 너무 느리거나 신뢰할 수 없거나 누구도 신경 쓰지 않는 문제를 해결하는 잘못된 기능을 구축하지 않아야 함

1. AI가 잘하는 패턴 학습

검증된 AI 패턴을 복사하여 사용자에게 익숙한 UX 패턴과 AI가 실제로 잘하는 기능을 결합
- 첫 번째 패턴: "문서/데이터/PDF와 대화" - AI는 검색과 요약에 뛰어나며, 이를 활용해 보고서와 추천을 생성 (예: Intercom의 Fin, Mintlify의 문서 채팅)
- 두 번째 패턴: 다양한 종류의 생성기 - 제목, 코드, 문서, SQL, 이미지, 필터 등을 생성 (예: Lovable, Bolt.new, Figma, Rippling, Notion)
- 세 번째 패턴: 도구 사용 - AI가 잘 정의된 도구를 활용하여 워크플로우를 자동화하고 개선 (예: MCP 서버, Zapier, Atlassian, Asana)
PostHog의 Max AI는 여러 패턴을 활용
- 데이터 및 문서와 대화
- SQL 인사이트 및 필터 생성
- 설문조사 생성 및 분석 인사이트와 같은 도구 사용
- 향후 세션 레코딩 자동 시청 및 분석 등 도구 사용 확장 예정

2. AI가 해결할 수 있는 문제 식별

AI가 제공할 수 있는 가치에 초점을 맞춰 제품 전반에서 작업을 검토
- 30초 이상 걸리는 명확한 단일 작업 - 긴 양식 작성, 수동 데이터 입력, 통합 설정, SDK 설치 등
- 사용자가 이해하지 못하는 언어나 인터페이스 사용이 필요한 경우 - 복잡한 UI, SQL 쿼리, 앱 빌딩 등
- 20회 이상 반복하는 작업 - 설명 작성, 요약 작성, 항목 생성 등
incident.io의 Stephen Whitworth 조언: "AI가 할 수 있는 멋진 새로운 것"보다 "사용자가 하루에 100번 하는 일을 AI가 더 잘 만들 수 있는 것"에 집중
- 예시: 사용자는 자동 생성된 인시던트 요약을 직접 작성하는 것보다 훨씬 선호하며, 현재 75%의 인시던트 요약이 AI로 생성됨
PostHog의 적용 사례
- AI 설치 마법사: PostHog 설치 시간을 약 10분에서 90초로 단축
- Max AI의 SQL 번역: 복잡한 SQL 쿼리를 자연어로 쉽게 작성할 수 있게 하여 SQL에 익숙하지 않은 사용자도 맞춤형 인사이트 생성 가능

3. 문제가 구체적이고 가치 있는지 검증

구체적이고 가치 있는 문제로 범위를 좁혀야 함
피해야 할 함정
- 가치 없는 문제에 기존 패턴 적용: 초기 단계의 단순한 제품에 "문서와 대화" 기능은 불필요하며, 핵심 사용성 문제를 숨길 수 있음
- AI로 너무 큰 문제 해결 시도: AI는 10억 달러를 벌게 해줄 수 없으며, 먼저 좁은 문제를 해결한 후 확장하는 것이 좋음
Max 구축 시 "수익을 어떻게 늘릴까?"와 같은 너무 광범위한 질문은 효과적이지 않다는 것을 빠르게 인식
- 대신 PostHog에 통합되어 사용자의 PostHog 컨텍스트를 활용하는 구체적인 기능에 집중
- 예시: Max는 어떤 테이블을 사용할 수 있는지 알기 때문에 더 나은 SQL을 작성하고, 내장되어 사용 가능한 도구를 이해하므로 네이티브 시각화로 제품 질문에 답변 가능

아이디어 구현하기

구축하려는 것이 실제로 작동하는지 확인하기 위해 핵심 요소에 집중

4. 앱의 컨텍스트와 상태가 핵심

모든 사람이 OpenAI API를 호출할 수 있지만, 앱의 컨텍스트는 고유함
포함할 수 있는 데이터
- 사용자가 하려는 작업
- 누가 수행하는지
- 계정 상태
- 앱 내 위치
- 앱의 데이터 스키마
Max가 "지난주 가입이 감소한 이유"를 질문받을 때 API가 받는 정보
- 현재 페이지 (대시보드, 표시된 인사이트, 적용된 필터, 사용자 역할)
- 데이터 스키마 (사용 가능한 이벤트, 이벤트 속성, 사람 속성)
- 계정 (조직 티어, 시간대, 보존 기간)
코드 예시를 통한 UI 컨텍스트 포맷팅
- 대시보드 정보 (이름, 표시된 인사이트, 적용된 필터, 날짜 범위)
- 인사이트 정보 (이름, 쿼리 유형, 분석된 이벤트, 분류)
워크플로우 내 "컨텍스트"(상태) 처리도 필수
- 대화가 진행되면서 컨텍스트가 손실되지 않도록 해야 하며, 특히 여러 하위 에이전트가 있을 때 중요
- 모든 워크플로우 부분에서 컨텍스트를 저장하고 포함
컨텍스트 최적화와 모델 선택이 모델 미세 조정보다 효과적이고 유용함

5. 쿼리 계획과 조건부 라우팅으로 AI를 성공으로 유도

AI를 제한 없이 두면 온갖 예상치 못한 행동을 하므로 성공을 위한 안내가 필요
여러 단계를 오케스트레이션하고 연결하여 구현: 쿼리 계획 → 데이터 검색 → 시각화
상태 관리 외에 필요한 사항
- AI가 사용할 수 있는 도구와 데이터를 인식
- 의도된 작업에 따라 올바른 도구와 데이터 선택 가능
- 쿼리 실행 및 포맷팅과 같은 도구가 실제로 작동하는지 확인
PostHog의 최상위 수준 라우터 예시
- 인사이트 생성 여부 판단
- 문서 검색 여부 판단
- 청구 관련 여부 판단
각 라우터 노드는 작업에 필요한 올바른 데이터와 도구로 연결되는 자체 조건을 가짐
- AI가 작업 완료에 필요한 구성 요소를 갖추도록 보장하여 성공 가능성 향상

6. 모니터링, 가드레일, 오류 처리로 실패 대비

구축한 구조가 실패를 방지하지만, AI는 결국 가드레일에 부딪힐 것이므로 가드레일 제공 필수

모니터링

문제 발생 시점을 알기 위해 처음부터 모니터링 구현
Max AI 팀의 Georgiy 조언
- 프로덕션 트레이스 모니터링이 필수적
- 도그푸딩을 위한 모니터링 도구를 구축했으며, 처음부터 있었으면 좋았을 것
- 규모에서 트레이스를 모니터링하기가 더 어려워지므로 온라인 평가가 도움이 될 것 (다음 우선순위)
- 100개의 대화를 검토하는 것은 어렵고, 하루에 1,000개의 대화를 검토하는 것은 불가능
- 이러한 대화는 실제 사용자 질문과 어려움이며, 에이전트를 구축하는 데 필요한 모든 인사이트를 제공

환각 방지

AI가 환각할 수 있는 것은 모두 환각하므로, 직접 설정해야 하는 데이터와 따라야 할 규칙을 명시
AI 설치 마법사의 규칙 예시
- API 키를 절대 환각하지 말 것. 대신 .env 파일에 채워진 API 키를 항상 사용
- "// 실제 앱에서는..."와 같은 플레이스홀더 주석 추가 금지
- 기존 비즈니스 로직을 수정하거나 시뮬레이션 코드 추가 금지
- 이미 사용 중이지 않은 새 패키지나 라이브러리 임포트 금지
- 인증 라이브러리(Clerk, Auth.js 등)가 사용 가능하다고 가정 금지

사용자 가드레일

빈 텍스트 상자를 보면 사람들은 두려워하고 모든 것을 잊어버림
해결책: AI 기능 사용 방법에 대한 제안 추가, 올바른 방향으로 유도, 가능한 작업 상기

오류 처리

워크플로우가 때때로 중단되므로 재시도 및 속도 제한으로 우아하게 처리
고급 사용자를 위해 LLM 분석, 오류 추적, 기능 플래그 설정 가능
- PostHog는 세 가지 모두 제공 (편리한 우연의 일치)

기능 개선하기

AI 모델은 빠르고 예측 불가능하게 진화하므로, AI 기능은 예상보다 더 많은 유지보수와 지속적인 개선이 필요

7. AI 지식 사일로 방지

AI 기능 구축은 팀의 "AI 담당자" 한 명의 책임이 되어서는 안 됨
AI는 제품에 깊이 통합되어야 하며, 이는 사용자와 대화하고 그들을 위한 무언가를 구축하는 사람들의 전문성이 필요함을 의미
권장 방법
- 프리미티브 구축 및 AI 기능을 조합 가능하게 만들기: 팀이 프롬프트, 스트리밍, 동의, eval, 분석을 재발명할 필요가 없도록 하여 고유하고 부가가치 있는 AI 기능에 집중 가능
- 앱 전체에서 일관된 UX 패턴 유지: PostHog의 경우 Max가 해당하며, 수천 개의 AI 위젯으로 인한 혼란 방지
- AI 전문가를 팀에 일시적으로 배치: 팀이 AI 기능을 더 빠르게 구축하도록 돕고 조직 전체에 AI 지식 분산 (Max AI 팀이 수행)

8. 속도에 집중

AI 기능, 특히 복잡한 기능의 큰 과제 중 하나는 느림
워크플로우는 종종 LLM 제공업체에 대한 여러 호출을 의미할 수 있으며, 이는 많은 대기 시간으로 이어질 수 있음
앱이나 웹사이트에서 작업을 완료하는 대체 방법이 있을 때 특히 답답할 수 있음
Superhuman의 창립자 Rahul Vohra의 조언: "속도가 승리"
- 예시: Instant Reply 또는 Auto Summarize
- Gmail과 Outlook도 유사한 기능이 있지만 요청 시 답장과 요약을 생성해야 하며 완료될 때까지 기다려야 함
- Superhuman에서는 이를 사전 계산하여 항상 즉각적으로 제공되며, 이러한 단순한 차이가 사용자 경험에 엄청난 영향을 미침

개선 방법

모델 벤치마크와 새 모델 릴리스 인지: 더 나은, 더 빠른 모델이 출시되면 테스트하고 사용하여 기능과 속도 모두에서 가장 큰 향상을 얻을 수 있음 (LLM 분석 사용)
작업에 따라 빠른 모델과 느린 모델 혼합
- 제목 생성, 세션 재생 필터, 설문조사 요약, 인사이트 검색에는 빠른 모델 (gpt-4.1-mini, gpt-4.1-nano) 사용
- 스키마 생성, 대화 처리, 컨텍스트 관리에는 느린 모델 (gpt-4.1) 사용
비동기 처리 사용: 세션 요약 및 패턴 추출과 같은 복잡한 AI 작업은 Temporal 워크플로우를 통해 비동기적으로 실행되어 사용자 상호작용을 차단하지 않음. 이후 Redis에 캐시되어 재계산 없이 재시도 지원

9. 효과성을 지속적으로 모니터링하고 평가

새 기능이 ✨ AI ✨라는 이유만으로 덜 엄격하게 판단되어서는 안 됨
잘못된 아이디어는 제품을 악화시킬 수 있으며, 모델의 변화는 사용자 모르게 경험에 부정적인 영향을 미칠 수 있음

효과성 평가 방법

초기에 eval 추가: 작은 골든 또는 합성 데이터셋도 일반적인 개발 주기에 비해 엄청난 성능 향상 제공. 규모에서도 구현이 예상보다 쉬운 작업이었으며, 향후 기능 구축도 더 빠르게 만듦
A/B 테스트: AI 기능과 일반 경험 비교, 다양한 프롬프트, 컨텍스트, 워크플로우 등 테스트
다양한 고객 유형의 AI 사용률 확인 (예: 무료 사용자 vs 엔터프라이즈, 제품 vs 영업)
- 제품 관리자와 마케터가 이상적인 고객 프로필인 제품 엔지니어보다 Max를 더 자주 사용한다는 발견으로 로드맵 재고려
사용자가 AI 응답을 좋음/나쁨으로 평가하도록 허용: 사용자가 응답을 나쁘게 평가하면 추가 세부 정보 요청하여 컨텍스트, 프롬프트, 워크플로우 조정에 활용
AI vs 비AI 사용 비교: 기존 활성화 및 유지 지표를 사용하여 AI가 제품과 사용자 라이프사이클에 이상적으로 맞는 위치와 긍정적인 영향 여부 이해

마무리

이 9가지 교훈은 독립적인 것들이 아니라 함께 작동함
끝으로 건너뛰어 eval 최적화 = 훌륭한 제품 구축이라고 생각하는 것은 실수
사용자에게 가치 있는 것을 구축하는 것이 목표이지 화려한 기술 데모가 아님
AI라고 해서 사용자가 가치를 찾을 것이라는 의미는 아님
훌륭한 제품 구축에 대해 배운 모든 교훈이 여전히 적용됨
- 사용자와 대화
- 빠르게 출시
- 실험 실행
- 반복