숫자는 말한다, 하지만 전부 말하진 않는다
요즘 AI 발표 자료를 보면 공통점이 하나 있습니다. 퍼센트와 배수(倍數)가 넘쳐납니다. DeepSeek는 처리량 1.96배, RAG 엔지니어는 검색 정확도 25%p 상승, OCR 벤처는 분당 500장. 숫자 자체는 구체적이고 설득력 있어 보입니다. 하지만 ML 분석가로서 첫 번째로 드는 질문은 항상 같습니다. "이 숫자, 베이스라인은 뭔가요? 측정 조건은요?"
DeepSeek DualPath: 1.96배는 어떤 조건의 1.96배인가?
DeepSeek 팀이 공개한 논문에 따르면, 'DualPath' 시스템은 KV 캐시를 이중 경로(메모리 + 네트워크)로 분산 읽어 에이전트 워크로드의 처리량을 끌어올립니다. 오프라인 추론 1.87배, 온라인 서비스 초당 에이전트 실행 횟수 1.96배—수치 자체는 인상적입니다.
그런데 Ablation study 결과가 공개됐는지가 먼저 궁금합니다. 1.96배라는 수치가 단일 턴(single-turn) 대비인지, 수십~수백 회 상호작용이 발생하는 멀티턴 에이전트 워크로드 대비인지에 따라 실제 프로덕션 환경에서의 체감 개선은 전혀 달라집니다. 논문은 에이전트 워크로드가 '사람-모델-환경' 반복 구조로 진화했다고 정확히 짚고 있습니다. 기존 단일 턴 기준 벤치마크로는 이 개선을 제대로 포착할 수 없다는 뜻이기도 합니다. KV 캐시 최적화가 스토리지와 네트워크 부하를 재분배하는 방식이라면, 인프라 구성(특히 스토리지 I/O 대역폭)에 따라 성능 이득의 분산이 매우 클 수 있습니다. 실제 운영 환경에서도 이 수치가 재현되는지, 재현 가능성(reproducibility) 검증이 관건입니다.
RAG 하이브리드 검색: 60% → 85%, 샘플 사이즈가 충분한가요?
dev.to에 공개된 엔지니어링 사례는 솔직한 데이터를 제시합니다. 순수 벡터 검색(임베딩 + 코사인 유사도)에 BM25 키워드 매칭을 더한 하이브리드 검색으로 전환했더니 검색 정확도가 약 60%에서 약 85%로 올라갔다는 겁니다. Reciprocal Rank Fusion(RRF)으로 두 결과를 합산하는 방식이며, 두 리스트 모두에 등장하는 문서가 상위에 오르는 구조입니다.
하지만 여기서 통계적 의심을 제기하지 않을 수 없습니다. 테스트 셋이 50개 질문입니다. 25%p 개선이 통계적으로 유의미하려면 이 정도 샘플 사이즈는 아슬아슬합니다. 특히 개선 대부분이 약어(acronym)·전문 용어 쿼리에서 발생했다고 명시했는데, 이는 해당 코퍼스의 특성에 크게 의존합니다. 기술 문서 기반 QA라면 BM25 단독이 벡터 검색보다 우수할 수 있고, 자연어 중심 비즈니스 문서라면 벡터 검색이 더 강합니다. 이건 correlation이지 causation이 아닙니다—BM25 추가가 정확도를 올린 게 아니라, 이 데이터셋이 BM25에 친화적인 분포를 갖고 있을 가능성이 있습니다. 평가 셋을 최소 200개 이상으로 늘리고, 도메인별로 층화 샘플링(stratified sampling)을 적용해야 일반화 주장이 가능해집니다. 그럼에도 이 사례가 가치 있는 이유는 청크 사이즈, 임베딩 차원 축소(PCA/UMAP), 리랭커 레이턴시 트레이드오프까지 실측 데이터를 공개했다는 점입니다.
Text-to-SQL 벤치마크: GPT-4o가 58%라면, 현업은 어디쯤인가?
DySQL-Bench, BibSQL, DLBench—세 벤치마크는 공통된 문제의식을 공유합니다. 기존 Spider, BIRD 같은 테스트가 '완벽한 단일 쿼리'를 가정한 반면, 실제 사용자는 반복적으로 수정하며 데이터베이스와 상호작용한다는 것입니다.
DySQL-Bench의 1,072개 멀티턴 태스크에서 GPT-4o의 정확도는 58.34%, Pass@5(장기 일관성)는 23.81%에 불과했습니다. 이 수치는 냉정하게 봐야 합니다. 벤치마크의 50%가 UPDATE 연산으로 구성된 설계 자체가 이미 현재 LLM의 약점을 겨냥하고 있기 때문입니다. 반면 BibSQL의 96.6%는 도메인(중국어 학술 검색)과 파이프라인(PoT: Python pseudocode → SQL) 특화 덕분이라는 맥락을 함께 읽어야 합니다. 범용 모델을 특화 도메인에서 평가한 수치를 일반화하면 곤란합니다. SOTA 달성 발표에 항상 물어야 할 것: 어떤 데이터 분포에서, 어떤 평가 지표로?
사이냅 OCR IX: 분당 500장, 테스트 환경 상세가 열쇠다
사이냅소프트가 공개한 사이냅 OCR IX 성능 수치—GPU 11GB 1장, 동시 30건 요청, 분당 약 500장—는 프로덕션 관점에서 접근할 필요가 있습니다. KVT(키밸류 트레이너) 구성에서는 분당 240장으로 절반 이하로 줄어드는데, 이는 VLM 추론 오버헤드가 단순 OCR 대비 상당하다는 신호입니다.
궁금한 건 문서 복잡도 분포입니다. 단순 신분증 기준인지, 다단 표가 포함된 금융 서류 기준인지에 따라 throughput 수치는 크게 달라집니다. 농협은행·케이뱅크·신한은행 등 200건 이상의 레퍼런스는 신뢰 지표로 작동하지만, 인식 정확도(Precision/Recall)가 숫자로 제시되지 않은 점은 아쉽습니다. 처리 속도와 정확도는 trade-off 관계에 있으며, '분당 500장'이 어느 정확도 임계치에서 달성된 수치인지가 실제 도입 판단의 핵심입니다. VLM 기반으로 사전 학습 없이 미지 서식을 즉시 처리한다는 주장도 Zero-shot 성능 벤치마크 없이는 검증하기 어렵습니다.
시사점: 좋은 숫자보다 좋은 실험 설계가 먼저다
세 사례를 관통하는 교훈은 하나입니다. 숫자의 신뢰도는 실험 설계의 엄밀함에 비례합니다. DeepSeek DualPath는 에이전트 워크로드 특화 조건을 명시했다는 점에서, 적어도 측정 맥락을 공개한 셈입니다. RAG 사례는 작은 샘플 사이즈지만 방법론과 코드를 함께 공개해 재현 가능성을 높였습니다. Text-to-SQL 벤치마크 삼총사는 오히려 현 LLM의 한계를 적나라하게 드러냄으로써 과장 없는 평가의 모범을 보였습니다.
반면 사이냅 OCR IX 발표는 throughput 수치는 구체적이지만 정확도 지표가 빠진 '반쪽짜리' 공개라는 인상을 지우기 어렵습니다. 평가 데이터셋의 문서 종류, 해상도 분포, 정확도 기준이 함께 공개될 때 비로소 경쟁 제품과 의미 있는 비교가 가능합니다.
전망: 벤치마크 군비경쟁에서 '운영 지표' 중심으로
LLM 생태계가 성숙할수록 벤치마크 게임의 규칙이 바뀌고 있습니다. 단순 정확도 수치 경쟁에서 latency, throughput, cost-per-token, 그리고 에이전트 환경의 멀티턴 일관성 같은 운영 지표(operational metrics)로 무게중심이 이동하고 있습니다. DySQL-Bench가 Pass@5를 측정하고, RAG 사례가 리랭커의 레이턴시 비용을 실측하며, DualPath가 에이전트 실행 횟수를 기준 지표로 삼은 것은 이 흐름을 반영합니다.
분석가로서 앞으로 AI 성능 발표를 볼 때 체크리스트는 간단합니다. 베이스라인은 무엇인가, 샘플 사이즈와 데이터 분포는 공개됐는가, 정확도와 속도 trade-off는 어떻게 제시됐는가, 그리고 실제 운영 환경에서 재현 가능한가. 이 네 가지를 통과하지 못한 숫자는 마케팅 카피일 가능성이 높습니다.