소개
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. 이 세션에서 브라우저 유즈·컴퓨터 유즈를 실제로 쓸 수 있는지 확인
강의 기능을 흉내내기 전에 먼저 이 기기에서 실행 가능한지부터 확인했습니다.
확인 항목
결과
코덱스 CLI 설치 여부
설치됨 (codex-cli 0.142.0)
이 세션이 코덱스인가
아님 (Claude Code 세션)
브라우저 자동화 도구(playwright)
미설치
로컬 크로미움/크롬
없음
코덱스 자체는 이 기기에 있지만, 지금 실행 중인 세션은 코덱스가 아니고 브라우저를 직접 제어할 도구도 없습니다. 강의에서 다룬 브라우저 유즈·컴퓨터 유즈는 이 세션에서 실행할 수 없다는 것이 확인된 사실입니다. 그래서 과제 지시대로 파일 기반 자동화로 방향을 바꿨습니다. 반복 손 작업을 실제로 스크립트화하는 쪽입니다.
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
스킬
검증 언급
문서 뒤쪽 1/3
abstract-analysis, core-figure, core-methods, core-problem, core-results, core-table, core-to-html, full-slides, insight-agent, lens-academic, lens-industry, lit-search, metadata-verify, methodology-brief, paper-scrapper, question, source-grounding, validation-agent (18개 전부)
0개
0개
18개 스킬 문서 중 어느 것도 "자가 검토/체크리스트로 검토/self-review/마지막 검증"에 해당하는 표현을 마지막 1/3에서 쓰지 않았습니다. 지난주 수치는 "24개 중 6개(25%)"였습니다. 이번 주는 "18개 중 0개(0%)"입니다.
Step 7. 숫자가 달라진 이유를 셋으로 나눠 확인
숫자 하나가 아니라 세 가지가 동시에 달라졌을 수 있어 각각 확인했습니다.
(1) 스킬 개수 자체가 다릅니다. git log로 이 저장소의 브랜치 구조를 봤습니다.
브랜치
스킬 문서(SKILL.md) 개수
paper-agent(현재 체크아웃) / origin/kkkim-paper-agent
18개
origin/kkkim-pipeline
16개
origin/main
13개
origin/sezinie-paper-agent
11개
origin/epigenomics
9개
다섯 브랜치 중 어느 것도 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는 "검증 절차", "검증 질문" 같은 표현이 있지만 정확히 "자가 검토"나 "체크리스트로 검토"라는 말은 쓰지 않아 걸리지 않았습니다.
세 가지 중 어느 것이 얼마나 기여했는지는 지난주 수치를 낸 원본 체크아웃이 없어 정확히 갈라낼 수 없습니다. 다만 셋 다 사실이고, 손으로 센 지난주 숫자와 스크립트로 센 이번 주 숫자는 같은 기준을 겨눴다고 믿었지만 실제로는 다른 것을 재고 있었다는 것만은 분명합니다.
결과와 배운 점
측정 결과
항목
2주차(지난주, 다른 PC)
3주차(이번 주, 이 PC)
개인 설정 전역 스킬(~/.claude/skills)
27개
1개
~/.codex/skills 사용자 스킬
미측정
0개(시스템 제공 6개만 존재)
BioProject01/skills 스킬 문서
24개
18개
같은 정규식으로 재검사한 검증·체크리스트 언급
6개(25%)
0개(0%)
검증 전용 스킬(파이프라인 4단계)
미측정
2개(validation-agent, metadata-verify)
AGENTS.md의 "마무리 단계 self-check" 명시 지침
미측정
1곳(359번째 줄)
이 저장소에서 "24개"가 나온 브랜치
-
0개(5개 브랜치 확인, 9~18개 분포)
이 세션에서 브라우저 유즈·컴퓨터 유즈 실행 가능 여부
-
불가(코덱스 CLI는 설치돼 있으나 이 세션이 코덱스가 아니고 playwright·크로미움도 없음)
배운 점
"같은 기준으로 다시 쟀다"는 말은 저장소가 그대로일 때만 성립합니다. 스킬 개수가 24개에서 18개로 바뀐 이유를
git log로 확인하기 전까지는 "검증 습관이 나빠졌다"는 결론으로 갈 뻔했습니다. 실제로는 브랜치가 다른 것이었습니다. 수치 비교 전에 대상이 같은지부터 확인해야 합니다.손으로 센 숫자는 재현되지 않습니다. 지난주 "24개 중 6개"를 이번 주 스크립트가 그대로 재현하지 못했습니다. 코드로 옮기고 나서야 제가 지난주 무엇을 세고 있었는지조차 불확실해졌습니다. 자동화는 답을 빠르게 주는 도구가 아니라, 지난 측정이 얼마나 느슨했는지 드러내는 도구였습니다.
검증은 스킬 안에도, 파이프라인에도 있을 수 있습니다.
validation-agent는 스킬 전체가 검증이고,AGENTS.md에는 "마무리 단계 self-check" 지침이 따로 있습니다. 둘 다 검증인데 제 스크립트는skills/폴더만 봐서 후자를 놓쳤습니다. 무엇을 셀지 정하는 것 자체가 측정의 절반입니다.다른 PC라는 조건을 먼저 확인하지 않으면 안 됩니다.
project-handoff-checkpoint가 이 기기 어디에도 없다는 것을 처음에 확인하지 않았다면, "지난주 계획을 실행했는지" 검증하겠다고 시간을 썼을 것입니다. 확인 가능한 것과 확인 불가능한 것을 가장 먼저 갈라야 했습니다.이번 주 과제의 "자동화"는 브라우저·컴퓨터 유즈가 아니어도 됩니다. 이 세션에는 그 기능이 없었지만, 제가 실제로 반복하던 손 작업(스킬 문서 검증 단계 세기)을 스크립트화하는 것으로 같은 정신을 실천했습니다. 도구가 없으면 파일 기반 자동화로 대체할 수 있다는 것이 이번 주의 실질적인 소득입니다.
시행착오
처음에는 "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개를 손으로 센 원본 수치