지난주 "24개 중 6개(25%)"라던 숫자를, 스크립트로 다시 세니 "18개 중 0개"가 나왔습니다

소개

2주차 사례글에서 저는 다섯 가지를 계획했습니다. 검증 단계를 먼저 쓰기, 실제로 쓰는 4개 스킬에 검증을 붙이기, 연구 저장소의 스코어러를 스킬 안으로 옮기기, project-handoff-checkpoint를 첫 대상으로 삼기, "검토 필요 N건"을 맨 위에 적는 형식 넣기.

이번 세션은 지난 세션과 다른 PC에서 돌아갑니다. 확인해보니 project-handoff-checkpoint는 ~/.claude에도 ~/.codex에도, 이 기기 어디에도 없습니다. 지난주 계획을 실행했는지 이 자리에서 검증할 방법 자체가 없다는 뜻입니다. 이건 "확인하지 못한 것"으로 정직하게 남겨 둡니다.

대신 이번 주 강의는 코덱스의 웹서치, 브라우저 유즈, 컴퓨터 유즈를 다뤘고, 과제는 "오늘 배운 것으로 반복 작업을 자동화해보라"는 것이었습니다. 그런데 2주차에서 제가 실제로 반복하고 있던 손 작업이 하나 있었습니다. 스킬 문서를 열어서 검증 단계가 있는지 눈으로 세는 일입니다. 이번 주는 그 세는 작업 자체를 스크립트로 자동화하고, 지난주 손으로 잰 숫자와 이번 주 스크립트로 잰 숫자를 나란히 놓아 봤습니다.

진행 방법

사용 도구: Claude Code, Python 3, 코덱스 CLI(존재 확인만), git

Step 1. 이번 주 강의에서 새로 나온 기능 확인

3주차 강의 자막(2531줄, whisper 로컬 전사)을 읽었습니다. 강사가 오늘 다룰 기능을 먼저 나열합니다.

브라우저 유즈, 이 코덱스가 브라우저를 직접 탐험하면서 돌아다니는 거 시키는 거. 그리고 컴퓨터 유즈는 말 그대로 진짜 컴퓨터를 키보드랑 마우스를 얘가 가지고 움직이면서 쓸 수 있도록 그렇게 하는 기능이고요.

이어서 브라우저 유즈가 왜 필요한지를 설명합니다.

옛날 AI 모델들은 사실 이 브라우저 직접 탐색하면서 돌아다니기보다는 DOM이라는 거를 사용한다던가 아니면 보통 그냥 웹에 있는 코드를 통해서 다운을 받는다던가 이런 식으로 진행을 했었는데, 이 브라우저 유즈라는 게 생기면서 실제로 코덱스가 브라우저에 들어와서 클릭 클릭 하면서 어디에 뭐가 있는지 제가 직접 클릭도 하고 주문도 할 수 있고 그렇게 하는 기능인데요.

앱샷(화면 캡처)에 대해서는 이렇게 설명합니다.

어떤 앱이든, 웹이든, 뭐 터미널 같은 것들로 그냥 이렇게 앱샷. 이러면 그냥 내가 뭐 캡처를 하거나 뭘 하지 않아도 전부 다 이 컨텍스트가 이 안에 들어가 있습니다.

반복 작업을 스킬로 만드는 기능(워크플로 녹화/레코드 앤 리플레이)은 이렇게 설명합니다.

내가 그냥 매크로 녹화하는 것처럼 녹화 기능을 켜고 어떤 식으로 뭘 해야 하는지 워크플로를 녹화해서 보여주면, 얘가 그거를 지가 보고 스킬로 만드는, 반복 작업을 쓸 수 있는 스킬로 만드는 그런 기술이고요.

강의 후반에 강사가 정산 사이트에서 CSV를 다운로드하는 과정을 직접 녹화해 스킬로 만드는 시연을 보여주고, 이렇게 정리합니다.

그래서 뭐 매일 같이 반복해야 하는 작업이나 그런 것들이 있다면 이걸로 한 번 스킬로 잘 써주시는 것도 좋을 것 같아요.

강의 말미에는 세 기능을 언제 쓰는지 기준을 정리해 줬습니다.

외부에 있는 것들을 뭔가 웹서치를 시키거나 웹서핑이 필요하다, 자료가 외부에 있다, 뭔가 다운받아야 될 것들이 굉장히 많다. (중략) 프로그램 조작이 필요하다 그러면 이거 컴퓨터 유즈 같은 경우에는, 예를 들어서 얘가 코덱스랑 뭔가 작업을 막 하다가 안 된다, 지가 못한다 하는 것들이 생겨요. 그러면 저 같은 경우에는 그냥 그럴 때 컴퓨터 유즈 강제로 소환하면서, 컴퓨터 유즈로 니가 직접 해 하면은 약간 그냥 알아서 잘 해줍니다.

Step 2. 이번 주 과제 확인

강사가 과제를 안내한 부분입니다.

그래서 이번 주 3주차 과제도 똑같이 저희 이 챌린지 사이트 내 있는 도전 과제들 대부분 완료를 하시면 되고요. 자동화 실험 같은 거 뭐 직접 해 보셔도 되고,

이어지는 문장은 whisper 전사가 심하게 깨져("웨피아시나", "브라우저요즘", "컴퓨터요즈" 같은 표기) 원문 그대로 인용하기 어렵습니다. 문맥과 앞 설명을 종합하면 "오늘 배운 웹서치·브라우저 유즈·컴퓨터 유즈로 자동화까지 해봐도 된다"는 취지입니다.

챌린지 사이트는 카톡방으로 배포된 접근 제한 자료라 이 세션에서 열 수 없습니다. 정직하게 "확인하지 못한 것"입니다. 대신 두 번째 조건, 자동화 실험을 직접 해보는 쪽으로 방향을 잡았습니다.

Step 3. 이 세션에서 브라우저 유즈·컴퓨터 유즈를 실제로 쓸 수 있는지 확인

강의 기능을 흉내내기 전에 먼저 이 기기에서 실행 가능한지부터 확인했습니다.

코덱스 자체는 이 기기에 있지만, 지금 실행 중인 세션은 코덱스가 아니고 브라우저를 직접 제어할 도구도 없습니다. 강의에서 다룬 브라우저 유즈·컴퓨터 유즈는 이 세션에서 실행할 수 없다는 것이 확인된 사실입니다. 그래서 과제 지시대로 파일 기반 자동화로 방향을 바꿨습니다. 반복 손 작업을 실제로 스크립트화하는 쪽입니다.

Step 4. 실제로 반복하던 손 작업을 찾기

2주차에 제가 한 일을 되짚어 보면, BioProject01/skills의 각 SKILL.md를 하나씩 열어 검증 단계가 있는지, 그것이 문서 뒤쪽에 있는지를 눈으로 셌습니다. 이번 주도 같은 저장소를 다시 재려면 같은 작업을 반복해야 합니다. 이걸 스크립트로 옮겼습니다.

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

기준은 2주차와 똑같이 두었습니다. 자가 검토가 있는가, 그것이 마지막 단계인가.

Step 5. 개인 설정 폴더부터 재확인

먼저 지난주 27개라고 쟀던 ~/.claude/skills부터 이 기기에서 다시 봤습니다.

find ~/.claude/skills -maxdepth 3
  graphify/SKILL.md

1개입니다. ~/.codex/skills도 봤습니다.

find ~/.codex/skills -maxdepth 3
  .system/review-agent, skill-creator, plugin-creator,
  skill-installer, openai-docs, imagegen  (6개, 전부 시스템 제공)

사용자가 만든 스킬은 0개고, 코덱스가 기본 제공하는 시스템 스킬 6개만 있습니다. 지난주 27개를 쟀던 개인 설정 폴더는 이 기기에 없습니다. 다른 PC의 계정 상태라는 뜻입니다.

Step 6. BioProject01/skills를 스크립트로 재검사

git status로 먼저 작업 트리 상태를 확인했습니다. paper-agent 브랜치, origin/kkkim-paper-agent와 동기화된 상태로 변경 사항 없음(clean)이었습니다. 이 저장소에 Step 4의 스크립트를 돌렸습니다.

python3 count_verification.py BioProject01/skills

18개 스킬 문서 중 어느 것도 "자가 검토/체크리스트로 검토/self-review/마지막 검증"에 해당하는 표현을 마지막 1/3에서 쓰지 않았습니다. 지난주 수치는 "24개 중 6개(25%)"였습니다. 이번 주는 "18개 중 0개(0%)"입니다.

Step 7. 숫자가 달라진 이유를 셋으로 나눠 확인

숫자 하나가 아니라 세 가지가 동시에 달라졌을 수 있어 각각 확인했습니다.

(1) 스킬 개수 자체가 다릅니다. git log로 이 저장소의 브랜치 구조를 봤습니다.

다섯 브랜치 중 어느 것도 24개가 아니었습니다. git log에는 celltype-annotation, multiome-integration 스킬을 추가한 커밋(5월 29일, 다른 작성자)이 있지만 지금 체크아웃한 paper-agent의 skills/에는 그 폴더가 없습니다. 지난주 "24개"를 만든 정확한 브랜치/체크아웃이 무엇이었는지는 이 세션에서 재현할 수 없었습니다. 이것도 "확인하지 못한 것"입니다.

(2) 검증이 스킬 밖, 파이프라인 단계로 옮겨져 있었습니다. validation-agent와 metadata-verify를 열어보니 둘 다 스킬 전체가 검증 그 자체였습니다. AGENTS.md의 5단계 파이프라인 중 4번째가 validation-agent 실행이고, 359번째 줄에는 이런 지침이 있습니다.

본 정합성 규칙이 지켜졌는지 확인은 build_index 같은 별도 도구가 아닌, LLM이 마무리 단계에서 self-check한다.

정확히 "마지막 단계 self-check"인데, 개별 스킬 파일이 아니라 파이프라인을 정의하는 AGENTS.md에 있습니다. 제 스크립트는 skills/ 폴더의 18개 파일만 봤기 때문에 이 지침을 셀 수 없었습니다.

(3) 정의를 지난주보다 좁게 적용했을 가능성입니다. 2주차 시행착오에서 "검증"이나 "확인" 같은 흔한 말을 포함하면 96%까지 부풀었다고 적었습니다. 이번 주 스크립트는 그 교훈대로 좁은 정규식만 썼습니다. validation-agent는 "검증 절차", "검증 질문" 같은 표현이 있지만 정확히 "자가 검토"나 "체크리스트로 검토"라는 말은 쓰지 않아 걸리지 않았습니다.

세 가지 중 어느 것이 얼마나 기여했는지는 지난주 수치를 낸 원본 체크아웃이 없어 정확히 갈라낼 수 없습니다. 다만 셋 다 사실이고, 손으로 센 지난주 숫자와 스크립트로 센 이번 주 숫자는 같은 기준을 겨눴다고 믿었지만 실제로는 다른 것을 재고 있었다는 것만은 분명합니다.

결과와 배운 점

측정 결과

배운 점

1. "같은 기준으로 다시 쟀다"는 말은 저장소가 그대로일 때만 성립합니다. 스킬 개수가 24개에서 18개로 바뀐 이유를 git log로 확인하기 전까지는 "검증 습관이 나빠졌다"는 결론으로 갈 뻔했습니다. 실제로는 브랜치가 다른 것이었습니다. 수치 비교 전에 대상이 같은지부터 확인해야 합니다.

2. 손으로 센 숫자는 재현되지 않습니다. 지난주 "24개 중 6개"를 이번 주 스크립트가 그대로 재현하지 못했습니다. 코드로 옮기고 나서야 제가 지난주 무엇을 세고 있었는지조차 불확실해졌습니다. 자동화는 답을 빠르게 주는 도구가 아니라, 지난 측정이 얼마나 느슨했는지 드러내는 도구였습니다.

3. 검증은 스킬 안에도, 파이프라인에도 있을 수 있습니다. validation-agent는 스킬 전체가 검증이고, AGENTS.md에는 "마무리 단계 self-check" 지침이 따로 있습니다. 둘 다 검증인데 제 스크립트는 skills/ 폴더만 봐서 후자를 놓쳤습니다. 무엇을 셀지 정하는 것 자체가 측정의 절반입니다.

4. 다른 PC라는 조건을 먼저 확인하지 않으면 안 됩니다. project-handoff-checkpoint가 이 기기 어디에도 없다는 것을 처음에 확인하지 않았다면, "지난주 계획을 실행했는지" 검증하겠다고 시간을 썼을 것입니다. 확인 가능한 것과 확인 불가능한 것을 가장 먼저 갈라야 했습니다.

5. 이번 주 과제의 "자동화"는 브라우저·컴퓨터 유즈가 아니어도 됩니다. 이 세션에는 그 기능이 없었지만, 제가 실제로 반복하던 손 작업(스킬 문서 검증 단계 세기)을 스크립트화하는 것으로 같은 정신을 실천했습니다. 도구가 없으면 파일 기반 자동화로 대체할 수 있다는 것이 이번 주의 실질적인 소득입니다.

시행착오

• 처음에는 "18개 중 0개"라는 숫자만 보고 "검증 습관이 지난주보다 나빠졌다"고 쓸 뻔했습니다. git log -- skills/와 브랜치별 스킬 개수를 직접 세어 보고서야 저장소 자체가 달랐다는 것을 알았습니다. 숫자가 예상과 다르게 나오면 바로 결론을 쓰지 말고 원인부터 나눠 봐야 합니다.

• validation-agent, metadata-verify를 처음엔 "검증 언급 스킬"로 세려다가, 이 둘은 스킬 자체의 목적이 검증이라 2주차의 "본문 안에 검증 단계가 있는가"라는 정의와 다르다는 것을 깨닫고 별도 항목("검증 전용 스킬")으로 분리했습니다.

• 코덱스 CLI가 이 기기에 설치돼 있는 것을 보고 브라우저 유즈를 바로 써보려 했지만, 지금 세션이 코덱스가 아니라는 것을 뒤늦게 확인했습니다. 도구 존재 여부와 이 세션에서의 실행 가능 여부는 다른 질문입니다.

앞으로의 계획

• 지난주 계획(4개 실제 스킬에 검증 붙이기, project-handoff-checkpoint부터)은 이 기기에 대상이 없어 그대로 넘어갈 수 없습니다. 다음에 원래 설정이 있는 PC로 돌아가면 먼저 이어서 하겠습니다.

• count_verification.py는 이번에 임시로 짠 스크립트입니다. BioProject01의 skills/ 폴더에 정식으로 옮겨 두면, 스킬을 새로 추가하거나 고칠 때마다 손으로 세지 않고 매번 같은 기준으로 검사할 수 있습니다.

• 다음에는 AGENTS.md 같은 오케스트레이터 문서까지 포함해서 세는 스크립트로 넓히겠습니다. 이번 주에 확인한 대로 검증이 스킬 파일 안에만 있는 게 아니기 때문입니다.

• 4주차는 "나만의 워크스페이스 에이전트 시스템"이 주제라고 강의에서 예고했습니다. 이번 주에 만든 카운팅 스크립트를 그 시스템의 점검 스킬 하나로 편입시켜 볼 계획입니다.

도움 받은 글 (옵션)

• 23기 코덱스 입문 3주차 강의 (김진형): 브라우저 유즈, 컴퓨터 유즈, 앱샷, 워크플로 녹화(레코드 앤 리플레이), 리모트 컨트롤의 정의와 각 기능을 언제 쓰는지 기준, 이번 주 과제 안내

• BioProject01 저장소의 AGENTS.md, skills/(본인 연구): 5단계 파이프라인 중 Validation Agent 단계, "LLM이 마무리 단계에서 self-check" 지침, 브랜치별 스킬 개수 차이

• 23기 코덱스 입문 2주차 사례글 (본인): 검증 단계를 "자가 검토가 있는가", "마지막 단계인가"로 정의한 기준과 그 정의로 24개 중 6개를 손으로 센 원본 수치