무엇이 에이전트 루프(Agent Loop)를 유용하게 만드는가?

지난 며칠 동안 제 피드는 에이전트 루프(agent loops)에 관한 게시물들로 가득 찼습니다.

전달되는 메시지는 대개 동일한 아이디어의 변형입니다. 에이전트에게 한 번에 한 단계씩 프롬프트(prompting)를 주는 것을 멈추고, 스스로 행동하고, 자신의 작업을 평가하며, 목표를 향해 계속 나아갈 수 있는 시스템을 설계하기 시작하라는 것입니다. 미래는 우리가 하루 종일 에이전트에게 프롬프트를 입력하는 모습이 아닙니다. 우리가 다른 일을 하고 있거나, 심지어 잠을 자고 있는 동안에도 계속해서 진전을 이룰 수 있는 루프(loops)를 설계하는 것입니다.

그것은 이미 다 아는 이야기입니다.

제가 이해하지 못했던 것은 루프의 어떤 부분들이 실제로 중요한가 하는 점이었습니다.

_모델(model)_일까요? _도구(tools)_일까요? _메모리(memory)_일까요? _트리거(trigger)_일까요? 아니면 사람이 개입하지 않아도 실행될 수 있다는 사실일까요?

제가 찾은 대부분의 예시들은 개념을 설명했습니다. 어떻게 설계할지에 대해 생각하는 법을 설명하는 경우는 거의 없었습니다. 그리고 상황이 잘못되었을 때 어떤 일이 발생하는지를 보여주는 경우는 훨씬 더 적었습니다.

그래서 루프에 관한 또 다른 게시물을 읽는 대신, 저는 간단한 루프를 직접 만들어 보기로 했습니다.

Claude Code, Cloudinary Skills, 그리고 Cloudinary MCP servers를 사용하여, 저는 '이미지 자산의 전송 용량을 최소 20% 이상 줄인다'라는 간단한 목표를 가진 미디어 최적화 루프를 만들었습니다.

이제 답해야 할 질문은 단 하나뿐이었습니다:

무엇이 루프를 유용하게 만드는가?

모든 자동화가 루프인 것은 아닙니다.

유용한 루프가 되려면 몇 가지 요소가 함께 작동해야 합니다:

이 요소들 중 하나라도 빠지면, 루프는 무너지기 시작할 것입니다.

트리거 (Trigger)가 없으면 아무것도 시작되지 않습니다. 목표 (Goal)가 없으면 성공이 어떤 모습인지 알 수 없습니다. 지식 (Knowledge)이 없으면 에이전트 (Agent)는 추측하게 됩니다. 행동 (Actions)이 없으면 권장 사항만 제시할 수 있을 뿐입니다. 메모리 (Memory)가 없으면 매 실행마다 처음부터 다시 시작해야 합니다. 검증 (Verification)이 없으면 루프 (Loop)가 실제로 진전을 보이고 있는지, 아니면 단순히 그럴듯해 보이는 출력물만 생성하고 있는지 알기가 매우 어렵습니다.

마지막 포인트는 결국 프로젝트 전체에서 가장 중요한 교훈이 되었습니다. 그 원 안의 8가지 요소 중, 중앙을 가로지르는 하나의 짧은 체인이 루프의 성공 여부를 실제로 결정합니다. 이에 대해서는 나중에 더 자세히 다루겠습니다.

목표 계층 (The Goal Layer)

모든 것은 단순한 목표에서 시작되었습니다:

이미지 전달 가중치(delivery weight)를 최소 20% 감소시킬 것

이 목적이 성공의 모습을 결정했으며, 궁극적으로 루프가 내리는 모든 결정을 이끌었습니다.

처음에는 당연하게 들릴 수 있습니다. 하지만 그렇지 않았습니다. 프로젝트 후반부에 저는 루프의 동작 방식 중 놀라울 정도로 많은 부분이 처음에 목표를 얼마나 명확하게 정의하느냐에 달려 있다는 것을 발견했습니다.

지식 계층 (The Knowledge Layer)

에이전트에게는 Cloudinary에 대한 지식과 루프 자체가 어떻게 작동해야 하는지에 대한 지식이 모두 필요했습니다.

저는 에이전트가 변환 구문 (Transformation syntax)을 추측하거나, 학습 데이터로부터 최적화 모범 사례 (Optimization best practices)를 기억해내려 애쓰거나, 실행할 때마다 매번 자신만의 워크플로우 (Workflow)를 만들어내는 것을 원하지 않았습니다.

이를 해결하기 위해, 저는 Cloudinary Skills와 함께 커스텀 루프 스킬 (Custom loop skill)을 사용했습니다.

Cloudinary Skills는 도메인 지식 계층 (Domain knowledge layer) 역할을 했습니다. 이 경우, 변환 중심 스킬 (Transformation focused skill)은 최적화 전략, 변환 구문, 그리고 Cloudinary 모범 사례에 대한 가이드를 제공하여 에이전트가 메모리나 추측에 의존하지 않고 정보에 기반한 결정을 내릴 수 있도록 했습니다.

커스텀 루프 스킬은 워크플로우 자체를 정의했습니다. 이는 에이전트에게 목표를 읽고, 메모리를 조사하며, 결과를 평가하고, 상태를 업데이트하며, 루프를 계속할지 아니면 중단할지를 결정하는 방법을 알려주었습니다.

매 단계마다 에이전트에게 정확히 무엇을 해야 할지 지시하는 대신, 저는 재사용 가능한 Cloudinary 지식과 재사용 가능한 워크플로 (workflow)를 모두 제공했습니다. 그러면 루프 (loop)는 문제에 대해 추론하고, 행동을 취하며, 결과를 평가하고, 다음에 무엇을 할지 결정할 수 있었습니다.

액션 레이어 (The Action Layer)

지식만으로는 충분하지 않습니다. 루프가 실제 작업을 수행하려면 환경과 상호작용할 수 있는 능력이 필요합니다. 바로 이 지점에서 Cloudinary MCP 서버가 등장했습니다.

Asset Management MCP 서버를 통해 루프는 1MB보다 큰 이미지 에셋 (asset)을 찾아내고, 메타데이터 (metadata)를 조사하며, 가장 큰 최적화 기회를 우선적으로 파악할 수 있었습니다.

Environment Configuration MCP 서버를 통해 루프는 여러 에셋에 적용할 수 있는 최적화 패턴을 식별했을 때, 재사용 가능한 이름이 지정된 트랜스포메이션 (transformation)을 생성할 수 있었습니다. 동일한 트랜스포메이션 로직을 반복해서 생성하는 대신, 루프는 최적화 전략을 등록하고 향후 실행 시 재사용할 수 있었습니다.

기술 (Skills)과 MCP 서버가 결합되어 루프에 지식과 행동 능력을 모두 부여했습니다. 기술은 에이전트가 무엇이 일어나야 하는지 추론하도록 도왔고, MCP 서버는 그것을 실제로 수행할 수 있게 해주었습니다.

저에게 가장 인상적이었던 것은 개별적인 MCP 호출이 아니었습니다. 루프가 추론에서 행동으로 넘어가는 과정을 지켜보는 것이었습니다. 그것은 더 이상 단순히 최적화를 권장하는 수준에 머물지 않았습니다. 제 Cloudinary 계정을 조사하고, 기회를 식별하며, 발견한 내용에 기반하여 변경 사항을 적용할 수 있었습니다.

메모리 레이어 (The Memory Layer)

루프에는 이미 수행한 작업을 기억할 방법도 필요했습니다. 저는 다음과 같은 사항을 추적하는 간단한 메모리 파일을 사용했습니다:

• 이미 평가된 에셋 (assets)
• 이전 실행 요약
• 생성된 이름 지정 트랜스포메이션 (transformations)
• 현재 루프 상태

이를 통해 향후 실행 시 매번 처음부터 시작하는 대신, 이전 실행이 중단된 지점부터 이어서 작업을 수행할 수 있었습니다. 에이전트는 이미 처리된 내용을 확인하고 남은 작업에만 집중할 수 있었습니다.

목표(goal), 지식(knowledge), 행동(action), 그리고 메모리(memory) 레이어가 갖춰짐에 따라, 루프(loop)는 실제 작업을 수행하고 자신이 수행한 내용을 기억할 수 있게 되었습니다. 하지만 루프가 아직 할 수 없었던 것은 그 작업이 정말로 유용한지 판단하는 것이었습니다.

평가 레이어 (The Evaluation Layer) (내가 실수했던 부분)

루프의 첫 번째 버전은 성공적인 것처럼 보였습니다.

에이전트는 자산(assets)을 분석하고, 최적화 전략(optimization strategies)을 생성했으며, 평균적으로 거의 68%의 절감 효과를 보고했습니다. 만약 제가 거기서 멈췄다면, 아마도 프로젝트가 완료되었다고 생각했을 것입니다.

문제는 그 절감 수치들이 추정치(estimates)였다는 점입니다. 루프는 실제로 자신의 작업을 검증(verifying)하고 있지 않았습니다. 루프는 차원(dimensions), 형식(formats), 그리고 알려진 최적화 패턴(optimization patterns)을 살펴보고, 어느 정도의 최적화가 가능할지에 대해 근거 있는 추측(educated guesses)을 하고 있었습니다. 수치들은 합리적으로 보였습니다.

실제로 일어나고 있었던 일은 다음과 같습니다. 제가 작성한 원래의 루프 지침(instructions)은 에이전트에게 최적화가 절감 목표를 충족하는지 평가하라고 명령했지만, 그 방법(how)은 전혀 명시하지 않았습니다. 그래서 에이전트는 모호한 지침을 받았을 때 다른 합리적인 에이전트들이 하는 것처럼 행동했습니다. 바로 추정(estimated)을 한 것입니다. 에이전트는 일반적인 최적화 전략과 관련된 전형적인 절감 수치를 알고 있었고, 그 지식을 사용하여 확신에 찬 것처럼 들리는 숫자를 만들어냈습니다.

해결책은 더 똑똑한 모델이 아니었습니다. 더 정밀한 지침이었습니다.

저는 루프 명령에 한 섹션을 추가했습니다:

## Step 8 — 결과 평가 (Evaluate results)

처리된 각 자산에 대해 다음을 결정하십시오:
...

그게 전부였습니다. 저는 에이전트에게 무엇을 어떻게 측정하라고 말하지 않았습니다. 단지 "추정된(estimated)" 것과 "측정된(measured)" 것은 서로 다른 것이며, 자신이 나에게 주는 값이 어느 쪽인지 라벨을 붙여야 한다는 사실만을 알려주었습니다.

그 단 하나의 지침이 전체 실행 과정을 바꾸어 놓았습니다. 에이전트는 최적화된 URL을 실제로 가져오고(fetching), 실제 바이트 크기(byte sizes)를 원본과 비교하기 시작했습니다. 왜냐하면 이제 자신의 숫자가 어느 범주에 속하는지에 대해 정직해야 했기 때문입니다.

검증이 모든 것을 바꾸었다

평가 단계(evaluation step)를 추가한 후, 동일한 자산 배치에 대한 추정 절감액(estimated savings) 대 실제 측정 절감액(measured savings)은 다음과 같습니다:

추정치가 가리키는 곳에 도달한 것은 거의 없었습니다.

아기 고양이 GIF가 핵심적인 수치입니다: 예측치는 70%였으나, 측정치는 0%였습니다. 원인을 파헤쳐 보니 테스트 요청이 WebP를 제대로 협상(negotiating)하지 못했고, 이로 인해 Cloudinary의 자동 포맷 선택 기능이 GIF 전송으로 되돌아간(fall back) 것이었습니다. 최적화 전략 자체가 틀린 것은 아니었습니다. 측정 결과는 해당 요청에서 일어나야 했던 일과 실제로 일어난 일 사이의 간극을 드러냈습니다.

하지만 GIF가 진짜 핵심은 아닙니다. food/spices를 보십시오: 추정치는 30%였으나, 측정치는 61.3%였습니다. breakfast를 보십시오: 추정치는 53%였으나, 측정치는 77.3%였습니다. 이들은 근접하지 않았습니다. 에이전트의 추정치는 배치 내 거의 모든 자산에 대해 양방향 모두 5~31 퍼센트 포인트(percentage points)만큼 차이가 났습니다.

이 부분이 실제로 제가 이 문제를 생각하는 방식을 바꾸어 놓았습니다. 추정치는 단순히 '부정확(imprecise)'했던 것이 아니었습니다. 그것은 '신뢰할 수 없는(unreliable)' 상태였으며, 이는 단순히 보정 계수(fudge factor)로 수정할 수 있는 성격의 것이 아니었습니다. 왜냐하면 때로는 실제 수치가 예측보다 훨씬 좋았고, 때로는 훨씬 나빴기 때문입니다. 검증(verification) 없이는 어떤 자산이 어느 범주에 속하는지 알 방법이 없었습니다. 루프(loop)는 단 하나의 확신에 찬 평균값을 보고하고 다음 단계로 넘어갔을 것이고, 저는 그것을 믿었을 것입니다.

8단계(Step 8) 지침이 적용됨에 따라, 이제 루프는 최적화된 Cloudinary URL을 생성하고, 변환된 자산을 요청하며, 실제 전달된 바이트 크기(byte sizes)를 측정하고, 이를 원본과 비교합니다. 또한 신뢰도가 낮은 결과에는 플래그(flagging)를 표시하여 제가 어디를 먼저 살펴봐야 할지 알려줍니다.

루프는 옳았습니다. 제가 틀렸습니다.

실제 측정을 통한 첫 번째 실행 후, 루프는 여전히 7개의 적격한 자산이 남아 있다고 보고했습니다.

저의 첫 번째 반응은, '왜 계속 진행하지 않았지?'였습니다.

저는 다시 돌아가 목표를 확인했습니다. 목표는 다음과 같지 않았습니다:

1MB보다 큰 모든 자산을 최적화하라.

그것은 다음과 같았습니다:

전달 무게(delivery weight)를 20% 줄여라.

그것들은 비슷하게 들립니다. 하지만 완전히 다른 동작을 만들어냅니다.

루프(loop)가 멈췄을 때, 처리된 자산 전체에 대해 측정된 평균 절감액은 이미 20%를 훨씬 상회하고 있었습니다. 목표는 달성되었습니다. 루프의 관점에서는 작업이 완료된 것입니다. 남은 7개의 자산을 처리한다고 해서 결과가 더 진실해지지는 않았을 것입니다.

루프는 혼란스러워하지 않았습니다. 혼란스러웠던 것은 저였습니다.

저는 한 가지 목표를 적어두었지만, 머릿속에는 다른 목표를 품고 있었습니다. 루프는 실제로 적혀 있는 목표, 즉 실제 수치와 대조하여 확인할 수 있는 목표를 따랐습니다. 루프는 정확히 멈춰야 할 시점에 멈췄습니다.

루프는 당신이 의도한 목표가 아니라, 당신이 정의한 목표를 충실히 추구합니다.

실제로 작업을 수행하고 있었던 체인 (The Chain)

돌이켜보면, 0%를 측정했던 GIF와 루프가 그대로 두었던 7개의 자산은 동일한 교훈을 두 번 말해준 것과 같습니다.

앞서 저는 유용한 루프가 갖춰야 할 8가지 요소인 트리거(trigger), 목표(goal), 지식(knowledge), 행동(action), 평가(evaluation), 메모리(memory), 결정(decision), _반복(repeat)_을 보여드렸습니다. 그것은 아키텍처(architecture), 즉 당신이 조립해야 할 부품들입니다. 하지만 그것이 목표를 향한 진보를 실제로 이끄는 부분은 아닙니다. 그 부분은 더 작습니다:

8가지 요소가 아키텍처라면, 이것은 엔진입니다. 이 프로젝트의 다른 모든 것들, 즉 트리거, 기술(Skills), MCP 서버, 메모리 파일은 모두 이 체인(chain)을 지원하기 위해 존재합니다. 하지만 이것이야말로 어떤 것을 한 번 실행되고 보고하는 스크립트가 아닌, '루프'로 만드는 핵심 부분입니다.

스크립트는 실행(Action) 단계를 수행할 수 있습니다. 하지만 오직 루프(Loop)만이 측정(Measure) → 검증(Verify) → _결정(Decide)_을 수행할 수 있으며, 그 결과를 사용하여 반복 여부를 결정할 수 있습니다. 측정(Measurement)은 루프에 목표와 동일한 단위의 수치를 제공했습니다. 검증(Verification)은 그 수치와 목표치를 비교하는 과정이었습니다. 결정(Decision)은 루프가 그 결과값을 가지고 수행하는 동작으로, 작업이 남아 있더라도 목표가 달성되었다면 중단하는 것을 의미합니다.

측정(Measurement)이 없다면 루프는 검증할 대상이 없게 됩니다. 검증(Verification)이 없다면 결정(Decision)은 그저 자신감 있는 어조를 띤 추측에 불과하게 됩니다. 결정(Decision)이 없다면, 행동은 하지만 언제 멈춰야 할지는 모르는 에이전트가 됩니다.

실전에서의 루프 (The Loop, In Practice)

한 걸음 물러나서 보면, 이 프로젝트에서 각 레이어(Layer)가 실제로 무엇이었는지는 다음과 같습니다: