루프 엔지니어링 - 에이전트를 프롬프트하는 시스템을 설계하기

• 코딩 에이전트에게 매 턴마다 직접 프롬프트하던 방식을 끝내고, 에이전트를 대신 프롬프트하는 시스템을 설계하는 작업 방식으로의 전환
• 루프는 목적을 정의하면 AI가 완료될 때까지 반복하는 재귀적 목표이며, 약 다섯 개의 구성 요소로 이루어짐
• 다섯 요소는 Automations, Worktrees, Skills, Plugins·connectors, Sub-agents이며, Claude Code와 Codex 양쪽 모두 현재 다섯 가지를 전부 보유
• 여섯 번째 요소인 메모리는 단일 대화 밖에 상태를 저장하는 markdown 파일이나 Linear 보드로, 매 실행마다 잊는 모델을 보완
• 아직 초기 단계이며 토큰 비용 주의가 필수, 검증·이해는 여전히 사람의 몫임 (build the loop, stay the engineer)

루프 엔지니어링의 정의와 등장 배경

• 루프 엔지니어링은 에이전트에 프롬프트하는 사람의 자리를 자신에서 시스템으로 대체하는 것, 그 일을 대신하는 시스템을 직접 설계
  • 루프는 목적을 정의하면 AI가 완료될 때까지 반복하는 재귀적 목표(recursive goal)
  • 코딩 에이전트와 일하는 미래의 방식일 수 있으나 아직 초기 단계이며, 토큰 비용 주의가 필수 (token rich/poor 여부에 따라 사용 패턴이 크게 달라짐)
• 인용
  • Peter Steinberger "더 이상 코딩 에이전트에 프롬프트하지 말고, 에이전트에 프롬프트하는 루프를 설계하라"
  • Boris Cherny (Anthropic의 Claude Code 책임자) "이제 Claude에 프롬프트하지 않고, Claude에 프롬프트하고 무엇을 할지 정하는 루프를 돌린다. 내 일은 루프를 작성하는 것"
• 지난 약 2년간은 좋은 프롬프트와 충분한 컨텍스트를 주고, 한 턴씩 주고받으며 에이전트를 도구로 직접 쥐고 있는 방식이었으나 그 방식은 끝나가는 중
• 이제는 작업을 찾아 분배하고, 검증하고, 완료된 것을 기록하고, 다음 작업을 결정하는 작은 시스템을 만들어 그 시스템이 에이전트를 찌르게 함
  • 이전 글 agent harness engineering(에이전트 하나가 도는 환경)과 factory model(소프트웨어를 만드는 시스템)의 상위에 위치
  • 타이머로 실행되고, 작은 헬퍼를 생성하며, 스스로에게 먹이를 주는 harness
• 더 이상 도구의 문제가 아님 — 1년 전엔 루프를 원하면 bash 더미를 직접 작성·유지해야 했으나, 이제 구성 요소가 제품 안에 그대로 탑재됨
  • Steinberger의 목록이 Codex 앱과 거의 정확히 일치하고 Claude Code와도 거의 동일하므로, 어느 도구냐를 다투는 대신 어느 쪽에서도 동작하는 루프를 설계

루프의 다섯 가지 구성 요소와 메모리

• 루프에는 다섯 가지가 필요하고, 거기에 상태를 기억할 한 곳이 추가됨
  • Automations — 스케줄에 따라 발동해 스스로 발견·분류(triage)를 수행
  • Worktrees — 병렬로 일하는 두 에이전트가 서로 충돌하지 않도록 함
  • Skills — 에이전트가 추측으로 메울 프로젝트 지식을 기록해 둠
  • Plugins·connectors — 이미 쓰는 도구에 에이전트를 연결
  • Sub-agents — 한쪽이 아이디어를 내고 다른 쪽이 검증
• 여섯 번째는 메모리, markdown 파일이나 Linear 보드 등 단일 대화 밖에 살며 완료된 것과 다음 할 것을 보관
  • 너무 단순해 보이지만 모든 장기 실행 에이전트가 의존하는 동일한 트릭(이전 글 long-running agents)
  • 모델은 실행 사이에 모든 것을 잊으므로 메모리는 컨텍스트가 아니라 디스크에 있어야 함 — 에이전트는 잊어도 repo는 잊지 않음
• 두 제품 모두 현재 다섯 가지를 전부 보유, 이름만 조금 다를 뿐 능력은 동일

Automations — 루프의 심장 박동

• Automations는 루프를 한 번의 실행이 아닌 실제 루프로 만드는 요소
  • Codex 앱에서는 Automations 탭에서 생성, 프로젝트·실행할 프롬프트·주기·로컬 체크아웃인지 백그라운드 worktree인지를 선택
  • 무언가 발견한 실행은 Triage 인박스로 가고, 아무것도 못 찾은 실행은 스스로 아카이브됨
  • OpenAI는 일일 이슈 triage, CI 실패 요약, 커밋 브리핑 작성, 지난주 추가된 버그 사냥 같은 지루한 일에 내부적으로 사용
  • 자동화가 skill을 호출할 수 있어, 거대한 지시문 벽을 붙여 넣는 대신 $skill-name을 발동해 반복 작업을 유지보수 가능하게 함
• Claude Code는 스케줄링과 hooks로 동일 지점에 도달
  • /loop으로 일정 간격마다 프롬프트나 명령을 실행, cron 작업 스케줄링, 에이전트 라이프사이클 특정 시점에 hooks로 셸 명령 발사 가능
  • 노트북을 닫은 뒤에도 계속 돌리려면 전체를 GitHub Actions로 넘길 수 있음
• 세션 내 두 번째 프리미티브로 이 글의 핵심에 가까운 기능 존재
  • /loop은 정해진 주기마다 재실행
  • /goal은 작성한 조건이 실제로 참이 될 때까지 계속하며, 매 턴 후 별도의 작은 모델이 완료 여부를 검사해 코드를 쓴 에이전트가 채점자가 되지 않게 함
    • 예: "test/auth의 모든 테스트 통과, lint clean" 같은 조건을 주고 자리를 떠남
  • Codex도 동일하게 /goal을 제공, 검증 가능한 정지 조건이 성립할 때까지 턴을 넘기며 작동하고 pause·resume·clear 지원

Worktrees — 병렬이 혼돈이 되지 않도록

• 에이전트를 둘 이상 돌리는 순간 파일이 충돌하기 시작, 이것이 실패 지점
  • 두 에이전트가 같은 파일을 쓰는 것은 두 엔지니어가 서로 말 없이 같은 줄을 커밋하는 것과 같은 두통
  • git worktree가 이를 해결 — 같은 repo 히스토리를 공유하면서 각자의 브랜치 위 별도 작업 디렉터리이므로 한 에이전트의 편집이 다른 쪽 체크아웃에 닿을 수 없음
• Codex는 worktree 지원을 내장해 여러 스레드가 한 repo를 동시에 건드려도 부딪히지 않음
• Claude Code는 git worktree, 세션을 자체 체크아웃으로 여는 --worktree 플래그, subagent에 붙이는 isolation: worktree 설정으로 동일한 격리 제공 (각 헬퍼가 끝나면 스스로 정리되는 새 체크아웃을 받음)
• worktree는 기계적 충돌을 없애주지만 당신이 여전히 상한선 — 실제로 돌릴 수 있는 수는 도구가 아니라 본인의 리뷰 대역폭이 결정 (이전 글 the orchestration tax)

Skills — 매번 프로젝트를 다시 설명하지 않도록

• skill은 매 세션 금붕어처럼 같은 프로젝트 컨텍스트를 다시 설명하는 일을 멈추는 방법
  • 두 도구 모두 동일 포맷 사용 — 지시문과 메타데이터를 담은 SKILL.md가 든 폴더, 그리고 선택적 스크립트·참조·에셋
  • Codex는 $나 /skills로 호출하거나, 작업이 skill 설명과 맞으면 스스로 실행하므로 영리한 설명보다 간결하고 지루한 설명이 더 나음
  • Claude Code도 같은 방식 (이전 글 agent skills)
• skill은 의도(intent)가 반복 비용이 되지 않게 하는 곳
  • 에이전트는 매 세션을 차가운 상태로 시작하고 의도의 빈틈을 자신만만한 추측으로 메움 (이전 글 the intent debt)
  • skill은 그 의도를 외부에 적어둔 것 — 컨벤션, 빌드 단계, "그 사건 때문에 이렇게는 안 한다" 같은 것을 한 번 적어두면 에이전트가 매 실행마다 읽음
  • skill이 없으면 루프가 매 사이클마다 프로젝트 전체를 0에서 재유도, 있으면 누적되어 복리처럼 쌓임
• skill은 저작 포맷이고 plugin은 배포 방법 — 여러 repo에 공유하거나 묶을 때 plugin으로 패키징 (Codex·Claude Code 모두 동일)

Plugins·connectors — 루프가 실제 도구에 닿게

• 파일시스템만 볼 수 있는 루프는 작은 루프
  • MCP 기반의 connector가 에이전트로 하여금 이슈 트래커 읽기, DB 질의, 스테이징 API 호출, Slack 메시지 전송을 가능하게 함
  • Codex와 Claude Code 모두 MCP를 말하므로 한쪽용 connector가 보통 다른 쪽에서도 그대로 동작
  • plugin은 connector와 skill을 묶어, 동료가 기억으로 전체를 다시 구축하지 않고 한 번에 설치
• 이것이 "여기 수정안이 있다"고 말하는 에이전트와, PR을 열고 Linear 티켓을 연결하고 CI가 green이 되면 채널에 핑을 보내는 루프의 차이
  • connector는 루프가 단지 가능성을 말하는 데 그치지 않고 실제 환경 안에서 행동하게 하는 이유

Sub-agents — 만드는 쪽과 검사하는 쪽을 분리

• 루프에서 가장 유용한 구조는 단연 코드를 쓰는 쪽과 검사하는 쪽의 분리
  • 코드를 쓴 모델은 자기 숙제를 채점할 때 너무 관대함
  • 다른 지시문과 때로는 다른 모델을 가진 두 번째 에이전트가 첫 번째가 스스로 납득해 버린 것을 잡아냄
• Codex는 요청할 때만 subagent를 생성, 동시에 실행한 뒤 결과를 하나의 답으로 합침
  • .codex/agents/에 TOML 파일로 자체 에이전트 정의 (name·description·instructions, 선택적 model·reasoning effort)
  • 예: 보안 리뷰어는 high effort의 강한 모델, explorer는 빠른 read-only 모델
• Claude Code는 .claude/agents/의 subagents와 작업을 주고받는 agent teams로 동일하게 처리
  • 두 도구의 통상 분담은 한 에이전트가 탐색, 하나가 구현, 하나가 스펙 대비 검증 (이전 글 the code agent orchestra, adversarial code review)
• 루프는 보지 않는 동안 돌므로 신뢰할 수 있는 검증자(verifier) 가 있어야 자리를 떠날 수 있음
  • subagent는 각자 모델·도구 작업을 하므로 토큰을 더 소모, 두 번째 의견이 값어치 있는 곳에 사용
  • Claude Code의 /goal이 내부적으로 하는 일도 이것 — 새 모델이 작업한 쪽 대신 완료 여부를 판단, 정지 조건 자체에 maker·checker 분리를 적용

하나의 루프는 어떻게 생겼는가

• 합쳐 놓으면 단일 스레드가 작은 제어판으로 바뀜, 반복해 쓰는 한 가지 형태
  • automation이 매일 아침 repo에서 실행, 그 프롬프트가 triage skill을 호출해 어제의 CI 실패·열린 이슈·최근 커밋을 읽고 결과를 markdown 파일이나 Linear 보드에 기록
  • 할 가치가 있는 각 항목마다 스레드가 격리된 worktree를 열어 sub-agent에게 수정 초안을 맡기고, 두 번째 sub-agent가 그 초안을 프로젝트 skill과 기존 테스트 대비로 리뷰
  • connector가 루프로 하여금 PR을 열고 티켓을 갱신하게 함, 루프가 처리하지 못한 것은 triage 인박스로 들어옴
  • 상태 파일(state file) 이 전체의 척추 — 무엇을 시도했고 통과했고 아직 열려 있는지를 기억해 다음 날 아침 실행이 오늘 멈춘 지점에서 이어감
• 핵심은 그 단계들 중 어느 것도 프롬프트하지 않고 한 번 설계했다는 점 — Codex든 Claude Code든 구성 요소가 같아 같은 루프

루프가 여전히 대신해 주지 않는 것

• 루프는 일을 바꿀 뿐 사람을 지우지 않음, 오히려 루프가 좋아질수록 더 날카로워지는 세 가지 문제 존재
• 검증은 여전히 본인 몫
  • 무인으로 도는 루프는 무인으로 실수하는 루프이기도 함
  • verifier sub-agent를 maker와 분리하는 이유는 루프의 "끝났다"에 의미를 부여하기 위함이나, 그래도 "done"은 증명이 아니라 주장 (이전 글 code review in the age of AI — 일은 동작을 확인한 코드를 출하하는 것)
• 이해는 방치하면 썩음
  • 루프가 직접 쓰지 않은 코드를 빨리 출하할수록 존재하는 것과 실제로 이해하는 것 사이 간극이 커짐
  • 이것이 comprehension debt, 매끄러운 루프는 루프가 만든 것을 읽지 않으면 그 간극을 더 빨리 키움
• 편안한 자세가 위험한 자세
  • 루프가 스스로 돌면 의견 갖기를 멈추고 돌려받은 것을 그대로 받기 쉬움 (cognitive surrender)
  • 루프 설계는 판단을 갖고 하면 치료제, 사고를 피하려고 하면 가속제 — 같은 행동, 정반대의 결과

루프를 만들되, 엔지니어로 남아라

• 일이 진화하는 방식의 예고편으로 보이나, 코드를 직접 리뷰하지 않거나 자동 루프에만 의존하면 제품 품질이 떨어지고 점점 더 깊은 구멍으로 빠지는 하향 나선에 갇힐 수 있음
• 루프를 설정하되 에이전트에 직접 프롬프트하는 것도 여전히 효과적, 핵심은 적절한 균형 찾기
• 루프는 사람에 따라 정반대 결과 — 같은 루프를 만든 두 사람 중 한 명은 깊이 이해한 일을 더 빨리, 다른 한 명은 일을 이해하지 않으려고 사용
  • 루프는 그 차이를 모르지만 당신은 앎
• 이것이 루프 설계를 프롬프트 엔지니어링보다 쉽지 않고 더 어렵게 만드는 이유 — Cherny의 요점은 일이 쉬워졌다는 게 아니라 레버리지 지점이 옮겨졌다는 것
• 결론: 루프를 만들되, 그저 시작 버튼을 누르는 사람이 아니라 엔지니어로 남을 사람처럼 만들 것