AX LABS
← 블로그 에이전트 제품 설계

프롬프트가 아니라 루프를 설계하라

가장 가치 있는 일이 모델 호출에서 한 칸 멀어졌다

프롬프트 한 줄이 며칠 만에 AI 개발 현장의 화두를 바꿨다. Anthropic에서 Claude Code를 이끄는 Boris Cherny가 "나는 더 이상 Claude에게 프롬프트하지 않는다. Claude에게 프롬프트하고 다음 할 일을 정하는 루프들이 돌고 있고, 내 일은 그 루프를 설계하는 것"이라고 말했다.

Peter Steinberger가 "코딩 에이전트에게 프롬프트하지 말고, 에이전트에게 프롬프트하는 루프를 설계하라"로 이어받았고, Addy Osmani가 이 패턴에 루프 엔지니어링(Loop Engineering)이라는 이름을 붙였다.

새로 발명된 개념이 아니다. 현장 실무자들이 이름 없이 해오던 일에 정확한 이름이 붙었을 뿐이다. 그리고 이 이름은 코딩 에이전트보다 AX 전반에 더 중요하다.

작업의 단위가 네 번 이동했다

지난 2년간 "AI를 잘 쓴다"는 말의 의미는 계속 바뀌었다. 각 단계는 앞 단계를 감싸면서 레버리지를 모델 호출에서 한 걸음씩 멀리 옮겼다.

단계 무엇을 설계하나 작업 단위
프롬프트 엔지니어링 한 번의 지시 내가 직접 치는 한 턴
컨텍스트 엔지니어링 그 답에 무엇을 넣을지 문서·히스토리·도구 정의
하네스 엔지니어링 에이전트가 일하는 환경 전체 에이전트 하나의 작업 공간
루프 엔지니어링 무엇을 언제 프롬프트하고 언제 멈출지 스스로 판단하는 시스템

프롬프트 엔지니어링은 사라지지 않는다. 루프는 결국 프롬프트로 만들어지고, 루프 안의 엉성한 프롬프트는 엉성한 결과를 더 빨리 만들 뿐이다.

달라진 것은 무게중심이다. 가장 가치 있는 일이 좋은 프롬프트를 쓰는 데서 좋은 루프를 설계하는 데로 옮겼다.

루프는 재귀적 목표다

루프는 목적을 한 번 정해두면 일이 실제로 끝날 때까지 에이전트가 스스로 반복하는 구조다. 두 개의 층으로 보면 분명해진다.

안쪽 루프는 이미 돌고 있다. 에이전트는 매 턴 생각하고(Reason), 도구를 호출해 행동하고(Act), 결과를 관찰하고(Observe), 다시 생각한다. 학계가 ReAct라 부르는 패턴이다.

바깥 루프가 루프 엔지니어링이 얹는 층이다. 사람이 매 턴을 손으로 조종하는 대신, 일을 찾아내고 나눠주고 검증하고 기록하고 다음을 정하는 작은 운영 시스템이 에이전트를 대신 굴린다.

우리는 2년간 도구를 손에 쥐고 한 턴씩 움직였다. 이제는 그 도구를 찌르는 시스템을 만들고, 내가 아니라 그 시스템이 에이전트를 찌르게 둔다.

이름이 붙기 전 이 아이디어를 증명한 것은 'Ralph'였다. Geoffrey Huntley는 2025년 코딩 에이전트를 단순한 while 루프에 넣고 같은 프롬프트를 명세에 반복해 먹였다.

비결은 컨텍스트 리셋이다. 긴 세션은 창이 옛 추론과 막다른 길로 차면서 성능이 떨어지지만, 매 반복이 깨끗한 컨텍스트의 새 에이전트라면 이를 우회한다. 지능은 영웅적인 한 번의 실행이 아니라 잘게 쪼갠 명세, 검증 가능한 결과, 그리고 모델이 더럽힐 수 없는 외부 기억에 있다.

부품은 이미 다 들어 있다

좋은 소식은 이걸 직접 만들 필요가 없다는 것이다. 1년 전이라면 손으로 유지보수하는 bash 더미였겠지만, 지금은 Claude Code와 Codex 안에 부품이 이미 들어 있다. 직접 굴려보며 매핑하면 이렇다.

부품 실제 기능 (Claude Code / Codex) 하는 일
자동화 /loop, /schedule, hooks, GitHub Actions, Codex Automations 정해진 주기에 알아서 일을 찾고 분류한다
워크트리 git worktree, 백그라운드 워크트리 에이전트를 병렬로 돌려도 파일이 충돌하지 않는다
스킬 SKILL.md, CLAUDE.md 컨벤션·빌드 순서·금기를 한 번 적어 매 세션 재설명을 없앤다
커넥터 MCP 서버 이슈 트래커·DB·스테이징 API·Slack에 에이전트를 연결한다
서브에이전트 subagents, /goal의 검증 모델 만드는 에이전트와 검증하는 에이전트를 분리한다
메모리 컨텍스트 창 바깥의 마크다운·이슈 보드 에이전트는 잊어도 저장소는 기억한다

가장 유용한 한 수는 서브에이전트로 만드는 자와 검증하는 자를 분리하는 것이다. 코드를 쓴 모델은 자기 숙제를 후하게 채점한다. 다른 지시(때로는 다른 모델)를 가진 두 번째 에이전트가 첫 번째가 스스로 납득시킨 것을 잡아낸다.

그리고 메모리에는 단 하나의 조건이 있다. 컨텍스트 창 바깥에 살아야 한다. 마크다운 한 장이든 GitHub 이슈 목록이든, 내일 아침의 실행이 그 파일을 읽고 오늘 멈춘 지점에서 이어받는다.

멈춤 조건은 소원이 아니라 계약이다

루프에서 가장 중요한 한 줄은 역설적으로 '언제 멈출지'다. "체크아웃 흐름을 더 좋게 만들어라"는 채점 기준을 주지 않아서 루프가 내키는 대로 멈춘다.

장시간 무인 에이전트를 돌리는 실무자들은 멈춤 조건을 소원이 아니라 계약으로 쓰라는 같은 결론에 도달했다.

  1. 목표 상태 — "커버리지를 올려라"가 아니라 "src/billing 커버리지 90% 이상"
  2. 증거 — "다 된 것 같다"가 아니라 "테스트가 0으로 종료되고 리포트가 수치를 확인"
  3. 제약 — "공개 API를 건드리거나 기존 테스트를 지우지 말 것"
  4. 예산 — "25턴 또는 5달러, 먼저 도달하는 쪽에서 정지"

Claude Code의 /goal이 이 원리로 동작한다. 매 턴 뒤, 코드를 짠 모델이 아니라 별도의 작은 모델이 끝났는지를 채점한다. 만드는 자와 검증하는 자의 분리를 멈춤 조건 자체에 적용한 것이다.

하나의 루프는 실제로 이렇게 돈다

부품을 합치면 하나의 스레드가 작은 관제판이 된다. 매 평일 아침 도는 분류 루프를 예로 들면 이렇다.

  1. 자동화가 예약 시각에 저장소에서 깨어나 분류용 스킬을 호출한다.
  2. 스킬이 어제의 CI 실패, 열린 이슈, 최근 커밋을 읽고 메모리 파일에 발견 사항을 적는다.
  3. 할 가치가 있는 항목마다 격리된 워크트리를 열고 서브에이전트가 수정 초안을 만든다.
  4. 두 번째 서브에이전트가 그 초안을 프로젝트 스킬·기존 테스트에 대조해 검토한다.
  5. 커넥터가 PR을 열고 티켓을 갱신한다. 루프가 처리 못 한 건은 분류 인박스로 들어와 사람을 기다린다.

여기서 사람이 실제로 한 일을 보라. 시스템을 한 번 설계했을 뿐, 저 단계들을 직접 프롬프트하지 않았다. Codex든 Claude Code든 부품이 같기에 같은 루프가 돈다.

신뢰는 한 칸씩 벌어야 한다

엔터프라이즈 도입의 핵심 질문은 "어떻게 안전하게 단계적으로 올리는가"다. 루프도 같다. 한 번에 자동 병합까지 가면 안 된다.

단계 루프가 하는 일 사람의 역할
0 · 수동 없음 — 사람이 매 턴 프롬프트 전 과정 개입
1 · 분류 발견 사항을 마크다운에 기록 (코드 변경 없음) 읽고 판단
2 · 초안 격리 워크트리에 수정 초안 모든 PR 리뷰·병합
3 · 검증된 PR 검증 서브에이전트가 먼저 거른다 승인
4 · 자동 병합 저위험 항목(의존성 범프·린트)만 자동 병합 로그 감사

지금 단계가 '손으로 했을 일'을 실제로 만들어내고 있을 때만 다음 칸으로 올라간다. 각 레벨은 정확히 하나의 새 권한만 추가하고, 증거가 허락할 때까지 사람을 경로 안에 남긴다.

이것은 개발 이야기가 아니다

루프 엔지니어링은 코딩 에이전트에서 시작됐지만 핵심은 AX의 본질을 그대로 보여준다. 도구를 들여놓는 것과 일하는 방식을 시스템으로 다시 설계하는 것은 다르다.

"직원들이 프롬프트를 잘 쓰게 만들자"는 1단계다. 진짜 전환은 "반복되는 일을 발견하고 검증하고 멈추는 시스템을 누가 설계하는가"에서 일어난다. 더 똑똑한 모델을 기다리는 일은 우리 손 밖이지만, 지금 가진 모델을 더 잘 굴리는 루프는 지금 우리 손으로 만질 수 있다.

레버리지는 개인 역량에서 팀의 시스템으로, 다시 전사의 운영 구조로 이동한다. 잘 설계된 루프는 좋은 판단을 몇 배로 키우고, 잘못 설계된 루프는 나쁜 판단을 그것도 덜 지켜보는 사이에 몇 배로 키운다. 루프는 그 차이를 모른다. 사람만 안다.

그러니 루프를 설계하되 실행 버튼을 누르는 사람이 아니라 시스템을 책임지는 엔지니어로 남아야 한다. 반복되는 업무를 운영 가능한 루프로 다시 설계하려면 AX Ops 방법론 →

참고