Practical tactics to build reliable AI apps - Dmitry Kuchin, Multinear

영상 링크: Practical tactics to build reliable AI apps — Dmitry Kuchin, Multinear
채널명: AI Engineer

신뢰할 수 있는 AI 애플리케이션을 구축하는 실질적 전략 핵심 요약

• 발표자는 15년간 스타트업 공동창업자 및 CTO로 다양한 경험을 쌓았고, 최근 몇 년간 여러 기업에 생산 단계 AI 솔루션을 실제로 구축한 경험을 바탕으로 신뢰성 있는 AI 앱 개발 전략을 제시함
• 일반적인 소프트웨어 개발 생명주기(설계-개발-테스트-배포)와 달리, AI 기반 POC(Proof of Concept)는 처음 50% 성공은 쉽지만, 나머지 50%의 신뢰성 확보가 매우 어려움
• 모델의 비결정적 성질 때문에 지속적 실험과 데이터 사이언스적 접근이 필수적이며, 구성요소(프롬프트, 모델, 데이터 등) 중 하나라도 변경되면 예상치 못한 영향을 미칠 수 있음
• 일반적으로 활용되는 데이터 사이언스 지표(팩추얼리티, 편향 등)만으로는 실제 제품/비즈니스 요구를 제대로 반영할 수 없으며, 사용자 관점이나 사업 목표에 직접 연결되는 구체적 평가지표가 필요함
• 예시로 ‘고객지원 챗봇’ 프로젝트에서는 팩추얼리티 측정이 아닌 ‘AI가 해결하지 못해 인간 상담원으로 이관되는 비율’이 핵심 성과지표임을 밝혀냄
• 효과적인 평가는 실제 시나리오를 바탕으로, FAQ 등 자료의 각 항목별로 사용자가 궁금해 할 질문과 필요한 정보 체크리스트를 도출하여 다수의 체크리스트 기반 eval(평가) 항목을 생성하는 방식이 중요
• 평가 시 ‘평균 점수’보다는 각 케이스별 구체적 실패 원인을 추적해, 프롬프트/로직/모델/데이터 단위로 실험적 반복 개선 필요
• 실험 과정에서 새로운 변경이 과거 정상작동하던 부분을 되돌릴(회귀) 수 있으므로 체계적 벤치마크 구축이 필수적임
• 솔루션 유형별(FAQ 챗봇, 텍스트-DB 변환, 분류기 등)로 평가 방법이 달라지며, 경우에 따라 LLM을 평가판정자로 쓰거나, 모의 데이터베이스, 분류기 등 다양한 방식의 정밀 평가체계를 구축해야 함
• 제시한 오픈소스 플랫폼(Multinear)은 이러한 평가 자동화에 활용 가능하며, 특정 벤더 종속 없이 원리 자체가 실전 전반에 적용 가능함

세부 요약 - 주제별 정리

경험 기반으로 도출한 신뢰할 수 있는 AI 앱 개발의 가장 큰 문제점 제시

• 발표자는 15년 이상의 스타트업 CTO 및 공동창업자 경력, 최근 수년간 생산 레벨의 제너레이티브 AI 솔루션 구현 경험을 바탕으로 강연 진행
• 다양한 기업과 협업하며 실제 AI 프로젝트 도입·출시 과정을 직접 경험
• 기존 소프트웨어와는 달리, AI 앱은 일정 수준 이상의 신뢰도 확보가 극히 어렵다는 점을 실감
• AI 엔지니어 관련 컨퍼런스에서도 정확한 적용 전략이 제대로 논의되지 않는 현실 지적

기존 소프트웨어 개발 방식의 한계와 AI에서 발생하는 특이점 정리

• 소프트웨어 개발은 설계→개발→테스트→배포의 표준 생명주기 따름
• AI POC 개발 역시 초기에는 프롬프트 하나로 50% 수준의 결과는 빠르게 내지만, 100% 신뢰성 확보는 매우 어렵다고 강조
• 언어모델은 본질적으로 비결정적(nondeterministic)이기 때문에 실험적 접근이 필수적이며, 복잡성이 매우 높음
• 프롬프트, 모델, 데이터 등 구성요소가 지속적으로 변화하며, 작은 변경도 전체 앱 품질에 미치는 영향이 큼

데이터 사이언스적 지표의 맹점과 제품·사업 관점의 평가지표 필요성 강조

• 현장에서 자주 등장하는 오류: ‘팩추얼리티’, ‘바이어스’ 등 데이터 사이언스 지표만 측정하고 실제 효용을 간과
• 예시: ‘고객지원 챗봇’ 설계 시 동료에게 “성공여부를 무엇으로 판단하냐” 물었더니 추상 지표만 언급
• 실제로는 ‘인간상담원 이관률’ 등 비즈니스에 직결되는 지표가 훨씬 본질적임을 경험에서 도출
• “팩추얼리티가 매우 높아도 사용자가 원하는 정답이 아닐 수 있다”는 점 강조

실제 사용자 시나리오를 바탕으로 역설계 방식의 평가항목 도출 전략 제안

• 효과적 평가는 실제 FAQ 등 문서로부터 역으로 ‘사용자 질문→필수 정보 체크리스트’로 평가지표를 도출하는 과정에서 출발
• 예시: 은행 FAQ 중 ‘비밀번호 재설정’ 안내에 ‘모바일 인증 필요’ 등 구체적 조건 명시됨
• 평가 기준은 사용자 질문별로, 답변에 꼭 들어가야 하는 정보를 구체적으로 설정
• 일부 정보라도 누락되면 ‘정답’이 아님을 명확히 함

LLM과 다양한 프롬프트/페르소나 실험을 통한 평가 자동화 방법 설명

• 오픈소스 플랫폼(Multinear) 예시: 동일 질문의 입력/출력, 체크리스트 기반 평가를 자동화
• LLM에 ‘정답 체크리스트’를 제시하여, 다양한 프롬프트/페르소나별 답변 변이를 생성하고 일관성 평가
• 질문을 50가지 이상 변형하여도 체크리스트 기준 충족 여부를 반복적으로 테스트
• 각 평가마다 ‘어떤 정보가 빠졌는지’ 등 구체적인 피드백을 얻음

평가(evaluation) 구축 순서와 실전적 반복 개선 프로세스 구체화

• 기존엔 개발 후 평가하는데, 본 방법론은 POC 초기에 테스트(evaluation)부터 구축함이 핵심
• 첫 PC 버전과 동시에 첫 평가기준 정의→실행→통과/실패 케이스 상세 분석→원인별 반복 개선
• 개선 과정에서 프롬프트, 모델, 로직, 데이터 등 다양한 방식을 실험하며 최적화 시도
• 통계상 성공률(평균값)에만 의존하지 않고, 각 테스트 케이스의 실패 원인에 집중

반복 실험 과정에서 발생하는 회귀(regression)에 대한 방어전략 소개

• 실험적 개선 중 새로운 변경이 과거 작동하던 항목을 되돌리는 문제(회귀)가 자주 발생함을 경험적으로 강조
• 체크리스트 기반 평가는 자동 회귀 테스트 기능을 제공, 과거와 비교 가능
• 신뢰도 있는 벤치마크(테스트셋) 확립이 유지보수 및 확장 과정에서 매우 중요함

유형별 AI 솔루션에 맞춘 맞춤형 평가 설계의 필요성과 적용 사례 공유

• FAQ/고객지원 챗봇: LLM을 판정자로 사용, 체크리스트 기반 심사
• 텍스트-to-SQL, 텍스트-to-그래프: 모의 DB, 스키마 및 예시 데이터로 정답 쿼리 결과 비교
• 콜센터 분류기: 간단한 라벨 매칭 방식 적용
• 각 사업 영역·기능별로 평가방식 자체가 달라야 함을 경험적으로 증명

가드레일(guardrail)·예외 상황 평가의 구성 방법 안내

• 답변이 나오면 안 되는 질문, 혹은 일부 질문은 ‘다른 방식’으로 응답되어야 하는 경우도 벤치마크에 포함
• FAQ에 없는 질문, 비상식적 질의 등도 따로 분류·테스트하도록 설계

구체적 평가 체계 구축이 빠른 실험·적은 회귀·설명가능성(Explainability)에 도움 줌을 강조

• 사용자 경험과 실제 목표(비즈니스 성과)에 맞는 평가 항목들이 핵심 지표가 되어야 함
• 빈번한 자동테스트가 예기치 않은 품질저하(회귀)를 줄여주며, 신속한 실험·검증이 가능
• 체계적 평가 기준은 수행 결과의 해설성(explainability)까지 크게 늘려줌
• 결과적으로 ‘무엇이 왜 잘/못되는지’를 명확히 알 수 있음

Multinear 오픈소스 플랫폼 활용 및 접근 방식의 범용성 안내

• 발표자가 만든 Multinear 오픈소스 플랫폼은 위 모든 평가지표·벤치마크 자동화에 활용 가능
• 특정 벤더 종속이 아니며, 방법론 자체 전체 피드백-실험-평가 사이클에 두루 적용 가능
• 발표자는 현재도 신뢰성 있는 AI 자동화 스타트업을 운영하며, 실제 현장에서 방법론을 검증·적용하는 중임