루프 엔지니어링의 미학 (The Art of Loop Engineering)

• 에이전트를 안정적으로 유용한 작업에 활용하려면 좋은 모델만으로는 부족하며, 작업 집합에 맞게 설계된 하네스(harness) 가 필요함
• 가장 기본이 되는 에이전트 루프는 LLM에 컨텍스트를 주고 작업이 끝날 때까지 도구를 반복 호출하는 구조
• 여기에 검증 루프, 이벤트 기반 루프, 힐 클라이밍 루프를 쌓아 올리는(stacking) 방식으로 더 효과적인 에이전트를 구성
• 각 루프 계층은 LangChain 프리미티브로 계측(instrument)할 수 있으며, 내부 문서 작성 에이전트를 예시로 설명
• 진정한 잠재력은 모델 자체가 아니라 에이전트를 둘러싸고 구축하는 루프에 있음

Loop 1: 에이전트 루프

• 에이전트는 본질적으로 작업이 완료될 때까지 도구를 반복 호출하는 모델
• LangChain의 create_agent가 이 루프를 제공하며, 모델을 고르고 도구(tools) 를 연결하면 동작하는 에이전트 루프가 완성
  • 도구는 에이전트가 현실 세계에서 행동을 취할 수 있게 하는 요소
• 내부 문서 에이전트 예시에서, 첫 루프 단계는 문서 개선 요청을 받아 모델이 변경 사항을 계획·초안 작성하고, repo 클론·파일 읽기·문서 작성·풀 리퀘스트(pull request) 열기 등에 도구를 사용

Level 2: 검증 루프

• 에이전트 루프는 작업을 처리하지만 첫 시도에서 항상 정확하거나 일관된 결과를 내지는 않으며, 일관성이 중요할 때 출력을 점검하고 미흡하면 피드백을 모델로 되돌리는 검증 루프로 감쌈
• 검증 루프는 그레이더(grader) 를 추가해 에이전트 출력을 루브릭(rubric)에 대조하고, 실패 시 피드백과 함께 결과를 되돌림
  • 그레이더는 결정론적이거나 에이전트형일 수 있으며, LLM as a judge가 전형적 예시
  • RubricMiddleware가 이 패턴을 처리하거나, create_agent의 after_agent 훅으로 연결 가능
• 문서 작성 예시에서 그레이더는 각 시도 후 테스트를 실행해 모든 링크 정상 작동, 모든 CI 체크 통과, diff가 요청 범위에 한정됐는지 확인하여 수동 리뷰 없이 오류 유형을 포착
• 검증 추가는 실행당 지연 시간과 비용을 늘리지만, 속도보다 품질이 중요한 대부분의 프로덕션 용도에서는 가치가 있음

Level 3: 이벤트 기반 루프

• 에이전트 개발에서 가장 중요한 부분 중 하나는 통합 계층(integrations layer) 으로, 에이전트를 생태계에 연결해 백그라운드에서 실행되도록 함
• 이벤트 기반 루프는 새 문서 도착, 스케줄 발동, 웹훅 도착 같은 이벤트가 발생하면 에이전트를 실행
  • 에이전트는 수동으로 호출하는 대상이 아니라, 더 큰 시스템 안에서 지속적으로 동작하는 구성 요소
• LangSmith Deployment가 트리거 인프라를 지원하며, cron 스케줄과 웹훅을 지원
  • cron 활용의 인기 예시는 openclaw의 heartbeats로, 에이전트를 항상 켜져 있는 능동형 어시스턴트로 전환
• 문서 에이전트는 노코드 에이전트 빌더 Fleet로 구동되며, Fleet의 channels와 schedules가 이벤트 기반·cron 트리거를 처리
  • #docs-plz Slack 채널에 메시지가 오면 채널을 통해 문서 에이전트를 실행

Level 4: 힐 클라이밍 루프

• 앞의 세 루프가 작업을 자동화한다면, 네 번째 루프는 개선(improvement) 자체를 자동화
• 모든 에이전트 실행은 모델의 행동, 호출한 도구, 그레이더 피드백 등을 기록한 트레이스(trace) 를 생성하며, 이 트레이스에는 무엇이 작동하고 무엇이 안 되는지에 대한 높은 가치의 신호가 담김
• 힐 클라이밍 루프는 트레이스에 대해 분석 에이전트를 실행하고, 그 결과로 하네스 구성을 개선된 설정으로 재작성
  • 여기에는 프롬프트/도구 조정이나 그레이더 조정이 포함
  • LangSmith에서는 트레이스 분석 에이전트 Engine으로 이 네 번째 루프를 계측
• 문서 에이전트 예시에서 engine을 트레이스에 실행해 문제를 감지하며, 여러 트레이스가 잠재적 문제를 신호하면 문제되는 프롬프트나 도구의 변경을 요청하는 이슈가 등록
• 핵심은 반환 화살표가 단순히 맨 위로 되돌아가는 것이 아니라, 내부로 들어가 에이전트 루프를 직접 갱신한다는 점이며, 외부 루프의 각 주기가 내부 루프를 더 효과적으로 만듦

• 향후 전망

  • 프롬프트와 도구 구성이 가장 개선하기 쉽지만 유일한 선택지는 아니며, 오픈 웨이트 모델을 운영하는 팀은 힐 클라이밍 루프를 RL 파인튜닝에 연결해 트레이스나 평가 결과를 학습 신호로 삼아 모델 자체를 개선 가능
  • 메모리, 검색된 스킬 같은 보조 컨텍스트도 같은 방식으로 개선 가능하며, 루프는 패턴이고 무엇을 최적화할지는 사용자에게 달림

사람의 감독과 전문성

• 자동화가 사람을 루프에서 제거하는 것을 뜻하지는 않으며, 모든 계층에 사람의 감독이 가치를 더하는 지점이 존재
  • 자동 그레이더는 링크가 정상 작동하는지 확인할 수 있지만, 대상 독자에게 프레이밍이 잘못됐음을 알아채는 것은 사람의 몫이며, 맥락·경험·안목에서 나오는 판단이 사람 리뷰가 필요한 지점
• 일부 전문성은 프롬프트/도구 자체에 코드화해야 하지만, 금융 거래나 DB 작업 같은 민감한 행동에는 실시간 사람 리뷰가 필수
• LangChain은 모든 루프에서 이 접점을 계측하기 쉽게 지원
  • 에이전트 루프: 민감한 행동/도구 호출 전 사람 입력 요구
  • 검증 루프: 민감한 워크플로에서 사람이 그레이더 역할 수행
  • 애플리케이션 루프: 최종 사용자에게 반환 전 사람이 출력을 승인
  • 힐 클라이밍 루프: 배포 전 하네스 개선을 사람 리뷰로 통과
• 모든 LangChain 오픈소스 프레임워크는 human in the loop을 일급 프리미티브로 제공

종합 정리

• 네 개의 루프가 쌓이는 방식 요약
  • 에이전트 루프: 작업 완료까지 모델이 도구를 반복 호출 → 작업 자동화, 프리미티브는 create_agent 및 LangChain 지원 모델
  • 검증 루프: 출력을 루브릭으로 채점하고 실패 시 피드백과 함께 재시도 → 작업 품질·정확성 보장, 프리미티브는 RubricMiddleware
  • 이벤트 기반 루프: 이벤트가 실제 시스템을 갱신하는 에이전트 실행을 트리거 → 대규모 작업 자동화, 프리미티브는 cron 트리거/웹훅 기반 LangSmith Deployment 또는 Fleet channels
  • 힐 클라이밍 루프: 프로덕션 실행 트레이스가 분석 에이전트를 통해 하네스 구성을 개선 → 하네스 개선, 프리미티브는 LangSmith Engine
• 이것이 swyx가 말하는 loopcraft, 즉 실제 루프 엔지니어링의 모습이며, Steipete·Boris·Andrej 같은 리더들도 에이전트의 잠재력이 그것을 둘러싸고 구축하는 루프에 있다는 동일한 결론에 도달
• 루프 1·2는 오랫동안 다뤄왔으나, 이제 초점은 에이전트를 생태계에 내장해 기준에 따라 지속 개선되며 가치가 복리로 쌓이는 루프 3·4로 전환되어야 함
• Satya는 조직 차원의 이해관계를 짚으며, 사람의 판단과 토큰 자본이 함께 복리로 쌓이는 학습 루프를 일찍 구축하는 기업이 복제하기 어려운 우위를 확보한다고 언급