프롬프트를 멈춰라. 루프를 설계하라.
출처: Pulumi Blog
약 2년 동안 코딩 에이전트와 작업할 때의 기본 단위는 프롬프트였습니다. 좋은 프롬프트를 작성하고, 충분한 컨텍스트를 제공하고, 반환된 결과를 읽은 뒤 다음 프롬프트를 작성했습니다. 에이전트는 도구에 불과했고, 여러분은 그 도구를 계속 손에 쥐고 한 번씩 차례를 넘겼습니다.
그 방식은 이제 끝나갑니다. 구글 클라우드 AI 디렉터인 애디 오스마니는 이를 대체하는 개념에 이름을 붙였으며, 저는 그 이후로 계속 생각해 왔습니다: 루프 엔지니어링. 이제 여러분은 에이전트를 직접 프롬프트하는 사람이 아니라, 에이전트를 대신 프롬프트하도록 루프를 설계하는 사람이 됩니다.
제 표현을 빌리자면, 여러분은 “실행하는 것”을 멈추고 “실행되는 것”을 설계하기 시작합니다. 레버리지가 한 층 위로 올라갑니다. 여기서는 구성 요소들을 솔직히 살펴보고, 아무도 자동화하지 않는 부분을 짚어보려 합니다.레버리지가 한 층 위로 올라갔다
이 도구들을 만든 사람들은 이미 그 점프를 마쳤습니다. 피터 스타인버거는 이를 매달 리마인더로 올리고 있습니다.Peter Steinberger (@steipete) on X.
앤트로픽에서 Claude Code를 이끄는 보리스 체르니도 자신의 업무에 대해 같은 말을 합니다. 그는 이제 Claude에 직접 프롬프트하지 않습니다. 대신 Claude에게 프롬프트를 전달하고 다음 작업을 결정하는 루프를 운영합니다. 이 루프는 이슈 트래커, 팀 채팅, 타임라인을 스캔해 무엇을 만들지 판단합니다. “내 일은 루프를 작성하는 것”이라고 그는 말합니다.
루프는 스스로를 프롬프트하는 목표입니다. 목적을 설정하면 시스템은 그 목표가 달성될 때까지 반복합니다. 실제로는 작업을 찾아 배정하고, 결과를 확인하고, 완료된 내용을 기록한 뒤 다음 작업을 결정하고, 여러분 대신 에이전트를 호출합니다. 이 작은 시스템을 한 번 만들면 그대로 실행하도록 두면 됩니다.
자세히 들여다보면, 루프는 사실 두 개의 루프가 중첩된 구조입니다. 내부 루프는 명세에 따라 작업을 수행하고, 외부 루프는 어떤 작업을 해야 할지 결정합니다. 외부 루프는 이슈 트래커, 오류 피드, 체인지로그 등을 감시하고, 다음 명세를 작성해 하위에 전달합니다. 대부분의 사람들은 아직도 이 외부 루프를 머릿속에서 손으로 돌리며, 이를 “백로그”라고 부릅니다.
저를 놀라게 한 점은 이것이 이제 거의 도구 문제만은 아니라는 것입니다. 1년 전만 해도 루프는 영원히 유지해야 할 일련의 bash 스크립트였지만, 이제 그 조각들은 제품 안에 내장되고, 같은 형태가 Claude Code와 Codex에서도 나타납니다. 오스마니는 루프 엔지니어링을 하나의 하네스 위에 두 번째 층으로 보는데, 하네스는 단일 에이전트를 둘러싼 컨텍스트와 도구들을 의미합니다. 저는 몇 주 전 그 하네스에 대해 글을 썼습니다. 루프는 그 위에서 동작하는 요소로, 타이머에 따라 실행되고, 헬퍼를 스폰하며, 스스로에게 피드백을 줍니다.
다섯 가지 구성 요소와 이를 연결하는 하나의 요소
루프 엔지니어링을 단순화하면 대략 다섯 개의 빌딩 블록과 기억을 보관하는 장소가 됩니다. Claude Code와 Codex 모두 이제 이 다섯 가지를 모두 갖추고 있습니다. 이름은 조금씩 다를 수 있지만 기능은 동일합니다.
- 자동화는 루프의 심장박동입니다. 자동화가 있어야 루프가 한 번 실행에 그치지 않고 지속적인 루프가 됩니다. 일정에 맞춘 프롬프트·명령, 예약 작업, 에이전트 라이프사이클의 특정 시점에 트리거되는 훅, 혹은 노트북을 닫아도 계속 돌아가는 CI 잡 등이 이에 해당합니다. 탐색과 트리아지는 스스로 실행되고, 중요한 인사이트만 여러분에게 전달됩니다.
- 워크트리는 병렬 작업이 혼란으로 번지는 것을 방지합니다. 두 개 이상의 에이전트를 동시에 실행하면 파일 충돌이 발생합니다. 두 에이전트가 같은 파일을 수정하는 상황은 두 엔지니어가 같은 라인을 커밋하면서 사전 협의가 없는 것과 같은 골칫거리입니다. git 워크트리는 별도의 브랜치에 독립된 작업 디렉터리를 제공하므로, 한 에이전트의 수정이 다른 에이전트의 체크아웃에 영향을 주지 않습니다.
- 스킬은 의도를 기록한 것입니다. 에이전트는 매 세션을 처음부터 시작하고, 여러분의 의도에 구멍이 있으면 자신 있게 추측합니다. 스킬은 외부에 기록된 의도로, 컨벤션, 빌드 단계, “그 사건 때문에 이렇게 하지 않는다”는 규칙 등을 포함합니다. 에이전트는 매 실행 시 이 스킬을 읽어 적용합니다. 스킬이 없으면 루프는 매 사이클마다 프로젝트 전체를 처음부터 다시 유도하게 됩니다.
- 커넥터는 루프가 실제 도구와 연결되게 합니다. MCP 위에 구축된 커넥터를 통해 에이전트는 이슈 트래커를 읽고, 데이터베이스를 쿼리하고, 스테이징 API를 호출하거나 채팅에 메시지를 남길 수 있습니다. 이는 “수정이 여기 있다”는 에이전트와, 풀 리퀘스트를 열고 티켓을 연결하며 CI가 녹색이 되면 채널에 알림을 보내는 루프의 차이입니다.
- 서브 에이전트는 제작자를 검사자와 분리합니다. 코드를 작성한 모델은 자신의 과제를 과하게 관대하게 평가합니다. 다른 지시를 가진 두 번째 에이전트(때로는 다른 모델)를 두어 첫 번째 에이전트가 스스로 설득한 오류를 잡아냅니다. 워크트리와 콜드 컨텍스트 리뷰어는 제가 이전에 다룬 주제로, 에이전트를 병렬로 실행하면서 서로 방해하지 않게 하는 방법이었습니다.
그리고 여섯 번째 요소: 메모리. 마크다운 파일, Linear 보드, 상태 파일 등 단일 대화 외부에 존재하며 수행된 일과 다음 작업을 보관하는 모든 것이 메모리입니다. 겉보기에 사소해 보이지만 바로 게임 전체를 좌우합니다. 모델은 실행 사이에 모든 것을 잊어버리므로 메모리는 디스크에 저장돼야 하고, 컨텍스트 윈도우가 아니라 저장소에 존재해야 합니다. 에이전트는 잊어버리고, 레포는 기억합니다.
루프를 견고하게 만드는 요소
무인으로 실행되는 루프는 실수도 무인으로 저지르게 됩니다. 루프가 스스로를 검증하도록 만드는 것이 바로 검증이며, 검증에는 모델 외부에서 확실히 “예” 또는 “아니오”를 반환하는 오라클이 필요합니다. 테스트 통과, 클린 빌드, 녹색 파이프라인, 실제 프로덕션 신호 등이 오라클에 해당합니다. 오라클이 없으면 루프는 자신 있게 잘못된 작업을 빠르게 누적시켜 버립니다.이 개념은 이미 도구에 구현돼 있습니다. Claude Code의
/goal은 여러분이 직접 정의한 조건(예: “auth/ 아래 모든 테스트가 통과하고 lint가 깨끗함”)이 만족될 때까지 여러 턴에 걸쳐 작업을 이어갑니다. 각 턴이 끝날 때마다 별도의 더 빠른 모델이 트랜스크립트를 읽고 목표 달성 여부를 판단합니다. 코드를 작성한 에이전트가 그 코드를 평가하는 것이 아니라, 별도의 평가자가 존재하는 것이죠