개요
Rob Pike(Bell Labs, Plan 9, Go 언어 공동 창시자)가 1989년 제시한 프로그래밍의 5가지 기본 규칙. 36년이 지난 지금도 여전히 유효한 소프트웨어 공학의 핵심 원칙. 핵심 메시지: “측정 없이 최적화하지 마라, 단순함을 추구하라, 데이터가 알고리즘보다 중요하다.”
- 저자: Rob Pike
- 발표: 1989, Bell Labs
- 출처: cs.unc.edu
5가지 규칙 원문 + 해석
규칙 1: 어디가 느린지 예측하지 마라
“You can’t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you’ve proven that’s where the bottleneck is.”
프로그램이 어디서 시간을 소비할지 예측 불가능
↓
병목은 예상치 못한 곳에서 발생
↓
실제로 병목임이 입증되기 전까지
속도 개선 시도 금지
규칙 2: 측정이 먼저
“Measure. Don’t tune for speed until you’ve measured, and even then don’t unless one part of the code overwhelms the rest.”
속도 조정은 측정 후에만 수행
↓
코드의 한 부분이 전체를 압도할 때만 최적화 고려
↓
프로파일러로 실제 데이터 확인 → 그 다음 결정
규칙 3: 작은 n에서는 단순함이 답
“Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don’t get fancy. (Even if n does get big, use Rule 2 first.)”
복잡한 알고리듬 = 큰 상수 (constant factor)
↓
작은 n에서는 오히려 느림
↓
n이 자주 커지지 않는 한 단순한 방법 사용
↓
n이 커지더라도 먼저 규칙 2 적용 (측정)
규칙 4: 복잡한 알고리듬은 버그 천국
“Fancy algorithms are buggier than simple ones, and they’re much harder to implement. Use simple algorithms as well as simple data structures.”
복잡한 알고리듬:
✗ 버그 많음
✗ 구현 어려움
✗ 디버깅 어려움
✗ 유지보수 어려움
✗ 다른 사람이 이해 어려움
→ 단순한 알고리듬 + 단순한 데이터 구조
규칙 5: 데이터가 핵심 ⭐
“Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.”
올바른 데이터 구조 선택 + 잘 조직
↓
알고리듬이 거의 자명하게 드러남
↓
프로그래밍의 중심:
❌ 알고리듬
✅ 데이터 구조
한 줄 요약
| 규칙 | 핵심 |
|---|---|
| 1 | 추측으로 최적화하지 마라 |
| 2 | 측정 후 최적화하라 |
| 3 | 작은 n에는 단순한 방법 |
| 4 | 단순함이 안전함 |
| 5 | 데이터 구조가 알고리듬보다 중요 |
관련 철학 & 격언
Tony Hoare (1974)
“Premature optimization is the root of all evil” (조기 최적화는 만악의 근원)
→ Pike의 규칙 1, 2와 동일한 메시지
Ken Thompson 재해석
“When in doubt, use brute force” (의심스러울 때는 단순한 방법)
→ Pike의 규칙 3, 4 정신
KISS 원칙
Keep It Simple, Stupid
→ 규칙 3, 4의 일반화
Fred Brooks 『The Mythical Man-Month』
“Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.”
→ 규칙 5의 원조
일반 요약
“Write stupid code that uses smart objects” (똑똑한 객체를 사용하는 단순한 코드 작성)
2026년 관점에서의 재평가
여전히 유효
| 규칙 | 현재 상황 |
|---|---|
| 규칙 1, 2 | ✅ 절대 진리 — 프로파일러 없이 추측 → 자원 낭비 |
| 규칙 3 | ✅ 작은 n에서는 단순한 O(n²)가 O(n log n)보다 빠름 |
| 규칙 4 | ✅ 복잡 알고리즘 버그 + 유지보수 비용 여전히 큼 |
| 규칙 5 | ✅ 좋은 데이터 모델 = 좋은 시스템 (DB 설계, ML 데이터 큐레이션 등) |
시대 변화 반영
1989년: 단일 머신, 메모리 KB~MB, 알고리즘 미세 최적화 중요
2026년: 분산, GB~TB, 클라우드, AI
↓ 그래도 핵심은 같음
규칙 1·2: 분산 시스템에서 더 중요 (어디 병목? 네트워크? DB? CPU?)
규칙 3·4: 마이크로서비스 vs 모놀리식 논쟁의 핵심
규칙 5: AI 시대 = 데이터의 시대 (모델보다 데이터 큐레이션이 중요)
→ 관련: OmniCoder-9B (“학습 데이터 질이 모델 크기보다 중요”) → 관련: 코딩 에이전트 하니스 & Hashline (“하니스가 모델보다 중요”) → 관련: AI 시대 실행 비용 붕괴 (“실행은 쉬워졌지만 데이터·구조가 핵심”)
실전 적용 체크리스트
새 기능 만들 때
- 규칙 5: 데이터 구조부터 설계 (스키마, 모델, 관계)
- 규칙 4: 첫 구현은 가장 단순한 버전
- 규칙 3: n이 정말 큰가? 작으면 brute force OK
- 규칙 2: 동작 후 프로파일러로 측정
- 규칙 1: 측정 결과의 핫스팟만 최적화
코드 리뷰할 때
- 추측 기반 최적화 있나?
- 복잡한 알고리듬이 정말 필요한가?
- 데이터 구조가 적절한가?
- 단순한 대안이 있는가?
Rob Pike 본인의 원칙 적용 사례
Plan 9 OS:
- 단순한 인터페이스 (everything is a file)
- 분산 시스템도 같은 모델 사용
Go 언어:
- 단순함 우선 (제네릭은 한참 후 추가)
- 명시적 > 암시적
- "Less is exponentially more"
Unix 철학 계승:
- "Do one thing and do it well"
- 작은 도구 조합
안티패턴 (이 규칙들의 반대)
❌ "이 부분이 느릴 것 같아서 미리 최적화함"
→ 규칙 1, 2 위반
❌ "Red-black tree로 구현하면 더 빠를 것"
(실제로는 Vec/Array가 충분한데)
→ 규칙 3 위반
❌ "이 라이브러리가 더 멋있어 보여서 도입"
→ 규칙 4 위반 (복잡도 증가)
❌ "알고리즘부터 짜고 데이터는 나중에"
→ 규칙 5 위반
결론
36년이 지나도 변하지 않는 진리:
1. 측정하라 (Measure)
2. 단순하게 (Simple)
3. 데이터 우선 (Data First)
이 세 가지가 좋은 소프트웨어의 기반.