루프 엔지니어링

루프 엔지니어링이란, 에이전트에게 프롬프트를 입력하는 사람인 자기 자신을 대체하는 일이다. 그 역할을 대신할 시스템을 설계하는 것이다. 크게 다섯 가지 구성 요소로 이루어지며, Claude Code와 Codex는 현재 둘 다 이 다섯 가지를 모두 갖추고 있다. 이것이 앞으로 우리가 코딩 에이전트와 협업하는 방식의 미래가 될 수도 있다고 생각한다. 다만 아직 초기 단계인 만큼 확신하기 이르고, 토큰 비용에도 각별히 주의해야 한다. 무제한 토큰 예산을 가진 사람은 거의 없다는 현실을 감안해, 루프 엔지니어링이 정확히 무엇이고 어떤 의미를 갖는지 차근차근 짚어보려 한다.

---

Peter Steinberger는 최근 이렇게 말했다. "이제 코딩 에이전트에게 직접 프롬프트를 입력하는 시대는 끝났다. 에이전트에게 프롬프트를 넣어주는 루프를 설계해야 한다." Anthropic에서 Claude Code를 이끄는 Boris Cherny도 비슷한 말을 했다. "나는 더 이상 Claude에게 직접 프롬프트를 입력하지 않는다. Claude에게 프롬프트를 넣고 다음 행동을 결정하는 루프를 돌리고 있다. 내 일은 루프를 짜는 것이다."

그래서, 이게 대체 무슨 뜻일까?

지난 2년간 코딩 에이전트를 활용하는 방식은 단순했다. 좋은 프롬프트를 작성하고 충분한 컨텍스트를 제공하는 것. 무언가를 입력하고, 돌아온 결과를 읽고, 다음 내용을 입력하는 식으로 이어졌다. 에이전트는 도구였고, 우리는 그 도구를 손에서 놓지 않고 한 턴 한 턴 직접 조작했다. 그런 방식은 이제 끝나가고 있다. 적어도 그렇게 보는 시각이 늘고 있다.

이제는 작업을 찾아내고, 배분하고, 결과를 검토하고, 완료 여부를 기록하고, 다음 단계를 결정하는 소규모 시스템을 직접 구축한다. 그리고 여러분 대신 그 시스템이 에이전트를 호출하도록 맡기는 것이다. 이전에 이와 유사한 개념인 에이전트 하네스(agent harness) 엔지니어링—단일 에이전트가 작동하는 환경을 구성하는 것—과 팩토리 모델(factory model)—소프트웨어를 생산하는 시스템—에 대해 쓴 적이 있다. 루프 엔지니어링은 하네스보다 한 단계 위에 위치한다. 하네스에 타이머가 붙고, 보조 에이전트를 생성하며, 스스로를 먹여 살리는 구조다.

놀라웠던 점은, 이것이 더 이상 특정 도구의 문제가 아니라는 사실이다. 1년 전만 해도 루프를 만들려면 bash 스크립트 더미를 직접 짜야 했고, 그건 고스란히 자신의 짐이 됐다. 지금은 필요한 구성 요소들이 제품 안에 기본으로 탑재되어 있다. Steinberger가 제시한 목록은 Codex 앱에 거의 그대로 대응되고, Claude Code와도 거의 일치한다. 구조가 같다는 걸 알고 나면 어떤 도구가 더 낫냐는 논쟁은 의미를 잃는다. 어느 도구에서든 작동하는 루프를 설계하면 그만이다.

다섯 가지 구성 요소, 그리고 메모

루프에는 다섯 가지 요소와 기억을 저장할 공간 하나가 필요하다. 먼저 목록을 보고, 이어서 각각을 도구에 대응시켜 보겠다.

1. 자동화(Automations): 일정에 따라 자동으로 실행되어 작업을 발굴하고 분류한다.
2. 워크트리(Worktrees): 병렬로 작업하는 에이전트들이 서로 충돌하지 않도록 격리한다.
3. 스킬(Skills): 에이전트가 추측으로 때워야 할 프로젝트 지식을 명문화한다.
4. 플러그인 및 커넥터(Plugins and connectors): 에이전트를 기존 도구들과 연결한다.
5. 서브 에이전트(Sub-agents): 하나가 아이디어를 내면 다른 하나가 검토한다.

여섯 번째는 메모리다. 마크다운 파일이든, Linear 보드든, 단일 대화 바깥에 존재하면서 완료된 작업과 남은 작업을 기록하는 무언가가 필요하다. 너무 단순해 보여서 별 의미 없어 보일 수 있다. 하지만 이건 장기 실행 에이전트라면 누구나 의존하는 핵심 원리다. 장기 실행 에이전트에 대해 쓴 글에서도 다뤘지만, 모델은 실행과 실행 사이에 모든 것을 잊어버린다. 그래서 기억은 컨텍스트가 아닌 디스크에 남아 있어야 한다. 에이전트는 잊어도, 레포는 잊지 않는다.

두 제품 모두 현재 이 다섯 가지를 모두 갖추고 있다.

명칭은 군데군데 조금씩 다르지만 기능은 동일하다. 하나씩 살펴보려 한다. 솔직히 루프가 제대로 돌아가느냐, 아니면 어디선가 조용히 무너지느냐는 세부 사항에 달려 있기 때문이다.

자동화: 루프의 심장박동

자동화는 루프를 단발성 실행이 아닌 진짜 루프로 만들어주는 요소다. Codex 앱에서는 Automations 탭에서 프로젝트, 실행할 프롬프트, 실행 주기, 로컬 체크아웃 또는 백그라운드 워크트리 중 실행 환경을 설정한다. 무언가를 발견한 실행은 트리아지 수신함으로 전달되고, 아무것도 발견하지 못한 실행은 자동으로 보관 처리된다—이 부분은 꽤 편리하다. OpenAI 내부에서는 일간 이슈 분류, CI 실패 요약, 커밋 브리핑 작성, 지난주에 추가된 버그 탐지 같은 단순 반복 작업에 활용한다고 한다. 자동화는 스킬을 호출할 수도 있어서 반복 작업을 유지보수하기 쉬운 형태로 관리할 수 있다. 아무도 업데이트하지 않을 일정에 긴 지시문을 붙여넣는 대신 $skill-name 하나만 실행하면 된다.

Claude Code는 스케줄링과 훅을 통해 같은 목표에 도달한다. /loop로 프롬프트나 명령을 주기적으로 실행하거나, cron 작업을 예약하거나, 에이전트 생명주기의 특정 시점에 훅으로 셸 명령을 실행할 수 있다. 노트북을 닫은 후에도 계속 실행되길 원한다면 GitHub Actions로 넘기면 된다. 핵심 개념은 동일하다. 자율 태스크를 정의하고 주기를 부여하면, 결과가 알아서 찾아온다. 직접 돌아다니며 확인할 필요가 없다.

자동화는 작업을 발굴하는 역할을 한다. 루프의 나머지 부분은 그 작업에 실제로 행동하는 역할이다.

워크트리: 병렬 작업이 혼돈으로 변하지 않으려면

에이전트를 두 개 이상 동시에 실행하는 순간, 파일 충돌이 시작된다. 이게 가장 흔한 실패 원인이다. 두 에이전트가 같은 파일을 동시에 수정하는 상황은, 두 개발자가 서로 말 한마디 없이 같은 줄에 커밋하는 것과 정확히 같은 문제다. git 워크트리가 이를 해결한다. 같은 레포 히스토리를 공유하면서도 독립된 브랜치 위의 별도 작업 디렉터리를 제공하기 때문에, 한 에이전트의 수정이 물리적으로 다른 에이전트의 체크아웃에 닿을 수 없다.

Codex는 워크트리 지원을 기본으로 내장해, 여러 스레드가 같은 레포를 동시에 사용해도 서로 충돌하지 않는다. Claude Code는 git worktree, 세션을 독립된 체크아웃에서 열기 위한 --worktree 플래그, 그리고 서브 에이전트마다 작업 후 자동 정리되는 새 체크아웃을 부여하는 isolation: worktree 설정으로 동일한 격리를 제공한다. 이 모든 것의 인간적 측면은 오케스트레이션 세금에서 다룬 바 있다. 워크트리는 물리적 충돌을 제거하지만, 여전히 병목은 사람이다. 실제로 얼마나 많은 에이전트를 운용할 수 있는지는 도구가 아니라 여러분의 리뷰 처리 능력이 결정한다.

스킬: 매 세션마다 프로젝트를 처음부터 설명하지 않으려면

스킬은 금붕어처럼 매 세션마다 같은 프로젝트 컨텍스트를 반복 설명하는 수고를 덜어주는 방법이다. 두 도구 모두 동일한 형식을 사용한다. 지시사항과 메타데이터를 담은 SKILL.md 파일이 있는 폴더 구조이며, 선택적으로 스크립트, 참조 파일, 에셋을 포함할 수 있다. Codex는 $이나 /skills로 호출하거나, 태스크 내용이 스킬 설명과 일치할 때 자동으로 실행한다. 그래서 스킬 설명은 영리하게 쓰는 것보다 단순하고 명확하게 쓰는 편이 낫다. Claude Code도 동일하게 작동하며, 그 패턴은 에이전트 스킬에서 정리한 바 있다.

스킬은 의도를 매번 새로 설명하는 비용을 없애주기도 한다. 의도 부채에서 주장했듯, 에이전트는 매 세션을 백지 상태에서 시작하며 의도의 빈틈이 있으면 자신감 있게 추측으로 채운다. 스킬은 그 의도를 외부에 명문화하는 것이다. 컨벤션, 빌드 절차, "저번 그 사건 때문에 이 방식은 쓰지 않는다"는 결정 같은 것들을 한 번 작성해두면 에이전트가 매 실행마다 읽어간다. 스킬 없이는 루프가 매 사이클마다 프로젝트 전체를 처음부터 다시 파악해야 한다. 스킬이 있으면 지식이 쌓인다.

한 가지 구분해야 할 것이 있다. 스킬은 작성 형식이고, 플러그인은 배포 수단이다. 스킬을 여러 레포에서 공유하거나 몇 가지를 묶어서 배포하고 싶을 때 플러그인으로 패키징한다. Codex도, Claude Code도 마찬가지다.

플러그인과 커넥터: 루프가 실제 도구와 연결되다

파일시스템만 볼 수 있는 루프는 너무 좁다. MCP 기반의 커넥터를 사용하면 에이전트가 이슈 트래커를 읽고, 데이터베이스를 조회하고, 스테이징 API를 호출하고, Slack에 메시지를 보낼 수 있다. Codex와 Claude Code 모두 MCP를 지원하기 때문에 한쪽에서 만든 커넥터는 대부분 다른 쪽에서도 그대로 작동한다. 그리고 플러그인은 커넥터와 스킬을 묶어 팀원이 기억에 의존해 처음부터 재구성하는 대신 한 번에 설치할 수 있게 해준다.

이것이 "수정 방법은 이렇습니다"라고 말하는 에이전트와, PR을 열고 Linear 티켓을 연결하고 CI가 통과되면 채널에 알림을 보내는 루프의 차이다. 커넥터 덕분에 루프는 "할 수 있다면 이렇게 하겠다"고 말하는 대신, 실제 환경 안에서 직접 행동할 수 있다.

서브 에이전트: 만드는 에이전트와 검토하는 에이전트를 분리하라

루프에서 구조적으로 가장 유용한 요소는 단연 코드를 작성하는 역할과 검토하는 역할의 분리다. 코드를 작성한 모델은 자기 숙제를 채점할 때 너무 관대하다. 다른 지시사항, 때로는 다른 모델을 가진 두 번째 에이전트가 첫 번째 에이전트가 스스로 합리화해버린 부분을 잡아낸다.

Codex는 요청이 있을 때만 서브 에이전트를 생성하고, 동시에 실행한 뒤 결과를 하나로 합친다. .codex/agents/에 TOML 파일로 에이전트를 직접 정의할 수 있으며, 각각 이름, 설명, 지시사항, 선택적으로 모델과 추론 강도를 설정한다. 보안 검토 에이전트는 강력한 모델로 높은 추론 강도로 설정하고, 탐색 에이전트는 빠른 읽기 전용 모델로 운용하는 식이다. Claude Code는 .claude/agents/의 서브 에이전트와 작업을 넘겨주는 에이전트 팀으로 같은 방식을 구현한다. 두 도구에서 가장 일반적인 구성은 탐색 에이전트, 구현 에이전트, 스펙 검증 에이전트의 세 역할 분리다.

이 주장은 이미 두 번 펼친 바 있다. 코드 에이전트 오케스트라와 적대적 코드 리뷰에서다. 루프 안에서 이것이 특히 중요한 이유는, 루프는 여러분이 지켜보지 않는 동안에도 돌아가기 때문이다. 그러므로 실제로 신뢰할 수 있는 검증 에이전트가 있어야만 자리를 비울 수 있다. 서브 에이전트는 각자 독립적인 모델 및 도구 작업을 수행하므로 토큰을 더 소모한다. 두 번째 의견이 그 비용을 정당화할 수 있는 곳에만 쓰는 것이 좋다.

루프는 어떤 모습일까

이 요소들을 하나로 엮으면, 단일 스레드가 작은 제어판으로 변한다. 내가 자주 사용하는 구성을 소개한다.

자동화가 매일 아침 레포 위에서 실행된다. 프롬프트는 트리아지 스킬을 호출하고, 이 스킬은 전날의 CI 실패, 열린 이슈, 최근 커밋을 읽어 결과를 마크다운 파일이나 Linear 보드에 기록한다. 처리할 가치가 있다고 판단된 항목마다 격리된 워크트리가 열리고, 서브 에이전트 하나가 수정안을 작성하고, 다른 서브 에이전트가 그 수정안을 프로젝트 스킬과 기존 테스트 기준으로 검토한다.

커넥터를 통해 루프가 직접 PR을 열고 티켓을 업데이트한다. 루프가 처리하지 못한 항목은 트리아지 수신함으로 넘어온다. 상태 파일은 이 모든 것의 척추 역할을 한다. 무엇을 시도했고, 무엇이 통과됐고, 무엇이 아직 열려 있는지를 기억하기 때문에, 다음 날 아침 실행은 오늘 멈춘 지점에서 이어진다.

그리고 실제로 여러분이 한 일을 돌아보면, 한 번 설계한 것이 전부다. 각 단계에 직접 프롬프트를 입력한 적이 없다. Steinberger의 요점이 현실로 구현된 것이고, Codex든 Claude Code든 구성 요소가 동일하기 때문에 루프도 동일하게 작동한다.

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

루프는 일의 방식을 바꾸지만, 사람을 없애지는 않는다. 그리고 루프가 발전할수록 오히려 더 날카로워지는 문제가 세 가지 있다. 쉬워지는 게 아니다.

검증은 여전히 여러분의 몫이다. 감시 없이 돌아가는 루프는 곧 감시 없이 실수를 만드는 루프이기도 하다. 검증 서브 에이전트를 제작 에이전트에서 분리하는 이유는 루프의 "완료"라는 말이 실제로 의미를 갖게 하려는 것이다. 그래도 "완료"는 여전히 주장일 뿐, 증명이 아니다. AI 시대의 코드 리뷰에서 반복해서 강조한 말이지만, 우리의 역할은 실제로 작동한다고 확인한 코드를 배포하는 것이다.

방치하면 이해력은 녹슨다. 루프가 여러분이 작성하지 않은 코드를 빠르게 배출할수록, 실제로 존재하는 코드와 여러분이 실제로 이해하는 것 사이의 간극은 벌어진다. 이것이 이해 부채(comprehension debt)다. 루프가 매끄러울수록 루프가 만들어낸 것을 직접 읽지 않으면 이 부채는 더 빠르게 쌓인다.

그리고 편안한 자세가 가장 위험한 자세다. 루프가 스스로 돌아갈 때, 의견을 갖는 것을 멈추고 루프가 내놓는 결과를 그냥 받아들이고 싶은 유혹이 생긴다. 이를 인지적 항복(cognitive surrender)이라고 부른 바 있다. 루프를 설계하는 행위는 판단력을 발휘하며 할 때는 해결책이 되고, 생각을 회피하려고 할 때는 가속제가 된다. 같은 행동, 정반대의 결과다.

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

똑같은 루프를 만든 두 사람이 완전히 반대되는 결과를 얻을 수 있다. 한 명은 깊이 이해하는 작업을 더 빠르게 처리하는 데 루프를 쓴다. 다른 한 명은 작업을 이해하는 것 자체를 피하는 데 루프를 쓴다. 루프는 그 차이를 알지 못한다. 아는 것은 여러분이다.

그것이 루프 설계를 프롬프트 엔지니어링보다 쉽지 않게, 오히려 더 어렵게 만드는 이유다. Cherny의 말은 일이 쉬워졌다는 뜻이 아니다.

핵심은 레버리지 포인트가 이동했다는 것이다. 루프를 만들어라. 하지만 그저 실행 버튼을 누르는 사람이 아니라, 끝까지 엔지니어로 남겠다는 마음으로 설계하라.