핵심 이슈: '잘 되는 것 같다'는 메트릭이 아닙니다
근거는 있나요? RAG 시스템을 배포하고 "응답 품질이 좋아 보인다"고 말하는 팀, 커스텀 CV 모델의 mAP가 98%라며 프로덕션을 서두르는 팀 — 이들에게 공통적으로 빠져 있는 것은 측정의 정직함입니다. 이번 주 dev.to에 올라온 세 편의 글이 정확히 이 지점을 관통합니다. EU 규제 컴플라이언스 RAG를 혼자 만든 개발자의 실전기, RAG의 Recall과 Precision을 진단하는 프레임워크, 그리고 냉장고 식재료 인식 CV 모델의 반복 학습 회고까지. 도메인은 다르지만 결론은 하나로 수렴합니다: 베이스라인 대비 얼마나 개선되었는지 모르면, 개선한 것이 아닙니다.
사례 1 — RAG에서 라우팅이 임베딩보다 중요한 이유
EU AI Act, DORA, GDPR 조문을 대상으로 RAG 파이프라인을 구축한 Gibs 프로젝트는 '정확도 79.9%'라는 냉정한 숫자에서 출발합니다. 흥미로운 건 병목이 임베딩도, LLM도 아닌 분류 라우팅(classification routing)이었다는 점입니다. "threat-led penetration testing RTS 요건"이라는 질의에 'DORA'라는 단어가 없으니, 분류기가 AI Act 컬렉션으로 질의를 보내버린 거죠. 키워드 패턴을 DORA, ICT risk, TLPT, delegated act 등으로 확장한 단일 변경만으로 정확도가 79.9% → 90.8%로 뛰었습니다. 11 percentage point 개선이 프롬프트 엔지니어링이 아니라 정규식 몇 줄에서 나왔다는 사실은, 우리가 최적화 레버를 얼마나 자주 잘못 짚는지 보여줍니다.
더 주목할 점은 평가 데이터셋(golden dataset) 설계입니다. 140개 질문에 answer_must_contain, sources_must_contain, should_abstain 필드를 붙여 자동 채점하는 구조인데, 이 eval runner가 case-sensitive 버그 하나로 3% 정확도 손실을 잡아냈습니다. 샘플 사이즈 140이 통계적으로 충분한가? 솔직히 카테고리별로 나누면 셀당 20~30개 수준이라 신뢰구간이 넓을 수 있습니다. 그러나 eval이 아예 없는 파이프라인 대비, 이 정도만으로도 blind tuning을 방지하는 효과는 압도적입니다. 특히 abstention accuracy 96.7% — 범위 밖 질문에 답을 지어내지 않는 능력 — 은 컴플라이언스 도메인에서 가장 중요한 지표입니다. 환각 한 번이면 신뢰가 영(zero)이 되니까요.
사례 2 — Recall-Precision 진단: 같은 증상, 다른 원인
OptyxStack의 RAG 진단 가이드는 'Top-k를 늘리면 되겠지'라는 가장 흔한 오답에 정면으로 반박합니다. 이 글이 제시하는 4단계 진단 흐름은 명확합니다: ① Ground Truth 정의 → ② Top-N 후보군에 정답 문서가 있는가(Candidate Recall) → ③ 실제 프롬프트에 전달되었는가(Selection Recall) → ④ 전달된 컨텍스트의 노이즈 비율(Precision). 같은 "나쁜 답변"이라도 원인이 임베딩 품질인지, 리랭커 로직인지, 컨텍스트 오염인지를 구분하지 않으면 최적화는 주사위 던지기입니다.
특히 진단 매트릭스가 실용적입니다 — Candidate Recall ↓이면 임베딩·청킹·하이브리드 검색을, Recall ↑ Precision ↓이면 컨텍스트 필터링·confidence threshold를, 둘 다 ↑이면 Generator 쪽 추론 오류를 의심하라는 것. 이건 Gibs 사례와도 정확히 맞물립니다. Gibs의 79.9% 문제는 이 매트릭스의 첫 번째 행(Retrieval failure)에 해당했고, 라우팅 수정으로 Candidate Recall 자체를 끌어올린 거죠. 이 correlation이 causation인지는 ablation study 없이 단정할 수 없지만, 단일 변수 변경 후 11pp 개선이라는 데이터는 상당히 설득력 있습니다.
사례 3 — CV 모델의 mAP 98%는 시험지 유출이었습니다
FridgeChef 프로젝트의 실험 기록은 데이터 분할(split)이 메트릭을 얼마나 왜곡하는지를 교과서적으로 보여줍니다. V1 모델의 train/valid/test 비율은 95/3/2. Validation set이 고작 103장이니 mAP@50 98.0%, Precision 97.3%, Recall 98.3%이라는 화려한 숫자가 나올 수밖에 없습니다. 저자 본인의 표현이 정확합니다: "시험 문제의 95%를 이미 본 상태에서 A+를 받은 것." V2에서 70/20/10으로 재분할하자 mAP는 98.0% → 92.6%로 떨어졌고, 이것이 더 정직한 숫자입니다.
그런데 진짜 현실 점검은 unseen 이미지 테스트에서 나옵니다. 학습·검증·테스트 어디에도 포함되지 않은 새 이미지 2장에서 Custom V1의 Annotation Accuracy는 38.6%, Detection Accuracy는 40.5%에 그쳤습니다. 아이러니하게도 zero-shot 모델인 YOLO-World이 59.3% / 60.4%로 오히려 우세했죠. 물론 샘플 사이즈 2장으로 통계적 유의성을 논하는 건 불가능합니다 — 저자 역시 이를 인정합니다. 하지만 이 결과가 시사하는 바는 분명합니다: validation mAP과 real-world 성능 사이의 괴리는 데이터 분포(distribution)의 차이에서 비롯되며, 이 gap을 측정하지 않으면 "프로덕션에서도 그 성능 나오나요?"라는 질문에 영원히 답할 수 없습니다.
세 사례의 교차점: 측정 가능한 신뢰의 조건
세 프로젝트를 관통하는 공통 패턴을 정리하면:
| 프로젝트 | 핵심 교훈 | 메트릭 전/후 |
|---|---|---|
| Gibs (RAG) | 라우팅 수정 하나가 임베딩 튜닝보다 효과적 | 정확도 79.9% → 90.8% |
| RAG 진단 프레임워크 | Recall/Precision을 구분하지 않으면 최적화는 추측 | 4단계 진단 매트릭스 제안 |
| FridgeChef (CV) | 데이터 분할이 메트릭의 정직함을 결정 | mAP 98.0% → 92.6%(재분할) |
세 사례 모두 "eval first" 원칙을 실패 후 깨달았다는 점도 흥미롭습니다. Gibs 저자는 "파이프라인을 먼저 만들고 eval을 나중에 붙였는데, 반대여야 했다"고 회고하고, FridgeChef 저자는 split 비율을 방치한 채 baseline을 잡은 것을 반성합니다.
전망: 프로덕션 신뢰성은 '지표 문화'에서 시작됩니다
여기에 한 가지 사례를 더 겹쳐 봅니다. SuperLocalMemory v2.7은 LightGBM 기반 적응형 리랭킹을 local에서 돌리며, 콜드스타트 문제를 synthetic bootstrap으로 해결한다고 주장합니다. 아키텍처는 흥미롭지만, 제가 던지고 싶은 질문은 역시 같습니다 — 리랭킹 전후의 MRR(Mean Reciprocal Rank)이나 nDCG 변화를 정량적으로 보여주나요? 논문 8편을 인용한 research-backed 설계라고 해도, 사용자 행동 데이터 기반 모델은 behavioral drift에 취약하고, 그 drift를 모니터링하는 메트릭이 없으면 "적응형"이라는 수식어는 마케팅에 가깝습니다.
RAG든 CV든 개인화 검색이든, 프로덕션 신뢰성의 출발점은 동일합니다: eval을 먼저 만들고, 베이스라인을 측정하고, 변경 하나마다 지표를 다시 확인하는 것. 이건 화려한 아키텍처가 아니라 pandas.DataFrame에 결과를 쌓는 지루한 작업입니다. 하지만 그 지루함이 없으면, 우리가 만드는 시스템의 '신뢰'는 사용자에게 전달되는 또 하나의 환각일 뿐입니다.