기능 사이에 쉬어라 — 켄트 벡이 말하는 AI 시대의 Features vs Futures

출처: 100명이 10년 걸리던 엉망을 AI로 혼자 1주일 만에 — JUnit 만든 켄트 벡이 말하는 '기능 사이에 멈추는 법' — AgentOS. 원본은 Kent Beck 의 Prodacity 2026 발표 Software Engineering in the Age of AI(Rise8). 영상의 내용을 기록으로 남겨두기 위해 블로그로 작성했다.

JUnit 을 만들고 TDD 와 XP 를 이끈 켄트 벡이 "이제 AI 가 사람보다 코딩을 잘한다"는 말에 정면으로 반대했다. 그의 결론은 한 문장이다 — AI 덕분에 우리는 고칠 수 없는 프로젝트에 훨씬 빨리 도착하게 됐다. 그럼 어떻게 해야 하나. 기능과 기능 사이에 멈추라는 게 그의 답이다.

켄트 벡은 발표 내내 AI 를 "지니(genie)"라고 부른다. 이 글도 그 표현을 따른다.

결론부터 — 그럴듯하지만 돌아가지 않는다

켄트 벡이 프로그래밍에서 가장 사랑한 건 빨강/초록의 이분법이다. 프로그램이 안 돈다, 버그를 고친다, 이제 돈다. 그런데 지니가 만드는 프로그램은 자주 그냥 안 돈다.

Genie is really good at plausible, but actually working, no.

토큰을 쏟아부어 C 컴파일러를 만들었다는 무용담도 파보면 "C 컴파일러스러운 것"이라고 그는 말한다. 버그 하나를 고치면 세 개가 새로 생기고, C 프로그램을 제대로 컴파일해서 돌리지 못한다. 문법적으로 맞는 코드를 만들어 낸다고 프로그래머보다 낫다거나, 그 코드가 돌아간다는 뜻은 아니다. "언젠가는 덜 틀린 말이 되겠지만, 오늘은 그냥 틀렸다."

크래프트 책은 이제 버려야 한다

켄트 벡은 발표 제목에 들어간 크래프트(craft) — 프로그래밍을 장인의 손기술처럼 다루는 태도 — 를 다룬 책을 적어도 세 권 썼고, 그 책들이 "이제 완전히 쓸모없으니 버려야 한다"고 말한다. 커리어 끝자락에 하기엔 이상한 말이라고 본인도 인정하면서.

신중한 이름 짓기, 작은 조각으로 쪼갠 로직, 들여쓰기와 공백, 사람이 읽기 좋은 구조 — 예전엔 이런 결정에 큰 레버리지가 있었다. 5년 뒤 누군가 그 코드를 읽고 안도하는 식으로. 지금은 그 레버리지가 예전 같지 않다. 지니가 설명해 줄 수 있으니까 — 거짓말을 안 한다면.

그래도 사람이 코드를 이해할 필요가 없다는 뜻은 아니다. 사람이 읽을 수 있는 시스템과 없는 시스템 중 고르라면 당연히 전자다. 다만 "인라인하고, 추출하고, 이름을 바꾸니 전부 명확해졌다"는 그 짜릿한 순간 자체에는 더 이상 보상이 없다는 게 그의 솔직한 고백이다.

Features vs Futures

이 발표의 핵심 그림이다. 한 축은 기능(features), 다른 축은 여지(futures) — 앞으로 바꿀 수 있는 선택지(optionality)다. 앞니가 하나 빠졌을 땐 둘 다 "퓨처스"로 발음돼서 최악의 이름이었다는 농담도 곁들인다.

• 시작할 때는 기능이 0 이고 여지는 넓다
• 기능을 하나 넣을 때마다 여지를 태운다. 하위 호환을 지켜야 하고, 마음에 안 들어 빼더라도 그 흔적이 다음 선택을 좁힌다
• 계속 태우다 보면 무엇도 바꿀 수 없는 여지 0 상태에 도착한다. 그러면 프로젝트 2, 3, 4 를 새로 시작한다

예전엔 100명이 10년 걸려 이 절대 영도에 도착했다. 이제 AI 로 나 혼자, 내 사무실에서, 1주일이면 된다.

생산성이 오른 건 맞다 — 고칠 수 없는 프로젝트에 도착하는 생산성이.

그는 프로젝트의 경제적 가치를 지금 가진 기능과 다음에 할 수 있는 것들의 선택지를 더한 것으로 본다. 그러니 기능을 넣지 않고 여지를 늘리는 것만으로도 가치를 더할 수 있다.

대안 — 음표 사이에서 쉬기

음대 시절 들은 파블로 카살스 이야기가 나온다. 첼로는 공기를 많이 움직이는, 체력이 필요한 악기다. 16분음표가 끝없이 이어지는 곡을 두고 누가 "그 많은 16분음표를 치면 지치지 않느냐"고 묻자 카살스가 답했다 — "음표 사이에서 쉰다." 빨리 치려고 애쓰던 클래식 기타 전공생에게 음표 사이라는 개념은 충격이었다고 한다. 정작 카살스는 그런 말을 한 적이 없다 — 지어낸 이야기인데 너무 좋아서 안 할 수가 없단다.

지니가 핑거건을 쏘며 "보스, 기능 끝냈습니다. 다음 거 할까요?" 하고 묻는 순간이 바로 음표 사이다. 여기서 숨을 고르고 "아직 아니다"라고 말할 수 있다.

• 중복을 제거한다
• 가독성을 위해 구조를 다듬는다
• 방금 만든 걸 버리고 다른 방식으로 다시 구현해 본다

이 왕복 — 기능을 넣고, 여지를 되찾고, 다시 기능을 넣는 — 이 그가 그리는 궤적이다.

기능은 보이고 여지는 안 보인다

이 균형이 어려운 이유는 가시성이다. 기능은 모두가 본다. 사용자도 원하고, 받으면 고마워한다. 여지는 장부에 안 잡힌다. "바꿀 수도 있고 안 바꿀 수도 있는 걸 왜 손봤냐, 그냥 다음 기능을 넣지" 소리를 듣는다.

지니가 끼면 이 긴장이 더 세진다. "다음 기능 해"라고 하면 정말 빨리, 대충 돌아가는 무언가가 나온다. 반면 "이건 나중에 바꾸기 쉬워야 한다"는 요구는 어떤 스펙에도 안 적혀 있다. 모두가 끝나는 프로젝트를 원한다.

나에게 "끝났다 — 더 이상 이 소프트웨어를 바꾸고 싶지 않다"는 실패다.

다크 팩토리는 매번 탈선한다

사람의 피드백 없이 에이전트가 끝까지 돌리는 걸 다크 소프트웨어 팩토리라고 부른다. 켄트 벡은 "드디어 사악한 소프트웨어를 짤 수 있나" 기대했는데 그런 뜻이 아니라서 실망했다고 한다. 그가 해본 다크 팩토리는 매번 탈선했다. 문제는 탈선하는 과정이 너무 재밌다는 것 — "와, 이걸 어떻게 이만큼이나 했지?" 하고 감탄하는데, 결과물은 여전히 쓰레기다.

지니는 우리가 피드백을 모으고 분석하는 속도보다 빨리 피드백 기회를 만든다. 그러니 전속력으로 달리게 두고 싶은 유혹이 생긴다. 그가 코칭하는 사람과 팀에게 던지는 질문은 결국 하나다 — 다음 기능, 다음 기능, 다음 기능의 유혹 속에서 기능 사이의 공간을 어떻게 만들 것인가.

워드 커닝엄이 컴퓨터를 끈 날

켄트 벡이 학교를 막 나왔을 때 멘토가 위키를 만든 워드 커닝엄이었다. 둘이서 오후 내내 짠 코드가 원하는 대로 돌긴 했는데, 뭔가 찜찜했다. 그때 워드가 손을 뻗어 컴퓨터를 꺼버렸다. 저장도 없이.

켄트 벡은 씩씩대며 퇴근했다. 다음 날 아침, 전날 오후 내내 한 걸 15분 만에 다시 구현했고 이번엔 완전히 명확했다. 이게 그의 전구가 켜진 순간이다.

최고의 소프트웨어는 학습을 극대화하려 했더니 부산물로 소프트웨어가 나온 경우였다.

학습을 극대화하려 하면 습관도 속도도 완전히 달라진다. 지저분해지면 버리는 걸 두려워하지 않는다. 다크 팩토리에서는 아무것도 배우지 못한다 — 마지막에 지니가 얼마나 못 믿을 존재인지 배우는 것 말고는. 그건 이미 아는데 왜 자꾸 다시 배워야 하는지 모르겠다고 그는 말한다.

스펙 주도 개발은 워터폴이다

스펙을 충분히 잘 쓰면 지니가 충분히 좋은 소프트웨어를 만들어 줄 거라는 기대 — 스펙 주도 개발(spec-driven development)의 유혹이다. 켄트 벡은 여기에 이미 이름이 있다고 말한다. 워터폴이고, 한 번도 통한 적이 없다.

워터폴의 원전인 Winston Royce 의 1970년 논문에는 폭포 그림 바로 그 페이지에 "물론 이건 안 된다, 나중의 결정이 앞의 결정에 영향을 주니까"라고 적혀 있다고 켄트 벡은 말한다. 그래서 다음 페이지에는 위로 거슬러 오르는 피드백 화살표가 있다. 그런데 사람들 머리에 남은 건 첫 그림이었다 — 스펙을 잘 쓰면 소프트웨어가 끝난다는 꿈. 그림 한 장의 힘이 그만큼 세니 설명할 때 조심해야 한다고 그는 덧붙인다.

원샷 개발과 반복(iterative) 개발의 구분이 AI 와 함께 다시 돌아왔다. 경험이 쌓이면 "이거 또 왔네" 하는 순간이 많다.

노력 → 산출물 → 성과 → 미션

켄트 벡이 이날 행사에서 다른 발표를 듣고 고쳐 그린 그림이다.

예전엔 그가 impact 라고 부르던 자리에 이번엔 mission 을 넣었다. 웹으로 넘어오면서 성과를 관찰할 수 있게 된 것만 해도 큰 진보였다 — CD 로 배포하던 시절엔 새 기능을 누가 쓰는지 알 길이 없었으니까.

"지니가 20만 줄을 만들었다"는 말은 노력의 측정이다. 미션과는 아무 상관이 없다. 20만 줄이 2만 줄의 10배 가치인 것도 아니다. 그런데 그게 제일 재기 쉬우니 우리는 가로등 밑에서 열쇠를 찾는다. 지니 10개를 띄우면 노력이 10배가 된다 — 그래서 뭐가 달라지나.

지표의 횡포 — 굿하트의 법칙

생산성의 정의가 입력 대비 출력이다 보니, 지니의 산출량을 생산성으로 착각하기 쉽다. 코드 줄 수는 오래전에 헛소리로 판명 났는데 PR 수라는 이름으로 다시 돌아왔다. 노력이나 산출물을 재는 지표는 정의상 미션의 지표가 아니다.

미션은 재기 어렵다. 그 가치는 몰아서 온다 — 위기가 터진 뒤에야 "준비돼 있었구나" 하고 알게 된다. 그리고 이 사슬의 앞쪽에서 잴수록 굿하트의 법칙에 걸리기 쉽다.

측정이 목표가 되면, 더 이상 좋은 측정이 아니다.

켄트 벡은 굿하트가 낙관주의자였다고 본다. 측정이 측정 노릇을 못 하는 정도가 아니라, 사람들은 더 좋은 숫자를 위해 시스템 전체를 비틀고 더 나쁘게 만든다. 가시성을 잃는 게 아니라 미션의 진척을 잃는다.

정리

• 지니는 그럴듯한 코드를 잘 만들지 돌아가는 코드를 보장하지 않는다. 빨강/초록 판정기가 없으면 그럴듯함을 걸러낼 수 없다
• 기능을 넣을 때마다 여지(futures)를 태운다. AI 는 "고칠 수 없는 프로젝트"에 도착하는 시간을 100명·10년에서 1명·1주일로 줄였다
• 해법은 기능 사이에 멈추는 것 — 리팩터링하고, 중복을 걷어내고, 필요하면 버리고 다시 짜서 여지를 되찾는다. 스펙만 잘 쓰면 된다는 생각은 워터폴의 재림이다
• 코드 줄 수·PR 수는 노력의 지표일 뿐 미션의 지표가 아니다. 앞단을 목표로 삼으면 굿하트의 법칙대로 시스템이 비틀린다

참고 자료

• Software Engineering in the Age of AI — Kent Beck, Prodacity 2026 원본 발표
• Goodhart's law