Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

TL;DR Highlight

LLM 코딩 에이전트는 구조적 제약(아키텍처 패턴, ORM, DB 설계)이 쌓일수록 성능이 급격히 떨어지는 'constraint decay' 현상을 보인다는 연구 결과로, AI 코딩 도구를 프로덕션에 쓰려는 개발자라면 반드시 알아야 할 한계다.

Who Should Read

LLM 기반 코딩 에이전트(GitHub Copilot, Cursor, Claude Code 등)를 백엔드 개발에 도입하려는 팀, 또는 AI가 생성한 코드의 품질을 검증해야 하는 시니어 개발자와 아키텍트.

Core Mechanics

LLM 에이전트는 제약이 느슨한 상황에서는 코드를 잘 만들어내지만, 아키텍처 패턴·데이터베이스 설계·ORM(객체-관계 매핑, 코드로 DB를 다루는 방식) 같은 구조적 제약이 동시에 요구되면 성능이 크게 떨어진다.
연구팀은 이 현상을 'constraint decay(제약 붕괴)'라고 이름 붙였다. 구조적 요구사항이 하나씩 추가될수록 에이전트 성능이 누적적으로 떨어지는 패턴을 보인다.
8개 웹 프레임워크에 걸쳐 greenfield(새로운 프로젝트) 생성 80개 태스크와 기능 구현 20개 태스크, 총 100개 태스크를 동일한 API 명세 조건 하에 평가했다.
성능 좋은 구성에서도 단순 베이스라인 대비 완전한 구조 제약 조건에서 assertion(테스트 통과율)이 평균 30포인트 하락했고, 성능이 낮은 구성은 거의 0에 가까워졌다.
프레임워크별 차이도 뚜렷했다. Flask처럼 명시적이고 단순한 프레임워크에서는 잘 작동하지만, FastAPI·Django처럼 관례(convention)가 많은 프레임워크에서는 평균 성능이 현저히 낮았다.
오류 원인 분석 결과, 데이터 레이어 결함(잘못된 쿼리 작성, ORM 런타임 위반 등)이 가장 주된 실패 원인으로 꼽혔다.
기존 벤치마크들은 코드가 기능적으로 동작하는지만 평가하고 구조적 요구사항(아키텍처 준수 여부 등)은 무시하는 경향이 있어서, AI 코딩 도구의 실제 프로덕션 적합성을 과대평가해왔다.
연구팀은 종단간 동작 테스트(behavioral test)와 정적 검증(static verifier)을 함께 쓰는 이중 평가 방식을 사용해 기능 정확성과 구조 정확성을 모두 측정했다.

Evidence

프론티어 모델(최신 고성능 모델)을 비용 문제로 완전히 테스트하지 못했다는 점은 이 연구의 한계로 지적됐다. 따라서 구체적인 수치보다는 '구조적 제약이 쌓이면 성능이 떨어진다'는 전반적인 경향 자체에 주목해야 한다는 의견이 있었다.
장기간 agentic 코딩을 직접 실험한 개발자는 '제약을 나중에 추가하는 것보다 처음부터 함께 제공하는 편이 낫다'고 경험을 공유했다. 또한 코드베이스에 특정 패턴이 등장하면 에이전트가 그 패턴을 계속 따라가며 강화하는 '석회화(calcification)' 현상도 관찰했다고 했다.
context window(모델이 한 번에 처리할 수 있는 텍스트 양) 문제와의 연관성을 지적한 의견도 있었다. 프로덕션 수준의 코드를 만들려면 여러 디렉터리를 참조해야 하는데, 이게 context를 금방 채워버려서 제약 준수 능력이 떨어진다는 분석이다.
반대 경험을 공유한 댓글도 있었다. 기존 레거시 코드베이스가 클수록 오히려 패치가 더 정확해진다는 의견으로, SQL·git 툴 콜을 100번 넘게 하면서 컨텍스트를 충분히 쌓은 뒤 패치를 적용하는 방식이 핵심이라고 했다. 이 경우 greenfield(새 프로젝트)와는 다른 맥락이라는 점에서 논문의 설정과 차이가 있다.
실용적인 해결책으로 '코드베이스의 일부를 관용적(idiomatic)으로 잘 만들어두고 그 파일들을 exemplar(예시)로 @-멘션해서 에이전트에게 넘기는 방식'이 markdown으로 설명하는 것보다 훨씬 효과적이라는 팁이 공유됐다. 특히 JavaScript에서는 예시와 가이드를 줘도 에이전트가 엉뚱한 방식으로 구현하는 경향이 있다는 경험도 덧붙여졌다.
ArchUnit 같은 아키텍처 린터 도구를 활용해서 에이전트가 구조 규칙을 어겼을 때 정확한 피드백을 주는 방향이 해결책이 될 수 있다는 제안이 있었다. 아키텍처 규칙을 코드로 명시하고 자동으로 검증하는 방식은 LLM뿐만 아니라 팀 전체의 코드 품질에도 도움이 된다는 주장이다.

How to Apply

LLM 에이전트에게 복잡한 백엔드 코드를 맡길 때는 먼저 계획(planning) 단계를 별도로 거쳐라. ARCHITECTURE.md, BACKEND-GUIDELINES.md 같은 구조 문서를 AGENTS.md에 링크해두고 에이전트가 계획 수립 시에만 참조하도록 하면, 실행 단계에서 context를 아끼면서도 구조 제약을 반영할 수 있다.
FastAPI나 Django처럼 관례가 많은 프레임워크를 사용 중이라면 markdown 설명 대신 잘 작성된 코드 파일 자체를 exemplar로 제공하라. 에이전트가 따라야 할 패턴이 담긴 실제 파일을 @-멘션으로 넘기면 추상적 설명보다 훨씬 효과적으로 구조를 유지시킬 수 있다.
에이전트가 생성한 코드의 구조적 정확성을 검증하려면 기능 테스트 외에 ArchUnit(Java) 같은 아키텍처 린터를 CI 파이프라인에 추가하라. 에이전트가 구조 규칙을 어겼을 때 자동으로 감지하고 구체적인 피드백을 다시 에이전트에게 넘기는 루프를 구성하면 constraint decay를 부분적으로 보완할 수 있다.
정적 타입 언어(Go, TypeScript 등)로 코드베이스를 구성하면 에이전트가 잘못된 코드를 생성했을 때 빌드 오류로 즉시 감지되고 수정 루프가 빠르게 돌아간다. Python·JS처럼 동적 타입 언어는 구조적 오류가 런타임에서야 드러나므로, 에이전트와의 협업 시 정적 타입 언어가 구조 유지에 유리하다.

Terminology

constraint decay구조적 요구사항이 하나씩 추가될수록 LLM 에이전트의 코드 생성 성능이 누적적으로 떨어지는 현상. 마치 규칙이 많아질수록 규칙을 다 지키지 못하는 것처럼 성능이 붕괴된다.

ORMObject-Relational Mapping의 약자. 데이터베이스 테이블을 코드의 객체(class)로 다루게 해주는 기술. Django의 models.py나 SQLAlchemy가 대표적 예시.

greenfield task기존 코드 없이 완전히 새로 만드는 프로젝트나 태스크. 레거시 코드나 기존 패턴의 제약이 없는 상태에서 시작하는 것.

static verifier코드를 실행하지 않고 소스 코드 분석만으로 규칙 준수 여부를 검사하는 도구. 린터나 타입 체커, 아키텍처 검증 도구 등이 여기 해당.

context windowLLM이 한 번의 요청에서 처리할 수 있는 최대 텍스트 분량. 이 한계를 넘으면 초반에 준 지시나 제약 조건을 '잊어버리는' 것처럼 동작한다.

convention-heavy framework프레임워크가 암묵적인 규칙(파일 위치, 클래스 이름 규칙 등)을 많이 강제하는 방식. Django나 FastAPI처럼 따라야 할 관례가 많은 프레임워크를 의미하며, LLM이 이 관례를 모두 맞추기 어려워한다.