코딩 에이전트의 Constraint Decay, 백엔드에서 더 잘 보인다

요즘 코딩 에이전트는 작은 기능 구현이나 초안 생성에서는 꽤 그럴듯하다. 그런데 2026년 5월에 올라온 arXiv 논문 Constraint Decay: The Fragility of LLM Agents in Backend Code Generation은 조금 다른 지점을 짚는다. 문제는 “작동하느냐”보다 “정해진 구조를 끝까지 지키느냐”다.

기능 통과와 구조 준수는 다르다

논문은 80개의 신규 백엔드 생성 과제와 20개의 기능 구현 과제를 놓고, 같은 API 계약 아래에서 에이전트가 구조적 요구사항을 얼마나 지키는지 봤다. 테스트가 통과해도 아키텍처, DB 사용 방식, ORM 패턴이 어긋나면 실무에서는 바로 부채가 된다.

요구사항이 쌓이면 성능이 떨어진다

핵심 표현은 constraint decay다. 구조 요구사항이 늘어날수록 에이전트의 통과율이 눈에 띄게 떨어졌고, 강한 설정도 완전 명세 조건에서는 평균 30포인트 정도 하락했다. 약한 설정은 거의 0에 가까워지는 경우도 있었다.

프레임워크 차이도 컸다

Flask처럼 명시적이고 단순한 환경에서는 상대적으로 잘 버텼지만, FastAPI나 Django처럼 관례와 레이어가 많은 환경에서는 더 자주 무너졌다. 이건 모델 성능만의 문제가 아니라, 프레임워크가 숨겨둔 암묵적 규칙을 에이전트가 얼마나 잘 따라가느냐의 문제에 가깝다.

실무에서 볼 곳은 데이터 레이어다

에러 분석에서 많이 나온 원인은 잘못된 쿼리 조합, ORM 런타임 위반 같은 데이터 레이어 문제였다. 그래서 에이전트에게 백엔드를 맡길 때는 단순 E2E 테스트만 두기보다, 쿼리 패턴과 레이어 경계를 확인하는 정적 검증을 같이 두는 편이 현실적이다.

짧은 결론

코딩 에이전트는 “코드를 쓰는 도구”에서 “제약을 지키며 변경하는 도구”로 넘어가야 한다. 당분간은 요구사항을 짧게 주는 것보다, 검증 가능한 구조 규칙을 작게 쪼개고 자동 검사로 묶어두는 쪽이 더 안전해 보인다.

참고: https://arxiv.org/abs/2605.06445