최적화의 본질: 제거하라, 그리고 언제 추가할지 알아라
조직과 제품에서 불필요한 것을 찾아내는 질문, 요구사항 검증 방법론 5가지, 그리고 복잡성을 추가해야 하는 7가지 조건
최적화는 “더 잘하는 것”이 아니라 **“안 해도 되는 것을 찾아내는 것”**에서 시작한다. Elon Musk의 5-Step Engineering Process 첫 번째가 “Make the requirements less dumb”인 이유도 같다. 요구사항 자체가 불필요하면, 그걸 아무리 잘 구현해도 낭비다.
그런데 제거만이 답은 아니다. 제거의 반대편에는 “이건 반드시 있어야 한다”는 판단이 있다. 제거할 것과 추가할 것을 구분하는 기준이 없으면, 단순화는 방향을 잃는다.
이 글은 세 가지를 다룬다:
- 무엇을 제거해야 하는가 — 조직과 제품에 던져야 할 질문
- 요구사항이 진짜 필요한지 어떻게 검증하는가 — 실무 방법론과 체크리스트
- 언제 추가해야 하는가 — 제거의 반대 원칙
최적화의 제1원칙: 불필요한 것을 제거하라
최적화는 “더 잘하는 것”이 아니라 **“안 해도 되는 것을 찾아내는 것”**에서 시작한다. Elon Musk의 5-Step Engineering Process 첫 번째가 “Make the requirements less dumb”인 이유도 같다. 요구사항 자체가 불필요하면, 그걸 아무리 잘 구현해도 낭비다.
조직 최적화: 던져야 할 질문
1. 이 업무가 없어지면 매출이나 기술력에 영향이 있는가?
직접적 인과관계가 없으면 후보다. 보고를 위한 보고, 정렬을 위한 회의, 관성으로 유지되는 프로세스.
2. 동일한 정보가 두 번 이상 전달되는 지점이 있는가?
중복 커뮤니케이션은 조직 복잡도의 가장 흔한 증상이다. 파트너사 협업, 내부 핸드오프에서 특히.
3. 한 명이 빠지면 전체가 멈추는 구조인가?
Single point of failure는 리스크이자 병목이다. 6~15명 규모에서 이건 구조 설계의 문제지, 개인 역량의 문제가 아니다.
4. 비용 대비 활용률이 정당화되는가?
거점 4곳, 구독 서비스, 외부 도구 — 각각의 실사용률을 측정하고, 임계치 이하면 통합하거나 제거한다.
5. 이 프로세스에서 단계 하나를 제거할 수 있는가?
승인, 전달, 변환, 검수 — 단계가 존재하는 이유가 “원래 그랬으니까”라면 제거 대상이다.
제품 최적화: 던져야 할 질문
1. 이 기능을 제거하면 고객이 알아차리는가?
기능의 존재 자체가 아니라 고객의 작업 흐름에 미치는 영향으로 판단한다. 알아차리지 못하면 빼도 된다.
2. 고객이 가장 오래 머무는 단계는 어디인가?
시간이 오래 걸린다 = 마찰이 크다 = 불필요한 복잡성이 있다. 통신 프로토콜 설정, 파라미터 튜닝, 초기 연결 과정 등.
3. 부품(모듈) 하나를 빼도 시스템이 동작하는가?
SpaceX의 “delete the part” 원칙. 하드웨어 부품이든 소프트웨어 레이어든, 빼서 동작하면 원래 불필요했던 것이다. 나중에 필요하면 그때 다시 넣어도 된다.
4. 성능 병목의 실제 위치는 어디인가?
측정 없는 최적화는 추측이다. ADRC 알고리즘을 정교하게 만들어도 병목이 RS-485 통신 지연이면 효과가 없다. 프로파일링이 먼저, 최적화는 그 다음.
5. 경쟁사가 더 적은 복잡도로 같은 문제를 해결하고 있는가?
우리만 어렵게 하고 있다면, 그건 기술력이 아니라 설계 부채다.
수렴하는 원칙
위 질문들은 전부 하나로 수렴한다:
“이것이 없으면 안 되는가?”
조직에 던지면 운영 최적화, 제품에 던지면 엔지니어링 최적화, 비용에 던지면 재무 최적화가 된다. 대답이 “없어도 된다”면 제거하고, “필요하다”면 남기되 더 단순한 형태로 만든다.
최적화의 본질은 추가가 아니라 제거다. 더 이상 뺄 것이 없을 때 완성된다는 생텍쥐페리의 원칙이 엔지니어링에서도 그대로 적용된다. 복잡성은 기본값이고, 단순함은 의도적 설계의 결과다.
요구사항이 진짜 필요한지 검증하는 방법
“이것이 없으면 안 되는가?”라는 질문은 좋은 출발점이지만, 구체적으로 어떻게 검증하느냐가 빠져 있다. 다섯 가지 방법론이 이 gap을 채운다.
방법론 1: 소유권 추적 (Musk)
“It does not matter who gave them to you. It’s particularly dangerous if a smart person gave you the requirements because you might not question them enough.”
모든 요구사항에 부서가 아닌 사람 이름을 붙인다. “법무팀에서 요구했습니다”는 허용되지 않는다. 이름이 붙어야 그 사람에게 “왜?”를 물을 수 있다.
Musk는 5-Step Process에서 이 단계를 가장 먼저 배치했다. 순서가 중요하다 — 요구사항 검증 없이 최적화(3단계)나 자동화(5단계)를 하면 불필요한 것을 효율적으로 만드는 꼴이 된다.
| 순서 | 단계 | 핵심 |
|---|---|---|
| 1 | Make requirements less dumb | 요구사항 자체를 의심 |
| 2 | Delete the part/process | 삭제 편향 유지 (10% 복원이 목표) |
| 3 | Simplify/Optimize | 삭제 후에만 최적화 |
| 4 | Accelerate cycle time | 단순화 후에만 속도 향상 |
| 5 | Automate | 모든 정리 후에만 자동화 |
Tesla 프리몬트 공장에서 Musk 본인이 35단계를 12단계 전에 적용해 대규모 낭비가 발생했다고 직접 인정했다. 순서를 지키지 않으면 이 방법론은 오히려 해가 된다.
방법론 2: 근본 원인 추적 (5 Whys)
Sakichi Toyoda가 개발하고 Taiichi Ohno가 Toyota Production System에 통합했다. 표면적 요구 아래에 진짜 문제가 다를 수 있다는 전제에서 출발한다.
요구사항: "모바일 앱에 다크모드를 추가해달라"
Why 1: 왜 필요한가? → 밤에 눈이 피로하다
Why 2: 왜 눈이 피로한가? → 화면이 너무 밝다
Why 3: 왜 화면이 밝은가? → 기본 밝기가 고정되어 있다
Why 4: 왜 밝기가 고정인가? → 사용자가 조절하는 방법을 모른다
Why 5: 왜 모르는가? → 온보딩에서 설명이 없다
진짜 해결책: 온보딩 텍스트 수정 (2시간) ≠ 다크모드 개발 (2주)한계: Why 체인이 여러 갈래로 분기할 수 있다. 단일 선형 체인으로 따라가면 잘못된 루트를 선택할 수 있고, 숙련된 진행자 없이는 원하는 방향으로 유도하는 확증편향이 생긴다.
방법론 3: 고객 가치 역산 (Working Backwards)
코드를 한 줄도 쓰기 전에, 성공한 것처럼 가정하고 1페이지짜리 가상 보도자료를 먼저 작성한다. 2004년부터 Amazon의 모든 주요 프로젝트(AWS, Kindle, Prime Video)에 적용됐다.
핵심 질문:
- 이 기능의 런치 헤드라인을 한 문장으로 쓸 수 있는가?
- 고객이 이것 때문에 기존 행동을 바꾸겠는가?
- 이것 없이 고객이 현재 어떻게 문제를 해결하는가?
쓰지 못하면 요구사항이 덜 익은 것이다. 다만 매 스프린트에 적용하면 프로세스 과부하가 온다 — 분기 단위 큰 의사결정에 적합하다.
방법론 4: 전제 해체 (First Principles)
비유에 의한 추론(“다른 회사들도 이렇게 한다”)이 아니라, “이것이 왜 필요한가, 구성 요소는 무엇인가”를 묻는다.
3단계 프로세스:
- 가정 목록화: 현재 요구사항의 전제들을 전부 적는다
- 근본 사실로 분해: 각 전제가 실제 사실인가, 업계 관행을 따르는 것인가?
- 재구성: 기존 솔루션 없이 근본 사실만으로 요구사항을 다시 쌓는다
SpaceX 배터리 사례: 업계 기준 $600/kWh → 원자재로 분해 → 실제 $80/kWh 가능 → 요구사항(비용 기준) 자체가 잘못된 가정에 기반했다.
한계: 인지 부하가 높다. 매 요구사항에 적용하면 팀 피로도가 올라간다. 업계 관행을 그대로 따르는 것이 의심되는 경우에 선별 적용한다.
방법론 5: 현재 필요성 판단 (YAGNI)
Kent Beck의 Extreme Programming에서 유래. 핵심: 현재 필요하지 않은 기능을 “나중에 쓸 것 같아서” 지금 만들지 말라.
Martin Fowler가 정리한 투기적 기능의 4가지 비용:
| 비용 | 내용 |
|---|---|
| Build | 분석/코딩/테스트에 낭비된 직접 공수 |
| Delay | 실제 필요한 기능을 늦추는 기회비용 |
| Carry | 불필요한 코드가 다른 기능 개발을 느리게 함 |
| Repair | 6개월 후 방식이 달라졌을 때 발생하는 기술부채 |
Fowler 인용: 신중하게 분석한 기능들조차 1/3만이 실제로 의도한 지표를 개선한다.
질문 세 가지:
- “이것이 지금 사용자가 실제로 요청한 것인가?”
- “이것 없이 배포할 수 있는가?”
- “이것을 나중에 추가하는 비용이 지금 만드는 비용보다 실질적으로 더 큰가?”
YAGNI가 적용되지 않는 영역: 코드 가독성, 리팩토링, 테스트 코드, CI/CD 인프라. 이 영역은 나중에 추가하는 비용이 기하급수적으로 증가한다.
통합 체크리스트
5개 방법론을 하나의 흐름으로 통합하면, 신규 요구사항을 받았을 때 5분 안에 돌릴 수 있다.
- Gate 1 — 소유권 (Musk): 이 요구사항을 만든 사람 이름이 있는가? 직접 “왜?”를 물었는가?
- Gate 2 — 근본 원인 (5 Whys): Why를 3~5회 반복했을 때 처음과 다른 해결책이 나오는가?
- Gate 3 — 고객 가치 (Working Backwards): 런치 헤드라인을 한 문장으로 쓸 수 있는가?
- Gate 4 — 전제 검증 (First Principles): 업계 관행이 아닌 실제 사실에 기반하는가?
- Gate 5 — 현재 필요성 (YAGNI): 지금 이것 없이 배포할 수 있는가?
방법론 비교
| 방법론 | 최적 적용 시점 | 소요 시간 | 한계 |
|---|---|---|---|
| Musk Step 1-2 | 기능 설계 전 | 30분~1시간 | 권력 구조상 “왜?”를 묻기 어려운 조직에서 작동 불가 |
| 5 Whys | 특정 요구사항 심층 분석 | 15~30분 | Why 체인이 분기하면 잘못된 루트를 따라갈 수 있음 |
| Working Backwards | 분기 단위 큰 기능 결정 | 반나절~하루 | 매 스프린트에 적용하면 과부하 |
| First Principles | 업계 관행을 의심할 때 | 1~2시간 | 인지 부하 높음, 매번 적용하면 팀 피로 |
| YAGNI | 스프린트 단위 기능 선정 | 5분 | 인프라/테스트/리팩토링에는 적용 불가 |
일상에서는 YAGNI + Musk Step 1-2로 빠르게 걸러내고, 큰 의사결정에서 Working Backwards와 First Principles를 선별 적용하는 것이 현실적이다.
언제 추가해야 하는가
“이것이 없으면 안 되는가?”가 제거의 질문이라면, 추가의 질문은 이것이다:
“이 복잡성은 문제 자체에 내재된 것인가, 내가 만든 것인가?”
전자면 추가하라. 후자면 빼라.
Essential vs. Accidental Complexity
Fred Brooks (1986, “No Silver Bullet”)의 구분이 가장 근본적인 기준선이다:
- Essential Complexity (본질적 복잡성): 문제 도메인 자체에 내재. 제거하면 문제를 해결하지 못한다. 추가하거나 유지해야 한다.
- Accidental Complexity (우발적 복잡성): 구현 방법, 도구, 구조 선택으로 발생. 제거할 수 있고 제거해야 한다.
Brooks의 핵심 주장: 현대 엔지니어의 대부분의 시간은 이미 Essential Complexity를 다루는 데 쓰인다. 우발적 복잡성을 모두 제거해도 10배 생산성 향상은 불가능하다. 추가해야 할 복잡성과 제거해야 할 복잡성을 구분하는 것이 핵심이다.
추가를 정당화하는 7가지 조건
1. 없으면 핵심 목적 달성이 불가능할 때
“있으면 좋겠다”와 “없으면 안 된다”를 구분한다. 전자는 YAGNI다. 후자만 추가를 정당화한다.
2. 안전·규제·계약 의무일 때
ISO 10218, IEC 61508 같은 기준이 요구하는 복잡성은 협상 대상이 아니다. 안전 레이어를 “단순화”하겠다고 빼면 시장 진입 자체가 불가능하다.
3. 작동하는 단순 시스템이 이미 존재할 때 (Gall’s Law)
“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works.”
복잡성은 반드시 작동하는 단순 시스템 위에 추가해야 한다. 처음부터 복잡하게 설계하면 실패한다.
4. 단순화로 단일 실패 지점이 생길 때
중복 설계(redundancy)는 비효율처럼 보이지만, 이중화를 제거하면 시스템 신뢰성이 근본적으로 훼손된다. 로봇·항공 도메인에서 특히 그렇다.
5. 조율 비용이 실제 작업 비용을 초과할 때
Amazon의 Two-Pizza Rule이 이 원칙의 조직 버전이다. 팀원 간 커뮤니케이션 링크 = n(n-1)/2. 6명이면 15개, 12명이면 66개. 팀이 커지면 구조적 복잡성(팀 분리, API 경계)을 의도적으로 추가해야 한다.
조직 규모별 추가 임계점:
| 팀 규모 | 추가해야 할 구조 | 추가 안 할 경우 |
|---|---|---|
| ~20명 | 역할 명확화, 의사결정 프로세스 | 책임 모호, 병목 |
| ~30명 | HR/피플 기능 | 문화 이탈, 채용 실패 |
| ~50명 | 성과 관리 체계 | 고성과자 이탈 |
| 125~150명 | COO, 공식 조직 구조 | 실행력 붕괴 |
6. 학습·탐색 목적의 한시적 추가
SpaceX Raptor 1의 과잉 센서는 의도적이었다. 엔진 작동 원리를 이해하기 위한 “학습용 복잡성”이었고, 이해가 완료된 후 제거했다. 핵심은 제거 계획을 처음부터 명시하는 것이다.
7. 두 번째 사용 사례가 실제로 등장했을 때
Rule of Three: 같은 패턴이 두 번 반복되면 추상화를 검토한다. 한 번만 쓰이는 코드에 추상화를 추가하는 건 YAGNI다.
과도한 제거의 위험
“빼라”는 원칙을 맹목적으로 따르면 다른 종류의 문제가 생긴다.
비사용(non-use)과 불필요(unnecessary)는 다르다. Quora는 사용률이 낮다는 이유로 Direct Question 기능을 제거했지만, 핵심 사용자 세그먼트에게는 필요한 기능이었다. 사용 데이터만으로 제거를 결정하면 오류가 생긴다 — **“왜 안 쓰는가”**까지 확인해야 한다.
과도한 제거가 문제가 되는 4가지 패턴:
- 유일한 방어선 제거: 이중화는 비효율이 아니라 신뢰성이다
- 도메인 지식의 소실: 복잡한 비즈니스 규칙을 코드에서 빼면 지식 자체가 사라진다
- 진화 불가능한 단순함: 너무 단순하게 시작해서 확장이 구조적으로 불가능해지는 경우
- 사용 데이터만으로 판단: 비사용과 불필요를 혼동하는 오류
판단 비교표
| 상황 | 판단 | 근거 |
|---|---|---|
| ”있으면 좋겠다” 수준 | 제거 | YAGNI |
| 없으면 사용자가 목적 달성 불가 | 추가 | Essential Complexity |
| 성능 병목 — 측정 전 | 제거 | 측정 후 판단 |
| 성능 병목 — 측정 후 확인 | 추가 | 프로파일링 기반 |
| 규제·안전 요구사항 | 추가 | Non-negotiable |
| 조율 비용 > 실제 작업 비용 | 구조 추가 | 팀 분리, API 경계 |
| 단순화로 단일 실패 지점 발생 | 중복성 추가 | 안전 임계 시스템 |
| 학습·탐색 목적 | 한시적 추가 | 제거 계획 필수 |
| ”깔끔하게 만들고 싶다” | 제거 | Accidental Complexity |
| 두 번째 사용 사례 등장 | 추상화 추가 | Rule of Three |
결론: 최적화는 제거와 추가의 균형이다
최적화의 본질은 추가가 아니라 제거다. 더 이상 뺄 것이 없을 때 완성된다는 생텍쥐페리의 원칙이 엔지니어링에서도 그대로 적용된다. 복잡성은 기본값이고, 단순함은 의도적 설계의 결과다.
그러나 제거만으로는 부족하다. 핵심은 두 가지 질문을 동시에 들고 있는 것이다:
제거의 질문: “이것이 없으면 안 되는가?” 추가의 질문: “이 복잡성은 문제 자체에 내재된 것인가, 내가 만든 것인가?”
첫 번째 질문에 “없어도 된다”면 빼라. 두 번째 질문에 “문제에 내재된 것”이라면 추가하되, 반드시 작동하는 단순 시스템 위에 추가하라.
제거할 용기와 추가할 판단력. 이 둘을 함께 갖추는 것이 최적화다.
← All posts