프롬프트를 멈추고 루프를 설계하라

AI 에이전트에게 일을 시키는 단위가 프롬프트에서 루프로 올라가고 있다. 안쪽/바깥 루프 구조와 메모리, 필터, 결정 표면, oracle 네 가지 멘탈 모델로 루프 설계법을 정리했다.

Claude Code를 만든 Boris Cherny가 인터뷰에서 이렇게 말했습니다.

저는 더 이상 Claude에게 프롬프트하지 않습니다. 루프가 Claude에게 프롬프트하고 무엇을 할지 정합니다. 제 일은 루프를 작성하는 것입니다.

처음 들으면 말장난 같습니다. 루프도 결국 프롬프트로 만드는 것 아닌가? 하지만 이 말의 무게는 작업 단위라는 개념을 잡아야 보입니다. 프로그래밍의 역사는 사람이 다루는 작업 단위를 한 층씩 올려 온 역사입니다. 펀치 카드에서 어셈블리로, C 같은 고수준 언어로, Rails와 Next.js 같은 프레임워크로, 그리고 프롬프트로. 단위가 한 층 올라갈 때마다 같은 시간에 만들 수 있는 것이 몇 배씩 커졌습니다. 레버리지는 언제나 작업 단위를 올릴 때 생겼습니다.

abstraction-ladder

지금 일어나는 전환은 그 사다리의 다음 칸입니다. 프롬프트 하나하나를 입력하는 대신, 프롬프트를 대신 실행하는 루프를 설계하는 것. 그 루프를 이해하는 데 필요한 건 도구 사용법이 아니라 몇 개의 멘탈 모델입니다.

당신은 이미 루프 안에 있다

루프가 낯선 개념 같지만, 사실 우리는 이미 매일 루프를 실행하고 있습니다. 에이전트와 주고받으며 spec을 만들고, 구현을 시킵니다. 끝나면 코드 리뷰를 시키고, 나온 문제를 고치게 합니다. 만족할 때까지 리뷰와 수정을 두세 번 반복합니다. 테스트를 실행하고, 브라우저를 열어 동작을 확인하고, 깨진 곳을 또 고칩니다. PR을 머지하고, 에러가 늘지 않는지 지켜봅니다. 에러가 나오면 다시 고칩니다.

이 과정 전체가 루프입니다. 다만 그 루프를 진행시키는 엔진이 사람입니다. 매 단계 사이에 사람이 앉아서 다음 프롬프트를 입력해야 루프가 한 칸 전진합니다. 작업 단위가 프롬프트라는 말은, 사람이 루프의 본체라는 뜻입니다.

전환은 이 전체 과정을 하나로 묶는 것에서 시작합니다. 입력은 사람이 쓴 spec 하나, 출력은 머지된 PR과 동작을 증명하는 화면 녹화. 그 사이의 모든 반복은 루프가 알아서 진행합니다. 이때 모든 루프는 형태가 달라도 같은 뼈대를 가집니다.

loop-anatomy

  1. 트리거: 루프를 깨우는 신호. 프롬프트일 수도, 정해진 시각일 수도, 데이터 소스의 이벤트일 수도 있습니다.
  2. 실행: 에이전트가 일을 합니다.
  3. 판정: 끝났는지 확인합니다. 이 판정을 누가 하는지가 루프의 품질을 정합니다(뒤에서 oracle로 다룹니다).
  4. 반복: 안 끝났으면 실행으로 되돌아갑니다. 끝났으면 사람에게 알리고 종료합니다.

루프를 설계한다는 건 이 네 박자를 명시적으로 정의하는 일입니다. 그리고 좋은 설계에는 공통된 사고 틀이 있습니다. 하나의 핵심 구조와 네 개의 멘탈 모델입니다.

핵심 구조: 안쪽 루프와 바깥 루프

루프 하나를 만들고 나면 곧 다음 질문에 부딪힙니다. "이 루프에게 일감은 누가 주는가?" spec을 구현하는 루프가 있어도, spec을 매번 사람이 써야 한다면 사람이 여전히 병목입니다. 그래서 루프는 두 겹으로 설계합니다.

inner-outer-loops

안쪽 루프는 일을 합니다. spec 하나를 받아 구현, 검증, 수정을 반복하고 PR을 내놓습니다. 잘 정의된 일감 하나를 끝까지 처리하는 실행 기계입니다.

바깥 루프는 일감을 공급합니다. 세상의 신호를 감시하다가, 할 일을 발견하면 spec으로 만들어 안쪽 루프에 넘깁니다. 1인 메이커라면 이런 바깥 루프를 상상할 수 있습니다. 매일 앱 스토어 리뷰를 읽고 반복되는 불만을 발견하는 루프. 광고 전환율을 지켜보다가 평소 범위를 벗어나면 원인 후보를 정리하는 루프. 이들의 출력이 안쪽 루프의 입력이 됩니다.

이 분리가 중요한 이유는 두 루프의 성격이 다르기 때문입니다. 주기가 다릅니다. 바깥 루프는 매일이나 매주 단위로 깨어나고, 안쪽 루프는 일감이 도착할 때마다 작동합니다. 책임이 다릅니다. 바깥 루프는 "무엇을 할 것인가"를, 안쪽 루프는 "어떻게 끝낼 것인가"를 책임집니다. 그리고 가장 중요한 차이로, 사람의 자리가 그 경계에 있습니다. 바깥 루프가 만든 일감을 안쪽 루프에 넘기기 전, 사람이 승인하는 관문을 둡니다. 무엇을 만들지는 여전히 사람이 정하고, 어떻게 만드는지는 루프에 맡기는 구조입니다.

이 구조를 실제로 작동하게 만드는 멘탈 모델 네 가지를 하나씩 살펴봅니다.

멘탈 모델 1. 루프는 매번 백지에서 깨어난다

루프를 처음 설계할 때 가장 먼저 부딪히는 사실은, 루프가 어제 일을 기억하지 못한다는 것입니다. LLM의 작업 기억은 컨텍스트 창 하나뿐이고, 실행이 끝나면 사라집니다. 스케줄로 깨어나는 루프는 매번 새 컨텍스트에서 시작합니다.

중요한 건 이것이 결함이 아니라 의도된 설계라는 점입니다. 컨텍스트를 길게 끌고 가면 오래된 정보가 판단을 오염시킵니다. RALPH loop를 만든 Geoffrey Huntley는 이를 "Fresh Context Is Reliability"라고 부릅니다. 매번 백지에서 시작하고 필요한 것만 다시 읽는 쪽이 오히려 믿을 만하다는 겁니다. 그래서 결론은 하나로 모입니다. 기억은 모델 안이 아니라 모델 밖에 둡니다. 파일, Git, 이슈 트래커처럼 루프가 깨어나서 읽을 수 있는 곳에. Anthropic이 권하는 방법도 거창한 데이터베이스가 아니라, 에이전트가 진행 상황을 파일에 적어 두고 다음에 다시 읽는 단순한 패턴입니다.

설계할 때는 두 가지 질문에 답하면 됩니다.

깨어날 때 무엇을 읽는가. 루프가 상황 파악에 필요한 최소한의 기록입니다. 읽을 양이 실행마다 늘어나는 구조라면 잘못된 설계입니다. 언젠가 깨어나는 비용이 일하는 비용보다 커집니다.

무엇을 적어야 같은 일을 반복하지 않는가. 앱 리뷰를 읽는 루프라면 처리한 리뷰의 ID를 기록합니다. 다음 실행 때 그 목록을 먼저 확인하면, 같은 리뷰로 같은 일감을 두 번 만들지 않습니다. 이 장치가 없는 루프는 매일 같은 발견을 반복하는 기계가 됩니다.

멘탈 모델 2. 파이프라인은 정보를 줄여야 한다

바깥 루프를 만들면 강한 유혹이 생깁니다. "감시하는 모든 것을 보고하게 하자." 매일 광고 지표를 정리해서 이슈로 만들고, 리뷰 한 건마다 일감을 만드는 식입니다. 이 유혹에 넘어가면 루프는 한 달 안에 무시당하는 기계가 됩니다.

이유는 비대칭에 있습니다. 기계는 공짜로 쓰지만, 사람은 비용을 내고 읽습니다. 루프가 이슈를 만드는 데는 토큰 몇 푼이면 되지만, 그것을 읽고 "무시해도 되네"라고 판단하는 건 매번 사람의 주의력입니다. 필터 없이 자동 생성하면 어떻게 되는지는 뻔합니다. 첫 주에는 다 읽습니다. 둘째 주에는 훑습니다. 셋째 주부터는 통째로 무시합니다. 그 순간 진짜 중요한 신호도 함께 묻힙니다. 운영 세계에서 alert fatigue라고 부르는 현상과 같습니다.

그래서 파이프라인의 각 단계는 들어온 것보다 적고 밀도 높은 것을 내보내야 합니다. 이벤트, 신호, 일감은 서로 다른 것입니다.

signal-funnel

리뷰 한 건은 일감이 아니라 증거입니다. 같은 문제를 가리키는 리뷰 다섯 건이 모이면 비로소 일감 하나가 됩니다. 묶는 과정에서 우선순위도 공짜로 나옵니다. 증거 12건이 붙은 일감과 1건짜리 일감의 처리 순서는 자명합니다.

평소에는 아무것도 만들지 않는 대신, 한 줄 다이제스트를 보내게 합니다. "오늘 전환율 정상 범위, 신규 리뷰 3건은 기존 일감에 병합." 이 한 줄은 정보가 아니라 심장박동입니다. 루프가 조용한 것이 정상이어서인지 죽어서인지, 이 한 줄이 알려줍니다.

멘탈 모델 3. 사람의 개입은 한 번의 제스처로

루프에 사람의 승인이 필요한 지점은 반드시 생깁니다. 일감을 안쪽 루프에 넘기기 전, 비용이 드는 행동을 하기 전. 문제는 개입의 형태입니다. 루프가 사람의 대답을 기다리며 멈춰 있는 구조라면, 사람이 자리를 비우는 순간 모든 것이 멈춥니다.

답은 결정 표면(decision surface)입니다. 루프가 사람에게 묻고 기다리는 게 아니라, 제안을 남겨두고 종료합니다. 사람은 자기 시간에, 자기가 쓰는 도구에서, 가장 가벼운 제스처로 결정을 남깁니다. Slack 메시지에 이모지 반응 하나, 이슈에 라벨 하나. 루프는 다음 실행 때 그 반응을 읽고 행동합니다. 광고 전환율 루프가 "랜딩 페이지 헤드라인을 이렇게 바꾸면 어떨까요"라고 제안을 남기면, 사람은 마음에 드는 제안에 이모지 하나를 남기고, 다음 실행 때 루프가 그 변경을 진행하는 식입니다.

이 방식에는 두 가지 설계 원칙이 들어 있습니다.

비동기여야 합니다. 루프와 사람은 서로를 기다리지 않습니다. 루프는 제안을 남기고 종료하고, 사람의 결정은 다음 실행의 입력이 됩니다.

마찰이 낮아야 합니다. 결정에 드는 비용이 문서를 열고 코멘트를 다는 수준이면, 사람이 병목이 되고 결정은 밀립니다. 이모지 하나, 라벨 하나 수준까지 낮춰야 결정이 흐름을 막지 않습니다.

그리고 개입의 범위는 신뢰에 따라 단계적으로 줄입니다. 처음에는 루프가 보고만 하게 합니다(dry-run). 보고가 믿을 만해지면 승인 후 실행을 허용합니다. 패턴이 검증된 좁은 영역부터 승인 없는 자동 실행을 풀어줍니다. 신뢰는 한 번에 위임하는 게 아니라 단계적으로 위임하는 것입니다.

멘탈 모델 4. 자기 채점을 금지하라

루프의 해부학에서 미뤄 둔 질문으로 돌아옵니다. "끝났는가?"는 누가 판정하는가. 이 판정 기준을 테스트 이론의 용어로 oracle이라고 부릅니다. 결과가 맞는지 틀린지 알려주는 심판입니다.

가장 흔한 실수는 이 판정을 모델 자신에게 맡기는 것입니다. 코드를 쓴 모델에게 "잘 됐나요?"라고 물으면, 코드를 쓸 때 가졌던 맹점을 채점할 때도 똑같이 가집니다. 학생이 자기 답안지를 채점하는 것과 같아서, 같은 오해는 두 번 다 통과합니다. 한 번이면 작은 오류지만 루프는 반복됩니다. 자기 채점으로 통과한 어설픈 결과가 다음 실행의 입력이 되고, 그 위에 쌓입니다. 루프에 메모리를 달아 복리를 기대했는데, 실제로 복리로 쌓이는 게 엉성한 결과물(slop)인 상황이 이렇게 만들어집니다.

그래서 판정은 모델 바깥에서 가져옵니다. oracle에는 등급이 있습니다.

oracle-ladder

잘 설계된 루프는 이 등급을 사다리처럼 씁니다. 안쪽 반복에서는 싼 oracle로 빠르게 거르고, 루프의 출구에서는 비싼 oracle로 확정합니다. 일감의 완료 기준을 "PR 머지"가 아니라 "전환율 회복 확인"에 두는 순간, 루프는 보고서를 쓰는 기계가 아니라 결과를 내는 기계가 됩니다.

한 가지 함정이 더 있습니다. 기준이 생기면 기준을 노리는 최적화도 생깁니다. 에이전트 루프에서 실제로 관찰되는 사례가 "테스트가 안 통과하니 테스트를 고쳐서 통과시키기"입니다. 그래서 oracle은 독립적이어야 할 뿐 아니라 루프가 건드릴 수 없는 곳에 있어야 합니다. 에이전트가 수정할 수 있는 테스트보다, 에이전트가 건드릴 수 없는 실제 지표가 더 강한 oracle입니다.

사례: 루프 네 개를 처음부터 끝까지

1인 메이커가 만들 만한 루프 네 개입니다. 데이터 소스만 다를 뿐, 모두 같은 뼈대(트리거, 바깥 루프, 결정 표면, 안쪽 루프, oracle)를 공유합니다.

Sentry 에러 수정 루프

PostHog 지표 조사 루프

앱 리뷰 대응 루프

광고 성과 개선 루프

네 루프의 뼈대는 같습니다. 감시하고, 거르고, 사람이 가볍게 결정하고, 구현하고, 현실로 판정합니다. 데이터 소스만 바꾸면 같은 설계가 어떤 도메인에도 적용됩니다.

새로운 발명이 아니다

네 개의 멘탈 모델을 늘어놓고 보면 익숙한 그림이 보입니다. 상태 없는 워커, 외부 상태 저장소, 비동기 승인 큐, 외부 판정 기준. 분산 시스템이 수십 년 전부터 쓰던 설계입니다. 에이전트 루프는 새로운 발명이 아니라 그 패턴을 다시 발견한 것에 가깝습니다. 그래서 저는 이 분야의 유행어보다 멱등성, 큐, oracle 같은 오래된 개념으로 풀어서 이해하는 쪽이 오래간다고 생각합니다.

시작은 작게 잡는 게 좋습니다. 매주 손으로 반복하는 과정 하나를 고르고, 트리거, 실행, 판정, 반복의 네 박자로 적어 봅니다. 메모리는 어디에 둘지, 출력은 일감인지 다이제스트인지, 승인은 어떤 제스처로 받을지, 완료는 무엇으로 판정할지를 정합니다. 그리고 첫 몇 주는 보고만 하게 합니다. 루프의 판단이 믿을 만하다는 게 확인되면 그때 손을 뗍니다.

Boris의 말이 가리키는 지점도 결국 여기입니다.

결국 당신은 직접 실행하는 존재이기를 멈추고, 실행되는 것을 설계하는 존재가 됩니다. 레버리지가 한 층 위로 올라갑니다.

참고 자료