[Claude Code] 내 AI 봇이 ATP 요청에 스킬을 못 찾는 이유를 찾았다 — 설명문이 57자에서 잘리고 있었다

[Claude Code] 내 AI 봇이 ATP 요청에 스킬을 못 찾는 이유를 찾았다 — 설명문이 57자에서 잘리고 있었다

📝 한줄 요약

스킬을 계속 만들기만 하다가 관리 기준이 없다는 걸 깨닫고 4계층 학습자료를 적용했는데, 그 과정에서 내 핵심 업무 스킬의 설명문이 인덱스에서 field sensor and A...로 잘려 있는 걸 발견했습니다.

바쁘시면 이것만 읽어도 돼요

• 스킬 설명문(description)은 전체가 AI에게 보이지 않습니다. 제 런타임은 앞 57자만 인덱스에 넣습니다. 실측했습니다.

• 노출 중인 스킬 94개 중 **26개(28%)**가 정확히 57자에서 잘려 있었습니다.

• 그중 하나가 ATP/RLU 워크북 스킬이었고, ATP의 A 한 글자에서 잘렸습니다. ATP 요청에 이 스킬이 후보로 안 떠오를 수 있습니다.

• 새 스킬 3개를 만들려다 중복 판정을 먼저 했더니 3개 중 2개가 기존 스킬과 겹쳤습니다. 만들지 않고 경계를 나눴습니다.

• 결함을 고치려는데 다른 결함 스킬은 배포본이라 수정 금지였습니다. "고칠 수 있는 것"과 "고칠 수 없는 것"을 나누는 게 첫 관문이었습니다.

• 원본은 한 줄도 고치지 않았고, 별도 후보(candidate) 파일만 만들었습니다. 설치·실행 검증은 안 했고 전부 not_checked로 남겼습니다.

🎯 이런 분들께 도움돼요

• AI 스킬(또는 커스텀 지시문)을 여러 개 만들었는데 어떤 게 언제 불리는지 모르는 분

• "분명히 만들어뒀는데 AI가 안 쓴다"를 겪은 분

• AI에게 자료를 읽히고 "이제부터 이렇게 하자"고 시켰는데, 정말 반영됐는지 확인하고 싶은 분

• 남이 배포한 스킬·플러그인을 내 맘대로 고쳐도 되는지 헷갈리는 분

비개발자도 읽을 수 있게 썼습니다. 소스코드는 없습니다.

😫 문제 상황 (Before)

핵심 1 — 만들기만 했고, 관리 기준이 없었다

제 AI 봇에는 스킬이 114개 쌓여 있었습니다. 필요할 때마다 하나씩 만들었고, 만드는 법은 알았지만 관리하는 법은 몰랐습니다.

• 비슷한 스킬이 이미 있는지 확인하는 절차가 없었습니다.

• 스킬끼리 어떤 관계인지(A 다음에 B를 쓴다, A가 B를 대체했다) 기록하는 자리가 없었습니다.

• 무엇보다, 어떤 스킬이 언제 불리는지를 결정하는 게 무엇인지 몰랐습니다.

핵심 2 — 4계층 자료를 받고 봇에게 학습을 시켰다

"스킬 관리 4계층"이라는 학습자료를 받았습니다. 요지는 스킬이 늘어날 때 무너지는 순서가 있다는 것입니다.

성숙도 등급표가 아니라 실패 계보입니다. 각 층은 앞 층 해법이 만든 새로운 실패를 처리하려고 생겼습니다. 그래서 순서를 건너뛸 수 없습니다.

저는 이 자료를 제 AI 봇에게 읽히고 이렇게 지시했습니다.

이 자료 읽고, 우리가 스킬 만들 때 이 기준을 쓰자.

이 지시가 나중에 문제가 됩니다. 뒤에서 다시 나옵니다.

핵심 3 — 그리고 새 스킬 3개를 요청했다

두개 파일을 병렬로 매우 상세히 분석하고 나에게 설명해줘. 그리고 AI 봇에게 현재 읽고
우리가 스킬을 만들때 사용하자고 설명시켰는데 잘 반영하고 있는지 파악하고 사례글 하나를
작성해야하는데, 회의록 작성 스킬, ATP 측정 보고서, 영상만들기 스킬 등을 병렬로 작업해서
만들어보고 각 스킬별로 사례글을 만들자.

여기서 "만들어보고"가 그대로 실행되지 않았습니다. 왜 그런지가 이 글의 첫 반전입니다.

🛠️ 사용한 도구

대상 런타임과 버전: Hermes Agent 0.19.0, git 설치, 업데이트 지연 0.

공식 문서 확인 여부: 웹 공식 Docs는 열지 않았습니다(not_checked). 대신 두 가지로 대체했습니다.

1. 런타임에 설치된 스킬 작성 가이드(hermes-agent-skill-authoring, 197행)

2. 실행 중인 런타임이 저장한 스킬 프롬프트 스냅샷 파일(56,370 bytes) 직접 파싱

즉 "문서가 이렇다더라"가 아니라 **"내 런타임이 실제로 이렇게 하고 있다"**를 근거로 썼습니다. 다만 최신 웹 문서와 설치본 0.19.0의 차이는 대조하지 못했습니다.

🔧 작업 과정

에피소드 1 — 만들기 전에 물었다: "이미 있는 거 아냐?"

4계층 자료의 ③Taxonomy 층은 이렇게 묻습니다. "사실상 같은 일을 하는 스킬이 둘 이상 있는가?"

보통 이 질문은 만든 다음에 합니다. 저는 만들기 전에 했습니다. 기존 스킬 114개에서 겹칠 만한 것을 찾아 전문을 읽고 판정했습니다.

3개 중 2개가 중복 후보였습니다. 그래서 방침을 바꿨습니다. 새로 만드는 대신 경계를 나눴습니다.

• 기존 워크북 스킬 = 데이터 파일(XLSX)을 만든다

• 새 보고서 스킬 = 그 값의 의미를 쓴다

• 둘 사이에 "이어서 쓴다"는 관계를 명시한다

만들기 전에 5분 물어본 덕분에 스킬 2개를 안 만들었습니다. 이게 ③Taxonomy 층이 실제로 하는 일입니다.

에피소드 2 — "앞 57자만 인덱싱된다"가 정말인지 재봤다

학습자료에는 이런 문장이 있었습니다.

인덱스에 노출되는 description은 대개 앞부분만 잘려 들어간다(예: 첫 57자).

"예: 첫 57자"라고 예시로만 적혀 있었습니다. 런타임마다 다를 수 있는데 확인 방법은 안 주더군요. 그래서 직접 쟀습니다. 실행 중인 런타임이 저장해 둔 스킬 프롬프트 스냅샷을 파싱했습니다.

manifest 등재 스킬:      120개
프롬프트 실제 노출:       94개  (26개는 미노출)
description 총 문자수:    5,269자
description 평균 길이:    56.1자
description 최대 길이:    60자   ← 예외 없음
57자에서 잘린 스킬:      26/94 (28%)
잘린 형태:              앞 57자 + "..." = 정확히 60자
앞 57자가 충돌하는 그룹:  0개

판정: 사실이었습니다. 최대 길이가 60자에서 딱 끊기고, 잘린 것들은 예외 없이 57자 + "..." 형태입니다. 추정이 아니라 실측입니다.

숫자가 세 개 나와서 헷갈릴 수 있어 정의를 붙입니다. 셋 다 사실이고 서로 다른 것을 셉니다.

디스크에 114개가 있고, 등록 목록에는 120개가 잡히고(하위 폴더 구조 차이), 그중 실제로 AI가 보는 목록에는 94개만 올라갑니다. 나머지는 관리 도구가 오래된 것으로 분류해 뺐습니다. 이 글에서 "스킬 114개"는 디스크 기준입니다.

그리고 여기서 진짜를 발견했습니다.

에피소드 3 — 내 핵심 업무 스킬이 A 한 글자에서 잘려 있었다

잘린 26개 목록을 훑다가 멈췄습니다. 인덱스에 실제로 노출되던 문자열입니다.

Create polished XLSX/CSV workbooks for field sensor and A...

원문 설명은 이렇게 이어집니다. ...for field sensor and ATP/RLU measurement comparisons, preserving raw data, matching records by time... 총 336자입니다.

하필 ATP의 A 한 글자에서 잘렸습니다.

인덱스만 보는 모델에게 이 스킬은 "현장 센서와 A… 관련 XLSX"입니다. ATP도 RLU도 인덱스에 없습니다. 판정 근거가 사라진 겁니다.

이게 왜 비싼 자리인지가 중요합니다. 이 스킬은 제가 봇 기억 파일에 따로 저장까지 해 둔 핵심 업무를 담당합니다. 현장 측정값을 하나의 비교 워크북 파일로 만드는 일입니다. 그런데 "ATP 정리해줘"라고 말했을 때 이 스킬이 후보 목록에 안 뜰 수 있습니다.

한 가지는 정직하게 밝힙니다. 저는 라우팅 발동 로그를 확인하지 못했습니다. 미발동 위험은 잘린 문자열에서 나온 구조적 추론이고, "실제로 안 불린 사례"를 증거로 잡은 게 아닙니다.

원인은 명확했습니다. 원본 설정 파일 앞부분이 딱 2줄이었습니다.

name: field-measurement-workbooks
description: Create polished XLSX/CSV workbooks for field sensor and ATP/RLU ...

이게 전부입니다. 버전, 작성자, 라이선스, 태그, 관계 정보가 전부 없었습니다. 설명문 336자를 한 필드에 몰아넣었고, 인덱스는 그중 57자만 봤습니다.

참고로, 스킬 114개를 전수 조사해서 4계층 관계 필드가 있는지 세어 봤습니다.

관계 필드 검색 매칭:                    3 / 114
그중 실제 설정값(기계가 읽는 자리):        1 / 114
그중 본문 산문에만 있던 것:              2 / 114

114개 중 관계가 제대로 기록된 스킬은 딱 1개였습니다. 이건 스킬 하나의 결함이 아니라 컬렉션 전체의 미구현이었습니다.

에피소드 4 — 고치려니까, 고치면 안 되는 게 섞여 있었다

결함이 하나 더 나왔습니다. 논문 작성 스킬의 관계 목록에 이미 삭제된 스킬 이름이 남아 있었습니다. 본문에는 "이 스킬이 그걸 흡수했다"고 산문으로만 적혀 있었습니다. 기계가 읽을 수 있는 자리로는 옮겨지지 않은 겁니다. 끊어진 연결선(dangling edge)입니다.

찾았으니 고치면 되겠다 싶었는데, 확장과제 규칙을 읽고 손을 멈췄습니다. 규칙의 첫 관문이 이거였습니다.

allowed가 아니면 변환하지 않습니다. Factory 배포 Skill 원본은 수정하지 않습니다.

그래서 소유권을 판정했습니다. 런타임에 배포본 목록 파일(76줄, 이름:해시 형식)이 있었고, 여기 등재된 스킬은 배포본이라 로컬에서 고치면 안 됩니다.

끊어진 연결선을 가진 그 스킬이 blocked였습니다. 고치면 다음 업데이트에 덮어써지거나 해시가 안 맞습니다. 관할이 제 쪽이 아닙니다. 그래서 고치지 않고 업스트림 보고 대상으로만 정리했습니다.

반대로 변환 대상으로 고른 워크북 스킬은 배포본 목록에 없었습니다. 제 세션에서 봇이 만든 개인 스킬이고, 설정 파일에 라이선스 필드 자체가 없었습니다. 그래서 "라이선스가 허용한다"가 아니라 **"대조할 대상이 없다"**로 남겼습니다.

source_rights:
  learner_owned: true
  explicitly_modifiable_exercise_copy: true
  third_party_license_allows_modification: unknown
  factory_distributed_protected_skill: false
  verdict: allowed

이 게이트가 이번 과제에서 제일 배운 부분입니다. 결함을 찾는 것보다, 그 결함을 내가 고쳐도 되는지 판정하는 것이 먼저였습니다.

에피소드 5 — 원본은 손대지 않고, 사본과 후보를 따로 만들었다

순서는 이렇게 갔습니다.

1. 원본 스냅샷 — 원본을 별도 폴더에 그대로 복사. 원본 해시와 사본 해시를 양쪽에서 계산해 같은 값임을 확인했습니다.

2. 호환성 감사 — 12개 항목을 compatible / needs_change / blocked / not_checked로 판정했습니다.

3. 별도 후보 작성 — 원본 경로가 아니라 작업 폴더 안 runtime-native-candidate/에 새 버전을 만들었습니다.

4. 기계 검사 7항목 — 후보 파일에 실제로 실행했습니다.

감사 결과 분포입니다.

바꾼 것 중 핵심 3가지입니다.

핵심 1 — 설명문을 336자에서 114자로 줄이고, 앞 57자에 판정 근거를 넣었다

형식을 3종 세트로 바꿨습니다. Trigger / Negative-trigger / Differentiator. 인덱스에 잘려 들어가도 트리거 절 전체가 살아남는 형태입니다.

Before(336자) → Create polished XLSX/CSV workbooks for field sensor and A...
After (114자) → Trigger: ATP/RLU·센서 XLSX 비교 워크북. Negative-trigger: 해석 보고서...

앞 57자 충돌 그룹이 0개였으므로, 새 문자열이 기존 스킬과 앞머리 충돌을 만들지도 않습니다. 다만 이건 문자열 계산 결과입니다. 런타임이 실제로 이 문자열을 어떻게 잘라 넣는지는 확인하지 않았습니다.

핵심 2 — 짧은 판정용과 긴 판정용을 분리했다

①Indexer는 짧아야 하고(예산), ②Navigator는 길어야 합니다(정확도). 한 필드로 둘 다 만족시킬 수 없습니다. 그래서 짧은 routing(인덱스 노출용)과 긴 routing_detail(본문 판정용)로 이중화했습니다. 그리고 Negative-trigger로 인접 스킬 2개를 명시적으로 밀어냈습니다 — 해석 보고서는 저쪽, 렌더링 검수는 저쪽이라고 적었습니다.

핵심 3 — 관계는 억지로 채우지 않았다

④Ontology 층에는 관계 4종이 있습니다. 저는 이 중 1개만 채우고 3개를 빈 배열로 두고 그 이유를 파일 안에 주석으로 남겼습니다.

• chains_with에 검수 스킬 1개만 넣었습니다. 상류 보고서 스킬이 이미 이쪽을 향하는 연결선을 갖고 있어서, 되받으면 A→B, B→A 순환이 됩니다. 4계층 공리 "cycle 금지" 위반입니다. 그래서 의도적으로 비웠습니다.

• depends_on은 빈 배열입니다. 이 스킬을 돌리기 전에 반드시 실행해야 하는 스킬이 없습니다.

• variant_of, supersedes도 빈 배열입니다. 해당하는 대상이 없습니다.

학습자료가 미리 경고한 게 정확히 이 지점입니다. "표현력(그릇이 있다)과 채움(실제로 채워졌다)은 다르다." 그릇이 있다고 억지로 채우면 그게 다음 사람에게 거짓 정보가 됩니다.

에피소드 6 — 봇을 감사했다. 봇은 잘못이 없었다

원래 질문으로 돌아갑니다. "봇에게 4계층 자료를 읽히고 쓰자고 했는데, 반영했나?"

봇이 남긴 학습 기록을 찾았습니다. learnings/ 아래 2,911 bytes 파일과 날짜별 메모리 파일의 해당 절. 시각은 2026-07-26 23:30입니다.

원문과 한 줄씩 대조했습니다. 왜곡·누락이 없었습니다.

체크리스트 7항목까지 만들었습니다. 그중 4번이 이겁니다.

기존 유사 스킬을 확인했고, 중복이면 patch/merge/supersedes 후보를 판단했는가?

그리고 봇은 이 파일을 스스로 **"규칙 승격 전 학습 메모"**로 격을 낮춰 표시했습니다. "적용했다"고 말하지 않고 "적용 기준으로 정리했다"고 썼습니다. 과장 보고가 아니었습니다.

그런데 실제 스킬 파일에는 0건 반영이었습니다.

학습→기록은 PASS, 기록→실행은 FAIL입니다.

여기서 봇을 탓하려다 멈췄습니다. 제 지시를 다시 봤습니다.

이 자료 읽고, 우리가 스킬 만들 때 이 기준을 쓸게.

"만들 때"였습니다. "기존 114개를 점검해라"가 아니었습니다. 봇은 지시받은 범위를 정확히 수행했습니다. 자기 체크리스트 4번을 자기 컬렉션에 한 번도 돌려보지 않은 건, 돌려보라고 시키지 않았기 때문입니다.

AI가 시킨 대로 안 한 게 아니라, 제가 시킨 게 그것뿐이었습니다.

✅ 결과 (After)

구조 비교 — 실행 검증은 안 했다

먼저 분명히 합니다. 동일 입력으로 Before/After를 실행하지 않았습니다. 후보를 설치하지 않았고, 같은 입력을 양쪽에 넣어 돌려보지도 않았습니다. 따라서 아래 표의 상태는 **전 행 not_checked**이고, 기록하는 건 구조 차이뿐입니다. 결과가 좋아졌다는 주장은 이 글에 없습니다.

구조 차이 수치

후보 파일에 실제 실행한 기계 검사 7항목

3번을 PASS로 올리지 않은 이유는 정직하게 남깁니다. 후보가 과제 규정상 임시 폴더에 있어서, 지금 시점에는 이름과 폴더명이 다릅니다. 일치는 원본 경로로 설치한 뒤 성립합니다. 설치하지 않았으니 PARTIAL입니다.

4번도 그냥 PASS로 두면 과장입니다. 이 스캔이 본 것은 경로·비밀번호·API 키뿐이고, 시설명이나 거래처명은 보지 않았습니다. 시설명으로 다시 훑으면 후보 파일에 3건이 남습니다. 다만 세 건 모두 원래 스킬이 이미 갖고 있던 문자열이고, 그중 둘은 실제 참고자료의 파일명이라 바꾸면 링크가 끊깁니다(6번 검사가 그 이름으로 통과했습니다).

그래서 판정을 이렇게 갈랐습니다. 내 개인 스킬로 쓰는 동안은 현 상태 유지, 외부에 공유하기 전에는 시설명을 지운다. 이 글에는 그 문자열이 들어가지 않았습니다.

이걸 적는 이유가 있습니다. "스캔 통과"라고만 쓰면 읽는 사람은 모든 민감정보를 봤다고 믿습니다. 검사가 무엇을 안 봤는지 같이 적어야 그 PASS가 쓸모 있습니다.

5번의 "주 1건"도 숨기지 않습니다. 최종 응답 예시 블록에 <실제 산출 파일 절대경로>라는 꺾쇠 슬롯을 의도적으로 남겼습니다. 원본에 있던 가짜 절대경로 문자열 2건을 없애려고 바꾼 형태입니다. 미완성 자리표시자와는 다르지만, 스캔에 걸린다는 사실 자체는 기록합니다.

원본 무변경 증거

원본 스킬 폴더 아래 파일을 한 건도 수정·생성하지 않았습니다. 원본 수정 시각도 그대로입니다.

산출물 6종

extension-assignment/
├─ source-rights.md                  ← 소유권 판정 + 런타임 확인
├─ original-skill-snapshot/           ← 원본 사본 + 해시
├─ runtime-compatibility-audit.md     ← 12항목 감사
├─ runtime-native-candidate/          ← 별도 후보 (설치 안 함)
├─ before-after.md                    ← 구조 비교 (전 행 not_checked)
└─ watchdog-handoff.yaml              ← 판정 권한 넘김

하지 못한 것 — 전부 not_checked

• 공식 웹 Docs 미열람. 설치본 가이드 + 런타임 스냅샷 실측으로 대체했습니다. 최신 문서와 0.19.0의 차이는 대조 못 했습니다.

• 후보를 설치하지 않음 → 발견(discovery)·호출(invocation) 미확인. 승인 게이트를 hold로 남겼습니다.

• 동일 입력 실행 Before/After 미수행 → 구조 비교만.

• 라우팅 발동 로그 미확인 → 미발동 위험은 구조적 추론입니다.

• 기존 스킬 파일 수정 0건.

다음에 확인할 것

1. 후보를 원본 경로에 설치(별도 승인 필요) → 새 세션에서 인덱스 노출 문자열을 실측해 앞 57자 계산이 맞는지 대조

2. 관계가 가리키는 두 스킬을 같이 설치해 연결선 해소

3. 같은 센서 데이터 + 같은 수기 측정값으로 Before/After를 실제 실행해 이 표의 not_checked를 채우기

4. 배포본 스킬의 끊어진 연결선을 업스트림에 보고

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

핵심 1 — "정말 그런지 재봐"가 가장 값진 지시였다

학습자료의 "예: 첫 57자"를 그냥 믿었다면 아무것도 못 찾았습니다. AI에게 런타임에서 직접 측정하게 시켰더니 사실 확인 + 실제 결함 발견이 한 번에 나왔습니다. 요청에 없던 작업이었는데 여기서 이 글의 주제가 나왔습니다.

핵심 2 — 만들기 전에 중복을 물었다

"만들어줘"라고 하면 AI는 만듭니다. 만들기 전에 **"이미 있는 거 아냐?"**를 한 단계 넣으면 3개 중 2개를 안 만듭니다. 안 만든 게 성과입니다.

핵심 3 — "못 한 건 못 했다고 써"를 명시적으로 시켰다

AI는 완결된 보고서를 쓰려는 경향이 있습니다. not_checked라는 단어를 쓸 자리를 미리 정해주면 정직해집니다. 이번 결과물의 not_checked 5건은 전부 이 지시에서 나왔습니다.

핵심 4 — 지적을 사실로 확인시켰다

"AI가 만든 스킬에 렌더링 검수가 없을 것"이라고 지적했더니, AI가 방금 만든 3개 파일을 grep으로 검증해서 줄바꿈·표 넘어감 검수 항목 0건, 핵심 1/2/3 패턴 0건을 확인했습니다. 제 지적이 맞았음을 AI가 증거로 확인한 뒤 고쳤습니다. 지적만 하면 AI는 사과하고 넘어갑니다.

이렇게 하면 안 돼요

"앞으로 쓰자"는 과거를 안 건드립니다

제가 봇에게 준 지시는 이 기준을 스킬 만들 때 쓰자였습니다. 봇은 정확히 그것만 했습니다. 기존 114개는 그대로였습니다. 범위를 안 적으면 AI는 "앞으로"만 합니다. 이렇게 써야 했습니다.

이 기준을 앞으로 쓰고, 기존 스킬 전체에도 한 번 돌려서 위반 목록을 만들어줘.

결함을 찾자마자 고치면 안 됩니다

저는 끊어진 연결선을 찾고 바로 고칠 뻔했습니다. 그 스킬은 배포본이었습니다. 고치면 다음 업데이트에 덮어써지고, 해시가 안 맞고, 남의 저작물을 무단 변경한 게 됩니다. "이거 내가 고쳐도 되는 파일인가"가 결함 발견보다 먼저입니다.

빈 칸을 채우려고 관계를 만들면 안 됩니다

관계 필드 4개가 비어 있으면 채우고 싶어집니다. 저는 1개만 채우고 3개는 빈 배열 + 이유 주석으로 남겼습니다. 되받아 걸면 순환이 생겨서 공리 위반이 됩니다. 그릇이 있다고 채우는 건 다음 사람에게 거짓 정보를 넘기는 겁니다.

"구조가 바뀐 것"과 "결과가 좋아진 것"을 섞으면 안 됩니다

이 글에서 가장 조심한 부분입니다. 설명문 앞 57자에 ATP/RLU를 넣은 건 구조 변경입니다. 그래서 호출이 실제로 개선됐는지는 모릅니다. 설치도 안 했고 실행도 안 했습니다. AI에게 사례글을 쓰라고 하면 이 둘을 섞어서 "개선됐다"고 씁니다. 명시적으로 금지해야 합니다.

🌍 다른 업무에 적용한다면?

이 작업의 핵심 3가지는 스킬 관리 밖에서도 그대로 쓸 수 있습니다.

첫째, "목록에 있는데 안 불린다"는 이름 문제입니다

• 폴더·파일명: 앞부분만 보이는 자리(파일 탐색기, 탭, 검색 결과)에 판정 키워드가 있는지

• 문서 제목: 사내 위키 검색 결과에 제목 앞 절반만 뜰 때 무슨 문서인지 구분되는지

• 회의 안건: 캘린더 목록에서 잘려 보이는 앞부분에 핵심이 있는지

Use when..., 2026년 상반기... 같은 상투구로 시작하면 예산의 1/3을 날립니다. 실제로 제 영상 스킬은 Use when preparing이 앞 18자를 먹고 있었습니다.

둘째, 만들기 전 중복 판정은 어디서나 통합니다

새 템플릿, 새 채널, 새 SOP, 새 프로세스를 만들기 전에 "사실상 같은 일을 하는 게 이미 있는가"를 한 번 묻는 것. 3개 중 2개가 걸렸습니다.

셋째, 남의 것과 내 것을 나누는 게 첫 관문입니다

• 배포 플러그인·라이브러리 → 로컬 수정 금지, 업스트림 보고

• 공유 문서·회사 템플릿 → 사본 만들고 사본에서 작업

• 내가 만든 것 → 자유

넷째, AI 지시의 범위 함정은 업무 지시에도 그대로 있습니다

"앞으로 이렇게 하자"는 기존 것을 건드리지 않습니다. 사람에게도 마찬가지고, AI에게는 더 정확히 그렇습니다.

🚀 앞으로의 계획

바로 할 것

1. 후보를 실제 경로에 설치하고 새 세션에서 인덱스 노출 문자열을 눈으로 확인합니다. 앞 57자 계산이 맞았는지가 이번 작업의 유일한 미검증 핵심입니다.

2. 같은 입력으로 Before/After를 실제 실행해 not_checked 표를 채웁니다.

그다음

3. 검사 스크립트를 만듭니다. 학습자료는 "린트로 fail-closed 검증하라"고 하면서 구현을 안 줍니다. 봇도 못 만들었습니다. 검사할 것은 3가지입니다.

   • 설명문 앞 57자가 서로 충돌하는 쌍

   • 존재하지 않는 스킬을 가리키는 끊어진 연결선

   • self-loop / cycle / self-supersede

   위반이 있으면 실패로 끝나게 만듭니다. 끊어진 연결선이 남은 직접 원인이 도구 부재였습니다.

4. 잘린 26개 전체를 훑습니다. 이번엔 1개만 다뤘습니다. 나머지 25개 중 어느 게 비싼 자리인지 판정합니다.

5. 컬렉션 전체 분류 1회 통과. 114개에 분류 후보를 붙이고 "사실상 같은 일" 쌍을 찾습니다. 확정하지 않고 후보 목록만 만들어 제가 승인합니다.

6. 배포본 스킬의 끊어진 연결선을 업스트림에 보고합니다.

📋 재사용 가능한 프롬프트

1. 내 AI의 스킬 목록이 잘려 있는지 확인하기

내 AI 런타임이 시스템 프롬프트에 넣는 스킬 목록을 찾아서, 각 스킬의 description이 몇 자에서 잘리는지 실측해줘. 확인할 것: 전체 스킬 수, 실제 노출 수, description 평균/최대 길이, 잘린 스킬 개수와 비율, 잘린 형태(몇 자 + 말줄임표인지). 그리고 잘린 스킬 목록을 인덱스에 실제로 노출되는 문자열 그대로 보여줘. 추측하지 말고 실제 파일에서 재고, 못 재면 not_checked로 남겨.

2. 만들기 전에 중복 판정시키기

[만들려는 것] 스킬을 만들려고 해. 만들기 전에 기존 스킬 전체와 대조해서 사실상 같은 일을 하는 스킬이 있는지 판정해줘. 겹치는 후보가 나오면 그 스킬 전문을 읽고 중복도를 높음/낮음으로 판정하고, 높음이면 새로 만들지 말고 경계를 어떻게 나눌지 제안해줘. 판정 결과를 표로 주고, 내가 승인하기 전에 파일을 만들지 마.

3. 고쳐도 되는 파일인지 먼저 판정시키기

[대상 스킬/파일]을 고치려고 해. 고치기 전에 소유권을 판정해줘. 확인할 것: 배포본 목록에 등재되어 있는가, 설정 파일에 작성자·라이선스가 있는가, 내가 만든 것인가. 결과를 learner_owned / third_party_license_allows_modification / factory_distributed_protected_skill / verdict 형식으로 주고, verdict가 allowed가 아니면 고치지 말고 업스트림 보고용 정리만 해줘. 확인 못 한 항목은 허용이 아니라 unknown으로 남겨.

4. AI가 학습 지시를 반영했는지 감사하기

[자료 이름]을 읽고 앞으로 적용하자고 지시했는데, 실제로 반영됐는지 감사해줘. 단계를 나눠서 판정해: ①읽었나 ②정확히 이해했나 ③적용 기준으로 바꿨나 ④자기 상태를 정직하게 표시했나 ⑤실제 파일에 반영했나 ⑥기존 것도 점검했나. 각 단계에 PASS/FAIL과 근거 파일·수치를 붙여줘. FAIL이 나오면 AI를 탓하지 말고 내 지시의 어느 부분이 그 범위를 안 포함했는지 지적해줘.

5. 원본 안 건드리고 후보만 만들기

[대상]을 개선하고 싶은데 원본은 한 줄도 수정하지 마. 순서: ①원본을 별도 폴더에 복사하고 원본·사본 해시가 같은지 확인 ②호환성을 항목별로 compatible/needs_change/blocked/not_checked 판정 ③별도 폴더에 후보 작성 ④후보에 기계 검사 실행. 마지막에 실행 검증을 했는지 안 했는지를 명확히 구분해서 써줘. 설치·실행을 안 했으면 "결과가 좋아졌다"고 쓰지 말고 구조 차이만 기록해.

6. 관계 필드를 억지로 채우지 않게 하기

[대상]의 관계 필드(depends_on/chains_with/variant_of/supersedes)를 채워줘. 단, 해당하는 대상이 없으면 빈 배열로 두고 왜 비었는지 주석으로 남겨. 그리고 공리 3종을 검증해: self-loop 없는가, 되받아 걸면 순환이 생기는 쌍이 있는가, self-supersede가 있는가. 순환이 생길 수 있으면 한 방향만 남기고 왜 그쪽으로 정했는지 적어줘.

📌 확장과제 커버리지

zip 확장과제 Step 8이 요구하는 9항목이 이 글의 어디에 들어갔는지 매핑입니다.

Extension PASS 체크리스트 대응입니다.