Constraint Decay: 백엔드 코드 생성에서 LLM 에이전트의 취약성

• LLM 에이전트는 느슨한 명세의 코드 생성에는 강하지만, 운영급 백엔드가 요구하는 API 계약·아키텍처·DB·ORM 제약 준수에는 아직 취약함
• 동일한 OpenAPI 명세로 기능 요구를 고정하고, 8개 웹 프레임워크의 80개 그린필드 과제와 20개 기능 구현 과제에 같은 동작 테스트를 적용함
• 비기능 제약은 프레임워크 선택, 아키텍처 패턴, 데이터베이스 백엔드, ORM 통합 4개 차원으로 나눠 구조 복잡성의 영향을 분리함
• 제약 붕괴는 구조 요구가 누적될수록 성능이 급락하는 현상이며, 높은 구성도 완전 지정 과제에서 assertion pass rate가 평균 30포인트 하락함
• 실패의 핵심은 데이터 계층 결함으로, 잘못된 쿼리 구성과 ORM 런타임 위반이 에이전트 로직 실패의 약 45%를 차지함

핵심 문제와 평가 설정

• LLM 에이전트는 느슨한 명세의 자율 코드 생성에서는 강하지만, 운영급 백엔드 소프트웨어에 필요한 구조적 제약을 엄격히 지키는 능력은 충분히 평가되지 않았음
• 운영급 백엔드는 API 계약을 따르는 엔드포인트뿐 아니라 아키텍처 패턴, 데이터베이스 통합, 지정된 ORM 계층 같은 기능 외 요구사항도 만족해야 함
• 기존 벤치마크는 기능적으로 맞지만 구조적으로 임의적인 해법에도 보상을 주는 경우가 많아, 제약이 있는 다중 파일 백엔드 개발의 어려움을 충분히 포착하지 못함
• 기존 연구는 기존 코드베이스의 특정 이슈 해결, 자연어 프롬프트 기반 비제약 생성, 단일 파일 해법, 스켈레톤 코드 완성에 주로 초점을 맞췄고, 구조적 제약의 정도를 체계적으로 바꾸는 효과는 다루지 못했음
• 동일한 OpenAPI 명세로 기능 요구사항을 고정하고 모든 조건에 같은 엔드투엔드 동작 테스트를 적용해 구조적 복잡성의 영향을 분리함
• 실험은 8개 웹 프레임워크에 걸친 80개 그린필드 생성 과제와 20개 기능 구현 과제로 구성됨
• 비기능 제약은 프레임워크 선택, 아키텍처 패턴, 데이터베이스 백엔드, ORM 통합의 4개 차원으로 나뉨
• 기준 조건에서는 같은 API 명세만 주어지고, 제약 조건에서는 clean architecture, PostgreSQL, SQLAlchemy 같은 요구가 추가됨
• 평가는 엔드투엔드 동작 테스트와 정적 검증기를 함께 사용해 기능 정확성과 구조 준수를 분리함

주요 결과와 의미

• 제약 붕괴(constraint decay) 는 구조적 요구사항이 누적될수록 에이전트 성능이 크게 떨어지는 현상으로 확인됨
• 성능이 높은 구성도 기준 조건에서 완전 지정 과제로 갈수록 assertion pass rate가 평균 30포인트 하락했으며, 일부 약한 구성은 거의 0에 가까워짐
• 같은 API 계약에서도 프레임워크에 따라 성공률 차이가 컸고, 에이전트는 Flask 같은 가볍고 명시적인 프레임워크에서 더 잘 작동함
• FastAPI, Django처럼 관례가 많은 환경에서는 평균 성능이 훨씬 낮아짐
• 오류 분석에서는 데이터 계층 결함이 주요 원인으로 드러났고, 잘못된 쿼리 구성과 ORM 런타임 위반이 대표적임
• 데이터 계층 결함은 에이전트 로직 실패의 약 45% 를 유발하는 핵심 원인으로 분류됨
• 기능 요구사항과 구조 요구사항을 동시에 만족하는 일은 코딩 에이전트에게 여전히 중요한 미해결 과제로 남아 있음
• 평가 파이프라인, 과제 모음, 에이전트 실행 궤적, 분석 스크립트는 constraint-decay에 공개됨