요즘 컨설팅하면서, 컨설팅한 내용대로 개발하는 분들도 AI를 사용합니다. 그래서 개발자분들하고도 많은 이야기를 합니다. 그런 과정에서 기술적인 내용을 많이 공유하는 분들께서 공유해주신 내용을 읽었는데, 개발 현장에서는 두 가지 목소리가 공존합니다. 한쪽에서는 “AI 덕분에 이제 몇 시간 만에 프로토타입을 뚝딱 만들 수 있다, 더 빠르게 가야 한다”고 합니다. 다른 한쪽에서는 “기술 부채가 쌓이는 속도가 감당이 안 된다, 코드베이스가 아무도 이해 못 하는 AI 슬롭 덩어리가 되고 있다”고 걱정합니다.
누가 옳을까요? 흥미롭게도, 둘 다 옳습니다. 다만 서로 다른 이야기를 하고 있을 뿐입니다.
2026년 3월, 비슷한 시기에 두 편의 글이 발표됐습니다. 엔지니어링 매니저 James Stanier의 《Slow down to speed up》과 개발자 Mario Zechner의 《Thoughts on slowing the fuck down》입니다. 두 글은 관점이 꽤 다르지만 놀랍도록 같은 결론을 향해 수렴합니다. 이 글에서는 두 글의 핵심을 함께 정리하고, 실제 현장에서 어떻게 적용할 수 있을지 살펴보겠습니다.
AI는 빠른 뇌다 — 그리고 그게 문제다
노벨상을 수상한 심리학자 다니엘 카너먼은 그의 저서 《생각에 관한 생각 (Thinking, Fast and Slow)》에서 인간의 사고를 두 가지 모드로 나눴습니다.
- 시스템 1 (System 1): 빠르고, 자동적이며, 패턴을 즉각 인식합니다. “2+2는?” 같은 질문에 별 생각 없이 답이 튀어나오는 것이 이에 해당합니다.
- 시스템 2 (System 2): 느리고, 의도적이며, 분석적입니다. “이 전략이 과연 옳은가?”를 따져보는 것이 이에 해당합니다.
Stanier는 여기서 흥미로운 비유를 듭니다. AI 연구자 안드레이 카르파티(Andrej Karpathy)는 Dwarkesh Patel과의 대담에서 LLM을 “인간 텍스트의 통계적 증류물”로 묘사한 바 있습니다. 단어가 들어오면 패턴이 매칭되고, 단어가 나옵니다. 이것은 본질적으로 시스템 1 사고입니다.
“AI는 빠른 패턴 매칭에는 탁월합니다. 하지만 무엇을 만들지, 왜 중요한지, 올바른 문제를 풀고 있는지를 결정하는 작업은 여전히 인간의 판단을 필요로 합니다.”— James Stanier, Slow down to speed up
그리고 여기서 역설이 등장합니다. AI가 실행을 빠르고 저렴하게 만들수록, 실행에 앞서 내리는 결정들의 레버리지가 커집니다. 잘못된 요구사항, 오해된 문제, 결함 있는 설계 가정 — 이것들은 AI가 만드는 모든 것에 전파되는데, 이제는 훨씬 빠르게 전파됩니다. System 2를 제대로 실행하지 못하는 비용은, System 1이 강력해질수록 오히려 올라갑니다.
속도의 환상이란 무엇인가
Stanier는 재미있는 농담을 인용합니다. 학계에 떠도는 반어(irony)입니다.
“연구실에서 몇 주를 보내면 도서관에서 몇 시간을 아낄 수 있다.”
소프트웨어 버전도 있습니다. “몇 주간의 코딩은 몇 시간의 계획을 아껴준다.” — 역시나 반어입니다. 도서관에서 먼저 찾아봤어야 할 것을, 연구실에서 몇 주를 낭비한다는 이야기입니다. 계획보다 코딩을 먼저 시작해서 근본적으로 잘못된 방향을 뒤늦게 깨닫는 상황과 같습니다.
AI는 이 문제를 해결해주지 않습니다. 오히려 증폭시킵니다. AI는 잘못된 요구사항을 기반으로 수천 줄의 코드를 생성할 것이고, 잘못된 문제에 대한 우아한 해결책을 만들어줄 것입니다. 진행하고 있다는 착각을 주면서, 실제로는 더 깊은 구멍을 더 빠르게 파고 있는 것입니다. 이것이 Stanier가 말하는 “속도의 환상(The Illusion of Speed)”입니다.
현장에서는 무슨 일이 벌어지고 있나
Zechner는 이론보다 현실을 먼저 꺼냅니다. 그리고 그 현실은 꽤 불편합니다.
“소프트웨어가 점점 더 취약한 엉망이 되어가고 있다는 느낌이 듭니다. 98% 가동률이 예외가 아닌 표준이 되어가고 있으며, 대형 서비스에서도 그렇습니다.”— Mario Zechner, Thoughts on slowing the fuck down
그는 구체적인 사례들을 나열합니다. AWS 장애와 Amazon의 90일 코드 리셋, Satya Nadella가 언급한 Microsoft의 AI 작성 코드 비율 증가와 Windows 품질 하락, “코드의 100%를 AI가 작성한다”고 자랑하는 회사들에서 나오는 기가바이트 단위의 메모리 누수와 UI 버그들. 그리고 들려오는 이야기들 — 에이전트로 코딩하다가 스스로 만든 코드베이스에 갇혀버렸다는 개발팀들의 사례입니다.
Zechner가 진단하는 문제의 구조는 세 가지입니다.
① 실수의 복리 축적 (Compounding Booboos)
인간 개발자도 실수를 합니다. 그런데 인간은 결국 배웁니다 — 누군가 지적하거나, 스스로 고통을 느껴서입니다. 에이전트는 다릅니다. 같은 실수를 반복해도 학습하지 않습니다. 그리고 더 중요한 차이가 있습니다.
“인간은 병목입니다. 하루에 만들 수 있는 실수의 수가 제한되어 있습니다. 에이전트 군단에는 그 병목이 없습니다. 작고 무해해 보이는 실수들이 감당 불가능한 속도로 복리처럼 쌓입니다.”— Mario Zechner
루프에서 자신을 제거했기 때문에, 무해한 실수들이 코드베이스 괴물로 합쳐지고 있다는 사실을 전혀 모릅니다. 새 기능을 추가하려고 돌아섰을 때 비로소 알게 됩니다 — 그때는 이미 너무 늦었습니다.
② 복잡성의 상인 (Merchants of Complexity)
에이전트들은 서로의 실행 결과를 보지 못하고, 전체 코드베이스를 볼 수 없으며, 이전 결정을 모른 채 항상 로컬 관점에서 결정을 내립니다. 결과는 예측 가능합니다. 방대한 코드 중복, 추상화를 위한 추상화, 훈련 데이터에서 흡수한 카고 컬트식 “업계 모범 사례”의 혼합물입니다.
인간이 만드는 엔터프라이즈 코드베이스가 이 상태에 도달하는 데 수 년이 걸립니다. 에이전트와 2인 팀이면 몇 주 만에 같은 수준에 도달할 수 있습니다.
③ 에이전트 검색의 낮은 재현율 (Low Recall)
이제 에이전트에게 엉망이 된 코드를 고쳐달라고 하면 어떻게 될까요? 에이전트는 변경에 필요한 모든 코드를 찾지 못합니다. 코드베이스가 커질수록 재현율(recall)이 낮아집니다. 이것은 컨텍스트 윈도우 크기의 문제만이 아닙니다. 에이전트가 코드베이스를 인덱싱하고 검색하는 방식 자체의 구조적 한계입니다. 코드 스멜이 애초에 생기는 이유도 여기에 있습니다 — 에이전트는 기존 코드를 놓치고, 중복을 만들고, 불일치를 도입합니다.
두 관점은 어디서 같고 어디서 다른가
| 항목 | James Stanier | Mario Zechner |
|---|---|---|
| 관점 | 엔지니어링 매니저·조직 | 현장 개발자·개인 |
| 접근 방식 | 이론 프레임워크 (Kahneman) | 실증적 관찰, 사례 나열 |
| 주요 위험 | 잘못된 방향으로 빠르게 달리기 | 에이전트가 만드는 복잡성 복리 |
| 핵심 해법 | 느린 단계를 프로세스에 명시 | 아키텍처는 직접 작성 |
| AI 역할 | 실행 + 숙고 모두 활용 가능 | 보조 도구, 인간이 최종 게이트 |
| 공통 결론 | 에이전트에 대한 무비판적 위임이 문제의 핵심 | |
그러면 어떻게 해야 하나
두 저자가 제시하는 실천 방안을 통합해서 정리하면 다음과 같습니다.
① “느린 단계”를 명시적으로 설계하라
Basecamp의 방법론 Shape Up은 언덕 차트(Hill Chart) 개념을 씁니다. 언덕의 오르막은 불확실성이 높고 무엇을 만들지 발견하는 “알아가는 단계”이고, 내리막은 방향이 명확해진 후 실행하는 “달리는 단계”입니다. AI는 내리막을 극적으로 빠르게 만들어줍니다. 하지만 오르막을 건너뛰게 해주지는 않습니다.
Stanier는 코딩을 시작하기 전 다음 항목들을 먼저 정리하도록 권합니다.
- 우리가 실제로 풀고 있는 문제는 무엇인가?
- 완료의 기준(성공 기준)은 무엇인가?
- 범위 밖인 것은 무엇인가?
- 무엇이 잘못될 수 있는가? (사전 부검, Pre-mortem)
- 이 접근 방식을 실패하게 만들 요인은 무엇인가?
흥미로운 점은, 이 모든 과정에 AI를 활용할 수 있다는 것입니다 — 코드를 만들기 전에 요구사항을 검토하고 구멍을 찾는 역할로.
② 아키텍처는 직접 손으로 짜라
Zechner가 가장 강조하는 부분입니다. API 설계, 모듈 구조, 핵심 데이터 모델 — 시스템의 본질을 정의하는 것은 직접 작성해야 합니다. 자동완성 정도는 써도 좋습니다. 하지만 에이전트에게 설계를 위임해서는 안 됩니다.
“직접 쓰거나 단계별로 구축되는 것을 보는 단순한 행위가 마찰을 만들어냅니다. 그리고 그 마찰이 무엇을 만들고 싶은지, 시스템이 어떤 ‘느낌’인지를 더 잘 이해하게 합니다. 이것이 바로 당신의 경험과 취향이 들어오는 곳이며, 현재 SOTA 모델들이 아직 대체할 수 없는 영역입니다.”— Mario Zechner
③ 에이전트에게 맡길 좋은 작업의 기준을 세워라
Zechner는 에이전트에게 잘 맞는 작업의 특성을 구체적으로 제시합니다.
- 전체 시스템을 이해하지 않아도 범위를 한정할 수 있는 것
- 에이전트가 스스로 결과를 평가할 수 있는 것 (예: 벤치마크, 테스트 통과 여부)
- 미션 크리티컬하지 않은 것 — 내부 도구, 임시 스크립트, 데이터 가공
- 버려도 되는 프로토타입 — 가능성을 탐색하는 throwaway 코드
반대로, 아키텍처 결정이나 검토 가능한 양을 넘는 대량 코드 생성은 에이전트에게 맡겨서는 안 됩니다. 그리고 어떤 경우든 인간이 최종 품질 게이트가 되어야 합니다.
④ 버릴 프로토타입을 적극 활용하라
역설적으로, 빠른 프로토타입 제작은 “느리게 가는” 방법 중 하나입니다. 몇 시간 만에 무언가를 만들어 이해관계자에게 보여주고, 내 이해가 맞는지 검증한 뒤, 버립니다. 올바른 방향이 확실해졌을 때 본격적으로 만듭니다. Stanier가 표현한 “느림을 위한 속도(speed in service of slowness)”입니다.
⑤ 느린 단계를 가시화하라
AI 시대에 “왜 이렇게 오래 걸리냐”는 압박은 새로운 형태로 등장합니다 — “AI로 하면 되잖아.” Stanier는 이에 대응하는 방법을 제시합니다. 현재 어떤 단계에 있는지 명시적으로 소통하고, 느린 단계의 산출물(요구사항 문서, 설계 스케치, 사전 부검 결과)을 공유하고, 느린 단계에 시간 제한을 걸어 의도적으로 느린 것임을 드러내는 것입니다.
결국 이것은 판단력의 문제다
두 글을 관통하는 하나의 메시지가 있습니다. AI가 빨라질수록, 인간의 판단·설계·이해가 더 중요해진다는 것입니다. 속도는 방향이 맞을 때만 가치가 있습니다.
에이전트는 당신이 원하는 것을 만들어줍니다. 문제는 당신이 원하는 것을 당신이 제대로 알고 있냐는 것이고, 그 답은 아직 AI가 대신해 줄 수 없습니다.
“이 모든 것이 규율과 주도성을 요구합니다. 이 모든 것이 인간을 필요로 합니다.”— Mario Zechner
AI 도구를 잘 쓴다는 것은 AI를 많이 쓴다는 뜻이 아닙니다. 언제 쓰고 언제 멈춰서 직접 생각해야 하는지를 아는 것입니다. 가장 빠른 팀은, 적절한 순간에 가장 잘 멈추는 팀입니다. 그래서 그냥 단순하게 개발을 빨리 해줍니다 하는 그런 내용으로는 접근해서는 안되는 것이죠.
참고 출처
- James Stanier, 《Slow down to speed up》, The Engineering Manager, 2026년 3월
- Mario Zechner, 《Thoughts on slowing the fuck down》, mariozechner.at, 2026년 3월 25일
- Daniel Kahneman, 《Thinking, Fast and Slow》, Farrar, Straus and Giroux, 2011 — Wikipedia
- Andrej Karpathy, Dwarkesh Patel과의 대담 — LLM을 “인간 텍스트의 통계적 증류물”로 묘사
- Ryan Singer et al., 《Shape Up》, Basecamp — Hill Chart 방법론 참조
- James Stanier, 《Use it or lose it》 — “Thinking First” 프로토콜
- James Stanier, 《Invert, always invert》 — 사전 부검과 역방향 사고