루프 엔지니어링: 프롬프트하는 시대에서 루프를 설계하는 시대로

지난 2년간, 코딩 에이전트에게서 무언가를 얻어내는 방법은 한 가지였습니다. 프롬프트를 쓰고, 맥락을 공유하고, 돌아온 결과를 읽고, 다음 프롬프트를 쓰는 것. 에이전트는 도구였고, 우리는 그 도구를 손에서 놓지 않았습니다.

그런데 그 방식이 끝나가고 있습니다. 레버리지 포인트가 "프롬프트를 잘 쓰는 사람"에서 "프롬프트하는 시스템을 설계하는 사람"으로 옮겨갔기 때문입니다. 이걸 구글 엔지니어 Addy Osmani가 2026년 6월 에세이 "Loop Engineering"에서 정리했고, 이미 Claude Code와 Codex 두 도구가 이 루프를 짜는 데 필요한 모든 부품을 갖췄습니다.

다만 먼저 솔직하게 말하겠습니다. 루프 엔지니어링은 진짜지만, 대부분의 개발자는 아직 필요하지 않습니다. 이 글은 14단계 로드맵을 통해 "당신에게 루프가 필요한지" 먼저 판단하고, 필요하다면 어떻게 안전하게 짓는지를 다룹니다.

루프 엔지니어링이란 무엇인가

루프 엔지니어링은 프롬프터로서의 나를 대체하는 작은 시스템을 짓는 일입니다. 이 시스템은 스스로 작업을 찾고, 에이전트에게 넘기고, 결과를 검증하고, 무엇을 했는지 기록하고, 다음 수를 결정합니다. 당신은 이 시스템을 한 번 설계합니다. 그 다음부터는 시스템이 알아서 에이전트를 프롬프트합니다.

비유하자면, 운전 학원 강사가 옆에 붙어 "여기서 좌회전" 하고 매번 지시하던 방식에서, 목적지만 정해주면 알아서 가는 자율주행으로 넘어가는 것과 같습니다.

신호: 레버리지는 이미 이동했다

방향성 신호는 꽤 분명합니다. AI 기업 Anthropic은 자사 엔지니어가 2026년 2분기 기준 2024년보다 하루에 8배 많은 코드를 머지하고 있다고 밝혔습니다.

다만 이 숫자는 조심해서 읽어야 합니다. Anthropic 자체가 이 8배 수치를 "거의 확실히 진짜 생산성 향상에 대한 과대평가"라고 명시했습니다. 코드의 양을 측정한 것이지 품질이 아니기 때문입니다(실제로 Anthropic은 AI가 쓴 코드 품질이 2025년 말에는 사람보다 못했고 지금은 비슷한 수준이라고 덧붙였습니다).

그래서 "8배 생산성"이라고 단정하면 안 됩니다. 중요한 건 숫자가 아니라 무게중심이 타이핑에서 루프 설계로 옮겨갔다는 방향입니다.

그런데 아무나 하면 안 된다: 4가지 조건

대부분의 바이럴 글은 "루프 짜라"만 외칩니다. 하지만 정직한 버전은 다릅니다. 루프는 다음 4가지 조건을 모두 통과할 때만 비용보다 이득이 큽니다. 하나라도 빠지면 루프는 그냥 토큰을 태웁니다.

작업이 반복된다. 최소 주 1회는 돌아와야 설치 비용이 회수됩니다. 일회성 작업이라면 좋은 프롬프트 하나가 더 빠르고 쌉니다.
검증이 자동화돼 있다. 테스트, 타입 체커, 린터, 빌드 등 사람 없이 나쁜 결과를 떨어뜨릴 무언가가 필요합니다. 없으면 결국 모든 diff를 직접 읽는 의자로 돌아옵니다.
토큰 예산이 낭비를 흡수한다. 루프는 맥락을 다시 읽고, 재시도하고, 탐색합니다. 결과를 내든 안 내든 토큰을 씁니다.
에이전트가 시니어 엔지니어의 도구를 가졌다. 로그, 재현 환경, 자기가 쓴 코드를 실행하고 무엇이 깨지는지 보는 능력. 이게 없으면 루프는 눈을 감고 반복합니다.

이 조건은 1인 기업과 소규모 팀에게 특히 중요합니다. 자동 테스트가 약하고 토큰 예산이 빠듯한 환경일수록 "루프가 손해"가 되기 쉽기 때문입니다.

루프를 만드는 5가지 빌딩블록

루프를 짜는 부품은 다섯 가지입니다. Claude Code와 Codex 모두 이제 다섯 개를 전부 갖췄습니다.

자동화(Automations) — 스케줄이나 이벤트로 발화하는 심장박동입니다. Claude Code의 /loop(주기 재실행), /goal(조건이 참이 될 때까지 + 별도 모델이 완료를 체크), Routines, 그리고 Codex의 Automations 탭이 여기 해당합니다.
Worktree — 에이전트끼리 같은 파일을 건드리지 않도록 격리하는 별도 작업 공간입니다. 여러 에이전트를 병렬로 돌릴 때 충돌을 막아줍니다.
스킬(Skills) — 프로젝트 맥락을 한 번 적어두고 매 실행마다 읽게 합니다. 스킬이 없으면 루프는 매 사이클 맥락을 처음부터 다시 유도합니다.
커넥터(Connectors) — MCP(Model Context Protocol)로 깃허브, 슬랙, 이슈 트래커, 에러 추적기 같은 실제 도구에 손을 뻗습니다. 깃허브 연동이 가장 즉효입니다.
서브에이전트(Sub-agents) — 코드를 쓰는 에이전트와 검증하는 에이전트를 분리합니다. 이게 다섯 중 가장 중요합니다.

가장 중요한 원칙: 만드는 AI와 검사하는 AI를 분리하라

루프에서 구조적으로 가장 쓸모 있는 것은 단연 쓰는 에이전트와 검증하는 에이전트를 나누는 것입니다.

Osmani의 표현이 정확합니다. 코드를 쓴 모델은 "자기 숙제를 너무 너그럽게 채점"합니다. 늘 A+가 나옵니다. 다른 지시를 받은(때로는 다른 모델인) 두 번째 에이전트가, 첫 번째가 스스로 합리화하고 넘어간 것을 잡아냅니다.

사실 새로운 개념도 아닙니다. 이것은 Anthropic이 2024년 12월 "Building Effective Agents" 글에서 이미 문서화한 evaluator-optimizer(평가자-최적화자) 패턴입니다. 2026년에 유행한 어휘가 18개월 전에 이미 적혀 있던 셈입니다.

조용히 실패하는 루프: Ralph 루프와 이해 부채

엔지니어 Geoffrey Huntley는 루프가 조용히 실패하는 방식을 문서화하고 'Ralph(Wiggum) 루프'라 이름 붙였습니다. 완료 신호를 반쪽짜리 작업에서 미리 뱉어버려, 루프가 절반만 끝난 상태로 종료되는 현상입니다.

원인은 셋입니다. 진짜 검증자가 없거나(두 낙관주의자가 맞장구), 완료 조건이 모호하거나, 하드 스톱이 없는 경우입니다. "두 번째 에이전트에게 리뷰시켰다"는 게이트가 아닙니다. 게이트는 의견이 아니라 통과 아니면 실패인 객관적 신호 — 테스트, 빌드, 타입 체크여야 합니다.

그리고 루프가 좋아질수록 날카로워지는 비기술적 위험이 있습니다. 바로 **이해 부채(comprehension debt)**입니다. 루프가 내가 쓰지 않은 코드를 빠르게 쌓을수록, 저장소가 담은 것과 내가 이해하는 것 사이의 거리가 벌어집니다. 진짜 아픈 청구서는 토큰이 아니라, 아무도 읽지 않은 시스템을 디버깅해야 하는 날입니다. 완화책은 기술적인 게 아닙니다. diff를 읽고, 게이트를 가끔 점검하고, 루프를 아키텍처 작업에서 차단하는 것입니다.

무인 루프는 무인 공격면이다: 보안세

무인으로 도는 루프는 무인으로 열린 공격면이기도 합니다. 미리뷰 상태로 코드가 머지되지 않도록 보안 검사(SAST, 의존성 감사, 시크릿 스캔)를 게이트에 포함해야 하고, 커뮤니티 스킬을 무턱대고 자동 설치하면 그 안에 숨은 인젝션을 그대로 상속하게 됩니다(스킬 소스는 설치 전 감사하세요). 디버그 로그에 크리덴셜이 흩어지지 않도록 하고, 권한은 30일마다 다시 점검하는 것이 안전합니다.

첫 루프는 무엇으로 시작할까

4가지 조건을 통과했다면, 가장 작은 루프부터 만드세요. 부품은 넷이면 충분합니다 — 자동화 1개, 스킬 1개, 상태 파일 1개, 게이트 1개. 순서도 중요합니다. 수동으로 한 번 안정적으로 돌린 뒤 → 스킬로 만들고 → 루프로 감싸고 → 그다음 스케줄을 겁니다.

좋은 첫 루프는 이런 것들입니다.

CI 실패 분류(나이틀리로 실패를 스캔하고 원인을 분류해 쉬운 것은 수정 PR 초안 작성)
의존성 업데이트 PR(주간으로 업데이트를 스캔하고 호환성을 테스트)
린트 자동 수정(PR이 열릴 때마다 스타일 수정)

반대로 아키텍처 재작성, 인증/결제 코드, 프로덕션 배포, 모호한 제품 작업처럼 "완료가 판단의 영역"인 일은 절대 루프에 맡기지 마세요. 사람이 의자에 앉아 봐야 하는 일입니다.

핵심 지표는 토큰도, 시도 횟수도 아닙니다. **변경 1건을 수용시키는 데 드는 비용(cost per accepted change)**입니다. 수용률이 50% 아래라면, 루프가 덜어주려던 리뷰 작업을 당신이 도로 하고 있는 것이고, 그 루프는 지고 있는 겁니다.

루프는 만드세요. 단, "버튼만 누르는 사람"이 아니라 "끝까지 엔지니어로 남을 사람"처럼 만드세요.

자주 묻는 질문 (FAQ)

Q. 루프 엔지니어링과 그냥 자동화는 뭐가 다른가요? A. 일반 자동화는 정해진 절차를 반복합니다. 루프 엔지니어링은 에이전트가 작업을 찾고, 검증하고, 다음 수를 스스로 정하는 판단까지 포함합니다. 핵심은 검증 게이트와 상태 기록입니다.

Q. 개인 개발자도 루프를 짜야 하나요? A. 4가지 조건(반복·자동검증·토큰예산·시니어도구)을 못 채운다면 아직은 좋은 프롬프트 하나가 더 낫습니다. 특히 소비자 요금제에서 무거운 검증 루프를 돌리면 토큰 비용이 먼저 도착합니다.

Q. Claude Code와 Codex 중 무엇으로 시작하나요? A. 둘 다 자동화·worktree·스킬·커넥터·서브에이전트 다섯 부품을 갖췄습니다. 쓰던 환경에서 작은 루프(CI 분류 등)부터 시작하는 것이 정답입니다.

Q. 검증은 왜 꼭 다른 에이전트가 해야 하나요? A. 코드를 쓴 모델은 자기 결과에 후한 점수를 줍니다(self-preferential bias). 독립된 검증자만이 합리화하고 넘어간 실수를 잡아냅니다.

참고자료

https://addyo.substack.com/p/loop-engineering https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic https://www.anthropic.com/research/building-effective-agents https://ghuntley.com/ralph/

루프 엔지니어링: 프롬프트하는 시대에서 루프를 설계하는 시대로 (14단계 로드맵)