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

한 줄 핵심

AI 시대의 개발은 속도만 높이는 일이 아니라, 빠르게 기능을 만들되 그 사이사이에 설계와 학습을 통해 미래 변경 가능성을 회복하는 반복적 공정으로 재정의되어야 한다.

시간별 요약

1. 0:00
   경험의 출발점과 문제 제기 상업용 소프트웨어와 애자일·TDD·XP의 경험을 바탕으로, AI를 활용한 개발도 여전히 인간이 주도하는 공정이어야 한다는 관점을 제시한다. 질문을 즉시 던지고 답을 찾는 태도, 그리고 현업에서 축적된 문제 해결 감각이 오늘의 논의를 이끈다.
2. 7:01
   AI는 코드를 만들지만 신뢰를 보장하지 않는다 AI가 문법적으로 그럴듯한 코드를 빠르게 만들더라도 실제로는 동작하지 않거나 버그를 더 늘릴 수 있으므로, 결과물을 낙관적으로 믿어서는 안 된다. 프로그래머의 역할은 더 이상 코드를 생산하는 데만 있지 않고, 동작 보장과 검증을 통해 AI의 출력을 의심하고 걸러내는 데 있다.
3. 13:00
   craft의 의미는 바뀌지만 사라지지 않는다 예전의 craft는 세밀한 네이밍, 분해, 들여쓰기처럼 인간이 코드를 오래 읽고 이해하기 위한 미학에 가까웠지만, AI 시대에는 그 효용이 줄어든다. 대신 craft는 완성도를 늦추는 자기만족이 아니라, 적절한 시점에 불완전한 소프트웨어를 내놓고 피드백을 받되 시간이 중요한 상황에서는 빠르게 가치를 내는 판단으로 재정의된다.
4. 20:01
   기능과 미래 가능성의 균형 소프트웨어 가치는 현재 기능(features)과 다음 변경 가능성(futures)의 합이며, 기능을 추가할수록 미래의 선택지는 줄어든다. 따라서 매 기능 개발 후에는 리팩터링, 중복 제거, 재구현 같은 정리 시간을 의도적으로 넣어 미래 변경 가능성을 회복해야 한다.
5. 35:01
   일회성 명세보다 반복적 개발이 강하다 spec-driven development를 모든 문제의 해답처럼 보는 태도는 사실상 실패해 온 waterfall의 변형에 가깝다. 특히 큰 시스템과 대규모 사용자 기반에서는 한 번에 맞는 명세를 쓰는 것보다, 작은 변경을 반복하며 학습하고 조정하는 방식이 훨씬 현실적이다.
6. 44:01
   성과 측정은 코드량이 아니라 미션이어야 한다 코드 줄 수나 산출량은 노력의 지표일 뿐 미션의 성과를 말해주지 못한다. 진짜 중요한 것은 고객 행동 변화와 조직의 미션 달성도이며, 이를 위해서는 측정하기 쉬운 지표보다 실제 가치가 드러나는 결과를 추적해야 한다.

실무 인사이트

• AI를 도입한 개발팀은 '더 빨리 만들기'보다 '더 자주 멈춰서 검증하고 정리하기'를 프로세스에 명시해야 한다.
• 리팩터링과 설계 개선은 부가 작업이 아니라 미래 변경 비용을 낮추는 생산 활동으로 예산과 일정에 포함해야 한다.
• 성과 평가는 코드량, PR 수, 생성 속도 대신 실제 사용자 행동 변화와 미션 달성도에 연결해야 AI의 왜곡된 생산성을 피할 수 있다.