AI 코딩 에이전트가 API를 틀리게 호출하는 장면을 목격한 적이 있는가? Claude Code에 GPT-5.2 호출을 요청했더니 최신 responses API 대신 구버전 chat completions API를 집어 들었다는 Andrew Ng의 사례는, 사실 우리 모두가 매일 마주치는 일상적인 풍경이다. 파라미터를 잘못 추측하고, deprecated 엔드포인트를 자신 있게 호출하고, v3가 출시된 지 1년이 지났는데 여전히 v1을 사용하는 에이전트. 문제는 사용자가 그 실패를 에이전트 탓이 아니라 API 제공자 탓으로 돌린다는 것이다.
이 문제를 정면으로 겨냥한 것이 Andrew Ng이 공개한 오픈소스 프로젝트 Context Hub다. 핵심 아이디어는 단순하다. AI 에이전트가 훈련 데이터에 의존하는 대신, CLI로 정확하고 최신의 문서를 직접 가져오게 만드는 것이다. chub get your-api/docs --lang python 한 줄이면 에이전트는 추측 대신 검증된 문서를 읽고 코드를 생성한다. 발표 5일 만에 1,500개 이상의 스타를 받고, 현재 Stripe, OpenAI, Anthropic, Supabase, AWS 등 68개 API 제공자가 등록된 것은 이 문제의 절박함을 방증한다.
Context Hub의 설계에서 특히 주목할 부분은 문서의 독자를 사람이 아닌 기계로 전제한다는 점이다. 마케팅 문구 없이 설치 커맨드부터 시작하고, 현실적인 파라미터가 담긴 완성형 코드 예제를 앞에 배치하며, 에이전트가 자주 저지르는 실수 목록을 명시적으로 기술한다. 주석 시스템(chub annotate)을 통해 에이전트가 발견한 workaround와 gotcha를 세션 간에 저장하고 축적하는 구조도 흥미롭다. 문서가 에이전트와 함께 똑똑해지는 셈이다. 단, Context Hub 기여 가이드가 스스로 경고하듯, AI가 생성한 초안을 검토 없이 제출하면 잘못된 정보를 생태계에 다시 주입하는 악순환이 된다.
여기서 두 번째 이야기가 맞물린다. dev.to의 한 개발자가 46개 AI 보조 저장소를 구축한 뒤 뒤늦게 발견한 구조적 맹점이다. 그가 끌어온 비유는 생물학의 '근친교배 우울(inbreeding depression)'이다. 같은 가정, 같은 멘탈 모델, 같은 평가 기준으로 구축된 도구들이 서로를 검증하는 폐쇄 루프. 내부적으로는 완벽하게 정합적이지만, 그 전제 자체가 틀렸을 때는 아무것도 경보를 울리지 않는다. LLM은 이 문제를 증폭한다. 당신의 내부 기준을 넘겨주면, 모델은 그 기준이 잘못됐다고 말하는 대신 기준에 딱 맞는 자신감 있는 평가를 JSON으로 포맷해 돌려준다.
그가 찾은 처방은 의도적 외부 마찰(Intentional External Friction)이다. 생태계 외부의 도구를 서브프로세스로 호출하고, 그 JSON 출력만 읽는 독립 검증 레이어(flamehaven-validator)를 별도로 구축했다. Delta Gate(변경 전후 품질 스냅샷 비교), 적대적 코드 패턴 탐색, 크로스 도구 앙상블 등 네 가지 공격 각도로 자신의 생태계를 바깥에서 찌른다. 핵심은 도구가 내 가정을 공유하지 않아야 한다는 것이다. 모두가 같은 방향을 보는 코드 리뷰는 리뷰가 아니라 의식에 불과하다.
두 이야기를 연결하면 하나의 설계 원칙이 떠오른다. 컨텍스트의 품질은 출처의 다양성과 독립성에 달려 있다. Context Hub가 'source' 필드를 official, maintainer, community로 구분하는 이유, 그리고 AI 생성 문서를 반드시 사람이 한 줄씩 검토하도록 강조하는 이유도 같다. 에이전트에게 공급하는 컨텍스트가 단일 가정의 폐쇄 루프에서 나온다면, 생성되는 코드도 그 편향을 그대로 증폭한다. 좋은 컨텍스트는 단순히 '최신' 문서가 아니라, 서로 다른 관점에서 교차 검증된 정보다.
프론트엔드 개발 워크플로우로 옮겨 생각해보면 시사점이 구체적이다. Cursor나 Claude Code에 컴포넌트 생성을 맡길 때, 우리가 주입하는 컨텍스트는 어디서 왔는가? 내가 작성한 디자인 시스템 문서, 내가 만든 코드 컨벤션, 내가 정의한 평가 기준—이 세 가지가 모두 나에게서 나왔다면, 에이전트는 내 맹점을 충실히 재현한다. Context Hub 방식처럼 API 문서를 에이전트 소비용으로 별도 작성하거나, flamehaven-validator 방식처럼 생태계 바깥의 린터·접근성 검사·번들 분석 도구를 독립 레이어로 두는 것이 단순한 도구 추가가 아니라 컨텍스트 다양성 확보임을 인식해야 한다.
앞으로의 방향은 더 명확해질 것이다. AI 스택에서 컨텍스트 레이어는 모델 레이어만큼, 어쩌면 그보다 더 중요한 설계 영역으로 부상하고 있다. Context Hub처럼 에이전트 소비 전용 문서 표준이 API 생태계 전반에 자리를 잡고, 검증 레이어의 독립성이 CI 파이프라인의 기본 요건이 되는 흐름은 자연스럽다. 개발자에게 남는 질문은 하나다. 지금 내 에이전트에게 먹이는 컨텍스트는 누가, 어떤 가정으로, 어떻게 만들었는가.