# AI-Powered 기능을 구축하며 배운 것들 > Clean Markdown view of GeekNews topic #23475. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=23475](https://news.hada.io/topic?id=23475) - GeekNews Markdown: [https://news.hada.io/topic/23475.md](https://news.hada.io/topic/23475.md) - Type: news - Author: [neo](https://news.hada.io/@neo) - Published: 2025-10-06T10:20:01+09:00 - Updated: 2025-10-06T10:20:01+09:00 - Original source: [newsletter.posthog.com](https://newsletter.posthog.com/p/what-weve-learned-about-building) - Points: 20 - Comments: 0 ## Summary PostHog팀이 **Max AI** 등 **AI 기능**을 12개월간 개발하며 얻은 인사이트를 통해, 의미 있는 **문제 정의**, 검증된 **UX·AI 패턴 활용**, 그리고 **앱 컨텍스트·상태 관리**의 중요성을 강조합니다. **속도 최적화**와 **비동기 처리**, 그리고 **모델 벤치마크**를 통한 성능 개선은 개발자 경험과 사용자 만족도를 크게 바꿀 수 있으며, **지속적인 효과 평가**와 **A/B 테스트**, 그리고 팀 내 **AI 지식 분산**을 통해 제품의 일관성과 혁신성을 동시에 추구해야 함을 보여줍니다. 결국 **사용자 가치와 제품 본질**에 집중하는 접근이 진정한 AI 활용의 핵심입니다. ## Topic Body - **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라고 해서 사용자가 가치를 찾을 것이라는 의미는 아님 - 훌륭한 제품 구축에 대해 배운 모든 교훈이 여전히 적용됨 - 사용자와 대화 - 빠르게 출시 - 실험 실행 - 반복 ## Comments _No public comments on this page._