kangarooking/cangjie-skill 딥다이브
— 책 한 권을 "AI가 실제로 호출하는" 스킬 묶음으로 증류하는 파이프라인

독립성이 곧 증거다 — 격리된 병렬 추출

5개 추출기를 병렬로 돌리는 이유가 속도가 아니다. 문서에 세 가지 이유가 적혀 있는데 세 번째가 핵심이다: "독립성: 각 추출기가 독립적으로 판단해야 서로 오염되지 않고, 그래야 3중 검증이 진짜로 작동한다."

만약 하나의 에이전트가 순차적으로 5가지 관점을 훑는다면, 앞에서 "역발상 사고가 중요하다"고 판단한 게 뒤의 판단에 영향을 준다. 그러면 "여러 곳에서 독립적으로 발견됨"이라는 V1 검증의 근거가 사실은 자기 자신의 메아리가 된다.

일반화: 여러 LLM 판정을 앙상블할 때, 판정자들이 서로의 출력을 보면 앙상블의 통계적 의미가 사라진다. 이건 사람 채점에서 채점자 간 신뢰도를 재는 것과 같은 원리다.

과잉 수집 → 엄격 선별 (2단계 분리)

1단계 추출기들에게 반복적으로 지시하는 문장: "필터링 하지 마라 — 잘못 죽이느니 다 가져와라. 1.5단계 3중 검증에 맡겨라."

수집과 선별을 같은 단계에서 하면 어느 쪽도 제대로 안 된다. 수집하며 판단하면 기준이 흔들리고, 판단하며 수집하면 놓친다. 분리하면 각 단계가 하나의 명확한 목적 함수만 갖는다.

일반화: 데이터 파이프라인의 ELT(Extract-Load-Transform)와 같은 발상이다. 일단 원본을 다 적재하고 변환은 나중에.

낙방한 것도 사유와 함께 보관한다 — 감사 추적

탈락한 후보는 rejected/<id>.md에 어느 검증에서 왜 떨어졌는지까지 적어 남긴다. 삭제하지 않는다.

이유는 두 가지다. ① 사용자가 나중에 "그거 왜 빠졌지?"를 확인하고 되살릴 수 있다. ② 탈락 사유의 분포를 보면 추출기의 품질 자체를 진단할 수 있다 — 통과율이 5% 미만이면 추출기가 엉망이고, 80%를 넘으면 검증 기준이 물렁하다는 신호로 쓰라고 명시돼 있다.

일반화: LLM 필터를 만들 때 버린 것을 로그로 남기지 않으면 필터가 너무 빡센지 너무 헐렁한지 영원히 모른다. 이건 스팸 필터 설계의 기본이기도 하다.

미끼 문항과 형제 혼동 테스트 — 적대적 평가

4단계의 가장 영리한 규칙: "미끼 문항 중 최소 1개는 '같은 책에서 뽑은 다른 스킬이 발동해야 하는' 상황이어야 한다."

이유가 문서에 적혀 있다. 한 권에서 스킬 10여 개를 뽑으면 배포 후 가장 흔한 실제 장애는 "완전히 무관한 상황에서 발동"이 아니라 "형제 스킬끼리 서로 호출을 뺏는 것"이기 때문이다. 무관한 상황만 테스트하면 이 장애를 절대 못 잡는다.

더 나아가 블라인드 테스트 방식도 지정한다 — 서브에이전트에게 전체 스킬 목록을 주고 "이 중 어느 것을 발동할래?"라는 객관식으로 물으라고 한다. "이거 발동할래 말래?"라는 O/X 문제로는 형제 간 경합이 드러나지 않는다.

일반화: 분류기 평가에서 이진 분류 정확도만 보면 클래스 간 혼동 행렬이 안 보이는 것과 정확히 같은 문제다. cangjie-skill은 그걸 자연어 절차로 재발명했다.

"고치기 vs. 테스트 고치기"의 판정 규칙

테스트가 실패했을 때 스킬을 고칠지 테스트를 고칠지 — 이건 사람이 늘 자기합리화하는 지점이다. 문서는 세 갈래 규칙을 준다.

• 실패가 트리거 서술의 모호함을 드러냈다 → 스킬을 고친다
• 실패가 미처 생각 못 한 합당한 상황이었다 → 스킬을 고쳐 포함하거나 명시적으로 배제한다
• 실패가 미끼 채우려고 억지로 만든 과한 상황이었다 → 테스트를 고친다. 단, 사유를 반드시 기록

세 번째에 붙은 "사유 기록" 조건이 핵심이다. 자기합리화를 막을 수는 없지만 기록으로 남기게 만들면 빈도가 준다. 그리고 문서는 통과율 80% 미만이면 "표면 수리 금지, 2단계 통째로 재작업"이라고 못 박아 도망갈 구멍을 좁힌다.

PIPELINE_STATE.md — 자연어로 쓴 체크포인트

매 단계 완료 시 PIPELINE_STATE.md에 현재 단계 / 완료된 산출물 / 각 스킬 상태 / 다음 할 일을 체크리스트로 갱신한다. 시작할 때 이 파일이 있으면 처음부터 다시 하지 말고 거기서 이어가라고 지시한다.

LLM 세션은 컨텍스트 한계나 중단으로 끊기기 쉬운데, 수 시간짜리 작업을 처음부터 다시 돌리면 비용이 그대로 두 배다. 체크포인팅을 마크다운 파일로 구현한 셈이다.

과제 1 — 짧은 글 하나로 파이프라인 맛보기30분~1시간

목표: 책 말고 블로그 글 한 편(3,000~5,000자)으로 전체 흐름을 축소 실행한다.

절차: ① 방법론이 담긴 글 하나를 텍스트 파일로 저장 ② cangjie-skill을 스킬 디렉토리에 설치 ③ AI에게 "이 글을 cangjie-skill로 증류해줘" 요청 ④ 0단계 BOOK_OVERVIEW.md가 나오면 비판 절에 3개가 실제로 채워졌는지 확인

배우는 것: 짧은 글은 3중 검증을 거의 다 탈락한다. "통과율 5% 미만이면 경보"라는 규칙이 왜 있는지 몸으로 안다.

과제 2 — 3중 검증을 손으로 돌려보기1~2시간

목표: AI 없이, 본인이 좋아하는 책의 방법론 5개를 골라 V1/V2/V3를 직접 채점한다.

절차: ① 방법론 5개를 뽑아 적는다 ② 각각에 대해 다른 챕터 2곳의 근거를 실제로 찾아 페이지를 적는다 ③ 책에 없는 새 질문을 만들어 그 방법론으로 답해본다 ④ 저자 이름을 지워도 똑똑한 사람이면 할 말인지 판정

배우는 것: 대부분 V1에서 막힌다. 근거 2곳 찾기가 생각보다 어렵다는 걸 알면, 평소 자기가 "책에서 배웠다"고 믿던 것 상당수가 실은 한 문단짜리 인상이었음을 알게 된다.

과제 3 — 형제 혼동 테스트 만들어 돌리기반나절

목표: 4단계의 핵심인 미끼 문항을 직접 설계해 스킬 간 경합을 관찰한다.

절차: ① 서로 비슷한 스킬 2개를 만든다 (예: "회의록 요약"과 "액션 아이템 추출") ② 각각에 대해 should_trigger 3 / should_not_trigger 2(그중 1개는 형제가 답) / edge_case 1을 작성 ③ 깨끗한 새 세션에서 각 프롬프트를 던지고 실제 발동을 기록 ④ 통과율 계산

배우는 것: 십중팔구 형제 혼동에서 실패가 나온다. description을 어떻게 고쳐야 경계가 서는지, "무엇을 하는가"보다 "무엇을 하지 않는가"를 적는 게 효과적이라는 걸 체감한다.

과제 4 — 도메인을 바꿔 파이프라인 이식하기2~3일

목표: RIA-TV++의 골격을 책이 아닌 대상에 적용한다.

후보: 사내 위키 → 온보딩 스킬 / 과거 장애 보고서 → 트러블슈팅 스킬 / 코드 리뷰 코멘트 이력 → 팀 컨벤션 스킬

핵심 작업: 5개 추출기의 역할 분담을 재설계해야 한다. 장애 보고서라면 "프레임워크/원칙/사례/반례/용어"가 아니라 "증상/원인/조치/오진 패턴/시스템 용어"가 맞을 것이다. 3중 검증도 재정의가 필요하다 — V1의 "2곳 이상 독립 등장"은 "2건 이상 서로 다른 장애에서 등장"이 된다.

배우는 것: 이 저장소의 진짜 자산이 "책 증류"가 아니라 파이프라인 골격임을 확인한다. 골격만 남기고 살을 갈아끼울 수 있으면 완전히 이해한 것이다.

과제 5 — 검증자 독립성 문제 해결하기1주+

목표: 2-5절에서 지적한 "한계 1"(생산자와 검증자가 같은 모델)을 실제로 개선한다.

접근 방향:

• 모델 교차 검증 — 추출은 모델 A, 검증은 모델 B. 서로 다른 학습 분포를 가진 모델이 동시에 통과시킨 것만 채택
• 기계적 검증 추가 — V1(2곳 이상 근거)은 사실 프로그램으로 확인 가능하다. 인용된 원문이 실제 텍스트에 존재하는지 문자열 검색으로 확인하고, 두 인용의 위치가 충분히 떨어져 있는지 계산하면 "같은 문단 두 번 인용" 편법이 기계적으로 걸린다
• 사후 유용성 추적 — 스킬이 실제로 호출된 횟수와 그 대화의 결과를 로그로 남겨, "한계 4"(유용성 미측정)에 대한 데이터를 만든다

배우는 것: LLM 자기평가의 근본 한계와, 어디까지가 결정론적 검증으로 대체 가능한지의 경계. 두 번째 항목은 실제로 저장소에 기여할 만한 개선이다.