Ep.29 | 느리고 비싼 AI를 서비스로 만드는 법

정확한 AI 답변도 너무 늦게 오면 쓰이지 않습니다. 상담원의 12초를 따라가며 지연·비용·품질을 실제 사용자 결과로 바꾸는 순서를 살펴봅니다.
Loopers _'s avatar
Oct 23, 2026
Ep.29 | 느리고 비싼 AI를 서비스로 만드는 법

🧑🏻‍💻 Ep.29 | 느리고 비싼 AI를 서비스로 만드는 법

시범 운영 첫날, AI 답변 품질은 기대보다 좋았습니다. 그런데 상담원 화면을 녹화해보니 이상한 장면이 반복됐어요. 질문을 연 뒤 3초. 아무 변화가 없습니다. 7초. 로딩 아이콘만 돕니다. 12초가 되자 상담원은 기다리기를 포기하고 직접 답을 쓰기 시작했습니다. 그 직후 AI 답변이 도착했지만 이미 필요 없었습니다. 서버 기록에는 성공 요청으로 남았습니다. 사용자 입장에서는 실패였고요.
☑️
정확한 답이 도착했다는 사실과, 일하는 순간에 쓸 수 있었다는 사실은 다릅니다.
※ 이 글의 상담 흐름과 시간은 지연·비용 패턴을 설명하기 위해 재구성한 가상 사례입니다.

1. 평균 6초가 숨기는 것

팀 대시보드의 평균 응답 시간은 6초였습니다. 나쁘지 않아 보였습니다. 하지만 빠른 질문은 2초, 복잡한 질문은 12~18초가 걸렸고 상담원이 포기한 건 늘 뒤쪽 요청이었습니다. 평균만 보면 오래 기다린 사람의 경험이 지워집니다. 전체 분포와 상위 지연 구간을 보고, 무엇보다 사용자가 실제로 몇 초 뒤에 다른 행동을 하는지 봐야 합니다. 기능마다 기다림의 허용치도 다릅니다. 문서 요약은 몇 초 기다릴 수 있지만 입력 중 자동완성은 1초만 늦어도 흐름을 끊습니다. 고액 환불 검토는 더 느려도 정확성과 근거가 우선이고요. “AI 응답은 5초 이내” 같은 하나의 목표보다, 첫 반응과 최종 완료를 나눠 보는 편이 유용합니다. 1초 안에 질문을 이해했다는 신호를 주고, 근거를 찾는 중임을 보여주며, 최종 답은 업무가 멈추기 전까지 내놓는 식입니다.

2. 12초 동안 무슨 일이 있었나

팀은 느린 요청 하나를 단계별로 펼쳐봅니다. 주문 조회 400ms, 정책 검색 1.8초, 관련 없는 문서까지 다시 정렬하는 데 2.2초, 긴 프롬프트 전송과 첫 문장 생성에 5초, 나머지 문장 생성에 3초가 걸렸습니다. “모델이 느리다”는 한 문장 안에 서로 다른 병목이 숨어 있었어요. 모델만 더 빠른 것으로 바꾸기 전에 필요 없는 일을 줄일 수 있습니다. 질문에 상관없는 정책집 전체를 보내지 않고, 주문 조회와 문서 검색을 안전한 범위에서 함께 시작하고, 답변에 쓰지 않는 긴 대화 기록을 덜어냅니다. 각 단계의 시간을 따로 보지 않으면 최적화도 감으로 하게 됩니다. 모델을 바꿨는데 검색이 느린 채로 남거나, 토큰을 줄였지만 잘못된 문서가 들어가 재질문이 늘 수 있습니다.
💡 가장 비싼 단계가 아니라, 사용자의 기다림을 실제로 만드는 단계를 찾아야 합니다.

3. 비용은 답변 한 번에서 끝나지 않는다

처음에는 요청당 토큰 비용을 계산했습니다. 작은 모델이 절반쯤 저렴했어요. 그런데 한 달 뒤 전체 비용은 기대만큼 줄지 않았습니다. 작은 모델은 복합 주문에서 필요한 조건을 자주 놓쳤고, 상담원이 질문을 다시 보내거나 답을 크게 고쳤습니다. 한 문의를 해결하는 호출 수가 늘었고 재문의도 생겼습니다. 싼 답변을 여러 번 사는 구조가 된 겁니다. 그래서 계산 단위를 바꿔봅니다.
“AI 답변 한 번에 얼마인가?”가 아니라 “사용자 문제 하나를 해결하는 데 얼마가 들었는가?”
여기에는 모델 비용뿐 아니라 검색, 재시도, 상담원 수정 시간, 잘못된 안내 뒤의 보상까지 들어갑니다. 반대로 비싼 모델이 한 번에 해결해 상담 시간을 줄였다면 전체로는 더 쌀 수 있습니다. 정확도와 비용을 따로 최적화하면 이런 관계가 보이지 않습니다. 제품의 끝인 ‘해결’까지 함께 봐야 합니다.

4. 모든 질문을 같은 길로 보내지 않는다

배송 상태 분류와 복합 환불 판단은 필요한 능력이 다릅니다. 전자에는 작고 빠른 모델과 짧은 컨텍스트가 충분할 수 있습니다. 후자는 더 강한 모델, 최신 정책, 사람 검토가 필요할 수 있고요. 질문을 난이도와 위험에 따라 다른 경로로 보내는 방식을 라우팅이라고 부릅니다. 잘 쓰면 속도와 비용을 크게 줄일 수 있습니다. 다만 라우터도 틀립니다. “포인트로 일부 결제한 묶음 주문의 부분 반품”을 단순 상태 조회로 분류하면, 빠르고 싼 경로가 자신 있게 잘못 답할 수 있습니다. 그러니 모델별 품질만 평가하지 말고 어떤 질문이 어떤 경로로 갔는지도 테스트해야 합니다. 애매한 요청은 싼 길로 억지로 보내기보다 안전한 쪽으로 올립니다. 라우팅 실패로 얻는 비용 절감보다 잘못된 실행의 비용이 큰 영역에서는 특히 그렇습니다.

5. 캐시와 스트리밍이 만능은 아니다

같은 답을 저장해두면 빠르고 저렴합니다. 하지만 AI 제품에서 무엇이 ‘같은 요청’인지는 생각보다 복잡합니다. 질문 문장이 같아도 주문 상태, 사용자 권한, 정책 버전이 다르면 답은 달라야 합니다. 오래된 반품 정책을 빠르게 돌려주는 캐시는 장애를 가속할 뿐입니다. 캐시 키에는 결과를 바꾸는 조건이 들어가야 하고, 정책이 바뀌면 무효화돼야 합니다. 개인 정보가 다른 사용자에게 섞이지 않는지도 봐야 하고요. 답을 한 글자씩 보여주는 스트리밍도 체감 속도를 높입니다. 다만 첫 문장이 나중 근거와 충돌할 수 있는 고위험 판단이라면, 완성 전 문장을 사용자에게 보내는 것이 오히려 위험합니다. 초안 작성에는 유용하지만 환불 확정 안내에는 검증 뒤 한 번에 보여주는 편이 나을 수 있습니다. 기술은 목적이 아니라 기다림을 줄이는 수단입니다. 어떤 기다림을 줄이고 어떤 위험을 늘리는지 같이 봅니다.

6. 사용자가 떠난 순간까지 측정한다

최적화 뒤 서버 응답은 12초에서 7초로 줄었습니다. 그런데 상담원은 여전히 6초쯤에 직접 작성하기 시작했습니다. 성공률은 올랐지만 제품 사용률은 그대로였어요. 그제야 화면에서 실제 행동을 봅니다. 로딩 중 다른 문의로 이동한 시점, AI 답을 기다리지 않고 입력한 시점, 도착한 답을 얼마나 고쳤는지 말이죠. 시스템 지표와 사용자 흐름을 잇자 목표가 분명해집니다. 간단한 질문은 3초 안에 완성하고, 복잡한 질문은 1초 안에 “주문과 정책을 확인 중”이라는 진행 상태를 보여줍니다. 오래 걸리면 상담원이 다른 일을 할 수 있도록 완료 알림을 주고요. 기다림을 없앨 수 없을 때는 기다리는 방식을 설계했습니다.
✅ AI 서비스의 성능은 모델이 초당 몇 토큰을 내는지가 아닙니다. 사용자가 흐름을 잃기 전에 쓸 수 있는 결과를 얻고, 그 결과로 문제를 다시 하지 않아도 되는가입니다.
느리고 비싼 AI를 제품으로 만드는 답은 늘 더 싼 모델에 있지 않았습니다. 불필요한 경로를 줄이고, 어려운 요청을 알아보고, 해결까지의 비용을 보며, 기다리는 사람에게 정직한 화면을 주는 데 있었습니다.

🌱 성능을 사용자 경험으로 연결하는 개발자들이 모인 곳, 루퍼스

지연과 비용은 인프라 숫자이면서 동시에 사용자의 경험입니다. 운영 지표를 실제 제품 가치로 연결하는 고민을 나누고 싶다면 루퍼스에서 함께해보세요
☑️
AI 시대에도 결국 중요한 건 생각하는 힘과 성장하는 환경이라고 믿습니다.
루퍼스에는 성장에 진심인 800+명의 크루가 함께하고 있습니다. 현업에서 부딪히는 고민과 경험을 나누며 함께 성장하는 크루들의 이야기. 전액 기부 강의 그리고 다양한 오프라인 네트워킹까지! 루퍼스는 개발자를 위한 지속 가능한 성장을 만들어 갑니다.
AI 시대에도 결국 중요한 건 생각하는 힘과 성장하는 환경이라고 믿습니다.
루퍼스에는 성장에 진심인 800+명의 크루가 함께하고 있습니다. 현업에서 부딪히는 고민과 경험을 나누며 함께 성장하는 크루들의 이야기. 전액 기부 강의 그리고 다양한 오프라인 네트워킹까지! 루퍼스는 개발자를 위한 지속 가능한 성장을 만들어 갑니다.

📢 LOOPERS의 소식이 궁금하다면?

Share article