AI "둠 루프(Doom Loop)": 왜 당신의 자율 코딩 에이전트가 상황을 악화시키는지, 그리고 어떻게 해결할 것인가

최근 자율 AI 코딩 에이전트(autonomous AI coding agents)와 함께 작업하는 시간을 조금이라도 가져보았다면, 여러분은 그 과정을 잘 알고 있을 것입니다.

여러분은 에이전트에게 간단한 작업을 부여합니다: "사용자 프로필 페이지를 추가하고 이를 네비게이션 바(navbar)에 연결해줘."

에이전트는 "제가 할 수 있습니다"라고 말합니다. 그리고 코드를 작성합니다. 실행해 보면 임포트 에러(import error)가 발생합니다. 에러를 다시 붙여넣습니다. 에이전트는 사과하고 파일을 다시 작성하지만, 이제는 라우팅(routing)이 깨져 있습니다. 그 에러를 다시 붙여넣습니다. 10번의 반복이 지나면, 설정(config) 파일은 미스터리하게 삭제되어 있고, 네비게이션 바는 완전히 사라졌으며, 에이전트는 지원이 중단된(deprecated) 버전의 React를 설치하려고 시도하고 있습니다.

이것이 바로 AI 에이전트 둠 루프(AI Agent Doom Loop)입니다.

이런 현상이 발생하는 이유는 현재의 에이전트 프레임워크(agent frameworks)가 지능(intelligence)을 규율(discipline)로 착각하기 때문입니다. 우리는 에이전트에게 프로젝트에 대한 모든 것을 알려주는 10,000 토큰 분량의 SYSTEM_PROMPT.txt를 쏟아붓고, 에이전트가 실행 루프의 45번째 단계에서도 아키텍처 제약 사항을 기억하기를 바랍니다. 하지만 그런 일은 거의 일어나지 않습니다.

제가 Agent Rigor를 만든 이유는 스스로 코드를 짜다가 막다른 길로 치닫는 에이전트들을 계속해서 돌봐주는 것에 지쳤기 때문입니다.

근본 원인: 컨텍스트 부패 (Context Rot)

에이전트가 작업을 시작할 때, 그 컨텍스트(context)는 깨끗한 상태입니다. 하지만 에이전트가 파일을 읽고, 명령어를 실행하고, 에러를 마주하면서, 컨텍스트 윈도우(context window)는 쓰레기 같은 스택 트레이스(stack traces)와 이전의 실패한 시도들로 가득 차게 됩니다.

20단계쯤 진행되었을 때, 여러분이 정성스럽게 작성한 원래의 시스템 프롬프트(system prompt)는 파묻혀 버립니다. 에이전트는 아키텍처 가이드라인을 잊어버립니다. 에이전트는 전체적인 목표보다 눈앞에 놓인 즉각적인 에러를 우선시하기 시작합니다. 바로 이때 에이전트가 추측하고, 환각(hallucinating)을 일으키며, 상황을 악화시키기 시작합니다.

해결책: 점진적 공개(Progressive Disclosure)와 경험적 규율(Empirical Discipline)

Agent Rigor는 새로운 LLM이나 마법 같은 프롬프트 래퍼(prompt wrapper)가 아닙니다. 이것은 **엄격한 경험적 규율(strict empirical discipline)**을 강제하는 에이전트를 위한 운영체제(operating system)입니다.

하나의 거대한 프롬프트 대신, Agent Rigor는 3단계 계층 구조를 사용합니다:

1. L1 (Apex Kernel): 절대적이고 타협 불가능한 규칙입니다. (예: "API 시그니처(API signature)를 절대 추측하지 마세요. 항상 먼저 grep을 사용하거나 파일을 읽으세요.")
2. L2 (Phase Directors): 에이전트가 특정 단계(계획(Planning), 실행(Execution), 검증(Verification))에 진입할 때만 로드되는 오케스트레이션(Orchestration)입니다.
3. L3 (Skill Protocols): 특정 작업(자기 수정(self-correction) 등)을 위한 구체적인 지침이며, 해당 특정 작업이 진행 중일 때만 로드됩니다.

이것이 바로 **점진적 공개 (Progressive Disclosure)**입니다. 에이전트는 현재의 원자적 단계(atomic step)를 위해 반드시 필요한 지침만을 보게 됩니다.

나아가, Agent Rigor는 "알려진 양호한 상태(known-good state)" 정책을 강제합니다. 테스트가 실패할 경우, 에이전트는 단순히 같은 파일을 맹목적으로 계속 수정하지 않습니다. 대신 상태를 되돌리고(revert), 실제 증거를 분석하며, 새로운 접근 방식을 계획합니다. 더 이상 "이게 맞는 것 같다" 식의 커밋(commit)은 없습니다. 모든 것은 앞으로 나아가기 전에 경험적으로 증명되어야 합니다.

베이비시팅을 멈추고, 엔지니어링을 시작하세요

Cursor, Copilot 또는 그 어떤 코딩 어시스턴트(coding assistant)로 빌드하고 있다면, 당신에게는 규율 계층(discipline layer)이 필요합니다. 저희가 이를 어떻게 구현했는지는 여기 오픈 소스 리포지토리에서 확인하실 수 있습니다: Agent Rigor on GitHub.

만약 이것이 새벽 2시에 망가진 코드베이스를 되돌리는 수고를 덜어준다면, 별(star)을 눌러주세요. 더 중요한 것은, 만약 이 접근 방식이 틀렸다고 생각하신다면, 이슈(issue)를 열어 그 이유를 제게 알려달라는 것입니다.