AI 기능을 배포하는 개발자 유형은 딱 두 가지다
There are two types of developers shipping AI features
핵심 요약
AI 기능 배포 시 발생하는 예상치 못한 결과와 그에 따른 품질 관리의 중요성을 다룬 글.
- AI 배포 현실 — AI 기능 배포 시 언젠가는 반드시 불량 결과물을 마주하게 됨.
- 품질 관리 부재 — 사용자 신고에만 의존하는 피드백 루프는 매우 위험함.
- 평가 파이프라인 — 실제 사용 데이터를 기반으로 한 자동화된 평가 시스템 구축이 필수적임.
- 침묵의 실패 — 에러 로그 없이 잘못된 결과가 나오는 현상이 가장 치명적임.
오토바이 타는 사람들 사이에서 이런 말이 있다는 거 들어봤을 거다. '오토바이 타는 사람은 두 종류다. 이미 사고가 난 사람, 그리고 앞으로 사고가 날 사람.'
솔직히 AI 기능을 배포하는 사람들도 똑같다는 생각이 든다. 개판인 결과물을 내놓은 적이 있는 사람, 그리고 앞으로 내놓을 사람.
한동안 나는 내가 후자에 속한다고 꽤 자신했고, 불량 결과물을 막기 위한 좋은 관행들을 잘 갖췄다고 생각했다. 탄탄한 테스트 환경을 갖췄고, 내부 데모도 순조로웠으며 팀도 결과물에 만족했다. 우리는 순항 중이었다(미안, 더 이상 농담은 안 할게).
그런데 지난주에, 가볍게 말하는 게 아니라, 진짜 쓰레기 같은 응답이 담긴 스크린샷을 받았다. 김이 모락모락 나는 똥 수준이었달까... 뭐, 무슨 말인지 알겠지. 에러 로그는 하나도 없었고, 우리 쪽에서 뭔가 잘못됐다는 징후도 전혀 없었다. 이게 진짜 짜증 나는 게, '고장 났다'와 '사용자가 알아채고 신고한다' 사이의 안전장치가 전혀 없었다는 거다. 우리 피드백 루프는 말 그대로 사용자가 연락해주기만을 기다리는 수준이었다.
어쨌든. 그 이후로 문제를 해결했고, 몇 가지를 배웠으며, 실제로 사용자에게 전달되는 결과물에 대해 훨씬 더 건강한 수준의 편집증을 갖게 되었다.
그냥 푸념처럼 들렸다면 미안하다. 혹시 비슷한 상황에 처한 사람들이 있을까 봐 공유하고 싶었다. 이런 사건들이 결국 사람들에게 AI 품질을 진지하게 생각하게 만드는 계기가 되는 것 같다.


