저는 더 이상 Claude에게 직접 프롬프트를 입력하지 않습니다. Claude가 무엇을 해야 할지 스스로 파악하도록 하는 루프를 실행하고 있을 뿐입니다. 제 일은 루프를 작성하는 것입니다.
- 보리스 처니(Boris Cherny), Anthropic의 Claude Code 창시자이자 책임자.
약 2년 동안, 모두가 추구했던 기술은 프롬프트 엔지니어링이었습니다. 좋은 프롬프트를 작성하고, 충분한 맥락을 공유하고, 출력을 읽고, 다음 프롬프트를 작성하는 식이었죠. 당신은 에이전트를 도구처럼 한 번에 한 턴씩 다루었습니다.
그 시대는 조용히 막을 내리고 있습니다.
2026년 중반, 세 명의 목소리가 며칠 간격으로 같은 아이디어에 수렴했습니다. 보리스 처니(Claude Code)는 자신의 일이 이제 루프를 작성하는 것이라고 말했습니다. 피터 스타인버거(Peter Steinberger, OpenClaw 창시자)는 수백만 개발자에게 이렇게 말했습니다. "더 이상 코딩 에이전트에 프롬프트를 입력해서는 안 됩니다. 에이전트에 프롬프트를 입력하는 루프를 설계해야 합니다." 그리고 애디 오스마니(Addy Osmani, Google)는 널리 공유된 게시물에서 이 패턴에 이름을 붙였습니다: 루프 엔지니어링(Loop Engineering). 이 글에서는 루프 엔지니어링이 실제로 무엇인지, 어떤 문제를 해결하는지, 어떻게 해결하는지, 지금 당장 실행할 수 있는 실제 코드 데모, 그리고 과대광고 글에는 절대 언급되지 않는 정직한 트레이드오프를 분석합니다.
루프 엔지니어링이란 무엇인가?
루프 엔지니어링은 당신이 에이전트에게 프롬프트를 입력하는 역할을 대체하는 것입니다. 대신 프롬프트를 입력하는 시스템을 설계하는 것입니다.
루프는 재귀적 목표입니다. 목적과 검증 가능한 중단 조건을 정의하면, AI가 반복하며 작업을 발견하고, 구현하고, 검증하고, 진행 상황을 기록하여 조건이 충족될 때까지 계속합니다. 당신은 더 이상 루프 안에 있지 않습니다. 루프 위에 있는 것입니다.
계층 구조를 다음과 같이 생각해보세요:
- 프롬프트 엔지니어링: 하나의 좋은 명령어를 작성합니다.
- 컨텍스트 엔지니어링: 명령어 주변에 올바른 정보를 구성합니다.
- 에이전트 하네스 엔지니어링: 하나의 에이전트가 실행되는 환경을 구축합니다.
- 루프 엔지니어링: 타이머에 따라 하네스를 실행하고, 도우미를 생성하며, 자체적으로 확인하는 시스템을 구축합니다.
기존 워크플로우: 프롬프트 작성 → 출력 읽기 → 다음 프롬프트 작성 (당신이 루프입니다).
새로운 워크플로우: 루프를 한 번 설계 → 루프가 작업 발견 → 루프가 에이전트 할당 → 루프가 검증 → 루프가 상태 기록 → 반복 (당신은 검토하고 방향을 조정합니다).
루프 엔지니어링이 해결하는 문제들
문제 1: 당신이 병목 지점입니다
수동 프롬프트에서는 당신이 입력하지 않으면 아무 일도 일어나지 않습니다. 모든 턴은 사람을 기다립니다. 2026년의 에이전트는 몇 시간 동안 자율적으로 실행될 수 있으며, Claude Opus급 모델은 어려운 작업에서 거의 5시간 동안 감독 없이 실행된 사례가 있습니다. 하지만 인간이 주도하는 채팅은 당신의 타이핑 속도와 집중 시간에 의해 제한됩니다. 에이전트는 95%의 시간 동안 당신을 기다리며 유휴 상태입니다.
문제 2: 에이전트는 세션 사이에 모든 것을 잊어버립니다
매 세션은 빈 상태로 시작합니다. 모델은 프로젝트의 규칙, 빌드 단계, 그리고 힘들게 얻은 교훈을 처음부터 다시 유추하거나, 더 나쁘게는 자신 있게 추측으로 빈틈을 채웁니다. 이것이 오스마니가 의도 부채(intent debt)라고 부르는 것입니다. 즉, 명시되지 않은 의도가 매번 실행될 때마다 다시 갚거나(또는 다시 추측)되는 것입니다.
문제 3: 에이전트가 자신의 숙제를 스스로 채점합니다
코드를 작성한 에이전트는 코드를 검토할 때 너무 관대합니다. "다 됐어요"라는 주장은 증명이 아닙니다. 독립적인 검증 없이는 자율적 실행이 오류를 수정하기보다는 악화시킵니다.
문제 4: 병렬 에이전트가 충돌합니다
저장소에서 두 개 이상의 에이전트를 실행하는 순간, 그들은 서로의 파일을 덮어쓰기 시작합니다. 이는 두 명의 엔지니어가 서로 상의 없이 같은 줄에 커밋하는 것과 같은 재앙입니다.
문제 5: 반복 작업이 절대 자동화되지 않습니다
CI 실패 분석, 의존성 업데이트, 불안정한 테스트 추적, 이슈 레이블링, 일일 버그 정리 등은 지루하고 끝이 없으며 에이전트에 완벽하게 적합한 작업입니다. 하지만 아무도 매일 아침 에이전트에게 이 작업을 하라고 프롬프트를 입력하지 않습니다. 왜냐하면 당신이 매일 아침 나타나서 프롬프트를 입력해야 하기 때문입니다.
루프 엔지니어링이 문제를 해결하는 방법: 여섯 가지 구성 요소
실제로 감독 없이 실행되는 루프는 하나의 긴 프롬프트가 아닙니다. 다섯 가지 기능과 하나의 메모리를 갖춘 소규모 시스템입니다. 놀랍게도, Claude Code와 OpenAI의 Codex는 이제 이 여섯 가지를 모두 기본적으로 제공합니다. 루프 형태는 도구에 구애받지 않게 되었습니다.
- 자동화(Automations): 심장박동
발견과 분류를 자체적으로 수행하는 예약된 실행입니다. 이는 문제 5를 해결합니다.
- Claude Code: /loop 는 프롬프트를 일정 주기(1분 간격에서 며칠 단위까지)로 재실행합니다. cron으로 예약된 작업, Routines(클라우드 예약 자동화), 수명 주기 훅, 또는 노트북을 닫아도 유지되는 GitHub Actions 등이 있습니다.
- Codex: Automations 탭에서 프로젝트, 프롬프트, 주기를 선택하면 결과물이 Triage 받은 편지함에 들어가고, 빈 실행은 자동으로 보관됩니다.
세션 내에서 가장 강력한 기본 명령어는 /goal입니다. 당신이 작성한 조건(예: "test/auth의 모든 테스트 통과 및 린트 클린")이 검증 가능하게 충족될 때까지 턴을 계속 진행하고 자리를 비울 수 있습니다.
- 작업 트리(Worktrees): 병렬 처리를 위한 격리
Git 작업 트리는 각 에이전트에게 저장소 기록을 공유하면서 자체 브랜치에 자체 작업 디렉토리를 제공합니다. 편집 내용이 문자 그대로 충돌할 수 없습니다. 이는 문제 4를 해결합니다.
- Claude Code: git worktree, --worktree 플래그, 또는 하위 에이전트에 isolation: worktree를 사용하여 각 도우미가 새롭고 자체 정리되는 체크아웃을 받도록 합니다.
- Codex: 스레드당 내장된 작업 트리.
고급 사용자들은 이 방법으로 10~15개의 병렬 에이전트를 실행한다고 보고합니다.
- 스킬(Skills): 코드화된 프로젝트 지식
스킬은 SKILL.md 파일이 포함된 폴더입니다. 여기에는 프로젝트의 규칙, 빌드 단계, 그리고 "그 사건 때문에 이렇게 하지 않는다"와 같은 내용이 한 번 작성되고, 에이전트가 매 실행마다 읽습니다. 이는 문제 2를 해결합니다. 스킬이 없으면 루프는 매 주기마다 프로젝트를 처음부터 다시 유추합니다. 스킬이 있으면 지식이 축적됩니다.
- 플러그인 및 커넥터(Plugins & Connectors, MCP): 실제 도구를 다루는 손
파일 시스템만 볼 수 있는 루프는 매우 제한적입니다. MCP 커넥터를 사용하면 이슈 트래커를 읽고, 데이터베이스를 쿼리하고, PR을 열고, Linear 티켓을 업데이트하고, CI가 통과했을 때 Slack에 알릴 수 있습니다. 이것이 "여기 수정 사항이 있습니다"라고 말하는 에이전트와 수정 사항을 배포하는 루프의 차이입니다.
- 하위 에이전트(Sub-agents): 제작자와 검사자 분리
전체 패턴에서 가장 중요한 구조적 아이디어입니다. 하나의 에이전트(또는 모델)가 작성하고, 다른 지침을 가진 다른 에이전트가 검증합니다. 이는 문제 3을 해결합니다. Claude Code의 /goal에는 이것이 내장되어 있습니다. 별도의 모델이 중단 조건이 충족되었는지 평가하므로 작업자가 자신의 숙제를 스스로 채점하지 않습니다.
- Claude Code: .claude/agents/의 하위 에이전트, 에이전트 팀.
- Codex: .codex/agents/의 TOML 형식 하위 에이전트. 예를 들어, 높은 추론 노력의 강력한 모델을 보안 검토자로, 빠른 읽기 전용 모델을 탐색자로 사용합니다.
- 상태(State): 메모리 중추
마크다운 파일, 진행 로그, 또는 Linear 보드 등 대화 외부에 존재하며 완료된 작업과 다음 작업을 기록하는 모든 것입니다. 너무 단순해서 중요하지 않게 들릴 수 있습니다. 하지만 모든 장기 실행 에이전트가 의존하는 유일한 비결입니다: 모델은 실행 사이에 잊어버리지만, 저장소는 잊지 않습니다. 이는 작업 수준에서 문제 2를 해결하며, 다음 날의 실행이 오늘 중단된 지점에서 정확히 재개될 수 있도록 합니다. 자동화와 함께 문제 1을 해소합니다. 즉, 당신이 자는 동안에도 루프가 작동합니다.
실제 루프 하나의 예시
다음은 참조 형태입니다(오스마니 자신의 일일 루프에서 각색):
- 자동화가 저장소에서 실행됩니다. 해당 프롬프트는 분류 스킬을 호출하여 어제의 CI 실패, 열린 이슈, 최근 커밋을 읽고 결과를 STATE.md에 기록합니다.
- 수행할 가치가 있는 각 결과에 대해 루프는 격리된 작업 트리를 열고 제작자 하위 에이전트를 파견하여 수정 초안을 작성합니다.
- 검사자 하위 에이전트가 프로젝트 스킬 및 기존 테스트와 비교하여 초안을 검토합니다.
- 커넥터가 PR을 열고, 티켓을 연결하고, Slack에 게시합니다.
- 루프가 처리할 수 없는 모든 것은 당신을 위한 분류 받은 편지함에 들어갑니다.
- STATE.md는 시도한 내용, 통과한 내용, 아직 열려 있는 내용을 기록합니다. 다음 날의 실행은 거기서부터 재개됩니다.
출처 및 추가 자료: Addy Osmani, "Loop Engineering" (addyosmani.com); The New Stack의 루프 엔지니어링 보도; Meta의 Scale 컨퍼런스 및 CNBC 인터뷰에서의 Boris Cherny 대담; Claude Code Routines 문서 (code.claude.com/docs/en/routines); OpenAI Codex Automations 문서.
이 글을 바탕으로 루프를 구축하셨다면, 어떤 것을 가장 먼저 자동화하셨는지 댓글로 알려주시면 감사하겠습니다!
