# 속도를 늦춰야 빨라진다

> Clean Markdown view of GeekNews topic #27858. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=27858](https://news.hada.io/topic?id=27858)
- GeekNews Markdown: [https://news.hada.io/topic/27858.md](https://news.hada.io/topic/27858.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-03-26T09:21:01+09:00
- Updated: 2026-03-26T09:21:01+09:00
- Original source: [theengineeringmanager.substack.com](https://theengineeringmanager.substack.com/p/slow-down-to-speed-up)
- Points: 25
- Comments: 4

## Summary

AI가 실행 속도를 극단적으로 높이면서, 잘못된 요구사항이나 설계 가정을 **더 빠르게 확산시키는 문제**도 커지고 있습니다. Kahneman의 System 1/2 프레임워크를 빌려, 실행 전의 느린 사고 단계가 오히려 **가장 큰 레버리지 지점**이 된다고 주장합니다. 실용적인 부분은 AI를 코드 생성뿐 아니라 프리모텀·엣지 케이스 탐색·버릴 프로토타입 등 **숙고를 가속하는 도구**로 쓰라는 제안이고, **"AI 쓰면 되잖아?"** 라는 새로운 속도 압박에 대응하는 팀 커뮤니케이션 전략도 함께 다룹니다.

## Topic Body

- AI 시대에 가장 반직관적인 실천은 **언제 속도를 늦출지 아는 것**이며, 실행이 저렴해질수록 그 앞 단계의 의사결정이 더 중요해짐  
- Daniel Kahneman의 **System 1(빠른 패턴 매칭)과 System 2(느린 분석적 사고)** 프레임워크를 AI 시대 소프트웨어 개발에 적용  
- 잘못된 요구사항이나 설계 가정은 AI가 **더 빠르게 전파**하므로, 실행 전 느린 단계의 비용 대비 효과가 극대화됨  
- AI를 실행뿐 아니라 **사전 검토·프리모텀·엣지 케이스 탐색** 등 숙고 단계를 가속하는 데도 활용 가능  
- "AI 쓰면 되잖아?"라는 새로운 **속도 압박 문화**에 대응하려면, 느린 단계를 명시적으로 드러내고 타임박싱하는 전략이 필요  
  
---  
  
### 두 가지 사고 속도  
  
- Daniel Kahneman의 _Thinking, Fast and Slow_ 에서 제시한 두 가지 사고 모드를 AI 시대 개발에 대입  
  - **System 1**: 빠르고 자동적이며 패턴 매칭 기반의 사고  
  - **System 2**: 느리고 의도적이며 분석적인 사고  
- Andrej Karpathy는 Dwarkesh Patel과의 대화에서 LLM을 **유령이나 정령**에 비유, 인간 텍스트의 통계적 증류물로서 단어가 들어가면 패턴이 매칭되고 단어가 나오는 본질적으로 System 1적 존재  
- AI는 대규모 **빠른 패턴 매칭**에 탁월하지만, 무엇을 만들지, 왜 중요한지, 올바른 문제를 풀고 있는지 판단하는 작업은 여전히 **인간의 판단** 영역  
- 반직관적 핵심: AI가 느린 단계를 덜 중요하게 만든 것이 아니라 **더 중요하게** 만듦  
  - 실행이 저렴하고 빨라지면, 레버리지는 실행 이전의 **의사결정**으로 이동  
- 잘못된 요구사항, 오해된 문제, 결함 있는 설계 가정은 AI가 빌드하는 모든 것에 전파되며, 이제는 **더 빠르게 전파**됨  
  - System 1이 강력해질수록 **System 2를 잘못 수행하는 비용**이 증가  
  
### 속도의 환상  
  
- 학계의 오래된 농담: "도서관에서 몇 시간이면 될 일을 실험실에서 몇 주 걸림", 소프트웨어 버전: **"몇 주간의 코딩이 몇 시간의 기획을 절약해줌"**  
  - 실제로는 거꾸로인 것이 핵심 — 서둘러 시작하면 근본적 오류를 발견하고 고통스러운 재작업이 뒤따름  
- 소프트웨어 엔지니어링에서 실수는 가능한 한 **요구사항이나 설계 단계**에서 일찍 잡아야 한다는 명확한 직관 존재  
  - 박스 다이어그램은 쉽게 변경 가능, 오해된 요구사항은 더 어렵고, 근본적으로 결함 있는 배포 아키텍처는 **재작성** 수준  
- AI의 문제: **기술 부채를 그 어느 때보다 빠르게 생성** 가능  
  - 실행 이전의 결정이 결함이 있으면, AI는 그 결함을 **완전한 기능 코드처럼 보이는 형태**로 충실히 구현  
  - 오해된 요구사항 기반으로 수천 줄의 코드를 생성하고, 잘못된 문제에 대한 우아한 솔루션을 기꺼이 빌드  
- **속도의 환상**: 진전하고 있다고 느끼지만 실제로는 더 깊은 구멍을 파고 있는 상태  
- 속도를 포기하는 것이 아니라 **의도적으로 배치**하는 것이 답 — AI의 속도는 올바른 방향이 확인된 후에만 발휘해야 함  
  
### 느림이 효과를 발휘하는 순간  
  
- 의도적 느림이 효과를 발휘하는 지점은 크게 변하지 않음  
  - 요구사항은 문서상 단어일 때 변경 비용이 저렴하고, 실제 사용자에게 서비스하는 배포 코드일 때 비용이 비쌈  
  - 설계 결정은 다이어그램에서 수정이 쉽고 프로덕션 시스템에서는 어려움  
  - AI가 이 근본 물리학을 바꾼 것이 아니라, 올바르게 수행했을 때의 **레버리지를 증가**시킴  
- **Thinking First 프로토콜**: AI에 작업을 넘기기 전에 실제로 원하는 것을 명확히 하는 시간을 투자하는 것이 가장 저렴한 실수 포착 지점  
- AI는 실행 가속뿐 아니라 **숙고 자체를 가속**하는 데도 활용 가능한 흥미로운 역설  
  - **코딩 전 요구사항 명확화**: 10분간 해결할 문제, 성공 기준, 제약 조건을 적고, AI에게 작성한 내용을 검토시킨 후 생성  
  - **프리모텀(Pre-mortem) 실행**: 설계를 확정하기 전에 AI에게 "이 접근법에서 무엇이 잘못될 수 있는가?" 질문하여 미처 고려하지 못한 리스크 도출  
  - **문제 뒤집기(Invert)**: AI에게 "이 프로젝트를 실패하게 만드는 것은?" 질문하여 숨겨진 가정 노출  
  - **버릴 프로토타입 빌드**: AI로 몇 시간 만에 만들어 이해관계자에게 보여주고, 투자 전에 이해도 검증 — 느림을 위한 속도 투자  
  - **간이 내부 도구 빌드**: 실제 제품에 비용을 쓰기 전에 AI로 거친 버전을 먼저 만들어 실제로 필요한 것과 불필요한 것 파악  
  - **엣지 케이스 조기 도출**: 구현 시작 전에 AI에게 설계의 엣지 케이스와 실패 모드를 생성하게 하여 다이어그램 단계에서 처리  
  
### 새로운 문화적 역풍  
  
- "AI 쓰면 되잖아?"는 새로운 형태의 **속도 압박**이며, 생산성의 외양과 실제 처리량을 혼동하기 때문에 특히 위험  
  - AI가 몇 초 만에 코드를 생성할 수 있지만, 코드 생성과 **올바른 문제 해결**은 동일하지 않음  
- 대응 전략:  
  - **현재 어떤 단계에 있는지 명시적으로 공유**: 느린 단계에 있다면 요구사항 명확화, 엣지 케이스 사고, 올바른 문제 해결 확인 중이라고 설명  
  - **이해관계자 참여 유도**: 지금 이해관계자의 입력을 반영하는 비용은 저렴하고, 나중에는 비쌈  
  - **작업 과정 공유**: 요구사항 문서, 설계 스케치, 프리모텀 결과물 등 느린 단계의 **산출물을 가시화**하여 진행 중임을 증명  
  - **느린 단계에 타임박스 설정**: "코드 작성 전 2일간 요구사항 명확화"처럼 명확한 경계를 두어 의도적 느림이 **개방형이 아닌 계획적**으로 느껴지도록 함  
  - **학습 내용 공유**: 발견한 엣지 케이스, 잘못된 것으로 밝혀진 가정 등을 간략히 업데이트하여 느린 단계를 **가치의 가시적 흐름**으로 전환  
  - **퀵 윈 시연**: 버릴 프로토타입이나 목업을 일찍 만들어 빠르게 움직일 수 있음을 보여주고, 느리고 신중한 작업에 대한 **신뢰 확보**  
- Basecamp의 **Shape Up** 방법론의 힐 차트(Hill Chart) 개념과 유사  
  - 오르막: 불확실성이 높고 작업의 실체를 발견하는 **느린 단계**  
  - 내리막: 경로가 명확하고 실행만 하면 되는 **빠른 단계**  
- 지연의 변명이 아니라 **좋은 작업이 실제로 이루어지는 방식**에 대한 설명 — 장기적으로 가장 빨리 출시하는 팀은 종종 적절한 순간에 속도를 늦추는 팀  
  
### 실천 방법  
  
- 다음 AI 지원 작업 전에 시도할 것:  
  - 10분간 실제로 해결하려는 문제를 적고, 성공의 모습과 범위 밖의 것을 정의  
  - 빌드 시작 전에 AI에게 접근법에 대한 **프리모텀을 실행**시키기  
  - 작업이 상당한 규모라면 **버릴 프로토타입을 먼저 빌드**하여 방향 검증  
  
### 결론  
  
- 속도와 느림은 반대가 아니라 **서로 다른 단계를 위한 도구**  
- AI는 양쪽 모두에 효과적: 방향이 명확할 때의 **빠른 실행**, 불명확할 때의 **가속된 숙고**  
- 핵심 역량은 현재 어떤 단계에 있는지 파악하고 **적절한 템포를 적용**하는 것

## Comments



### Comment 53875

- Author: dankim0124
- Created: 2026-03-26T11:57:21+09:00
- Points: 1

천천히 빠르게 라는 말이 있지용

### Comment 53878

- Author: hungryman
- Created: 2026-03-26T12:21:04+09:00
- Points: 1
- Parent comment: 53875
- Depth: 1

대학원 시절에 교수님한테 자주 듣던 말인데,  
오랜만에 PTSD 오네요.

### Comment 53883

- Author: dankim0124
- Created: 2026-03-26T12:42:05+09:00
- Points: 1
- Parent comment: 53878
- Depth: 2

저는 군대에서 들었다에요

### Comment 53998

- Author: findnamo
- Created: 2026-03-27T21:20:38+09:00
- Points: 1
- Parent comment: 53883
- Depth: 3

저는 악보에서 읽었어요  
allegro non troppo (빠르지만 급하지 않게)