[한영자막] 켄트 벡이 밝히는 AI 시대의 소프트웨어 엔지니어링, 진짜 개발의 본질은 무엇일까요?

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

켄트 벡이 말하는 AI 시대 소프트웨어 엔지니어링의 본질은 인간의 판단과 피드백으로 작동하는 기능을 검증하고, 미래의 변경 가능성을 지키며 사용자의 목적을 달성하는 것이다.

📌 핵심 요점

1. 그럴듯한 코드와 신뢰할 수 있는 소프트웨어는 다르다. AI가 문법적으로 올바른 코드를 생성해도 실제 동작은 별도로 검증해야 한다. 자동화 테스트와 실수를 막는 설계를 함께 적용하고, 테스트를 편법으로 통과하는 구현도 확인해야 한다.
2. 프로젝트의 가치는 현재 기능과 미래 선택지의 합이다. 기능을 추가하면 하위 호환성과 기존 구조가 다음 변경을 제약한다. AI는 구현을 가속하지만, 변경할 수 없는 구조에 도달하는 시간도 줄일 수 있다.
3. 기능 구현과 구조 정비를 번갈아 수행해야 한다. 기능 사이에 리팩터링, 중복 제거, 가독성 개선과 재구현을 배치하면 변경 가능성을 회복할 수 있다. 벡은 인간의 피드백 없는 자율 개발보다 학습을 축적하는 반복을 강조한다.
4. 장인정신에 대한 투자는 지연 비용과 사용 기간에 맞춰야 한다. 지연 비용이 높으면 빠르게 프로그램을 내놓고 피드백을 얻는 편이 적절하다. 오래 사용할 소프트웨어이고 지연 비용이 낮다면 세부 구조를 정교하게 다듬는 노력이 보상받을 수 있다.
5. 개발 성과는 코드량에서 사용자 행동과 공동의 목적까지 연결해야 한다. 코드 줄 수와 PR 수는 산출물 지표다. 기능이 사용자의 행동을 바꾸고 미션 달성에 기여했는지 살펴야 하며, 수치 자체를 목표로 삼으면 시스템을 왜곡할 수 있다.

🧩 배경과 문제 정의

• 켄트 벡의 경험은 주로 상업용 소프트웨어 개발에 있지만, 군·정부 영역에서도 개발을 둘러싼 제약에는 공통점이 있다.
• AI가 문법적으로 올바르고 그럴듯한 코드를 생성하는 능력과, 실제로 작동하는 소프트웨어를 만드는 능력은 구별해야 한다. 생성 결과의 신뢰성을 검증하는 인간의 판단이 여전히 필요하다.
• AI로 기능 구현이 빨라질수록 변경 가능성을 소진하는 속도도 빨라진다. 개발의 핵심 문제는 현재 기능과 미래에 가능한 변경 사이의 투자 균형이며, 장인정신의 의미도 이 관점에서 달라진다.

🕒 시간순 섹션별 상세정리

1. 개발 영역의 공통 제약과 질문의 역할

• 상업용 소프트웨어 개발과 군·정부 분야는 관심사가 다르지만, 벡이 현장에서 접한 제약에는 상당한 공통점이 있다. [00:28]
• 질문은 여러 사람이 공유하지만 드러내지 못한 혼란을 해소하는 리더십이다. 대학 이산수학 수업에서 한 학생의 질문으로 모두가 이해하지 못하고 있다는 사실이 드러났고, 학생들은 교수에게 기존 설명을 다시 짚어 달라고 요구했다. [02:24]

2. 테스트 중심 개발의 뿌리와 기술·사회의 접점

• 벡은 소프트웨어 개발에 패턴 사고를 도입하는 데 기여했고, JUnit의 초기 아이디어를 만든 뒤 에리히 감마와 함께 다듬었다. [03:35]
• 사용자에게 도메인의 입력·출력 쌍을 받아 프로그램이 이를 만족하는지 확인하는 방식은 1957년 책에도 등장한다. 벡은 이를 TDD의 형태로 보며, 자신의 역할을 발명보다는 재발견과 개선으로 이해한다. [04:24]

3. 증강 개발에서도 인간의 판단이 중심에 남는다

• 벡이 사용하는 ‘증강 개발’이라는 표현에는 개발이 여전히 인간의 과정이라는 전제가 있다. 적어도 현재까지는 AI가 내리는 결정에 인간이 보탤 것이 많다. [06:23]
• AI를 ‘지니’라고 부르는 이유는 요청을 들어주더라도 결과가 실제로 원하던 것과 어긋날 수 있기 때문이다. 처음에는 인상적인 결과처럼 보여도, 최종적으로는 실망이 남는 관계를 염두에 둬야 한다. [06:44]

4. 그럴듯한 코드와 작동하는 프로그램은 다르다

• 문법적으로 올바른 프로그램을 생성한다는 사실만으로 AI가 인간보다 코딩을 잘하거나 결과물이 실제로 작동한다고 판단할 수는 없다. AI는 그럴듯함에는 강하지만, 증강 개발로 얻은 프로그램이 작동하지 않는 경우도 많다. [07:55]
• 벡이 비판하는 ‘토큰 비용 1만 달러로 만든 C 컴파일러’ 사례에서는 Hello World조차 작동하지 않거나, 버그 하나를 고칠 때 새 버그 세 개가 생기는 문제가 있었다. 컴파일러의 기준은 C 프로그램을 효율적으로 컴파일하고 그 결과가 실행되는지에 있어야 한다. [08:51]

5. AI가 만든 소프트웨어의 신뢰성은 직접 검증해야 한다

• 컴퓨터가 프로그래머를 대체했다는 주장은 현재 사실이 아니라는 것이 벡의 판단이다. 언젠가는 그 주장이 덜 틀릴 수 있지만, 지금의 개발자·관리자·구매자는 AI가 많이 개입한 소프트웨어에 비판적으로 접근해야 한다. [09:50]
• 개발자는 구조적으로 올바른 동작을 보장하거나 특정 종류의 버그를 불가능하게 만드는 방법을 사용해 왔다. 벡은 AI가 그런 방법을 갖췄다고 볼 수 없으므로, 기존에 코드에서 추론하던 신뢰성을 생성 결과에 그대로 가정해서는 안 된다고 본다. [10:49]

6. 프로그래머 대체 기대는 반복되어 왔다

• 업무 담당자가 자연어로 요구사항을 말하면 컴퓨터가 처리해 프로그래머가 필요 없어질 것이라는 기대는 새로운 현상이 아니다. 벡은 이를 COBOL의 구상과 연결하며, 현재를 같은 기대가 반복되는 다음 주기로 본다. [11:18]
• 코칭의 필요성도 남는다. 젊은 엔지니어는 여전히 비슷한 실수를 반복하며, 자신의 어려움이 특별하거나 혼자만의 문제가 아니라는 경험자의 설명은 압도감을 줄여 준다. [12:29]

7. 세부 코드 정리에 담긴 장인정신의 효용이 달라진다

• 벡은 프로그래밍에 온전히 자신을 담는 방법을 다룬 자신의 책 최소 세 권을 이제는 시대에 뒤처졌다고 평가한다. 신중한 이름 짓기, 작은 단위로 논리 분해하기, 들여쓰기와 공백, 사람이 이해하기 쉬운 구조가 기존 장인정신의 주요 표현이었다. [13:17]
• 이런 선택은 오랜 시간이 지난 뒤에도 코드를 이해할 수 있게 만드는 효과가 있었지만, 현재는 예전과 같은 영향력을 갖지 못한다. 그렇더라도 벡은 사람이 읽고 이해할 수 있는 시스템을 여전히 선호한다. [14:25]

8. 장인정신의 투자 수준은 지연 비용에 따라 달라진다

• 벡은 개발자가 외부와 단절된 채 자신의 만족을 위해 완성을 미루는 태도에 반대한다. 개인의 프로그래밍 경험만으로 작업 시간의 중요성을 밀어낼 수는 없다. [16:06]
• 지연 비용이 높다면, 다듬어지지 않았더라도 피드백을 얻을 수 있는 프로그램을 빠르게 내놓는 것이 적절하다. [16:45]

9. AI는 도전의 범위를 넓히지만 완성을 보장하지 않는다

• 벡은 약 18개월 동안 증강 개발로 매일 적극적으로 프로그래밍해 왔다. AI 덕분에 자신의 기술만으로는 감당하기 어려웠던 큰 프로젝트에 도전하고 상당한 진전을 만들 수 있었다. [18:22]
• 진전이 곧 완성은 아니었다. 버그 하나를 고치면 다른 부분이 깨지는 지점에 반복해서 도달했고, 기존 프로젝트를 끝내지 못한 채 이름에 2·3·4를 붙인 새 프로젝트로 다시 시작했다. [19:02]

10. 기능을 추가할수록 미래의 변경 선택지가 소진된다

• 기능 구현은 처음에는 빠르게 진행되지만 점차 느려진다. 이 변화를 이해하려면 현재 기능뿐 아니라 앞으로 무엇을 할 수 있는지, 즉 선택 가능성이나 ‘미래’를 함께 봐야 한다. [20:14]
• 시작할 때는 기능이 없는 대신 가능한 선택지가 많다. 기능 하나를 구현하면 다음 기능에서 하위 호환성을 유지해야 하거나, 기존 기능을 제거하는 작업이 필요해지는 등 이후 선택에 제약이 생긴다. [20:58]

11. AI는 변경 불가능한 상태에 도달하는 시간도 줄인다

• 벡은 과거에는 100명이 10년에 걸쳐 만들던 변경 불가능한 혼란을 이제 혼자 사무실에서 일주일 만에 만들 수 있다고 풍자한다. 적은 투자로 기능을 빠르게 쌓는 생산성이 유지·변경 가능한 결과를 보장하지는 않는다. [22:02]

12. 기능 사이의 멈춤이 변경 가능성을 회복한다

• 첫 기능을 구현하면서 일부 선택지를 소진하는 것은 피할 수 없지만, 다음 기능으로 바로 넘어갈 필요는 없다. 한숨 돌리는 시간을 통해 잃었던 변경 가능성을 되찾고, 경우에 따라 이전보다 더 늘릴 수도 있다. [24:02]
• 기존 코드 리팩터링, 중복 제거, 가독성 개선, 방금 만든 구현을 버리고 다른 방식으로 다시 만드는 작업은 기능 사이에 할 수 있는 구체적인 선택이다. [24:39]

13. 프로젝트의 가치는 현재 기능과 미래 선택지의 합이다

• 프로젝트의 경제적 가치는 현재 제공하는 기능과 앞으로 할 수 있는 일의 선택지를 합친 것으로 해석할 수 있다. 따라서 새로운 기능을 추가하지 않아도 미래 선택지를 늘리는 작업으로 가치를 높일 수 있다. [25:09]
• 기능 추가는 사용자가 바로 확인할 수 있지만, 나중에 필요할 수도 있는 변경을 가능하게 만드는 가치는 설명하기 어렵다. 이 때문에 구조 개선은 불필요한 치장처럼 보이기 쉽지만, 기능만 계속 추가하면 변경 가능성이 소진된다. [25:48]

14. 빠른 구현과 미래를 위한 투자의 긴장이 커진다

• AI가 개입하면 개발 시간과 투자 판단의 주기가 짧아진다. 다음 기능을 요청하면 아주 빠르게 얻을 수 있지만, 그 결과는 원하는 기능과 비슷하고 대체로 작동하는 수준일 수도 있다. [26:55]
• 오류의 원인을 제거하고 미래 변경을 쉽게 만드는 작업은 성과를 설명하기 어렵다. 명세에는 이런 요구가 잘 담기지 않고, 사람들은 대체로 완성되는 프로젝트를 원한다. [27:17]

15. 기능 구현과 구조 정비를 번갈아 수행한다

• 긴 시간 범위에서 보면 기능과 선택지가 함께 늘어나는 것처럼 보이지만, 실제 작업에서는 둘을 번갈아 개선하는 과정이 필요하다. [28:19]
• 기능과 선택지를 동시에 늘리려는 문제는 인간과 AI의 역량을 합쳐도 감당하기 어렵다는 것이 벡의 판단이다. 기능에서 진전을 만든 뒤 구조를 정비하고, 다시 진전과 정비를 반복하는 전략이 더 효과적이다. [28:37]

16. AI의 구현 속도에 맞춰 인간의 피드백을 확보해야 한다

• 익스트림 프로그래밍에서는 새로움보다 검증된 기법을 우선했다. 이제 AI는 사람이 피드백을 수집하고 분석할 준비를 마치기 전에 더 많은 피드백 기회를 만들어낼 만큼 빠르게 작업한다. [30:00]
• 인간의 개입과 피드백이 없는 완전 자율 개발은 벡의 경험에서 매번 궤도를 벗어났다. 결과물의 양과 생성 과정이 놀라워도 결과의 품질까지 보장하지는 않는다. [30:41]

17. 학습을 최대화하면 소프트웨어는 그 결과로 만들어진다

• 벡이 경험한 가장 좋은 소프트웨어는 학습을 최대화하는 과정에서 만들어졌다. 학습을 목표로 삼으면 작업 습관과 속도가 달라지고, 코드가 지저분해졌을 때 버리는 것도 두려워하지 않게 된다. [32:20]
• 워드 커닝햄과 오후 내내 만든 코드를 버린 뒤, 다음 날 같은 내용을 약 15분 만에 다시 구현했다. 두 번째 구현은 명확했고, 두 사람 모두 코드를 이해할 수 있었다. [33:47]

18. 완벽한 명세로 한 번에 완성하려는 기대는 폭포수 개발을 반복한다

• 좋은 명세를 작성하면 AI가 좋은 소프트웨어를 한 번에 만들어줄 것이라는 기대는 폭포수 개발과 같은 구조를 갖는다. 벡은 이 방식이 과거에도 작동하지 않았다고 본다. [35:25]
• 윈스턴 로이스의 원래 논문에는 뒤에서 내린 결정이 앞선 결정에 영향을 주므로 단방향 과정이 작동하지 않는다는 설명과 역방향 피드백 도식이 있었다. 그러나 폭포수 그림의 인상이 강해, 충분한 명세만으로 개발을 끝낼 수 있다는 기대가 남았다. [35:54]

19. 형식적 증명에는 변경 비용과 구현 사이의 간극이 남는다

• 프로그램 정확성 증명에서 익힌 사고방식은 데이터 흐름·제어 흐름 분석과 불변조건 정의에 비형식적으로 활용할 수 있다. 벡은 약 1년 전 친구의 소개로 Lean과 AI를 이용한 형식적 증명도 시도했다. [37:14]
• 형식적 명세의 속성을 증명한 뒤 요소 하나를 변경하면 증명 작업을 되돌려야 한다. AI가 이를 빠르게 해주더라도 변경에 부담이 남으며, 이는 변경을 장려하는 시스템을 만들려는 목표와 충돌한다. [37:48]

20. 신뢰할 수 있는 소프트웨어에는 테스트와 실수를 막는 설계가 필요하다

• 신중하게 고른 예제와 자동화 테스트, 실수가 발생하기 어렵게 만드는 설계를 함께 적용하면 결함 밀도를 낮추고 신뢰할 수 있는 소프트웨어를 만들 수 있다. [40:23]
• AI는 설계를 견고하게 만드는 대신 지름길을 택하거나 테스트의 의도를 무력화할 수 있다. 상수를 반환해 테스트를 통과시키는 등의 편법을 살펴야 하며, 이런 점검을 전제로 AI와도 신뢰할 수 있는 프로그램을 작성할 수 있다. [40:48]

21. 복잡한 운영 시스템은 배포된 가치를 반복해서 개선해야 한다

• 반복 개발은 실제 환경에 배포한 소프트웨어의 가치를 변경을 통해 높여가는 방식이다. 명세를 계속 확대해 한 번에 정확한 결과를 얻으려는 방식과는 작업의 출발점이 다르다. [41:31]
• 작은 앱에는 한 번에 만드는 방식이 적합할 수 있다. 반면 벡이 개발 중인 내장 프로그래밍 언어를 갖춘 그래프 데이터베이스용 가상 머신은, 이미 있는 가치에서 개선점을 찾아가는 과정이 필요하다. [42:12]

22. 개발 산출물의 다음 단계는 사용자의 행동 변화다

• 개발자가 노력을 투입해 고객에게 전달할 기능을 만드는 단계에서 기능은 산출물에 해당한다. [44:01]
• 고객이 기능을 사용하면서 행동이 달라지는 것이 결과다. 소프트웨어가 누구의 행동에도 변화를 만들지 못했다면, 그 소프트웨어를 만들 필요가 없었다는 판단이 가능하다. [44:24]

23. 공동의 목적 달성은 코드량으로 평가할 수 없다

• 사용자의 행동 변화는 소프트웨어 제작자와 사용자가 공유하는 목적, 즉 미션의 달성으로 이어져야 한다. 개발의 가치는 이 공동의 목적에 얼마나 기여했는지까지 연결해 살펴야 한다. [45:20]
• AI가 코드 20만 줄을 생성했다는 수치는 미션 달성 여부와 무관하다. 미션의 관점에서 20만 줄이 2만 줄보다 열 배의 가치를 뜻하지도 않지만, 측정하기 쉽다는 이유로 이런 수치에 관심이 쏠린다. [45:55]

24. 산출량 중심의 생산성은 실제 가치와 어긋날 수 있다

• AI는 적은 노력으로 많은 산출물을 만들기 때문에 생산성이 높아 보인다. 그러나 코드 줄 수나 PR 수처럼 노력 또는 산출물을 세는 지표는 미션을 측정하는 지표가 아니다. [46:48]
• 미션의 가치는 측정하기 어렵고 불연속적으로 드러나기도 한다. 위기가 발생한 뒤에야 그 위기에 대응할 준비가 되어 있었다는 가치를 확인할 수 있지만, 실제로 중요한 것은 이런 수준의 성과다. [47:36]

25. 지표를 목표로 삼으면 시스템과 미션의 진전을 해칠 수 있다

• 노력과 산출물처럼 과정의 앞부분을 측정할수록 굿하트의 법칙에 노출되기 쉽다. 지표가 목표가 되면 측정 기능을 잃는 데 그치지 않고, 사람들이 수치를 개선하려고 시스템 전체를 왜곡해 미션의 진전을 해칠 수 있다. [48:24]
• 미션에 가까운 성과를 측정할수록 각 개인의 기여를 구분하기는 어려워진다. 공동의 성과에서 누구에게 얼마만큼의 공을 돌릴지 판단하기 어렵다는 점이 미션의 진전을 장려하는 보상 설계의 과제로 남는다. [49:09]

26. 리더십은 공동의 목적을 반복해서 전달하고 사람들의 것으로 만드는 일이다

• 미션은 사람들의 이성과 감정 모두에 닿는 표현을 가져야 한다. 소프트웨어 개발이 어떤 모습이 될 수 있는지 같은 이야기를 지루해하지 않고 반복하는 능력이 리더십의 일부다. [50:07]
• 누군가 그 생각을 자신의 새로운 아이디어로 받아들여 원래 제안자에게 공을 돌리지 않더라도, 그 순간은 리더로서 성공한 순간일 수 있다. 생각이 다른 사람의 것으로 자리 잡았기 때문이다. [50:48]

🧾 결론

• AI가 개발자의 도전 범위를 넓혀도 완성과 신뢰성을 보장하지는 않는다. 생성 결과를 평가하고 다음 작업을 판단하는 인간의 역할이 남는다.
• 구조 개선은 미래에 구현할 수 있는 기능의 범위를 넓히는 투자다. 새 기능이 없어도 프로젝트의 경제적 가치를 높일 수 있다.
• 벡의 접근에서 좋은 소프트웨어는 피드백과 학습을 반복하며 만들어진다. 완벽한 명세로 한 번에 끝내려는 기대는 복잡한 시스템의 변경 과정을 충분히 반영하기 어렵다.

📈 투자·시사 포인트

• AI 개발 도구의 효용을 평가할 때 생성 속도와 함께 실제 동작, 결함, 유지·변경 가능성을 확인해야 한다. 적은 노력으로 많은 코드를 얻었다는 사실만으로 가치 창출을 판단하기 어렵다.
• 개발 자원은 다음 기능과 미래 변경 가능성에 나눠 배분해야 한다. 지연 비용과 예상 사용 기간이 구조 정비에 얼마나 투자할지 판단하는 기준이 된다.
• 사용자와 트래픽이 큰 서비스에서는 반복적인 개선을 전제로 접근필요가 있다. 매번 새로 생성하는 방식은 서비스 연속성과 데이터 마이그레이션 문제를 동반한다.
• 조직의 성과 지표와 보상 설계는 사용자 행동 변화와 공동의 목적에 가까워져야 한다. 다만 공동 성과에서 개인별 기여를 구분하기 어렵다는 과제도 함께 고려해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• AI가 개입한 프로그램의 실패와 완전 자율 개발의 이탈은 벡의 경험과 판단으로 제시된다. 제공된 자료에는 모델별·프로젝트별 비교 조건이나 실패율이 없어 모든 개발 환경으로 일반화하기 어렵다.
• 토큰 비용 1만 달러의 C 컴파일러 사례는 벡의 비판을 통해 소개된다. 해당 구현의 버전, 테스트 조건과 후속 수정 여부는 제공된 자료만으로 확인할 수 없다.
• 형식적 명세와 실행 구현 사이의 간극이 해소되지 않았다는 설명은 벡이 파악한 범위에 한정된다. 형식적 증명 도구 전반의 한계로 단정하려면 추가 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• AI가 구현한 기능마다 기대하는 입력·출력과 실제 실행 결과를 확인하고, 자동화 테스트를 편법으로 통과하는 코드가 있는지 검토한다.
• 기능 하나를 완료한 뒤 다음 기능에 착수하기 전에 중복, 이해하기 어려운 구조와 변경 제약을 점검하고 필요한 정비를 수행한다.
• 지연 비용과 예상 사용 기간을 적어 빠른 피드백 확보와 세부 구조 개선 중 어디에 우선 투자할지 결정한다.
• 작은 변경을 실제 사용 환경에 전달하고, 사용자의 행동을 관찰해 다음 구현과 구조 개선에 반영한다.

❓ 열린 질문

• 기능 추가와 변경 가능성 회복 사이의 투자 균형을 팀은 어떤 신호로 판단할 수 있을까?
• AI의 구현 속도에 맞춰 인간이 이해하고 피드백할 시간을 어떻게 확보할 수 있을까?
• 측정하기 어려운 미션의 성과를 장려하면서 개인별 기여도 공정하게 평가하려면 보상을 어떻게 설계해야 할까?