LangChain이 말하는 루프 엔지니어링 소개
루프 엔지니어링(Loop Engineering) 은 하나의 에이전트를 여러 겹의 반복 구조(loop)로 감싸서, 그저 "돌아가기만 하는" 에이전트를 "믿고 맡길 수 있는" 에이전트로 끌어올리는 설계 기법입니다. 최근 LangChain이 공개한 글 "The Art of Loop Engineering" 은 이 겹겹의 루프를 네 단계로 나누고, 각 단계를 어떤 LangChain 기본 요소(primitive)로 구현할 수 있는지 정리합니다. 여기서 제목의 art 는 미술이나 미학이 아니라, 에리히 프롬의 사랑의 기술(The Art of Loving) 이나 손자의 전쟁의 기술(The Art of War) 처럼 "무언가를 잘 해내는 솜씨와 노하우" 를 뜻합니다. 실제로 원문은 swyx가 쓴 글 "loopcraft: the art of stacking loops" 를 출발점으로 삼는데, 여기서 craft(기예, 솜씨)라는 단어가 곧 이 art 와 같은 의미로 쓰였습니다.
에이전트(Agent)가 유용한 이유는 현실 세계에서 실제로 행동을 취해 사람의 일을 자동화해 주기 때문입니다. 그런데 에이전트가 그 일을 믿을 수 있게 해내도록 만드는 것은 좋은 모델 하나만으로는 부족합니다. 특정한 작업 묶음에 꼭 맞게 설계된 하네스(harness) 가 필요합니다. 여기서 하네스란 모델을 감싸서 도구 호출, 결과 검증, 실행 트리거, 개선 신호 수집 같은 주변 장치를 붙여 주는 실행 골격을 말합니다. 가장 근본이 되는 에이전트 알고리즘은 단순합니다. 모델에게 맥락(context)을 주고, 작업이 끝날 때까지 반복해서 도구를 호출하게 두는 것입니다. 이것이 에이전트의 심장에 해당하는 가장 기본적인 루프이지만, 에이전트를 움직이는 유일한 루프는 결코 아닙니다.
LangChain이 제시하는 발상의 핵심은, 이 기본 루프를 더 큰 루프로 겹겹이 감싸는 것입니다. 마치 러시아 인형 마트료시카처럼, 안쪽의 에이전트 루프를 검증 루프가 감싸고, 그 검증 루프를 다시 이벤트 루프가 감싸고, 마지막으로 개선 루프가 전체를 감쌉니다. 바깥 루프는 안쪽 루프에게 "이 결과가 기준에 맞는가", "지금 실행할 때인가", "이 설정을 어떻게 더 좋게 바꿀까" 같은 새로운 능력을 더해 줍니다. 이렇게 루프를 쌓고(stack) 확장해서 더 효과적인 에이전트를 만든다는 발상이며, 최근 커뮤니티에서 논의되는 하네스 엔지니어링(Harness Engineering) 흐름과 정확히 맞닿아 있습니다. 신뢰할 수 있는 에이전트는 모델 자체보다 그 주변을 감싸는 실행 구조에서 결정된다는 관점입니다(관련해서는 Awesome Harness Engineering이나 12-Factor Agents 정리를 함께 참고하시면 좋습니다).
이 글에서는 LangChain이 제시하는 네 겹의 루프를 하나씩 살펴보고, 각 층을 어떤 LangChain 기본 요소로 계측(instrument)할 수 있는지 짚어 보겠습니다. 설명을 구체화하기 위해, 원문과 마찬가지로 LangChain 내부에서 실제로 돌아가는 문서 작성 에이전트(docs agent) 를 처음부터 끝까지 예시로 사용합니다. 참고로 아래에서 언급하는 여러 기능은 LangChain의 오픈소스 에이전트 프레임워크인 DeepAgents와 관측 도구 LangSmith에 기반합니다.
가장 근본적인 반복, 모델이 도구를 부르는 에이전트 루프 (Loop 1)
가장 안쪽에 있는 첫 번째 루프는 에이전트 그 자체입니다. 에이전트의 본질은 작업이 끝날 때까지 모델이 도구를 반복해서 호출하는 것입니다.
이것이 바로 LangChain의 create_agent가 제공하는 것입니다. 원하는 모델을 고르고 도구(Tools)를 꽂으면, 곧바로 작동하는 에이전트 루프가 만들어집니다. 도구는 에이전트가 현실 세계에서 실제로 행동을 취할 수 있게 해 주는 힘의 원천으로, 웹 검색, 파일 읽기와 쓰기, API 호출, 코드 실행처럼 모델이 텍스트 생성 이상의 일을 하도록 연결해 주는 함수들입니다.
이 루프의 동작은 하나의 사이클로 요약됩니다. 모델은 현재 맥락을 보고 다음에 무엇을 할지 판단해 도구에 행동(action) 을 지시하고, 도구는 그 행동을 실행한 뒤 결과를 관찰(observation) 로 되돌려 줍니다. 모델은 이 관찰을 맥락에 더해 다음 판단을 내리고, 이 주고받음을 작업이 완료됐다고 판단할 때까지 되풀이합니다. 생각하고 → 행동하고 → 관찰하고 → 다시 생각하는 이 반복이 에이전트를 단순한 챗봇과 구분 짓는 지점입니다.
LangChain 내부의 문서 작성 에이전트를 예로 들면, 이 첫 번째 루프 수준에서 에이전트는 문서 개선 요청을 받아 모델이 변경 사항을 계획하고 초안을 작성한 뒤, 도구를 사용해 저장소를 복제(clone)하고 파일을 읽고 문서를 쓰고 풀 리퀘스트(Pull Request)를 여는 일까지 스스로 수행합니다.
첫 시도가 틀릴 때를 대비하는 검증 루프 (Loop 2)
에이전트 루프는 일을 해내기는 하지만, 첫 시도에서 항상 정확하거나 일관된 결과를 내놓지는 않습니다. 일관성이 중요한 상황이라면, 이 에이전트 루프를 검증 루프(Verification Loop) 로 한 번 더 감싸는 것이 유용합니다. 검증 루프는 출력을 점검하고, 기준에 못 미치면 피드백과 함께 결과를 모델에게 되돌려 보내 다시 시도하게 합니다.
검증 루프의 핵심은 채점기(Grader) 를 추가하는 것입니다. 채점기는 에이전트의 출력을 루브릭(rubric), 즉 "무엇이 좋은 결과인가"를 정의한 평가 기준표에 비추어 확인하고, 통과하지 못하면 어디가 부족한지 피드백을 붙여 다시 시도하게 만듭니다. 채점기는 크게 두 가지로 만들 수 있습니다. 하나는 결정론적(deterministic) 채점기로, 테스트 통과 여부나 링크 정상 여부처럼 코드로 명확히 판정할 수 있는 규칙 기반 검사입니다. 다른 하나는 에이전트형(agentic) 채점기로, 판정 자체를 또 다른 모델에게 맡기는 방식입니다. 후자의 대표적인 예가 모델이 다른 모델의 출력을 심사관처럼 평가하는 LLM as a judge 패턴으로, 글의 논조나 적절성처럼 규칙으로 딱 떨어지지 않는 품질을 평가할 때 유용합니다.
LangChain에서는 RubricMiddleware가 이 패턴을 처리해 주며, create_agent에 after_agent 훅을 걸어 직접 연결할 수도 있습니다. 문서 작성 에이전트 예시에서는 채점기가 매 시도마다 테스트를 실행해서 모든 링크가 정상적으로 연결되는지, 모든 CI 검사가 통과하는지, 그리고 변경된 diff가 실제로 요청받은 범위 안에 머무는지를 확인합니다. 이런 종류의 오류는 사람이 수동으로 리뷰하지 않아도 걸러낼 수 있습니다.
물론 절충점(tradeoff)도 있습니다. 검증을 추가하면 실행마다 지연 시간(latency)과 비용이 늘어납니다. 채점하고, 실패하면 다시 시도하는 과정이 반복되기 때문입니다. 다만 속도보다 품질이 더 중요한 상황, 즉 대부분의 실제 운영(production) 사례에서는 그만한 값어치를 합니다.
에이전트를 생태계에 심는 이벤트 기반 루프 (Loop 3)
에이전트 개발에서 가장 중요한 부분 중 하나는 통합 계층(integrations layer) 입니다. 에이전트를 여러분의 생태계에 연결해서, 사람이 일일이 부르지 않아도 배경에서 알아서 돌아가게 만드는 층입니다.
이벤트 기반 루프(Event Driven Loop) 는 바로 이 연결을 담당합니다. 이벤트가 발생하면, 예를 들어 새 문서가 도착하거나 정해진 스케줄이 발동하거나 웹훅(webhook)이 들어오면 에이전트가 실행됩니다. 이 관점에서 에이전트는 여러분이 손으로 호출하는 무언가가 아니라, 더 큰 시스템 안에서 끊임없이 돌아가는 하나의 구성 요소가 됩니다. 여기서 웹훅은 특정 사건이 벌어졌을 때 외부 시스템이 미리 등록된 주소로 알림을 쏘아 주는 방식이고, 크론(cron)은 "매일 아침 9시" 처럼 정해진 시각에 작업을 자동 실행하는 스케줄러입니다. 이 둘이 에이전트를 사람의 요청이 아니라 세상의 사건에 반응하게 만들어 줍니다.
LangSmith Deployment는 이러한 트리거 인프라를 지원하며, 여기에는 크론 스케줄(cron schedules)과 웹훅(webhooks) 지원이 포함됩니다. 크론이 실제로 쓰이는 대표적인 예가 openclaw의 하트비트(heartbeat) 로, 주기적으로 에이전트를 깨워 항상 켜져 있는 능동적인 비서로 바꿔 줍니다.
LangChain의 문서 에이전트는 노코드 에이전트 빌더인 Fleet 위에서 돌아갑니다. Fleet의 채널(channels)과 스케줄(schedules)이 이벤트 기반 트리거와 크론 방식 트리거를 처리합니다. LangChain 팀은 사내 #docs-plz Slack 채널에 메시지가 올라올 때마다 문서 에이전트를 발동시키는 데 이 채널 기능을 사용합니다. 즉, 누군가 문서 개선을 요청하면 그 메시지 자체가 이벤트가 되어 에이전트를 깨우는 셈입니다.
스스로 나아지게 만드는 힐 클라이밍 루프 (Loop 4)
앞의 세 루프가 일을 자동화 한다면, 네 번째 루프는 (그리고 어쩌면 가장 중요한 루프는) 개선을 자동화 합니다.
이름부터 짚고 넘어가면, 힐 클라이밍(Hill Climbing) 은 컴퓨터 과학에서 오래된 최적화 기법의 이름입니다. 지금 위치보다 조금이라도 더 높은 지점(더 나은 상태)으로 한 걸음씩 옮겨 가며 언덕을 오르듯 해(解)를 개선하는 국소 탐색(local search) 방법입니다. 이 루프가 하는 일이 정확히 그것입니다. 에이전트의 현재 설정에서 출발해, 실제 실행에서 얻은 신호를 근거로 조금 더 나은 설정을 향해 반복적으로 올라갑니다.
그 신호의 원천이 바로 트레이스입니다. 에이전트가 한 번 실행될 때마다 트레이스(trace)가 남습니다. 트레이스는 모델이 무엇을 했는지, 어떤 도구를 호출했는지, 채점기가 어떤 피드백을 줬는지 등 실행의 전 과정을 시간 순으로 기록한 자료로, 에이전트의 속을 들여다보는 관측성(observability)의 핵심입니다. 이 트레이스 안에는 무엇이 잘 작동하고 무엇이 그렇지 않은지에 대한 값진 신호가 담겨 있습니다. 힐 클라이밍 루프(Hill Climbing Loop) 는 이 트레이스들을 분석 에이전트로 훑은 뒤, 거기서 얻은 발견을 바탕으로 하네스를 더 나은 설정으로 다시 씁니다. 여기에는 프롬프트(prompt)나 도구 조정, 채점기 조정 등이 포함될 수 있습니다.
LangSmith에서는 트레이스 분석 에이전트인 Engine을 사용해 이 네 번째 루프를 계측할 수 있습니다. 문서 에이전트 예시로 마무리하자면, LangChain 팀은 문서 에이전트의 트레이스 위에 Engine을 돌려 문제를 감지합니다. 여러 트레이스가 동일한 잠재적 문제를 반복해서 가리키면, 문제를 일으킨 프롬프트나 도구를 고쳐 달라는 이슈(issue)가 자동으로 등록됩니다.
여기서 핵심적인 동작은, 되돌아가는 화살표가 단순히 맨 위로만 순환하는 것이 아니라 안쪽으로 파고들어 에이전트 루프 자체를 직접 갱신한다는 점입니다. 바깥 루프가 한 바퀴 돌 때마다 안쪽 루프들이 더 효과적으로 바뀝니다. 앞의 세 루프가 정해진 하네스 안에서 일을 처리하는 데 그친다면, 이 네 번째 루프는 그 하네스 자체를 시간이 지날수록 더 똑똑하게 다시 빚어냅니다.
앞을 내다보면, 프롬프트와 도구 설정은 개선하기 가장 쉬운 대상일 뿐 유일한 선택지는 아닙니다. 오픈 웨이트(open-weight) 모델을 운영하는 팀이라면, 힐 클라이밍 루프가 강화학습(Reinforcement Learning) 기반 미세조정(fine-tuning)으로 이어질 수 있습니다. 트레이스나 평가(eval) 결과를 보상 신호(training signal)로 삼아 하네스 설정이 아니라 모델 자체의 가중치를 개선하는 것입니다. 메모리나 검색된 스킬(skill) 같은 보조 맥락도 같은 방식으로 개선할 수 있습니다. 원문의 표현을 빌리면, "루프는 하나의 패턴이며, 그 루프가 무엇을 최적화할지는 여러분에게 달려 있습니다."
자동화가 사람을 밀어내지는 않습니다, 휴먼 인 더 루프
자동화한다고 해서 사람을 루프에서 빼낸다는 뜻은 아닙니다. 모든 층에는 사람의 감독(oversight)이 가치를 더하는 자연스러운 지점이 존재합니다. 자동 채점기는 링크가 제대로 연결되는지는 확인할 수 있지만, 글의 틀(framing)이 독자층에 맞지 않는다 는 사실을 알아채는 데는 사람이 필요합니다. 맥락과 경험, 그리고 안목에서 나오는 그런 판단이야말로 사람의 리뷰가 제 몫을 하는 자리입니다.
일부 전문성은 프롬프트나 도구 자체에 명문화(codify)해 둘 수 있지만, 금융 거래나 데이터베이스 조작처럼 민감한 행동에는 실시간 사람 리뷰가 필수입니다. LangChain은 이러한 접점을 네 개의 루프 각각에 손쉽게 심어 넣을 수 있게 해 줍니다.
- 에이전트 루프에서는 민감한 행동이나 도구 호출 전에 사람의 입력을 요구할 수 있습니다.
- 검증 루프에서는 민감한 워크플로우에 대해 사람이 채점기 역할을 직접 맡을 수 있습니다.
- 애플리케이션 루프에서는 결과가 최종 사용자에게 반환되기 전에 사람이 승인할 수 있습니다. 여기서 애플리케이션 루프는 에이전트가 실제 시스템과 맞닿는 이벤트 기반 루프의 접점을 가리킵니다.
- 힐 클라이밍 루프에서는 하네스 개선안이 배포 전에 사람의 리뷰를 거쳐 흘러갈 수 있습니다.
LangChain의 모든 오픈소스 프레임워크는 이러한 휴먼 인 더 루프(Human in the Loop)를 일급(first-class) 기본 요소로 다룹니다.
네 가지 루프를 한눈에
지금까지 살펴본 네 개의 루프가 어떻게 쌓이는지 표로 정리하면 다음과 같습니다.
| 루프 | 하는 일 | 효과 | LangChain 기본 요소 |
|---|---|---|---|
| 1. 에이전트 루프 | 작업이 끝날 때까지 모델이 도구를 반복 호출 | 일의 자동화 | create_agent, LangChain이 지원하는 모든 모델 |
| 2. 검증 루프 | 출력을 루브릭으로 채점하고, 실패 시 피드백과 함께 재시도 | 품질과 정확성 확보 | RubricMiddleware |
| 3. 이벤트 기반 루프 | 이벤트가 에이전트 실행을 촉발하고 실제 시스템을 갱신 | 대규모 자동화 | 크론 트리거 또는 웹훅을 갖춘 LangSmith Deployment, Fleet 채널 |
| 4. 힐 클라이밍 루프 | 운영 트레이스가 분석 에이전트에 입력되어 하네스 설정을 개선 | 하네스 개선 | LangSmith Engine |
왜 지금 바깥쪽 루프에 주목해야 하는가
이것이 바로 루프 엔지니어링, swyx의 표현으로는 loopcraft가 실제 현장에서 어떤 모습인지를 보여 줍니다. Steipete, Boris, Andrej Karpathy 같은 여러 AI 리더가 같은 결론에 도달했습니다. 에이전트의 잠재력은 그 주위에 여러분이 쌓아 올리는 루프에 있다 는 것입니다.
LangChain은 그동안 루프 1과 2를 오래 고민해 왔다고 말합니다. 하지만 이제 초점은 루프 3과 4로 옮겨 가야 한다고 강조합니다. 에이전트를 여러분의 생태계에 심어 넣고, 여러분의 기준에 맞춰 끊임없이 스스로 개선하게 만들 때 비로소 가치가 복리로 불어나는 지점이기 때문입니다.
Satya Nadella는 이 문제의 조직적 의미를 이렇게 정리합니다. 사람의 판단과 토큰 자본(token capital)이 함께 복리로 쌓이는 학습 루프(learning loop)를 일찍 구축한 기업은, 남들이 따라잡기 어려운 우위를 갖게 될 것 이라는 이야기입니다. 결국 이 글이 던지는 메시지는 분명합니다. 좋은 에이전트를 만드는 일은 더 좋은 모델을 기다리는 것이 아니라, 모델을 감싸는 루프를 얼마나 솜씨 있게 쌓아 올리느냐에 달려 있다는 것입니다.
루프 스태킹, 더 깊이 알아보기
loopcraft: the art of stacking loops - swyx가 정리한 "루프를 쌓는 기술"의 원류가 된 글
https://www.latent.space/p/ainews-loopcraft-the-art-of-stacking
Andrej Karpathy - 에이전트와 그 주위의 루프에 대한 강연 영상
The Art of Loop Engineering 소개 블로그
더 읽어보기
이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다. 
파이토치 한국 사용자 모임
이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일
로 보내드립니다! 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다. 
아래
쪽에 좋아요
를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~ 