Agent 코딩은 왜 결제 시스템에서 자주 무너졌나: 내가 경계를 나눈 방법
나는 한동안 코딩 에이전트를 “작업 가속기"가 아니라 “개발 대체재"처럼 썼다. 결론적으로 속도는 잠깐 빨라졌고, 부채는 훨씬 빠르게 쌓였다.
특히 결제처럼 상태 정합성이 중요한 영역에서 이 방식은 거의 항상 같은 문제를 만들었다.
내가 겪은 현실: 부채는 커지는데 규모를 아무도 모른다
에이전트가 만든 코드의 가장 큰 위험은 “코드가 동작한다"는 사실이 안정성을 보증하지 않는다는 점이었다.
반복된 문제는 세 가지였다.
- 웹훅 중복/지연 이벤트 처리 누락
- 도메인 상태 전이 규칙 누락
- 기존 코드 맥락 오해로 인한 사이드 이펙트
겉으로는 기능이 붙어 있었지만, 시간이 지나면 수정 비용이 신규 개발 비용보다 더 커졌다.
참고: METR의 2025 연구는 숙련 개발자 환경에서 AI가 작업을 항상 빠르게 만들지 않는다고 보고했다. “도구를 쓰면 무조건 빨라진다"는 가정 자체를 경계해야 한다. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
왜 이런 일이 반복됐는가
내가 본 핵심 원인은 모델 능력의 부족보다 작업 경계의 부재였다.
에이전트에게 “결제 프로세스 개선” 같은 큰 단위를 넘기면 맥락이 섞이고, 설계와 구현, 검증 책임이 뒤엉킨다.
참고: Fred Brooks는 오래전부터 단일 도구로 본질적 복잡성을 제거할 수 없다고 경고했다. No Silver Bullet (1986)
나는 그 상태를 멈추고 아래처럼 경계를 나눴다.
- 설계는 사람이 한다.
- 에이전트는 모듈 단위 구현만 한다.
- 상태 전이/멱등성/권한 동기화는 자동 검증 없이는 머지하지 않는다.
내가 실제로 적용한 최소 경계
- 상태 머신을 먼저 고정한다.
- 모든 이벤트 처리에 idempotency 키를 둔다.
- “새 기능 추가"와 “기존 로직 수정"을 같은 작업에서 섞지 않는다.
- 에이전트가 변경한 파일 수가 기준을 넘으면 작업을 쪼갠다.
참고: Stripe는 멱등 요청을 “중복 실행 없이 안전하게 재시도하기 위한 장치"로 설명한다. 결제 도메인에서 이 규칙은 선택이 아니라 기본 안전장치였다. Idempotent requests
핵심은 “어디까지 맡길 것인가"보다 “어디부터는 절대 맡기지 않을 것인가"를 먼저 정하는 것이다.
그래서 지금의 운영 원칙
- Agent는 구현 가속기로만 쓴다.
- 설계 책임과 최종 품질 책임은 개발자에게 남긴다.
- 결제/권한/정산 같은 핵심 도메인은 경계 검사부터 통과시킨다.
이 원칙을 지키고 나서야 “빨리 만든 코드"가 아니라 “나중에도 고칠 수 있는 코드"가 남기 시작했다.