켄트 벡이 말하는 AI 시대 소프트웨어 엔지니어링의 본질

URL: https://www.youtube.com/watch?v=_0zB1Qj-xoE 날짜: 2026-10-03 채널: Tech Bridge 원문 제목: [한영자막] 켄트 벡이 밝히는 AI 시대의 소프트웨어 엔지니어링, 진짜 개발의 본질은 무엇일까요? 출연: Kent Beck, Gergely Orosz 원본 에피소드: How Kent Beck shapes the software engineering industry

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI가 코드를 빠르게 생산해도 소프트웨어 엔지니어링의 핵심인 이해·신뢰·소통·검증까지 자동화하지는 못한다.== 코딩은 도메인을 이해하고 프로그램을 믿을 수 있게 만드는 과정이며, 개발자는 코드 작성자가 아니라 문제를 함께 정의하고 선택지를 만들고 결과를 검증하는 사람이다.

• 켄트 벡은 “코드를 축적하는 속도가 신뢰를 축적하는 속도보다 빨라지고 있다”고 진단한다.
• Extreme Programming(XP), Test-Driven Development(TDD), SUnit/JUnit, 디자인 패턴은 모두 짧은 피드백과 사람 사이의 공동 이해를 축적하는 장치로 출발했다.
• AI 시대에는 정답 플레이북이 존재하지 않으므로 “아무도 모른다(Nobody knows)”를 출발점으로 값싸고 되돌릴 수 있는 실험을 반복해야 한다.

소프트웨어의 품질은 코드의 양이나 생성 속도만으로 결정되지 않는다. 요구사항을 함께 파고들고, 도메인을 이해하고, 올바른 결과를 테스트하고, 사용자와 동료가 같은 문제를 보고 있다는 신뢰를 만드는 과정이 품질의 토대다. AI는 이 과정의 일부를 가속하지만, 그 과정을 생략하면 보이는 부분만 구현한 뒤 보이지 않는 운영·규제·조직의 복잡성에 부딪힌다.

1. 코딩이 사라져도 소프트웨어 엔지니어링은 사라지지 않는다

1.1. 코드는 엔지니어링 활동의 일부이며 이해를 고정하는 수단이다

1. Dario Amodei의 주장에 대한 반박
   1. Anthropic의 Dario Amodei가 “코딩이 먼저 사라지고 그다음 소프트웨어 엔지니어링이 사라질 것”이라고 말하자, 켄트 벡은 그것이 소프트웨어 엔지니어링을 이해하지 못한 사람의 말이라고 답한다.
   2. 코딩은 눈에 잘 보이고 상당한 시간을 차지하지만, 실제 업무에는 자신감을 쌓고 사람들과 연결되고 도메인을 이해하는 활동이 함께 들어 있다.
2. 코딩이 제공하는 학습 루프
   1. 개발자는 도메인 개념을 어렵게 이해한 뒤 그것을 코드로 표현하고, 테스트로 이해가 맞았음을 확인하면서 프로그램을 신뢰하게 된다.
   2. 직접 프로그램을 만들수록 그 프로그램이 놓인 도메인을 더 깊이 이해한다. 코딩은 타이핑이 아니라 이해를 현실의 동작으로 굳히는 행위다.

1.2. 신뢰는 생성 속도를 따라가지 못하고 있다

1. 코드보다 느린 신뢰
   1. “우리는 신뢰를 축적하는 속도보다 빠르게 코드를 축적하고 있다”는 문장이 현재의 핵심 위험을 설명한다.
   2. 코드 생성기가 손가락 총을 쏘듯 “다 끝났습니다, 보스”라고 말해도, 무엇이 끝났는지, 어떤 가정이 들어갔는지, 어떤 실패가 남았는지는 자동으로 설명되지 않는다.
2. 사용자와의 대화가 만드는 신뢰
   1. 사용자가 “이 버튼이 이 일을 하게 해 달라”고 말할 때, 개발자가 “정말 해결하려는 문제는 무엇인가?”라고 되묻고 요구를 함께 다듬으면 인간적 신뢰가 쌓인다.
   2. 프롬프트 한 번으로 결과물을 받는 방식은 요구사항의 왕복, 공동 학습, 문제의 재정의를 건너뛰므로 이런 신뢰를 만들지 못한다.

1.3. 인간을 배우지 않아도 된다는 약속은 처음부터 잘못됐다

1. “컴퓨터만 이해하면 된다”는 우주의 농담
   1. 젊은 개발자들은 컴퓨터를 완전히 이해하면 성공할 수 있다는 약속을 받지만, 실제 영향력은 다른 사람과 소통하고 공감하고 설득하고 진정시키는 능력에 의해 제한된다.
   2. 켄트 벡은 컴퓨터를 잘 다루는 데만 집중한 결과, 사람을 이해해야 한다는 사실을 깨달았을 때 이미 10년 뒤처진 느낌을 받았다고 말한다.
2. 소프트 스킬은 타고난 성격이 아니라 훈련 가능한 기술이다
   1. 감정 조절, 공감, 몸짓과 말투 읽기는 자연스럽지 않을 수 있지만 학습할 수 있다.
   2. “그냥 질문했을 뿐” 또는 “사실을 말했을 뿐”이라는 태도는 상대를 공격하는 방식이 될 수 있다. 상대의 요구를 이해하기 위한 체크리스트와 비유를 의도적으로 사용하면 대화를 계속할 수 있다.

2. 창조적 충동과 작은 언어가 만든 개발 철학

2.1. 계산기에서 프로그래밍으로: 머릿속 아이디어를 세계에 구현하기

1. 초기 하드웨어 경험
   1. 켄트 벡의 아버지는 한국전쟁 당시 무전병으로 복무한 전기공학자였고, 가족은 실리콘 밸리가 되기 전의 서니베일에서 살았다.
   2. 아버지가 집에 가져온 약 65~70파운드짜리 프로그래머블 계산기에는 7세그먼트 LED 이전의 닉시관이 달려 있었다. 켄트는 숫자가 올라갔다 내려오는 루프를 만들어 몇 시간씩 바라봤다.
2. 기계의 구조를 알아가며 창조하는 즐거움
   1. 버로스 B5500 계열의 스택 기반 명령어 매뉴얼을 반복해서 읽었지만 처음에는 거의 이해하지 못했다. 그래도 기계가 작동하는 방식 자체가 매력적이었다.
   2. HP-35를 400달러에 사던 시절의 역순 폴란드 표기법 계산기, HP-45의 작은 프로그래밍 언어, Z80·800·6800 마이크로프로세서를 거쳐 아버지와 함께 6800 기반 기계를 납땜했다.
   3. BASIC이 등장하면서 머릿속의 아이디어를 프로그램으로 만들고 실제 세계에 결과를 남기는 순환이 강해졌다. 켄트 벡에게 프로그래밍은 상상·실행·현실의 결과를 잇는 창조적 충동이다.

2.2. 대학과 첫 직장: CS와 음악 사이를 오가며 완성의 의미를 배우다

1. 오리건대학교에서의 우회
   1. 다른 대학에 모두 불합격해 오리건대학교에 진학했고 첫해에는 컴퓨터과학을 공부했지만 수업을 쉽게 통과해 다소 지루함을 느꼈다.
   2. 기타를 여덟 살부터 연주했던 경험 때문에 음악 건물에서 오디션 전단을 보고 음악 전공으로 옮겼다. 손가락이 아플 때까지 반복 연습해 남들이 전날 수준에 머물 때 새로운 피킹과 스트러밍 패턴을 익히는 방식은 프로그래밍 학습 방식과 닮아 있었다.
   3. 음악과 프로그래밍을 번갈아 선택한 끝에 학부와 석사 과정을 마쳤고, 석사 논문은 새로운 질의 언어였다. 권위자와 형식적인 절차에 부딪혔지만 끝까지 마무리하는 일 자체가 중요하다는 것을 배웠다.
2. “나무를 흔드는 사람”
   1. 켄트 벡은 제시 잭슨의 표현을 빌려 자신을 “젤리를 만드는 사람이 아니라 나무를 흔드는 사람(tree shaker, not a jelly maker)”이라고 부른다.
   2. 새로운 아이디어를 시작하고 일정 수준까지 밀어붙이는 데 강하지만, 한 주제에 영원히 머무르지는 않는다. 다만 프로그램과 프로젝트를 세계에 내놓으려면 어느 순간에는 마무리가 필요하다.
3. Tektronix와 Smalltalk
   1. 대학원생 시절 Tektronix 연구팀의 프로그래밍 환경 발표에서 질문을 던졌다가 저녁 식사와 면접을 거쳐 입사했다.
   2. Smalltalk는 단순한 언어와 새로운 상호작용 환경을 함께 제공했다. 핵심 프리미티브는 메시지 전송, 변수 할당, 값 반환 세 가지뿐이었고, 숫자도 객체이며 덧셈조차 정수 객체에 + 메시지를 보내는 방식이었다.
   3. if-then-else 같은 제어구조조차 언어의 특수 기능이 아니라 라이브러리로 표현했다. true와 false에 ifTrue: 메시지를 보내 클로저를 실행하거나 무시하는 방식은 소수의 일관된 규칙으로 많은 추상화를 만드는 철학이었다.

2.3. Smalltalk의 확장성과 한계

1. 개인의 창조성을 증폭한 환경
   1. 겹치는 창, 마우스, 창 안의 패널과 스크롤바 같은 GUI 요소를 개척했고, 코드를 편집한 뒤 컴파일·링크 없이 즉시 실행하며 중단점과 디버거에서 고쳐 계속할 수 있었다.
   2. 모든 것을 보고 바꿀 수 있는 개인용 컴퓨터의 소유감은 새로운 아이디어를 현실에 만들게 했다. 그러나 100명이 한 프로그램의 모든 부분을 동시에 호환되지 않게 바꾸면 협업에는 제동 장치가 필요했다.
2. “누구나 만들 수 있다”는 반복되는 기대
   1. 객체지향이 등장하자 적은 프로그래머로 더 많은 일을 하고 일반인도 프로그램을 만들 수 있다는 기대가 커졌다.
   2. Tektronix 워크스테이션을 사용한 화학·구조·유체 엔지니어들은 겉보기에는 훌륭한 시스템을 만들었지만, 내부 코드는 유지보수하기 어려운 엉망인 경우가 많았다.
   3. 그래도 천 페이지짜리 요구사항 문서를 쓰고 8년을 기다린 뒤 원하는 것을 얻지 못하는 것보다, 현업 전문가가 직접 도구를 만들 수 있게 된 것은 큰 진전이었다. 현재의 AI·바이브 코딩도 같은 확장 효과와 같은 유지보수 문제를 동시에 보여준다.
3. Smalltalk가 주류가 되지 못한 이유
   1. Smalltalk의 키워드·중위 표기법은 낯설었고, C++의 “C with objects” 문법은 설계 철학은 달라도 기존 개발자에게 익숙했다.
   2. Smalltalk의 작은 메모리 공간과 상호작용성은 강력했지만, Apple 고객이 필요로 한 것은 C와 Pascal 컴파일러였다. Park Place 같은 회사가 Smalltalk 구현을 고가 개발 도구로 팔았으나 시장의 주류 요구와 맞지 않았다.

3. Ward Cunningham과 함께 만든 공동 설계

3.1. 키보드를 주고받으며 여러 수준의 설계를 오가다

1. HotDraw와 Prolog 실험
   1. 켄트 벡은 Smalltalk 교육을 준비하며 Prolog 가상 머신을 세 개 만들고 통합·추론 과정을 보여주는 애니메이션도 제작했다.
   2. Ward Cunningham이 만든 예제 코드 plumbing을 함께 살펴보면서 개선점을 제안했고, 두 사람은 고해상도 화면·동적 언어·자체 구현 환경에서 무엇이 가능한지 탐험하기 시작했다.
2. 공동 프로그래밍의 리듬
   1. 처음에는 Ward가 키보드를 잡고 켄트는 괄호와 마침표를 확인했다. 시간이 지나며 켄트가 저수준 패턴을 익히고 더 높은 수준의 제안을 하면 키보드를 넘겨받는 방식으로 역량이 상호 증폭됐다.
   2. 두 사람은 “이 코드가 왜 안 되나”에서 “애초에 이 문제를 풀어야 하나”, “어떤 도구가 있어야 쉽게 풀리나”, “설계가 철학적으로 타당한가”까지 대화를 오갔다.
   3. 월요일에는 커피를 마시며 실험 목록을 고르고, 화요일과 수요일에는 구현하고, 목요일에는 데모와 다듬기를 하고, 금요일에는 기술 보고서를 작성했다. 실패한 주에도 무엇이 부족했는지 알아내 다음 월요일의 실험 목록에 넣었다.

3.2. 이름과 시각화도 설계의 일부다

1. HotDraw의 의미 있는 도형
   1. 1980년대 후반의 그래픽 성능으로 겹친 사각형을 10Hz 정도로 부드럽게 움직이는 데 성공했고, 그 흥분에서 HotDraw라는 이름이 나왔다.
   2. 도형은 단순한 사각형이 아니라 프로세서·생성기·온도나 압력을 조절하는 도메인 요소를 나타냈다. 핸들은 그래픽을 움직이는 동시에 그 도메인 상태를 조작했고, 연결선은 의미 있는 관계를 표현했다.
2. 정확한 이름을 찾는 공동 작업
   1. 켄트가 drawing object, drawing handle이라고 부른 요소를 Ward는 figure, handle, drawing으로 다듬었다.
   2. 두 사람은 실제 종이 시소러스를 책상에 두고 더 정확한 단어를 찾았다. 코드의 목적은 다른 사람과 이제는 모델에게 의도를 전달하는 것이므로, 어휘와 명명은 장식이 아니라 프로그램의 이해 가능성을 결정하는 설계 행위다.

3.3. 디자인 패턴은 사람에게 선택권을 주는 제약이다

1. Christopher Alexander의 영향
   1. Christopher Alexander는 건축가가 사용자의 완성된 공간을 대신 상상하기보다, 사용자가 제약 안에서 스스로 중요한 결정을 내릴 때 건물에 생명력이 생긴다고 보았다.
   2. 소프트웨어 디자인 패턴은 모든 결정을 대신 내리는 청사진이 아니라, 이전 결정이 만든 제약 안에서 다음 결정을 돕는 반복 가능한 언어다.
2. 테스트 엔지니어가 소유한 인터페이스
   1. Tektronix의 테스트 엔지니어용 프로젝트가 실패하자 Ward는 새 패턴 세트를 만들었다. 각 작업을 창으로 나누되 구현 가능한 목록·텍스트·파형 같은 표현만 허용했다.
   2. 테스트 엔지니어가 자신의 작업 흐름을 직접 구성했기 때문에 결과물을 소유했고, Smalltalk 개발자는 그 설계를 실제로 구현했다. 문제 한가운데서 오랫동안 사용할 사람의 맥락을 모르는 외부 설계자가 완성품을 던지는 방식보다 훨씬 현실적이었다.
   3. 팀에 잠깐 나타나 소란을 일으키고 떠나는 “갈매기(seagull) 아키텍트”는 결과에 대한 이해관계가 없기 때문에 다른 결정을 한다. 좋은 설계에는 skin in the game이 필요하다.

4. Apple, CRC 카드, 객체 설계와 테스트의 탄생

4.1. Apple에서 배운 협업의 대가

1. Smalltalk 프로젝트의 시장 부적합
   1. 1987년 Apple은 Xerox의 Smalltalk를 받아 Macintosh용 환경으로 발전시키려 했다. 켄트 벡은 Tektronix에서 성장한 자신이 조직의 인식보다 빠르게 커졌다고 느껴 Apple로 옮겼다.
   2. 그러나 Apple의 개발 생태계는 C와 Pascal 컴파일러가 중심이었고 Smalltalk는 학교나 일부 개발자 외에는 판매를 견인하지 못했다.
2. Alan Kay의 Playground와 해고
   1. Alan Kay가 아이들을 위한 반응형 언어 Playground를 만들고 있었고, Xerox 출신의 Larry Tesler와 Dan Ingalls도 Apple에 있었다. 켄트는 Smalltalk 개발 역사를 읽으며 그런 환경을 동경해 Playground에 합류했다.
   2. 당시의 “펑크” 태도 때문에 다른 사람의 제안을 듣고도 자기 아이디어를 밀어붙였고, 1989년 OOPSLA 프로그램 위원장 업무에 몰두해 Playground 일을 한 달간 방치했다. 결국 팀 플레이어가 되지 못해 해고됐다.
   3. Playground는 오늘날의 반응형·Pub/Sub에 가까웠다. 객체에 메시지를 보내기보다 조건을 발생시키고 다른 객체가 기다리게 하는 제어 방식이었다.

4.2. CRC 카드: 데이터가 있는 곳으로 계산을 옮겨라

1. 객체 프로그램을 손으로 느끼기
   1. 명령형 프로그램은 흐름도를 그리면 실행 순서를 볼 수 있지만, 다형적 메시지를 보내는 객체 프로그램은 실제 어떤 코드가 호출될지 즉시 알기 어렵다.
   2. Ward는 클래스·책임·협력자(Class-Responsibility-Collaborator)를 인덱스 카드에 적어 객체가 무엇을 맡고 어떤 객체와 대화하는지 손으로 배치하게 했다.
2. 책임 배분의 핵심 규칙
   1. 객체지향 설계의 중요한 결정은 데이터를 가진 곳 가까이에 계산을 두어 결합도를 낮추는 것이다.
   2. 사각형의 면적 계산을 코드 곳곳에 height * width로 흩어놓지 말고 Rectangle의 area 책임으로 둔다. 내부 표현이 두 모서리든 왼쪽 위·높이·너비든 외부는 area만 호출하면 되므로 표현을 바꿀 수 있다.

4.3. SUnit과 JUnit: 불안을 자동화된 신뢰로 바꾸다

1. 테스트에 대한 사회적 장벽
   1. 당시에는 컴퓨터과학 성적이 높은 사람은 프로그래머가 되고 낮은 사람은 테스터가 된다는 계층 의식이 있었다. 테스트는 별도의 언어와 도구를 가진 적대적 감독 활동으로 취급됐다.
   2. 켄트 벡은 복잡한 코드를 만들수록 가능한 버그를 더 많이 상상해 불안해지는 성향이 있었고, 약 대신 자동화된 테스트로 불안을 가라앉히고 싶었다.
2. SUnit의 구조
   1. 여러 실험에서 테스트 케이스·테스트 스위트·테스트 결과라는 세 개의 클래스와 약 12개 메서드를 합쳐 격리된 테스트를 자동 실행하고 결과를 집계하는 Smalltalk 프레임워크를 만들었다.
   2. 테스트 도구도 같은 언어로 작성하면 테스트가 별도의 세계가 되지 않는다. setUp, 테스트 메서드, tearDown을 통해 코드와 같은 표현 체계 안에서 검증할 수 있다.
3. MassPar에서의 고성능 실험
   1. MassPar는 최대 16,000개의 처리 요소가 토러스 격자로 연결된 SIMD 아키텍처를 만들었고, 당시 Cray 성능을 10분의 1 가격으로 제공하려 했다.
   2. Smalltalk로 개발 환경을 만들고 Fortran 프로그램을 한 줄씩 실행하면서 16,000 프로세서의 성능 프로파일을 수집할 수 있었다. 지금의 Nvidia식 병렬 구조와 닮았지만 시대가 너무 빨랐다.
   3. SUnit의 아이디어는 JUnit, NUnit, xUnit 계열로 확산됐다. 테스트 대상과 같은 언어를 사용하면 프로그래머와 테스터 사이의 장벽이 줄고, 도구를 코드의 일부로 발전시킬 수 있다는 발상이 핵심이었다.

5. C3와 Extreme Programming: 불확실성 속에서 짧게 배우기

5.1. Chrysler 프로젝트와 방법론의 재시작

1. 객체지향 개발의 방법론 문제
   1. 기존 구조적 분석·설계 방법은 객체가 제공하는 변경 가능성을 충분히 반영하지 못했다. 여러 개발자와 방법론이 객체 개발의 답을 찾으려 했고, Martin Fowler는 분석 패턴을 연구했다.
   2. 1996년 무렵 Chrysler의 C3 급여 시스템은 Y2K를 앞두고 제때 완성될지 불확실했다. 켄트 벡은 Smalltalk 성능 컨설턴트로 들어갔지만, 올바른 결과를 보장하는 테스트가 없으면 빠르게 만들 수 없다고 지적했다.
2. 코드를 버리고 세 주마다 재시작하다
   1. 한 주 동안의 큰 변경 뒤 팀을 2주 쉬게 하고 지금까지 작성한 코드를 버렸다. 이후 급여 전문가 Marie가 테스트 케이스를 지정하면 세 주 단위로 구현·통합·배포·리팩터링을 반복했다.
   2. Ward에게 배운 페어 프로그래밍, SUnit에서 얻은 같은 언어의 테스트, 점진적 설계, 고객과의 피드백을 모두 극단까지 밀어붙였다. 켄트 벡은 이를 “알고 있는 것만 남기고 증명할 수 없는 것은 버리는” 가치 체계로 설명한다.

5.2. Extreme Programming이라는 이름과 코딩의 위상

1. 이름을 훔치기 어렵게 만들다
   1. 새 방식이 커질 것 같자 다른 사람이 이름과 방법을 가져갈까 걱정했고, 일부러 매력적이지 않은 이름을 고르려 했다. 극한 스포츠처럼 충분한 준비와 훈련이 있어야 불가능해 보이는 일을 할 수 있다는 뜻을 담아 Extreme Programming이라 불렀다.
   2. XP는 extreme와 programming이라는 단어의 부작용을 피하기 위한 약칭이 됐다. Microsoft Windows XP가 출시되면서 상표 소송을 했다면 성공해도, 실패하면 가족을 파산시킬 수도 있는 우스운 대체 우주가 생겼다.
2. 프로그래밍은 서류 작업이 아니라 현실 검증이다
   1. 당시 방법론은 다이어그램을 만들고 문서를 쌓은 뒤 마지막에 프로그래밍을 하는 사무 업무처럼 코딩을 취급했다.
   2. 켄트 벡은 키보드 앞에서 프로그램을 작성할 때 실제로 이해하는지 더는 속일 수 없다고 봤다. 올바른 값을 계산하거나 계산하지 못하는 “현실과 프로그램이 만나는 순간”을 개발의 중심에 놓았다.
3. 닷컴 붐에 맞은 이유
   1. 인터넷이 폭발하는 동안 순차적인 분석·설계·코딩·테스트 방법은 변화 속도를 감당하지 못했고, 반대로 피자만 문 아래로 밀어 넣는 카우보이 코딩도 안정성을 만들지 못했다.
   2. XP는 반복·투명성·테스트·빈번한 정렬·프로세스 조정으로 빠르면서도 안정적인 중간 지대를 제공했다. 사업 담당자와 기술자, 기술자끼리 자주 맞추면서 변화에 대응할 수 있었다.

5.3. TDD: 테스트를 먼저 쓰면 불안이 사라진다

1. 테이프 기반 급여 처리에서 얻은 단서
   1. 어린 시절 읽은 책에는 입력 테이프를 실제로 준비하고 프로그램을 작성하기 전에 예상 출력 테이프를 손으로 입력하라는 지침이 있었다.
   2. SUnit을 만들고 한참 뒤 그 기억을 떠올린 켄트 벡은 입력에 대응하는 기대 출력을 먼저 쓴다는 패턴을 테스트에 적용했다.
2. 스택 예제의 Red-Green-Refactor
   1. Stack new에 값을 넣고 꺼내 같은 값이 나오는 테스트부터 작성했다. 클래스와 메서드가 없으므로 처음에는 여러 방식으로 실패한다.
   2. 하나씩 테스트를 추가해 두 값을 역순으로 돌려주는지, 중복 제거와 pop, top, 빈 상태가 맞는지 확인했다. 마지막 테스트가 통과하자 “어떤 테스트도 통과하지 않을 것이라는 불안”이 사라지고 실제로 끝났다는 감각을 얻었다.
3. TDD는 도덕률이 아니라 작업 방식이다
   1. TDD가 유행한 뒤 사용하지 않는 사람을 비전문가라고 몰아붙이는 도덕적 곤봉으로 변질된 것이 쇠퇴의 한 원인이었다. 좋은 소프트웨어는 여러 워크플로로 만들 수 있다.
   2. TDD의 강점은 발견과 실현을 빠르게 번갈아 하는 데 있다. 대략적인 목적은 알지만 다음 단계만 확실할 때, 한 걸음 구현하고 배운 뒤 다음 걸음을 정하는 방식이 특히 강력하다.
   3. AI 에이전트는 잘못된 코드를 빠르게 만들 수 있으므로 테스트가 단기적으로 토큰을 더 쓰게 해도 장기적으로 실패 비용을 줄인다. 다만 AI 시대에 TDD를 정확히 어떻게 적용할지는 아직 아무도 모른다.

6. Agile Manifesto의 탄생과 방법론의 상업화

6.1. Snowbird에서의 혼란과 “daily”

1. RUP와 폭포수식 사용에 대한 반발
   1. Rational Unified Process 자체보다 사람들이 그것을 분석·설계·구현·분리 테스트의 폭포수식으로 사용한 결과가 문제였다. 소규모 반복과 선택지 보존을 주장하던 Scrum, Feature-Driven Development 등 여러 흐름이 비슷한 방향으로 움직였다.
   2. 노르웨이에서 모임을 가진 뒤 Jim Highsmith와 Alistair Cockburn이 Snowbird 회의를 소집했다. 켄트 벡은 심한 부비동 감염과 강한 약물 때문에 회의를 정확히 기억하지 못하지만, 모두가 자신의 가치를 넣으려 해 잘 풀리지 않았다고 회상한다.
2. 휴식 중 만들어진 합의
   1. 참석자들이 휴식하러 나간 사이 Martin Fowler와 Jim Highsmith가 남았고, 돌아왔을 때 “우리는 이것을 가치 있게 여기지만 저것을 더 가치 있게 여긴다”는 네 가지 가치의 기본 골격이 화이트보드에 적혀 있었다.
   2. 뒤이어 원칙을 썼고, 켄트 벡이 직접 기여한 단어는 비즈니스 담당자와 개발자가 프로젝트 내내 함께 일해야 한다는 문장의 “매일(daily)”이었다.
   3. 이름은 알파벳순이라 켄트는 첫 번째 서명자일 뿐이며, 선언문을 혼자 만든 사람은 아니라고 강조한다.

6.2. Agile이라는 이름의 문제

1. 방어할 수 없는 이름
   1. “나는 경직된 개발을 선호한다”고 말할 사람은 없으므로 누구나 자신을 Agile하다고 부를 수 있다. 반면 XP의 실천을 하지 않은 사람은 스스로를 Extreme Programmer라고 부르기 어렵다.
   2. 페어링, 점진적 설계, 철저한 테스트, 도구 투자 같은 기술을 실제로 하지 않으면 Agile이라는 단어만 남고, 시간이 지나며 그 단어가 의미를 잃거나 부정적인 인상을 갖게 된다.
2. 기술 토대 없는 Agile의 실패
   1. 대기업용 Scaled Agile Framework가 거대한 비용으로 판매되면서 원래의 목적보다 더 많은 관료주의를 만들었다.
   2. 재계획과 임의 순서의 기능 구현을 가능하게 하려면 조각 단위로 신뢰성 있게 개발하고, 선택지를 보존하도록 설계하고, 필요하면 도구까지 직접 만드는 기술이 필요하다.
   3. “누구나 할 수 있고 두 배의 일을 절반의 시간에 할 수 있다”는 약속은 거짓이다. 두 배의 성과는 가능하지만, 학교나 첫 직장에서 잘 가르치지 않는 기술을 오랫동안 훈련해야 한다.

6.3. JUnit과 선언문이 보여준 제품·커뮤니티 효과

1. 비행기 안에서 만든 JUnit
   1. Eric Gamma가 Java를 보여주고 켄트 벡이 SUnit을 보여주기 위해 비엔나에서 워싱턴으로 가는 비행기에 탔다.
   2. 인터넷도 좌석 전원도 없고 배터리는 2시간 반뿐인 상황에서 JUnit을 JUnit으로 테스트하며 만들었다. 도착 뒤 Martin Fowler에게 주자 다음 날 복사본을 달라는 요청이 몰렸다.
   3. 세 장짜리 플로피 디스크를 만들어 나눠줄 만큼 수요가 컸다. 원래의 실천이 커뮤니티의 손에 들어갈 때 제품-시장 적합성처럼 확산될 수 있다는 사례다.
2. 서명자가 만드는 투자감
   1. Agile Manifesto는 초기 서명자 이름을 공개하고 한동안 누구나 서명하게 했다. 사람들은 직접 참여하고 이름을 붙인 것에 투자감을 느꼈다.
   2. 다만 1986년 OOPSLA에서 시작해 2001년 선언문을 만들기까지 객체지향 기술의 결과를 정리하는 데 15년이 걸렸다. 새로운 기술이 나온 즉시 선언문을 만들자는 요구에 켄트 벡이 “아직 너무 이르다”고 말하는 이유다.

7. 닷컴 붕괴, 회복, 그리고 Facebook의 역설

7.1. 9·11 이후의 상실과 재학습

1. 개인적 붕괴
   1. 켄트 벡은 오리건 남부에 8헥타르의 땅을 사고 집과 사무실을 짓던 중이었다. 9·11 직전에는 고액 컨설팅 일이 8개월치 예약돼 있었지만 다음 날 전부 취소됐고, 집 공사비가 나오는 시점에 수입이 사라졌다.
   2. 심한 우울증과 번아웃으로 수년간 프로그래밍을 할 수 없었다. 사람들은 그를 영웅이나 악당으로 과장했고, XP가 인생을 망쳤다는 메시지까지 보냈다.
2. 영웅·악당 투사의 분리
   1. 타인이 보는 나, 내가 보는 나, 실제의 나 사이에는 차이가 있다. 누군가 영웅이나 악당을 필요로 해 특정 인물을 과대평가하거나 비난하는 것은 그들의 필요이지 그 사람의 본질이 아니다.
   2. 켄트 벡은 Sudoku 쉬운 문제에서 중간 난도로, 다시 십자말풀이와 Eclipse 프로그래밍 문제로 난도를 올리며 회복했다. 2002년부터 2011년까지를 잃어버린 10년으로 부르지만, “아직도 프로그래밍이 재미있다”는 감각을 되찾았다.

7.2. Facebook에서 기존 플레이북을 버리다

1. 50세에 2,000명 조직으로 들어간 이유
   1. 다섯 자녀의 학비 때문에 안정적인 수입이 필요했고, 출판만으로는 충분하지 않았다. 당시 Facebook은 약 2,000명 직원과 700명 엔지니어로 빠르게 성장하면서 안정성과 혁신을 동시에 달성하고 있었다.
   2. 켄트 벡의 책에 나온 관행을 거의 따르지 않는 조직이 어떻게 그 결과를 내는지 알아보기 위해 들어갔다. TDD 강좌를 해커톤에 등록했지만, 앞의 아르헨티나 탱고와 뒤의 고급 Excel 수업은 만석인데 TDD에는 단 한 명도 신청하지 않았다.
   3. 그는 기존 지식을 잊고 “원숭이처럼 보고 따라 하며” Facebook의 소프트웨어 엔지니어링을 다시 배웠고 7년을 머물렀다.
2. 테스트가 없어도 작동한 다층 피드백
   1. 개발자 머신에서 PHP 코드를 바꾸고 몇 초 만에 결과를 확인할 수 있었다. 코드 리뷰, 내부 배포, 단계적 롤아웃, 배포팀의 별점, 운영 관측성이 차례로 피드백을 제공했다.
   2. 별점이 낮으면 배포가 막혔고, 금요일의 사고 검토에서는 사건의 시간순 경과와 배운 점, 재발 방지책을 설명해야 했다. 운영팀이나 다른 사람을 탓하면 문제가 커졌고, 책임을 갖고 학습하는 태도를 보이면 통과했다.
   3. 켄트가 직접 작성한 단위 테스트도 결합된 다른 코드 때문에 사이트 장애를 일으켰다. 단위 테스트 하나만으로는 충분하지 않지만, 여러 피드백 층의 구멍이 한 줄로 맞물리지 않게 하는 Swiss cheese 모델이 전체 신뢰성을 만들었다.
3. 유틸리티가 된 Facebook
   1. 처음에는 계획과 마감일이 거의 없었다. Mark Zuckerberg가 사진 해상도를 네 배로 높이고 싶다고 하면 엔지니어가 불가능한 이유를 설명해도, 일단 시도하고 오래 걸리면 다른 문제로 옮겼다.
   2. Microsoft 출신 엔지니어는 좋은 문제를 지키려는 Microsoft와 달리 Facebook은 다른 사람이 같은 문제를 풀면 더 급한 불로 이동할 만큼 기회가 풍부했다고 설명했다.
   3. 시간이 지나 Facebook이 사회 인프라처럼 여겨지면서 “사람들이 911에 전화한” 장애 사건이 생겼고, 회사는 안정성을 훨씬 심각하게 다루게 됐다.

7.3. 작은 코드 개선과 조직 실험

1. 18쪽짜리 사진 PHP 파일과 연간 500만 달러 절감
   1. 부트캠프에서 당시 세계 최대 사진 사이트의 18쪽짜리 단일 PHP 파일을 출력해 살펴보다가 프런트엔드와 캐시·데이터베이스 사이 왕복을 더 병렬화할 수 있음을 발견했다.
   2. 수정 일주일 뒤 사진 관리자는 장비 수요가 급감해 서버를 재배치할 수 있었고 연간 500만 달러를 절감했다고 알렸다. 켄트는 그 일을 “그냥 만지작거렸을 뿐”이라고 표현한다.
2. 전역 최적화와 50-50 목표
   1. 상장 전 중간 관리자는 스톡옵션의 세대적 부를 지키기 위해 팀의 국소 최적화보다 회사 전체 가치가 오르는 배치를 선택했다. 개인의 팀을 돕는 것보다 주가를 올리는 곳으로 사람을 보내는 이상한 행동도 나타났다.
   2. 6개월 목표의 절반을 달성하면 A+이고 모두 달성하면 목표를 너무 낮게 잡은 것이며, 아무것도 달성하지 못하면 해고됐다. 위험을 감수하고 배워야 한다는 압박이 불안을 만들었지만, 모두 같은 규칙 아래 있어 태업자를 보호할 필요가 적었다.

7.4. Good to Great 코칭

1. 정체된 좋은 개발자를 한 단계 올리기
   1. 켄트 벡은 Messenger 인프라의 C++ 작업에서는 자신이 뛰어나지 않다는 것을 깨달았고, 과거 원격 코칭 경험을 바탕으로 Facebook에서 자발적으로 코칭을 시작했다.
   2. 처음에는 세 명에게 매일 한 시간씩 이야기했는데 너무 강도가 높았다. 두 명은 잘 성장했고 한 명은 해고됐지만, 입소문으로 프로그램이 Good to Great로 발전했다.
2. 측정 가능한 효과와 생산적 불편
   1. 한 번에 여섯 명을 일대일로 코칭하고, 선임과 주니어를 짝지어 코칭하게 한 뒤 코치들의 어려운 사례를 함께 검토했다. 스토리텔링 컨설턴트와 오프사이트도 진행했다.
   2. 코칭을 받은 사람은 비슷한 집단보다 다음 해 승진할 확률이 두 배였고, 약 200명을 직접 코칭했다. 퇴사 직전 Facebook 엔지니어 상위 1% 약 100명 중 10명이 그의 옛 학생이었다.
   3. 좋은 코칭은 달래는 말이 아니라 생산적인 불편을 유도한다. “그건 잘못하고 있다. 이걸 시도하고 결과를 말해 달라”고 요구하며, 학생이 시도할 의지가 없으면 관계를 끝낼 수도 있어야 한다. 코칭을 받은 사람이 다시 코치가 되고 그 코치가 또 다른 코치를 키우는 계보가 생겼다.

8. AI 가속 시대의 조직과 개발자

8.1. 개발 속도와 사업 속도의 불일치

1. 가속된 코드, 느린 의사결정
   1. AI는 개발 속도를 급격히 높였지만 사업의 고객지원·마케팅·영업·제품 의사결정 체계는 아직 5년짜리 주기로 움직인다.
   2. 어떤 고객사는 연 200만 달러짜리 SaaS를 자신에게 더 잘 맞는 바이브 코딩 대체품으로 만들었다. 공급자는 과거라면 몇 년 동안 애드온을 준비했겠지만 이제 한 달 안에 수익 기반을 잃을 수 있다.
   3. 켄트 벡의 Agile 정의는 “제때 반응하는 것”이다. 트랙터를 몰던 조직이 갑자기 Ferrari를 받았다고 해서 엔진 출력만큼 산길을 빨리 달릴 수 있는 것은 아니다. 회사가 조향 능력을 준비하지 않으면 실패한다.
2. 전환 비용이 0이 되는 산업
   1. 신문은 분류 광고 수입으로 기자와 종이 인쇄를 유지했지만, 분류 광고가 사라지면서 지역 저널리즘의 대응은 일부 성공하고 일부 실패했다.
   2. AI가 기존 서비스의 전환 비용을 거의 없애면 그 비용에 기대던 이익도 0에 가까워진다. 변화에 적응한 조직은 살아남지만 기존 보호막에 안주한 조직은 무너진다.

8.2. 바이브 코딩은 보이는 빙산의 끝만 해결한다

1. 작은 계산과 실제 급여 업무의 차이
   1. 사용자는 Claude에게 근무시간·시급·세율을 입력해 급여액을 계산하게 한 뒤 Gusto가 필요 없다고 생각할 수 있다.
   2. 실제 급여 업무에는 여러 주의 세무기관 보고, 거주 주와 근무 주의 차이, 회사 소재지, 공제와 규정 준수 등 보이지 않는 하위 문제가 들어간다.
   3. 보이는 빙산의 끝만 바이브 코딩하고 나머지를 버리면, 나중에 존재조차 몰랐던 downstream 문제에서 막힌다. AI가 코드를 만들 수 있는 것과 운영 가능한 시스템을 만드는 것은 다르다.
2. 개발자의 정체성 전환
   1. 개발자는 코드 작성과 장인정신을 자신의 정체성으로 삼아왔지만 AI가 그 부분을 빠르게 대신하고 있다.
   2. 앞으로의 핵심 활동은 요구사항을 구체화하고, 생성 결과를 검증하고, 시스템의 보이지 않는 맥락을 이해하고, 다른 사람과 신뢰를 만드는 일이다. 무엇이 최선의 방법인지 아직은 “아무도 모른다”.

8.3. 3X 모델과 사라진 플레이북

1. Explore: 탐색
   1. 결과를 예측할 수 없는 단계에서는 서로 상관없는 값싼 실험을 최대한 많이 시도한다. 목표는 처음부터 완성하는 것이 아니라 무엇이 작동하는지 찾는 것이다.
   2. AI 개발에서도 한 번에 큰 설계를 확정하기보다 작은 프롬프트·테스트·Markdown 지침·커밋 훅을 조합해 결과를 비교하고, 실패를 기록해야 한다.
2. Expand: 확장
   1. 무언가가 작동하면 다른 시도를 버리고 한 가지에 집중한다. 장애물을 하나씩 제거하며 짧은 기간에는 지속 불가능해 보일 정도로 자원을 몰아붙인다.
   2. 탐색의 규율과 확장의 규율은 다르다. 탐색의 습관으로 확장하면 집중력이 부족하고, 확장의 습관으로 탐색하면 너무 일찍 하나의 답에 고착된다.
3. Extract: 추출
   1. 반복 가능한 성장 방식이 생기면 새 국가 출시 같은 일을 정해진 플레이북으로 수행하고 규모의 경제를 얻는다.
   2. 탐색·확장·추출 단계에 따라 코드 작성법, 프로젝트 관리, 채용 인원, 조직 구조, 품질 기준이 모두 달라야 한다.
4. 플레이북이 백지화된 AI 시대
   1. 지난 20년은 추출 단계의 플레이북을 잘 적용하는 사람이 선임 엔지니어로 인정받는 시기였다. 백엔드 확장성, 멱등성, 프로덕션 버그 대응 같은 표준 답이 축적돼 있었다.
   2. 생성형 AI는 기존 플레이북을 지웠다. 입력을 조금 바꾸면 출력이 크게 달라지고, 다음 주에는 도구가 바뀐다. 플레이북을 적용하는 능력과 플레이북을 새로 쓰는 능력은 다르므로, 전자가 정체성인 사람은 불안해질 수밖에 없다.
   3. 지금 필요한 것은 비밀스러운 AI 플레이북을 사는 일이 아니다. 커뮤니티에서 실험을 공유하고, “이 Markdown 파일을 추가했더니 이런 결과가 났다”, “내 환경에서는 나빠졌다”고 차이를 토론하면서 다음 플레이북을 공동으로 만드는 일이다.

8.4. AI 개발 선언문은 아직 이르다

1. 1986년의 객체지향 실험에서 2001년 Agile Manifesto까지 15년이 걸렸다. 기술의 결과와 실천을 충분히 경험한 뒤에야 간단한 원칙으로 압축할 수 있었다.
2. AI 도구와 모델은 빠르게 변하고 있으며, 지금의 성공법이 다음 주에도 유효하다는 보장이 없다. 따라서 “AI 개발의 새 선언문”을 당장 만들기보다 “아무도 모른다. 시도하고 공유하자”가 정직한 원칙이다.

9. 지금 켄트 벡이 만드는 것과 시작하는 법

9.1. AI가 되돌려준 창조적 충동

1. Arlo와 라이브러리 품질의 실험
   1. Arlo라는 객체지향 데이터베이스와 여러 자료구조를 만들며 익숙하지 않은 언어로 라이브러리 품질의 코드를 작성할 수 있는지 실험한다.
   2. Rust 전문가가 아닌데도 일부 작업에서 Rust의 B-tree보다 빠른 B+ tree를 만들었다. 이 결과가 “그렇다면 Rust 전문가라면 무엇을 만들 수 있고, 왜 아직 만들지 않았을까?”라는 새 질문을 낳는다.
2. 뉴스레터와 사업 계획
   1. 뉴스레터를 지속 가능한 사업으로 만드는 방법을 AI와 함께 탐색하고, 사업 파트너도 고용했다. 코드를 만드는 일뿐 아니라 글쓰기와 경험에 대한 성찰도 계속한다.
3. 막히면 고치지 말고 다시 시작하기
   1. GitHub에는 Project, Project 2, New Project 3처럼 시작하고 밀어붙인 뒤 버린 흔적이 남아 있다.
   2. Genie가 더 이상 진전하지 못하면 기존 결과를 억지로 수정하지 않고, 구현 순서·Markdown 파일·커밋 훅을 바꿔 처음부터 다시 시작한다.
   3. 싸고 되돌릴 수 있는 실험이라면 멍청해 보이는 아이디어도 시도할 가치가 있다. 대부분 실패하지만 경쟁자가 시도하지 않은 한 번의 성공이 새로운 플레이북이 된다.

9.2. 개발의 본질을 회복하는 실행 원칙

1. 문제를 코드 생성 요청으로 축소하기 전에 사용자와 원하는 결과·숨은 제약·운영 책임을 대화로 확인한다.
2. 생성된 코드를 곧바로 신뢰하지 말고 도메인 사례, 경계 조건, 회귀 테스트, 실제 운영 신호로 검증한다.
3. 큰 설계를 먼저 확정하기보다 값싸고 되돌릴 수 있는 서로 다른 실험을 여러 개 실행한다.
4. 잘 작동하는 실험이 발견되면 확장 단계의 집중으로 전환하고, 반복 가능한 절차가 생긴 뒤에만 추출 단계의 표준화·조직화를 적용한다.
5. 소프트웨어 기술과 함께 공감, 말투 읽기, 요구사항 재확인, 책임 있는 사고 보고를 훈련한다.
6. 새 방법론을 도덕적 자격증으로 만들지 않는다. TDD·XP·Agile은 실제 문제와 맥락에 맞는 실용적 선택이지 사람의 우열을 판정하는 기준이 아니다.

주요 발언 모음

“우리는 신뢰를 축적하는 속도보다 빠르게 코드를 축적하고 있다.”

“코딩은 당신이 하는 일의 일부일 뿐이고, 그중에서도 작은 부분이다.”

“이것은 가장 거대한 우주의 실용적 농담이다. 컴퓨터만 이해하면 성공할 수 있다고 약속받았는데, 나중에 사람을 이해해야 한다는 사실을 알게 된다.”

“테스트 주도 개발은 도덕적 결정이 아니라 실용적 결정이다.”

“아무도 모른다. 나만 모르는 것이 아니라 아무도 모른다.”

“나는 젤리를 만드는 사람이 아니라 나무를 흔드는 사람이다.”

“보이는 빙산의 끝을 바이브 코딩할 수는 있지만, 보이지 않는 나머지를 버리면 나중에 자신이 몰랐던 문제에 도달한다.”

“창의적 충동이 Genie와 함께 돌아왔다. 내 상상과 작업 때문에 전에는 없던 실제 결과물이 생긴다.”

핵심 데이터 & 수치

• 65~70파운드: 어린 켄트 벡이 처음 접한 프로그래머블 계산기의 무게다.
• 400달러: 아버지가 구입한 HP-35 계산기의 당시 가격이다.
• 약 10Hz: HotDraw에서 사각형을 부드럽게 움직일 수 있었던 당시의 애니메이션 성능이다.
• 최대 16,000개: MassPar의 토러스 격자에 연결된 처리 요소 수다.
• 3개 클래스·12개 메서드: SUnit 초기 프레임워크의 대략적인 규모다.
• 3주: C3 프로젝트가 반복한 개발·테스트·통합 주기다.
• 15년: 객체지향 개발의 초기 실험에서 Agile Manifesto까지 원칙이 성숙하는 데 걸린 시간이다.
• 8개월: 9·11 직전 켄트 벡에게 예약돼 있던 고액 컨설팅 기간이다.
• 7년: 켄트 벡이 Facebook에 머문 기간이다.
• 500만 달러/년: 사진 코드의 병렬화 개선으로 재배치할 수 있게 된 서버 비용이다.
• 2배: Good to Great 코칭 참여자의 다음 해 승진 가능성이 비교 집단보다 높았던 정도다.
• 200명 이상: 켄트 벡이 Facebook에서 직접 코칭한 대략적인 인원이다.
• 200만 달러/년: 한 고객사가 AI로 대체하려 했던 SaaS 구독 비용 사례다.

결론 및 시사점

1. AI는 코드 작성과 반복 구현을 급격히 가속하지만, 문제를 정의하고 도메인을 이해하고 결과를 검증하는 인간의 책임을 없애지 않는다.
2. 개발자는 생성량보다 신뢰량을 관리해야 한다. 테스트는 코드의 정답을 확인하는 동시에 사람과 프로그램이 같은 이해를 공유한다는 증거다.
3. 사용자·동료와의 대화, 공감, 요구사항의 재정의는 자동화할 수 없는 소프트웨어 엔지니어링의 중심이다.
4. TDD·XP·디자인 패턴의 공통 기반은 짧은 피드백, 공동 설계, 선택지 보존, 실패 비용의 축소다.
5. Agile이라는 이름만 도입하면 관료주의가 늘어난다. 반복적 개발을 실제로 수행할 기술적 기초와 도구가 먼저 필요하다.
6. AI 시대에는 검증된 플레이북이 사라졌으므로 “아무도 모른다”는 사실을 인정하고 탐색을 조직의 기본 행동으로 삼아야 한다.
7. Explore에서 값싼 실험을 많이 하고, Expand에서 작동하는 한 가지에 집중하고, Extract에서 반복 가능한 운영 모델을 만든다.
8. AI 도구를 잘 쓰는 개발자는 더 많은 코드를 생성하는 사람이 아니라 더 많은 실험과 학습을 안전하게 수행하고, 결과를 팀의 신뢰와 지식으로 전환하는 사람이다.
9. 가장 현실적인 혁신 전략은 실패해도 되돌릴 수 있는 작은 아이디어를 계속 시도하고, 막히면 낡은 결과를 과감히 버리고 다시 시작하는 것이다.

보조 정보

• 원본 대화는 The Pragmatic Engineer의 2026년 7월 1일 에피소드이며, Budapest에서 Craft Conference 2026 직전에 녹음됐다.
• 원본 방송에는 AI 에이전트 코드 검증 서비스 Antithesis, 객체·전문 검색 서비스 turbopuffer, SaaS 기업용 인증·권한 서비스 WorkOS에 대한 협찬 안내가 포함돼 있다.
• Gergely Orosz는 대화의 마지막에 켄트 벡의 일관된 태도를 “신뢰보다 빠른 코드 축적”, “멍청해 보이는 아이디어 시도”, “나무를 흔드는 사람”으로 정리하고, AI 개발 선언문을 만들기에는 아직 이르다는 답변을 다시 강조한다.

핵심 요약 (20줄)

1. 켄트 벡은 코딩이 사라져도 소프트웨어 엔지니어링의 이해·신뢰·소통은 사라지지 않는다고 말한다.
2. 코딩은 도메인을 이해하고 프로그램을 신뢰하게 만드는 학습 과정이며 단순한 타이핑 작업이 아니다.
3. AI는 코드보다 빠르게 신뢰를 축적하지 못하므로 생성 결과의 가정과 한계를 사람이 검증해야 한다.
4. 사용자와 문제를 함께 정의하는 대화는 자동화하기 어려운 인간적 신뢰를 만든다.
5. 켄트 벡은 컴퓨터만 잘하면 된다는 약속이 사람을 이해해야 한다는 현실을 가린 우주의 농담이었다고 회고한다.
6. Smalltalk는 메시지·변수 할당·값 반환이라는 작은 기반으로 일관된 객체 세계를 만들었다.
7. Smalltalk의 개인적 창조성은 강력했지만 많은 사람이 만든 프로그램은 유지보수와 협업의 한계를 드러냈다.
8. Ward Cunningham과의 페어 작업은 키보드·설계 수준·명명·주간 피드백을 하나의 학습 루프로 묶었다.
9. 디자인 패턴은 사용자를 대신하는 설계도가 아니라 제약 안에서 사용자가 선택하도록 돕는 언어다.
10. CRC 카드는 데이터가 있는 곳으로 책임과 계산을 옮겨 결합도를 낮추는 객체 설계 도구다.
11. SUnit과 JUnit은 테스트를 별도 감독 업무가 아닌 프로그래머의 언어 안에 넣어 신뢰를 자동화했다.
12. C3 프로젝트는 코드를 버리고 세 주기마다 테스트·통합·재계획을 반복해 Extreme Programming으로 발전했다.
13. TDD의 본질은 테스트를 도덕적 규율로 강요하는 것이 아니라 행동과 학습을 빠르게 번갈아 하는 데 있다.
14. Agile Manifesto는 15년의 객체지향 실험 뒤에 만들어졌으며 “daily”라는 협업 원칙이 켄트 벡의 기여였다.
15. 기술적 기반 없는 Agile은 대기업용 관료주의나 “두 배의 일을 절반 시간에”라는 과장된 판매 문구로 변질된다.
16. Facebook은 단위 테스트가 적어도 개발·리뷰·단계적 배포·관측성·사고 검토의 다층 피드백으로 안정성을 확보했다.
17. Good to Great 코칭은 생산적인 불편과 코치의 계보를 통해 엔지니어의 성장과 승진을 가속했다.
18. AI는 개발 속도를 높였지만 조직의 사업 의사결정 속도는 느리므로 변화에 제때 반응하지 못하는 회사가 실패할 수 있다.
19. AI 시대의 정직한 원칙은 아무도 모른다는 사실을 인정하고 Explore·Expand·Extract 단계별로 실험과 학습을 반복하는 것이다.
20. 켄트 벡은 막히면 과거 결과를 고집하지 않고 다시 시작하며 AI가 오랫동안 미뤄둔 창조적 아이디어를 현실로 돌려주었다고 말한다.