저희 ThakiCloud는 K8s 기반 AI/ML SaaS 플랫폼에서 모델 서빙과 멀티에이전트 워크플로를 직접 다룹니다. 이 데모가 왜 온프레미스 추론 경제성의 변곡점을 보여주는지, 그리고 운영 관점에서 무엇을 시사하는지 짚어보겠습니다.
핵심은 두 가지가 동시에 성립했다는 점입니다.
10개 서브에이전트가 각각 SVG 작품을 생성하고 그 결과를 갤러리로 조립하는 구조는, 클라우드 API 비용 없이 로컬에서 멀티에이전트 패턴을 검증할 수 있다는 것을 보여줍니다. (100+ tokens/sec는 작성자의 로컬 환경 자가 보고 수치이므로 [추정]으로 받아들이는 것이 정확합니다. 하드웨어·양자화·배치 설정에 따라 크게 달라집니다.)
병렬 서브에이전트를 띄우는 것은 멋지지만, 운영에는 규율이 필요합니다. 저희가 멀티에이전트 워크플로를 다루며 얻은 원칙은 이렇습니다.
로컬 멀티에이전트 데모가 의미 있는 진짜 이유는 데이터 주권과 비용입니다. 민감한 코드·문서를 외부 API에 보내지 않고 사내 GPU에서 처리하려는 수요가 분명히 존재합니다. 중형 오픈웨이트 모델이 실용 처리량에 도달하면서, 이 수요는 더 이상 이론이 아니라 운영 가능한 옵션이 됩니다.
저희가 다루는 영역이 바로 이 지점입니다. K8s 위에서 모델 서빙을 표준화하고, Kueue로 GPU 워크로드를 큐잉하며, 멀티에이전트 오케스트레이션을 재현 가능하게 운영하는 일입니다. 로컬 단일 머신 데모를 조직 규모의 서빙 인프라로 확장하면, 자원 스케줄링·격리·관측성이 핵심 과제가 됩니다. 단순히 모델을 띄우는 것과, 다수의 테넌트가 안정적으로 멀티에이전트를 돌리게 하는 것은 다른 문제입니다.
Gemma 4 26B 로컬 멀티에이전트 데모는 “온프레미스 추론이 실용 영역에 들어왔다”는 신호입니다. 모델이 작아지고 빨라지면서, 멀티에이전트 패턴을 클라우드 비용 없이 검증할 수 있게 되었습니다. 이를 조직 규모로 키우는 일에 관심 있는 엔지니어라면, 이런 서빙·스케줄링 문제가 매일의 과제인 곳입니다.
출처: Gemma 4 26B 로컬 멀티에이전트 오케스트레이션 커뮤니티 데모. Gemma 모델 정보: https://ai.google.dev/gemma (처리량 수치는 작성자 로컬 벤치 자가 보고 [추정])
]]>저희 ThakiCloud는 이미 이 도구를 프로덕션 도구 체인에 채택해 운영 중이기 때문에, 단순 소개가 아니라 실사용 관점에서 정리합니다.
기존 컨텍스트 절감 도구들은 대부분 비가역입니다. 한 번 자르면 원본을 되돌릴 수 없습니다. Headroom의 핵심 차별점은 로컬에서 동작하고, 여러 콘텐츠 타입을 커버하며, 가역적이라는 점입니다. 원본은 설정된 TTL 안에서 복원할 수 있습니다. 즉 “압축했더니 에이전트가 디테일을 잃었다”는 전형적 실패를 구조적으로 막습니다.
Headroom은 라이브러리, 프록시, MCP 서버 세 가지 형태로 붙일 수 있습니다. 콘텐츠 타입을 인식해서 JSON의 이상치·로그의 실패 라인만 남기는 식으로 선택적으로 압축하고, 브레드크럼 해시로 원본 복원 경로를 유지합니다.
Headroom은 콘텐츠 타입별로 다른 압축기를 씁니다.
통합도 광범위합니다. Python/TypeScript 라이브러리 호출, Anthropic/OpenAI SDK 래퍼, 미들웨어, MCP 클라이언트까지 드롭인으로 붙습니다. 코드를 거의 바꾸지 않고 끼워 넣을 수 있다는 점이 채택 장벽을 낮춥니다.
저희 환경에서 가장 효과가 큰 지점은 반복 구조의 대용량 JSON 도구 출력입니다. 검색 결과나 로그 배열을 컨텍스트에 넣기 전에 SmartCrusher로 결정론적으로 압축하면, 무손실에 가까운 상태로 절반 이상을 절감할 수 있습니다(평문은 압축 대상이 아니라 JSON 경로에 한정됩니다). 가역성 덕분에 압축본을 우선 투입하고, 특정 섹션이 필요할 때만 원본을 복원하는 운영이 가능합니다.
이는 멀티에이전트 오케스트레이션에서 특히 중요합니다. K8s 위에서 다수의 서브에이전트가 도는 워크플로에서는 컨텍스트 위생이 곧 비용 통제이고, 캐시 히트율 관리이며, 응답 지연 관리입니다. Headroom은 이 레이어를 코드 변경 없이 끼워 넣을 수 있게 해줍니다.
한 가지 정직한 한계도 짚습니다. Headroom은 로컬 프로세스를 실행할 수 있어야 동작하므로, 샌드박스로 격리된 환경에서는 쓸 수 없습니다. 단일 프로바이더의 네이티브 compaction만으로 충분하고 크로스 에이전트 메모리가 필요 없는 팀에는 과잉일 수 있습니다.
Headroom은 “컨텍스트는 공짜가 아니다”라는 원칙을 도구로 구현한 사례입니다. 가역 압축이라는 설계 덕분에, 비용을 깎으면서도 에이전트가 디테일을 잃지 않습니다. ThakiCloud가 컨텍스트 위생을 어떻게 비용·신뢰성 문제로 다루는지에 관심 있는 엔지니어라면, 이런 레이어를 프로덕션에서 직접 운영하는 곳이 저희입니다.
출처: Headroom (headroom-ai), PyPI https://pypi.org/project/headroom-ai/ · GitHub https://github.com/chopratejas/headroom (작성자 Tejas Chopra, 2026-06 릴리스)
]]>저희 ThakiCloud는 K8s 기반 AI/ML SaaS 플랫폼에서 RAG 문서 인제스트를 다룹니다. 모델 비의존 파서가 왜 비용·주권 관점에서 매력적인지, 그리고 어디까지 헷지해야 하는지 짚어보겠습니다.
LiteParse의 핵심 차별점은 파싱에 LLM을 쓰지 않는다는 것입니다. 이 설계가 주는 이점은 분명합니다.
LiteParse 측은 모델 비의존 파서 범주에서 여러 벤치마크 최고 점수를 주장합니다. 다만 이 주장은 자체 측정이고 model-free 범주에 한정된다는 점을 명시해야 합니다. LLM 기반 파서와의 절대 비교가 아니라, “모델을 안 쓰는 파서 중에서”라는 조건이 붙습니다. 속도·정확도 주장은 이 범주 한정으로 헷지하는 것이 정직합니다.
모델 비의존 파서가 만능은 아닙니다. 트레이드오프를 분명히 해야 합니다.
RAG 파이프라인을 프로덕션에서 운영하면, 인제스트 비용이 의외로 큰 비중을 차지합니다. 문서가 많고 자주 갱신될수록, 파싱에 LLM을 쓰는지 여부가 운영 비용을 좌우합니다. LiteParse 같은 model-free 파서를 기본 경로로 두고, 복잡한 문서만 LLM 파서로 에스컬레이션하는 라우팅이 비용 효율적입니다.
저희가 다루는 영역이 이 지점입니다. K8s 위에서 문서 인제스트 파이프라인을 표준화하고, 문서 유형에 따라 파서를 라우팅하며, 민감 문서를 사내에서 처리해 데이터 주권을 보장하는 일입니다. 인제스트를 단순 전처리가 아니라 비용·주권·품질이 만나는 1급 설계 문제로 다룹니다.
LiteParse는 “RAG 인제스트에 항상 LLM이 필요한 것은 아니다”라는 메시지를 줍니다. 모델 비의존 파서는 비용·지연·데이터 주권에서 분명한 이점이 있고, 복잡한 문서는 LLM 파서로 보완하는 하이브리드가 현실적입니다. 인제스트 비용을 1급 시민으로 다루는 일에 관심 있는 엔지니어라면, 이런 문제가 매일의 과제인 곳입니다.
출처: LlamaIndex LiteParse (Apache 2.0). GitHub: https://github.com/run-llama/llama_cloud_services (벤치마크 점수는 자체 측정, model-free 범주 한정 주장).
]]>저희 ThakiCloud는 K8s 기반 AI/ML SaaS 플랫폼에서 이미지 서빙과 프롬프트 템플릿을 다룹니다. 이 기법이 왜 결정론적 품질을 만들어내는지, 그리고 제품화 관점에서 무엇을 시사하는지 짚어보겠습니다.
구조화 프롬프트의 원리는 단순합니다. 모델에게 “포맷을 자유롭게 풀게” 하지 말고, 검증된 골격에 내용을 채우게 하는 것입니다. 자유도를 줄이면 평균 품질이 올라갑니다. 이 사례는 프롬프트를 다섯 섹션으로 나눕니다.
각 섹션을 분리하면 결과가 흔들릴 때 어느 레이어를 고쳐야 할지 즉시 보입니다. 스타일이 약하면 3번을, 인물이 뭉개지면 1번을 강화하는 식입니다.
스타일 변환에서 가장 흔한 실패는 “스타일은 입혔는데 원본을 잃는 것”입니다. 이 기법은 두 가지 장치로 막습니다.
이는 프롬프트 작법의 일반 원칙과 정확히 일치합니다. 긍정 프레이밍으로 “무엇을 유지하라”를 명시하고, 출력 형태를 구조로 고정하면 모델이 매번 다르게 푸는 것을 막을 수 있습니다.
개인이 한 번 잘 만든 프롬프트는 일회성입니다. 이를 제품으로 만들려면 템플릿화가 필요합니다. 5섹션 구조를 고정된 템플릿으로 박고, 사용자는 각 섹션의 값만 채우게 하면, 비전문가도 일관된 품질의 결과를 얻습니다.
저희가 다루는 영역이 이 지점입니다. 이미지 생성 모델을 K8s 위에서 서빙하고, 검증된 프롬프트 템플릿을 API로 노출하며, 사용자 입력을 구조화된 슬롯에 매핑하는 일입니다. 모델에게 포맷을 생성시키지 말고 내용만 생성시키는 원칙을 이미지 도메인에 적용하면, 자유 프롬프트의 품질 편차를 제품 수준의 일관성으로 바꿀 수 있습니다.
구조화 프롬프트의 교훈은 텍스트와 이미지에 동일하게 적용됩니다. 자유 서술을 검증된 골격으로 강등시키고, 보존할 것을 앵커링하며, 레이어로 스타일을 제어하십시오. 자유도를 줄이는 것이 곧 품질을 올리는 길입니다.
출처: GPT Image 2 구조화 프롬프트 스타일 변환 커뮤니티 사례 분석. 이미지 모델 프롬프트 작법 일반 원칙 기반 정리.
]]>저희 ThakiCloud는 K8s 기반 AI/ML SaaS 플랫폼에서 모델 서빙을 다룹니다. 이 사례가 왜 컨슈머 GPU 추론 경제성의 변곡점인지, 그리고 무엇을 검증하고 무엇을 헷지해야 하는지 짚어보겠습니다.
먼저 신뢰도를 분리하는 것이 중요합니다.
이렇게 출처별 신뢰도를 명시하는 것이 데이터 과학자의 기본 위생입니다. 인상적인 수치일수록 출처를 분리해서 봐야 합니다.
QAT의 핵심은 양자화를 학습 시점에 반영한다는 것입니다. 일반적인 사후 양자화(PTQ)는 학습이 끝난 모델을 낮은 비트로 압축하는데, 이 과정에서 정확도 손실이 생깁니다. QAT는 학습 중에 양자화 노이즈를 모델이 학습하게 해서, 낮은 비트에서도 정확도를 보존합니다.
여기에 TurboQuant 같은 추가 양자화 기법이 얹히면, 메모리 풋프린트를 더 줄이면서 품질 저하를 억제할 수 있습니다. 결과적으로 8GB VRAM이라는 컨슈머 등급 메모리 안에 12B 모델과 긴 컨텍스트를 함께 넣는 것이 가능해집니다.
이 사례가 의미 있는 진짜 이유는 서빙 단가입니다. 데이터센터 GPU 한 장 값으로 컨슈머 GPU 여러 장을 살 수 있습니다. 양자화 인식 학습 덕분에 중형 모델이 컨슈머 GPU에서 실용 품질로 돌아가면, 온프레미스 추론의 비용 구조가 근본적으로 바뀝니다.
저희가 다루는 영역이 이 지점입니다. 양자화된 모델을 K8s 위에서 표준화해 서빙하고, Kueue로 GPU 워크로드를 큐잉하며, 이기종 GPU 풀(데이터센터 + 컨슈머)을 한 스케줄러 아래 두는 일입니다. 단일 머신에서 모델 하나를 띄우는 것과, 다수의 테넌트가 양자화 모델을 안정적으로 공유하게 하는 것은 다른 문제입니다. 메모리 격리, 처리량 보장, 품질 회귀 모니터링이 운영의 핵심 과제가 됩니다.
Gemma 4 12B를 8GB GPU에서 돌린 사례는 “양자화가 추론 경제성을 바꾼다”는 신호입니다. 단, 인상적인 처리량 수치는 출처를 분리해 [추정]으로 보고, 공식 릴리스와 개인 벤치를 구분해야 합니다. 양자화 모델을 조직 규모로 서빙하는 일에 관심 있는 엔지니어라면, 이런 서빙·스케줄링 문제가 매일의 과제인 곳입니다.
출처: Gemma 4 12B QAT + TurboQuant 컨슈머 GPU 커뮤니티 벤치마크. Gemma: https://ai.google.dev/gemma · TurboQuant(ICLR 2026). 처리량 수치는 작성자 개인 벤치 [추정].
]]>저희 ThakiCloud는 K8s 기반 AI/ML SaaS 플랫폼에서 모델 서빙을 다룹니다. 이 사례가 온프레미스 대형 LLM 서빙 경제성에 던지는 함의를 짚어보겠습니다.
대형 모델을 작은 GPU에 욱여넣는 데에는 두 가지 기술이 결합됩니다.
약 10 tok/s라는 처리량은 프로덕션 서빙에는 느리지만, 이 수치는 작성자의 단일 환경 측정값이므로 [추정]으로 보는 것이 정확합니다. 중요한 것은 “전용 데이터센터 GPU 없이도 753B 모델을 구동하는 경로가 열렸다”는 점입니다.
이 사례가 의미 있는 진짜 이유는 데이터 주권과 서빙 옵션의 확장입니다. 민감한 도메인에서는 753B급 SOTA 모델을 외부 API에 보내지 않고 사내에서 돌리려는 수요가 분명히 존재합니다. 단일 소비자 GPU에서의 10 tok/s는 데모 수준이지만, 이를 다수의 GPU로 확장하고 배치·텐서 병렬을 적용하면 실용 처리량에 도달할 수 있습니다.
저희가 다루는 영역이 이 지점입니다. 대형 오픈웨이트 모델을 K8s 위에서 다중 GPU로 샤딩해 서빙하고, Kueue로 GPU 자원을 배분하며, 희소 어텐션 커널 같은 모델별 최적화를 표준화된 서빙 스택에 통합하는 일입니다. 단일 머신 데모를 멀티테넌트 프로덕션 서빙으로 키우는 것이 핵심 과제입니다.
GLM-5.2를 RTX 4090에서 돌린 사례는 “대형 SOTA 모델의 온프레미스 서빙 경로가 열렸다”는 신호입니다. 커널 이식과 희소 어텐션이 접근성을 만들고, 양자화가 메모리를 푸는 구조입니다. 이를 조직 규모의 서빙 인프라로 확장하는 일에 관심 있는 엔지니어라면, 이런 문제가 매일의 과제인 곳입니다.
출처: GLM-5.2(753B, FP8) RTX 4090 구동 커뮤니티 사례. 처리량 약 10 tok/s는 작성자 단일 환경 [추정]. GLM 모델군 정보는 Zhipu AI/Z.ai 공식 자료 참조.
]]>저희 ThakiCloud는 K8s 기반 AI/ML SaaS 플랫폼에서 학습 워크로드와 GPU 오케스트레이션을 다룹니다. RL 사후학습을 인프라 문제로 바라보는 이 프레임워크가 왜 중요한지 짚어보겠습니다.
RL 사후학습은 지도학습과 다른 부담을 줍니다.
이 세 단계가 한 루프에서 반복되므로, 추론(롤아웃)과 학습(업데이트)을 같은 GPU 풀 위에서 효율적으로 스케줄링하는 것이 핵심 과제가 됩니다. 추론과 학습은 자원 프로파일이 다르기 때문에, 단순히 한 작업으로 묶기 어렵습니다.
slime이 “RL 스케일링”을 표방하는 것은, 단일 GPU의 RL 루프가 아니라 대규모 분산 환경에서의 RL 사후학습을 겨냥한다는 뜻입니다. 롤아웃 생성과 정책 업데이트를 분산하고, 그 사이의 데이터 흐름을 효율적으로 관리하는 것이 프레임워크의 역할입니다. GLM-5.2 같은 대형 모델의 사후학습에 실제로 쓰였다는 점이, 이 프레임워크가 데모가 아니라 프로덕션 규모에서 검증되었음을 시사합니다.
slime 같은 RL 사후학습 프레임워크는 저희가 다루는 학습 인프라 문제와 정확히 맞닿습니다. K8s 위에서 Kueue로 GPU 워크로드를 큐잉할 때, RL 루프의 추론·학습 교대 패턴을 어떻게 스케줄링할지가 핵심 과제입니다. 롤아웃 생성은 추론 자원 프로파일을, 정책 업데이트는 학습 자원 프로파일을 갖기 때문에, 한 루프 안에서 자원을 동적으로 재배분해야 합니다.
저희가 다루는 영역이 이 지점입니다. RL 사후학습 같은 복합 워크로드를 멀티테넌트 GPU 플랫폼에서 안정적으로 돌리고, 자원을 공정하게 배분하며, 학습 절차를 재현 가능하게 표준화하는 일입니다. 오픈소스 RL 프레임워크가 늘어날수록, 이를 조직 규모의 학습 인프라에 통합하는 일의 가치도 커집니다.
slime은 “RL 사후학습은 알고리즘 문제이자 인프라 문제”라는 메시지를 줍니다. 추론과 학습이 교대하는 RL 루프를 대규모로 스케줄링하는 것이 핵심이고, 이를 오픈소스로 공개한 것이 생태계에 기여합니다. RL 학습 인프라를 K8s 위에서 운영하는 일에 관심 있는 엔지니어라면, 이런 문제가 매일의 과제인 곳입니다.
출처: slime — LLM post-training framework for RL Scaling (Z.ai / THUDM). GitHub: https://github.com/THUDM/slime
]]>arxiv를 autoarxiv로 바꾸기만 하면, 에이전트가 코드베이스 환경을 설정하고, 최소 재현을 실행하며, GPU 복제 비용까지 추정합니다.
저희 ThakiCloud는 K8s 기반 AI/ML SaaS 플랫폼에서 GPU 워크로드 오케스트레이션을 다룹니다. 이 접근이 왜 흥미롭고, 어디서 통합 가치가 나오는지 짚어보겠습니다.
autoresearch가 자동화하는 단계는 명확합니다.
이 분해가 영리한 이유는, 재현을 “전부 아니면 전무”로 다루지 않기 때문입니다. 최소 재현으로 빠르게 신뢰도를 확인하고, 전체 재현 비용을 미리 추정해서 GPU를 태우기 전에 의사 결정을 할 수 있게 합니다. 비용을 쓰기 전에 측정하라는 원칙을 재현성 도메인에 적용한 것입니다.
재현성 자동화가 실무에 유용한 이유는 세 가지입니다.
autoresearch가 추정하는 “GPU 복제 비용”은 저희가 매일 다루는 문제와 정확히 맞닿습니다. K8s 위에서 Kueue로 GPU 워크로드를 큐잉하고, 자원을 공정하게 배분하며, 비용을 워크로드별로 귀속시키는 일입니다.
재현 에이전트가 “이 논문을 전체 재현하려면 GPU N장을 M시간”이라고 추정하면, 그 추정을 Kueue 큐에 제출 가능한 작업 명세로 옮길 수 있습니다. 최소 재현은 작은 큐에서 빠르게, 전체 재현은 예약된 GPU 풀에서 배치로 돌리는 식의 워크플로가 자연스럽게 그려집니다. 재현성 자동화와 GPU 스케줄링이 만나는 지점이 바로 저희가 다루는 영역입니다.
alphaXiv autoresearch는 “재현성을 에이전트로 자동화한다”는 방향을 보여줍니다. 핵심은 전체 재현을 강제하지 않고, 최소 재현과 비용 추정으로 의사 결정을 돕는다는 설계입니다. 이를 GPU 오케스트레이션과 결합해 조직 규모로 운영하는 일에 관심 있는 엔지니어라면, 이런 문제가 매일의 과제인 곳입니다.
출처: alphaXiv autoresearch 기능 소개. alphaXiv: https://www.alphaxiv.org/
]]>저희 ThakiCloud는 K8s 기반 AI/ML SaaS 플랫폼에서 GPU 워크로드와 학습 인프라를 다룹니다. 이 논문이 왜 데이터 과학자와 인프라 엔지니어 모두에게 유용한지 짚어보겠습니다.
논문이 5세대를 평가하는 다섯 축은 그 자체로 대규모 학습 인프라의 평가 프레임입니다.
이 논문이 하드웨어 논문을 넘어 방법론적으로 유용한 이유는 이렇습니다.
저희는 TPU 같은 전용 슈퍼컴퓨터를 만들지는 않지만, 이 논문의 설계 원칙은 K8s 기반 GPU 플랫폼에 그대로 이식됩니다. 아키텍처 안정성은 표준화된 서빙·학습 인터페이스로, 회복탄력성은 Kueue 기반 작업 재시도와 체크포인팅으로, 전력 효율은 GPU 활용률 모니터링과 워크로드 패킹으로 나타납니다.
수천 칩 규모의 교훈을 수십~수백 GPU 규모의 멀티테넌트 플랫폼에 적용하는 것이 저희가 다루는 영역입니다. 고장을 상수로 가정하고, 시스템 전체 처리량을 보며, 전력·비용을 1급 지표로 다루는 운영 철학은 규모와 무관하게 옳습니다.
구글의 TPU 5세대 논문은 “대규모 AI 인프라는 칩이 아니라 시스템”이라는 메시지를 데이터로 보여줍니다. 아키텍처 안정성으로 누적하고, 회복탄력성으로 처리량을 지키며, 전력 효율을 1급 지표로 다루십시오. 이 원칙은 GPU 클러스터를 운영하는 모든 팀에 적용됩니다.
출처: “Google’s Training Supercomputers from TPU v2 to Ironwood: Architectural Stability, Scale, Resilience, Power Efficiency, and Sustainability Across Five Generations”, arXiv:2606.15870 (2026-06-14). https://arxiv.org/abs/2606.15870
]]>저희 ThakiCloud는 K8s 기반 AI/ML SaaS 플랫폼을 운영하면서 멀티에이전트 워크플로의 라우팅 품질을 직접 다뤄왔기 때문에, 이 논문의 결론이 실무와 정확히 맞닿는다고 봅니다.
논문은 복합 스킬 라우팅을 세 단계로 정식화합니다.
SkillWeaver 프레임워크는 이 세 단계를 각각 LLM 태스크 분해기, FAISS 인덱싱 기반 바이인코더(bi-encoder) 스킬 검색기, 의존성 인식 DAG 플래너로 구현합니다. 평가를 위해 저자들은 공개 MCP 생태계에서 수집한 실제 MCP 서버 스킬 위에서 복합 쿼리로 구성된 벤치마크를 함께 제안합니다.
이 논문에서 데이터 과학자가 가져가야 할 가장 중요한 한 줄은 이것입니다. 표준 LLM 분해는 스텝 레벨에서 카테고리 재현율(category recall)이 낮게 나온다는 것입니다.
즉, 검색기를 아무리 좋게 만들어도 분해 단계에서 서브태스크를 절반 넘게 떨구면 뒤 단계가 전부 무너집니다. 직관적으로는 “검색을 더 잘하자”로 가기 쉽지만, 측정은 정반대를 말합니다. 고쳐야 할 곳은 분해입니다.
저자들은 이를 해결하기 위해 검색 결과를 피드백으로 받아 분해를 스킬 라이브러리의 어휘에 반복적으로 정렬시키는 retrieval-augmented 루프를 제안합니다. 분해가 “내가 가진 스킬로 실행 가능한 형태”로 수렴하도록 만드는 접근입니다.
이 논문이 단순 데모가 아니라 방법론으로서 유용한 이유는 세 가지입니다.
저희는 SkillWeaver의 문제 정식화와 평가틀을 차용해, 내부 스킬 코퍼스 위에서 단일 검색 vs 분해 기반 라우팅을 직접 측정했습니다. 결과는 논문과 방향이 같았습니다. 완벽히 분해해도 천장이 존재했고, 병목이 분해 그리고 검색기/디스크립션 품질 양쪽에 있었습니다. 다시 말해 “검색은 멀쩡하니 분해만 고쳐라”는 논문의 결론이 모든 환경에 그대로 이전되지는 않습니다. 환경마다 직접 측정해야 한다는 것이 저희의 실무 교훈입니다.
이런 측정 인프라와 라우팅 게이트를 K8s 위에서 재현 가능하게 운영하는 일이 ThakiCloud가 다루는 영역입니다. 에이전트 라우팅 품질을 데이터로 다루고 싶은 엔지니어라면, 이런 문제가 매일의 과제인 곳입니다.
SkillWeaver의 메시지는 명확합니다. 복합 작업에서 라우팅 품질을 올리려면 모델을 키우기 전에 분해를 고치고, 단계별로 측정하라는 것입니다. 고치기 전에 측정하라는 이 논문의 진짜 교훈은, 멀티에이전트를 운영하는 모든 팀에 그대로 적용됩니다.
출처: “Compositional Skill Routing for LLM Agents: Decompose, Retrieve, and Compose”, arXiv:2606.18051 (2026-06-16). https://arxiv.org/abs/2606.18051
]]>