Learning Principles
원칙
- 새 문서를 많이 만들기보다 기존 문서 하나를 쓸모 있게 만든다.
- 개념 설명은 반드시 실무 문제, 판단 기준, 짧은 기술 답변으로 연결한다.
- “정의는 아는데 언제 쓰는지 모르는 상태”를 완료로 보지 않는다.
- AI 답변은 초안으로만 쓰고 공식 문서, 코드, 실행 결과로 검증한다.
최종 목표
- 실무에서 문제를 예방하고 원인을 좁힐 수 있다.
- 기술 질문을 받았을 때 개념, 원리, 장단점, 실무 사례를 연결해 설명할 수 있다.
- 암기한 답변이 아니라 실제 판단 기준을 말할 수 있다.
- 각 문서는 나중에 기술 답변과 실무 체크리스트로 재사용할 수 있어야 한다.
학습 루프
- daily-study-board 또는 mastery-map에서 학습할 주제를 고른다.
- 해당 주제 인덱스에서 질문 하나를 고른다.
- 기존 문서가 있으면 보강하고, 없으면
_templates/concept-template.md로 작은 문서 하나를 만든다. - 실무에서 문제가 되는 상황을 먼저 쓴다.
- 동작 원리와 해결 절차를 쓴다.
- 한계, 부작용, 잘못 쓰는 경우를 쓴다.
- 마지막에 핵심 요약과 꼬리 질문을 남긴다.
완료 기준
아래 항목이 없으면 아직 미완성 문서로 본다.
| 항목 | 확인 질문 |
|---|---|
| 문제 상황 | 이 개념을 모르면 어떤 버그, 장애, 성능 문제가 생기는가? |
| 동작 원리 | 내부에서 어떤 순서로 동작하는가? |
| 판단 기준 | 어떤 상황에서 쓰고, 어떤 상황에서 피해야 하는가? |
| 트레이드오프 | 성능, 정합성, 복잡도, 운영 비용 중 무엇을 잃는가? |
| 검증 방법 | 로그, 테스트, 실행 계획, 메트릭 등으로 어떻게 확인하는가? |
| 기술 답변 | 1분 안에 정의, 원리, 실무 예시를 말할 수 있는가? |
문서 작성 순서
좋은 순서는 “정의 → 원리 → 실무”가 아니라 “문제 → 원리 → 판단”이다.
- 어떤 문제가 생기는지 쓴다.
- 왜 그런 문제가 생기는지 원리를 쓴다.
- 해결 옵션을 비교한다.
- 실무 체크리스트를 남긴다.
- 짧은 기술 답변으로 압축한다.
커밋 예시
git add .
git commit -m "docs: refine jpa persistence context"
git push origin main