AI 코딩은 빨리 만드는 것보다 씨앗을 지키는 일이 먼저입니다

AI 코딩 도구를 쓰면 코드가 빠르게 나옵니다. 그래서 처음에는 생산성이 크게 오른 것처럼 느껴집니다. 하지만 코드가 빨리 나온다는 사실만으로 좋은 개발이 되는 것은 아닙니다.

Kent Beck은 마구잡이로 AI 코딩을 하다 보면 코드가 점점 엉키고, 나중에는 더 이상 기능을 붙이기 어려운 상태가 될 수 있다고 봅니다. 그는 이 상황을 “씨앗을 먹는 것”에 비유합니다.

농부가 당장 배고프다고 다음 수확을 위해 남겨야 할 씨앗까지 먹어버리면, 가을에 거둘 것이 없어집니다. 코드도 비슷합니다. 당장 돌아가게 만드는 데만 집중하면 미래에 확장하고 고칠 수 있는 기반을 잃을 수 있습니다. AI 코딩의 목표는 더 많은 코드를 뽑아내는 것이 아닙니다. 작동하는 깔끔한 코드를 유지하는 것입니다.

빨리 돌아가는 코드가 항상 좋은 코드는 아닙니다

AI는 기능을 빠르게 만들어줍니다. 쿠폰 할인 시스템, 로그인 기능, API 엔드포인트, 테스트 코드까지 몇 분 안에 만들 수 있습니다. 문제는 그 코드가 장기적으로 견딜 수 있는지입니다.

급하게 만든 코드는 처음에는 괜찮아 보일 수 있습니다. 테스트가 부족해도 화면에서는 돌아갑니다. 구조가 애매해도 한두 기능은 통과합니다. 중복이 있어도 당장은 티가 잘 나지 않습니다. 하지만 다음 기능을 붙일 때부터 문제가 보입니다.

어디를 고쳐야 하는지 알기 어렵고, 기존 동작이 깨질까 불안하고, 리팩터링하려고 해도 테스트가 없어서 손대기 어렵습니다. AI가 빨리 만든 코드를 사람이 이해하고 정리하지 못하면, 속도는 곧 부채가 됩니다.

씨앗을 먹는 코딩은 미래의 확장성을 잃습니다

“씨앗을 먹는다”는 비유는 AI 코딩에 잘 맞습니다. 씨앗은 당장 먹을 수도 있습니다. 그러면 지금은 배가 부릅니다. 하지만 다음 계절에 심을 것이 없어집니다. 코드에서 씨앗은 테스트, 설계 여지, 리팩터링 가능한 구조, 일관된 네이밍, 작은 단위의 변경입니다. 이런 것을 남겨야 다음 기능을 붙일 수 있습니다. 반대로 당장 돌아가는 코드만 계속 만들면 미래의 씨앗을 먹게 됩니다.

중복이 늘고, 책임이 섞이고, 테스트가 빠지고, 코드가 커질수록 변경 비용이 올라갑니다. 처음에는 빨랐지만 나중에는 작은 수정도 오래 걸리는 상태가 됩니다. AI 코딩을 쓸수록 이 씨앗을 의식적으로 남겨야 합니다.

AI가 엉키는 신호를 봐야 합니다

AI가 코드를 잘못된 방향으로 만들기 시작할 때는 신호가 있습니다. 첫째, 같은 형태의 코드를 반복해서 만듭니다. 이미 있는 구조를 재사용하지 않고 비슷한 코드를 새로 만듭니다. 둘째, 요청하지 않은 기능을 붙입니다. 필요한 범위를 넘어가면서 코드가 커지고 검토할 양이 늘어납니다. 셋째, 테스트를 삭제하거나 비활성화하려 합니다. 테스트가 실패하니 테스트 자체를 없애는 방향으로 움직이는 경우입니다.

이런 신호가 보이면 더 시키기보다 멈춰서 기준을 다시 줘야 합니다. AI가 더 많은 코드를 만들게 하는 것이 아니라, 더 좁은 범위에서 검증 가능한 변경을 하게 해야 합니다.

Augmented Coding의 목표는 작동하는 깔끔한 코드입니다

Kent Beck이 제안한 방향은 Augmented Coding입니다. 핵심은 AI가 개발자를 대체해서 알아서 코드를 만드는 것이 아닙니다. 개발자가 주도권을 가진 채 AI를 활용하는 것입니다. 여기서 목표는 단순히 “작동하는 코드”가 아닙니다. “작동하는 깔끔한 코드”입니다. 작동한다는 것은 기능이 요구사항을 만족한다는 뜻입니다. 깔끔하다는 것은 코드가 읽히고, 테스트되고, 바뀔 수 있다는 뜻입니다.

AI 코딩이 이 목표를 벗어나면 속도는 의미가 줄어듭니다. 코드가 빨리 나왔는데 수정하기 어렵고, 테스트가 없고, 구조가 엉켜 있다면 결국 사람이 다시 비용을 냅니다.

TDD는 AI 코딩의 가드레일이 됩니다

TDD의 Red-Green-Refactor 흐름은 AI 코딩과 잘 맞습니다. 먼저 Red 단계에서 실패하는 테스트를 만듭니다. 이 테스트는 AI에게 “무엇을 만들어야 하는지”를 말로 설명하는 대신 실행 가능한 스펙을 제공합니다.

그다음 Green 단계에서 테스트를 통과하는 최소 코드를 만듭니다. 여기서 핵심은 최소 코드입니다. AI가 필요 이상으로 많은 기능을 만들지 않도록 범위를 좁히는 역할을 합니다.

마지막으로 Refactor 단계에서 구조를 정리합니다. 작동하는 상태를 유지하면서 이름, 중복, 책임 분리, 복잡도를 다듬습니다. 이 세 단계가 있으면 AI가 아무 방향으로나 달리는 것을 줄일 수 있습니다.

테스트는 스펙이자 검증 기준입니다

AI에게 “쿠폰 할인 시스템 만들어줘”라고 말하면 너무 많은 해석이 가능합니다. 고정 금액 할인인지, 퍼센트 할인인지, 최대 할인 금액이 있는지, 만료된 쿠폰은 어떻게 처리하는지, 중복 적용은 가능한지 등 선택할 것이 많습니다. 테스트는 이 선택을 구체화합니다.

실패하는 테스트를 먼저 만들면 AI는 그 테스트를 통과하는 방향으로 움직입니다. 구현이 잘못되면 테스트가 실패합니다. 개발자는 실패 지점에서 멈춰서 확인할 수 있습니다.

그래서 테스트는 단순한 품질 확인 도구가 아닙니다. AI에게 주는 스펙이고, 동시에 AI가 범위를 벗어났을 때 멈추게 하는 가드레일입니다.

커스텀 커맨드와 계획 파일은 반복을 안정화합니다

AI 코딩 워크플로우가 반복된다면 지침을 파일로 남기는 편이 좋습니다. `CLAUDE.md`, custom commands, `plan.md` 같은 파일은 AI에게 작업 순서와 검증 기준을 반복해서 알려주는 역할을 합니다.

예를 들어 TDD 사이클을 실행하는 커맨드, Red 단계만 실행하는 커맨드, Green 단계만 실행하는 커맨드, Refactor 단계만 실행하는 커맨드를 나누면 작업을 더 작은 단위로 통제할 수 있습니다. 계획 파일에는 어떤 테스트를 만들지, 어떤 기능을 구현할지, 어떤 기준을 통과해야 완료인지 남길 수 있습니다. 이렇게 하면 AI와의 작업이 즉흥적인 대화가 아니라 반복 가능한 개발 흐름이 됩니다.

개발자가 판단의 주체로 남아야 합니다

TDD와 커맨드가 있다고 해서 AI가 항상 좋은 코드를 만든다는 뜻은 아닙니다. 중간중간 개발자가 봐야 합니다. 테스트가 정말 의미 있는지, 구현이 과하게 커지지 않았는지, 리팩터링이 설계를 나아지게 했는지, 기존 구조와 맞는지 확인해야 합니다. AI 코딩에서 개발자의 역할은 사라지지 않습니다. 오히려 더 선명해집니다.

직접 모든 코드를 치는 사람에서, 스펙을 테스트로 만들고, 변경 범위를 제한하고, 리팩터링 기준을 잡고, 품질을 판단하는 사람으로 이동합니다. AI가 속도를 담당할수록 개발자는 씨앗을 지켜야 합니다.

코드가 오늘 돌아가는 것만 보지 말고, 내일도 바꿀 수 있는지 봐야 합니다. 그 기준을 지키는 루프가 TDD이고, 그 루프 안에서 AI를 쓰는 방식이 Augmented Coding에 가깝습니다.