성장 로그

성장 로그 스킬

문제점: 대부분의 사람들은 "X에서 버그 수정"을 학습 로그로 작성합니다. 그건 일기 항목이지 학습 결과물이 아닙니다. 진정한 성장 로그는 패턴을 추출하여 다음 번에 인식할 수 있게 합니다.

이 스킬이 가르치는 것: 세션을 넘어 복리로 쌓이는 학습 항목을 작성하는 방법입니다. Markdown 파일, Notion, Obsidian, 일반 텍스트 등 모든 노트 시스템에서 작동합니다. 템플릿은 범용적이므로 자신의 환경에 맞게 조정하세요.

활성화 시점

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

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

세 가지 규칙

규칙 1: 실패 > 성취

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

나쁨: "로그인 플로우를 성공적으로 구현했습니다." 좋음 (웹 개발): "로그인 플로우: 세션 토큰이 유지되지 않았습니다. 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 설명 템플릿: 기능이 아닌 차이점을 설명하라"
능력 변화	측정 가능한 스킬 향상	맥락 (전후 비교)	"Git: clone/push에서 12개 커밋의 독립적인 PR까지"

품질 체크리스트

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

• 제목이 사건이 아닌 패턴을 명명하고 있는가?
• "다음 번에 나는..." 문장이 있는가?
• "인식할 신호"가 다음 번에 패턴을 촉발할 만큼 구체적인가?
• 작성 전에 기존 항목에서 중복을 검색했는가? (보올 원칙)
• 근본 원인이 증상과 구분되어 있는가?
• 관련 기억이 교차 연결되어 있는가?
• 항목이 4-8문장인가? 더 짧으면 너무 얕고, 더 길면 사건을 서술하는 것입니다.

안티 패턴

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

저장

노트를 보관하는 어디든 항목을 저장하세요. 일반적인 패턴:

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

하나의 관례를 선택하고 유지하세요. 형식보다 검색 가능성이 중요합니다.

Delivery Gate를 사용하는 경우

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

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

방법론 없는 강제 → 빈 항목. 강제 없는 방법론 → 잊혀진 캡처. 각각은 독립적으로 유용하지만, 함께 사용하면 루프를 완성합니다.