The Art of Loop Engineering — 루프를 쌓아 에이전트를 운영하는 법

한 줄 요약

LangChain의 The Art of Loop Engineering은 에이전트의 기본 구조를 “모델이 도구를 반복 호출하는 루프”로 설명한 뒤, 실전 에이전트는 그 위에 검증 루프, 이벤트 기반 실행 루프, 운영 trace를 바탕으로 하네스를 개선하는 hill climbing 루프를 겹겹이 쌓아야 한다고 주장한다.

한국어 번역

에이전트가 유용한 이유는 실제 세계에서 행동을 수행해 일을 자동화하도록 도와주기 때문이다. 하지만 에이전트가 가치 있는 일을 안정적으로 하게 만들려면 좋은 모델만으로는 부족하다. 특정 작업 집합에 맞게 세심하게 설계된 하네스가 필요하다.

에이전트의 핵심 알고리즘은 단순하다. LLM에 컨텍스트를 주고, 작업이 끝날 때까지 루프 안에서 도구를 호출하게 하는 것이다. 이것이 가장 기본적인 루프다. 하지만 에이전트를 움직이는 루프는 이것 하나가 아니다. 최근 swyx는 “loopcraft: the art of stacking loops”라는 글에서, 더 효과적인 에이전트를 만들기 위해 루프를 쌓고 확장할 수 있다는 아이디어를 잘 설명했다.

아래는 LangChain이 이 스택을 바라보는 방식과, 각 레벨을 LangChain primitive로 계측하는 방법이다.

루프 1: 에이전트

핵심적으로 에이전트란 작업이 완료될 때까지 모델이 루프 안에서 도구를 호출하는 것이다.

LangChain의 create_agent가 제공하는 것이 바로 이것이다. 원하는 모델을 고르고, 도구를 연결하면 작동하는 에이전트 루프가 생긴다. 도구는 에이전트가 실제 세계에서 행동할 수 있게 해 주는 수단이다.

LangChain의 내부 문서 에이전트를 예로 들어 보자. 이 예시는 이후 글 전체에서 동기 부여 사례로 사용된다. 첫 번째 루프 레벨에서 이 에이전트는 문서 개선 요청을 받고, 모델은 변경 계획과 초안을 만든 다음, 저장소 clone, 파일 읽기, 문서 작성, pull request 열기 등의 도구를 사용한다.

레벨 2: 검증 루프

에이전트 루프는 일을 처리하지만, 첫 시도에서 항상 정확하거나 일관된 결과를 내지는 않는다. 일관성이 중요할 때는 에이전트를 검증 루프로 감싸는 것이 유용하다. 검증 루프는 출력물을 검사하고, 기준에 미치지 못하면 피드백을 모델에 다시 보낸다.

검증 루프는 grader를 추가한다. grader는 에이전트의 출력을 rubric에 비추어 검사하고, 실패하면 그 결과와 피드백을 다시 보낸다. grader는 결정론적일 수도 있고 agentic할 수도 있다. 여기서 고전적인 예시는 LLM-as-a-judge다.

RubricMiddleware가 이 패턴을 처리한다. 또는 create_agent의 after_agent hook으로 직접 연결할 수도 있다.

문서 작성 에이전트 예시에서는 grader가 각 시도 후 테스트를 실행한다. 모든 링크가 해석되는지, 모든 CI 체크가 통과하는지, diff가 실제 요청 범위에 한정되는지를 확인한다. 이런 종류의 오류를 잡는 데는 수동 리뷰가 필요 없다.

트레이드오프도 있다. 검증을 추가하면 실행당 지연 시간과 비용이 늘어난다. 품질이 속도보다 중요한 경우, 즉 대부분의 production use case에서는 그 비용을 감수할 가치가 있다.

레벨 3: 이벤트 기반 루프

에이전트 개발에서 가장 중요한 부분 중 하나는 integration layer다. 즉 에이전트를 생태계에 연결해 백그라운드에서 실행되도록 만드는 것이다.

이벤트 기반 루프는 에이전트를 생태계에 연결한다. 새 문서가 도착하거나, 일정이 트리거되거나, webhook이 도착하는 식으로 이벤트가 발생하면 에이전트가 실행된다. 이때 에이전트는 사람이 수동으로 호출하는 대상이 아니라, 더 큰 시스템 안에서 계속 실행되는 컴포넌트다.

LangSmith Deployment는 cron schedule과 webhook을 포함한 trigger infrastructure를 지원한다. cron이 실제로 쓰이는 대표적인 예시는 openclaw의 heartbeat다. heartbeat는 에이전트를 항상 켜져 있는 proactive assistant로 바꾼다.

LangChain의 문서 에이전트는 no-code agent builder인 Fleet으로 구동된다. Fleet의 channel과 schedule은 이벤트 기반 trigger와 cron 스타일 trigger를 처리한다. LangChain은 #docs-plz Slack 채널에 메시지가 올라올 때마다 문서 에이전트를 실행하기 위해 channel을 사용한다.

레벨 4: Hill climbing 루프

처음 세 루프는 일을 자동화한다. 네 번째 루프, 그리고 아마 가장 중요한 루프는 개선을 자동화한다.

모든 에이전트 실행은 trace를 만든다. trace는 모델이 무엇을 했는지, 어떤 도구를 호출했는지, grader feedback은 무엇이었는지 등을 기록한 것이다. 이런 trace에는 무엇이 잘 작동하고 무엇이 그렇지 않은지에 대한 고가치 신호가 들어 있다. hill climbing 루프는 그 trace 위에서 분석 에이전트를 실행하고, 발견한 내용을 사용해 더 나은 설정으로 하네스를 다시 작성한다. 여기에는 prompt/tool 조정이나 grader 조정이 포함될 수 있다.

LangSmith에서는 trace analysis agent인 Engine을 사용해 이 네 번째 루프를 계측할 수 있다.

문서 에이전트 비유로 마무리하면, LangChain은 문서 에이전트 trace 위에서 Engine을 실행해 문제를 감지한다. 여러 trace가 잠재적 문제를 가리키면, 문제가 되는 prompt나 tool의 변경을 요청하는 issue가 생성된다.

여기서 핵심은 return arrow가 단순히 맨 위로 되돌아가는 것이 아니라, 안쪽으로 들어가 에이전트 루프 자체를 직접 업데이트한다는 점이다. 바깥 루프의 각 cycle은 안쪽 루프를 더 효과적으로 만든다.

앞으로를 보면, prompt와 tool configuration은 개선하기 가장 단순한 대상일 뿐 유일한 대상은 아니다. open-weight model을 운영하는 팀이라면 hill climbing 루프를 RL fine-tuning으로 이어 붙일 수 있다. trace나 eval outcome을 training signal로 사용해 모델 자체를 개선하는 것이다. memory와 retrieved skill 같은 보조 컨텍스트도 같은 방식으로 개선할 수 있다. 루프가 패턴이고, 무엇을 최적화할지는 사용자가 정한다.

사람의 감독과 전문성

자동화는 사람을 루프에서 제거한다는 뜻이 아니다. 모든 레벨에는 사람의 감독이 가치를 더하는 자연스러운 지점이 있다. 자동 grader는 링크가 해석되는지 확인할 수 있다. 하지만 독자에게 맞지 않는 framing을 알아차리는 일은 사람의 몫이다. 컨텍스트, 경험, 취향에서 얻어지는 그런 판단이야말로 human review가 필요한 이유다.

일부 전문성은 prompt와 tool 자체에 codify되어야 한다. 하지만 민감한 행동에는 실시간 human review가 필수다. 금융 거래나 DB operation을 떠올리면 된다. LangChain은 모든 루프에서 이런 touch point를 계측하기 쉽게 만든다.

에이전트 루프에서는 민감한 action/tool call 전에 human input을 요구한다.
검증 루프에서는 민감한 workflow에 대해 사람이 grader 역할을 할 수 있다.
application loop에서는 결과가 최종 사용자에게 반환되기 전에 사람이 output을 승인할 수 있다.
hill climbing 루프에서는 하네스 개선안이 배포 전에 human review를 거칠 수 있다.

LangChain의 모든 open source framework는 human-in-the-loop를 first class primitive로 추가할 수 있게 한다.

전체 구조

표로 보면 네 가지 루프는 다음처럼 쌓인다.

루프	하는 일	영향	LangChain primitive
1. 에이전트 루프	작업이 완료될 때까지 모델이 도구를 반복 호출한다	작업 자동화	`create_agent`, LangChain이 지원하는 임의의 모델
2. 검증 루프	에이전트가 실행되고, output이 rubric에 따라 채점되며, 실패하면 feedback과 함께 재시도된다	작업 품질과 정확성 보장	`RubricMiddleware`
3. 이벤트 기반 루프	이벤트가 실제 시스템을 업데이트하는 에이전트 실행을 trigger한다	규모 있는 자동화 작업	cron trigger/webhook을 갖춘 LangSmith Deployment 또는 Fleet channel
4. Hill climbing 루프	production run의 trace가 분석 에이전트로 들어가 하네스 configuration을 개선한다	하네스 개선	LangSmith Engine

이것이 swyx가 말한 loopcraft, 즉 루프 엔지니어링이 실제로 현장에서 보이는 모습이다. Steipete, Boris, Andrej 같은 AI 리더들도 모두 같은 결론에 도달했다. 에이전트의 잠재력은 에이전트 주변에 어떤 루프를 구축하느냐에 있다.

LangChain은 한동안 루프 1과 2를 고민해 왔다. 하지만 이제 초점은 루프 3과 4로 이동해야 한다. 에이전트를 조직의 생태계에 심고, 사용자의 기준에 반응해 계속 개선하게 만들 때 가치가 복리로 쌓이기 때문이다.

Satya는 조직적 stakes를 이렇게 framing한다. 인간의 판단과 token capital이 함께 복리로 쌓이는 learning loop를 일찍 구축하는 회사는 복제하기 어려운 우위를 만들 것이다.

핵심 takeaway

이 글은 loop-engineering을 단일 에이전트 설계가 아니라 중첩된 운영 루프 설계로 해석한다.
루프 1·2는 단일 실행의 생산성과 품질을 다루고, 루프 3·4는 조직 시스템 안에서 실행 빈도와 학습 속도를 키운다.
검증 루프는 비용과 지연을 늘리지만, production workflow에서는 품질을 위한 기본 비용으로 보는 편이 적절하다.
hill climbing 루프의 핵심은 trace를 “로그”가 아니라 prompt, tool, grader, memory, skill, 나아가 모델 개선에 쓰는 학습 신호로 다루는 것이다.
사람은 제거되는 것이 아니라, 민감한 action, framing 판단, 배포 전 harness change review 같은 고레버리지 지점으로 이동한다.

description	LangChain의 The Art of Loop Engineering은 에이전트의 기본 구조를 “모델이 도구를 반복 호출하는 루프”로 설명한 뒤, 실전 에이전트는 그 위에 검증 루프, 이벤트 기반 실행 루프, 운영 trace를 바탕으로 하네스를 개선하는 hill climbing 루프를 겹겹이 쌓아야 한다고 주장한다.
tags	ai-agents, ai-coding, automation, harness

LLM Wiki

탐색기