Building AI Products That Actually Work - Ben Hylak (Raindrop), Sid Bendre (Oleve)

영상 링크: Building AI Products That Actually Work — Ben Hylak (Raindrop), Sid Bendre (Oleve)
채널명: AI Engineer

실제로 작동하는 AI 제품 만들기 — Ben Hylak(Raindrop), Sid Bendre(Oleve) 핵심 요약

• 이 영상은 Raindrop의 CTO Ben Hylak과 Oleve의 공동 창업자 Sid Bendre가 실제로 효과적으로 작동하는 AI 제품을 어떻게 만들 수 있는지 공유하는 대담의 형태로 진행됨
• 최근 AI 제품 개발에서 가장 중요한 과제로 ‘반복적 개선(iteration)’의 중요성이 강조되며, 초기 완벽한 설계가 아닌, 실사용과 피드백을 통한 지속적 향상 필요성을 주장함
• 대형 기술 기업(OpenAI, Google 등)의 AI 제품 출시에도 여전히 다수의 예기치 못한 버그와 사용자 불만 사례가 실제로 빈번하게 발생함을 데이터와 예시(예: Virgin Money 챗봇, Grok의 이상응답)로 설명함
• AI 제품 개발이 향후 쉬워질 것이란 관점과 어려울 것이란 관점이 공존하며, 특히 사용자의 의도를 AI가 정확히 이해하고 소통하는 부분이 복잡하고 본질적으로 어렵다는 점을 강조함
• 기존의 평가(eval) 기법(성능 벤치마크 등)은 실제 제품의 품질을 완벽히 반영하지 못함을 지적하며, 오히려 실사용 데이터와 실제 사용자 반응(신호, signal)을 집중적으로 분석해야 함을 주장함
• Raindrop에서는 ‘명시적 신호(예: thumbs up/down, 복사 등)’와 ‘암묵적 신호(예: 거절, 사용자의 실망 등)’를 구분하며, 앱의 성능과 결함 탐지를 위해 다양한 신호 분석 체계를 도입함
• Sid Bendre는 바이럴 앱을 수백만 MAU로 스케일하며, 일관성 있고 만족스러운 AI 경험을 확장할 수 있었던 자체 프레임워크 ‘Trellis’를 소개함
• Trellis는 무한한 AI 출력 결과를 ‘버킷’으로 나누고, 영향력 기준으로 우선순위를 매기며, 반복적으로 세분화·개선하는 6단계 체계적 과정임
• 지속적인 신호 수집 및 트래킹, 문제점 정의, 사용자의 의도 파악, 워크플로 분할 및 강화, 효율적 우선순위 선정, 그리고 반복적 개선을 통해 ‘마법 같으면서도 일관된’ AI 경험을 의도적으로 만들어낼 수 있음을 강조
• 실질적으로 작동하는 AI 제품을 위해서는 ‘우연한 성공’이 아니라 ‘제조된, 검증 가능한 결과’가 필요하다는 점을 시사하며 강연을 마무리함

세부 요약 - 주제별 정리

반복적 개선이 실제로 작동하는 AI 제품 개발의 핵심임이 입증됨

• Ben Hylak은 ‘AI 제품이 실제로 작동하게 만드는 것’에서 가장 필수적인 요소로 반복적 개선(iteration)을 꼽음
• 최초 완벽한 설계(PRD 등)로 전체 동작을 정의하는 것이 불가능하며, 실사용 이후 결과를 바탕으로 지속적으로 제품을 고도화해야 함을 주장
• AI 제품에서는 예측하지 못한 행동 및 엣지 케이스가 빈번하게 등장, 실전 배포와 이후의 빠른 대처가 필수임
• 벤은 Raindrop과 고객사들의 다양한 프로젝트를 경험하면서 성공하는 제품의 공통점은 시행착오와 데이터를 통한 주기적 개선이라고 강조

실제 사용자 사례와 최근 AI 제품의 실패 사례 소개로 문제를 구체적으로 밝힘

• OpenAI, Google, Virgin Money, Grok 등 대형 기업의 AI 제품이 최근 실제 서비스 환경에서 경험한 버그 및 황당한 사례들을 열거
  • 예: Virgin Money 챗봇이 “virgin”이라는 단어 사용 고객을 부당하게 차단 위협
  • Google Cloud AI 챗봇이 이용자의 크레딧 문의에 엉뚱하게 Azure, Roblox 크레딧으로 잘못 응답
  • Grok은 전혀 무관한 논란(남아공 white genocide 등) 주제로 엉뚱하게 대화가 전개됨
• 이런 문제들은 단순한 기술 미성숙이 아니라 AI 시스템 특유의 비결정적, 컨텍스트 불충분 이해, 실제 사용자와 상호작용 간의 복합적 요인임을 실례로 보여줌

AI 제품 개발의 난이도는 향후 일부분 쉬워지겠지만, 의사소통 본질 문제로 인해 여전히 어렵다는 점이 강조됨

• API에서 포맷 요구, 출력 제약 등은 점점 더 쉬워지고 있음(예: JSON 스키마 직접 지정)
• 그러나 AGI(범용인공지능) 시대에도 ‘프롬프트 엔지니어링’ 등 의도와 목표의 정확한 전달 및 해석은 여전히 힘들 것임을 벤은 강조(폴 그레이엄의 주장과 반대)
• 신규 입사자 온보딩, 일상적 커뮤니케이션에서조차 인간간에도 오해가 빈번함을 비유적으로 설명
• 더욱이 기능이 많고, 외부 툴(MCP 등)과 연계될수록 미정의 행동, 예외, 포맷 다양성 등의 변수가 늘어나 복잡성 가중

기존 AI 평가 방식이 실질적 제품 품질을 완벽히 반영하지 못한다는 점이 수차례 반복되어 설명됨

• 모델 벤치마크, 기존 eval 점수가 실제 제품력과 상관관계가 약하다는 Goodhart’s law에 근거한 비판
  • 최근에 출시된 모델들이 eval 점수는 낮아도 실제 사용자의 만족도나 실전 성능이 훨씬 개선된 사례가 빈번
• “얼마나 웃긴가”, “콘텐츠의 품질”, “AI가 만든 답변이 적절한가” 등을 LM(언어모델) 자체로 평가하는 방식은 대체로 신뢰성 부족
  • 베스트 프랙티스는 인력이 직접 검수한 고품질 데이터셋이나 ‘자동 평가(Eval)’ 기준이 명확한 문제 중심
• 프로덕션 데이터 활용, 온라인 평가 전환 등도 비용, 정확성, 패턴 인지 한계로 비현실적임
  • OpenAI 사례: “eval은 우리가 이미 인지하고 있던 이슈만을 잡아낼 뿐, 실제 이상행동은 실서비스에서야 발견됨”

에러 대신 ‘신호’를 중심으로 AI 문제 진단이 필요함을 새로운 관점으로 제시함

• 전통 소프트웨어(CI, Sentry 등)는 구체적인 예외(에러) 정보를 자동으로 인지·처리하지만, AI 앱에서는 명확한 에러가 없음
• 실제로는 앱의 성능이나 결함을 파악하는 데 ‘신호(signal)’ 기반 분석이 효과적임을 실제 사례와 함께 설명
  • 신호: 사용자가 실제로 보이는 행동, 명시적 피드백, 데이터 속에 숨어있는 암묵적 반응 등
• Raindrop에서는 이를 ‘ground truthy indicator’(근거 있는 성능 지표)라고 명명하며 구조화

다양한 신호(명시적/암묵적)가 실제 AI 제품 진단과 개선에 어떻게 쓰이는지 구체적으로 제시됨

• 명시적 신호: thumbs up/down(피드백), 메시지 복사 빈도, 선호 응답(AB테스트), 에러/재실행/문법오류 등
  • ChatGPT도 ‘답변 복사 비율’을 주요 신호로 수집
• 암묵적 신호: 거절(Refusal), 태스크 실패, 사용자 이탈/불만 등 데이터를 통한 간접적 감지
• 신호들을 분류, 클러스터링, 트렌드 분석(예: Grok의 트윗 검색 관련 사용자 불만 집중 발생) 방식으로 핵심 이슈를 추출

신호 정의, 수집, 탐색, 세분화, 반복 개선의 전체 프로세스가 구체적으로 설명됨

• 신호 정의: 앱이 직접 전송하는 이벤트(명시적), 데이터 내 패턴에서 추출하는 암묵적 신호
• 신호 탐색: Sentry의 태그 탐색처럼, 신호·메타데이터·모델다운·키워드·인텐트 등을 다양한 각도에서 분석
• 반복적 패턴 찾기: 데이터 지속 관찰, 유저 대화, 새로운 결함 정의, 예기치 못한 이슈 발굴, 신호 기반 트래킹 구축
• 실제 Raindrop 사례: 모든 이벤트를 개별적으로 분석, Slack 알림 등 실시간 모니터링, 다양한 AI 파이프라인에서 실전 적용

AI 바이럴 제품의 성장과 경험 전달, 그리고 ‘Trellis’ 프레임워크 도입 배경이 상세히 공유됨

• Sid Bendre는 4명 소규모 팀으로 만든 AI 기반 컨슈머 앱 제품군을 600만 MAU, 누적 5억 뷰까지 성장시킨 경험 소개
• 성공적 AI 앱에 필요한 요소를 2가지로 정리: ‘와우 요소(바이럴성)’와 ‘신뢰감 있는 경험의 일관성’
• AI의 비결정성(예상불가 출력) 문제를, 완전한 통제가 아닌 ‘가이드’하는 체계로 해결해야 함을 강조
• Trellis 프레임워크는 이러한 반복적, 체계적 개선을 위해 개발됨

무한한 가능성을 갖는 AI 출력 결과를 조직적으로 다루는 ‘Trellis’의 6단계 과정이 소개됨

• Trellis의 3대 원칙:
  • Discretization(출력 공간을 특정 버킷으로 분할)
  • Prioritization(비즈니스 임팩트 기준 우선순위 매김)
  • Recursive Refinement(각 버킷 내 반복 세분화 및 개선)
• 실제 Trellis의 6단계 프로세스:
  1. 최소기능 MVP 에이전트 론칭 및 대규모 사용자 데이터 수집
  2. 실제 사용 패턴에 따라 의도(Intent) 분류 및 파악
  3. 의도를 세미-결정적 워크플로로 전환(유연하면서도 신뢰성 있는 반복 경로 구축)
  4. 워크플로의 우선순위를 KPI 기반으로 선정
  5. 각 워크플로 내 실패 패턴, 하위 의도 분석
  6. 모든 과정 내에서 재귀적 반복(진화적 구조, 지속 개선)
• 더 나은 워크플로우 우선순위 산정법: 단순 사용량(Volume)보다는 Negative Sentiment×Volume×Achievable Delta×전략적 연관성 등 복합적 고려 필요

Trellis 활용을 통해 효율적이고 예측 가능한 AI 개선 문화를 정착시킬 수 있음을 실제 사례로 설명함

• 각 워크플로에 ‘자기-귀속, 자기-검증, 자기-경계’ 특성을 적용해 팀의 민첩성 및 신뢰성 강화
• 부분 개선이 전체 시스템에 퍼지는 부작용 방지, 빠른 실험과 확장 가능
• 반복적 딥다이브 및 세분화로, ‘우연적인 마법’이 아니라 ‘의도된, 시험 및 속성 추적 가능한 마법적 경험’을 재현 가능

결론: 실제로 작동하는 AI 제품은 우연이 아닌 체계적이고 신호 기반의 반복적 개선으로 만들어짐

• 검증 가능한 신호 트래킹, 반복적 문제 분해 및 개선, KPI에 부합하는 선택적 투자, 사용자와의 지속적 소통이 성공의 필수 조건임을 강조
• AI 경험의 ‘마법’조차도 조직적이고 구조화된 과정을 통해 재현 가능하다는 점을 시사하며, 발표를 마무리함