프로덕션이 어려운 이유

Module 5는 실제 서비스(production)에 올린 RAG를 다룬다. 프로토타이핑 때와는 다른 부담이 생기고, 필요한 기술도 달라진다. 첫 편은 시스템이 실제 고객의 손에 들어갔을 때 마주치는 새로운 문제들을 정리한다.

 

 

1. 확장(Scaling)에서 오는 부담

첫 문제는 단순히 트래픽이 늘면서 생긴다. 사용자가 많아지면 동시에 처리할 request 수와 request→응답 사이의 latency 양쪽에서 throughput에 제약이 생긴다. request가 많아지면 메모리·연산 사용량이 늘고 결국 비용도 오른다. 대규모에서 기본 시스템 성능을 유지하는 일 자체가 어렵다.

그림 1. 확장 부담 — 트래픽이 늘면 latency·메모리·연산·비용이 함께 오른다.

 

 

 

2. 프롬프트의 예측 불가능성

두 번째는 사용자가 보내는 프롬프트의 다양성과 예측 불가능성이다. 아무리 엄격히 테스트해도 시스템이 받을 모든 유형의 request를 예측하긴 어렵다. 출시 전 테스트에서 잘 됐어도, 새로운 요청 일부에서 시스템이 무너질 수 있다.

그림 2. 예측 불가능성 — 사용자는 창의적이고 예측 불가라서, 테스트에 없던 질문에 시스템이 흔들린다.

 

 

 

3. 지저분한 실제 데이터

또 다른 문제는 실제 데이터가 매우 지저분하다는 것이다. 데이터가 조각나 있거나, 형식이 나쁘거나, metadata가 빠진 경우가 흔하다. 게다가 많은 데이터가 텍스트가 아니라 이미지·PDF·슬라이드 형태다. 이런 데이터를 knowledge base에 넣으려면 접근(추출)할 방법이 필요하다.

그림 3. 지저분한 데이터 — 조각나거나 형식이 나쁘고, 상당수가 이미지·PDF·슬라이드에 담겨 있다.

 

 

4. 보안과 프라이버시

보안·프라이버시도 중요한 우려다. 많은 RAG가 애초에 knowledge base의 데이터가 비공개·독점이기 때문에 배포된다. 권한 있는 사용자는 접근하게 하면서도 데이터를 비공개로 유지하는 것이 핵심 기능이다("private by design").

그림 4. 보안·프라이버시 — 권한 있는 사용자만 접근하도록 하면서 데이터를 비공개로 지킨다.

 

 

 

5. 실수의 실제 비용 — "Eat Rocks" 사례

이 모든 문제에 더해, production의 가장 큰 위험은 실수가 금전적·평판상 실제 타격이 된다는 것이다. Google이 AI 검색 요약을 처음 냈을 때, 어떤 프롬프트에 "영양을 위해 돌을 먹으라"고 답한 일이 있었다. 원인을 보니 사용자가 "돌을 얼마나 먹어야 하나요?"라고 물었고 — 어리석고 예측하기 힘든 질문이었다 — 시스템이 검색한 기사·포럼 글 상당수가 농담이었는데 그 사실을 인식하지 못한 것이었다. Google은 이후 수정하고 원인을 설명하는 블로그 글까지 냈다.

그림 5. "Eat Rocks" 사례 — 검색 소스가 농담임을 인식하지 못해 잘못된 답을 냈다. production 실수는 비싸다.

 

 

6. 그 밖의 실패 사례

Google만이 아니다. 항공사 챗봇은 선의의 고객에게 실제로 없는 할인을 약속했고, 악의적 사용자는 RAG를 속여 제품을 공짜로 사거나 비밀 정보를 캐내려 한다. production은 RAG가 작동하기에 그 자체로 어려운 환경이다.

그림 6. 다른 실패 사례 — 없는 할인 약속, 악의적 악용 등. 여러 산업에서 반복된다.

 

그래서 필요한 것. ① 문제가 생기기 전에 예측하고 ② 생겼을 때 추적하며 ③ 변경이 실제 개선으로 이어지는지 검증하는 시스템을 갖추는 것이 핵심이다. Module 5는 이를 위한 기법들 — 관측성(observability)·평가·최적화·보안·멀티모달 — 을 하나씩 다룬다.

 

다음 글에서는 그 첫 단계 — RAG를 정량적으로 재는 평가 전략(evaluation strategies) — 을 다룬다.