저는 LLM API를 활용한 몇 가지 사이드 프로젝트를 운영하고 있는데, 제 일주일 중 가장 짜증 나는 부분은 디버깅이 아니라 바로 정보를 찾아보는 것입니다. 입력/출력/추론(thinking) 토큰별로 나뉘어 있는 가격 체계, 세 단계나 깊숙이 숨겨진 속도 제한(Rate limits), 제가 사용하는 정확한 모델과 일치하지 않는 샘플 코드까지. 네 가지 서로 다른 레이아웃을 가진 네 개의 포털(문서, 콘솔, 모델 카탈로그, API 레퍼런스)이 존재합니다.

그리고 이러한 탐색 방식의 근육 기억(muscle memory)은 제공업체 간에 전혀 공유되지 않습니다. 플랫폼마다 구성 방식이 모두 다르고, 몇 주마다 새로운 모델과 가격 변동 사항을 출시합니다.

제가 더 이상 직접 찾아보지 않게 만들어 준 설정은 다음과 같습니다.

패턴: 로컬 문서, 에이전트가 이를 읽음

Context7을 사용해 보셨다면 그 개념을 알고 계실 것입니다. AI 어시스턴트가 오래된 학습 데이터로 환각(hallucination)을 일으키게 두는 대신, 현재의 문서를 AI 어시스턴트의 컨텍스트(context)에 주입하는 방식입니다. 이는 오픈 소스 라이브러리 (open-source library) 측면의 문제를 해결합니다. 하지만 모델 _플랫폼 (platform)_의 가격, 속도 제한(rate limits), 그리고 파라미터 스키마(parameter schemas)는 MCP가 가져올 수 있는 어떤 리포지토리(repo)에도 존재하지 않습니다.

Alibaba Cloud의 Model Studio 팀은 동일한 아이디어를 자신들의 플랫폼에 적용한 에이전트 스킬(Agent Skill)인 bailian-docs-llm-wiki를 출시했습니다. 한 번의 설치로 플랫폼의 전체 문서와 모델 카탈로그의 구조화된 스냅샷이 에이전트가 직접 읽을 수 있는 로컬 파일이 됩니다.

세 가지 레이어:

레이어	내용	용도
models/	콘솔 게이트웨이 API에서 가져온 구조화된 카탈로그 데이터	가격, 속도 제한(rate limits), 컨텍스트 윈도우(context windows), 샘플 코드
...
Three-layer local knowledge base with conflict precedence

models/ 레이어가 차별점입니다. 이는 스크래핑된 HTML이 아니라, 카탈로그 UI를 구동하는 것과 동일한 데이터 엔드포인트(data endpoint)입니다. QPM 제한, 계층별 가격, 파라미터 정의, 그리고 공식 샘플 코드가 모두 구조화된 필드로 제공됩니다.

설정

npx skills add modelstudioai/skills

Node.js ≥ 18. 프롬프트에서 bailian-docs-llm-wiki를 선택하세요. 그 이후에는 설정이 전혀 필요 없습니다. 플랫폼의 문서, 모델 또는 가격에 관한 질문을 던지면 자동으로 활성화됩니다. Claude Code, Qwen Code, Cursor 등 Agent Skills (에이전트 스킬)를 지원하는 모든 환경에서 작동합니다. 쿼리는 로컬 파일을 읽기 때문에 비용이 전혀 들지 않으며 API 키도 필요하지 않습니다. 실제로 모델을 실행할 때는 키가 필요할 것입니다 (신규 계정은 무료 티어 제공): API 키 받기.

무엇을 대체하는가, 작업별 비교

가격 및 속도 제한 (Rate limits). _"qwen3-max의 입력 및 출력 비용은 얼마인가요? 속도 제한은 어떻게 되나요?"_라고 물어보세요. 계층별 가격, QPM (Queries Per Minute), 컨텍스트 윈도우 (Context Window) 정보가 소스 파일 경로와 함께 한꺼번에 제공됩니다. 제가 처음 파일을 확인했을 때, 수치가 정확히 일치했습니다.

모델 제품군 간 필터링. _"128K 이상의 컨텍스트를 지원하며 함수 호출 (Function calling)이 가능한 모델은 무엇인가요?"_라고 물어보세요. 카탈로그 UI는 그런 방식으로 필터링할 수 없지만, 이 스킬은 한 줄에 모델 하나씩 구성된 models.jsonl 파일을 검색(grep)하여 정확한 필드 매칭을 수행합니다. 제가 실제로 가장 자주 묻는 질문은 반대의 경우입니다. 우리 대부분은 쉬운 작업은 저렴한 모델로 보내고, 어려운 문제에 비싼 모델을 아껴두기 때문입니다: "이 배치 분류 (Batch classification) 작업에 적합한 저렴한 모델은 무엇인가요?" 가격은 필터링할 수 있는 또 다른 필드일 뿐입니다. 터미널 사용자라면 에이전트를 아예 건너뛸 수도 있습니다 (해당 스킬의 자체 문서에 있는 예시):

jq -c 'select(.contextWindow>=1000000)' models.jsonl
grep '"function-calling"' models.jsonl | jq -c '{model,family,contextWindow}'

에디터 내 샘플 코드 및 파라미터 (Sample code and parameters, in-editor). samples 필드에는 curl/Python/Node.js/Java 형태의 공식 예제가 포함되어 있으며, predictConfig에는 플랫폼 플레이그라운드 (playground)와 일치하는 파라미터 이름, 기본값 및 범위가 포함되어 있습니다. 코딩 에이전트에게 질문하고, 붙여넣고, 조정하세요. 그리고 에이전트가 프로젝트에 연결하기 전에 그 자리에서 바로 샘플을 실행하여 검증하도록 하세요. 전체 루프가 에디터 내부에서 유지됩니다.

에러 코드 및 개념 (Error codes and concepts). 에러 코드는 로컬의 가공되지 않은 공식 문서 (raw official docs)에서 grep으로 검색됩니다. 더 이상 문서 사이트의 검색창과 씨름할 필요가 없습니다. 개념 질문(예: "이 플랫폼의 RAG 옵션은 무엇인가요?")은 미리 합성된 비교 페이지 (comparison pages)를 참조합니다.

업데이트 따라잡기 (Catching up on updates). 새로운 모델이 출시되었다는 소식을 들으면, 설치 명령어를 다시 실행하여 스냅샷 (snapshot)을 갱신한 다음, _"모델 목록에 무엇이 새로 추가되었나요?"_라고 질문합니다. 여기서 경계점을 유의하세요: 이것은 푸시 구독 (push subscription)이 아니라 사용자가 직접 갱신하는 스냅샷입니다. 저에게는 이것이 적절한 트레이드오프 (trade-off)입니다.

환각(Hallucination)을 일으키지 않는 이유

이 스킬의 규칙에는 세 가지 제약 사항이 내장되어 있습니다:

1. 답변은 반드시 실제 로컬 파일에서 가져와야 합니다. API, 파라미터, 에러 코드 또는 가격에 대해 모델의 기억(memory)으로 빈틈을 채워서는 안 됩니다.
2. 모든 답변은 사용자가 직접 열어서 확인할 수 있는 파일 경로를 인용합니다.
3. 충돌 우선순위: models/ (게이트웨이 데이터) > raw/ (공식 문서) > wiki/ (합성된 데이터). 품질이 낮은 합성 페이지는 자동으로 건너뜁니다.

환각 위험이 제로(zero)는 아니지만, "파일을 열어서 검증할 수 있음"은 "맞는 페이지를 찾은 것 같습니다"보다 훨씬 낫습니다.

솔직한 범위 (Honest scope)

Alibaba Cloud Model Studio를 사용하거나 Qwen 모델을 평가하는 사람들을 위해 구축되었습니다. 만약 귀하의 스택이 완전히 다른 제공업체에 있다면, 이 스킬은 즉흥적으로 답변하는 대신 의도적으로 범위를 벗어난 질문을 거부합니다. 이는 올바른 동작이지만, 해당 분야에서는 도움이 되지 않을 것입니다. 직접 테스트해보고 싶다면 무료 티어를 이용하세요: 가입하기.

제공업체 문서를 에이전트의 컨텍스트 (context)에 유지하기 위해 어떤 방식을 사용하시나요? Context7, llms.txt, 아니면 자체 제작한 방식인가요? 의견을 나누고 싶습니다.