Step 344. 침투 플레이북 v2.0 — 경험이 매뉴얼이 되는 순환

Level 4 — 전문가 | 난이도 ★★★★☆ | 예상 소요 시간 4~6시간 (자산 수집 + 비평적 재독 + 개정 + 버전 선언)

전제: Step 272의 플레이북 v1.0, Step 304~313의 OSCP 체크리스트, Step 314~319의 버그바운티 정찰 절차, Step 343의 시나리오 훈련 타임라인이 있습니다.

준비물: 플레이북 v1.0 저장소(Git), v1.0 이후 만들어진 모든 루틴 문서와 훈련 기록, 변경 이력을 적을 빈 파일 하나.
⚠️ 이 챕터의 실습은 내 랩·합법 플랫폼 전용입니다. 허가 없는 시스템에 적용하면 범죄입니다. 플레이북에 실리는 절차는 전부 합법 학습 플랫폼과 내 랩에서 검증된 것이어야 합니다.
성격 안내: 오늘은 프로젝트 챕터입니다 — 새 기술이 아니라, 지난 수십 Step의 경험을 플레이북에 이전하는 개정의 날입니다.

Step 272에서 여러분은 플레이북 v1.0을 "지금 실력의 사진"이라고 선언했습니다. 그때의 선언에는 약속이 하나 붙어 있었습니다 — 이 문서는 평생 개정된다는 것. 그 후로 OSCP를 준비하고 실기를 치렀고, 버그바운티에서 실서비스를 정찰했고, Step 343에서 랩 전체를 대상으로 종합 시나리오를 수행했습니다. 사진 찍은 지 벌써 일흔 개의 Step이 지났습니다. v1.0은 이제 낡은 사진입니다.

오늘은 그 사진을 갱신하는 날입니다. 그런데 오늘의 핵심은 개정 그 자체가 아니라 개정의 순환입니다. 실전에서 배우고, 플레이북에 반영하고, 다음 실전에서 검증하고, 다시 반영하는 — 이 순환이 돌기 시작하면 여러분의 실력은 복리로 자랍니다. v2.0은 그 순환이 한 바퀴 돌았다는 첫 증거입니다.

1. 학습 목표

이 챕터를 끝내면 다음을 할 수 있습니다:

v1.0 이후 축적된 자산(체크리스트·타임라인·교훈)을 전수 수집해 개정 후보 목록을 만든다
v1.0을 비평적으로 읽어 "현실과 다른 절차"를 식별한다
각 절차에 "실제 검증 사례(날짜/머신)" 링크를 붙여 v2.0으로 개정한다
도구 목록을 "현재 실제로 쓰는 것" 기준으로 갱신한다
변경 이력(changelog)과 개정 주기를 정해 문서의 생명주기를 제도화한다

2. 배경 지식 — 오늘의 도구와 개념

오늘의 도구 한눈에 보기

구분	내용
언어·환경	마크다운 + Git(플레이북 저장소), Git Bash
오늘의 명령	`git log`, `git diff`, `grep -rn` — 개정 전후 비교와 검증에 사용
필요한 개념	비평적 재독, 검증 사례 링크, 도구 목록 갱신, 변경 이력, 개정 주기
오늘의 산출물	플레이북 v2.0(개정된 절차 + CHANGELOG.md + 개정 주기 선언)

2-1. v1과 v2의 차이 — 사진에서 영상으로

v1.0은 "지금 실력의 사진"이었습니다. 사진의 가치는 나중에 비교할 때 생긴다고 했습니다 — 오늘이 그 "나중"입니다. v2.0의 작업은 크게 세 종류입니다.

수정: v1.0에 적었지만 실전에서는 다르게 행동하게 된 절차
추가: v1.0에 없던 단계 — AD 체인의 정교화, 버그바운티 정찰, 시나리오 운용
삭제: 한 번도 펴 보지 않은 카드, 더 이상 안 쓰는 도구

이 중 가장 가치 있는 것은 삭제입니다. v1.0을 만든 날의 여러분은 "언젠가 쓸지도 모르는 것"을 넣었을 것입니다. 일흔 Step을 지나며 한 번도 펴지 않은 카드가 있다면, 그것은 앞으로도 펴지 않습니다. 지우는 것이 개정입니다.

2-2. 비평적 재독 — "실제로는 이렇게 안 했다"를 찾아내기

개정의 첫 동작은 쓰기가 아니라 읽기입니다. v1.0을 처음부터 끝까지 읽되, 각 절차 옆에 세 가지 도장 중 하나를 찍습니다.

비평적 재독의 도장 세 가지:
[그대로] — 최근 실전에서도 이 절차대로 했다
[수정  ] — 방향은 맞지만 실제로는 더 짧게/다르게 했다
[폐기  ] — 한 번도 이렇게 하지 않았다, 책상 위의 절차였다

"수정"과 "폐기" 도장이 찍힌 곳이 v2.0의 작업 구역입니다. 여기서 중요한 태도 — v1.0을 존중하되 신뢰하지 마세요. v1.0의 저자는 일흔 Step 전의 여러분이고, 그 사람은 지금의 여러분보다 모릅니다. 문서가 아니라 기억과 기록이 심판입니다.

2-3. 검증 사례 링크의 승격 — 링크에서 표로

Step 272에서는 각 카드에 write-up 링크 하나를 거는 것으로 검증을 표시했습니다. v2.0에서는 이것을 검증 표로 승격합니다. 절차마다 "언제, 어떤 대상에서, 어떤 결과로" 검증됐는지가 보여야, 전투 중에 그 절차를 믿을 근거가 생깁니다.

### 절차 카드의 v2.0 형식 (예시)
#### SMB 열거 — 초기 접촉
crackmapexec smb 대상IP -u '' -p '' --shares
| 검증 | 날짜 | 대상 | 결과 |
|------|------|------|------|
| ✅ | OSCP 모의시험 2 | 머신 B | 익명 공유 READ — flag 단서 |
| ✅ | Step 343 시나리오 | 랩 워크스테이션 | null session 거부 → 다음 카드로 |

검증 표에는 실패한 사례도 싣습니다. "이 환경에서는 안 먹혔다"는 기록이 다음 시도의 분기를 결정하니까요. 성공만 기록된 플레이북은 절차의 한계를 모르는 문서입니다.

2-4. 도구 목록 갱신 — 도구 상자의 정리

v1.0 이후 여러분의 손은 바뀌었습니다. 새 도구를 익혔고, 어떤 도구는 더 빠른 대안에 자리를 내줬고, 어떤 도구는 별칭과 스크립트로 자동화됐습니다. 도구 목록의 갱신 규칙은 단 하나입니다 — 지난 3개월간 실제로 실행한 도구만 남긴다.

쉘 히스토리가 심판입니다. 실제로 무엇을 쳤는지가 "무엇을 쓰는 도구인가"의 정의이기 때문입니다. 3-4에서 이것을 명령으로 확인합니다.

2-5. 변경 이력과 개정 주기 — 문서의 생명주기

v1.0의 개정 규칙은 "새 머신/대회마다 배운 것 1개 이상 반영"이었습니다. 이 규칙은 잘 작동했지만 한계가 있었습니다 — 작은 반영은 쌓이는데, 구조 전체의 재점검은 아무에게도 배정되지 않았습니다. 그래서 v2.0부터는 두 층의 개정을 둡니다.

상시 개정: 기존 규칙 그대로. 실전 직후, 배운 것을 해당 절에 즉시 반영
정기 개정: 분기 1회, 오늘 같은 전면 재독. 버전 번호가 오르는 자리

변경 이력은 CHANGELOG.md 한 파일에 날짜 내림차순으로 쌓습니다. git log가 아니라 별도 파일인 이유 — changelog는 "무엇이 왜 바뀌었는가"의 서사가 필요하고, 커밋 메시지는 그 서사를 담기에 너무 좁습니다.

3. 따라 하기

3-1. 개정 후보 수집 — 자산의 전수 조사

v1.0 이후의 자산을 한 디렉터리 목록으로 모읍니다. Git Bash에서 각 저장소를 훑으며 후보를 적습니다.

입력 (Git Bash):

ls ~/wiki ~/oscp-notes ~/bugbounty 2>/dev/null
ls playbook/

출력 예시:

ad-paths.md  oscp-checklist.md  report-template.md  시나리오-timeline.md
recon-procedure.md  triage-log.md
01_정찰/  02_서비스별_열거/  03_침투_패턴/  04_리눅스_privesc/
05_윈도우_privesc/  06_AD/  07_피벗팅/  막힘_대처_트리.md

그리고 개정 후보 목록 파일을 만듭니다 — playbook/v2_작업목록.md. 각 자산 옆에 "어느 절로 가는가"를 적는 것이 전부입니다.

v2 작업 목록 (화면 예시):
- oscp-checklist.md      → 01, 04, 05 절 보강 (열거 순서가 바뀌었다)
- 시나리오-timeline.md   → 신규 08 절 "시나리오 운용" 제안
- recon-procedure.md     → 01 절에 "실서비스 정찰" 하위 카드 추가
- ad-paths.md            → 06 절 전면 개정 (경로가 3개에서 9개로)

왜 하는가: 개정의 실패 패턴 1위는 "모으다가 지쳐서 쓰지 못하는 것"입니다. 그래서 수집 단계의 산출물을 문서가 아니라 목록 한 장으로 제한합니다. 목록이 완성되면 수집은 끝입니다 — 각 자산의 정독은 해당 절을 개정할 때 하면 됩니다.

3-2. 비평적 재독 — 도장 찍기

v1.0의 각 파일을 열어 2-2의 도장을 찍습니다. 판정의 근거는 반드시 기록입니다 — 최근 훈련 타임라인, OSCP 노트, 대회 로그. 기억이 흐릿하면 그 절차는 "미검증"으로 돌려 보냅니다.

비평적 재독 결과 (화면 예시):
01_정찰/nmap_템플릿.md
  1차 카드 [그대로] — OSCP 실기에서도 이 순서였다
  2차 카드 [수정 ] — --min-rate 2000 → 3000으로 올렸다 (모의시험 2 기록)
  3차 UDP [수정 ] — 실전에서는 거의 안 돌렸다. "의심 단서 있을 때만"으로 격하
막힘_대처_트리.md
  3단계 HackTricks [수정 ] — 최근에는 내 write-up 저장소 검색이 먼저였다
  5단계 24시간 방치 [그대로] — Step 343에서도 이것이 열었다

읽는 법: "수정" 도장의 메모가 곧 v2.0의 diff입니다. 이 단계에서 문서를 고치지 마세요 — 도장만 찍습니다. 읽기와 쓰기를 섞으면 재독이 중간에 멈춥니다.

3-3. 절별 개정 — 수정·추가·삭제의 실행

도장이 다 찍히면 절을 하나씩 개정합니다. 각 절의 작업 순서는 고정입니다 — ① 수정 도장 처리, ② 새 자산의 카드 추가, ③ 폐기 도장 삭제, ④ 각 카드에 검증 표 부착.

v2.0에서 새로 생기는 대표적인 변화 세 가지를 예로 듭니다.

① 막힘 대처 트리의 순서 변경 — 최근 데이터가 옛 순서를 뒤집었습니다.

# 막힘 대처 트리 v2
1. 열거 재검토 — 안 본 포트/페이지가 있나
2. 내 write-up 저장소 검색 — 비슷한 머신을 전에 풀었나   # v1의 3단계 HackTricks 앞으로
3. 자산 목록 × 미시도 표면 곱하기
4. 서비스별 HackTricks 페이지 확인
5. 더 넓은 스캔 — 전체 포트, UDP, 대형 워드리스트
6. 24시간 방치 후 재시도
> 개정 근거: 최근 10회 정체 중 6회는 2번(내 기록 검색)에서 해소 (Step 330~343 로그)

② 신규 절 "08 시나리오 운용" — Step 343의 타임라인 운용 규칙이 카드로 승격됩니다.

# 08 시나리오 운용 — 여러 머신을 하나의 작전으로
- 시작 시 목표 문장 1개 선언 ("DC의 X 파일 획득")
- 발견 즉시 자산 지도에 추가 — 크리덴셜 표 + 네트워크 그림
- 시간축 로그: 시각 / 행동 / 결과 / 얻은 정보
> 검증 사례: Step 343 종합 시나리오 (타임라인 41행, 체인 5단계)

③ 도구 카드의 삭제 — 3개월간 실행 기록이 없는 카드는 지웁니다. 지운 목록은 CHANGELOG에 "삭제: 이유"로 남깁니다 — 삭제의 근거가 나중의 되살림 판단을 도와줍니다.

3-4. 도구 목록 갱신 — 히스토리가 심판

실제로 무엇을 쓰고 있는지 히스토리로 확인합니다.

입력 (Git Bash):

history | awk '{print $2}' | sort | uniq -c | sort -rn | head -20

출력 예시:

    412 cd
    287 ls
    198 grep
    141 python
    118 nmap
     97 git
     84 crackmapexec
     71 gobuster
     ...

읽는 법: 이 목록에 없는 도구가 플레이북에 있다면, 그 카드는 의심 대상입니다. 반대로 이 목록 상위에 있는데 플레이북에 없는 도구가 있다면 — 예컨대 crackmapexec을 매일 치는데 카드가 없다면 — 그것이 v2.0의 가장 시급한 추가입니다. WSL의 랩 환경에서 작업했다면 wsl -d <랩이름> -- bash -c "history | ..."로 랩 쪽 히스토리도 같은 방법으로 확인하세요.

3-5. CHANGELOG 작성과 v2.0 선언

playbook/CHANGELOG.md를 만들고 첫 항목을 기록합니다.

# 플레이북 변경 이력

### v2.0 (2026-09-XX)
- 수정: 01 절 nmap 카드 --min-rate 상향, UDP 카드 격하 (근거: 모의시험 2)
- 수정: 막힘 트리 순서 변경 — 내 write-up 검색을 2번으로 (근거: 최근 10회 정체 로그)
- 추가: 08 시나리오 운용 절 신설 (근거: Step 343)
- 추가: 실서비스 정찰 카드 (근거: 버그바운티 시즌)
- 삭제: 미사용 도구 카드 N장 (근거: 3개월 히스토리)
- 제도: 분기 1회 정기 개정 선언. 다음 재독 예정일: ____.

### v1.0 (과거 날짜)
- 첫 완성. 8개 절 뼈대 + 명령 카드 N장.

그리고 커밋합니다 — 플레이북 v2.0. 마지막으로 README의 버전 절을 고치고, 다음 정기 개정일을 캘린더에 등록합니다. 캘린더에 없는 개정 주기는 선언이 아니라 바람입니다.

4. 미션과 연습문제

미션 — 플레이북 v2.0 완성

v1.0 이후의 자산을 전수 조사해 v2_작업목록.md를 완성한다
v1.0 전 절을 비평적 재독하고 세 가지 도장(그대로/수정/폐기)을 찍는다
절별 개정을 실행한다 — 수정·추가·삭제 + 모든 카드에 검증 표 부착
도구 목록을 히스토리 기준으로 갱신하고, 삭제한 카드의 근거를 CHANGELOG에 남긴다
CHANGELOG.md에 v2.0 항목을 기록하고, 개정 주기와 다음 재독일을 캘린더에 등록한 뒤 v2.0 커밋을 남긴다

연습문제

문제 1. v2.0 개정의 세 동작(수정·추가·삭제) 중 가장 가치 있는 것이 "삭제"인 이유를 설명해 보세요.

문제 2. 비평적 재독에서 "도장 찍기"와 "고치기"를 분리하는 이유를, 읽기와 쓰기의 작업 특성 차이로 설명해 보세요.

문제 3. 검증 표에 실패 사례도 싣는 이유를, "성공만 기록된 플레이북"의 한계와 대조해 설명해 보세요.

문제 4. 상시 개정과 정기 개정의 두 층 구조가 필요한 이유를, v1.0의 개정 규칙("실전마다 1개 반영")의 한계로 설명해 보세요.

5. 모범 답안과 완료 기준

미션 모범 답안

3-1~3-5의 흐름이 곧 답입니다. 작업 목록 한 장 → 도장 찍힌 재독 → 절별 개정(검증 표 포함) → 히스토리 기반 도구 갱신 → CHANGELOG와 캘린더 등록, 그리고 v2.0 커밋.

검증하는 법: ① git diff v1.0..v2.0에 수정·추가·삭제 세 종류가 모두 보이는가. ② 모든 카드에 검증 표(성공+실패 사례)가 있는가. ③ CHANGELOG의 각 항목에 근거(날짜/머신/로그)가 붙어 있는가. ④ 삭제된 카드 목록과 이유가 기록됐는가. ⑤ 다음 정기 개정일이 캘린더에 실제로 등록됐는가. ⑥ git log에 v2.0 커밋이 있는가.

연습문제 해답

문제 1 해답. 삭제는 "나는 이것을 안 쓴다"는 검증된 지식의 기록이기 때문입니다. 수정과 추가는 문서를 키우지만, 삭제는 문서의 신뢰 밀도를 높입니다 — 남아 있는 카드 전부가 실전에서 펴는 것임을 보증하니까요. 또한 "한 번도 펴지 않은 카드"는 미래에도 펴지 않을 확률이 높고, 그런 카드가 섞여 있으면 전투 중 "이걸 펴야 하나 말아야 하나"의 판단 비용이 매번 발생합니다. 지우는 것은 잃는 것이 아니라, 남은 것들의 가치를 올리는 행위입니다.

문제 2 해답. 읽기(판정)와 쓰기(개정)는 서로 다른 사고 모드입니다. 재독은 전체를 훑으며 분포를 보는 일이고, 개정은 한 절에 몰입하는 일입니다. 둘을 섞으면 첫 몇 절만 정성껏 고치고 뒷 절은 지쳐서 넘어가는 편향이 생깁니다. 도장만 찍는 재독을 끝내면 "작업량의 지도"가 먼저 완성되므로, 개정의 우선순위와 분배를 계획할 수 있습니다. 또한 도장 단계에서는 기록을 대조하며 판정하므로, 고치기 시작한 뒤의 "이렇게 고치고 싶다"는 욕심이 판정을 오염시키는 것도 막습니다.

문제 3 해답. 성공만 기록된 플레이북은 절차의 적용 한계를 모르는 문서입니다. "익명 공유 열거가 먹혔다"는 기록만 있으면 다음 실전에서 안 먹혔을 때 절차가 잘못된 건지 환경이 다른 건지 판단할 수 없습니다. 실패 사례("null session 거부 환경에서는 다음 카드로")가 함께 있으면 절차의 전제 조건이 드러나고, 전투 중 분기 판단이 빨라집니다. 검증 표의 성공 열은 "믿어도 된다"를, 실패 열은 "언제까지 믿는가"를 알려 줍니다.

문제 4 해답. 상시 개정은 절차 단위의 개선 — 카드 한 장의 옵션 변경, 링크 추가 — 에는 강하지만, 구조 단위의 문제에는 무력합니다. 절의 분할이 현실과 어긋나거나, 트리의 순서가 통계적으로 틀렸거나, 절반의 카드가 사장(死藏)되는 문제는 "실전마다 1개 반영"으로는 드러나지 않습니다 — 그 규칙은 전체를 다시 읽는 자리를 만들지 않기 때문입니다. 정기 개정은 그 자리를 제도로 보장합니다. 상시가 문장을 고치는 일이라면, 정기는 목차를 고치는 일입니다.

완료 기준 체크리스트

[ ] v1.0 이후 자산의 전수 조사 목록(v2_작업목록.md)을 만들었다
[ ] v1.0 전 절에 세 가지 도장(그대로/수정/폐기)을 찍는 재독을 끝냈다
[ ] 수정·추가·삭제 세 종류의 개정을 모두 실행했다
[ ] 모든 카드에 성공·실패 사례를 포함한 검증 표를 붙였다
[ ] 도구 목록을 쉘 히스토리 기준으로 갱신했다
[ ] 삭제한 카드와 그 근거를 CHANGELOG에 남겼다
[ ] CHANGELOG에 v2.0 항목을 기록하고 다음 정기 개정일을 캘린더에 등록했다
[ ] 미션: 플레이북 v2.0 커밋을 남겼다

6. 흔한 실수와 해결

벽 1. 완벽하게 다듬으려다 개정이 끝나지 않아요

증상: "08 절을 더 다듬고 나서 커밋해야지"를 3주째 반복 중입니다.

원인: v2.0을 완성품으로 오해했습니다 — v1.0 때와 같은 함정의 재발입니다.

해결: 플레이북은 참고서가 아니라 작전 매뉴얼입니다. 기준은 단 하나 — "다음 실전에서 내가 실제로 펴 볼 형태인가". 그 형태면 커밋하세요. 완벽함보다 개정의 순환이 중요합니다. 순환이 돌면 v2.1, v2.2에서 얼마든지 다듬어집니다. 커밋되지 않은 개정은 순환에 들어가지 못합니다.

벽 2. 재독하다 보니 v1.0이 부끄러워서 전부 갈아엎고 싶어요

증상: 도장이 아니라 전면 재작성 욕구가 올라옵니다.

원인: 일흔 Step의 성장이 커서 옛 문서가 유치해 보이는 것 — 자연스러운 감정입니다.

해결: 그 부끄러움은 재작성이 아니라 CHANGELOG의 문장으로 표현하세요. "v1.0의 이 절차는 입문기의 것이었고, 지금은 이렇게 한다" — 이 대비가 문서의 가치입니다. v1.0을 지우지 마세요. git tag로 남겨 두세요. 1년 뒤 v3.0을 개정할 때, 그 태그가 여러분의 성장 폭을 증명하는 자료가 됩니다.

벽 3. 히스토리 기준으로 지우려니 "나중에 필요하면 어쩌지"가 두려워요

증상: 삭제 도장을 찍고도 실행을 못 합니다.

원인: 삭제를 소실로 오해했습니다. Git 저장소에서 삭제는 소실이 아닙니다.

해결: 두 장치를 기억하세요. ① Git 이력 — 지워진 카드는 git log와 CHANGELOG의 "삭제: 이유" 항목으로 언제든 되살릴 수 있습니다. ② 스크랩북 분리 — 정 미련이 남는 카드는 플레이북이 아니라 위키의 "보관함"으로 옮기세요. 플레이북의 자격 기준("최근 3개월 내 실행")을 통과 못 한 것과 지식 자체를 버리는 것은 다릅니다.

벽 4. history 명령이 아무것도 안 보여줘요

증상: Git Bash에서 history를 쳤는데 몇 줄 없거나, 지난 세션의 기록이 없습니다.

$ history | wc -l
12

원인: 셸 히스토리는 기본적으로 세션 종료 시 저장되고, Git Bash의 기본 설정은 저장 크기가 작습니다. 그리고 진짜 작업은 WSL 랩에서 했다면 Git Bash 히스토리에는 애초에 없습니다.

해결: 작업이 일어난 셸의 히스토리를 봐야 합니다 — 랩 작업이 WSL이었다면 wsl -d <랩이름> -- bash -c "history | awk ..."로 랩 쪽을 확인하세요. 그래도 기록이 부족하면 이번 개정은 기억과 훈련 로그(타임라인, write-up)를 심판으로 쓰고, 다음 개정을 위해 히스토리 저장을 키워 두세요(HISTSIZE, HISTFILESIZE).

벽 5. CHANGELOG의 "근거"를 쓰려니 기록이 없어요

증상: "이 카드를 왜 고쳤더라" — 대회 로그를 뒤져도 그날의 판단이 안 나옵니다.

원인: 배운 것을 반영한 시점과 기록한 시점이 어긋났습니다. 상시 개정을 커밋만 하고 근거를 안 적은 것입니다.

해결: 이번에는 정직하게 "근거: 기억 (미검증)"으로 적고 넘어가세요 — 꾸며낸 근거보다 미검증 표시가 낫습니다. 그리고 제도를 고치세요: 상시 개정의 커밋 메시지 형식을 반영: 내용 (근거: 날짜/대상)으로 고정합니다. 형식이 비어 있으면 커밋을 미루게 되고, 그 미룸이 기록을 강제합니다.

7. 정리

오늘의 개념

개념	한 줄 설명
개정의 세 동작	수정(현실과 다른 절차) · 추가(새 자산) · 삭제(안 펴는 카드) — 삭제가 최고 가치
비평적 재독	도장(그대로/수정/폐기)만 찍는 읽기와 고치는 쓰기의 분리
검증 표	절차별 성공+실패 사례의 기록 — 신뢰와 적용 한계의 증거
히스토리 갱신	"실제로 친 명령"만이 "쓰는 도구" — 쉘 히스토리가 심판
두 층 개정	상시(실전마다 1개 반영) + 정기(분기 1회 전면 재독)
CHANGELOG	무엇이 왜 바뀌었나의 서사 — 삭제의 근거도 여기에

오늘의 명령

명령	용도
`git diff v1.0..HEAD`	개정 전후의 비교
`git tag v1.0`	옛 버전의 보존 (지우지 않기)
`history \| awk '{print $2}' \| sort \| uniq -c \| sort -rn`	실제 사용 도구의 순위
`grep -rn "키워드" playbook`	개정 후에도 검색 가능성이 살아 있는지 확인
`git commit -m "플레이북 v2.0"`	개정의 기준점 선언

명령어보다 중요한 감각

플레이북의 버전 숫자는 문서의 버전이 아니라 여러분의 버전입니다. v1.0을 만든 사람과 v2.0을 만든 사람 사이의 일흔 Step이 git diff에 고스란히 남아 있습니다 — 더 짧아진 절차, 더 냉정해진 삭제, 더 촘촘해진 검증 표. 그 diff가 성장의 가장 정직한 증거이고, 이 문서가 살아있는 한 그 증거는 계속 쌓입니다.

그리고 순환을 기억하세요. 오늘의 v2.0은 끝이 아니라 두 번째 바퀴의 시작점입니다. 다음 실전에서 이 문서가 한 번이라도 "펴지는" 순간, 그 페이지는 다시 개정 후보가 됩니다. 실력을 복리로 불리는 엔진은 화려한 신기법이 아니라 이 지루한 순환입니다 — 실전, 반영, 개정, 다시 실전.

전부 체크되면 Step 344 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.