"넣고 안 넣고 차이가 크다"는 검증 단계가 제 스킬 27개 중 5개에만 있었습니다

소개

1주차 사례글에서 저는 자동화할 일을 고르기 전에 자동화하면 안 되는 일부터 갈라냈습니다. 기준 하나를 더 붙였습니다. "틀렸을 때 되돌릴 수 있는가."

이번 주 강의에서 스터디장이 스킬의 마지막 단계를 이야기하며 이렇게 말했습니다.

체크리스트 검토, 요거는 필요 없다고 생각하실 수도 있는데, AI로 현업에서 직접 업무를 많이 해 본 결과 요거를 넣고 안 넣고의 차이가 굉장히 큽니다.

마지막에 검증하는 절차를 무조건 자기가 한 번 더 회고해 보도록 만들어 보시는 게 사고가 안 날 가능성이 높습니다.

1주차에 제가 "되돌릴 수 있는가"를 물었다면, 이번 주 질문은 "틀렸을 때 스스로 알아채는가"입니다. 앞의 것은 사고 후 대응이고 뒤의 것은 사고 예방입니다.

제 스킬 27개에 그 단계가 있는지 세어 봤습니다.

진행 방법

어떤 도구를 사용했고, 어떻게 활용하셨나요?

사용 도구: Claude Code, Python 3

Step 1. 검증 단계의 정의를 정하기

강의의 예시를 기준으로 삼았습니다.

3. 체크리스트 검토
   작성한 초안을 체크리스트로 자가 검토한다.
   문서 맨 위에 "검토 필요 N건"을 요약해 넣는다.

두 가지 조건이 보입니다.

Step 2. 두 조건으로 27개 검사

LAST = r'(자가\s*검토|체크리스트로\s*검토|checklist|self-?review|
          마지막.{0,20}(검증|검토)|final (check|review))'
# 문서 뒤쪽 1/3에 있으면 "마지막 단계"로 판정

27개 중 5개입니다.

Step 3. 실제로 쓰는 4개를 따로 보기

1주차와 K스킬 사례글에서 확인한, 실제로 호출된 스킬 넷을 봤습니다.

제가 실제로 쓰는 4개 중 검증 단계가 끝에 있는 것은 0개입니다.

project-handoff-checkpoint는 검증을 언급하지만 문서 앞쪽입니다. 무엇을 확인하라는 안내는 있는데 마지막에 스스로 돌아보는 절차는 없습니다.

Step 4. 왜 이렇게 됐는지

제 스킬은 대부분 무엇을 어떻게 만들지를 적습니다. 만들고 나서 확인하는 부분은 제가 눈으로 봅니다.

그런데 이번 세션에서 그 눈이 여러 번 놓쳤습니다.

전부 결과를 만든 뒤 다시 보지 않아서 생긴 것입니다. 스터디장이 "넣고 안 넣고의 차이가 굉장히 크다"고 한 것이 이 자리였습니다.

Step 5. 검사를 붙인 것과 안 붙인 것의 차이

반려에이전트 사례글에서 이미 확인한 수치가 있습니다.

검사 하나를 마지막에 붙였더니 44건이 0건이 됐습니다. 규칙 파일은 내내 같았습니다.

Step 6. 다른 저장소의 스킬도 같은 비율이었다

개인 설정 폴더만 본 결과라 편향이 있을 수 있어, 연구 저장소의 스킬도 세어 봤습니다. BioProject01에는 데이터셋마다 스킬이 하나씩 있습니다.

BioProject01/skills/
  10x-embryonic-mouse-brain/
  human-brain-multiome/
  human-hspc-10x-multiome/
  share-seq-mouse-skin/
  external/

두 곳이 거의 같습니다. 만든 시기도 목적도 다른데 비율이 겹칩니다. 개인 습관 문제가 아니라 스킬을 쓸 때 검증을 뒤에 붙이는 습관이 아예 없다는 뜻으로 읽었습니다.

한 가지 다른 점이 있습니다. 연구 저장소에는 스킬 바깥에 evals/ 폴더가 따로 있고 거기에 케이스와 스코어러가 있습니다. 검증을 스킬 안이 아니라 옆에 두었습니다. 그래서 스킬만 세면 없어 보입니다.

이번 주 강의의 핵심은 스킬 안에 넣으라는 것이었습니다. 옆에 두면 스킬을 부를 때 같이 안 불립니다.

Step 7. 도구를 고르는 기준도 같은 자리에 있었다

이날 채팅에서 MCP를 어떻게 쓰느냐는 이야기가 나왔습니다.

mcp는 로컬 서버 운용 상태에 의존하는 경우가 많다 보니 불안정한 경우가 많아서, 같은 기능의 플러그인이 있으면 그걸 쓰는 게 좀 더 좋은 것 같아요. (체크)

검증 단계를 붙이는 것과 같은 이야기로 읽혔습니다. 결과가 매번 같게 나오는 쪽을 고른다는 기준입니다. 제 스킬 27개 중 검증이 뒤에 붙은 것이 5개뿐이라 나머지 22개는 결과가 매번 다를 수 있는데, 저는 그것을 확인할 장치를 안 뒀습니다.

준비 시점에 대한 이야기도 있었습니다.

대시보드 기획은 23기 스터디 커리큘럼 나오면서부터 진행했습니다. OT 전에 해 두시면 기수 동안 즐기실 수 있으세요. (도시아재)

커리큘럼 자체가 좋은 입력 자료가 된다는 뜻입니다. 저는 매주 강의를 듣고 나서 무엇을 잴지 정하는데, 정할 시점을 앞으로 당길 수 있다는 것을 여기서 봤습니다.

결과와 배운 점

측정 결과

배운 점

1. 검증을 사람이 하기로 해 두면 안 하게 됩니다. 제 스킬은 "만드는 방법"만 적혀 있고 확인은 제 몫입니다. 그런데 이번 세션에서 네 번 놓쳤습니다. 사람이 하기로 한 일은 바쁘면 건너뜁니다. 스킬 안에 넣으면 건너뛸 수 없습니다.

2. 검증을 옆에 두면 같이 안 불립니다. 연구 저장소에는 평가 하네스가 세 개 있는데 스킬 폴더 밖에 있습니다. 그래서 스킬을 실행할 때 자동으로 돌지 않고, 제가 따로 실행해야 합니다. 강의가 "스킬 안에 넣으라"고 한 이유가 이것입니다. 있는 것과 불리는 것은 다릅니다.

3. 검증 위치가 중요합니다. 7개가 검증을 언급하는데 5개만 뒤쪽에 있습니다. 앞에 적힌 "이렇게 확인하세요"는 만들기 전에 읽히고 끝납니다. 마지막에 있어야 만든 결과를 대상으로 삼습니다.

4. "검토 필요 N건"을 맨 위에 적게 하는 것이 핵심이었습니다. 스터디장의 스킬은 자가 검토만 하는 게 아니라 건수를 문서 첫 줄에 올립니다. 사람이 어디를 봐야 할지 바로 알게 하는 장치입니다. 제 검사 스크립트도 "합계 N건"을 마지막에 찍는데, 그 한 줄이 있어서 고치게 됩니다.

5. 1주차의 기준을 한 칸 앞으로 옮겼습니다. 1주차에 저는 "틀렸을 때 되돌릴 수 있는가"로 자동화 대상을 골랐습니다. 되돌리는 것은 사고가 난 뒤입니다. 틀렸을 때 스스로 알아채게 만드는 것이 그 앞에 있어야 합니다.

시행착오

• 검증 단계를 키워드로 찾다가 "검증"이나 "확인" 같은 흔한 말까지 넣으면 대부분이 걸립니다. 에이전트하네스 1주차에서 같은 방식으로 96%가 나왔던 적이 있어, 이번에는 "자가 검토", "체크리스트로 검토"처럼 절차를 가리키는 표현으로 좁혔습니다. 25%가 나왔습니다.

• "마지막 단계인가"를 문서 뒤쪽 3분의 1에 있는지로 판정했습니다. 이건 위치로 순서를 짐작한 것이라 정확하지 않습니다. 스킬을 하나씩 열어 보면 달라질 수 있습니다.

앞으로의 계획

• 이번 주 과제인 스킬을 만들 때 마지막 검증 단계를 먼저 쓰겠습니다. 본문보다 그것을 먼저 적어 두면 빠뜨리지 않습니다.

• 실제로 쓰는 4개에 검증 단계를 붙이겠습니다. 27개 전부가 아니라 쓰는 것부터입니다. 안 불리는 스킬에 검증을 붙여 봐야 작동하지 않는다는 것을 1주차에 확인했습니다.

• 연구 저장소의 스코어러를 스킬 안으로 옮기겠습니다. 새로 짤 필요가 없습니다. evals/에 있는 것을 스킬의 마지막 단계에서 부르게만 하면, 지금 따로 실행하던 것이 자동으로 돕니다.

• project-handoff-checkpoint가 첫 대상입니다. 5회로 가장 많이 쓰는데, 인계 문서에 빠진 항목이 있으면 다음 세션 전체가 어긋납니다. 검증이 가장 필요한 자리입니다.

• "검토 필요 N건"을 맨 위에 적는 형식을 제 스킬에도 넣으려 합니다. 결과를 다 읽지 않아도 손댈 곳이 있는지 알 수 있습니다.

도움 받은 글 (옵션)

• 프로젝트 저장소의 skills/ (본인 연구): 데이터셋별 스킬 다섯 개와 문서 24개 중 검증 절차를 언급한 것이 6개라는 측정, 검증이 스킬 안이 아니라 별도 evals/ 폴더에 놓여 있다는 구조

• 2주차 강의 채팅: MCP가 로컬 서버 상태에 의존해 불안정하니 같은 기능의 플러그인이 있으면 그쪽을 쓴다는 체크의 기준, 커리큘럼이 나오자마자 기획을 시작해 OT 전에 준비를 마쳤다는 도시아재의 순서

• 23기 코덱스 입문 2주차 강의 (김진형): 스킬을 프롬프트 템플릿으로 설명한 정의, description이 작동 트리거가 되는 구조, 주간 보고 스킬의 3단계 구성, "마지막 검증 절차를 넣고 안 넣고의 차이가 굉장히 크다"는 현업 경험, 플러그인과 MCP의 구분

• 23기 코덱스 입문 1주차 사례글 (본인): 자동화할 일보다 하면 안 되는 일부터 갈라낸 기준과 "되돌릴 수 있는가"라는 판정 항목