research

Strategic vs Tactical Programming — Matt thesis의 직접 root

Strategic vs Tactical Programming — Matt thesis의 직접 root

Ousterhout 책 3장의 핵심 명제. 매 코드 작업이 task 완료가 목표인가, 시스템 design 개선이 목표인가. Matt thesis가 이 명제를 사람-AI 분할로 확장한 자리. overview의 철학적 root 3개 중 하나. simple-not-easy의 strategic 사고가 무엇인지의 운영적 답.

한 줄

Tactical = 매 코드 작업의 목표가 동작하는 코드 만들기. Strategic = 매 코드 작업의 목표가 시스템 design을 좋게 만들기. 차이는 시간 지평 — tactical은 다음 commit, strategic은 다음 6개월. AI 시대에 가장 중요한 명제는: AI에게 tactical을 위임하면 사람의 시간 100%를 strategic에 쓸 수 있다. 이게 research/stateless-llm-sdk/software-fundamentals-thesis|Matt thesis가 산업 차원에서 의미 있는 이유.

⚛️ 철학

원칙의 왜. 더 깊은 root와의 연결.

Ousterhout의 책 A Philosophy of Software Design 3장의 첫 명제:

"The most important thing about programming is that you have to think strategically, not tactically."

두 mode의 정의:

mode매 코드 작업의 목표시간 지평결과
Tactical이 task가 동작하는가?다음 committask 완료 + complexity 작은 누적
Strategic이 task로 시스템 design이 어떻게 변하는가?다음 6개월task 완료 + design 개선

Ousterhout의 핵심 권장: 매 코드 작업의 10-20%를 strategic에 투자. 수치 자체는 mechanical하지 않다. 핵심은 strategic 시간을 의식적으로 만드는 것. 이 시간 동안:

  • 좋은 abstraction 찾기
  • 변수·함수 이름 다듬기
  • 작은 refactor
  • 인접 영역 정리
  • 왜 이 design인가를 commit 메시지나 ADR에 적기

이 명제가 root인 이유는 모든 다른 fundamentals의 적용 mechanism을 정의함:

→ Strategic은 fundamentals 적용의 시간 예산. 이 예산이 0이면 fundamentals는 책 속 이론에 머무름.

simple-not-easy와의 연결: Strategic 사고 = simple 만들기, Tactical 사고 = easy 선택 (대부분).

  • Tactical: 매 step에서 easy한 답(빠른 hack)을 선택 → complex 누적
  • Strategic: 매 step에서 simple로 끌어올리기(추가 작업 감수) → simple 유지

Matt thesis가 이 명제를 사람-AI 분할로 확장:

Ousterhout 1인 모델:
  사람 한 명이 tactical 80% + strategic 20%

Matt 사람-AI 모델:
  사람 = strategic 100%
  AI = tactical 100%

이게 research/stateless-llm-sdk/software-fundamentals-thesis|Matt thesis의 가장 단순한 표현. 복잡한 새 명제가 아니라 Ousterhout 명제의 자원 분할.

다른 root와의 연결:

  • Brooks의 No Silver Bullet — essential complexity 처리는 strategic 사고가 필요. AI는 essential을 못 처리. Brooks의 silver bullet 부정이 Matt thesis의 근거
  • DDD의 모델 발견 — strategic 활동의 도메인-측 표현. domain expert와 함께 모델을 발견하는 것은 본질적으로 strategic
  • Karpathy의 vibe coding 함정 = 전 영역을 tactical로. Strategic 부재 = design 부재

🧱 추상적 작동 구조

두 mode의 시간 흐름을 비교:

핵심 통찰: 두 모드의 초기 cost는 비슷하다. Strategic이 task당 추가 시간 10-20%. 그런데 누적되면 정반대 곡선:

Ousterhout의 강력한 metaphor — Tactical Tornado:

"A tactical tornado is a programmer who pumps out code furiously, but in a tactical fashion. The tornado moves through the codebase, plowing through everything in their path... You'll see this person's PRs, and they look great in the moment, but a year later, you'll find that the codebase is in shambles."

Tactical tornado는 시스템 전체를 망가뜨리는 속도가 strategic 사람들이 고치는 속도보다 빠름. 한 사람의 tactical 행동이 팀 전체의 strategic 노력을 무력화.

Matt thesis의 사람-AI 모델을 그림으로:

→ substrate가 만들어내는 가치는 strategic/tactical 분할의 enabler. v1.0의 정체성이 이 자리.

⚠️ 약점/한계

원칙의 적용 한계. 잘못 적용 시 함정.

1. 측정 어려움과 조직 압력

Strategic 활동의 ROI는 수개월~수년 후에 드러남. Tactical 활동은 즉시 ship 가능. 조직이 velocity만 측정하면 자연스럽게 tactical 강제됨. 매니저가 strategic 시간을 낭비로 봄.

해결: Strategic을 별 시간으로 분리하지 말고, 매 task 안에 통합. PR 하나에 기능 + 인접 정리. ADR을 commit과 함께. strategic을 invisible하게 만들면 조직 압력에서 자유.

2. Strategic의 Paralysis 함정

Strategic을 완벽한 design 추구로 오해하면 ship을 못함. Waterfall의 함정. Strategic은 완벽한 답을 찾는 게 아니라, 다음 6개월 후의 자신에게 친절한 답을 찾는 것.

해결: Strategic도 작은 step. 한 task당 strategic 활동도 5-10분 단위로 timeboxed. 여기서 끝 라인을 명시적으로.

3. AI 시대 specific — Tactical 감각 상실 위험

사람이 strategic만 하면 코드를 못 읽게 될 수 있음. AI가 짠 코드를 비판적으로 review하려면 tactical 감각이 필요. Willison의 golden rule과 정렬:

"I won't commit any code to my repository if I couldn't explain exactly what it does to somebody else."

해결: 사람도 tactical을 정기적으로 한다. AI 위임 비율을 80% 정도로 제한. 20%는 사람이 직접 코드 작성·디버깅. tactical 감각이 strategic 판단의 input.

4. Premature abstraction의 root

Strategic을 너무 일찍, 너무 많이 적용하면 premature abstraction. 도메인을 충분히 이해하기 전에 완벽한 추상화를 만들어 놓고, 도메인이 변할 때 그 추상화가 잘못된 방향임을 발견.

해결: Strategic은 증거가 쌓인 후에 적용. Rule of three (같은 패턴이 3번 반복되면 그때 추상화). tracer-bullets|tracer bullets로 빠르게 탐색하고, 패턴이 보이면 strategic으로 정착.

5. 도메인이 너무 안정적일 때 가치 작음

CRUD UI, glue code, 1회성 자동화에서는 strategic 투자의 ROI가 작음. 도메인 변화가 작으면 미래의 자신에게 친절할 필요 약함.

해결: 도메인 별로 strategic 비중을 다르게. 핵심 도메인(많이 변화) = strategic 30%, 주변 도메인(안정) = strategic 5%. 일률적 10-20% 적용 X.

6. Strategic도 가설 — 틀릴 수 있음

Strategic 결정도 틀린 design을 만들 수 있음. 미래 예측이 빗나감. 그러면 strategic 시간이 반대로 부채가 됨.

해결: reversibility와 함께 적용. Strategic 결정은 되돌릴 수 있는 형태로. ADR에 결정의 가정을 명시. 가정이 깨지면 ADR을 수정.

🔄 대안 흐름

이 원칙이 적용 안 되는 시나리오와 다른 답.

대안 1 — YAGNI (You Aren't Gonna Need It)

XP의 핵심 명제. 필요할 때까지 만들지 말기. Premature abstraction 회피, tactical 정당화.

→ Ousterhout와 부분 충돌. Ousterhout: 지금 strategic 시간 투자가 미래에 갚는다. YAGNI: 예측은 틀린다, 단순 유지가 답. 합의 지점: YAGNI는 기능 추가에 적용, strategic은 현재 코드 정리에 적용. 둘이 다른 영역.

대안 2 — Refactor as you go (별 시간 X)

Strategic을 별도 시간이 아닌 매 task 안에 통합. Boy Scout Rule (떠날 때 캠프장은 왔을 때보다 깨끗해야 한다).

→ 약점 1의 해결책 그 자체. Ousterhout 원칙의 덜 분리된 표현. 추천 패턴.

대안 3 — Spike and Stabilize

Tactical로 빠르게 탐색 (spike) → 작동 확인 → Strategic으로 재작성·안정화. Geoff Hardy의 패턴.

→ Ousterhout 원칙과 합칩 가능. 학습 단계는 tactical, 안정화는 strategic. AI 시대 적용: AI가 spike, 사람이 stabilize 결정.

대안 4 — Move Fast and Break Things (Facebook 초기)

Tactical 100%. Speed가 모든 것. 부서지는 것은 빠르게 고치면 됨.

→ 한 번 통했지만 결국 Move Fast With Stable Infra로 수정됨 (Facebook 자체). Tactical only는 결국 strategic 부족 비용을 지불.

대안 5 — Cost-of-Change Curve가 flat인 경우

XP의 명제: 좋은 도구·언어·문화로 변경 비용을 평탄하게 유지. 그러면 strategic의 가치 작음 (어차피 변경이 싸니).

→ 부분적으로 옳지만 cost-of-change 평탄화 자체가 strategic 활동. 다른 차원에서 strategic 필요.

💡 인사이트

AI 시대 왜 지금 부활하는가 + 학내 segment 의미.

1. AI 시대의 새 자원 분할 — 사람=strategic 100%

Ousterhout는 1인 모델에서 10-20% strategic 권장. 그러나 AI 시대에는 tactical을 AI에게 통째로 위임할 수 있다. 그러면 사람의 시간 100%를 strategic에 쓸 수 있음.

이게 research/stateless-llm-sdk/software-fundamentals-thesis|Matt thesis가 산업 차원에서 의미 있는 이유. 단순 효율 향상이 아니라 자원 분배의 근본 변화. 1990s에는 strategic 시간이 sacrifice였지만 2026에는 strategic이 사람의 자연 자리.

학내 segment에서: 학생도 tactical을 AI에게 빠르게 위임하고 strategic 사고에 시간 투자. 학습이 압축됨. 1990s 학생이 1년 걸려 배우던 design 감각을 6개월에 흡수 가능.

2. Tactical Tornado의 AI 시대 표현

Ousterhout의 tactical tornado metaphor를 AI에 적용하면 무서운 그림이 나옴:

AI agent 자체가 tactical tornado가 될 위험 빠르게 코드를 양산하지만 시스템 design을 고려 안 함. 시간당 100 PR, 그런데 1년 후 codebase가 shambles.

deep-modules#인사이트|deep-modules 인사이트의 shallow 양산 약점이 이 metaphor의 정확한 표현. AI는 기본적으로 tactical. Strategic 사람이 AI의 brake 역할을 안 하면 tornado 그 자체.

해결: 사람이 AI의 strategic 검토자. 매 step 사람이 design 영향 평가. AI에게 tactical만 허락.

3. 10-20% 수치의 AI 시대 재해석

Ousterhout의 10-20% 수치는 1인 모델 가정. AI 시대에 재해석:

Era사람의 시간 분배Strategic 비중
1990s (1인 모델)tactical 80% + strategic 20%20%
2026 (AI 위임)strategic 80% + tactical 20% (AI review)80%

→ Strategic 비중이 4배. 이게 v1.0이 사용자에게 약속하는 생산성의 본질. 더 빠른 코드가 아니라 더 많은 strategic 사고 시간.

4. v1.0 design 직접 적용

research/stateless-llm-sdk/design-principles|7 원칙의 원칙 2 (Strategic Substrate, Tactical Execution)는 이 명제의 직접 표현:

layerstrategic 표면 (사람)tactical 동작 (AI)
SKILL.mdfrontmatter (owner, success criteria, scope)skill body (실제 동작)
Provider traittrait 정의 (4 method)vendor 구현 (retry, cache)
Hooks어디 hook을 박을지 결정hook 실행
Agent loop시작/끝 조건turn, tool dispatch

→ 모든 layer가 strategic/tactical 분할 표면을 갖는 게 v1.0의 정체성.

5. 학내 segment의 학습 곡선 압축

학내 학생에게 fundamentals 학습은 오랜 시간이 걸렸음. 이유: tactical(돌아가는 코드)에 시간을 다 쓰느라 strategic 사고에 시간이 안 남음. AI 시대에는:

→ 학습 곡선이 1년 → 6개월로 압축. v1.0이 학내 segment에 가져다 주는 교육적 가치. 단순 도구가 아니라 학습 가속기.

6. Strategic 검증 도구 — Willison의 golden rule

Willison의 "explain to someone else" 명제가 strategic 검증의 가장 직관적 도구:

AI가 짠 코드를 다른 사람에게 설명할 수 있나? Yes → strategic 검증 통과 (사람이 design을 이해) No → tactical만 했음. AI 위임 너무 깊음

이 한 가지 질문이 사람-AI 분할의 건강 지표. v1.0에 이걸 명시적 ritual로 박을 수 있음 (e.g., commit hook이 "이 변경을 한 줄로 설명하시오" 강제).

7. Strategic 부재의 산업 데이터

research/stateless-llm-sdk/research-to-production-gap|research-to-production-gap의 88% pilot 실패는 조직 차원의 strategic 부재. AI 도입 = tactical 가속, 그러나 strategic 사고 부재 → tornado → shambles.

12% 성공 cohort의 공통: strategic 사고를 mechanism에 박음. named-ownership = strategic 책임자가 명시적. ship-and-rollback-as-normal = strategic 결정의 가역성.

→ Matt thesis가 산업 데이터로 검증된 사례. 12% 성공의 공통이 strategic vs tactical 분할.

8. 한국어 의미 — *전략(戰略)*과 전술(戰術)

한국어 한자어가 두 개념을 명료하게 분리:

  • 전략(戰略) = 전쟁의 큰 그림·계획·도리. 시간 지평 길고, 결과는 누적
  • 전술(戰術) = 전쟁의 기술·재주·즉각 동작. 시간 지평 짧고, 즉각 효과

simple-not-easy의 한국어 직관과 같은 패턴. Ousterhout의 명제가 영어로는 발견인 게, 한국어로는 언어가 이미 알려준 것. 학내 segment에서 가르칠 때:

"AI는 전술가, 당신은 전략가. v1.0은 그 분할을 가능하게 하는 substrate."

이 한 문장이 v1.0의 정체성을 한국어로 압축.

다음에 가야 할 자리

이 노트가 호출한 다른 원칙들 — 자연스러운 다음 노트:

  • information-hiding — strategic 결정을 module 안에 박는 mechanism (Parnas 1972)
  • reversibility — strategic 결정도 가설. 되돌릴 수 있는 형태 강제
  • named-ownership — strategic 책임자가 명시적. 12% 성공 cohort의 공통
  • deep-modules — strategic = interface 정의, tactical = implementation

관련

Sources

직접 source

  • A Philosophy of Software Design — John Ousterhout (2018, 2nd ed 2021). 책 3장 Working Code Isn't Enough — Strategic vs Tactical Programming
  • 책의 Tactical Tornado metaphor도 같은 챕터

Matt thesis 측 source

대안 흐름 source

  • Extreme Programming Explained — Kent Beck (XP YAGNI의 root)
  • Refactoring — Martin Fowler (Boy Scout Rule, refactor as you go)
  • Cost of Change Curve — Kent Beck XP의 핵심 명제

AI 시대 응용

← research 목록으로홈으로