Cowork 레슨앤런 시리즈 · 2편 — 셋업·인프라
레슨앤런 1편(다운로드 경로 분리)에서 “부수 발견 4건” 으로 적어둔 항목들이 있다. 그 중 첫 번째 — “코워크 폴더 루트에 떠도는 *.skill 파일들” 을 이번 회차에 처리했다.
들여다보니 7개나 있었다. 그 중 절반은 “실제 사용자 스킬과 이름은 같지만 사실은 안 작동하는 옛 익스포트” 라는 사실까지 발견됐다. 5-3편의 “임시 처소 패턴” 이 글로만 정의된 게 아니라 내 폴더에 그대로 살아있던 것.
이 글은 그 한 사이클의 기록이다.
발견한 문제 — *.skill 파일 7개의 정체
6편(스킬)에서 정리한 원칙은 한 줄이었다.
사용자 스킬은
.claude/skills/[이름]/SKILL.md형태로 작동. 이 경로 외에 있으면 작동 안 함.
그런데 내 코워크 폴더 루트엔 *.skill 확장자 파일 7개가 떠돌고 있었다. 진단해보니 정체가 갈렸다.
| 분류 | 개수 | 정체 |
|---|---|---|
| 사용자 스킬과 동명 | 3개 | 옛 작업본 / 익스포트 / 백업 (실제 작동은 .claude/skills/ 쪽이 함) |
| 사용자 스킬에 없는 이름 | 4개 | 옛 활동 패키지·익스포트 잔존물 |
A 그룹 — 사용자 스킬과 동명 3개
세 파일이 다 “이름은 같지만 크기·내용은 다른 버전” 이었다.
naver-blog-draft.skill(41.9KB) ↔.claude/skills/naver-blog-draft/SKILL.md(32.2KB)weekly-stock-review.skill(8.7KB) ↔.claude/skills/weekly-stock-review/SKILL.md(8.6KB)youtube-seo.skill(3.4KB) ↔.claude/skills/youtube-seo/SKILL.md(11KB)
이게 정확히 5-3편의 단일 진실 원천 위반이다. 같은 사실(또는 같은 명세)이 두 곳에 있는데 한쪽이 갱신되면 즉시 충돌. 게다가 6개월 운영하면서 “어느 게 진짜인지” 가 점점 흐려졌다.
B 그룹 — 옛 활동 패키지 4개
korean-history-posting.skill— 같은 이름의 플러그인 스킬이 시스템 영역에 따로 운영 중. 루트의 .skill은 옛 익스포트.lightroom-photo-workflow.skill— 라이트룸 사진 보정 워크플로우 옛 시도. 활동 중단됨.travel-photo-auto-pipeline.skill— 여행 사진 자동화 옛 파이프라인. 블로그 작성 스킬로 흡수됨.whitenoise-shorts.skill— 백색소음 채널 숏츠 작업 옛 시도. 채널 수익화 정지로 작업 중단.
네 개 모두 “한때 시도했는데 지금은 안 쓰는 것” 들이었다. 운영 환경이 변하면서 자연스럽게 다른 스킬로 흡수되거나 활동 자체가 중단됐는데, 파일은 그대로 남아있었다.
왜 이런 일이 일어났나 — “임시 처소가 영구가 되는 과정”
5-3편에서 다음 패턴을 짚었다.
“임시 처소가 가장 흔한 단일 진실 원천 위반.”
이번에 발견된 7개 파일이 정확히 그 패턴의 결과물이다. 시간 흐름으로 재구성해보면:
| 시점 | 일어난 일 |
|---|---|
| 4~5개월 전 | 스킬 새로 만들면서 익스포트 파일을 루트에 “임시로” 떨궈둠 (백업 + 다른 컴퓨터에 옮길 용도) |
| 1~2개월 후 | 스킬 본문이 .claude/skills/에서 활발히 진화. 루트의 .skill은 “옛 버전 스냅샷” 으로 점점 멀어짐 |
| 2~3개월 후 | 두 위치의 차이가 명확해졌는데 “나중에 정리해야지” 가 누적 |
| 6개월 시점 | 진단해보니 “어느 게 진짜인지” 가 본인도 헷갈리는 상태 |
이 흐름은 흔하다. 새 스킬을 만들거나 보강할 때 어딘가에 “안전한 복사본” 을 두고 싶은 욕구는 자연스럽다. 다만 “임시” 라는 이름표가 시간을 못 이긴다.
해결 방안 — 정착시킬까, 옮길까
A 그룹(중복)과 B 그룹(옛 활동) 각각 두 가지 옵션이 있었다.
A 그룹 — 동명 중복 처리
옵션 ①: 루트의 .skill을 “진짜 백업” 으로 인정하고 .claude/skills/ 사이드와 비교해서 가치 있는 차이가 있으면 통합
옵션 ②: 진실 원천은 .claude/skills/ 쪽. 루트의 .skill은 통째로 백업 폴더로 이관
내가 고른 것: 옵션 ②. 이유는 5-3편의 단일 진실 원천 원칙 그대로 — “같은 사실은 한 곳에만”. 루트의 .skill이 가지고 있는 옛 버전 정보가 정말 필요해지면 백업 폴더에서 꺼내면 된다. 일상 운영 중에 “어느 게 진짜?” 헷갈릴 비용이 더 크다.
B 그룹 — 옛 활동 처리
옵션 ①: 활동 자체가 끝났으니 통째로 삭제
옵션 ②: 백업 폴더로 이관 후 README에 “왜 안 쓰는지” 한 줄 메모
내가 고른 것: 옵션 ②. 이유는 5-2편의 안전장치 원칙 — “삭제분은 별도 백업 파일에”. 활동을 다시 시작할 가능성이 0은 아니고, 백업 폴더에 두면서 README로 “왜 중단됐는지” 를 기록해두면 미래의 내가 “이거 왜 안 쓰지?” 헷갈리지 않는다.
두 그룹 모두 동일한 결론(백업 폴더 이관)이 나온 게 흥미로웠다. 결국 단일 진실 원천 원칙 + 안전장치 백업 원칙이 합쳐지면 “삭제하지 말고 별도 위치로 이관” 이 자연스러운 답이 된다.
실제 정비 4단계
이번에도 5-2편 안전장치 패턴을 그대로 적용했다.
Step 1 — 백업 위치 잡기
루트에 skill_backups/ 폴더가 이미 있었다. 다만 정작 거기엔 한 파일밖에 없었고(5월 초 한 번 손댄 흔적), 새로 정비할 것들은 회차별 하위 폴더로 분리하는 게 시간 추적에 좋다.
skill_backups/
└── 2026-05-14_루트정비/ ← 신설
회차별 폴더로 두면 “5월 14일 정비 때 옮긴 것” 이 시간순으로 명확해진다. 7편 파일명 규칙(날짜 접두사 압축)을 백업 폴더 구조에도 그대로 적용.
Step 2 — 7개 파일 일괄 이동
*.skill 확장자로 일괄 매칭해서 한 번에 옮겼다. 7개 모두 한 번에. 분류 작업(A 그룹 / B 그룹)은 README에서 정리.
Step 3 — README 작성 (가장 중요)
백업 폴더에 옮긴 직후 README를 같이 박는 단계가 핵심이다. “왜 옮겼는지” 가 없으면 6개월 뒤에 보고 “이게 뭐지? 다시 살려야 하나?” 가 된다.
skill_backups/2026-05-14_루트정비/README.md
내용은 세 가지:
- A 그룹 / B 그룹 분류 (왜 옮겼는지 한 줄씩)
- 각 파일의 크기·동명 사용자 스킬 존재 여부
- 복원 방법 (필요 시 원래 위치로 복사)
5편의 “변경 일자·이유 메모” 원칙(좋은 구조 ⑤번)을 백업 폴더에도 적용한 형태.
Step 4 — 정비 결과 검증
루트의 *.skill 파일 0개 확인. 백업 폴더에 7개 + README 안전 보관 확인. CLAUDE.md는 손대지 않음 — 헌법에 *.skill 파일 관련 언급 0건이라 갱신 불필요. 이게 1편의 “Chrome 다운로드 경로” 케이스와 다른 점이다.
결과 — 무엇이 깨끗해졌나
| 항목 | 정비 전 | 정비 후 |
|---|---|---|
코워크 폴더 루트의 *.skill 파일 |
7개 | 0개 |
.claude/skills/와 동명 중복 파일 |
3개 | 0개 (백업 이관) |
| 옛 활동의 잔존 패키지 | 4개 | 0개 (백업 이관 + 사유 기록) |
| 단일 진실 원천 위반 (5-3편) | 3건 | 0건 |
| 임시 처소 패턴 (5-3편) | 3건 | 0건 |
| 사용자 스킬 작동 영향 | 없음 (어차피 루트의 .skill은 작동 안 함) | 없음 (변경 없음) |
핵심 포인트: 이 정비는 “동작에는 변화 없음, 인지 비용에는 큰 변화” 다. 어차피 루트의 .skill 파일들은 Cowork가 사용자 스킬로 인식하지 않았다(6편 원칙 — .claude/skills/ 경로만 인식). 그런데 내가 “어느 게 진짜인지” 헷갈리는 상태였다. 정비 후엔 진실 원천이 명확해졌다.
다른 사람에게 적용할 수 있는 일반 원칙 3가지
① *.skill 확장자만 봤다고 작동하는 스킬은 아니다
이게 가장 자주 오해되는 지점이다. “.skill 확장자니까 Cowork가 알아서 처리하겠지” 는 사실이 아니다. Cowork는 정확한 경로 + 정확한 파일명(.claude/skills/[이름]/SKILL.md)으로만 사용자 스킬을 인식한다.
루트의 *.skill 파일이 있어도 그건 그냥 텍스트 파일이거나 ZIP 패키지일 뿐이고 자동 호출되지 않는다. 본인이 “이게 작동하는 스킬” 이라고 생각하면 사고. 진단할 때 이 차이를 먼저 명확히.
② 익스포트·백업 파일에 “왜 만들었는지” 메모를 같이 박을 것
내가 4~5개월 전 .skill 파일들을 루트에 떨궈둘 때 “왜” 라는 메모를 같이 안 적었다. 그래서 이번 진단 때 “이게 뭐지? 백업인가 익스포트인가 작업본인가?” 가 매번 헷갈렸다.
해법: 익스포트·백업 파일을 만드는 시점에 README 한 줄도 같이. “2026-04-22 naver-blog-draft v3 익스포트, 다른 컴퓨터 이전용” 같은 한 줄이면 6개월 뒤의 본인이 즉시 판단 가능.
③ 백업 폴더는 “회차별 하위 폴더” 로 시간 추적
skill_backups/ 한 폴더에 모든 백업을 평평하게 떨어뜨리면 시간이 지나 “이건 언제 옮긴 거지?” 가 헷갈린다. 회차별 하위 폴더(2026-05-14_루트정비/ 같은 식)로 두면 정비 이력이 그대로 폴더 트리에 누적된다.
5편 좋은 구조 ⑤번(“변경 일자·이유 메모”)을 백업 폴더 구조 자체에 박는 패턴이다.
30분 사이클 시간 분배
| 단계 | 시간 |
|---|---|
진단 (루트 *.skill 파일 분류 + .claude/skills/와 비교) |
8분 |
| 해결 방안 결정 (A 그룹 / B 그룹 옵션 비교) | 4분 |
| 실제 정비 (백업 폴더 신설 + 7개 이동 + README 작성) | 10분 |
| 검증 (루트 잔존 확인) | 2분 |
| 결과 보고 + 글로 정리 시작 | 6분 |
1편의 “다운로드 경로 분리” 보다 진단 시간이 좀 더 들었다. 7개 파일이 각각 어떤 정체인지 — 사용자 스킬과 동명인지·옛 활동인지·익스포트인지 — 를 한 번씩 들여다봐야 했기 때문. 정비 시간 자체는 비슷.
마무리 + 다음 회차 예고
5-3편의 “임시 처소 패턴” 이 글로만 정의된 게 아니라 실제 내 폴더에 살아있었다는 게 이번 회차의 가장 큰 발견이었다. 6개월 운영하면서 “임시” 라는 이름표가 시간을 못 이기는 모습.
남은 부수 발견 3건은 다음 회차에 한 건씩 처리할 예정:
| 회차 | 다룰 항목 |
|---|---|
| 다음 | 임시 폴더 3개 (_grid_preview/, _temp_cafe/ 등 — 7편 흔한 실수 ②번 직접 적용) |
| 그 다음 | 일회성 추출물 5개 (DATA_SUMMARY.txt 등 — 영구 vs 일회성 가치축 위반) |
| 마지막 | ROI 트래커 파일 2곳 중복 (가장 위험·가치 큰 케이스 — 단일 진실 원천의 정수) |
순서를 “쉬운 것 → 어려운 것” 으로 잡았다. 마지막의 ROI 트래커는 데이터 손실 위험이 있어 다른 정비보다 신중히 다룰 예정.
2026년 5월 현재 상태
- 정비 완료 일자: 2026-05-14 (1편 발행 직후 한 사이클 더)
- 이동 대상 파일: 7개 (
*.skill일괄) - 백업 위치:
skill_backups/2026-05-14_루트정비/ - 백업 폴더 안 구성: 7개 *.skill 파일 + README.md (정비 사유 + 복원 방법)
- CLAUDE.md 갱신: 없음 (헌법에 해당 경로 언급 0건)
- 사용자 스킬 작동 영향: 없음 (어차피 루트의 .skill은 작동 안 함)
- 남은 부수 발견: 3건 (다음 회차에 한 건씩 처리 예정)
undefined