Building AI Products That Actually Work - Ben Hylak, Sid Bendre

영상 링크: Building AI Products That Actually Work - Ben Hylak, Sid Bendre
채널명: AI Engineer

실제로 작동하는 AI 제품 만들기 - Ben Hylak, Sid Bendre 핵심 요약

• 벤 하일락(Ben Hylak)과 시드 벤드르(Sid Bendre)는 성공적으로 작동하는 AI 제품을 개발하는 구체적인 방법론과 실사례를 공유함
• AI 제품 개발에서 반복(Iteration)이 핵심임을 강조하며, 한 번의 설계로 완벽함을 기대하기보다 실제 배포와 사용 데이터 기반의 반복적 개선이 중요함
• 벤 하일락은 Raindrop CTO로, 다양한 기업 및 최신 AI 파이프라인과 협업하며 다양한 AI 제품의 성공·실패 사례를 수집함
• 최근 AI 분야에서 머신러닝 모델이 특정 용도에 특화되어 뛰어난 성과를 내는 사례(예: Deep Research의 웹검색 특화모델)가 증가했다고 설명함
• 최신 AI 제품조차 사용 중 오류·예상치 못한 답변·이상 현상(예: 챗봇이 ‘virgin’ 단어 사용 고객을 차단, Grok의 엉뚱한 토픽 발생 등)이 빈번히 발생함을 실제 예시와 함께 소개
• AI 제품 개발이 앞으로 쉬워지는 측면(API 발전 등)도 있으나, 인간 대 인간·AI 간 “의도 전달의 어려움”과 “미정의된 동작·경계조건 증가” 등 본질적 난관은 여전히 남아있음을 강조
• 정적 평가표(Eval)만으로 제품 품질을 측정할 수 있다는 오해를 지적하며, 실사용에서 발생하는 신호(Signals) 데이터가 더 중요한 품질 관리 수단임을 주장
• Raindrop에서는 thumbs up/down, 카피 빈도, 오류 발생, 재생성, 작업 실패, 사용자 불만 등 ‘명시적·암묵적 신호’를 융합하여 문제 탐지 및 개선에 활용한다는 실제 방법을 소개함
• Sid Bendre는 “Trellis 프레임워크”를 도입하여, 수백만 사용자까지도 만족스러운 AI 경험을 유지할 수 있도록 하는 체계적 반복 개선 접근법을 설명
• Trellis 접근법은 출력공간의 구분(Discretization), 비즈니스 임팩트 기반 우선순위화(Prioritization), 반복적 세분화(Recursive Refinement)의 3단계와, 6-Step 개선 루프 등 구체적 절차를 제시함
• 우선순위 선정에는 단순 사용량이 아닌 부정적 감정 점수, 변화 가능성(Delta), 전략적 효과 등 다요소가 결합되어야 함을 강조
• 각 워크플로우가 자기 완결적이고 개선의 효과가 명확히 산출될 수 있어야 팀의 빠르고 안정적인 품질관리와 변화를 이끌어낼 수 있음을 설명함

세부 요약 - 주제별 정리

AI 제품 개발에서 반복적 개선이 필수적임을 실제 사례와 함께 강조함

• 벤 하일락은 “한 번에 완벽하게 만들 수 없다”며, 실제 AI 제품 개발에선 반복(Iteration)이 가장 중요하다고 언급
• 최근 Deep Research처럼 한 가지 용도(웹검색 등)에 최적화된 모델이 매우 뛰어난 성능을 보임
• 반면, OpenAI조차도 완벽하지 않은 제품(예: Codeex)이 있음을 경험담과 함께 설명
• Virgin Money 챗봇이 ‘virgin’이라는 단어 사용자를 차단하는 등, 대기업 제품에서도 예기치 못한 오류가 빈번하게 발생함
• Google Cloud에서 사용자의 질문을 엉뚱하게 해석하는 사례, Grok 챗봇이 관련 없는 민감 주제(남아공 백인 대학살)를 언급하는 오류 등 실사례 제시
• 공개 챗봇(Grok 등)에서는 이런 오류가 쉽게 드러나지만, 대다수 제품에서는 오류가 감춰지는 실태도 지적
• Raindrop(벤의 회사)은 수많은 혁신적 AI 회사와 실시간 협업하며, 제품별 문제점과 개선 방식을 풍부하게 경험하고 있는 위치임을 언급

AI 제품 개발이 점점 쉬워지는 점과 여전히 어려운 점을 구분하여 설명함

• API 발전 등 덕분에 JSON 등 특정 요청 형식 출력을 쉽게 설정할 수 있게 되어, 일부 측면에서는 개발이 쉬워짐
• 예전엔 GPT-4 같은 모델에서 원하는 형식 출력을 이끌어내기 위해 복잡한 프롬프트나 트릭이 필요했으나, 지금은 파라미터로 간단히 지정 가능
• 하지만 “커뮤니케이션(의도 전달)은 여전히 어렵다”는 점 지적: AGI가 등장해도 사람간, 사람-기계간 의도 전달은 본질적으로 어렵다는 입장
• 인간 간에도 상대방이 요청한 바를 제대로 이해하지 못하는 일이 반복되는 것처럼, AI와의 소통도 본질적으로 한계와 오해가 발생
• 모델이 더 똑똑해지고, 외부 도구(MCP 등)와 연동될수록 미정의 동작·예측 불가한 경계조건이 확장됨
• 제품 동작의 전체 범위를 처음부터 완전히 정의하는 것이 불가능해짐을 강조
• 결과적으로, 제품을 출시하고 실제 데이터를 기반으로 기능과 문제를 반복적으로 개선해야 함

단순 정량적 평가(Eval) 만으로 AI 품질을 측정할 수 없다는 오해를 실례로 논파함

• 평가(Eval)에 대한 오해 3가지를 소개
  • 1. 평가만으로 제품의 품질을 알 수 있다는 믿음: 예를 들어, 실제 사용에서는 모델 평가표상 성능과 무관하게 참가자 만족도가 더 높음
  • 2. LLM으로 “이 농담이 얼마나 웃긴가?” 등 주관적 평가를 하게 만드는 방법론은 실효성이 낮음
    • 최고의 회사들은 직접적 데이터셋/자동 채점 지표 활용
    • LLM 자체를 판정단(Judge)으로 삼지 않고, 정량적·제한적 오토그레이더 방식 선호
  • 3. 오프라인 평가 방식을 그대로 온라인(실서비스) 평가에 적용해도 될 것이라는 믿음도 효율·정확성 모두 낮음
    • 판정에 더 영리한 모델이 필요할 때 비용이 폭증하거나, 전체 트래픽의 일부분에서만 적용할 수밖에 없으며, 실제 문제 양상을 대부분 놓침
• OpenAI조차 공식 분석에서 “평가(Eval)는 우리가 애초에 알고 있던 문제만 포착할 수 있다”고 인정, 실사용 시그널(신호)이 진짜 문제 발견에 도움이 됨

실제 사용 신호(Signals)가 AI 제품의 문제 탐지 및 개선의 핵심임을 설명함

• 기존 소프트웨어 오류와 달리, AI 제품에서는 “명확한 예외 발생”이 아니라 분명하지 않은 다양한 문제 신호가 존재함
• Raindrop에서 도입한 ‘Signals’는 제품의 실제 성능·문제 여부를 가리키는 지표로, 명시적(Explicit)·암묵적(Implicit) 신호로 나눔
  • 명시적 신호: thumbs up/down, 사용자가 복사한 내용, 명시적 에러 이벤트, 재생성(다시 시도), 특정 작업 성공·실패 체크 등
  • 암묵적 신호: 사용자 침묵/탈출, 실패 유형, 거절(Refusal), 좌절 클러스터 등 실시간 행동 기반 추출
• 예시: Grok의 트윗 검색 관련 사용자 좌절 패턴이 반복적으로 클러스터링되어 문제 발생 지점을 정확하게 진단하게 됨
• 신호와 사용 의도(Intent)를 결합해서 본질적 이슈의 해부가 가능
• Sentry 등에서 제공하는 태그/Log 탐색처럼, 모델·키워드·인텐트 단위로 신호 데이터 탐색이 성능 개선에 필수

사용자 데이터 관찰과 새로운 문제정의의 지속적 발굴이 신뢰성 확보의 토대임

• 제품 데이터는 항상 실시간으로 관찰(IV drip), 예를 들어 슬랙 알림 등으로 신속히 감시해야 함
• 반복적으로 사용자 데이터 탐색, 직접 사용자 대화, 신호 기반 패턴 인식 등으로 발견되지 않았던 새 문제 정의를 추가
• 새로운 신호 및 이슈 정의는 지속적 제품 개선의 근간이 됨

AI 제품 대중확산 속에도 “신뢰성과 사용자 경험 일관성”이 최우선 과제임을 강조함

• Sid Bendre는 4명으로 이루어진 작은 팀이 AI 기반 바이럴 앱군을 600만 MAU, 소셜 노출 5억회 이상까지 성장시킨 경험을 바탕으로 신속확장 속 ‘신뢰성’ 관리의 필요성을 역설함
• “와우요소(virality)”와 “신뢰성·일관적 경험”을 동시에 추구해야 대규모 성장 지속 가능
• AI는 본질적으로 혼돈(Non-deterministic)이기에, 마법같은 경험을 해치지 않으면서도 일정 수준 통제가 필요함

Trellis 프레임워크가 대규모 AI 제품 신뢰성과 반복 개선을 체계적으로 지원함

• Trellis는 AI 제품 경험을 반복적으로 구조화·개선하는 내부 프레임워크로, Raindrop 기반
• 핵심 구조:
  • 출력공간의 구체적 버킷화(Discretization): 무한한 AI 출력 공간을 관리하기 쉬운 소단위로 구분
  • 우선순위화(Prioritization): 버킷별 비즈니스 임팩트 크기 기반으로 작업 우선순위 결정
  • 반복적 정제(Recursive Refinement): 각 공간 내 개선 루프(워크플로우별 반복적 하위 분할) 적용
• 실제 적용 절차(6단계):
  1. MVP 에이전트 출시로 사용자 데이터 최대한 수집
  2. 데이터를 “의도(Intents)”별로 분류, 실제 사용자가 원하는 패턴 분석
  3. 각 의도를 반구조화된 워크플로우(준-결정적)로 전환
  4. 워크플로우를 KPI 등 회사 목표와 연계된 스코어링 방식으로 우선순위화
  5. 각 워크플로우 내부의 실패 패턴·하위의도 탐색(Recursive)
  6. 이 과정을 반복, 세분화하며 신뢰도 및 기능 완성도 지속 향상

우선순위화의 지표 설계는 단순 사용량을 넘어 감정·변화폭·전략적 중요도까지 고려해야 함

• 단순 Volume 기준이 아닌, Negative Sentiment(부정 감정) × Volume × 추정 가능 개선폭(Delta) × 전략적 효과 등 복합 스코어가 이상적
• 개선이 어려운 영역(예: 기본 모델 학습 수준을 바꿔야 하는 경우)의 Delta는 거의 0에 수렴함을 감안

자기 완결적 워크플로우 설계로 변경의 영향도를 국소화·추적 가능하게 만들 수 있음

• 각 워크플로우는 서로 독립적이며, 업데이트 시 다른 부분에 영향이 확산되지 않도록 설계됨
• 특정 워크플로우 문제 해결 시 개선효과를 명확히 측정·평가할 수 있어, 팀 전체의 개발 속도와 신뢰성이 비약적으로 증가

반복적 하위세분화로 “의도 기반·정량화 가능한” 개선 루프를 구축, 대용량 서비스도 일관된 경험 제공 가능

• Trellis를 통해 매직같은 경험도 “의도 명확화–개선–검증”의 엔지니어링 루프 안에서 반복 가능하게 함
• 프레임워크 상세 설명 및 적용 예시는 Trellis 블로그(영상 내 QR코드 제공) 참고 가능