🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

이 글은 에이전트를 잘 작동시키려면 단일 모델 성능보다 작업 실행, 검증, 이벤트 구동, 지속 개선을 겹겹이 설계하는 ‘루프 엔지니어링’이 핵심이라고 설명한다.

📌 핵심 요약

• 에이전트의 기본 구조는 LLM에 맥락을 주고 도구를 반복 호출하게 하는 단순한 루프이지만, 실제로 가치 있는 업무를 안정적으로 수행하려면 그 주변에 더 많은 루프가 필요하다.
• 첫 번째 루프는 에이전트 루프이며, 모델이 도구를 사용해 파일 읽기, 문서 작성, 저장소 조작, 풀 리퀘스트 생성 같은 실제 작업을 수행하도록 만든다.
• 두 번째 검증 루프는 결과물을 루브릭이나 테스트로 평가하고, 실패하면 피드백을 다시 모델에 전달해 품질과 일관성을 높인다.
• 세 번째 이벤트 구동 루프는 일정, 웹훅, 채널 메시지 같은 외부 이벤트가 에이전트 실행을 자동으로 촉발하게 하여 에이전트를 더 큰 시스템 안의 지속 실행 구성요소로 만든다.
• 네 번째 힐 클라이밍 루프는 실행 traces를 분석해 프롬프트, 도구, 그레이더, 나아가 모델이나 메모리·검색된 스킬 같은 보조 맥락까지 개선하는 지속적 개선 구조를 만든다.

🧩 주요 포인트

1. 에이전트의 기본 구조는 LLM에 맥락을 주고 도구를 반복 호출하게 하는 단순한 루프이지만, 실제로 가치 있는 업무를 안정적으로 수행하려면 그 주변에 더 많은 루프가 필요하다.
2. 첫 번째 루프는 에이전트 루프이며, 모델이 도구를 사용해 파일 읽기, 문서 작성, 저장소 조작, 풀 리퀘스트 생성 같은 실제 작업을 수행하도록 만든다.
3. 두 번째 검증 루프는 결과물을 루브릭이나 테스트로 평가하고, 실패하면 피드백을 다시 모델에 전달해 품질과 일관성을 높인다.
4. 세 번째 이벤트 구동 루프는 일정, 웹훅, 채널 메시지 같은 외부 이벤트가 에이전트 실행을 자동으로 촉발하게 하여 에이전트를 더 큰 시스템 안의 지속 실행 구성요소로 만든다.
5. 네 번째 힐 클라이밍 루프는 실행 traces를 분석해 프롬프트, 도구, 그레이더, 나아가 모델이나 메모리·검색된 스킬 같은 보조 맥락까지 개선하는 지속적 개선 구조를 만든다.

🧠 상세 정리

1. 좋은 에이전트에는 모델보다 넓은 실행 장치가 필요하다

글은 에이전트가 현실 세계에서 행동을 취해 업무를 자동화한다는 점에서 유용하다고 출발한다. 그러나 가치 있는 일을 안정적으로 수행하게 하려면 좋은 모델 하나만으로는 부족하고, 특정 작업 집합에 맞게 설계된 하네스가 필요하다고 강조한다. 가장 기본적인 알고리즘은 LLM에 맥락을 주고 완료될 때까지 도구를 반복 호출하게 하는 것이지만, 저자는 이 루프가 에이전트를 움직이는 유일한 루프가 아니라고 본다. 따라서 글의 핵심은 단일 루프가 아니라 여러 루프를 쌓고 확장해 에이전트의 신뢰성과 활용도를 높이는 방식이다.

2. 첫 번째 루프: 모델이 도구를 반복 호출하는 에이전트 루프

가장 안쪽의 루프는 모델이 작업이 끝날 때까지 도구를 호출하는 구조다. LangChain의 create_agent는 모델과 도구를 연결해 이 기본 에이전트 루프를 구성하게 해 주며, 도구는 에이전트가 실제 세계에서 행동할 수 있게 만드는 핵심 수단이다. 글은 내부 문서 에이전트를 예로 들어, 문서 개선 요청을 받으면 모델이 변경 계획을 세우고 초안을 만들며 저장소 복제, 파일 읽기, 문서 작성, 풀 리퀘스트 열기 같은 일을 수행한다고 설명한다. 이 단계의 목적은 일을 자동화하는 것이며, 아직 결과의 품질이나 반복적 개선까지 보장하는 단계는 아니다.

3. 두 번째 루프: 결과를 평가하고 피드백하는 검증 루프

에이전트 루프는 일을 수행하지만 첫 시도에서 항상 정확하거나 일관된 결과를 내지는 않는다. 그래서 품질이 중요할 때는 결과물을 루브릭에 따라 평가하고 부족하면 피드백을 다시 모델에 보내는 검증 루프가 유용하다. 이때 그레이더는 결정론적 방식일 수도 있고, LLM을 판정자로 사용하는 에이전트형 방식일 수도 있으며, 글은 RubricMiddleware나 create_agent의 after_agent 훅으로 이 패턴을 구성할 수 있다고 설명한다. 문서 작성 에이전트의 경우 링크가 모두 해결되는지, CI가 통과하는지, diff가 요청 범위에 맞는지를 검사해 수동 검토 없이도 특정 오류군을 잡아낸다. 다만 검증은 실행 시간과 비용을 늘리므로, 속도보다 품질이 중요한 생산 환경에서 특히 가치가 크다고 정리한다.

4. 세 번째 루프: 이벤트가 에이전트를 실행시키는 시스템 루프

세 번째 루프는 에이전트를 사람이 직접 호출하는 도구가 아니라 더 큰 생태계 안에서 계속 작동하는 구성요소로 만든다. 새 문서가 들어오거나, 일정이 트리거되거나, 웹훅이 도착하면 에이전트가 자동으로 실행되는 방식이다. 글은 LangSmith Deployment가 cron 일정과 웹훅을 포함한 트리거 인프라를 지원한다고 설명하며, openclaw의 하트비트처럼 에이전트를 항상 켜진 능동적 조수로 만드는 사례도 언급한다. 또한 문서 에이전트는 Fleet의 채널과 스케줄을 통해 Slack의 #docs-plz 채널에 메시지가 오면 실행되도록 구성되어 있다고 소개한다. 이 루프의 핵심 효과는 자동화된 작업을 규모 있게 운영 시스템 속으로 넣는 것이다.

5. 네 번째 루프: 실행 기록을 분석해 하네스를 개선하는 힐 클라이밍

앞의 세 루프가 일을 자동화한다면, 네 번째 루프는 개선 자체를 자동화한다. 모든 에이전트 실행은 모델의 행동, 호출한 도구, 그레이더 피드백 등을 담은 trace를 남기며, 이 기록에는 무엇이 잘되고 무엇이 문제인지에 대한 높은 가치의 신호가 들어 있다. 힐 클라이밍 루프는 이러한 traces를 분석 에이전트에 입력하고, 발견 내용을 바탕으로 프롬프트, 도구 설정, 그레이더 설정 같은 하네스 구성을 개선한다. 글은 LangSmith Engine을 이 네 번째 루프를 계측하는 수단으로 제시하며, 문서 에이전트 traces에서 반복 문제가 감지되면 문제가 있는 프롬프트나 도구를 수정하라는 이슈가 생성된다고 설명한다. 중요한 점은 바깥 루프가 단순히 다시 실행하는 데 그치지 않고 안쪽 에이전트 루프 자체를 업데이트한다는 것이다.

6. 인간 감독은 자동화 루프 안에서 계속 필요하다

저자는 자동화가 인간을 루프에서 제거한다는 뜻은 아니라고 분명히 말한다. 링크가 해결되는지 같은 항목은 자동 그레이더가 확인할 수 있지만, 독자에게 맞는 프레이밍인지 같은 판단은 맥락, 경험, 취향을 가진 인간 검토가 필요한 영역이다. 일부 전문성은 프롬프트나 도구에 코드화할 수 있지만, 금융 거래나 데이터베이스 작업처럼 민감한 행동에는 실시간 인간 검토가 필수적이라고 본다. LangChain의 오픈소스 프레임워크들은 에이전트 루프에서 민감한 도구 호출 전 인간 입력을 요구하거나, 검증 루프에서 인간이 그레이더 역할을 하거나, 애플리케이션 루프에서 최종 출력 승인 절차를 두는 방식의 human in the loop 구성을 일급 요소로 지원한다고 설명한다.

7. 루프 엔지니어링의 결론: 가치는 바깥 루프에서 누적된다

글은 네 가지 루프를 표로 정리하며 에이전트 루프는 작업 자동화, 검증 루프는 품질과 정확성 보장, 이벤트 구동 루프는 규모 있는 자동 실행, 힐 클라이밍 루프는 하네스 개선을 담당한다고 요약한다. 저자는 이것이 실제적인 loop engineering 또는 swyx가 말한 loopcraft의 모습이라고 말한다. 글의 결론은 에이전트의 잠재력이 모델 자체보다 그 주변에 어떤 루프를 쌓느냐에 달려 있다는 쪽으로 이동한다. 특히 오래전부터 중요하게 다뤄진 첫 번째와 두 번째 루프를 넘어, 이제는 에이전트를 조직의 생태계 안에 심고 생산 실행 결과에 따라 계속 개선되는 세 번째와 네 번째 루프에 더 집중해야 한다고 주장한다.

🧾 핵심 주장 / 시사점

• 에이전트 설계의 핵심 단위는 단일 프롬프트나 모델 호출이 아니라, 실행·검증·트리거·개선이 서로 맞물리는 반복 구조다.
• 검증 루프는 비용과 지연을 늘리지만, 생산 환경처럼 품질이 속도보다 중요한 상황에서는 오류를 체계적으로 줄이는 핵심 장치로 제시된다.
• 가장 큰 장기 가치는 에이전트를 조직의 이벤트 흐름에 연결하고, 실제 실행 trace를 다시 하네스 개선으로 되돌리는 학습 루프에서 발생한다.

✅ 액션 아이템

• 에이전트 설계를 단일 모델 성능 중심에서 벗어나 실행, 검증, 이벤트, 힐클라이밍 루프를 함께 포함한 다층 구조로 정한다.
• 에이전트 루프는 파일 읽기, 문서 작성, 저장소 조작, PR 생성 같은 실제 작업을 반복 수행하도록 도구 호출 경로를 확정한다.
• 검증 루프에서 루브릭과 테스트 결과를 즉시 반영해 실패 피드백을 모델로 되돌리고, traces 분석으로 프롬프트·도구·그레이더를 갱신한다.

❓ 열린 질문

• 실제 작업 자동화에서 어떤 작업은 에이전트 루프에 넣고 어떤 작업은 사람이 최종 승인해야 하는 경계는 어떻게 정할 것인가?
• 루브릭 또는 테스트가 실패했을 때 어느 지표를 우선 적용해 재시도와 중단을 판단할 기준이 될 것인가?
• 일정·웹훅·채널 이벤트가 에이전트를 촉발할 때 호출 빈도와 범위를 조절해 안정성을 유지할 판단 기준은 무엇인가?