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

팀에서 AI 코딩 에이전트를 적극적으로 사용한 지 6개월이 됐다. 처음 몇 주의 신선함이 지나고 나면 실제 품질에 대한 냉정한 평가가 필요해진다. 이 글은 우리가 일상적으로 관찰한 패턴을 기록한 것이다.

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

반복적이고 패턴이 명확한 코드. CRUD 엔드포인트, 데이터 변환 로직, 유틸리티 함수처럼 “이렇게 하면 된다”는 패턴이 이미 정해진 작업은 에이전트가 빠르고 정확하게 작성한다. 사람이 직접 짜면 실수할 수 있는 반복적인 타이핑 오류가 없다.

문서화와 주석. 기존 코드에 주석을 추가하거나 README 를 보완할 때 품질이 좋다. 어투가 일관되고 빠진 내용을 채워주는 데 유용하다.

테스트 코드 기반 작성. 스펙이 명확하면 테스트 케이스를 빠르게 만들어낸다. 특히 경계값과 예외 케이스를 빠트리지 않고 목록화하는 데 도움이 된다.

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

시스템 전체 맥락이 필요한 결정. 어느 서비스가 어떤 DB 연결을 쓰는지, 특정 필드가 왜 그런 이름인지, 레거시 제약으로 인한 설계 선택 같은 것들은 코드 파일만으로는 파악이 안 된다. 이런 맥락이 필요한 지점에서 에이전트는 표면적으로 맞아 보이지만 실제로는 기존 약속과 충돌하는 코드를 생성한다.

에러 처리의 깊이. 정상 경로는 잘 구현하지만, 예외 상황을 어느 레이어에서 어떻게 처리해야 하는지는 프로젝트마다 다른 관례가 있다. 에이전트는 이 관례를 맥락 없이 추론해야 하므로 기존 패턴과 다른 처리 방식을 섞어 넣는 경우가 잦다.

보안 관련 판단. 입력 검증, 권한 체크, 민감 데이터 처리 같은 부분은 에이전트가 “그럴듯하게” 구현하지만, 프로젝트의 실제 보안 정책과 맞는지 확인 없이 믿어서는 안 된다. 이 영역은 리뷰 기준을 높게 유지한다.

우리가 실제로 사용하는 방식

에이전트 생성 코드는 초안으로 다룬다. 빠르게 구조를 잡는 데 쓰고, 그 위에서 실제 비즈니스 로직과 맥락을 사람이 보완한다. “에이전트가 만들었으니 됐다”는 태도는 결국 리뷰에서 놓친 문제가 운영에서 터지는 결과로 이어진다.

에이전트를 잘 쓰는 것은 결국 어디에 믿고 어디에서 손을 더 얹어야 하는지를 파악하는 것이다. 그 경계를 직접 경험으로 찾아가는 중이다.

— by slecs