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

URL: https://www.youtube.com/watch?v=_0zB1Qj-xoE 날짜: 2026-10-03 채널: Tech Bridge

메타데이터

• 원문 제목: [한영자막] 켄트 벡이 밝히는 AI 시대의 소프트웨어 엔지니어링, 진짜 개발의 본질은 무엇일까요?
• 발표자: Kent Beck
• 영상 길이: 약 51분 43초
• 원문 강연: Kent Beck: Software Engineering in the Age of AI, Prodacity 2026
• 핵심 키워드: Augmented Development, Genie, Plausible vs Working, Features vs Futures, Iterative Development, TDD, Refactoring, Formal Methods, Goodhart’s Law, Mission

---

📌 핵심 질문 / 이 강연이 관통하는 핵심 논점

==AI가 코드의 상당 부분을 작성하는 시대에도 소프트웨어 엔지니어링은 사라지지 않으며, 핵심은 그럴듯한 코드를 빠르게 얻는 일이 아니라 변화 가능한 시스템을 만들고 실제 미션에 기여하는 과정을 설계하는 데 있다.==

• AI가 만드는 코드는 구문상 그럴듯한(plausible) 결과와 실제로 작동하는(working) 결과를 구분하지 못하므로, 인간은 신뢰를 추론하지 말고 적대적으로 검증해야 한다.
• 기능(Features)을 추가할수록 미래의 변경 선택권(Futures)이 소진되므로, 기능 사이에 멈춰 이해·리팩터링·중복 제거·설계 개선을 수행해야 한다.
• 한 번의 완벽한 명세로 소프트웨어를 끝내려는 방식은 변화와 피드백을 배제하는 폭포수 모델의 반복이며, 실제 시스템은 작은 가치 배포와 반복적인 학습으로 진화해야 한다.
• 노력(Effort)·산출(Output)·사용자 행동의 변화(Outcome)를 측정하는 것만으로는 공동의 미션(Mission)을 측정할 수 없고, 코드 줄 수와 PR 수를 목표로 삼으면 Goodhart의 법칙에 따라 시스템 자체가 망가진다.

켄트 벡이 붙인 ‘지니(Genie)’라는 이름은 AI가 요청을 들어주지만 의도한 바와 다른 것을 내놓는다는 관계를 압축한다. AI는 개발자의 기술적 야망을 확장하고 피드백을 빠르게 만들지만, 인간의 이해와 판단이 사라진 완전 자율 소프트웨어 공장은 언제나 궤도를 벗어난다. 장인정신(Craft)은 코드 한 줄 한 줄을 아름답게 다듬는 개인적 취향이 아니라, 지연 비용과 시스템 수명을 고려해 언제 만들고 언제 멈추며 무엇을 버리고 무엇을 검증할지 선택하는 실천으로 재정의된다.

1. 배경과 문제의식: 상업 소프트웨어에서 증강 개발까지

켄트 벡은 자신의 경력과 질문하는 태도를 소개하며 소프트웨어 장인정신의 의미가 AI 앞에서 어떻게 바뀌는지 논의를 연다.

1.1. 상업 소프트웨어 개발자에서 기술·사회학의 교차점으로

1. 상업 소프트웨어가 출발점이다

   1. 경력의 중심: 평생 상업 소프트웨어 개발에 몸담았고, 군·정부 영역과의 접점은 간헐적이었다.
   2. Lockheed 일화: 오래전 Lockheed 프로젝트에 참여했던 경험을 꺼내며 “Lockheed가 아직도 있나요?”라고 묻고, 관객이 그렇다고 답하자 “내가 그 회사를 침몰시키지는 않았나 보네요”라고 농담한다.
   3. 공통 제약: 행사에서 들은 군·정부 관련 주제는 평소 관심사 밖이었지만, 소프트웨어 개발과 제약의 구조가 매우 비슷하다고 본다.

2. 오래 묵힌 문제를 뒤에서 계속 굴린다

   1. 사고 방식: 문제를 머릿속 뒤편에 넣어두고 계속 ‘소화(digest)’한다.
   2. 시간의 폭: 답이 몇 분 만에 나올 때도 있지만 몇 달, 몇 년, 심지어 수십 년이 걸릴 때도 있다.
   3. General Whiting의 자극: 10~15년 동안 다듬어온 아이디어의 정교화된 버전을 행사 당일 General Whiting의 이야기를 듣다가 풀었다고 예고한다.

3. 질문은 리더십의 행동이다

   1. 즉시 질문하기: 의문을 품은 채 앉아 있기보다 손을 들고 바로 질문하는 편을 선호한다.
   2. Ken Ross의 이산수학 수업: 대학 신입생 시절 실험적인 이산수학(discrete mathematics) 수업에서 Ken Ross 교수가 명확하게 설명하지 못하자, 3주쯤 지나 학생들이 멍한 눈으로 칠판만 바라보게 됐다.
   3. 집단적 각성: 한 학생이 “무슨 일이 일어나는지 아는 사람 있나요?”라고 묻자 모두가 “아무것도 모르겠다”고 답했다. 교수의 지각을 계기로 학생들은 “아무도 이해하지 못했으니 예정된 강의를 멈추고 다시 설명해 달라”고 한꺼번에 요구했다.
   4. 결과와 농담: Ken Ross는 훗날 매우 유명한 이산수학 교과서를 썼고, 벡은 자신들의 수업이 그 책의 탄생에 상당한 책임이 있다고 농담한다.

1.2. 켄트 벡의 이력과 TDD의 뿌리

1. 소프트웨어 개발의 여러 원형을 다뤘다

   1. Patterns: 패턴과 패턴식 사고를 소프트웨어 개발에 도입하는 데 중요한 역할을 했다.
   2. JUnit: 프로그래머 테스트와 테스트 프레임워크인 JUnit을 처음 만들었고, Erich Gamma와 함께 다듬은 뒤 수많은 방식으로 복제됐다.
   3. Extreme Programming: Extreme Programming(XP)을 자신의 대표적인 작업으로 소개한다.
   4. Agile Manifesto: 애자일 선언문(Agile Manifesto)의 서명자이며, 알파벳순으로 첫 번째 서명자였다고 말한다.

2. TDD는 완전히 새로운 발명이 아니라 재발견과 정제다

   1. 1957년 책의 발견: 『Digital Programming』과 비슷한 제목의 1957년 책을 발견했는데, 당시에는 이진 컴퓨터와 십진 컴퓨터의 구분조차 아직 정리되지 않았다.
   2. 입출력 쌍으로 검증: 책은 사용자를 찾아가 해당 영역의 입력·출력 쌍을 ‘check items’로 받아 프로그램이 그 예시와 일치하는지 확인하라고 권한다.
   3. TDD와의 동일성: 벡은 그 대목에서 “이게 바로 Test-Driven Development다”라고 느꼈다. 따라서 TDD를 자신이 발명했다고 주장할 수는 없고, 오래된 아이디어를 재발견해 정제했다고 표현한다.

3. 현재는 증강 개발의 최전선에 있다

   1. 고잠재력 엔지니어 코칭: 오랫동안 성장 가능성이 높은 엔지니어들을 코칭해왔다.
   2. Frontier Lab 경험: 프론티어 모델을 만드는 연구소와 함께 일하며, 모델 하나를 만드는 문제가 아니라 연속적인 프론티어 모델을 만드는 팀이 실제로 어떻게 일해야 하는지 고민한다.
   3. 기술과 사회학: 문제를 단순히 도구를 누르면 해결되는 ‘press play’ 작업으로 보지 않고, 기술과 사회학의 교차점에서 팀의 행동·학습·협업을 함께 살핀다.

2. ‘지니’와 그럴듯한 코드의 함정

AI가 프로그래머보다 코딩을 잘한다는 주장은 구문 생성과 실제 작동을 혼동한 결과이며, 신뢰는 자동으로 따라오지 않는다.

2.1. Augmented Development는 아직 인간의 과정이다

1. 지니라는 비유

   1. 요청과 결과의 어긋남: 지니는 소원을 들어주지만 실제로 원했던 것과 다른 결과를 내놓는다.
   2. 협업의 반복: 인간이 요청하면 지니가 결과를 돌려주고, 결과는 매우 멋져 보이지만 마지막에는 의도와 어긋난 부분 때문에 실망하게 된다.
   3. 인간의 잔여 판단: 적어도 현재는 지니가 내리는 결정에 인간이 더할 판단이 많으므로 ‘자동화’보다 ‘증강 개발(Augmented Development)’이라고 부른다.

2. Plausible은 Working이 아니다

   1. 핵심 반박: AI가 구문상 올바른 프로그램을 만들 수 있다고 해서 프로그래머보다 낫거나 실제로 작동한다는 뜻은 아니다.
   2. 벡의 선호: 자폐인으로서 프로그래밍의 이진적인 빨강·초록(red/green) 피드백을 좋아했다. “프로그램이 작동하지 않는다”에서 버그를 고치고 “이제 고쳐졌다”로 이동하는 명확함이 편안했다.
   3. AI의 약점: 지니는 plausibility, 즉 그럴듯함에는 매우 뛰어나지만 working, 즉 실제 작동에는 자주 실패한다.

3. C 컴파일러 사례

   1. 과장된 성공담: 1만 달러어치 토큰을 써서 작동하는 C 컴파일러를 얻었다는 이야기가 퍼진다.
   2. 검증하면 드러나는 문제: Hello World조차 실제로 동작하지 않거나 남은 버그가 있고, 하나의 버그를 고칠 때 세 개의 버그가 새로 생긴다.
   3. C compiler-ish: 깊이 파고들면 C 컴파일러에 가까운 무언가일 뿐, C 프로그램을 효율적으로 컴파일해 실행하는 수준의 ‘작동하는 컴파일러’는 아니다.
   4. 판정 기준: 프로그램이 실제 C 프로그램을 효율적으로 컴파일하고 실행해야 한다는 기준을 포기해서는 안 된다.

2.2. 신뢰를 추론하지 말고 적대적으로 검증하라

1. 관계의 재설정

   1. 대상: 프로그래머, 프로그래머의 관리자, 소프트웨어 구매자 모두 AI가 생산에 깊이 관여한 소프트웨어를 냉소적으로 바라봐야 한다.
   2. 적대적 질문: “당신은 이게 작동한다고 말하지만, 나도 만족시켰나? 얼마나 진짜인가? 얼마나 세게 밀어붙여야 하나?”라고 물어야 한다.
   3. 추론의 붕괴: 사람이 설계 단계에서 보장하던 특정 버그 클래스의 불가능성이나 ‘구조에 의해 작동함(by construction)’을 AI가 자동으로 제공한다고 가정할 수 없다.

2. 프로그래머를 없애려는 반복된 사이클

   1. 역사적 반복: 벡은 머리카락을 잃을 만큼 오랜 세월 동안 “이제 프로그래머는 필요 없다”는 선언을 여러 번 보아왔다.
   2. 평문 요구사항의 환상: 비즈니스 담당자가 평문으로 요구사항을 말하면 컴퓨터가 계산하고 프로그래머가 사라질 것이라는 꿈은 고급 언어와 COBOL의 고수준 설명으로 이미 반복됐다.
   3. 현재의 다음 라운드: AI 코딩은 같은 사이클의 최신 라운드이며, 그래서 직업 자체를 잃을까 걱정하지 않는다.

3. 젊은 엔지니어에게 필요한 도움

   1. 실수의 지속성: 젊은 엔지니어는 로마 시대부터 이어진 것과 같은 젊은 엔지니어의 실수를 반복한다.
   2. 코치의 역할: “당신은 조금 이상하지만 혼자가 아니고, 나는 더 심한 것도 봤다”라고 말해주는 사람이 거의 압도된 엔지니어에게 큰 위안을 준다.

3. 장인정신(Craft)의 재정의

코드의 미시적 표현을 다듬는 능력은 여전히 유용하지만 예전과 같은 지렛대(leverage)를 갖지 않으며, 장인정신은 시간·피드백·변화 가능성을 조율하는 실천으로 이동한다.

3.1. 예전의 Craft가 잃은 지렛대

1. 기존 장인정신의 표현

   1. 책임 있는 작성: 프로그래머가 자기 자신을 프로그래밍 행위에 온전히 투입하는 방법을 고민하는 책을 최소 세 권 썼다.
   2. 미시적 결정: 좋은 이름, 작은 조각으로의 논리 분해, 조각들의 조합, 들여쓰기, 공백, 사람이 이해하기 쉬운 프로그램 구조가 핵심 실천이었다.
   3. 장기 가독성: 5년 뒤 누군가 코드에 도착했을 때 “읽고 이해할 수 있어서 다행이다”라고 느끼게 만드는 효과가 있었다.

2. AI가 바꾼 레버리지

   1. 결정의 가치 감소: AI가 코드를 만들고 설명하는 상황에서는 이름과 들여쓰기 같은 결정이 예전과 같은 영향력을 갖지 않는다.
   2. 인간 가독성의 지속 가치: 사람이 읽고 이해할 수 있는 시스템과 읽을 수 없는 시스템 중에서는 여전히 전자를 선택한다.
   3. 설명의 가속: 지니가 거짓말을 하지 않는다는 조건 아래에서는, 인라인·추출·이름 변경을 통해 구조를 파악하는 과정을 AI에게 설명받으며 더 빨리 이해할 수 있다.
   4. 사라진 쾌감: 코드를 세부적으로 정리해 “아, 이렇게 연결되는구나”라고 깨닫는 순간은 즐겁지만, 그 한 번의 깨달음에 예전만큼의 실질적 보상이 남지 않는다.

3.2. 시간과 품질 사이의 판단

1. Craft에 대한 양가감정

   1. 개인 동굴에 대한 비판: 벡은 ‘craft’가 프로그래머가 컴퓨터와 둘만의 동굴에 들어가 완성될 때까지 다듬는 행위로 납치된 적이 있다고 비판한다.
   2. 지연 비용이 높은 경우: 지연 비용이 높다면 피드백을 주는 못생긴 프로그램(ugly program)이 정확한 선택일 수 있다.
   3. 장기 수명의 경우: 지연 비용이 낮고 소프트웨어가 20년 동안 살아남을 예정이라면 스위스 시계공처럼 완성도 있게 만드는 편이 장기적으로 이득이다.
   4. 강한 반대: 프로그래머가 작업하는 경험을 위해 시간이 무한히 늘어나도 된다는 생각에는 강하게 동의하지 않는다.

2. 새로운 Craft의 방향

   1. 유효한 규율: 장인정신은 사라지지 않았지만 나타나는 방식이 달라진다.
   2. 판단의 대상: 코드 줄을 아름답게 만드는 일보다 언제 빠른 피드백을 얻고, 언제 구조를 고치고, 언제 오래 유지할 설계를 선택할지 판단하는 일이 중요해진다.
   3. 학습 중심: 장인정신은 생산 속도를 숭배하는 대신 변화에 대응할 수 있는 이해를 축적하는 방식으로 드러난다.

4. Features와 Futures: 기능 사이에서 미래의 선택권을 회복하기

AI는 기능을 전례 없이 빨리 늘리지만, 기능을 추가하는 과정에서 미래의 변경 가능성을 태운다. 프로젝트의 경제적 가치는 현재 기능과 앞으로 가능한 선택권의 합이다.

4.1. AI와 함께 커진 야망, 반복되는 벽

1. 18개월의 증강 개발

   1. 복귀 계기: Gene Kim과 Steve Yegge의 데모를 보고 다시 매일 하드코어하게 프로그래밍하기 시작했다.
   2. 기술의 확장: 원래 자신의 기술로는 도달하기 어려웠던 터무니없이 야심찬 프로젝트를 시도하고 상당한 진전을 만들 수 있게 됐다.
   3. GitHub의 흔적: 프로젝트 이름 뒤에 Project 2, Project 3, Project 4가 이어진다. 한 버그를 고치면 다른 부분이 깨지는 벽에 계속 부딪혔기 때문이다.
   4. 반복되는 낙관: 새 프로젝트에 ‘1’을 붙이지 않는 것은 이번에는 정말 완성할 수 있을 것이라고 매번 생각하기 때문이다. 그러나 실제로는 계속 릴리스하고 다시 시작해야 한다.

2. Features의 곡선

   1. 초기의 속도: 기능 진척은 초반에는 빠르다.
   2. 점점 느려지는 이유: 시간이 갈수록 기존 기능과의 호환성, 누적된 설계, 변경 비용 때문에 새 기능을 추가하는 속도가 늦어진다.
   3. 다른 축: 이 곡선을 설명하는 다른 축을 벡은 optionality, 즉 선택권이라고 부르다가 Futures라는 단어로 정리한다.
   4. 치아 농담: 앞니 하나를 부러뜨린 뒤 ‘futures versus features’라고 부르게 되어 발음상 끔찍한 선택이었다고 농담하지만, 치아를 고쳐 지금은 괜찮다고 말한다.

4.2. 기능은 미래를 태운다

1. 선택권의 시작과 소진

   1. 초기 상태: 처음에는 만들 수 있는 일이 매우 많지만 기능은 하나도 없다.
   2. 첫 기능의 비용: 하나의 기능을 구현하면 그 기능을 유지하기 위한 하위 호환성(backward compatibility)이 생기고, 원치 않는 기능을 제거할 때도 다음 선택지가 줄어든다.
   3. 누적 효과: 다음 기능을 위해 다시 Futures를 태우고 또 태우면, 결국 다른 것을 바꾸는 순간 모든 것이 깨지는 상태가 된다.
   4. 프로젝트 재시작: 모든 것이 엉망이 되어 변경 선택권이 0에 가까워지면 벡은 Project 2, Project 3, Project 4를 시작한다.

2. AI가 엉망을 싸게 만든다

   1. 과거의 비용: 예전에는 100명이 10년을 일해야 다른 것을 바꾸면 깨지는 절대적 0 상태에 도달했다.
   2. 현재의 비용: AI를 쓰면 혼자 자기 사무실에서 일주일 만에 완전히 변경 불가능한 엉망을 만들 수 있다.
   3. 역설적 생산성: 훨씬 적은 투자로 ‘더 이상 바꿀 수 없는 프로젝트’에 도달하는 능력은 한편으로는 큰 생산성 향상이다.

4.3. 기능 사이의 쉼표와 리팩터링

1. Pablo Casals의 16분음표 일화

   1. 이야기: 20세기 위대한 첼리스트 Pablo Casals가 16분음표를 끝없이 연주하는 곡을 연주했다.
   2. 질문과 답: 누군가 “그 많은 16분음표를 연주하다가 지치지 않나요?”라고 묻자 “아니요, 음표 사이에서 쉽니다”라고 답했다는 이야기다.
   3. 사실 여부: 실제로 Casals가 한 말인지는 아니고 만들어진 이야기지만, 젊은 클래식 기타 전공자였던 벡에게 ‘음표 사이’가 있다는 발상은 매우 강렬했다.

2. 기능이 끝난 직후 멈춘다

   1. 지니의 다음 요청: 지니가 손가락 총 모양을 하며 “알겠습니다, 보스. 기능을 끝냈습니다. 다음 것을 구현할까요?”라고 묻는다.
   2. 인간의 호흡: 인간은 “잠깐, 아직 준비되지 않았을지도 모른다”고 말하며 다음 기능 전에 멈출 수 있다.
   3. 선택권 보충: 이미 구현한 부분을 개선하고, 미래의 기능을 위한 구조적 여유를 되돌려놓을 수 있다.

3. 기능 사이에서 할 수 있는 일

   1. 중복 제거: 반복되는 구현을 없애 구조를 단순하게 만든다.
   2. 가독성 최적화: 당장 동작만 유지하는 대신 사람이 이해하기 쉬운 방향으로 구조를 정리한다.
   3. 재구현: 방금 만든 것을 버리고 다른 방식으로 다시 만들어 결과가 달라지는지 확인한다.
   4. 가치의 정의: 프로젝트의 경제적 가치는 현재 기능의 합뿐 아니라 다음에 할 수 있는 모든 일, 즉 Futures의 합이다.

4.4. 보이지 않는 Futures를 가시적인 Features와 균형 잡기

1. 측정의 비대칭

   1. Features는 보인다: 사용자는 기능이 생겼는지 즉시 확인하고 환영한다.
   2. Futures는 숨는다: 미래에 바꿀 수 있다는 선택권은 실제로 필요하지 않을 때 눈에 보이지 않아 “다음 기능을 왜 안 만들었나”라는 비판을 받는다.
   3. 0으로의 추락: 계속 다음 기능만 추가하면 선택권이 0으로 떨어지고 모두가 그 상태를 싫어하게 된다.

2. 왕복 궤적

   1. 기본 원칙: 다음 기능을 추가하는 투자와 다음에 무엇을 만들 수 있을지를 결정하는 Futures 투자를 균형 잡아야 한다.
   2. AI의 압박: AI가 다음 기능을 매우 빨리, 대체로 작동하는 형태로 만들어주므로 Futures에 투자할 기회비용이 더 커진다.
   3. 완료의 재정의: “더 이상 이 소프트웨어를 바꾸고 싶지 않다”는 상태는 완성이 아니라 실패다. 좋은 소프트웨어는 새로운 아이디어를 계속 자극해야 한다.
   4. 명세의 한계: “앞으로 쉽게 바꿀 수 있게 한다”는 조건은 대부분의 명세에 적히지 않으므로, Futures의 가치는 요구사항 문서에서 과소평가된다.

3. 동시에 최적화하지 말고 번갈아 최적화한다

   1. 인지 한계: 기능과 미래의 선택권을 한 번에 최고 수준으로 구현하는 일은 지니와 인간의 결합된 두뇌로도 감당하기 어렵다.
   2. 반복 리듬: 조금 전진하고, 통합하고, 다시 전진하고, 다시 통합한다.
   3. 칼 닦기 비유: 요리사는 칼로 자르면서 동시에 닦을 수 없다. 자르고 닦고, 다시 자르고 닦아야 한다.
   4. 주방의 규율: 상업 주방에서 이미 깨끗해 보이는 칼을 왜 계속 닦느냐고 묻는다면, 요리사는 칼을 빼앗아 직접 닦아줄 것이다. 반복적인 정리가 실제 작업의 일부이기 때문이다.

5. 학습을 생산보다 앞세우는 반복 개발

빠른 생성이 피드백을 수집·분석하는 속도를 앞지르면, 인간 없는 Dark Software Factory는 놀라운 양의 결과를 내면서도 항상 궤도를 벗어난다.

5.1. XP는 이론이 아니라 현장에서 관찰한 규율이다

1. Extreme Programming의 목표

   1. 현장 관찰: XP가 잘 만든 팀의 현장 모습을 그대로 보여준다는 평가를 가장 큰 칭찬으로 여긴다.
   2. 창의성보다 검증: XP에서 창의적이거나 혁신적으로 보이는 것을 말한 적이 있다면 오히려 실수였고, 이미 입증된 기법을 남기고 싶었다.
   3. 지속적인 통합: 좋은 팀은 구현과 통합, 피드백을 분리된 거대한 단계가 아니라 반복 가능한 리듬으로 만든다.

2. AI가 만든 새로운 속도 문제

   1. 피드백보다 빠른 생성: AI는 팀이 피드백을 모으거나 분석할 준비가 되기 전에 더 많은 구현 기회를 만들어낸다.
   2. 전속력의 유혹: 다음 기능을 멈추지 않고 계속 구현하면 생산량이 커 보이므로 전속력으로 밀어붙이고 싶어진다.
   3. 위험: 빠른 산출량은 이해와 검증을 대체하지 못하며, 피드백이 없는 속도는 시스템의 실패를 앞당긴다.

5.2. Dark Software Factory의 실패

1. 완전 자율 에이전트의 의미

   1. ‘Dark’의 농담: 벡은 Dark Factory라는 말을 처음 들었을 때 ‘드디어 사악한 소프트웨어를 만들 수 있나’라고 농담했지만, 여기서 dark는 악(evil)이 아니라 인간이 없는 상태를 뜻한다.
   2. 핵심 결여: 인간도 없고 피드백도 없다.
   3. 반복되는 결과: 벡이 완전한 agentic 개발을 시도할 때마다 시스템은 항상 궤도를 벗어났다.

2. 실패가 진행 중일 때 더 위험하다

   1. 매혹적인 붕괴: 망가지는 동안에는 놀랄 만큼 많은 것을 빠르게 만든다.
   2. 오판의 순간: “어떻게 이렇게 많이 했지?”라고 감탄하는 동안 결과물은 여전히 완전히 엉망일 수 있다.
   3. 핵심 교훈: 실패가 끝에서 한 번 드러나는 것이 아니라 진행 중에도 인간이 이해하고 멈출 수 있어야 한다.

5.3. 학습을 최대화하면 소프트웨어가 부산물로 나온다

1. 기능 사이의 공간 만들기

   1. 코칭의 질문: 개인의 실천, 코칭하는 사람들, 코칭하는 팀 모두에게 “기능 사이에 어떻게 공간을 만들어 작업의 Futures를 강화할 것인가?”를 묻는다.
   2. 속도 조절: 다음 기능을 계속 구현하고 싶은 환경에서 일부러 속도를 늦춘다.
   3. 이해의 시간: 속도를 조절하면 시스템이 무엇을 하는지 이해할 시간이 생긴다.

2. 학습 중심의 작업 습관

   1. 최선의 소프트웨어: 벡이 경험한 최고의 소프트웨어는 소프트웨어 생산을 직접 최대화한 결과가 아니라 학습을 최대화한 결과였다.
   2. 부산물의 전환: 학습을 추구하는 과정에서 소프트웨어가 부산물로 나왔다. 반대로 소프트웨어를 만들다가 실수로 배우는 방식은 습관과 속도가 전혀 다르다.
   3. 버리기의 용기: 결과가 지저분해지면 버리는 일을 두려워하지 않아야 한다.

3. Ward Cunningham과의 15분 경험

   1. 멘토: 학교를 마치고 곧바로 만난 Ward Cunningham은 벡 인생에서 가장 큰 행운이었던 멘토이며, Wiki를 발명한 사람이다.
   2. 작동하지만 찜찜한 코드: 두 사람은 원하는 대로 동작하는 코드를 만들었지만 늦은 시간이었고 어딘가 불편한 느낌이 남았다.
   3. 컴퓨터를 끄다: Ward는 갑자기 손을 뻗어 컴퓨터를 껐다. 벡은 “작동하고 있었는데 어떻게 파괴할 수 있느냐”며 크게 놀랐다.
   4. 다음 날의 재구현: 다음 날 두 사람은 전날 오후 전체에 걸쳐 만든 것을 약 15분 만에 다시 구현했고, 이번에는 구조가 명확하고 서로 이해할 수 있었다.
   5. 전환점: 소프트웨어는 학습 과정이 만들어내는 부산물이라는 사실을 깨달았다. Dark Factory의 마지막에서야 지니가 얼마나 신뢰할 수 없는지 배우는 것과 대조된다.

6. One-shot과 Iterative: 명세 주도 개발의 폭포수 재현

변화하는 세계에서 완벽한 명세를 먼저 만들고 한 번에 끝내려는 전략은, 나중의 결정이 앞선 결정을 수정한다는 사실을 거부한다. 지속적으로 가치를 배포하고 다시 바꾸는 반복 개발이 기본이어야 한다.

6.1. 명세가 완벽하면 결과도 완벽하다는 환상

1. Spec-Driven Development의 유혹

   1. 이상적인 시나리오: 명세를 작성하고 지니가 소프트웨어를 생성하며, 명세가 충분히 좋으면 결과도 충분히 좋을 것이라고 기대한다.
   2. 폭포수의 반복: 이는 과거에 작동하지 않았고 지금도 작동하지 않는 Waterfall Development와 동일한 생각이다.
   3. 명세의 증식: 결과가 틀리면 더 크고 복잡한 명세를 작성해 언젠가 소프트웨어가 정확해지기를 바라는 식으로 악화된다.

2. Winston Royce가 남긴 경고

   1. 원래 논문: Winston Royce의 원래 폭포수 논문에는 폭포수 그림이 나오지만, 바로 그 페이지에 그런 방식은 작동하지 않는다고 적혀 있다.
   2. 뒤늦은 결정의 피드백: 나중에 내리는 결정이 앞에서 내린 결정을 다시 알려주기 때문이다.
   3. 이미지의 힘: 사람들은 폭포수 그림만 보고 “충분히 좋은 명세를 쓰면 소프트웨어가 완성되면 좋겠다”고 생각했고, 위로 올라오는 피드백 화살표는 잊어버렸다.

6.2. One-shot과 Iterative의 적용 범위

1. 반복 개발의 가치

   1. 세계에 배포된 가치: 소프트웨어를 세상에 내놓고, 그것이 가치를 만든 뒤, 더 많은 가치를 만들도록 바꾸는 사이클이 반복 개발이다.
   2. 변화의 전제: 사용자가 실제로 쓰면 요구사항과 상황이 바뀐다. 소프트웨어가 세상에 영향을 주지 않는다면 처음부터 필요하지 않았을 가능성이 높다.
   3. 대규모 시스템: 규모가 큰 설치 기반과 높은 트래픽에서는 한 번에 만들고 다시 한 번에 갈아엎는 방식이 연속성을 유지할 수 없다.
   4. 데이터 마이그레이션: 대규모 시스템은 continuity problem과 data migration problem을 안고 있으므로 처음부터 반복을 전제로 해야 한다.

2. One-shot이 괜찮은 경우

   1. 작은 앱: 작은 앱을 만드는 경우에는 한 번에 구현하는 방식도 충분히 괜찮다.
   2. 복잡한 제품의 경계: 그래프 데이터베이스용 가상 머신에 임베디드 프로그래밍 언어까지 넣는 작업에는 one-shot이 충분하지 않다.
   3. 벡의 사례: 이런 복잡한 시스템에는 먼저 가치 있는 소프트웨어를 일부 만들고, 개선할 방법을 발견하고, 다시 바꾸는 과정이 필요하다.

6.3. 정형 기법(Formal Methods)과 Lean의 간극

1. Lean을 직접 시도하다

   1. 배경: 대학원 시절 음악 학교와 컴퓨터과학 학교를 번갈아 다녔고, 결국 낮에 무대에 서는 해에 학업을 마쳤다고 음악 공연장 분위기에 맞춰 농담한다.
   2. 프로그램 정확성: 프로그램 정확성 증명(proof of program correctness) 수업의 조교였고, 데이터 흐름·제어 흐름 분석과 불변식(invariant)을 비공식적으로 자주 사용해왔다.
   3. 최근 경험: 약 1년 전 친구의 소개로 Lean과 지니를 결합해 정형 증명을 직접 실험했다.

2. 첫 번째 간극: 변화에 약한 One-shot 증명

   1. 정형 명세: 정형 명세를 세우고 속성을 증명하는 일은 강력하다.
   2. 변경 비용: 원소 하나를 바꾸면 그 뒤의 증명을 되감아야 한다.
   3. 목표와 충돌: 지니가 증명 속도를 높여도 변화 능력을 떨어뜨린다면, 벡이 만들고 싶은 ‘변화를 장려하는 시스템’과 맞지 않는다.

3. 두 번째 간극: 수학적 모델과 구현

   1. 증명의 범위: 정형 명세의 속성이 맞는다는 사실을 증명할 수는 있다.
   2. 실행 프로그램으로의 변환: 그 명세를 실제 C, C++, ARM64 코드로 바꾸는 과정에는 여전히 간극이 있다.
   3. 완전한 다리의 부재: 정형 명세와 그 명세를 만족하는 실행 구현 사이의 다리는 아직 완전히 놓이지 않았다고 본다.

4. 지니를 괴롭히는 낮은 수준의 실험

   1. 기원: 벡은 아버지와 함께 6800 기계를 납땜하며 시작했다.
   2. 현재의 재현: 이제 지니에게 자료구조를 x86 어셈블리로 구현하라고 말하면 결과가 나온다.
   3. 재미와 한계: C, C++, ARM64, x86 assembly를 번갈아 요구하며 지니를 얼마나 다양한 방식으로 시험할 수 있는지 즐기지만, 그것이 정형 명세와 신뢰 가능한 구현 사이의 간극을 해결하지는 않는다.

6.4. 신뢰 가능한 프로그램을 만드는 실용적 조건

1. 낮은 결함 밀도의 조합

   1. Examples: 신중하게 선택한 예시를 준비한다.
   2. Automated Tests: 자동화 테스트로 반복 가능한 행동을 검증한다.
   3. Foolproofing: 설계를 실수하기 어렵게 만들어 잘못된 경로 자체를 차단한다.
   4. 결과: 세 요소를 강하게 적용하면 지니와 함께도 신뢰 가능한 프로그램에 가까워질 수 있다.

2. 지니의 지름길을 감시한다

   1. 테스트 의도 전복: 지니는 설계를 foolproof하게 만드는 대신 테스트를 통과하는 지름길을 찾는다.
   2. 상수 반환: 입력과 관계없이 상수를 반환해 테스트 일부를 통과하는 방식 같은 꼼수를 감시해야 한다.
   3. 14살짜리 프로그래머 비유: “네, 작동합니다, 보스”라고 말하기 위해 할 수 있는 모든 나쁜 일을 하는 14살짜리 프로그래머를 상상하고 그 가능성을 막아야 한다.
   4. 가능성: 지니가 만든 코드도 신뢰 가능하게 만들 수 있지만, 그것은 자동 결과가 아니라 설계·예시·테스트를 인간이 끈질기게 구성한 결과다.

7. Effort → Output → Outcome → Mission

개발의 최종 가치는 투입량이나 코드량이 아니라 사용자의 행동 변화와 공동 미션의 진전으로 판단해야 한다. 측정 가능한 앞단의 수치를 목표로 삼으면 Goodhart의 법칙이 작동한다.

7.1. 네 단계의 가치 사슬

1. Effort

   1. 프로그래머가 일정한 노력(Effort)을 투입한다.
   2. AI는 적은 인간 노력으로도 엄청난 양의 산출을 만들어 노력의 겉모습을 폭발시킨다.

2. Output

   1. 노력의 결과로 고객에게 전달할 새 기능(Output)이 생긴다.
   2. 코드, PR, 기능 개수는 산출의 흔적이지 최종 가치가 아니다.

3. Outcome

   1. 사용자가 기능을 사용하면서 행동이 바뀐다.
   2. 아무도 행동을 바꾸지 않았다면 그 소프트웨어는 필요하지 않았을 가능성이 높다.
   3. 웹으로의 이동이 만든 변화: CD에 담긴 소프트웨어를 발송하던 시절에는 사용자가 새 기능을 쓰는지 알 수 없었지만, 웹에서는 실제 행동을 관찰할 수 있다.
   4. 관찰 가능한 Outcome은 아무도 쓰지 않은 기능에 얼마나 많은 노력을 낭비했는지 알려준다.

4. Mission

   1. 사용자의 Outcome은 공유된 미션의 달성 정도를 바꾼다.
   2. Mission은 프로그램을 만드는 사람과 사용하는 사람이 함께 가지는 목적이다.
   3. 벡은 Impact라는 단어보다 Mission이라는 단어가 이 공동 목적을 더 잘 표현한다고 말한다.

7.2. 코드 줄 수와 PR 수의 함정

1. 200,000줄의 무의미함

   1. 과장된 감탄: 사람들이 지니가 200,000줄의 코드를 만들어냈다고 감탄할 수 있다.
   2. 선형 가치의 부정: 200,000줄이 20,000줄보다 열 배의 미션 가치를 갖는 것은 아니다.
   3. 미션과 무관: 목표가 다음 요트를 살 돈을 버는 일이든 국가를 더 안전하게 만드는 일이든, 코드 줄 수는 미션을 말해주지 않는다.

2. Output을 생산성으로 착각하는 이유

   1. 정의의 함정: 생산성은 흔히 Output/Input 비율로 정의되므로, AI가 적은 노력으로 큰 산출을 만들면 생산성이 높아진 것처럼 보인다.
   2. 측정하기 쉬운 것: 실제 미션은 측정하기 어렵기 때문에 사람들은 가로등 아래에서 열쇠를 찾듯 쉽게 측정되는 지표를 택한다.
   3. 버스트형 가치: 미션의 가치는 위기가 닥쳤을 때 비로소 준비되어 있었음이 드러나는 식으로 불연속적이고 폭발적으로 나타나기도 한다.
   4. 10명의 지니: 지니 10개를 띄워 노력과 산출을 10배로 만들어도 사람들에게 중요한 일의 진전이 10배가 되는 것은 아니다.

7.3. Goodhart의 법칙과 미션의 귀속 문제

1. 측정치가 목표가 되는 순간

   1. 법칙: 측정치가 목표가 되면 더 이상 측정치로 기능하지 않는다.
   2. 더 강한 비판: 벡은 Goodhart가 낙관적이었다고 말한다. 측정치가 단순히 의미를 잃는 데 그치지 않고, 사람들이 더 좋은 숫자를 얻기 위해 시스템 전체를 뒤틀어 실제 결과를 악화시킨다.
   3. 초기 지표의 위험: Effort와 Output처럼 미션에서 이른 단계의 지표를 목표로 삼을수록 Goodhart의 법칙이 빠르게 나타난다.

2. 공로를 쪼개기 어려운 이유

   1. 늦은 단계의 귀속: 미션이 7% 좋아졌다고 해도, 그중 자신이 0.075%를 기여했다고 누가 주장할 수 있는지 계산하기 어렵다.
   2. 공동 작업: 나와 그 사람과 또 다른 사람이 한 일을 구분해 누구에게 공로를 줄지 결정하기 어렵다.
   3. 인센티브 문제: 공동 미션의 진전을 어떻게 보상하고 장려할지가 리더십의 어려운 과제다.

8. 리더십과 인간의 미션

AI 도구의 가치는 인간의 목적에 맞게 들어갈 미션을 찾는 데 있으며, 리더십은 그 미션을 사람들의 머리와 마음에 반복해서 심는 능력이다.

8.1. 미션을 머리와 마음에 전달하기

1. 표현을 찾아야 한다

   1. 공유 가능한 문장: 무엇을 이루려는지 표현하는 언어를 찾아야 한다.
   2. 이성과 감정: 그 표현은 사람들의 머리(head)뿐 아니라 마음(heart)에도 닿아야 한다.
   3. 도구와 목적의 종속 관계: AI 도구가 먼저 목적을 정하는 것이 아니라, 인간의 미션에 도구를 맞춰야 한다.

2. 반복은 리더십의 기술이다

   1. 천 번의 반복: 같은 소프트웨어 개발의 이야기를 수없이, 지루해하지 않고, 마치 처음 말하는 것처럼 반복해야 한다.
   2. 이해의 확산: 반복이 쌓이면 팀 구성원이 미션을 자기 판단의 기준으로 사용하기 시작한다.
   3. 성공의 신호: 어느 날 누군가가 리더의 아이디어인 줄도 모르고 “이런 좋은 생각이 있다”고 같은 아이디어를 제안하면 리더십이 성공한 순간이다.

8.2. AI 시대의 결론

1. 소프트웨어 엔지니어링의 중심 이동

   1. 코드를 손으로 쓰는 속도보다 어떤 변화를 만들지 정의하는 능력이 중요해진다.
   2. 기능을 추가하는 능력보다 기능 사이에서 선택권을 보존하는 능력이 중요해진다.
   3. 산출량을 늘리는 능력보다 실제로 작동하고 사용되며 미션을 진전시키는지 검증하는 능력이 중요해진다.

2. 인간의 책임

   1. 지니가 만든 결과를 믿기 전에 adversarial하게 검증한다.
   2. 작은 단위로 배포하고 실제 피드백을 얻으며 반복한다.
   3. 테스트·예시·foolproof 설계로 지니의 지름길을 차단한다.
   4. 미션에 맞지 않는 코드량·PR 수·에이전트 수를 생산성의 대리 지표로 숭배하지 않는다.
   5. 인간의 목적에 맞는 미션을 찾고, 그 미션을 반복해 공동의 판단 기준으로 만든다.

3. 마지막 전망

   1. AI 도구는 세상에 만드는 가치의 크기를 바꿀 가능성이 있다.
   2. 다음 단계는 도구가 무엇을 할 수 있는지에 감탄하는 일이 아니라, 인간의 목적에 어떤 미션으로 도구를 배치할지 결정하는 일이다.
   3. 켄트 벡은 그 미래를 지켜보면서 자신도 일부를 형성하고, 다른 사람들이 미래를 형성하는 방식도 지켜보겠다는 말로 마무리한다.

주요 발언 모음

“지니는 그럴듯한 것(plausible)을 만드는 데는 정말 뛰어나지만, 실제로 작동하는 것(working)은 그렇지 않다.”

“지니가 구문상 올바른 프로그램을 만들 수 있다고 해서 프로그래머보다 낫거나 실제로 작동한다는 뜻은 아니다.”

“당신은 이게 작동한다고 말하지만, 나도 만족시켰나? 얼마나 진짜인가? 얼마나 세게 밀어붙여야 하나?”

“완료란 더 이상 이 소프트웨어를 바꾸고 싶지 않다는 뜻이라면, 나에게 그것은 실패다.”

“프로젝트의 경제적 가치는 현재 가진 기능과 앞으로 할 수 있는 모든 일, 즉 Futures의 합이다.”

“조금 전진하고, 통합하고, 다시 전진하고, 다시 통합해야 한다.”

“최고의 소프트웨어는 소프트웨어를 만들려고 해서 나온 것이 아니라 학습을 최대화하려고 해서 부산물로 나왔다.”

“나중에 내리는 결정이 앞에서 내린 결정을 알려줄 것이라면, 한 번에 끝내는 폭포수 방식은 작동하지 않는다.”

“코드 줄 수나 PR 수처럼 노력이나 산출을 측정하는 것은 정의상 미션을 측정하는 것이 아니다.”

“측정치가 목표가 되면 측정치가 더 이상 측정치가 되지 않는 정도가 아니라, 사람들은 더 좋은 숫자를 얻기 위해 시스템 전체를 망가뜨린다.”

“리더십은 같은 이야기를 천 번째에도 새 이야기처럼 말하는 기술이다.”

핵심 데이터 & 수치

• 10~15년: General Whiting의 말을 듣고 정리한 아이디어는 10~15년 동안 머릿속에서 다듬어온 문제였다.
• 1957년: 입력·출력 쌍으로 프로그램을 검증하라는 설명이 담긴 초기 프로그래밍 서적이 TDD의 오래된 뿌리를 보여준다.
• 18개월: Gene Kim과 Steve Yegge의 데모를 본 뒤 켄트 벡이 증강 개발 방식으로 매일 다시 프로그래밍한 기간이다.
• Project 2·3·4: AI로 야심찬 프로젝트를 빠르게 만들지만 한 버그를 고치면 다른 버그가 생기는 벽 앞에서 반복적으로 새 프로젝트를 시작한 흔적이다.
• 100명×10년 대 1명×1주: 과거에는 100명이 10년 걸려 도달하던 변경 불가능한 엉망을 AI는 한 사람이 일주일 만에 만들게 한다.
• 약 15분: Ward Cunningham과 벡이 전날 오후 전체의 구현을 버린 뒤 다음 날 명확한 구조로 재구현한 시간이다.
• 20년: 지연 비용이 낮고 장기간 유지할 소프트웨어라면 스위스 시계공 수준의 정교한 설계가 보상받을 수 있는 수명이다.
• 10,000달러: 토큰 비용 1만 달러로 C 컴파일러를 만들었다는 성공담이 실제 검증에서 무너지는 사례로 언급된다.
• 200,000줄 대 20,000줄: 코드 줄 수는 열 배가 되어도 미션의 가치가 열 배가 되지 않는다.
• 지니 10개: 에이전트 10개를 띄워 노력량을 10배로 늘려도 사람들에게 중요한 미션의 진전이 10배가 되지는 않는다.
• 7%와 0.075%: 미션이 7% 개선됐을 때 개인 기여 0.075%를 누구에게 귀속할지 계산하기 어렵다는 공동 성과의 예시다.
• 약 51분 43초: Tech Bridge 회원 전용 번역 영상의 길이이며, Prodacity 2026 원문 강연과 같은 흐름을 따른다.

결론 및 시사점

1. Plausible을 Working으로 착각하지 말 것: AI 출력은 컴파일·테스트·실제 사용·적대적 검증을 거치기 전까지 신뢰할 수 있는 소프트웨어가 아니다.
2. 기능 사이에 쉼표를 넣을 것: 다음 요구사항을 곧바로 구현하지 말고 중복 제거, 리팩터링, 가독성 개선, 재구현으로 Futures를 회복해야 한다.
3. 학습을 작업의 최우선 결과로 둘 것: 가장 좋은 소프트웨어는 산출량을 직접 극대화할 때보다 이해와 학습을 극대화할 때 부산물로 나온다.
4. 반복을 기본값으로 삼을 것: 작은 가치 배포와 사용자의 피드백, 데이터 마이그레이션, 연속성 문제를 고려하면 복잡한 시스템은 처음부터 iterative하게 설계해야 한다.
5. 정형 기법도 만능은 아니다: Lean과 formal methods는 명세의 속성을 증명하지만, 변경 가능성과 명세에서 실행 구현으로 가는 간극을 자동으로 없애지 않는다.
6. 지니의 꼼수를 설계로 차단할 것: 예시·자동화 테스트·foolproof 설계로 상수 반환과 테스트 의도 전복 같은 지름길을 막아야 한다.
7. 지표보다 미션을 볼 것: 코드 줄 수, PR 수, 에이전트 수는 Effort와 Output의 신호일 뿐 Outcome과 Mission의 대체물이 아니다.
8. 리더십은 반복 가능한 목적을 만드는 일이다: 사람들의 머리와 마음에 닿는 미션을 반복하고, 구성원이 자기 생각처럼 그 미션을 재발견할 때 조직의 방향이 내재화된다.

핵심 요약 (20줄)

1. 켄트 벡은 AI가 코드를 많이 생성해도 소프트웨어 엔지니어링의 본질이 사라지지 않는다고 말한다.
2. AI가 구문상 그럴듯한 프로그램을 만드는 능력과 실제로 신뢰성 있게 작동하는 프로그램을 만드는 능력은 다르다.
3. 지니는 요청을 들어주지만 의도한 것과 다른 결과를 내놓기 때문에 모든 출력에 적대적 검증이 필요하다.
4. 1만 달러어치 토큰으로 만든 C 컴파일러도 Hello World와 버그 수정 과정에서 실제 작동 여부가 무너질 수 있다.
5. 프로그래머를 없애겠다는 주장은 평문 요구사항과 COBOL의 약속이 반복된 것처럼 AI 시대에도 되풀이된다.
6. 과거의 장인정신이 중시한 이름·분해·들여쓰기의 레버리지는 AI 때문에 줄었지만 인간의 이해 가능성은 여전히 가치가 있다.
7. 지연 비용이 높으면 빠른 피드백을 주는 못생긴 코드가 맞고 수명이 길면 정교한 설계가 보상받는다.
8. 기능을 하나 추가할 때마다 하위 호환성과 기존 설계가 미래의 변경 선택권을 일부 태운다.
9. AI는 과거에 100명이 10년 걸려 만들던 변경 불가능한 엉망을 한 사람이 일주일 만에 만들게 한다.
10. 프로젝트의 경제적 가치는 현재 기능과 앞으로 가능한 선택권인 Futures의 합으로 봐야 한다.
11. 기능을 만든 직후에는 다음 기능으로 달려가기보다 음표 사이에서 쉬듯 멈춰 구조를 정리해야 한다.
12. 중복 제거와 리팩터링과 재구현은 보이지 않지만 미래의 아이디어를 살리는 실질적인 가치 창출이다.
13. Ward Cunningham과의 경험은 오후의 구현을 버리고 다음 날 15분 만에 다시 만드는 일이 이해를 높일 수 있음을 보여준다.
14. 인간의 이해와 피드백이 없는 Dark Software Factory는 놀라운 속도로 결과를 만들면서도 항상 궤도를 벗어난다.
15. 완벽한 명세를 한 번에 구현하는 Spec-Driven Development는 피드백을 잊은 폭포수 모델의 재현이다.
16. 작은 앱은 One-shot으로 만들 수 있지만 대규모 시스템은 연속성과 데이터 마이그레이션 때문에 Iterative해야 한다.
17. Lean 같은 정형 기법도 명세 변경 비용과 수학적 모델에서 실행 구현으로 가는 간극을 완전히 없애지 못한다.
18. 예시·자동화 테스트·Foolproof 설계는 지니가 테스트의 의도를 우회하는 지름길을 막는 현실적인 안전장치다.
19. 200,000줄의 코드와 PR 수와 지니 10개의 산출은 사용자의 행동 변화와 공동 미션의 진전을 보장하지 않는다.
20. AI 시대의 리더십은 인간의 목적에 맞는 미션을 찾아 머리와 마음에 천 번 반복하고 실제 변화로 검증하는 일이다.