AI 코딩 에이전트가 만드는 코드의 평균 품질

결제·정산 팀이 에이전트 코드에 냉정해야 하는 이유

HEDVION에서 AI 코딩 에이전트를 본격적으로 도입한 지 6개월이 넘었다. 처음 몇 주는 생산성 차이가 눈에 띄었다. CRUD 엔드포인트를 10분 만에 뽑아내고, 기존 코드에 빠진 테스트 케이스를 자동으로 채워주는 경험은 확실히 인상적이었다. 그런데 우리가 하는 일이 결제 처리, 정산 자동화, PG 연동이라는 걸 떠올리면, 에이전트가 "빠르게 그럴듯하게" 만들어준 코드를 그대로 믿는 것이 얼마나 위험한지 금방 드러나기 시작했다.

다른 도메인이라면 에이전트가 놓친 엣지 케이스는 QA 단계에서 잡히거나, 잡히더라도 빠르게 핫픽스로 수정할 수 있다. 결제·정산은 다르다. 이중 청구, 금액 불일치, 미처리 환불은 고객이 인지하기 전에 이미 손실이 발생해 있다. 에이전트가 생성한 코드에서 문제가 터졌을 때 "AI가 만들었다"는 말은 아무런 방어막이 되지 않는다. 그래서 우리는 에이전트의 실제 품질 패턴을 꽤 집요하게 관찰하고 기록했다.

에이전트가 일관되게 잘하는 영역

반복적이고 패턴이 명확한 코드에서 에이전트의 생산성은 실제다. 정산 배치 처리에서 매일 반복되는 트랜잭션 집계 로직, PG사별 응답 포맷을 우리 도메인 모델로 변환하는 매핑 코드, API 엔드포인트의 기본 구조 — 이런 코드는 에이전트가 사람보다 빠르고 실수가 적다. 특히 PG사가 추가될 때마다 거의 동일한 구조로 반복되는 어댑터 코드는 에이전트가 기존 구현을 참조해서 첫 번째 초안을 만들어주는 것만으로도 1~2시간을 절약한다. 사람이 직접 짜면 발생하는 단순 타이핑 오류나 복붙 실수도 없다.

문서화와 주석도 에이전트가 실제로 잘하는 영역이다. 정산 로직처럼 회계 규칙이 얽혀 있는 코드는 주석 없이는 몇 달 뒤에 팀원도 이해하기 어려운 경우가 많다. 에이전트는 기존 코드를 읽고 일관된 어투로 주석을 채우고 빠진 설명을 보완한다. 테스트 코드도 마찬가지다. 스펙이 명확하면 경계값과 예외 케이스 목록을 빠르게 만들어준다. 우리 경험상 에이전트가 만든 테스트 케이스 초안이, 리뷰 과정에서 사람이 미처 떠올리지 못한 케이스를 하나 이상 포함하고 있는 경우가 드물지 않았다.

에이전트가 반복적으로 실수하는 영역

가장 위험한 지점은 시스템 전체 맥락이 필요한 결정이다. 에이전트는 현재 컨텍스트 창 안에 있는 파일을 기반으로 추론한다. "왜 이 테이블에 created_at이 두 개인가", "이 상태 코드는 PG사 A의 타임아웃과 B의 취소 응답이 혼용되어 있어서 분리가 안 된 것이다" 같은 히스토리는 코드 파일에 담겨 있지 않다. 에이전트는 이런 맥락 없이 표면적으로 정합성이 맞는 코드를 만든다. 컴파일되고 테스트도 통과하지만, 기존 시스템의 암묵적 약속과 충돌하는 코드가 조용히 들어오는 것이다.

에러 처리의 깊이와 보안 관련 판단도 반복적으로 문제가 된다. 정상 경로는 잘 구현하지만, 결제 실패를 어느 레이어에서 잡고 어떻게 로깅하고 어디까지 재시도해야 하는지는 프로젝트마다, 심지어 PG사마다 다른 관례가 있다. 에이전트는 이 관례를 충분히 읽어내지 못한 채 일반적인 패턴을 적용한다. 결과적으로 기존 코드와 에러 처리 방식이 뒤섞이고, 모니터링 알림이 엉뚱한 조건에서 발생하거나 반대로 누락되는 상황이 생긴다. 보안도 마찬가지다. 입력 검증, 권한 체크, 민감 데이터 처리에서 에이전트는 "그럴듯한" 구현을 만들어내지만, 우리 시스템의 실제 보안 정책 — 카드 정보 마스킹 규칙, 로그에 노출되면 안 되는 필드 목록, 특정 엔드포인트의 추가 인증 요구사항 — 은 파일만 보고 추론할 수 없다.

수치로 본 실제 패턴: 6개월 관찰 결과

6개월간 우리가 내부적으로 관찰한 패턴을 정리하면 이렇다. 패턴이 명확한 반복 코드(어댑터, 매핑, CRUD)에서는 에이전트 초안의 약 75~80%가 리뷰 이후 큰 수정 없이 머지됐다. 이 영역에서 에이전트는 실제로 시간을 아껴준다. 반면 도메인 맥락이 깊이 얽힌 코드 — 정산 기간 계산, PG사별 환불 상태 처리, 정책 예외 케이스 — 에서는 에이전트 초안을 리뷰하다가 기존 설계와 충돌하는 부분을 발견하는 비율이 50%를 넘었다. 이 경우 초안을 구조 스케치 수준으로만 활용하고, 실제 구현은 사람이 다시 쓰는 경우가 많았다.

트레이드오프는 명확하다. 에이전트를 쓸수록 초안 속도는 올라가지만, 리뷰 밀도를 동시에 높이지 않으면 코드베이스 일관성이 무너진다. 소규모 팀에서 리뷰 속도가 따라가지 못하면, 에이전트가 만든 이질적인 패턴이 코드베이스에 조용히 누적된다. 단기 생산성 향상이 장기 유지보수 비용으로 전환되는 전형적인 패턴이다. 에이전트를 아예 안 쓴 것보다 빠를 때도 있고, 잘못된 방향을 수정하는 데 오히려 더 많은 시간이 든 경우도 있었다.

HEDVION 팀이 실제로 적용하는 시나리오

현재 우리가 사용하는 방식은 세 단계로 정리된다.

첫째, 에이전트에게 줄 컨텍스트를 사람이 사전에 정의한다. 단순히 "이 기능 만들어줘"가 아니라, 관련 도메인 규칙, 기존 패턴의 위치, 피해야 할 안티패턴을 함께 제공한다. 정산 계산 로직을 작성시킬 때는 우리가 사용하는 기간 계산 방식, 반올림 정책, 예외 케이스 처리 순서를 먼저 설명한다. 이 작업이 귀찮게 느껴질 수 있지만, 컨텍스트 없이 에이전트가 만든 코드를 수정하는 비용보다 훨씬 작다.

둘째, 보안·에러처리·상태 전이 코드는 에이전트 초안을 구조 참고용으로만 쓴다. 이 세 영역은 에이전트가 우리 정책을 알 수 없다는 걸 전제하고, 항상 사람이 처음부터 다시 검토하고 작성한다. 에이전트가 만든 흐름을 화이트보드에 그려놓고 "이 구조에서 실제 우리 정책을 적용하면 어떻게 달라지는가"를 검토하는 방식이 효과적이었다.

셋째, 에이전트 코드가 포함된 PR에는 리뷰 체크리스트를 별도로 붙인다. 일반 PR 체크리스트에 더해, 기존 에러 처리 패턴과 일치하는가 / 로깅 포맷이 모니터링 규칙과 맞는가 / 민감 데이터가 예상치 않은 위치에서 노출되는 경우는 없는가, 이 세 항목을 의무화했다. 이후 에이전트 코드 관련 리뷰 코멘트가 줄었고, 실제 문제를 운영 전에 잡는 비율이 올라갔다.

지금 바로 써먹을 수 있는 실행 시사점

1. 에이전트 적용 범위를 코드 유형별로 명시적으로 구분하라. 반복 코드와 문서화는 에이전트에게 많이 맡기되, 도메인 맥락이 깊은 코드는 사람이 초안을 쓰고 에이전트를 보조로 활용한다. 이 경계를 암묵적으로 두지 말고 팀 내에서 문서화해두는 것이 중요하다. 경계가 문서화되지 않으면 팀원마다 다른 기준으로 에이전트를 쓰게 되고, 결국 코드베이스 일관성이 흔들린다.

2. 에이전트에게 컨텍스트를 주입하는 비용을 아끼지 마라. 잘 작성된 프롬프트와 배경 설명은 에이전트 초안 품질을 눈에 띄게 높인다. 이 작업이 시간 낭비처럼 느껴진다면, 그 에이전트 초안을 수정하는 데 든 시간을 한 번 측정해보면 생각이 바뀐다.

3. 보안·에러처리·권한 관련 코드는 기본적으로 신뢰하지 않는 리뷰 기준을 적용하라. 컴파일되고 테스트를 통과한다고 안전하지 않다. 우리 시스템의 실제 정책과 대조하는 과정이 반드시 필요하며, 이 기준을 PR 템플릿에 명시적으로 박아두는 것이 운용상 가장 빠른 방법이다.

4. PR에서 에이전트가 작성한 부분을 투명하게 표시하라. 어느 부분이 에이전트 생성 코드인지 밝히고, 해당 부분에 별도 리뷰 기준을 적용하면 리뷰어가 어디에 집중해야 할지 명확해진다. "AI가 만들었으니 됐다"는 태도가 리뷰에서 놓친 문제를 운영에서 터뜨리는 결과로 이어진다는 것을, 우리는 직접 경험으로 확인했다.