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

(langchain.com)

48P by GN⁺ 8일전 | ★ favorite | 댓글 2개

에이전트를 안정적으로 유용한 작업에 활용하려면 좋은 모델만으로는 부족하며, 작업 집합에 맞게 설계된 하네스(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는 조직 차원의 이해관계를 짚으며, 사람의 판단과 토큰 자본이 함께 복리로 쌓이는 학습 루프를 일찍 구축하는 기업이 복제하기 어려운 우위를 확보한다고 언급