저의 지난 기사에서, 한 독자의 댓글이 SKILLmama 설계의 허점을 드러냈고, 저는 이를 수정하기 위해 Phase 1.5를 출시했습니다. 이번에는 아무도 저에게 지적할 필요가 없었습니다. 제가 아주 오래전에 했어야 했던 일을 했습니다. 실제로 Antigravity를 열고, 저의 README를 따르며, 어떤 일이 일어나는지 지켜본 것입니다.

작동하지 않았습니다.

기록 (The Recording)

SKILLmama는 네 가지 에이전트 — Claude Code, Claude.ai, OpenAI Codex, 그리고 Antigravity — 를 지원하며, README는 항상 이 네 가지 모두에 대해 동일한 것을 약속해 왔습니다: 설치한 다음, 기능에 관한 질문을 하면 호환성/인기/유지보수/단순성 분석이 포함된 점수가 매겨지고 순위가 지정된 추천을 받는다는 것입니다.

저는 Antigravity에 대해 그 주장을 실제로 검증해 본 적이 없었습니다. 그래서 그것을 열고 다음과 같이 입력했습니다:

find me the best vector database for a Python project

그리고 평범하고 일반적인 답변을 받았습니다. 스택 스캔 (stack scan)도 없었습니다. 제약 조건 질문도 없었습니다. 점수 테이블도 없었습니다. 그저 기술 (skill)이 전혀 로드되지 않은 일반적인 어시스턴트에게서 받을 법한 자유 형식의 응답뿐이었습니다.

SKILLmama가 실행되고 있지 않았습니다. 실행하려고 시도조차 하지 않았습니다.

잘못된 추측들 (The Wrong Guesses)

저의 첫 번째 가정은 합리적이었습니다: 제가 사람들에게 사용하라고 말해왔던 npx skills add CLI가 Antigravity가 확인하지 않는 경로에 설치하고 있는 것이 틀림없다고 생각했습니다. 저는 실제 경로를 찾기 위해 CLI 자체의 소스(vercel-labs/skills)를 읽으러 갔습니다. 답처럼 보이는 것을 찾았습니다. 그곳에 스킬 파일을 수동으로 복사했습니다. Antigravity를 재시작했습니다. 다시 테스트했습니다.

여전히 아무것도 없었습니다. 똑같이 일반적인 답변이 나왔습니다.

두 번째 추측. 아마도 디렉토리를 완전히 잘못 지정했을 수도 있습니다. CLI의 에이전트 설정 (agent config)에서 그럴듯해 보이는 다른 경로를 시도했습니다. 다시 재시작했습니다. 다시 테스트했습니다.

여전히 아무것도 없었습니다.

연속으로 두 번의 잘못된 추측은 보통 당신이 잘못된 계층 (layer)을 디버깅하고 있다는 신호입니다. 저는 _스킬을 관리하는 도구_를 역공학 (reverse-engineering) 하고 있었는데, 사실은 _에이전트 자체_가 어디를 탐색하는지에 대해 무엇을 문서화하고 있는지를 읽었어야 했습니다.

진짜 정답은 내가 읽지 않았던 문서에 있었다

antigravity.google/docs/skills — Antigravity가 스킬 (skills)을 어떻게 발견하는지에 대한 실제 공식 문서입니다. 저는 이전에 단 한 번도 이 문서를 열어본 적이 없었습니다.

문서에는 두 가지 위치가 명확하게 명시되어 있습니다:

Project scope: <workspace-root>/.agents/skills/<skill-folder>/
Global scope:  ~/.gemini/config/skills/<skill-folder>/

제가 했던 두 가지 추측 중 어느 것도 일치하지 않았습니다. 제가 진실 (ground truth)로 믿었던 CLI의 소스 코드 자체는 Antigravity가 절대 찾아보지 않을 곳을 가리키고 있었습니다.

저는 스킬을 실제 경로로 복사하고, Antigravity를 한 번 더 재시작한 뒤 직접 물었습니다: "설치된 스킬은 무엇인가요?"

SKILLmama — AI-Native Capability Discovery Engine

그곳에 있었습니다. Global & Built-in Skills 아래에 목록으로 표시되어 있었고, Antigravity 자체의 네이티브 명령 (native commands) 바로 옆에 자리 잡고 있었습니다. 저는 동일한 벡터 데이터베이스 (vector-database) 질문을 다시 던졌고 — 이번에는 명시적으로 호출하여 — README가 내내 약속했던 결과, 즉 제약 조건 질문 (constraint question)과 그에 따른 점수화된 분석 (scored breakdown)을 정확히 돌려받았습니다.

작동했습니다. 다만 제가 사람들에게 설치하라고 말해왔던 방식으로는 작동하지 않았을 뿐입니다.

루프 닫기 (Closing the Loop)

실제 재현 (repro) 사례를 확보한 후, 다른 사람들도 이미 이 문제를 겪었는지 확인해 보았습니다. 그리고 vercel-labs/skills에서 Antigravity가 실제로 필요로 하는 바로 그 수정 사항을 요청하는 오픈 이슈 (open issue)를 발견했습니다. 저는 그 이슈에 제가 발견한 재현 사례를 추가했습니다: 현재 CLI가 설치하는 방식, Antigravity가 실제로 읽는 방식, 그리고 이 불일치 (mismatch)를 재현하는 방법입니다. 제가 수정해야 할 리포지토리 (repo)는 아니지만, 이를 수정할 사람을 위해 증거를 남겨둘 가치는 있었습니다.

이제 README는 (가정된 것이 아닌) 확인된 올바른 경로로의 수동 설치를 가장 먼저 안내하며, CLI는 현재 어디서 문제가 발생하는지에 대한 명시적인 경고와 함께 보조적인 옵션으로만 언급합니다.

보너스: 그 과정에서 발견한 것

Antigravity 버그를 추적하는 과정에서, 같은 작업 과정 중에 수정할 가치가 있는 두 가지 사항을 추가로 발견했습니다:

점수 산정(Scoring)이 더 정직해졌습니다. 이전에는 호환성 점수(Compatibility score)가 단순히 감지된 스택(stack)을 기반으로 추론되었습니다. 이제 점수를 매기기 전에, SKILLmama는 실제 환경을 확인합니다. 필요한 환경 변수(env var)가 .env.example에 존재하나요? CLI가 PATH에 설정되어 있나요? 이제 누락된 의존성(dependency)은 조용히 부풀려진 숫자가 아니라 점수상의 플래그(flag)로 나타납니다.

네 개의 어댑터(adapters)가 조용히 서로 달라져 있었습니다. codex/AGENTS.md와 antigravity/PROMPT.md에는 이미 폐기된 이전의 2단계 아키텍처(two-stage architecture)의 잔재가 남아 있었습니다. 즉, Codex와 Antigravity가 실제로 실행하던 지시 사항(instructions)이 skillmama/SKILL.md에 있는 표준 파이프라인(canonical pipeline)과 미묘하게 어긋나 있었습니다. 세 가지 모두 동일한 로직을 실행하도록 통합하였으며, 진정으로 에이전트(agent)별로 특화된 부분(설치 구문 등)만 다르게 남겨두었습니다.

변경 사항

이 모든 내용은 v1.4.3에 반영되었습니다. 특히 Antigravity의 경우:

mkdir -p ~/.gemini/config/skills/skillmama
curl -sL https://raw.githubusercontent.com/Magithar/SKILLmama/main/skillmama/SKILL.md \
  -o ~/.gemini/config/skills/skillmama/SKILL.md

Antigravity를 재시작한 다음, 명시적으로 호출하십시오: SKILLmama find me a vector database for this project.

github.com/Magithar/SKILLmama — Apache 2.0.

이 교훈은 사실 Antigravity에 관한 것이 아니었습니다. "README에 작동한다고 적혀 있다"와 "작동하는 것을 직접 보았다"는 서로 다른 주장이며, 저는 전자를 충분하다고 간주해 왔다는 점입니다. 그것은 충분하지 않습니다. 만약 하나 이상의 플랫폼을 위한 설치 지침(install instructions)이 포함된 무언가를 유지 관리한다면, 직접 실행해 보십시오. 당신이 작성했던 기억 속의 해피 패스(happy path)가 아니라, 바로 오늘, 실제 경로를 말입니다.