내 Skill은 완료가 불가능한 구조였다

한 줄 요약

직접 만든 Skill을 공식 문서 기준으로 감사했더니, 완료 기준 하나가 내 실제 사용 조건에서 영원히 충족될 수 없는 항목이었습니다. 문장을 다듬어서는 안 나오고 구조를 다시 보고서야 나왔습니다. 그리고 개선본을 만들고 나서 덮어쓰지 않기로 했습니다 — 상위집합이 아니었거든요.

시작 전 상태

앞서 만든 Skill이 하나 있습니다. 카드 명세서를 읽어 가계부에 입력하는 절차인데, 이미 여러 번 고쳐서 실제 파일로도 잘 돌아갔습니다. 합계도 정확히 맞았고요.

그런데 매번 마지막에 걸렸습니다. 완료 선언을 못 했습니다.

그때는 "장부를 안 봐서 그렇지"라고 넘겼습니다. 원인이 다른 데 있는 줄은 몰랐습니다.

입력과 맥락

• 대상: 제가 직접 만든 Skill (learner-owned, 수정 자유)

• 제외: 스터디에서 배포받은 Skill 3종 — 라이선스상 원본 수정 금지라 읽기만 하고 손대지 않았습니다

• 원본은 SHA-256으로 스냅샷을 떠두고 시작했습니다

• 검증 입력은 앞서 쓰던 것과 동일한 카드 명세서 파일

내가 직접 내린 판단

공식 문서를 먼저 읽기로 했다. 그동안은 실측으로 규칙을 알아냈습니다 — 폴더 위치를 바꿔가며 어디에 둬야 인식되는지 확인하는 식으로요. 맞긴 했지만 "어쩌다 통한 것"과 "규격대로 한 것"은 다릅니다. 감사를 하려면 기준이 있어야 했습니다.

호출을 수동 전용으로 막았다. 이 Skill은 실제 가계부에 기록을 만듭니다. 공식 문서가 부작용 있는 작업에 권장하는 설정이 있어서 적용했습니다. 대신 자동으로 불려 나오는 편의를 잃었습니다.

도구 자체를 차단했다. "장부는 승인받고 읽어라"는 규칙이 그동안 본문 문장으로만 있었습니다. 안 지키면 그만이죠. 공식 필드로 도구를 아예 빼버리면 런타임이 막습니다. 지켜지길 기대하는 것과 못 하게 만드는 것은 다릅니다.

그리고 마지막에 덮어쓰지 않기로 했다. 이게 제일 늦게 내린 판단이고, 뒤에 씁니다.

만든 것 또는 해본 것

감사 — 11개 항목

공식 스펙과 대조한 결과 needs_change가 6개 나왔습니다.

구조 변경

BEFORE                    AFTER
skill/                    skill/
└─ SKILL.md (160줄)       ├─ SKILL.md (132줄)
                          └─ references/
                             ├─ 파일형식·청구주기 (87줄)
                             └─ 매핑규칙 (95줄)

본체는 짧아지고 전체 분량은 늘었습니다. 공식 문서의 원칙 — 긴 참조 자료는 필요할 때만 로딩된다 — 에 맞춘 결과입니다.

문서에서 알게 된 두 가지

읽지 않았으면 잘못 만들었을 것들입니다.

도구 차단은 영구가 아니었습니다. 다음 메시지를 보내면 해제됩니다. 세션 전체를 막으려면 권한 설정 쪽 규칙이 필요합니다. "구조적으로 막았다"고 쓸 뻔했는데, 정확히는 호출된 턴 동안만입니다.

Skill 본문은 한 번 로딩되면 다시 읽히지 않습니다. 세션 내내 그 상태로 남습니다. 그래서 "이 단계에서 한 번 하세요" 식으로 쓰면 뒤로 갈수록 흐려집니다. 상시 지시문으로 써야 합니다. 개선본 맨 앞에 "작업 내내 유효한 기준" 4개를 넣은 건 이 때문입니다.

증거와 관찰

동일 입력 Before/After

BEFORE : 38건 / 1,630,960
AFTER  : 38건 / 1,630,960

완전히 같습니다. 파싱·매핑 규칙을 안 건드렸으니 당연합니다. 이번 작업은 결과가 아니라 구조를 바꾼 것이고, 결과가 좋아졌다고 주장하지 않겠습니다.

가장 큰 발견

원본 완료 기준에 이 항목이 있었습니다.

[ ] 중복 대사를 실행했고 결과를 보고했다

그런데 저는 이 작업에서 실제 장부를 읽지 않기로 정했습니다. 즉 이 항목은 제 환경에서 영원히 체크될 수 없습니다. 아무리 잘 돌아도 완료에 도달 못 하는 Skill이었던 겁니다.

실제로 그 일이 일어났습니다 — 판별 못 한 건 0개, 합계 정확히 일치, 그런데도 완료 불가.

Skill의 완료 기준이 제 실제 운영 조건과 어긋나 있었습니다. 이건 문장을 고쳐서는 안 보이고, 구조를 처음부터 다시 보고 나서야 보였습니다.

부수적으로 이름과 역할도 어긋나 있었습니다. 설명은 "명세서를 입력한다"였는데, 실제로 값을 낸 일은 제안표를 만드는 것이었습니다. 설명문은 이 Skill을 언제 쓸지 판단하는 근거라서, 역할과 어긋나면 엉뚱한 상황에 불려 나옵니다.

실패·막힘·수정

개선본이 더 낫지 않았습니다

만들고 나서 덮어쓰려다가 멈췄습니다. 개선본이 원본의 상위집합이 아니었기 때문입니다.

특히 첫 줄이 뼈아팠습니다. 절대경로를 없애려고 참조 자료를 안으로 복사했는데, 자립성을 얻고 동기화를 잃었습니다. 마침 같은 날 원본 규칙 문서를 고쳤는데, 개선본은 그걸 모릅니다.

대신 개선본에 "작업 시작 시 원본 문서가 갱신됐는지 확인하고, 어긋나면 원본이 정본" 이라는 지시를 넣어 완화했습니다. 없앤 게 아니라 줄인 겁니다.

그래서 덮어쓰지 않고 다른 이름으로 나란히 설치했습니다. 원본은 그대로 두고, 개선본은 별도 이름으로 추가했습니다. 설치 전후 원본 해시가 동일한 걸로 무손상을 확인했습니다.

읽고 제안하는 일은 개선본이 낫고, 실제 입력은 원본에만 있습니다. 하나가 하나를 대체하는 관계가 아니었습니다.

not_checked로 남긴 것

발견 여부를 제 쪽에서 확인할 수 없습니다. 자동 호출을 끄면 설명문이 에이전트 컨텍스트에 올라가지 않기 때문입니다. 즉 목록에 안 보이는 게 정상 동작입니다.

앞서 다른 Skill을 설치했을 때는 즉시 목록에 떠서 확인이 됐는데, 이번엔 우리가 고른 설정 때문에 그 확인 경로가 막혔습니다. 사용자가 명령 메뉴를 열어 보는 것으로만 확인됩니다.

그 외에 확인 못 한 것 — CLI 실제 버전, MCP 서버 단위 차단 문법(그래서 도구 8개를 하나씩 나열했습니다).

결과와 다음 실험

이번 과제의 이름은 "확장"인데, 실제로 한 일의 절반은 덜어내기였습니다. 입력 경로를 빼고, 도구를 막고, 완료 기준에서 도달 불가능한 항목을 뺐습니다. 남은 것이 실제로 쓰던 기능과 일치했습니다.

그리고 개선본을 만들고 나서야 원본이 왜 그렇게 생겼는지 알았습니다. 원본에 있던 장부 절차는 군더더기가 아니라, 제가 안 쓰기로 한 경로였을 뿐입니다. 그래서 지우지 않고 남겼습니다.

다음 하나만 고른다면 — 동기화 리스크를 구조로 푸는 것입니다. 지금은 "확인하라"는 지시로 막아뒀는데, 이건 결국 지켜지길 기대하는 방식입니다. 오늘 배운 게 바로 그 방식의 한계였고요. 규칙 문서를 참조 폴더 안으로 옮기든, 생성 시각을 비교하는 절차를 두든, 사람이 기억하지 않아도 되게 만드는 쪽이 맞습니다.

watchdog_handoff:
  program: 지피터스 23기 에이전트하네스
  week: W1
  source_skill: w1-extension-assignment
  learner_display_name: whooing
  candidate_title: "내 Skill은 완료가 불가능한 구조였다"
  learner_claimed_url: none
  source_status: draft
  decision_authority: watchdog
  skill_decision: not_performed
  watchdog_live_verification: required
  reward_delivery: separate_downstream_operation