Ralph Loop만으로는 부족합니다
요약
단순한 반복 루프(Ralph Loop) 방식의 에이전트 설계가 가진 한계를 지적하며, 유한 상태 머신(Finite State Machine)을 활용한 설계의 중요성을 강조합니다. 상태 머신을 통해 무한 루프, 컨텍스트 오버플로, 목표 표류 문제를 해결하고 관측 가능성을 높일 수 있습니다.
핵심 포인트
- 단순 루프 방식은 작업 상태를 인지하지 못해 무한 루프나 목표 표류를 유발함
- 유한 상태 머신(FSM)을 통해 계획, 구현, 검토 등 명확한 단계를 정의해야 함
- 상태 머신은 컨텍스트 오버플로를 방지하고 에러 상태를 명시적으로 관리함
- 상태 기반 설계는 에이전트의 실행 과정을 추적하는 관측 가능성을 제공함
"저는 더 이상 Claude에게 프롬프트를 작성하지 않습니다. 제 업무는 루프(loop)를 작성하는 것입니다."
— Boris Cherny, Claude Code 제작자
그가 왜 그렇게 말하는지는 이해하지만, 저는 다르게 표현하고 싶습니다.
개발자의 업무는 루프를 작성하는 것이 아닙니다. 그것은 상태 머신 (state machines)을 설계하는 것입니다.
모든 주요 에이전트 프레임워크(agent framework) — Claude Code, Codex, Cursor, LangGraph — 는 내부적으로 동일한 작업을 수행합니다. while 루프가 LLM을 호출하고, 도구(tool)를 사용할지 확인하고, 도구를 실행한 뒤, 완료될 때까지 반복합니다. 루프는 단순히 해결된 문제가 아닙니다. 그것은 지루한 문제입니다.
어려운 부분은 그 주변의 모든 것입니다.
루프는 작업이 어떤 상태에 있는지 알지 못합니다. 그저 무언가 고장 나거나 토큰(tokens)이 다 떨어질 때까지 계속 진행할 뿐입니다. 이것이 바로 Ralph Loop입니다 — 코를 crayon(크레용)으로 막았던 심슨 가족의 아이 이름에서 따왔습니다. 에이전트, 무한 루프, 시작. Ralph Loop는 작동하고 유명하지만, 작업 중 어디에 있는지에 대한 기억이 전혀 없습니다. Ralph처럼, 그것은 왜 그러는지도 모른 채 계속 나아갑니다.
해결책: 유한 상태 머신 (Finite State Machine)
NBA 결승전을 생각해 보세요. Spurs와 Knicks는 즉흥적으로 움직이지 않습니다 — 모든 소유권(possession)에는 상태가 있습니다. 속공(Fast break). 인바운드 플레이(Inbound play). 하프코트 세트(Half court set). 각각은 다음에 어떤 일이 일어날지에 대한 구체적인 읽기(reads)와 트리거(triggers)를 가지고 있습니다. 포인트 가드 De'Aaron Fox는 즉흥적으로 행동하는 것이 아닙니다. 시스템이 그에게 어떤 상황에 처해 있는지 알려주고, 상황이 그에게 무엇을 해야 할지 알려줍니다.
여러분의 에이전트도 같은 방식으로 작동합니다. 여러분은 계획(planning), 구현(implementing), 검토(reviewing), 오류 처리(error handling)와 같은 단계들을 정의하고, 각 전이(transition)를 트리거하는 요소를 정의합니다. 에이전트는 오케스트레이션(orchestrate)하는 것이 아닙니다. 그것은 실행(execute)합니다. 상태당 하나의 집중된 작업만 수행합니다.
이것이 프로덕션에서 중요한 이유
에이전트가 고장 날 때는 거의 항상 다음 세 가지 중 하나입니다:
- 무한 루프 (Infinite loops) — 누군가 알아차리기 전에 한 시스템이 동일한 답변을 58번 반복했습니다.
- 컨텍스트 오버플로 (Context overflow) — 히스토리가 너무 길어져서 모델이 조용히 무언가를 잊기 시작합니다.
- 목표 표류 (Goal drift) — 70번의 턴이 지나자, "인증(auth)은 건드리지 마세요"라는 지침이 완전히 증발해 버렸습니다.
상태 머신 (State machines)은 이 세 가지 문제를 모두 해결합니다. 루프는 토큰이 소진될 때까지 도는 것이 아니라, 리스트가 비워질 때까지 실행됩니다. 목표는 압착되는 컨텍스트 (context) 속에 있는 것이 아니라 전이 로직 (transition logic) 안에 존재합니다. 그리고 실패는 걷잡을 수 없이 나빠지는 것이 아니라, 다음 단계에 대한 명시적인 규칙을 가진 에러 상태 (error state)로 전이됩니다.
관측 가능성 (Observability)
상태 머신은 관측 가능성 (observability) 또한 제공합니다. 에이전트가 고장 나기 전까지 거쳐온 정확한 상태 시퀀스 (sequence of states)를 확인할 수 있습니다.
그것이 바로 Entire가 만들어진 목적입니다. 에이전트 세션 전체에 걸친 완전한 트랜스크립트 기록 (transcript history)을 제공하여, 에이전트가 무엇을 했는지뿐만 아니라 그 행동을 할 때 어떤 상태였는지까지 확인할 수 있게 합니다.
검사할 수 없는 시스템은 시스템이 아닙니다. 그것은 그저 분위기만 좋은 루프일 뿐입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기