루프 엔지니어링: 프롬프트를 쓰는 것에서 에이전트가 스스로 돌아가는 루프를 설계하는 것으로
2026년 6월 7일, Addy Osmani는 자신의 블로그에 「Loop Engineering」이라는 장문의 글을 발표했다. 그는 Anthropic의 Claude Code 리더인 Boris Cherny의 말을 인용했다:
"나는 이제 Claude에게 프롬프트를 쓰지 않는다. 루프가 Claude에게 프롬프트를 걸어주고, 루프가 다음에 무엇을 할지 스스로 결정한다. 내가 하는 일은 루프를 짜는 것이다."
이 말은 Peter Steinberger에 의해 더 슬로건에 가까운 버전으로 정리되었다: "더 이상 에이전트에게 프롬프트를 걸지 마라. 에이전트가 스스로 돌아가는 루프를 설계하라." 이틀 만에 '루프 엔지니어링(Loop Engineering)'이라는 용어는 AI 개발 커뮤니티에서 빠르게 퍼져나갔다.
왜 루프 엔지니어링이 갑자기 공감을 얻고 있는가?
두 가지 변화가 겹치면서 이 개념이 탄생했다.
변화 1: 단일 프롬프트의 레버리지가 붕괴되고 있다. Claude Code, Cursor Composer, Cline 같은 도구들은 "하나의 프롬프트 → 관찰 가능한 작업 단위"의 시간을 수십 초에서 수십 분, 심지어 수 시간으로 늘렸다. 한 번의 대화가 하나의 피처(feature)를 완성할 수 있게 되면서, "30초만 더 프롬프트를 다듬자"는 접근의 한계 효율(marginal return)은 급격히 희석되고 있다.
변화 2: 에이전트가 24시간 돌아갈 수 있게 되었다. GitHub Actions, cron, Claude Code의 /loop 명령어 등은 에이전트가 사람의 감시 없이도 작업을 계속할 수 있게 해준다. 에이전트가 세션(session)으로부터 독립할 수 있게 되면서, "누가 엔터를 누르는가"가 새로운 병목이 되었다.
Osmani의 표현을 빌리면:
"Loop engineering is replacing yourself as the person who prompts the agent."
— 루프로, 엔터를 누르는 '당신'을 대체하는 것이다.
다섯 가지 컴포넌트 + 하나의 State
Osmani는 실제로 동작하는 루프를 다섯 가지 컴포넌트와 하나의 공유 State로 분해한다. 중요도 순으로 정리하면 다음과 같다.
1. State (공유 메모리)
루프 전반에 걸쳐 읽고 쓸 수 있는 저장 공간이다. 마크다운 파일이든, SQLite든, TODO.md든 구현체는 중요하지 않다. **단일 사실 원(single source of truth)**이 핵심이다.
State는 반드시 루프 바깥에 있어야 한다. State를 대화 히스토리 안에 넣는 것은 안티패턴이다 — "아까 어디까지 이야기했더라"라는 세션 컨텍스트에 의존하는 루프는 context window가 가득 차는 순간 한 번에 무너진다.
2. Sub-agent (검증/분업)
두 번째 에이전트가 첫 번째 에이전트의 출력을 검증하는 구조다. 메이커-체커(Maker-Checker) 패턴.
핵심은 검증 에이전트가 독립적인 컨텍스트를 가져야 한다는 점이다. 같은 세션에서 "한번 더 생각해봐서 문제없는지 확인해"라고 하면, 모델은 자기 자신의 출력을 확인(confirm)하는 쪽으로 쏠리기 마련이다. 물리적으로 두 프로세스를 분리해야 효과가 있다.
3. Automation (트리거)
루프가 언제 작동하는지에 대한 설계. 세 가지 유형이 있다:
- Schedule-driven: 고정된 시간에 실행 (cron)
- Event-driven: 특정 이벤트에 의해 트리거 (PR 제출, 이슈 생성 등)
- Goal-driven: 검증 가능한 목표 조건을 주고, 루프가 스스로 실행·판단·종료
Goal-driven는 가장 저평가된 유형이다. 목표가 없으면 루프는 max-iteration에 도달해 강제 종료되거나, 사람이 직접 중지 버튼을 눌러야 한다.
4. Skill (컨텍스트 재사용)
"이 프로젝트에서 X류의 일을 어떻게 처리하는가"를 재사용 가능한 단위로 패키징한 것이다. Claude Code에서는 SKILL.md, Cursor에서는 .cursorrules가 이에 해당한다.
Skill은 프롬프트의 엔지니어링 버전이다 — "잘 쓴 한 단락의 프롬프트"에서 "프로젝트 전체가 사용하는 버전 관리되고, 여러 루프에서 참조 가능한 프롬프트"로의 진화다.
5. Worktree (병렬 격리)
병렬로 실행되는 각 에이전트가 독립적인 git worktree를 가져, 서로 간섭하지 않는다.
6. Plugin/Connector (외부 도구)
MCP 서버, API 커넥터, CLI 래퍼 등으로 에이전트가 단순히 텍스트만 출력하는 것이 아니라 실제로 데이터베이스를 수정하고, 커밋을 올리고, PR을 제출할 수 있게 한다.
가장 눈에 띄는 컴포넌트이지만, 역설적으로 가장 과대평가되기 쉬운 부분이다. State와 Sub-agent 없이 플러그인만 잔뜩 연결하면 스스로에게 지뢰를 묻는 셈이다.
계층 관계
Agentic 엔지니어링: 이 시스템이 하나의 목표를 신뢰성 있게 완수할 수 있는가
└── Harness 엔지니어링: 엔진 바깥의 기계 전체
├── Loop Engineering: 루프 자체의 설계
├── 기타 harness 하위항: 도구 호출, 관찰 가능성, 가드레일
└── Context 엔지니어링: 윈도우에 무엇을 넣을 것인가
└── Prompt 엔지니어링: 그 한 문단을 어떻게 잘 쓸 것인가
루프 엔지니어링은 다섯 번째 레벨이 아니라, harness 계층 안에서 독립적으로 명명된 엔지니어링 하위 분야다.
세 가지 부채: 루프가 매끄럽게 돌아갈수록, 당신은 무너질 가능성이 높다
1. 검증 부채 (Verification Debt)
루프가 돌아가면 "작업 완료"라는 출력을 내놓는다. 하지만 이 네 글자는 에이전트의 '주장'이지 '증명'이 아니다. CI가 초록불이어도 로직이 올바른 것은 아니고, PR이 올라갔다고 코드가 유지보수 가능한 것도 아니다.
갚는 방법은 오직 하나: 검증 단계를 루프 안에 물리적으로 넣어서, 루프가 사람이나 실행 가능한 테스트를 기다리며 멈추도록 만드는 것이다.
2. 이해 부채 (Comprehension Debt)
루프 덕분에 하룻밤에 PR 10개를 머지할 수 있게 되었다. 하지만 그 10개의 PR이 실제로 무엇을 바꿨는지 정말 이해하고 있는가? 6개월 뒤 프로덕션에 버그가 터졌을 때, 자기 저장고 앞에 서서 낯선 코드를 읽는 기분을 느끼게 될 수 있다.
갚는 방법은 감속 독서다 — 중요한 모듈은 루프가 작성한 뒤 바로 머지하지 말고, 직접 읽어보며 "왜 이렇게 했는가"를 한두 줄 메모하는 것이다.
3. 인지 항복 (Cognitive Surrender)
루프가 원활하게 돌아갈수록, 더 많이 돌리고 싶어진다. "버튼을 누르면 결과가 나온다"는 경험이 너무 중독적이기 때문이다. 어느 날 문득 "이 일을 해야 하는가?"를 더 이상 생각하지 않고, "어떤 루프에게 맡길까?"만 생각하는 자신을 발견하게 된다.
Osmani의 원문:
"The comfortable posture is the dangerous one."
— 편안한 자세가 가장 위험한 자세다. 이 부채는 도구로 갚을 수 없다. 오직 자기 각성에 달려 있다.
한 줄 요약
루프가 바꾸는 것은 당신의 업무 내용이지, 당신을 삭제하는 것이 아니다. 검증 부채는 당신이 확인하라고 요구하고, 이해 부채는 당신이 읽으라고 요구하며, 인지 항복은 당신이 생각하라고 요구한다. 세 가지를 모두 갚아야 루프 엔지니어링은 레버리지가 되고, 하나라도 갚지 못하면 그것은 만성 독이 된다.
로딩 중...