딸깍코딩은 편합니다. AI 에이전트에게 요구사항을 던지고, 버튼을 누르듯 코드를 만들면 당장 돌아가는 화면이 생깁니다. 문제는 속도가 아니라, 그 속도로 이유 없는 코드도 같이 쌓인다는 점입니다.

AI 에이전트 코딩의 진짜 리스크는 “코드를 못 만든다”가 아닙니다. 오히려 너무 잘 만들기 때문에, 실험 코드와 프로덕션 코드의 경계가 흐려지고, 왜 존재하는지 모르는 레거시가 빠르게 늘어납니다.

이 글에서는 딸깍코딩을 멈추자는 이야기가 아니라, AI를 쓰기 전에 Product 초반 설계를 어떻게 잡아야 레거시 비용을 줄일 수 있는지 정리합니다.

딸깍코딩의 문제는 생성 속도가 아니라 제거 비용이다

AI 에이전트는 생각보다 코드를 잘 만듭니다. 컴포넌트를 만들고, API를 붙이고, 데이터 구조를 바꾸고, 스타일도 빠르게 맞춥니다. 그래서 초반에는 개발 속도가 빨라진 것처럼 보입니다.

하지만 나중에 문제가 됩니다. 누가 왜 만든 코드인지 모르는 파일이 생기고, 한 번 쓰고 버렸어야 할 실험 코드가 실제 사용자 흐름 안으로 들어옵니다. 이때부터 시스템은 조용히 오염됩니다.

생성은 몇 분이면 되지만, 제거는 훨씬 비쌉니다. 지우려면 이 코드가 어디서 호출되는지, 어떤 예외를 막고 있는지, 어떤 사용자 흐름과 연결되어 있는지 다시 파악해야 합니다.

AI가 만든 코드는 ‘내가 만든 코드’보다 더 위험할 수 있다

내가 직접 만든 코드는 적어도 왜 그렇게 만들었는지 기억이 남습니다. 반면 AI가 만든 코드는 결과만 남고 의도가 사라지기 쉽습니다. 리뷰하지 않고 병합하면 팀은 개발 속도를 얻는 대신 미래의 리팩토링 지옥을 예약합니다.

특히 에이전트형 코딩은 한 번에 여러 파일을 건드립니다. UI, API, 타입, 데이터 저장 방식, 테스트 파일까지 동시에 바뀌기 때문에 작은 기능처럼 보여도 실제 변경 범위는 커질 수 있습니다.

Product 초반 설계에서 먼저 정해야 할 5가지

AI 에이전트에게 코드를 맡기기 전, Product 설계에서 먼저 정해야 할 것이 있습니다. 거창한 PRD가 아니라도 괜찮습니다. 최소한 아래 다섯 가지는 정하고 들어가야 합니다.

사용자	누가 이 기능을 쓰는가. 내부 운영자인가, 고객인가, 익명 방문자인가.
문제	이 기능이 없어서 지금 어떤 일이 막히는가.
성공 기준	완성됐다고 판단할 수 있는 화면, 수치, 행동은 무엇인가.
경계	이번에 만들지 않을 것은 무엇인가. 어디까지가 실험인가.
삭제 기준	효과가 없을 때 어떤 파일, 데이터, 기능을 제거할 수 있는가.

여기서 가장 자주 빠지는 것은 삭제 기준입니다. 만들 때부터 지울 수 있게 설계하지 않으면, 기능은 계속 남고 시스템은 점점 무거워집니다.

실험 코드와 프로덕션 코드를 분리해야 한다

AI 에이전트로 만든 첫 버전은 대부분 실험 코드입니다. 빨리 확인하기 위한 코드이지, 바로 오래 운영할 코드가 아닙니다. 그런데 이 경계가 무너지면 실험이 제품 내부에 눌러붙습니다.

그래서 기능마다 상태를 붙이는 습관이 필요합니다. prototype, internal, beta, production처럼 단계가 있어야 하고, 각 단계마다 리뷰 기준이 달라야 합니다.

• prototype: 화면이나 흐름을 확인하기 위한 코드. 데이터 영속성 최소화.
• internal: 내부 운영자가 쓰는 코드. 로그와 실패 복구를 확인.
• beta: 일부 사용자에게 열 수 있는 코드. 권한, 데이터, 알림을 검증.
• production: 삭제 기준과 운영 책임자가 명확한 코드.

AI 에이전트에게 바로 던지면 안 되는 요청

나쁜 요청은 보통 짧습니다. “이거 만들어줘”, “대충 붙여줘”, “자동화해줘” 같은 말은 AI에게 너무 많은 결정을 넘깁니다. 그러면 AI는 빠르게 만들지만, 제품의 방향과 맞지 않는 결정을 코드 안에 박아 넣습니다.

반대로 좋은 요청은 구현보다 맥락을 먼저 줍니다. 사용자가 누구인지, 지금 막힌 문제가 무엇인지, 이번에 만들지 않을 것이 무엇인지, 기존 구조에서 건드리면 안 되는 파일이 무엇인지 알려줍니다.

팀에서 정해야 할 AI 코딩 리뷰 기준

AI가 만든 코드를 검토하지 않는 팀은 속도만 얻는 것이 아닙니다. 미래의 유지보수 비용도 같이 삽니다. 그래서 AI 코드 리뷰는 “돌아가냐”보다 “남겨도 되냐”를 봐야 합니다.

• 이 코드가 필요한 이유가 주석이나 문서에 남아 있는가.
• 기존 책임 경계를 침범하지 않았는가.
• 임시 로직이 프로덕션 경로에 들어가지 않았는가.
• 삭제해도 되는 파일과 남겨야 하는 파일이 구분되는가.
• 테스트 또는 수동 검증 방법이 남아 있는가.

정리: AI 코딩은 더 많이 만드는 기술이 아니라 덜 망치는 운영 방식이다

AI 에이전트는 앞으로 더 좋아질 겁니다. 더 많은 파일을 읽고, 더 긴 작업을 하고, 더 그럴듯한 코드를 만들 겁니다. 그러면 Product 초반 설계의 중요성은 줄어드는 것이 아니라 더 커집니다.

생성 속도가 빨라질수록, 무엇을 만들지 않는지 정하는 능력이 더 중요해집니다. 딸깍코딩의 최후를 피하려면 버튼을 누르기 전에 제품의 경계부터 잡아야 합니다.

AI 코딩의 핵심은 더 빨리 만드는 것이 아니라, 나중에 지울 수 있는 구조로 만드는 것이다.

FAQ

AI 코딩을 쓰지 말아야 하나요?

아니요. AI 코딩은 강력한 도구입니다. 다만 설계 없이 바로 구현부터 맡기면 코드가 빠르게 쌓이고, 나중에 제거 비용이 커집니다.

초기 스타트업도 이런 설계가 필요한가요?

오히려 초기일수록 필요합니다. 무거운 문서가 아니라, 사용자·문제·성공 기준·제외 범위·삭제 기준만 정해도 이후 리팩토링 비용이 크게 줄어듭니다.

가장 먼저 도입할 기준은 무엇인가요?

실험 코드와 프로덕션 코드의 경계를 나누는 것입니다. 이 기준만 있어도 AI가 만든 코드가 제품 내부에 무분별하게 쌓이는 일을 줄일 수 있습니다.