개요

요즘 AI 업계에서 가장 자주 들리는 단어 하나가 ‘루프(loop)‘입니다. Claude Code를 만든 보리스 체르니(Boris Cherny)가 지난 금요일 Meta @Scale 콘퍼런스에 올랐는데, 청중에게서 받은 첫 질문이 “루프가 진짜냐, 다음 거품이냐"였습니다. 체르니의 답은 단호합니다. “진짜다.” 2년 전엔 사람이 직접 코드를 썼고, 그다음엔 에이전트가 코드를 썼는데, 이제는 에이전트가 다른 에이전트에게 시켜서 코드를 쓰는 단계로 넘어가고 있다는 겁니다. 소스 코드에서 에이전트로 넘어간 만큼 큰 도약이라고 말합니다.

보리스 체르니의 Meta @Scale 발표 장면 — ‘루프는 진짜’라고 말한 그 순간

위 영상은 체르니의 @Scale 발표 전체입니다. 본인이 실제로 어떻게 루프를 돌리고 있는지를 32분 부근에서 구체적으로 풀어줍니다. 한 에이전트는 코드 아키텍처를 계속 다듬을 거리를 찾고, 다른 에이전트는 중복된 추상화를 묶을 곳을 찾습니다. 둘 다 평범한 개발자처럼 풀 리퀘스트를 올리고, 코드가 계속 바뀌니까 일을 멈출 이유도 없습니다. 그래서 끝없이 돕니다.

핵심 요약

  • 루프는 에이전트 다음 단계: 사람 → 에이전트 → 에이전트가 에이전트를 부리는 구조로 이동 중
  • 체르니 본인이 두 개 돌린다: 아키텍처 개선용 + 중복 추상화 통합용 — 둘 다 PR을 올린다
  • 새 개념은 아니다: 재귀 함수의 비결정 버전. 사람 대신 서브에이전트가 종료 조건을 판단한다
  • Ralph Loop가 대표 패턴: “지금까지 한 일 요약하고, 목표 달성됐어?“를 반복해 모델을 제자리에 잡아둔다
  • 본질은 test-time compute: 컴퓨트만 충분히 부으면 풀리는 문제, 멈출 이유가 없으면 끝까지 부으면 된다
  • 비용은 만만치 않다: 토큰을 빨아들이는 속도가 챗봇과는 다른 차원. 천장이 없다는 게 문제이자 특징

루프는 사실 새 개념이 아닙니다

전산학 1학년 때 배우는 재귀(recursion)를 떠올려 보면 됩니다. 자기 자신을 다시 부르는 함수, 그리고 멈출 조건. 에이전트 루프도 똑같은 뼈대를 씁니다. 차이는 한 군데입니다. 언제 멈출지를 결정하는 것이 사람이 짠 if 조건이 아니라 또 다른 서브에이전트라는 점이죠. 그래서 비결정적(non-deterministic)입니다. 같은 입력으로도 종료 시점이 매번 다를 수 있습니다.

프로그래머들이 AI에게 일을 시키기 시작하자마자 누군가는 이 패턴을 떠올릴 수밖에 없었습니다. “AI가 AI를 감독한다"는 발상은 막을 도리가 없었습니다.

Ralph Loop, 가장 단순한 트릭

요즘 가장 인기 있는 루프 중 하나가 Ralph Loop입니다. 심슨 가족의 어수룩한 캐릭터 ‘랄프 위검’에서 이름을 따왔습니다. 구조는 어이없을 만큼 단순합니다.

  1. 모델에게 지금까지 한 일을 전부 요약시킨다
  2. “그래서, 목표는 달성됐어?“라고 묻는다
  3. 아니라면 다시 일을 시키고, 같은 질문을 반복한다

이게 왜 잘 먹힐까요. AI 모델은 오래 돌릴수록 자기가 어디 있는지 잃어버리는 경향이 있습니다. 컨텍스트는 길어지고, 초기 목표는 흐려지고, 엉뚱한 방향으로 새기 시작하죠. Ralph Loop는 매 라운드마다 모델을 출발점으로 끌어다 놓는 셈입니다. 마치 산만한 동료에게 30분마다 “원래 뭐 하기로 했지?“라고 물어주는 매니저와 같습니다.

결국엔 test-time compute 이야기

다른 각도로 보면, 루프는 추론 단계에서 컴퓨트를 더 쓰는 방향의 연장선입니다. OpenAI 연구원 노암 브라운(Noam Brown)이 이달 초에 정리한 한 줄이 있습니다. “요즘 모델은 컴퓨트만 충분히 부으면 거의 어떤 문제든 푼다.” 그렇다면 문제를 풀게 만드는 가장 단순한 방법은? 풀릴 때까지 컴퓨트를 부으면 됩니다.

특히 ‘언덕 오르기(hill-climbing)’ 형 문제에 잘 맞습니다. 코드 베이스 개선처럼 한 번에 0.1점씩이라도 올라갈 수 있는 작업이라면, 임계점에 닿을 때까지 계속 작은 개선을 쌓으면 됩니다. 체르니의 사례가 정확히 이겁니다. 끝이 정해진 작업이 아니라, 컴퓨트가 있는 한 계속 좋아지는 작업에 루프를 거는 겁니다.

비용 이야기를 빼면 절반만 본 겁니다

토큰을 얼마나 태우는지 감이 오시나요. 일반 챗봇은 사용자가 한 번 묻고 한 번 답하면 끝납니다. 에이전트는 한 작업당 수십 번 모델을 부릅니다. 루프는 거기에 천장을 없앤 구조입니다. 24시간 돌리면 24시간만큼 토큰을 씁니다. 일주일 돌리면 일주일만큼 씁니다.

토큰을 파는 Anthropic 입장에서는 더할 나위 없습니다. 그런데 사는 쪽 입장은 다릅니다. 한 달 코드 리뷰 자동화 한 번에 얼마가 나올지 가늠하기 어려워집니다. 그래서 루프를 도입하려면 드리프트(drift), 비용 한도, 감시 포인트까지 세트로 설계해야 합니다. 이게 없으면 그냥 새는 수도꼭지를 켜둔 것과 똑같습니다.

실무자가 볼 핵심 포인트

  • ‘에이전트 관리’ 패러다임이 바뀌고 있다는 사실 자체가 중요합니다. 지금까지는 명확한 목표 잡고, 작게 쪼개고, 너무 멀리 못 가게 잡아두는 게 정석이었습니다. 루프는 그 반대 방향, 즉 신뢰하고 풀어주는 쪽입니다.
  • 첫 도입은 ‘끝없이 좋아질 수 있는 작업’부터 하세요. 코드 아키텍처 정리, 중복 추상화 통합, 테스트 커버리지 향상처럼 임계 종료 조건이 모호한 일이 잘 맞습니다. 반대로 “한 번 답이 나오면 끝"인 작업은 굳이 루프로 갈 필요 없습니다.
  • Ralph Loop를 가장 작은 형태로 먼저 시도하세요. 자작 프레임워크부터 만들 필요 없습니다. “지금까지 한 일 요약 → 목표 달성 여부 자문” 두 단계면 시작 가능합니다.
  • 비용 한도와 감시 채널을 같이 설계하세요. 토큰 상한, PR 개수 상한, 머지 자동화 금지, 사람 리뷰어 필수처럼 명시적 제동장치가 없으면 사고가 납니다.
  • 드리프트 측정 지표를 정해두세요. 루프가 점점 엉뚱한 곳으로 빠지는지 확인할 신호(예: 통과 테스트 비율, 회귀 빈도, 리뷰 거절률)를 미리 정해두면 멈출 시점을 놓치지 않습니다.

원문 출처

원문 보기 — Russell Brandom, TechCrunch (2026-06-22)