📺 영상 요약 아카이브
← 목록

100명이 10년 걸리던 엉망을 AI로 혼자 1주일 만에 — JUnit 만든 켄트 벡이 말하는 '기능 사이에 멈추는 법'

AgentOS · 2026-10-08 18:55 · 33:08

한 줄 핵심

AI가 코드를 빠르게 만들어도 그 결과는 대개 ‘작동하는 소프트웨어’가 아니라 ‘그럴듯한 산출물’이므로, 기능을 쌓는 속도보다 기능 사이에서 배우고 되돌릴 여지를 남기는 개발 방식이 더 중요하다는 주장이다.

시간별 요약

  1. 0:00
    인트로 — AI가 사람보다 코딩을 잘한다? 도입부에서는 AI가 사람보다 코딩을 잘한다는 인식에 의문을 제기하며, 이 영상이 그런 주장에 반대하는 관점에서 전개된다는 점을 암시한다.
  2. 1:15
    그럴듯하지만 돌아가지 않는 C 컴파일러 겉보기에는 문법적으로 맞아 보이지만 실제로는 제대로 동작하지 않는 결과물을 AI가 자주 만들어낸다는 점이 핵심이다. 진짜 기준은 그럴듯함이 아니라 C 프로그램을 효율적으로 컴파일해 실제로 실행되느냐에 있다.
  3. 4:12
    크래프트 책은 이제 버려야 한다 과거에 중요했던 세심한 이름 짓기, 분해, 들여쓰기, 가독성 최적화 같은 크래프트의 결정들은 이제 예전만큼 큰 효과를 내지 못한다. 다만 인간이 코드를 이해하는 능력 자체는 여전히 중요하고, AI가 설명해 주는 맥락 속에서 더 빠르게 이해할 수 있다.
  4. 7:45
    기능과 여지(Features vs Futures) 그래프 소프트웨어 발전은 기능을 추가할수록 미래의 선택지와 변경 가능성을 소모하는 방향으로 진행된다. AI를 쓰면 한 사람이 짧은 시간 안에 프로젝트를 완성 불가능한 상태까지 밀어붙일 수 있을 만큼 속도가 빨라진다.
  5. 11:27
    대안은? 음표 사이에서 쉬기 기능 하나를 끝낸 뒤 다음 기능으로 곧장 가는 대신, 그 사이에 멈춰서 리팩터링과 중복 제거, 가독성 개선, 재구현을 할 수 있어야 한다. 이 중간 구간이 현재의 기능뿐 아니라 앞으로의 선택지에도 가치를 더하는 핵심 시점이다.
  6. 14:58
    기능은 보이고 여지는 안 보인다 — 완성은 실패 기능 추가는 눈에 잘 보이지만 미래의 변경 가능성, 즉 여지를 키우는 일은 잘 드러나지 않는다. 그래서 ‘완성’만을 목표로 하면 미래에 바꾸기 어려운 소프트웨어를 만들게 되며, 그 관점에서는 완성 자체가 실패가 될 수 있다.
  7. 17:38
    다크 팩토리는 매번 탈선한다 인간의 개입과 피드백 없이 AI가 계속 달리는 완전 자율형 개발은 거의 항상 탈선한다. 결과가 흥미롭고 빠르게 나오더라도, 그 과정에서 학습이 없으면 결국 신뢰할 수 없는 산출물만 남는다.
  8. 20:07
    워드 커닝엄이 컴퓨터를 끈 날 좋은 소프트웨어는 산출물을 최대화하는 과정이 아니라 학습을 최대화한 결과로 나온다. 한 번은 완성 직전처럼 보이던 코드를 과감히 지우고 다음 날 다시 구현했을 때 오히려 더 명확하고 이해 가능한 결과가 나온 경험이 이를 보여준다.
  9. 22:57
    스펙 주도 개발은 워터폴이다 정교한 스펙을 먼저 쓰고 AI가 소프트웨어를 만들어 주면 된다는 발상은 사실상 워터폴과 다르지 않다. 나중의 결정이 앞선 결정을 바꾸기 때문에, 한 번에 끝내려는 방식보다 반복적 개발이 본질적으로 더 맞다.
  10. 25:30
    노력 → 산출물 → 성과 → 미션 개발의 가치는 노력이나 산출물이 아니라, 실제 사용자 행동 변화와 그것이 조직의 미션 성취로 이어지는지에 있다. 웹 환경처럼 결과를 관찰할 수 있을 때만 출력이 아니라 성과를 기준으로 개발을 평가할 수 있다.
  11. 28:52
    지표의 횡포 — 굿하트의 법칙 lines of code, PR count처럼 쉽게 측정되는 값은 노력이나 출력의 지표일 뿐 미션의 지표가 아니다. 측정하기 쉬운 것을 목표로 삼는 순간 시스템이 왜곡되고, 실제로 중요한 미션 달성은 더 멀어진다.
  12. 32:21
    마무리 마지막은 앞선 논지를 정리하며, AI 시대일수록 속도보다 학습, 출력보다 미래의 변경 가능성, 측정 가능한 지표보다 미션을 우선해야 한다는 메시지로 닫는다.

실무 인사이트

  • AI 코딩 도입 시에는 ‘얼마나 빨리 만들었는가’보다 ‘중간에 멈춰서 되돌아보고 고칠 수 있는가’를 팀 규칙으로 넣는 것이 효과적이다.
  • 스펙을 길게 쓰는 것보다 짧은 단위로 구현·검증·리팩터링을 반복하는 흐름이 AI 시대의 개발 품질을 더 잘 지킨다.
  • 활동 지표를 KPI로 삼기보다 사용자 행동 변화와 미션 성과를 함께 보지 않으면, AI가 만든 높은 생산성이 오히려 왜곡된 최적화를 부를 수 있다.