공통 스킬 관리: 원본 하나, 배포본 둘

설치됐다는 말로는 부족했다

기존 스킬을 설치하고 연결을 확인하도록 AI에 맡겼다. 대상은 캘린더 작업을 위한 스킬이었다. AI가 내용을 읽어 보니 처음 예상한 MCP 연결이 아니라 gog CLI를 사용하는 방식이었다.

확인 결과 실행 도구는 설치돼 있었지만, 첫 인증 상태 점검에서는 저장된 토큰이 없었다. 스킬 파일과 실행 도구가 있다는 사실만으로 캘린더에 접근할 수 있다고 말할 수 없었다.

이때부터 설치 확인을 나눠 볼 필요가 생겼다.

앞 단계가 확인됐다고 다음 단계까지 완료되는 것은 아니었다. 이 기록에서 첫 연결 점검의 결론은 “도구는 있으나 인증이 확인되지 않음”이었다.

같은 대화에서 여러 AI 도구가 스킬을 함께 쓸 수 있게 해 달라는 요청도 했다. 이때 공통 원본과 배포 대상으로 정리한 것은 앞의 캘린더 스킬과 별개인 에이전트 생성용 스킬이었다.

두 작업을 구분해야 한다. 캘린더 사례는 실행 도구와 인증을 확인한 과정이고, 에이전트 생성 스킬은 같은 지침을 여러 도구에 배포한 과정이다. 캘린더 인증 문제를 공통 배포로 해결했다는 이야기는 아니다.

AI는 Ruler로 관리할 공통 원본을 두고 Codex와 Claude가 읽을 위치에 적용했다고 보고했다. 본문뿐 아니라 참조 문서와 자산도 함께 옮기고, 각 위치에 파일이 있는지 확인했다.

구조는 공통 원본에서 두 도구의 배포본으로 이어졌다. 도구마다 따로 고치기 시작하면 어떤 파일이 기준인지 흐려질 수 있으므로, 원본과 적용된 사본을 구분하는 것이 이 작업의 핵심이었다.

당시 보고로 확인한 범위는 공통 원본을 만들고 두 위치에 파일과 관련 자료를 적용했다는 것이다. Codex와 Claude에 같은 과제를 주고, 각각 해당 지침을 읽어 같은 규칙을 따르는지 비교한 결과는 없었다.

따라서 “두 곳에 파일이 있다”와 “두 도구에서 실제로 잘 동작한다”를 같은 결론으로 묶지 않았다. 앞의 캘린더 점검에서도 파일 존재와 실행 가능 여부가 달랐고, 공통 배포에서도 파일 전달과 지침 적용은 따로 확인해야 했다.

내 요청은 설치 후 연결 확인, 여러 AI에서의 재사용이었다. AI는 의존 도구와 인증 상태를 조사하고 공통 원본과 배포 위치를 정리했다. 그 결과 다음에 검사할 대상도 분명해졌다. 각 도구에서 실제 작업을 수행하며 지침과 참조 자료를 읽는지 확인하는 단계가 남았다.

이 글은 2026년 4월 4일 작업 기록을 바탕으로 썼다. 당시 배포를 현재 버전의 일반 설치법으로 제시하지 않으며, 이번 작성에서는 인증이나 도구 설정을 바꾸지 않았다.