모두가 프롬프트에 대해 이야기하지만, 에이전트가 실제로 실패하는 지점은 루프(Loop)입니다

프롬프트 엔지니어링 (Prompt engineering)이 모든 관심을 받고 있습니다. 그것은 눈에 보이는 부분이며, 복사하고 공유하며 스스로 똑똑하다고 느낄 수 있는 요소입니다. 하지만 제가 구축하거나 벤치마킹한 모든 에이전트 시스템 (agentic system)에서, 문제가 발생하는 지점은 프롬프트가 아닙니다. 바로 루프 (loop)입니다.

에이전트 (agent)는 단일한 프롬프트-응답 (prompt-and-response) 구조가 아닙니다. 그것은 루프입니다. 상태를 관찰하고 (observe), 행동을 취하며 (take an action), 결과를 평가하고 (evaluate), 계속할지 결정하는 (decide) 과정입니다. 완료될 때까지, 혹은 에이전트가 포기하거나, 나선형으로 오류가 심화되거나, 조용히 잘못된 결과물을 만들어낼 때까지 이 과정을 반복합니다.

루프 엔지니어링 (Loop engineering)은 루프가 실패하는 수많은 방식 중 하나로 빠지는 대신, 올바른 결과로 수렴하도록 해당 루프를 설계하는 규율입니다.

다음은 1,412회의 실행을 통해 12개의 모델을 벤치마킹하고, 루프가 실제로 작동해야만 하는 프로덕션 수준의 지원 에이전트 (support agent)를 구축하며 제가 루프에 대해 배운 내용입니다.

루프를 명확하게 정의하자면
프레임워크 (framework)의 이름을 모두 걷어내면, 모든 에이전트는 동일한 사이클을 실행합니다:

[

]

관찰 (Observe): 에이전트가 현재 상태인 작업 (task), 이전 결과, 사용 가능한 도구 (tools)를 읽습니다.

행동 (Act): 행동을 선택하고 실행합니다.

평가 (Evaluate): 무슨 일이 일어났는지 평가합니다.

결정 (Decide): 계속할지, 접근 방식을 바꿀지, 아니면 종료할지 결정합니다.

이 네 가지 단계 각각이 루프가 실패할 수 있는 지점입니다. 그리고 이러한 실패는 이론적인 것이 아니라, 제가 기록으로 가지고 있는 실제 사례들입니다.

루프가 실제로 실패하는 방식 (증거 포함)

제가 RDAB 벤치마크를 실행했을 때, 가장 흥미로운 실패는 오답이 아니었습니다. 그것은 루프의 실패, 즉 에이전트의 반복 사이클 (iteration cycle)이 특정적이고 반복 가능한 방식으로 무너지는 것이었습니다.

[

]

네 가지 사례 모두에 나타난 패턴을 보십시오. 이 중 어느 것도 프롬프트 문제는 아닙니다. 더 나은 시스템 프롬프트(System Prompt)로 토큰 스파이럴 (Token Spiral)을 해결할 수는 없습니다. 지시사항의 문구를 바꾼다고 해서 모델이 샌드박스 (Sandbox) 제약 조건에 적응하게 만들 수도 없습니다. 이것들은 에이전트가 관찰(Observe)하고, 평가(Evaluate)하며, 계속 진행할지 결정(Decide)하는 방식, 즉 루프(Loop) 구조의 실패입니다.

해결책은 더 똑똑한 에이전트가 아니라, 더 잘 설계된 루프입니다

에이전트가 실패할 때 본능적으로 더 유능한 모델이나 더 정교한 프롬프트를 찾게 됩니다. 이는 증상만을 치료하는 것입니다. 루프 엔지니어링 (Loop Engineering)은 구조를 다룹니다. 네 가지 설계 원칙이 대부분의 역할을 수행합니다.

루프를 제한하십시오 - 모든 루프에는 중단 조건이 필요합니다

반복 횟수(Iterations)나 토큰에 대한 엄격한 제한이 없는 루프는 토큰 스파이럴 (Token Spiral)이 발생하기를 기다리는 것과 같습니다. Claude의 토큰 스파이럴 사례는 모델의 결함이 아니라 예산(Budget)의 부재였습니다. 루프에는 단계별 상한선(Step Ceiling)과 토큰 상한선(Token Ceiling)이 있어야 하며, 외부 요인에 의해 강제 종료될 때까지 실행되는 대신, 둘 중 하나라도 도달하면 중단하고 에스컬레이션 (Escalate)해야 합니다.

에이전트가 환경을 읽을 수 있게 만드십시오

grok 네임스페이스 (Namespace)의 사각지대 문제는 에이전트가 중요한 제약 조건을 관찰할 수 없었기 때문에 발생했습니다. 에이전트는 이미 존재하는 것을 계속해서 임포트(Import)하려고 시도했습니다. 잘 설계된 루프는 관찰 (Observe) 단계에서 관련 환경 상태를 드러내어, 에이전트가 눈을 가린 채 행동하지 않도록 합니다. 만약 에이전트가 실패하는 행동을 계속 반복한다면, 그것은 관찰 단계가 에이전트에게 필요한 정보를 제공하지 못하고 있다는 신호입니다.

행위자(Actor)와 평가자(Evaluator)를 분리하십시오

'정답은 맞지만, 자체 점검(self-check)은 하지 않는' 실패는 성공처럼 보이기 때문에 가장 위험합니다. 결과를 생성한 에이전트는 그것을 판단하기에 적절하지 않은 개체입니다. 이미 스스로 확신하고 있기 때문입니다. 해결책은 루프(loop) 내에 독립적인 평가 단계를 두는 것입니다. 즉, 별도의 체크, 별도의 모델, 또는 행위자(actor)가 제어할 수 없는 결정론적 단언(deterministic assertion)을 도입해야 합니다.

평가 루프를 시스템으로 다시 연결하십시오

실패를 포착하지만 시스템을 변화시키지 못하는 평가는 막다른 길입니다. 각 루프 반복(iteration)을 평가하는 목적은 수정 사항을 다음 반복으로, 에이전트의 지침(instructions)으로, 그리고 동일한 실패가 두 번 발생하지 않도록 하는 회귀 테스트(regression test)로 다시 피드백하는 것입니다.

루프가 제대로 작동할 때의 모습

의도적으로 구조화된 루프를 사용하여 제가 구축한 통신 지원 에이전트인 RelayOps를 통해 이를 구체적으로 설명하겠습니다.

파이프라인은 다음과 같습니다: 결정론적 액세스 게이트(deterministic access gate) → 의도 분류기(intent classifier) → 라우터(router) → 범위가 지정된 도구(scoped tools) / RAG → 독립적인 가드레일(guardrail) → 응답 또는 상담원에게 전달.

이 루프는 부수적인 것이 아니라 설계된 것입니다. 액세스 게이트는 어떤 모델도 요청에 손을 대기 전에 실행되며, 이는 LLM이 무시할 수 없는 결정론적인 체크입니다. 가드레일은 응답이 고객에게 도달하기 전에 차단할 수 있는 독립적인 평가 단계입니다. 그리고 자율적으로 행동할지 아니면 사람에게 에스컬레이션(escalate)할지에 대한 결정은 신뢰도와 리스크를 기준으로 제어되는 루프 내의 명시적인 분기(branch)입니다.

다음은 루프가 중요하다는 것을 증명하는 부분입니다. RelayOps는 자기 선호 편향(self-preference bias)을 피하기 위해 LLM-as-judge(판사로서의 LLM), 즉 교차 계열 판사(cross-family judge, 한 모델 계열이 다른 계열을 사용할 수 있는 에이전트를 채점하는 방식)를 사용하여 적대적 평가(adversarial evaluation)를 수행합니다.

한 FAQ 사례에서 결정론적 체크는 통과했습니다. 에이전트가 올바른 지식 베이스(knowledge base) 문서를 인용했기 때문입니다. 하지만 판사는 이를 실패로 처리했습니다. 답변이 출처를 인용하기는 했지만, 질문에 직접적으로 답하지 않았기 때문입니다. 검색(retrieval) 단계에서 잘못된 스니펫(snippet)이 첫 번째 순위로 매겨졌기 때문에, 정답 대신 문제 해결(troubleshooting) 조각을 먼저 제시했습니다.

'인용구가 존재하는가?'라고 묻는 규칙 기반 체크(rule-based check)는 통과했습니다. 하지만 '실제로 답변을 했는가?'라고 묻는 독립적인 평가자(independent evaluator)는 실패 판정을 내렸습니다. 그 격차가 바로 '정답은 맞지만 자가 점검(self-check)은 하지 않은' 실패 사례이며, 루프(loop)에 별도의 평가자가 있었기에 포착될 수 있었습니다.

그리고 결정적으로, 루프가 완성되었습니다. 이 실패는 실제 수정(타이밍 스니펫이 첫 번째 순위로 오도록 하는 가벼운 어간 추출(light stemming))과 더불어, '인용은 하지만 답변은 하지 않는' 응답이 이제 오프라인 스위트(offline suite)에서도 실패하도록 만드는 결정론적 회귀 어설션(deterministic regression assertion)을 이끌어냈습니다. 포착되었고, 수정되었으며, 재발 방지책까지 마련되었습니다. 이것이 루프가 엔드 투 엔드(end-to-end)로 작동하는 방식입니다. 에이전트가 똑똑해서가 아니라, 루프가 설계(engineered)되었기 때문입니다.

루프 엔지니어링(Loop engineering) vs 프롬프트 엔지니어링(Prompt engineering)

이 둘은 서로 다른 문제를 해결하기 때문에 그 차이를 명확히 구분할 가치가 있습니다.

두 가지 모두 필요합니다. 하지만 프롬프트 엔지니어링에는 한계점이 존재합니다. 더 나은 프롬프트가 구조적으로 망가진 루프를 고칠 수는 없습니다. 토큰의 나선형 증폭(token spiral), 네임스페이스 사각지대(namespace blind spot), 확인되지 않은 출력(unchecked output) 등은 어떤 프롬프트로도 해결할 수 없습니다. 루프는 반드시 설계되어야 합니다.

여기서 얻어야 할 교훈

에이전트는 프롬프트가 아니라 루프에서 실패합니다. 제가 계속 목격하는 네 가지 실패 모드—수렴하지 못한 채 나선형으로 회전하기, 환경에 대해 눈먼 상태로 행동하기, 너무 일찍 멈추기, 그리고 자신의 작업물을 전혀 점검하지 않기—는 모두 구조적인 문제입니다.

의도적으로 루프를 설계하십시오. 정지 조건(stop conditions)을 부여하고, 환경을 읽기 쉽게 만들며, 행위자(actor)와 평가자(evaluator)를 분리하고, 평가 피드백을 다시 시스템으로 환류(close)시키십시오. RelayOps FAQ의 실패 사례는 이 논증을 축소해 놓은 것과 같습니다. 독립적인 평가자가 규칙을 통과한 것을 잡아냈고, 그 수정 사항은 회귀 테스트(regression test)를 통해 고정되었습니다.

에이전트가 더 똑똑해질 필요는 없습니다. 루프가 더 잘 설계되어야 합니다. 그것은 설계(design)의 문제이며, 설계 문제는 실제로 해결할 수 있는 문제입니다.

당신을 가장 힘들게 했던 루프의 실패 사례는 무엇인가요? 나선형(spiral)으로 빠지는 현상인가요, 사각지대(blind spot)인가요, 아니면 틀린 결과물을 자신 있게 생성하면서도 전혀 알아차리지 못하는 에이전트인가요?