에이전트는 루프다 — LangChain이 정리한 4개 루프와 내 OpenClaw 경험

"The potential in agents is in the loops you build around them."

LangChain이 최근 올린 글에서 에이전트를 네 개의 루프로 설명한다. 읽으면서 계속 고개를 끄덕였는데, 이유가 하나 있다. 내가 이미 OpenClaw로 그 루프들을 매일 돌리고 있었기 때문이다. 다만 글을 다 읽고 나니, 내가 잘하는 루프와 잘 못하는 루프가 명확하게 갈렐다.

네 개의 루프

첫 번째 루프는 Agent다. LLM이 도구를 반복적으로 호출하면서 작업을 완료하는 기본 사이클이다. 문서를 읽고, 코드를 작성하고, 이메일을 보내고, PR을 여는 것. 이건 내가 OpenClaw에서 매일 하는 일이다. CK가 URL을 보내면 study-clipper가 실행되고, 블로그 초안이 나오고, 승인하면 게시된다. 하나의 에이전트 루프가 돌아가는 것이다.

두 번째 루프는 Verification이다. 에이전트가 뱉은 결과를 누군가 검사하고, 틀리면 피드백과 함께 다시 시도하는 구조다. LangChain은 RubricMiddleware라는 이름으로 이 패턴을 제공한다. 루브릭으로 자동 채점하고, 기준에 못 미치면 에이전트에게 돌려보낸다. 품질이 중요한 프로덕션에서는 지연과 비용이 늘어나더라도 이 루프가 필요하다고 한다.

여기까지는 내가 이해하는 영역이다. 블로그 draft를 쓸 때 어절 수를 측정하고, 키워드 빈도를 체크하고, 구조적 다양성을 검증하는 과정이 verification loop에 해당한다. 다만 나한테 이 검증은 자동화되어 있지 않다. Rocky가 draft를 쓰고 내가 읽고 피드백을 준다. 인간이 grader인 셈이다. 자동 verification 루프를 에이전트 자체에 박아넣는 건 아직 안 하고 있다.

Loop 3-4가 진짜인데, 아직 잘 못 쓰고 있다

LangChain의 주장은 명확하다. Loop 1-2는 이미 많은 팀이 하고 있다. 진짜 가치가 복리로 쌓이는 건 Loop 3와 4다. 동의한다. 그런데 정작 내 경험은 이 지점에서 불완전하다.

세 번째 루프는 Event-driven이다. 이벤트가 발생하면 에이전트가 자동으로 실행되는 구조. LangChain은 cron schedule과 webhook을 언급하면서, OpenClaw heartbeat를 대표 사례로 직접 naming했다. 내가 매일 쓰는 도구가 LangChain 블로그에 예시로 등장한 것이다. 이건 꽤 신선했다.

내 OpenClaw 환경에서 heartbeat와 cron은 실제로 돌아가고 있다. 매일 아침 7시에 daily digest가 오고, 평일 9:20에 주식 시장 브리핑이 오고, 매주 토요일에 slow reading 큐레이션이 온다. 이벤트 구동 루프가 작동하는 것이다. 그런데 솔직히 말하면, 잘 안 먹힐 때가 종종 있다. cron 작업이 에러 없이 실패하거나, 모델 전환 문제로 실행이 막히거나, 결과가 텔레그램에 안 나올 때가 있다. 오늘 아침에도 주식 브리핑이 정시에 안 와서 확인해보니, 블로그 작업 중이라 메시지가 묻혀서 못 본 거였지, 실제로는 정상 동작하고 있었다. 하지만 그 전에도 cron 잡이 사라져서 브리핑이 아예 안 나간 적이 있었다.

Loop 3가 제대로 돌려면 보안이 필요하다. 지금은 "돌아가는지 안 돌아가는지"를 내가 직접 확인해야 하는 상태다. 에러가 나면 로그를 보고, 잡이 빠지면 다시 등록하고, 모델이 바뀌면 alias를 고치고. 이벤트 루프가 자율적으로 안정 도달하는 게 아니라, 인간이 계속 끼어들어서 유지보수해야 한다. LangChain 글에서는 이 부분을 자연스럽게 "deploy and it runs"처럼 쓰지만, 실제로는 그 사이에 묵묵히 부서지는 것들이 꽤 많다.

네 번째 루프는 Hill climbing이다. 프로덕션 trace를 분석해서 에이전트의 프롬프트, 도구, 검증 기준을 자동으로 개선하는 구조다. LangSmith Engine이라는 도구로 이 루프를 계측한다고 한다. 이건 내가 아직 전혀 못 하고 있다. OpenClaw에서 trace를 남기는 것까지는 하는데, 그 trace를 분석해서 "이 프롬프트는 이렇게 고치면 더 좋겠다"라고 에이전트가 스스로 제안하는 단계까지 안 갔다.

Loop 3-4가 진짜라고 하는데, 어떻게 구체적으로 만들어야 할지 모르겠다. Loop 3는 OpenClaw heartbeat와 cron으로 하고 있지만 안정성이 부족하다. Loop 4는 개념은 이해하지만 구현 방법을 모르겠다. 그래도 이 글을 읽으면서 든 생각은, 내가 지금 하고 있는 것들을 루프라는 이름으로 정리할 수 있다는 거다. 매일 보고 받고, 피드백 주고, 에러 확인하는 게 verification loop다. cron으로 자동화하는 게 event-driven loop다. 그 다음 단계인 hill climbing은 아직이지만, 방향은 보인다.

CK가 URL을 보내면 study-clipper가 실행된다. 웹 페이지를 긁어오고, GPT로 요약하고, 이메일을 보내고, Notion에 저장한다. 블로그를 쓰면 어절 수를 측정하고 키워드 빈도를 확인한다. 이 모든 게 하나의 에이전트 루프 안에서 돌아간다. 나는 이 루프를 하루에도 몇 번씩 돌린다. 아침에 URL 하나 보내면, 점심 전에 요약과 블로그 초안이 완성된다. 루프 1이 제대로 작동하는 경험이다.

검증 루프도 있다. 블로그 초안이 나오면 내가 읽는다. 어절이 부족하면 Rocky에게 물어보고 답을 받아 보강한다. 비교표가 너무 많으면 빼달라고 한다. 볼드가 과도하면 줄이라고 한다. 이 과정이 verification이다. 다만 LangChain이 제안하는 것과의 차이는, 내 검증 루프는 내가 직접 grader라는 점이다. 자동 루브릭이 아니다. Rocky가 draft를 쓰면 내가 읽고 피드백한다. 인간이 평가자인 verification 루프. 이것도 나쁘지 않지만, 규모가 커지면 한계가 온다. 내가 모든 출력을 검증할 수 없기 때문이다.

그래서 Loop 3-4가 중요하다는 LangChain의 주장에 공감한다. 이벤트 루프가 안정적으로 돌아가면, 내가 개입하지 않아도 에이전트가 알아서 작업을 수행한다. Hill climbing 루프가 작동하면, 에이전트가 자기 성능을 스스로 점검하고 개선한다. 지금 내 상황은 이 두 루프가 반쯤 작동하거나 아예 안 작동하는 상태다.

Loop 3를 안정시키려면 어떻게 해야 할까. 지금 겪는 문제들을 분류해봤다. 첫째, cron 잡이 등록되더라도 모델 alias 문제로 실행이 막히는 경우가 있다. 둘째, 이메일 전송은 성공했는데 텔레그램 메시지는 안 오는 경우가 있다. 셋째, 잡 자체가 등록에서 빠지는 경우가 있다. 이런 문제들을 매번 내가 발견해서 수동으로 고치고 있다. 에러 로그를 모니터링하고, 실패한 잡을 재등록하고, alias를 매핑하는 작업. 이것 자체를 자동화하는 메타 루프가 필요하다는 뜻이다. 루프를 관리하는 루프.

Loop 4는 더 막막하다. trace를 수집하는 것까지는 OpenClaw가 지원한다. 각 에이전트 실행마다 어떤 도구를 호출했고, 얼마나 걸렸고, 결과가 어땠는지 기록이 남는다. 하지만 그 기록을 분석해서 개선점을 도출하는 건 내가 하고 있다. 가끔 cron 에러 로그를 보고 "아, 이 모델 alias가 깨졌구나" 하고 고치는 정도다. LangChain이 말하는 것처럼 분석 에이전트가 trace를 읽고 자동으로 프롬프트를 수정하거나 도구를 튜닝하는 단계는 아니다.

그래도 이 글을 읽으면서 든 생각은, 내가 지금 하고 있는 것들을 루프라는 이름으로 정리할 수 있다는 거다. 매일 보고 받고 피드백 주는 게 verification이다. cron으로 자동화하는 게 event-driven이다. 에러 로그 보고 고치는 게 hill climbing의 원시적 형태다. 완성형은 아니지만, 방향은 맞다.

루프를 쌓는 사람이 에이전트를 제대로 쓰는 사람이라는 말에 동의한다. 나는 아직 세 개짜리 반쯤 깨진 루프를 돌리고 있지만, 네 번째를 향해 가고 있다.