핵심 요약

• “너프” 의심의 대부분은 재현 가능한 측정 없이는 참도 거짓도 아니며, n=1 비교는 판정 근거가 되지 않는다.
• 측정이 통제되지 않으면 안 된다: 고정 프롬프트, 고정 채점, 핀된 CLI, 매일 같은 시각, 그리고 통계적 유의성.
• 실제로 있었던 품질 저하 사례는 “은밀한 너프”가 아니라 클라이언트 기본값 변경, 세션 버그, 시스템 프롬프트 수정이었다 — Anthropic이 2026년 4월 postmortem으로 공식 인정했다.
• 검증된 실험(livenerf)에 따르면 모델이 “덜 생각”하게 되면 정확도보다 출력 토큰이 먼저 움직인다. 개인 추적에서 토큰 수 추적이 가장 저렴한 조기 경보다.
• 같은 계열 모델 교체(예: Opus 5 5.5) 정도의 미세한 차이는 월 몇 달러짜리 개인 추적으로는 잡지 못한다. 한계를 알고 측정하자.

왜 “네프 느낌”만으로는 판정이 안 되는가

LLM은 본질적으로 비결정적(non-deterministic)이다. 같은 프롬프트를 두 번 보내도 출력이 달라진다. sampling 온도를 0으로 고정해도 완전한 재현이 보장되지 않고, 최신 모델은 thinking을 끌 수 없는 경우도 있다. 그래서 “어제는 잘하던 게 오늘은 안 된다”는 경험 하나로는 다음 세 가지가 구분되지 않는다.

1. 정상적인 샘플링 변동
2. 실제 서비스 변경(라우팅, 기본값, 프롬프트, 인프라)
3. 사용자 쪽 변화(프롬프트·컨텍스트가 길어짐, 과제가 어려워짐, 신선함 효과가 사라짐)

HN에서 이 주제를 다룰 때마다 반복되는 정론도 같다. “네트워크 느낌”은 증거가 아니고, n=1 비교는 쓸모가 없다는 것. 실제로 한 커뮤니티에서는 여러 해 동안 “너프됐다”는 보고가 반복됐지만 지속적으로 재현된 사례는 소수였고, 그 소수는 뒤에서 설명할 “인시던트”로 판명됐다.

측정 프로토콜: 고정 패널 + 매일 실행 + 통계

2026년 9월 Opus 5.5 출시 직후 시작된 오픈소스 실험 livenerf가 좋은 참고 사례다. 이 프로젝트는 “출시 후 모델이 조용히 나빠지는가”라는 질문 하나에 대해, 논쟁이 감싸움이 되지 않도록 통제된 측정 설계를 공개하고 실행 중이다. 핵심 설계는 다음과 같다.

여기서 개인이 가져갈 수 있는 원칙은 명확하다. 바꿀 수 있는 것은 전부 동결하고, 바뀐 것만 측정한다. 프롬프트·채점 기준·도구 버전·실행 시각이 흔들리면 그 흔들림이 모델 변화로 위장한다.

조기 신호는 토큰 수다

livenerf가 검증 단계에서 얻은 가장 실용적인 발견은 이것이다. 노력(effort) 등급을 high에서 medium으로 낮추면 정확도는 −4.2 ± 3.9포인트로 통계적으로 애매하지만, 출력 토큰은 −26%로 즉각·명확하게 줄어든다. low까지 내리면 정확도 −8.3 ± 4.5포인트, 토큰 −62%다.

alt=”livenerf 검증 결과: 노력 등급 변경과 모델 교체가 정확도와 출력 토큰에 미치는 영향”/>

*출처: ninjahawk/livenerf 저장소 검증 수치 (2026-10-01 기준)*

즉 개인 수준에서 “모델이 예전보다 덜 생각하는 것 같다”를 확인하는 가장 싼 방법은 정답률 재측정이 아니라 동일 과제의 출력 토큰 중앙값 추적이다. 토큰 수는 로그에 남고, 노이즈가 적고, 변화가 정확도보다 먼저 나타난다.

주의할 점도 있다. livenerf의 검증에서 Opus 5로 모델을 통째로 바꿔도 Opus 5.5와 99% 신뢰수준에서 구분되지 않았다(−3.8 ± 6.3포인트). 같은 계열의 미세한 교체는 이 정도 규모의 추적으로는 잡을 수 없다는 것을 스스로 측정한 셈이다. 개인 추적의 한계를 인정하고, “잡을 수 있는 것”(노력 등급·프롬프트 변경급의 변화)과 “못 잡는 것”(동급 모델 스왑)을 구분해서 해석해야 한다.

실제로 있었던 “너프”의 정체 — Anthropic postmortem

“은밀한 너프”가 사실이었던 적이 있을까. Anthropic은 2026년 4월, Claude Code 품질 저하 보고에 대해 공식 postmortem을 발표했다. 사용자들이 “모델이 나빠졌다”고 느낀 기간의 원인을 조사한 결과, 세 가지 개별 변경이 확인됐다.

이 사례가 시사하는 바가 두 가지 있다. 첫째, 사용자들의 체감 저하는 실재했고 원인도 실재했다. 둘째, 그 원인은 “가중치를 몰래 양자화했다”류의 음모가 아니라 클라이언트 기본값·프롬프트·세션 처리의 변경이었다. API는 영향을 받지 않았고, 문제는 Claude Code·Agent SDK·Cowork 쪽이었다. Anthropic은 같은 글에서 “모델을 의도적으로 저하시킨 적은 없다”고 밝히며, 내부 eval이 초기에 재현하지 못한 이유(트래픽 슬라이스별로 다른 시점에 다른 변경이 적용됨)도 설명했다.

5단계 실전 체크리스트

내가 쓰는 모델이 나빠졌는지 의심될 때, 다음 순서로 확인한다. 하루 10분 이내로 끝나는 것부터.

1. 내 쪽 변경 배제 — 시스템 프롬프트, 컨텍스트 길이, 도구 목록, 노력(effort) 설정, CLI/SDK 버전이 바뀌지 않았는지 먼저 확인한다. Opus 5.5는 API 기본 effort가 medium이므로 명시 안 하면 high가 아니다.
2. 고정 과제 3~5개 재실행 — 예전에 잘 풀었던 실무 과제를 프롬프트째 저장해뒀다가 그대로 돌린다. 한 번이 아니라 3회 이상.
3. 출력 토큰 중앙값 비교 — 같은 과제의 출력 토큰 수가 기록 대비 20% 이상 줄었으면 노력·프롬프트·라우팅 변경 의심. 정답률보다 민감한 지표다.
4. API와 구독 경로 분리 테스트 — 같은 모델을 API로 호출해 결과가 다르면 문제는 서빙 경로(구독 클라이언트) 쪽. postmortem 사례가 정확히 이 패턴이었다.
5. 공식 상태 페이지·changelog 확인 — 클라이언트 변경 이력을 먼저 본다. 모델 가중치 의심은 최후에.

자주 묻는 질문

너프 측정에는 얼마나 많은 샘플이 필요한가?

livenerf 기준으로 하루 1회 전 패널(90샘플)을 10일간 돌려야 약 ±7.5포인트 변화를 감지한다. 개인이 몇 번 물어보고 “더 멍청해졌다”고 결론 내리는 것은 이 감도에서 수십 배 모자란다. 반드시 분포 비교로 판정한다. 평가 세트 설계 자체의 원칙은 AI Evals 실무 가이드를 참고한다.

temperature 0으로 하면 재현되지 않나?

완전하지 않다. 서버 측 배치·라우팅·캐싱 상태에 따라 미세하게 달라질 수 있고, 최신 모델은 thinking을 비활성화할 수 없어 변동성이 남는다. 그래서 “완전한 결정성”이 아니라 “결정적인 것은 전부 동결”이 현실적인 목표다.

벤치마크 점수가 그대로면 너프가 아닌가?

그렇다고 단정할 수 없다. 공개 벤치마크는 운영사가 식별해 특별 취급할 수 있고(livenerf도 이 한계를 명시한다), 실사용 품질과 벤치마크 점수가 항상 일치하지 않는다. 반대로 벤치마크가 나빠졌다고 반드시 의도적 너프인 것도 아니다. 인시던트인지 의도인지는 운영사 투명성 없이는 구분 불가능하다.

그냥 다운그레이드 모델이 섞여 들어오는 건 아닐까?

같은 이름 뒤에 여러 버전이 롤아웃되는 것은 업계에서 실제로 있는 운영 방식이다. 다만 livenerf 검증에서 보았듯 동급 모델 스왑은 개인 규모 측정으로 잡기 어렵다. 의심되면 API 직접 호출과 구독 경로를 비교하는 편이 실용적이다.

정리

“모델이 나빠졌다”는 느낌은 무시할 신호도 아니지만 그 자체로 결론도 아니다. 실제 품질 저하 사례는 존재했고, 그 원인은 측정 가능한 변경이었다. 개인이 할 수 있는 가성비 최고의 대응은 (1) 고정 과제와 프롬프트 동결, (2) 출력 토큰 중앙값 추적, (3) API/구독 경로 분리 비교다. 그리고 커뮤니티 주장은 어디까지나 발견의 단서로 쓰고, 판정은 재현 가능한 측정과 공식 자료로 한다.

참고자료

• ninjahawk/livenerf — Opus 5.5 출시일 기준 30일 너프 추적 벤치마크 (GitHub)
• An update on recent Claude Code quality reports — Anthropic Engineering, 2026-04-23
• Adding Error Bars to Evals — Anthropic, arXiv:2411.00640
• Claude Opus 5.5 문서 — 기본 effort medium, 컨텍스트 1M, $4/$20 (Anthropic Platform Docs, 2026-10-02 확인)
• Opus 5.5 nerfing 논의 — r/ClaudeAI 커뮤니티 스레드 (2026-10-01~02), Hacker News “Livenerf: Has Opus 5.5 been nerfed yet?” (914 포인트)

The post LLM 너프 의심, 체감 대신 데이터로 확인하는 법 appeared first on .

핵심 요약

• 무엇: Hermes Agent 전용 올인원 플러그인. 기획·리서치·리뷰·운영 등 123개 워크플로 스킬, 파일 기반 장기 기억 프로바이더, 실행 비용·상태를 보여주는 HUD를 함께 넣는다.
• 누구에게: Hermes Agent를 설치는 했지만 스킬을 하나씩 골라 붙이기보다 검증된 묶음으로 시작하고 싶은 사람, 세션 간 기억과 작업 흐름 표준화가 필요한 사람.
• 핵심 차이: oh-my-zsh이 셸에 프레임워크를 얹듯 Hermes에 “운영 계층”을 얹는다. 개별 스킬 모음이 아니라 라우팅·기억·보고가 함께 동작한다.
• 주의: 설치가 Hermes config.yaml의 스킬 경로, 플러그인 목록, memory.provider, 스킨까지 바꾼다. 제거 커맨드는 파일·디렉터리만 지우고 설정 등록은 남긴다. 백업과 수동 복구 절차가 필수다.
• 검증 기준일: 2026-09-15, npm 버전 2.0.3(2026-09-12 발표) 기준. GitHub 1,990★, 159 포크.

도구 정보와 실제 증가 속도

스타 증가율 수치는 오늘 처음 스냅숏을 잡은 관계로 provisional(초회 관측)이며 실제 일별 증분이 아니다. 대신 확인 가능한 활동 신호는 릴리스 주기(8월 말부터 6회), 일일 커밋, npm 게시 이력이다. 커뮤니티 신호로는 공식 Discord, 제작자 X(@rlaope) 계정, 한국어 LinkedIn 소개 글, skillsllm.com 에이전트 카탈로그 등재가 있다. Hacker News 논의는 아직 없다.

설치하면 무엇이 바뀌나 — 직접 검증 결과

격리된 임시 홈(/tmp)에서 npm tarball을 내려 받아 vendored wheel(oh_my_hermes-2.0.3-py3-none-any.whl, SHA256 고정)을 가상환경에 설치하고 omh --hermes-home <격리경로> setup을 실행했다. 실제 사용자 홈은 두 번째 실행부터 건드리지 않았음을 파일 시스템 타임스탬프로 확인했다.

설치 결과:

• ~/.omh/skills/에 123개 워크플로 스킬 생성(안내·리서처·플래너·리뷰어·운영자 등 9개 역할 그룹)
• <hermes-home>/plugins/omh/에 대형 플러그인 번들 설치(메모리 프로바이더, 브라우저 브리지, 훅, 거버넌스 모듈 포함)
• Hermes config.yaml에 4군데 변경: skills.external_dirs에 스킬 경로 추가, plugins.enabled에 omh 추가, memory.provider: omh 설정(기억 글자上限 2200→4000, 1375→2000으로 함께 변경), display.skin: omh 지정
• TUI 위젯(tui-widgets/omh-status.mjs)과 스킨 4종 추가

진단:omh doctor는 격리 환경에서 44/44 통과(0 blocking, 경고 3개는 PATH 미등록 등 운영성 항목)였다.

제거:omh uninstall --all은 ~/.omh와 plugins/omh 디렉터리를 지운다(실제 로그로 확인). 그러나 config.yaml의 네 가지 등록은 그대로 남는다. 재설치 후 다시 제거해도 동일했다. 완전한 원상복구에는 config.yaml 수동 편집이 필요하다.

요구 권한·보안 검토

• 설치 경로: 공식 install.sh(531줄)은 자기 GitHub 저장소와 릴리스에서만 내려 받는다. sudo 사용은 없었다. venv는 ~/.local/share/omh 아래에 만든다.
• npm 공급망: 런타임 의존성 0개, 파이썬 휠을 패키지 안에 동봉하며 SHA256(wheelSha256, cacheTreeSha256)을 manifest에 고정해 무결성을 검사한다. npm provenance 게시 활성화 상태다.
• LLM 호출: 라이브러리 안에 LLM 클라이언트가 없다. 판단은 호스트 CLI(Hermes가 쓰는 모델)를 빌려 쓰고, 별도 API 키가 필요 없다는 게 README의 설명이고, 설치 과정에서 키 입력을 요구하지 않은 것으로 확인됐다.
• 네트워크: 플러그인에 egress 시도 영수증(egress_attempts) 모듈이 있어 외부 전송을 거버넌스로 기록·통제하는 구조다. 텔레메트리는 준비도 프로브·실행 요약류이며 옵트인(기본 꺼짐)이라고 문서에 명시돼 있다.
• 침입성(가장 중요): memory.provider: omh는 Hermes 기본 기억 시스템을 OMH 것으로 교체한다. isolation 검증 중 인자 순서를 잘못 써서 --hermes-home 없이 실행한 적이 있었는데, 이때 실제 사용자 ~/.hermes의 config.yaml·플러그인·스킨이 수정됐다. 곧바로 백업본 기준으로 전부 원상복구했고(파일·설정 모두 정상 확인), 이 경험 자체가 “명시적 hermes-home 지정 없이는 운영 환경을 침범할 수 있다”는 실측 경고가 된다.
• 비용: 도구 자체는 무료(MIT). 실행 비용은 Hermes가 쓰는 모델 usage 그대로다. HUD가 실행별 토큰·달러를 계산해 보여준다.

기존 유명 도구와 비교 — superpowers와는 무엇이 다른가

Agent 스킬 프레임워크로 자주 비교되는 대표 도구와의 관계를 정리한다.

관계 분류: 보완재(허점을 메우는 관계)다. superpowers가 Claude Code 생태계의 사실상 표준 스킬 팩이라면, OMH는 Hermes 생태계에서 같은 역할을 하려는 도구다. 두 에이전트를 함께 쓰는 사람에게는 각 호스트에 각각 두는 것이고, Hermes만 쓰는 사람에게는 superpowers 대신이 아니라 “Hermes에는 superpowers가 없으므로 그 자리를 채우는 선택지”다. superpowers(28.6만★)나 Anthropic 공식 스킬(17.6만★) 대비 역사와 검증 규모는 작지만(약 2천★), Hermes Agent 자체가 24.5만★로 한국어 사용자가 빠르게 늘고 있는 호스트라는 점이 이 도구의 의미다.

Claude Code / Codex / Hermes별 설치·연결 방법

OMH는 Hermes Agent 플러그이다. Claude Code와 Codex에는 설치 대상이 없다는 점을 먼저 명확히 한다(에이전트가 이 글을 읽고 OMH를 설치하려는 경우 아래 안전 프롬프트를 사용한다).

Hermes Agent에 설치(공식 절차)

1. 전제: Hermes Agent가 설치돼 있고 Python 3.11+, Node 18+.
2. 원라인 설치: curl -fsSL https://raw.githubusercontent.com/rlaope/oh-my-hermes/main/install.sh | sh
3. 설정: omh setup — 단, 운영 홈이 아닌 별도 홈에서 시험할 때는 반드시 omh --hermes-home <경로> setup처럼 전역 인자를 서브커맨드 앞에 둔다. 뒤에 붙이면 무시되고 기본 홈을 수정한다(실측).
4. 확인: omh doctor — 44개 검사가 모두 통과해야 정상.
5. Hermes 재시작 후 대화에서 워크플로가 인식되는지 확인.

바뀌는 경로(설치 시 생성)

• ~/.omh/ — 스킬 123종, 런타임 상태
• <hermes-home>/plugins/omh/ — 플러그인 번들
• <hermes-home>/tui-widgets/omh-status.mjs, <hermes-home>/skins/omh*.yaml
• <hermes-home>/config.yaml — 앞서 나열한 4군데 수정

제거·원상복구

1. omh uninstall --all — ~/.omh, 플러그인 디렉터리 삭제(커맨드 패키지는 설치 방식에 따라 npm uninstall -g oh-my-hermes 또는 brew uninstall omh)
2. config.yaml 수동 복구 — skills.external_dirs의 omh 경로 삭제, plugins.enabled에서 omh 제거, memory.provider: omh 줄 삭제(기억 한도도 원복), display.skin 원복
3. 변경 전 config.yaml 백업이 있으면 그것으로 되돌리는 것이 가장 확실하다

Claude Code / Codex 사용자: 이 도구는 두 에이전트의 확장이 아니다. Hermes Agent를 별도로 운영 중이라면 그 Hermes에만 설치한다.

안전한 복사·붙여넣기 프롬프트

이 글의 URL을 에이전트(Claude Code, Codex, Hermes)에 붙여 넣고 설치를 맡길 때 쓸 프롬프트다. 운영 환경 보호를 위해 그대로 사용하기를 권한다.

https://blog.kwt.co.kr/ 에 안내된 oh-my-hermes(OMH)를 설치해줘. 다음 규칙을 지켜.

1. 버전 고정: npm 패키지 oh-my-hermes 2.0.3을 쓴다. 설치 후 `omh --version`으로 2.0.3인지 확인하고 다르면 중단·보고해.
2. 사전 백업: ~/.hermes/config.yaml이 있으면 타임스탬프 붙은 복사본을 만들어. 설치 전 백업이 없으면 진행하지 마.
3. 격리 먼저: 먼저 임시 디렉터리(예: /tmp/omh-trial)에 HOME을 두고 시험 설치한다. `omh --hermes-home /tmp/omh-trial/.hermes setup`처럼 전역 인자(--hermes-home)를 서브커맨드 앞에 쓴다. 인자를 뒤에 붙이면 실제 홈이 수정되니 주의.
4. 진단: `omh --hermes-home /tmp/omh-trial/.hermes doctor`가 44/44 통과인지 확인하고 결과를 그대로 보여줘.
5. 실제 설치 승인: 격리 검증 결과를 보고한 뒤, 내가 명시적으로 "실제 홈에 설치"라고 답할 때까지 실제 ~/.hermes는 건드리지 마.
6. 권한 확인: 설치 중 API 키 입력, 비밀 입력, sudo를 요구하면 중단하고 보고해.
7. 제거 실습: 격리 환경에서 `omh uninstall --all`을 실행해 파일이 지워지는 것과 config.yaml에 omh 등록이 남는 것을 확인·보고해. config 복구는 백업본으로 하는 법을 함께 보여줘.
8. 금지: 운영 프로젝트 디렉터리 변경, 실제 사용자 홈 설정 변경(5번 승인 전), 비용 결제, credentials 열람.

직접 검증한 것과 못 한 것

직접 실행해 확인한 것(2026-09-15, npm 2.0.3 tarball)

• npm 패키지 구조: 의존성 0, vendored 휠 SHA256 고정, provenance 필드
• 격리 홈 설치: 스킬 123종 생성, config.yaml 4군데 수정, TUI 위젯·스킨 설치
• omh doctor 44/44 통과
• omh uninstall --all의 파일 제거와 config 미복구 동작
• 인자 순서 오용 시 실제 홈 수정 동작(발견 즉시 원상복구 완료)

검증하지 못한 것

• Hermes 실세션에서의 워크플로 실행 품질(기억 저장·라우팅 정확도) — 설치·진단까지만 무해 검증
• Windows PowerShell 설치 경로
• 장기 운영 시 안정성과 업데이트(omh update) 동작
• README가 제시하는 성능 수치(별도 벤치마크 아님, 독립 검증 없음)

유용한 경우 / 추천하지 않는 경우

유용한 경우

• Hermes Agent를 본격 작업 호스트로 쓰면서 스킬을 일일이 구성할 시간이 없을 때
• 세션 간 프로젝트 기억이 필요하고, 파일 기반(그리프 가능) 기억을 선호할 때
• 여러 작업 유형(리서치·기획·리뷰·운영)에 표준 절차를 물리고 실행 비용을 HUD로 감시하고 싶을 때

추천하지 않는 경우

• Hermes를 가볍게만 쓰는 경우 — 기본 기능으로 충분하고 설정 침입성이 손해다
• config.yaml을 직접 관리하며 민감하게 쓰는 경우 — 제거 시 수동 복구가 부담이면 피한다
• Claude Code/Codex 중심 사용자 — 이 도구는 그 대상이 아니다(superpowers 등 해당 생태계 도구를 쓴다)
• 운영 환경에서 즉시 쓰려는 경우 — 반드시 격리 검증 후 도입한다

자주 묻는 질문(FAQ)

oh-my-zsh과 같은 건가요?

이름에서 따온 건 맞다. 셸에 프레임워크를 얹듯 Hermes에 운영 계층을 얹는다는 관점은 같다. 다만 셸 스크립트 모음과 달리 기억 프로바이더 교체·모델 라우팅처럼 호스트 동작에 깊이 관여한다는 점이 다르다.

Claude Code에서도 쓸 수 있나요?

아니다. Hermes Agent 전용 플러그이다. Claude Code에는 superpowers 같은 대응 생태계가 있다.

제거하면 Hermes가 망가지나요?

omh uninstall --all 후 config.yaml의 omh 등록을 수동으로 지우지 않으면 Hermes가 없는 경로·프로바이더를 참조할 수 있다. 설치 전 config.yaml 백업이 필수인 이유다.

API 키가 추가로 필요한가요?

필요하지 않다. 판단은 Hermes가 이미 쓰는 모델 연결을 빌려 쓴다(README 명시, 설치 중 키 요구 없음으로 확인).

데이터가 외부로 나가나요?

라이브러리에 LLM 클라이언트가 없고 기억은 로컬 파일 기반이다. 텔레메트리는 옵트인이다. 설치·설정 단계에서 외부 전송을 요구하는 동작은 관찰되지 않았다. 다만 에이전트 플러그인 특성상 실행 시 호스트 권한을 쓰는 만큼, 민감 저장소가 있는 환경이라면 격리 검증 후 도입한다.

확인된 참고 자료

• 공식 저장소: https://github.com/rlaope/oh-my-hermes
• 설치 문서: https://github.com/rlaope/oh-my-hermes/blob/main/docs/INSTALLATION.md
• 한국어 README: https://github.com/rlaope/oh-my-hermes/blob/main/README.ko.md
• npm 패키지: https://www.npmjs.com/package/oh-my-hermes
• Hermes Agent(호스트): https://github.com/NousResearch/hermes-agent
• 비교 대상 superpowers: https://github.com/obra/superpowers
• 제작자 소개(LinkedIn, 한국어): https://kr.linkedin.com/posts/esperer_github-rlaopeoh-my-hermes-the-agent-engineering-activity-7498651733376696320-TNID
• 기준일: 2026-09-15. 스타·다운로드 수치는 이날 실측이며 이후 변동될 수 있다.

The post Hermes Agent를 “내 업무용 도구”로 바꾸는 oh-my-hermes: 설치·보안·제거 직접 검증 appeared first on .

왜 지금 도구 레지스트리가 중요해지나

초기 AI 에이전트는 미리 등록된 몇 개의 도구만 사용했다. 웹 검색, 파일 읽기, 이메일 전송, 캘린더 수정처럼 에이전트 런타임에 이미 들어 있는 도구 목록 안에서 LLM이 하나를 고르는 구조다. 도구 수가 적을 때는 이 방식이 단순하고 효과적이다.

문제는 에이전트가 실제 업무 환경으로 들어가면서 생긴다. 회사에는 HR 시스템, 결재 API, 데이터웨어하우스, Jira, GitHub, Slack, CRM, 회계 시스템, 사내 문서 검색, 배포 파이프라인 같은 수많은 도구가 있다. 모든 도구를 에이전트 설정에 수동으로 등록하고, 모든 도구 설명을 매번 LLM 컨텍스트에 넣는 방식은 오래 버티기 어렵다.

여기서 도구 레지스트리의 필요성이 나온다. 에이전트가 처음부터 모든 도구를 들고 있는 것이 아니라, 필요한 순간에 “이 작업에 맞는 능력이 어디에 있는가”를 검색하고, 검증하고, 선택 후보로 가져오는 구조가 필요하다.

앱스토어 비유가 유용한 이유

스마트폰 앱 생태계에서 앱스토어는 단순 파일 저장소가 아니다. 사용자는 앱스토어에서 앱을 검색하고, 설명과 리뷰를 보고, 권한을 확인하고, 설치한다. 개발자는 앱을 등록하고, 버전을 관리하고, 배포 채널을 얻는다. 플랫폼은 정책, 결제, 보안, 심사, 업데이트를 관리한다.

AI 에이전트 도구 레지스트리도 비슷한 문제를 다룬다. 다만 사용자가 사람이 아니라 에이전트라는 점이 다르다. 에이전트는 앱 아이콘이나 마케팅 문구보다 기계가 읽을 수 있는 메타데이터가 필요하다. 어떤 작업에 적합한지, 호출 방식은 무엇인지, 누가 제공하는지, 신뢰할 수 있는지, 어떤 권한이 필요한지를 구조화된 형태로 받아야 한다.

Agent Registry는 무엇을 저장하나

레지스트리가 저장하거나 색인하는 것은 “코드 전체”가 아닐 수 있다. 더 중요한 것은 에이전트가 판단할 수 있는 설명과 연결 정보다. 예를 들어 어떤 MCP 서버가 있다면, 레지스트리는 그 서버가 어떤 기능을 제공하는지, 어떤 자연어 요청에 적합한지, 어떤 URL이나 엔드포인트로 연결되는지, 누가 게시했는지, 어떤 인증이 필요한지 같은 정보를 다룬다.

Google Developers Blog가 소개한 Agentic Resource Discovery, ARD는 이 문제를 표준 명세 관점에서 다룬다. ARD 공식 문서는 이를 “AI 클라이언트가 이 작업에 무엇을 사용할 수 있는가를 물으면, 발견 서비스가 맞는 리소스를 돌려주는 개방형 발견 프로토콜”로 설명한다. 또한 ARD는 호출 런타임이 아니라 호출 전 발견 계층이라고 못박는다.

Google Cloud 문서의 Agent Registry도 같은 흐름을 제품 인프라 관점에서 보여준다. 문서 목차만 봐도 agents, endpoints, MCP servers, tools, discovery, search, access control 같은 항목이 함께 등장한다. 즉, 레지스트리는 단순 목록 페이지가 아니라 에이전트와 도구를 운영하는 관리 계층으로 확장된다.

도구 레지스트리가 해결하려는 5가지 문제

1. 에이전트가 모든 도구를 미리 알 필요가 없다

현재 방식에서는 도구를 쓰려면 에이전트 설정이나 코드에 먼저 등록해야 한다. 레지스트리 방식에서는 필요한 능력을 검색해 후보를 가져올 수 있다. 이는 도구가 수십 개에서 수백 개로 늘어날 때 특히 중요하다.

2. LLM 컨텍스트에 모든 도구 설명을 넣지 않아도 된다

도구 설명이 많아질수록 컨텍스트 비용과 선택 오류가 커진다. 레지스트리는 전체 도구 목록을 매번 LLM에 주는 대신, 검색으로 소수 후보를 좁히는 역할을 할 수 있다. LLM은 모든 도구가 아니라 관련 후보 안에서 선택한다.

3. 신뢰와 출처를 기계적으로 확인할 수 있다

에이전트가 런타임에 도구를 찾는다면 피싱 도구나 잘못된 엔드포인트를 피해야 한다. 도메인 기반 카탈로그, 게시자 정보, trust metadata, 조직 정책은 “이 도구를 믿고 연결해도 되는가”라는 질문에 답하기 위한 장치다.

4. 기업 내부 도구 거버넌스가 가능해진다

기업에서는 공개 웹보다 사내 레지스트리가 먼저 중요해질 수 있다. 어떤 에이전트가 어떤 도구를 호출할 수 있는지, 민감 데이터가 외부로 나가지 않는지, 승인된 MCP 서버만 쓰는지, 감사 로그가 남는지 같은 문제가 실제 운영 병목이 되기 때문이다.

5. 도구 생태계가 플랫폼을 넘어 연결된다

한 회사의 에이전트 플랫폼 안에서만 도구를 찾는 구조는 폐쇄적이다. ARD 문서가 강조하듯, 공개 웹과 기업 내부에는 여러 발견 서비스가 존재할 수 있다. 이는 하나의 중앙 앱스토어가 아니라, 여러 레지스트리가 서로 다른 커뮤니티와 정책에 맞게 색인하는 구조에 가깝다.

MCP, A2A, ARD와의 관계

이 주제에서 가장 흔한 혼동은 레지스트리와 실행 프로토콜을 섞는 것이다. MCP는 도구를 연결하고 호출하는 방식이다. A2A는 에이전트 간 협업 방식이다. OpenAPI는 HTTP API를 설명하고 호출하는 방식이다. 반면 Agent Registry와 ARD는 그런 리소스를 “어디서 찾고 어떻게 믿을 것인가”에 초점을 둔다.

따라서 Agent Registry는 MCP의 경쟁자가 아니다. 오히려 MCP 서버가 많아질수록 “좋은 MCP 서버를 어떻게 찾고, 공식 제공자인지 어떻게 확인하고, 우리 조직 정책상 호출 가능한지 어떻게 판단할 것인가”라는 문제가 생긴다. 레지스트리는 이 질문을 다루는 계층이다.

개발자와 운영자가 지금 준비할 것

1. 도구 인벤토리를 만든다. 사내 API, MCP 서버, 자동화 스크립트, 워크플로, 데이터 조회 기능을 “에이전트가 호출 가능한 리소스” 관점으로 정리한다.
2. 사람용 문서와 기계용 메타데이터를 분리한다. 블로그 글이나 README만으로는 부족하다. 대표 질의, capability, 입력/출력, 권한, 제한사항이 구조화되어야 한다.
3. 공개 리소스와 내부 리소스를 나눈다. 공개 웹에서 발견되어도 되는 도구와 사내 에이전트만 써야 하는 도구는 레지스트리 정책이 달라야 한다.
4. 신뢰 모델을 설계한다. 도메인 소유권, 게시자 검증, 승인된 엔드포인트, 버전 고정, 감사 로그가 필요하다.
5. LLM에게 모든 도구를 주지 않는 구조를 고려한다. 검색, 후보 축소, 정책 필터링, 최종 선택의 단계를 나누면 비용과 오류를 줄일 수 있다.

앱스토어 다음은 정말 Agent Registry인가

비유로는 그렇다. 사람 중심 컴퓨팅에서 앱스토어가 앱 발견과 유통의 중심이었다면, 에이전트 중심 컴퓨팅에서는 레지스트리가 도구 발견과 거버넌스의 중심이 될 가능성이 있다. 다만 수익 배분, 리뷰, 설치 같은 소비자 앱스토어 모델이 그대로 복제된다고 보기는 어렵다.

더 현실적인 모습은 세 가지가 공존하는 구조다. 공개 웹에는 여러 오픈 레지스트리가 생기고, 클라우드 플랫폼은 관리형 Agent Registry를 제공하며, 기업 내부에는 사내 도구만 색인하는 프라이빗 레지스트리가 생긴다. 에이전트는 작업에 따라 이 중 하나 또는 여러 발견 계층을 사용한다.

이 변화가 중요한 이유는 에이전트의 능력이 모델 크기만으로 결정되지 않기 때문이다. 어떤 도구를 찾을 수 있는지, 어떤 데이터를 안전하게 조회할 수 있는지, 어떤 워크플로를 신뢰하고 실행할 수 있는지가 실제 업무 성능을 좌우한다. 모델이 두뇌라면, 레지스트리는 외부 세계와 연결되는 주소록이자 검증된 도구 상자다.

짧은 결론

AI 에이전트 도구 레지스트리는 단순한 목록 서비스가 아니다. 에이전트가 사용할 수 있는 능력을 발견하고, 설명하고, 검증하고, 정책에 맞게 연결하는 인프라다. ARD, Agent Registry, MCP 서버 검색, 사내 도구 카탈로그는 모두 같은 방향을 가리킨다. 앞으로의 질문은 “어떤 모델을 쓰는가”뿐 아니라 “그 모델이 어떤 검증된 도구 생태계에 접근할 수 있는가”가 된다.

FAQ

AI 에이전트 도구 레지스트리는 무엇인가

AI 에이전트가 사용할 수 있는 도구, 스킬, MCP 서버, API, 워크플로, 다른 에이전트를 검색하고 검증하기 위한 카탈로그 또는 검색 계층이다.

Agent Registry는 앱스토어와 같은가

비유로는 비슷하지만 완전히 같지는 않다. 앱스토어는 사람이 앱을 찾고 설치하는 유통 채널이고, Agent Registry는 에이전트가 호출 가능한 리소스를 발견하고 신뢰 정보를 확인하는 기술 계층에 가깝다.

Agent Registry가 MCP를 대체하나

대체하지 않는다. MCP는 발견된 도구를 실제로 연결하고 호출하는 방식 중 하나다. 레지스트리는 MCP 서버를 어디서 찾고 어떻게 신뢰할지 다룬다.

기업은 왜 자체 레지스트리가 필요할 수 있나

기업 내부 도구와 데이터는 권한, 감사, 정책, 보안 요구사항이 강하다. 공개 레지스트리만으로는 부족하기 때문에 사내 도구를 색인하고 승인된 에이전트만 접근하게 하는 프라이빗 레지스트리가 필요할 수 있다.

공식 출처와 같이 읽을 글

• Google Developers Blog: Announcing the Agentic Resource Discovery specification
• Agentic Resource Discovery 공식 문서
• ARD How to publish 가이드
• Google Cloud Agent Registry overview
• Agentic Resource Discovery란? AI 에이전트가 도구를 직접 찾는 검색 표준
• llms.txt 작성 방법 Best Practice
• AI 검색 최적화 GEO란?

The post AI 에이전트 도구 레지스트리 시대: 앱스토어 다음은 Agent Registry인가 appeared first on .