수백에서 수천 개의 스킬을 파일 단위로 관리하며 자연어 요청을 그때그때 알맞은 스킬로 라우팅하는 에이전트 하네스를 운영하고 있다면, 혹은 그런 시스템을 설계할 계획이라면 이 논문이 다루는 질문이 낯설지 않을 것입니다. 라우팅 품질이 기대에 못 미칠 때, 다음 투자를 복잡한 요청을 잘게 쪼개는 분해(decomposition) 계층에 부어야 할까요, 아니면 후보를 찾아내는 리트리버와 인덱스 자체를 손봐야 할까요. 이 논문은 국내 클라우드·AI 엔지니어가 실제로 마주치는 이 갈림길에서, 값비싼 LLM 분해 파이프라인을 새로 만들지 않고도 어느 쪽에 먼저 투자해야 하는지 두 숫자만으로 판별하는 방법을 제시합니다.

문제의식: “리트리벌은 이미 해결됐다”는 가정

최근 스킬 라우팅을 다루는 연구들은 하나같이 라이브러리가 수백에서 수천 개 규모로 커지면서 모델이 매 턴 모든 후보를 다 볼 수 없게 됐다는 점을 지적합니다. 그래서 소수의 후보만 먼저 검색으로 추려내고, 요청이 여러 스킬을 걸치는 복합 요청이면 하위 작업으로 쪼개 각각 라우팅하는 구조가 표준이 되어가고 있습니다. 이 흐름을 정식화한 대표 연구인 SkillWeaver(arXiv:2606.18051)는 여기서 한 걸음 더 나가, 오라클 top-1 recall이 99.5퍼센트에 이른다는 근거로 “리트리벌은 사실상 해결됐고 진짜 병목은 분해”라고 결론짓습니다. 이 결론을 그대로 받아들이면, 운영자는 검색기를 그대로 두고 분해 계층에 엔지니어링 예산을 쏟아야 한다는 뜻이 됩니다.

이 논문은 그 결론이 다른 환경에서도 그대로 유지되는지 검증합니다. 검증 대상은 논문 저자들이 실제로 운영하는 1800개 이상의 파일 기반 스킬을 담은 단일 조직 프로덕션 하네스이며, 라우터는 결정론적인 BM25 계열 어휘 검색기이고, 요청은 한국어와 영어가 뒤섞인 자연어입니다. 잘 정제된 영어 중심 벤치마크가 아니라, 실제로 돌아가는 덜 정제된 다국어 코퍼스에서 같은 주장을 시험해본 것입니다.

Compositional Routing: Step Coverage vs Chain Completion by Strategy ORACLE 상한선(63.6%)이 완전 커버리지에서 한참 못 미쳐, 리트리버가 진짜 병목임을 보여주는 실측 결과입니다.

핵심 기여: ceiling-gap 진단법

논문의 중심 아이디어는 간단하지만 효과적입니다. 완벽한 분해를 가정한 상한선(ORACLE)과 지금 당장 운영 중인 단일 패스 검색(SINGLE)의 커버리지 차이, 즉 ceiling gap을 계산하는 것입니다. 여기서 ORACLE은 사람이 미리 정성껏 쪼개놓은 정답 수준의 하위 작업들을 게이트 없이 그대로 검색기에 태워 얻은 결과이므로, 새로운 LLM 호출이나 실제 배포용 분해 파이프라인이 전혀 필요 없습니다. 검증셋 몇 개만 손으로 준비하면 됩니다.

이 진단이 읽어내는 것은 숫자 하나가 아니라 두 숫자의 관계입니다. ORACLE 자체가 거의 100퍼센트에 가깝고 SINGLE과의 격차가 크다면, 그건 SkillWeaver가 측정한 상황과 같은 레짐이므로 분해에 투자하는 게 맞습니다. 반대로 ORACLE 자체가 100퍼센트에 한참 못 미친다면, 아무리 완벽하게 분해해도 남는 격차의 상당 부분을 메울 수 없다는 뜻이므로 리트리버와 인덱스 쪽을 먼저 손봐야 합니다.

실측 결과가 바로 이 두 번째 경우였습니다. 12개 사례로 구성된 복합 라우팅 벤치마크에서 SINGLE의 step coverage는 52.9퍼센트였고, 게이트를 완전히 제거한 채 정답 수준 분해를 적용한 ORACLE은 63.6퍼센트에 그쳤습니다. SkillWeaver가 보고한 99.5퍼센트 근처와는 거리가 멉니다. 완벽한 분해로도 필요한 스킬의 3분의 1 이상을 여전히 찾아내지 못한다는 뜻입니다. 규칙 기반 분해(SAD), 재분할을 추가한 개선판(ISAD), 정답 수준 분해에 게이트를 적용한 버전(SAD-AGENT)은 오히려 모두 35.0~41.9퍼센트로 SINGLE보다 낮았습니다. 하위 작업을 쪼개는 과정에서 게이트가 애매한 후보를 떨어뜨려 커버리지를 깎아 먹은 탓입니다. 반면 이 조직의 과거 엔지니어링 로그를 보면, 분해 로직은 전혀 건드리지 않고 한국어-영어 어휘 격차를 메우는 동의어 사전 확장 한 번만으로 ORACLE 상한선이 42.5퍼센트에서 63.6퍼센트로 21.1포인트 뛰었습니다. 분해가 아니라 리트리버 쪽 작업이 실제로 성과를 냈다는 직접 증거입니다.

ORACLE Ceiling Before and After Synonym Engineering 동의어 사전 확장 한 차례가 분해 로직 변경 없이 ORACLE 상한선을 21.1포인트 끌어올렸습니다. 같은 12개 벤치마크에서 2026년 6월 20일과 24일 로그를 대조한 사례 연구입니다.

분해 실패 유형을 분석한 결과도 흥미롭습니다. 12개 사례 중 과분해(over-decomposition)는 0건인 반면 저분해(under-decomposition)는 9건으로 압도적이었는데, 이는 SkillWeaver가 보고한 지배적 실패 유형(과분해)과 정반대입니다. 저자들은 이 역전 현상을 분해 실패 유형이 분해라는 개념 자체의 보편적 속성이 아니라 특정 분해기의 경계 탐지 튜닝에서 나오는 부산물임을 보여주는 증거로 해석합니다. 그래서 분해 문제와 리트리버 문제를 분리하려는 어떤 진단이든, 분해기 하나의 결과만으로 판단하지 말고 ORACLE처럼 분해를 고정한 조건에서 리트리버 자체의 상한선을 따로 읽어야 한다는 것이 이 논문의 방법론적 핵심입니다.

Decomposition Error Taxonomy (12 Cases) 저분해(9/12)가 지배적 실패 유형으로 나타나, SkillWeaver가 보고한 과분해 우세와 정반대 양상을 보입니다. 논문 본문의 분해 오류 분류 표를 도식화한 것으로, 별도 측정이 아닌 분석적 정리 자료입니다.

회사·사회·과학에 대한 기여

기업 입장에서 이 진단법은 1800개 이상의 스킬을 운영하는 자사 하네스에 그대로 적용 가능한, 거의 비용이 들지 않는 사전 투자 판단 절차를 제공합니다. 실제로 이미 돌아가고 있는 복합 라우팅 벤치마크 스크립트로 바로 실행할 수 있어, 진짜 병목이 리트리버 커버리지인데 분해 로직에 헛되이 공수를 쏟는 상황을 막아줍니다.

사회적으로는 이 진단이 팀들을 불필요한 분해 계층 과잉 설계에서 벗어나게 해준다는 의미가 있습니다. 분해 파이프라인은 매 요청마다 추가 추론 비용과 별도의 평가·오류 처리 부담을 낳지만, 동의어 사전 확장 같은 리트리버 개선은 엔지니어 한 명이 유지보수할 수 있는 수준입니다. 대규모 ML 인프라 팀이 없는 소규모 조직도 신뢰할 수 있는 자율 에이전트 시스템을 더 쉽게 도입할 수 있게 되는 셈입니다.

과학적으로는 리트리벌이 “사실상 해결된 문제”라는 최근 컴포지셔널 스킬 라우팅 문헌의 통념에 정면으로 반박하는 재현 가능한 반례를 제시합니다. 정제된 영어 중심 벤치마크에서는 성립할 수 있는 주장이, 덜 정제되고 한국어-영어가 뒤섞인 실제 프로덕션 코퍼스에서는 성립하지 않는다는 것을 보여줌으로써, “리트리벌이 해결됐다”는 일반화가 리트리벌 자체의 속성이 아니라 코퍼스와 인덱스의 속성이라는 점을 드러냅니다. 그리고 SINGLE 대비 ORACLE의 격차를 읽는 ceiling-gap 진단법 자체는 라우팅 연구 전반에 적용 가능한 형태로 일반화된다고 주장합니다.

한계

저자들은 한계를 숨기지 않고 명시합니다. 복합 벤치마크는 12개 사례에 불과해 통계적으로 검증된 모집단 추정치가 아니라 사례 연구로 읽어야 합니다. 단일 조직·단일 코퍼스에서 얻은 특정 수치(63.6퍼센트 같은)가 다른 환경에도 그대로 나타난다고 주장하지 않습니다. 일반화되는 것은 수치가 아니라 진단 절차 자체입니다. 한국어-영어 이중 언어 혼합만 다뤘을 뿐 다른 언어쌍에 대한 검증은 이뤄지지 않았고, 진단법 자체의 라이브 프로덕션 A/B 테스트도 수행하지 않은 회고적 벤치마크 연구라는 점도 밝히고 있습니다. 특히 눈에 띄는 대목 하나가 있습니다. 논문 제출 하루 전 시도한 재현 실행이 파싱 가능한 결과 파일을 내지 못하고 조용히 실패했다가, 다음 날에야 성공했다는 재현성 사고를 그대로 기록한 것입니다. 이런 진단 도구일수록 measured/skipped/error 같은 명시적 상태값을 갖춘 엄격한 머신 리더블 출력 계약이 필요하다고 제언합니다.

논문 상세 페이지는 여기에서 확인할 수 있습니다: https://huggingface.co/datasets/thaki-AI/daily-paper-2026-07-09-retriever-vs-decomposition-skill-routing