LLM 에이전트는 왜 백엔드에서 무너지는가 — '제약 붕괴'라는 새 한계

요즘 개발 트위터와 해커뉴스에서 조용히 화제가 된 논문이 하나 있습니다. 제목은 “Constraint Decay: The Fragility of LLM Agents in Back End Code Generation”. 한국말로 옮기면 “제약 붕괴 — 백엔드 코드 생성에서 LLM 에이전트의 취약성"인데요. 해커뉴스에서 166점, 83개의 댓글을 받으며 단숨에 상위권에 올랐습니다. AI가 프론트엔드 컴포넌트는 그럴듯하게 만들면서, 왜 백엔드만 들어가면 와르르 무너지는지를 체계적으로 파헤친 연구입니다.

‘Constraint Decay’가 도대체 뭔가요

제약 붕괴, 줄여서 ‘CD’라고 부르는 이 현상은 한 문장으로 요약하면 이렇습니다. 대화가 길어질수록 LLM 에이전트가 처음에 받은 제약 조건들을 점점 잊어버리거나 위반하기 시작한다는 겁니다.

처음에는 “이 API는 인증이 필요해”, “DB 스키마는 이걸 따라야 해”, “트랜잭션은 반드시 롤백 처리해야 해” 같은 규칙들을 잘 지킵니다. 그런데 코드를 한 줄 한 줄 추가하고, 함수를 호출하고, 다른 모듈을 참조하다 보면 어느 순간 그 제약들이 슬그머니 사라집니다. 인증 미들웨어가 빠지고, 외래키 관계가 깨지고, 트랜잭션 안에서 외부 API를 호출하는 식으로요.

연구팀은 이걸 “체계적 연구를 통해 LLM 기반 코딩 에이전트에서 일어나는 제약 붕괴 현상을 노출시켰다"고 표현합니다. 우연한 버그가 아니라 구조적 한계라는 겁니다.

왜 하필 백엔드에서 더 심하게 나타나나

프론트엔드는 비교적 자기 완결적입니다. 버튼 하나, 카드 컴포넌트 하나만 보면 끝나는 작업이 많죠. 시각적으로 결과가 바로 보이니 틀리면 바로 잡을 수도 있고요.

백엔드는 다릅니다. 한 줄의 코드가 10개의 보이지 않는 제약과 얽혀 있습니다.

• 트랜잭션 경계
• 인증·인가 체크
• 데이터베이스 스키마 무결성
• 동시성 처리
• 에러 핸들링 규칙
• 로깅 표준
• API 계약(스키마)
• 멱등성 요구사항
• 외부 서비스 SLA
• 보안 정책

이 모든 게 동시에 만족돼야 코드가 ‘맞는’ 겁니다. 그런데 LLM은 토큰을 하나씩 예측하는 모델이라, 컨텍스트 안에 들어 있는 제약들이 많을수록 일부를 흘려보내는 경향이 생깁니다. 길어진 대화 속에서 우선순위가 흐려지는 거죠.

GPT-5.2를 썼는데 왜 5.2-codex는 안 썼나

해커뉴스 댓글에서 가장 눈에 띈 지적이 이거였습니다. “Odd they used GPT-5.2 and not GPT-5.2-codex” — 코드 특화 모델을 두고 왜 일반 모델로 평가했냐는 거죠.

타당한 비판입니다. 코덱스 변형은 코드 생성에서 제약 추적이 훨씬 강하다는 게 일반적인 평가니까요. 다만 연구자 입장에서 보면, 일반 모델로 측정해야 “에이전트 프레임워크 자체의 한계”를 더 깨끗하게 드러낼 수 있다는 반론도 가능합니다. 코덱스가 가려주는 결함을 일반 모델은 정직하게 드러내는 셈이죠.

또 다른 댓글에서는 이 연구가 최근에 나온 “여러 분야의 문서 편집 작업을 LLM에 위임하는 논문"과 비슷한 결을 가진다고 언급합니다. 즉 코드만의 문제가 아니라 긴 컨텍스트, 다중 제약 작업 전반에서 일관되게 관찰되는 패턴이라는 거죠.

실무자에게 시사하는 것

이 연구가 의미 있는 건 단순히 “AI는 아직 부족해"라는 결론을 넘어서, 어디서 어떻게 부족한지를 진단했다는 점입니다. 실무에 적용한다면 이렇게 정리해볼 수 있겠습니다.

첫째, 긴 에이전트 세션을 짧게 끊으세요. 한 번에 100개 파일을 수정하게 하지 말고, 작업 단위로 컨텍스트를 리셋하는 게 안전합니다.

둘째, 제약을 코드 바깥에 박아두세요. 시스템 프롬프트에만 적어두면 잊혀집니다. 린터, 타입 시스템, CI 검사, 스키마 검증 같은 외부 강제 장치에 제약을 새겨야 합니다.

셋째, 백엔드 PR은 사람이 더 꼼꼼히 봐야 합니다. 프론트엔드와 같은 신뢰도로 보면 안 됩니다. 특히 트랜잭션, 인증, DB 마이그레이션이 걸린 부분은요.

마무리하며

LLM 에이전트가 “아직 백엔드를 못 한다"는 막연한 감각을 데이터로 입증한 연구입니다. 코덱스 변형으로 다시 측정하면 결과가 달라질 수 있다는 한계는 있지만, ‘제약 붕괴’라는 개념 자체는 한동안 AI 코딩 도구를 평가하는 새로운 축으로 자리 잡을 것 같습니다.

여러분의 팀에서 AI 코딩 도구를 쓰고 있다면, 한 번 돌아보세요. 프론트엔드 PR과 백엔드 PR의 머지 후 사고 비율을 따로 집계해보면 어떨까요. 숫자가 말해주는 게 꽤 많을 겁니다.