학생 적용 가이드 — 14 원칙을 어디서·언제 적용하는가
도메인 모르는 학생이 14 원칙을 다 배운 후 마비되는 함정의 답. overview·reading-guide 다음에 오는 적용 단계 가이드. synthesis-complex-to-simple의 통합 명제를 학생 단위로 운영하는 timeline.
한 줄
도메인 모름이 정상이고, 14 원칙은 처음부터 다 적용할 게 아니라 문제가 발생할 때 답을 찾는 카탈로그. Tracer bullet으로 시작 → vibe coding으로 작동 → 비용 발견 → 그때 원칙 등장이 자연 path. 원칙을 *외우려 하지 말고 카탈로그로 두기. 불편함이 신호, 신호 없으면 적용 X.
🧭 핵심 mental model — 3가지
1. 14 원칙 = 답 카탈로그, 문제 카탈로그가 아님
- ❌ "deep module을 만들어야지" (원칙을 처음부터 적용)
- ✅ "왜 코드를 navigate 못하지?" → 카탈로그 검색 → deep module 답 발견
원칙을 외우지 말고 문제 발생 시 reading-guide 카탈로그에서 검색.
2. Vibe coding은 entry point로 정당
simple-not-easy 인사이트 5 다시: 학내 학생 easy → simple 학습 path:
- Day 0-1은 vibe coding이 합리적 선택
- 비용을 의식한 순간부터 fundamentals 흡수
- "vibe coding 절대 X" 같은 강박은 잘못된 학습
3. Strategic은 순간이 아니라 반복에서 발생
- 처음에는 strategic 없어도 OK
- 같은 패턴 3번 반복되면 그때 strategic 결정 (Rule of three)
- 원칙이 자연 등장하는 자리
⏱️ 학생의 자연 timeline
*14 원칙은 시간에 따라 자연 등장. 학생이 의식하지 않아도 시스템이 가르쳐준다.
| 시점 | 활동 | 자연 등장 원칙 | 왜 등장 |
|---|---|---|---|
| Day 0-1 | "이거 해봐야겠다" → tracer bullet 발사 | (아직 X — 그냥 vibe coding) | 도메인 탐색. easy가 정당 |
| Day 2-7 | 작은 작동 확인. AI에게 시켜 결과 받기 | ship-and-rollback-as-normal (git commit), named-ownership (자기 도구) | 자동 강제 — git 쓰면 자동, 자기 도구라 자동 |
| Week 2 | 같은 단어 반복 ("수강신청", "정정") | ubiquitous-language | AI verbose 응답 → vocabulary skill 욕구 |
| Week 3 | 코드가 작은 파일 30개로 흩어짐 | deep-modules | navigate 어려움 → "왜 이렇게 분산?" 인지 |
| Week 4 | 변경 시 다른 부분 깨짐 | orthogonality | 한 변경 → cascading. 왜? 질문 |
| Sprint 2 | 외부 시스템 변경 → 모든 도구 깨짐 | anti-corruption-layer | 외부 변화에 코드 망가짐 → 격리 욕구 |
| Sprint 2 | AI가 test 무시하고 코드 변경 | tdd-as-small-deliberate-steps | garbage 누적 발견 → "AI에게 test 보호 강제" 필요 |
| Sprint 3 | "이쪽 도구 / 저쪽 도구" 분리됨 | bounded-context | 도메인이 나뉨을 인지 |
| Production 직전 | 사용자 1명 생김 | reversibility, information-hiding | 결정 무게 변함, 사용자가 내부에 의존 |
| Production | 1학기 후 후배에게 전달 | named-ownership (transfer), information-leak-vs-abstraction (leak 측정) | 인계 비용 |
→ Day 0-1에는 14 원칙 중 0개도 의식 안 함. Sprint 3쯤이면 절반 이상이 자연스럽게 적용됨.
🎯 어디서부터? — Tracer Bullet 4단계
tracer-bullets 명제의 학생 단위 운영:
1. 무엇을 만들지 한 줄로 적기
"수강신청 시간표 충돌 검사기"
"학과 공지 모아보기"
"논문 정리 도구"
한 줄로 안 적히면 너무 큼. 더 작게 쪼개기.
2. End-to-end 가장 작은 단위로 작동시키기
- input 1개 → output 1개. 다른 case 무시
- 24시간 안에 작동하는 무언가
3. AI에게 작은 단위로 시키기
- "이 함수만 짜줘"
- 결과 보고 OK인지만 판단
4. 작동 확인 + git commit
- 작동 → 다음 작은 task
- 안 작동 → 다른 시도 (revert, 재시도)
→ 이 4단계가 fundamentals 0개 적용해도 되는 minimum. 그러나 암묵적으로 tracer-bullets + ship-and-rollback-as-normal + strategic-vs-tactical-programming 적용 중.
🚦 언제 원칙으로 돌아가는가? — 3가지 신호
신호 없으면 원칙 적용 X. 원칙은 예방약이 아니라 치료약. 미리 다 먹으면 over-engineering.
신호 1 — "왜 자꾸 같은 단어를 길게 설명해?"
→ ubiquitous-language skill 만들 시간. AI에게 한 번에 vocabulary 정착시키면 다음 session부터 자동.
신호 2 — "이거 고치니까 저쪽이 깨졌어"
→ orthogonality 또는 information-hiding. 왜 두 곳이 묶였는가 분석. 격리 가능한가?
신호 3 — "AI가 이상한 길로 가서 garbage 만들었어"
→ tdd-as-small-deliberate-steps + tracer-bullets (작은 step). AI에게 test 보호 prompt 강제 박기.
추가 신호:
- "외부 시스템 바뀌어서 모든 게 깨졌어" → anti-corruption-layer
- "이 결정을 되돌릴 수 없어" → reversibility
- "누가 책임지나?" → named-ownership
💻 직접 코딩 vs AI 위임 — 영역별 가이드
| 직접 짜야 하는 자리 | AI 위임 OK |
|---|---|
| 디버깅 (AI 짠 거 이해 못하면 본인이 멈춤) | 보일러플레이트 |
| 핵심 알고리즘 (이해 못하면 검증 불가) | 친숙한 패턴 (N번 짜본 거) |
| 처음 1-2 프로젝트 (fundamentals 체험으로 흡수) | 1회용 / 실험 코드 |
| Edge case 짚기 (AI는 일반 case에 약함) | 복잡한 lib 사용법 |
| Runtime 직관 (코드가 어떻게 행동하는지) | 형식 변환·glue code |
핵심 rule — sources/key-articles-summary#4. Simon Willison|Willison golden rule의 학생 단위 변형:
내가 디버깅할 수 있을 정도로만 AI에게 위임.
만약 AI가 짠 코드의 디버깅이 안 되면 — 그 자리는 직접 짜야 했던 자리. 다음에는 그 영역 직접.
📖 학생의 진짜 자산은?
❌ 시간 지나면 잊힘 / AI도 다 앎 (가치 작음)
- Spring 어떤 annotation
- Rust borrow checker 규칙
- React hook 종류
- Python pandas API
✅ AI가 못 가짐 (학생의 진짜 자산)
- Trade-off를 보고 자기 도메인에 맞게 선택하는 감각
- 왜 이 결정인가 (adr-as-strategic-mechanism|ADR로 표현 가능)
- 이 시스템이 어디서 깨질지 예측 (leak 인지)
- 14 원칙 카탈로그에서 답 찾기
→ 14 원칙 학습 후 학생의 진짜 자산은 후자. AI가 못 가지는 영역.
⏰ 설계 시간 — 1주일은 우스움. 적정 시간
| 단위 | 시간 | 사례 |
|---|---|---|
| 새 feature 결정 | 15-30분 | "이 기능을 어떻게 추가할까" |
| ADR 1장 | 30분 ~ 2시간 | 큰 결정 (vendor 선택, BC 분리 등) |
| Tracer bullet 발사 전 design | 1-2시간 | 전체 architecture 첫 그림 |
| 새 프로젝트 strategic kickoff | 반나절 | 14 원칙 어떤 것 적용할지 |
| ❌ 1주일 설계 | (anti-pattern) | Big upfront design 함정 |
왜 1주일이 우스운가: 설계 → 구현 → 발견의 cycle을 위반. 도메인을 모르는 채로 설계하면 premature abstraction. 1주일 설계 후 구현하면 50%+가 잘못된 방향. 빠르게 tracer bullet으로 증거 쌓고 다시 설계가 답.
자연 cycle:
30분 strategic 사고 → 1-3일 tracer bullet 구현 → 발견 → 30분 ADR update → 다시 구현
strategic-vs-tactical-programming + tracer-bullets + reversibility가 모두 가리키는 답.
🚀 학생의 실용 시작 path
다음 프로젝트에 그대로 적용:
Day 0 (30분):
- "이거 해봐야겠다" 한 줄 적기
- ADR-001 — strategic kickoff
(왜 이걸 만드나, 사용자 누구, 성공 기준)
Day 1-7:
- Tracer bullet 발사 (vibe coding OK)
- 매 commit 시 1줄 description (mini ADR)
- 큰 결정마다 ADR 작성 (30분)
Week 2+:
- 불편함 발생 → 3가지 신호 매핑
- reading-guide의 Theme별 path → 답 찾기
- 같은 패턴 3번 반복 → 그때 strategic ADR
ADR 5장 쌓이면:
- 자기 판단 패턴 보이기 시작
- "내가 뭘 아느냐"의 답이 ADR 묶음 그 자체
🧘 마음 무게 측면
학생이 불안한 게 자연스러움. AI 시대 모두가 느낌. 정상.
해법: ADR 쓰는 습관 자체가 불안을 자산으로 변환:
- ADR 없으면 → "내가 뭘 아는지" 모름 → 불안
- ADR 있으면 → 내가 무엇을 아는지 가시화 → 자산
5번째 ADR쯤 판단 패턴 보임. 10번째쯤 자기 도메인의 strategic architect가 됨.
이게 named-ownership 인사이트 8 — *"AI 사용 자유와 결과 책임 의무는 분리되지 않는다"*의 학생 단위 mechanism. 책임을 가지면 내 것이 됨.
한 줄 요약
Tracer bullet으로 시작, vibe coding으로 작동, 불편함 발생 시 reading-guide Theme별 path에서 답 찾기. 14 원칙을 카탈로그로 두고 매 큰 결정 ADR로 남기기. 5장 쌓이면 내가 무엇을 아는가의 답이 명료.
관련
- overview — 14 원칙 지도
- reading-guide — Theme별 path 검색 자리
- synthesis-complex-to-simple — 14 원칙 통합 명제 (이 가이드의 theory)
- adr-as-strategic-mechanism — 내가 무엇을 아는가의 mechanism
- tracer-bullets — 시작 도구
- simple-not-easy — easy → simple path 정당화
- strategic-vs-tactical-programming — strategic 시간의 자리
Sources
이 가이드는 대화에서 발견된 통찰의 정리. 직접 source는 14 원칙 노트들 + 다음:
- Andrej Karpathy — vibe coding (entry point 정당화)
- Simon Willison — Not all AI-assisted programming is vibe coding (golden rule)
- research/stateless-llm-sdk/study-resources-fundamentals|study-resources-fundamentals — easy → simple 학습 path