고객을 학살하는 '오버스펙' AI 모델을 만났을 때, 욕먹지 않고 서비스를 살려내는 3단계 튜닝법

얼마 전 유튜브에서 꽤 흥미로운 영상을 하나 봤습니다. 델타 항공 기내 엔터테인먼트 시스템에 탑재된 체스 게임이 승객들을 그야말로 '박살' 내고 있다는 내용이었습니다. 그랜드마스터급 실력자가 와도 이기기 힘들 정도로 난이도 조절에 실패한 이 봇을 보며, 사람들은 "인공지능의 반란"이라며 웃어넘깁니다. 하지만 저는 그 영상을 보며 웃을 수 없었습니다. 오히려 등골이 서늘해지는 기분을 느꼈습니다. 그 체스 봇은 우리 엔지니어들이 현업에서 저지르는 가장 흔하고 치명적인 실수를 적나라하게 보여주는 거울이었기 때문입니다. 바로 '사용자의 맥락을 무시한 성능 과잉'입니다.

솔직히 말해, 저도 과거에 비슷한 삽질을 한 적이 있습니다. 클로바 재직 시절, OCR 모델의 정확도를 0.1%라도 더 올리기 위해 밤새 파라미터를 튜닝하고 무거운 백본 네트워크를 갖다 붙인 적이 있습니다. 벤치마크 점수는 아름답게 올랐지만, 정작 서비스에 배포했을 때 사용자의 반응은 싸늘했습니다. 추론 속도가 너무 느려졌기 때문입니다. 사용자는 99.9%의 정확도를 가진 3초짜리 응답보다, 98%의 정확도라도 0.1초 만에 뜨는 응답을 원했습니다. 델타 항공의 체스 봇도 마찬가지일 겁니다. 비행기 안에서 심심풀이로 체스를 두는 승객은 알파고와 대결하고 싶은 게 아닙니다. 적당히 고민하고 적당히 이겨주는 '접대 바둑' 같은 경험을 원하죠. 그런데 엔지니어는 그저 "이 알고리즘이 최적의 수입니다"라며 계산된 결과를 던져버린 겁니다. 이건 기술의 승리가 아니라, UX(사용자 경험)의 참패입니다.

이런 상황은 최신 LLM(거대언어모델)을 도입하려는 스타트업 현장에서 비일비재하게 일어납니다. 며칠 전, 저희 회사 주니어 엔지니어가 간단한 고객 문의 분류 시스템에 최신형 고성능 LLM을 붙여왔더군요. 성능은 끝내줬습니다. 하지만 토큰당 비용과 레이턴시(지연 시간)를 계산해 보니, 이 기능 하나가 전체 인프라 비용의 30%를 잡아먹을 판이었습니다. "고객이 '환불해 주세요'라고 말하는 걸 이해하는 데 굳이 셰익스피어 전집을 학습한 모델이 필요합니까?"라고 물었을 때, 그 친구의 당황하던 표정이 잊히지 않네요. 우리는 종종 기술적 우월감에 취해 비즈니스의 본질인 '비용 대비 효용'을 망각합니다. 델타 항공의 체스 봇이 고성능 GPU 서버에서 돌아갈까요? 아닐 겁니다. 구닥다리 임베디드 칩 위에서 최소한의 리소스로 돌아가는 가벼운 알고리즘일 겁니다. 그런데도 사용자를 압살합니다. 이는 역설적으로, 모델의 크기나 최신 트렌드보다 중요한 건 '어떻게 서빙하느냐'라는 사실을 증명합니다.

그렇다면 이런 '오버스펙'의 함정에서 빠져나와 서비스를 살리려면 어떻게 해야 할까요? 첫째, '정확도(Accuracy)'가 아니라 '만족도(Satisfaction)'를 지표로 삼으세요.

체스 게임이라면 승률 50%를 유지하도록 봇이 일부러 실수하는 로직(Heuristic)을 넣어야 합니다. 추천 시스템이라면 무조건 클릭률이 높은 자극적인 콘텐츠만 띄우는 게 아니라, 사용자가 피로하지 않게 다양성을 섞어주는 로직이 필요합니다. 엔지니어링은 수학 문제를 푸는 게 아니라, 사람의 문제를 푸는 것입니다. 수치적 최적화가 서비스의 최적화를 보장하지 않습니다.

둘째, 무조건 가볍고 싼 모델부터 시작하세요.

엑셀로 처리할 수 있는 데이터에 RAG(검색 증강 생성)를 붙이지 마십시오. 정규식(Regex)이나 간단한 룰 베이스로 해결되는 문제에 딥러닝을 들이대지 마십시오. 델타 항공 체스 봇의 교훈은 "단순한 알고리즘도 충분히 강력하다"는 것입니다. 우리는 그 강력함을 제어하지 못해 사고를 칠 뿐이죠. 저는 항상 팀원들에게 "로지스틱 회귀로도 안 되면 그때 딥러닝을 꺼내라"고 강조합니다. 인프라 비용은 회사의 수명과 직결됩니다. 돈 벌지 못하고 리소스만 태우는 모델은 화려한 쓰레기일 뿐입니다.

마지막으로, '실패하는 시나리오'를 설계하세요.

델타 체스 봇이 욕을 먹는 이유는 '지는 법'을 배우지 못했기 때문입니다. AI 모델도 마찬가지입니다. 모델이 모르는 질문을 받았을 때, 엉뚱한 환각(Hallucination)을 내뱉으며 아는 척하는 것보다 "죄송합니다, 그 부분은 아직 잘 모르겠네요"라고 솔직하게 말하는 시스템을 설계하는 것이 훨씬 어렵고 중요합니다. 이를 위해선 단순히 모델 학습에만 매달릴 게 아니라, 후처리(Post-processing) 로직과 예외 처리에 더 많은 공을 들여야 합니다. 화려한 모델 뒤에 숨겨진 지루한 엔지니어링 작업들이 결국 서비스의 품질을 결정합니다. 기술은 도구일 뿐, 그것을 휘두르는 우리의 철학이 빈약하다면 그 결과물은 승객을 괴롭히는 체스 봇처럼 폭력적으로 변할 수 있습니다.