AI 코딩은 빨리 만드는 것보다 씨앗을 지키는 일이 먼저입니다
AI 코딩 도구는 기능을 빠르게 만듭니다. 그래서 처음에는 생산성이 크게 오른 것처럼 느껴집니다. 하지만 빠르게 돌아가는 코드가 장기적으로 고치기 쉬운 코드라는 뜻은 아닙니다.
Kent Beck이 말한 Augmented Coding의 핵심은 AI에게 많은 코드를 뽑게 하는 것이 아닙니다. 테스트와 리팩터링을 통해 작동하는 깔끔한 코드를 유지하면서 개발자가 주도권을 놓치지 않는 것입니다.
씨앗을 먹는 코딩이 위험한 이유
당장 배고프다고 다음 수확을 위해 남겨야 할 씨앗까지 먹으면, 지금은 버틸 수 있어도 다음 계절에 심을 것이 없습니다. 코드에서 씨앗은 테스트, 작은 설계 단위, 읽히는 이름, 리팩터링 가능한 구조입니다. 이 씨앗을 남겨야 다음 기능을 붙이고 장애를 고칠 수 있습니다.
AI가 만든 코드를 검토하지 않고 계속 쌓으면 처음에는 빠릅니다. 하지만 중복이 늘고, 책임이 섞이고, 테스트가 빠지면 작은 수정도 어려워집니다. 속도가 미래의 변경 가능성을 먹어버리는 상태가 됩니다.
장면 요약: 오늘의 속도가 내일의 변경 가능성을 먹기 시작하면 멈춰야 합니다.
AI가 엉키고 있다는 신호
다음 증상이 보이면 더 시키기보다 멈춰야 합니다.
비슷한 코드가 여러 파일에 반복됩니다.
요청하지 않은 기능이 붙습니다.
기존 테스트를 삭제하거나 건너뜁니다.
오류를 없애려고 검증을 약하게 만듭니다.
함수가 커지고 책임이 섞입니다.
왜 이 구조인지 설명하기 어려워집니다.
이때 필요한 것은 더 강한 프롬프트가 아니라 작업 루프를 다시 잡는 일입니다. 실패하는 테스트, 최소 구현, 리팩터링 순서를 회복해야 합니다.
TDD는 AI 출력의 범위를 줄입니다
AI에게 말로만 기능을 설명하면 해석의 폭이 넓습니다. 테스트를 먼저 쓰면 원하는 동작이 더 좁아집니다. Red-Green-Refactor 흐름은 AI 코딩에서도 유효합니다.
실패하는 테스트로 원하는 동작을 정의합니다.
AI에게 테스트를 통과하는 최소 구현만 요청합니다.
통과한 뒤 중복과 이름, 책임 분리를 리팩터링합니다.
테스트가 계속 통과하는지 확인합니다.
테스트는 AI를 불신하기 위한 장치가 아닙니다. AI가 빠르게 움직일 수 있는 안전한 울타리입니다.
장면 요약: 테스트는 AI를 막는 벽이 아니라 뛰어도 되는 범위입니다.
리팩터링까지 맡겨야 완성입니다
AI에게 구현만 맡기고 멈추면 가장 중요한 단계가 빠집니다. 기능이 통과한 뒤에는 중복 제거, 이름 정리, 책임 분리, 테스트 가독성 개선을 별도 요청으로 분리해야 합니다.
리팩터링 요청도 막연하면 안 됩니다. "깔끔하게 해주세요"보다 "중복된 조건문을 하나의 정책 함수로 모으고, 공개 API 동작은 바꾸지 말고, 기존 테스트를 모두 통과시키세요"처럼 범위를 좁혀야 합니다. AI는 빠르게 고칠 수 있지만, 어떤 품질 기준을 지켜야 하는지는 사람이 지정해야 합니다.
구현과 리팩터링을 같은 요청에 섞지 않는 것도 중요합니다. 먼저 동작을 고정하고, 그다음 구조를 다듬어야 무엇이 깨졌는지 추적할 수 있습니다. 이 순서를 지켜야 AI의 빠른 수정이 새로운 혼란으로 바뀌지 않습니다.
바로 적용할 체크리스트
AI 코딩을 팀에 넣고 있다면 다음 규칙을 작업 지침으로 고정해보세요.
새 기능은 먼저 실패하는 테스트나 인수 조건으로 정의합니다.
AI가 테스트를 삭제하거나 약화하면 작업을 중단합니다.
구현 후 중복과 책임 섞임을 별도 단계로 리팩터링합니다.
커스텀 커맨드나 작업 문서에 검증 명령을 적습니다.
커버리지보다 핵심 동작을 증명하는 테스트를 우선합니다.
사람이 이해하지 못한 코드는 병합하지 않습니다.
AI 코딩의 좋은 목표는 빠르게 많은 코드를 만드는 것이 아닙니다. 다음 변경을 가능하게 하는 씨앗을 남긴 채로 속도를 얻는 것입니다.