속도를 늦춰야 빨라진다

(theengineeringmanager.substack.com)

12P by GN⁺ 20시간전 | ★ favorite | 댓글 3개

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) 개념과 유사
- 오르막: 불확실성이 높고 작업의 실체를 발견하는 느린 단계
- 내리막: 경로가 명확하고 실행만 하면 되는 빠른 단계
지연의 변명이 아니라 좋은 작업이 실제로 이루어지는 방식에 대한 설명 — 장기적으로 가장 빨리 출시하는 팀은 종종 적절한 순간에 속도를 늦추는 팀