성장 기록

성장 기록 스킬

문제점: 대부분의 사람들은 학습 기록을 "X에서 버그 수정"과 같이 작성합니다. 그것은 일기 항목이지 학습 자산이 아닙니다. 진정한 성장 기록은 다음에 다시 인식할 수 있도록 패턴을 추출합니다.

이 스킬이 가르치는 것: 세션 전반에 걸쳐 축적되는 학습 항목을 작성하는 방법입니다. Markdown 파일, Notion, Obsidian, 일반 텍스트 등 모든 노트 시스템과 함께 작동합니다. 템플릿은 일반적이므로 자신의 환경에 맞게 조정하십시오.

활성화 시점

• 복잡한 작업 완료 후 (다중 파일, 새 기능, 아키텍처 변경)
• 실패, 실수, 또는 "예상보다 어려웠다"라는 순간 후
• 일정 기간 동안 배운 내용을 검토하고 싶을 때

활성화하지 말아야 할 때: 사소한 변경(오타 수정, 한 줄 변경, 디버깅 없는 설정 값 변경). 기준: 이 작업에 디버깅, 재작업, 롤백 또는 명확하지 않은 결정이 포함되었는가? 그렇다면 → 항목 작성. 아니라면 → 건너뜁니다.

세 가지 규칙

규칙 1: 실패 > 성과

실패는 성공보다 영양 밀도가 높습니다. 발견하는 데 2시간이 걸린 버그 하나가 처음에 바로 작동한 3가지 기능보다 더 많은 것을 가르칩니다.

나쁨: "로그인 흐름을 성공적으로 구현했습니다." 좋음 (웹 개발): "로그인 흐름: Chrome 128+에서 쿠키 SameSite가 기본값으로 Lax로 설정되어 세션 토큰이 유지되지 않았습니다. 패턴: 교차 출처일 때 항상 SameSite=None; Secure를 명시적으로 설정하세요. 인식 신호: 브라우저 업그레이드 후 또는 출처 경계를 넘을 때 인증이 중단됩니다." 좋음 (데이터 파이프라인): "CSV 가져오기가 빈 행에서 pandas.read_csv(dropna=False)가 len()이 유효한 것으로 계산하는 너비가 0인 행을 유지하기 때문에 자동으로 실패했습니다. 패턴: 행 개수 검증 전에 항상 df.dropna(how='all', inplace=True)를 실행하세요."

규칙 2: 보올 원칙 (伯乐原则)

새 항목을 작성하기 전에 물어보세요: "이것은 기본적으로 내가 이미 기록한 것과 동일한가?"

동일한 근본 원인, 다른 증상 → 병합, 중복 생성 금지. 새로운 근본 원인 → 새 항목.

확인 방법: 작성 전에 근본 원인의 키워드로 기존 항목을 검색하십시오. 일치하는 항목을 찾으면 중복 항목을 만드는 대신 기존 항목 아래에 새 증상을 추가 예시로 추가하십시오.

예시: "파일 생성 후 출력 인덱스 업데이트를 잊음"과 "작업 후 스킬 평가 업데이트를 잊음" — 동일한 근본 원인(자동 캡처 트리거 없음). "작업 후 캡처 공백"에 대한 하나의 항목으로 병합하십시오.

규칙 3: 전이 가능해야 함

모든 항목은 다음 질문에 답해야 합니다: "다음에 비슷한 상황에 직면했을 때, 나는 무엇을 다르게 할 것인가?"

그 문장을 쓸 수 없다면 아직 패턴을 추출하지 않은 것입니다.

구체적인 사건에서 패턴을 추출하는 방법:

1. 한 문장으로 무슨 일이 일어났는지 진술
2. 근본 원인에 도달할 때까지 반복적으로 "왜?"를 질문 (보통 3-5회)
3. 일반화: "이것은 어떤 종류의 문제인가?" ("Chrome 128 버그"가 아닌 "기존 동작을 깨는 브라우저 기본값 변경")
4. 공식화: "다음에 [신호]를 보면, 나는 [행동]을 할 것이다."
5. 신호 이름 지정: 어떤 특정 관찰 가능한 것이 이 패턴이 활성화되었음을 알려주는가?

항목 템플릿

범위: 고유 근본 원인당 하나의 항목. 일반적인 길이: 4-8문장. 작성하는 데 2분 이상 걸리면 이벤트를 나열하고 있는 것입니다. 30초 미만이면 충분히 깊이 들어가지 않은 것입니다.

## [제목: 사건이 아닌 패턴]

### 컨텍스트
- 무엇을 하려고 했는가?
- 무엇이 잘못되었는가 / 무엇이 놀라울 정도로 잘 작동했는가?

### 근본 원인 / 핵심 통찰
- 증상뿐만 아니라 기본 메커니즘

### 패턴 (전이 가능)
- 다음에 [비슷한 상황]에서, 나는 [특정 행동]을 할 것이다.
- 인식할 신호: [무엇이 이 패턴이 활성화되었음을 알려주는가?]

### 관련
- [항목 이름](../path/to/related-entry.md)

항목 유형

네 가지 유형 모두 위 템플릿을 사용합니다. 유형은 어떤 섹션이 가장 중요한지를 결정합니다:

유형	사용 시기	강조점	예시 제목
실패	무언가 고장 나거나, 디버깅이 필요하거나, 재작업이 필요했을 때	근본 원인	"세션 간 구성 상속 ≠ 동작 상속"
방법론	작업에서 반복 가능한 프로세스가 도출되었을 때	컨텍스트 / 패턴	"PPT → 오픈북 시험 학습 가이드: 3계층 구조"
패턴 발견	도구, 시스템 또는 사고에 대한 재사용 가능한 통찰력	패턴 섹션	"PR 설명 템플릿: 기능이 아닌 차이점을 설명하라"
역량 변화	측정 가능한 기술 향상	컨텍스트 (이전 vs 이후)	"Git: clone/push에서 12개 커밋이 있는 독립 PR까지"

품질 체크리스트

성장 기록 항목을 최종 확정하기 전에:

• 제목이 사건이 아닌 패턴을 나타내는가?
• "다음에 나는 ...을 할 것이다"라는 문장이 있는가?
• "인식할 신호"가 다음에 패턴을 트리거할 수 있을 만큼 구체적인가?
• 작성 전에 기존 항목에서 중복을 검색했는가? (보올 원칙)
• 근본 원인이 증상과 구분되어 있는가?
• 관련 기억들이 상호 연결되어 있는가?
• 항목이 4-8문장인가? 더 짧으면 = 너무 얕음; 더 길면 = 사건을 나열하는 것.

안티 패턴

• 피해야 할 것: "결제 모듈에서 버그 수정" (사건, 패턴 아님)
• 피해야 할 것: git 커밋 메시지를 그대로 복사 (커밋은 무엇이 변경되었는지 설명; 로그는 왜 중요한지 추출)
• 피해야 할 것: 모든 커밋에 대해 항목 작성 (패턴이 나타날 때만)
• 피해야 할 것: 전이 가능 문장 생략 (없으면 그냥 일기입니다 — 이것은 협상 불가)
• 피해야 할 것: 동일한 패턴을 다른 제목 아래 중복 (보올 원칙 위반 — 작성 전 검색)

저장

노트를 보관하는 곳에 항목을 저장하십시오. 일반적인 패턴:

• growth-log/ 디렉토리의 Markdown 파일 (날짜별 파일: YYYY-MM-DD.md)
• Notion, Obsidian 또는 노트 앱의 전용 섹션
• 일관된 명명 규칙을 가진 일반 텍스트 파일

하나의 규칙을 선택하고 고수하십시오. 검색 가능성이 형식보다 중요합니다.

전달 게이트를 사용하는 경우

delivery-gate 중지 훅은 파일 시스템 타임스탬프를 통해 오늘 학습 파일이 수정되었는지 확인합니다. 이 스킬은 무엇을 쓸지를 가르칩니다 — 따라서 전달 게이트가 확인하는 파일에 빈 타임스탬프가 아닌 실제로 유용한 패턴이 포함됩니다.

작업 완료 → 전달 게이트 확인: 학습 파일이 오늘 수정되었는가?
  → 오래됨 (수정된 파일 없음): 차단 — "무엇을 배웠습니까?"
  → 최신 (파일 수정됨): 통과 — 이 스킬은 내용이 유용함을 보장합니다

강제 없이 방법론만 있으면 → 빈 항목. 방법론 없이 강제만 있으면 → 학습 내용 캡처를 잊어버림. 각각은 독립적으로 유용하며 함께 사용하면 학습 루프를 완성합니다.