Skip to content
Back to Blog
[TUTORIAL]

Claude Code 루프 엔지니어링: 프롬프트에서 루프를 짜는 사람으로

5 min read0 views

Claude Code 루프 엔지니어링: 프롬프트에서 루프를 짜는 사람으로

결론부터 말씀드릴게요. 이제 잘하는 사람은 Claude에게 매번 지시(프롬프트)를 타이핑하지 않습니다. 일을 시키는 루프(loop, 반복 작업 사이클) 자체를 설계하고, 루프가 알아서 Claude를 굴리게 둡니다. Anthropic의 Claude Code 팀은 2026-07-06 공식 가이드 "Getting started with loops"에서 이 흐름에 루프 엔지니어링(loop engineering) 이라는 공용 어휘를 붙였습니다. 저자는 Delba de Oliveira와 Michael Segner입니다.

왜 지금 이 이야기가 중요할까요? 모델이 좋아질수록 사람이 개입하는 단위가 커지기 때문입니다. 예전엔 문장 하나(프롬프트)를 던졌다면, 이제는 시스템 하나(루프)를 설계합니다. 이 전환을 놓치면 여전히 매번 붙어서 시키는 방식에 갇히고, 잡은 사람은 같은 시간에 몇 배의 일을 처리합니다.

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

루프란? 멈춤 조건(stop condition)에 닿을 때까지 "일하고 → 결과를 확인하고 → 다시 일하는" 사이클을 반복하는 에이전트입니다. 한 번의 응답으로 끝나는 복잡한 작업은 드물고, 에이전트는 반복할 수 있을 때 더 잘합니다.

여기서 핵심 질문은 딱 두 개예요. "어떻게 시작하고(트리거), 언제 멈추는가(멈춤 조건)". 이 둘을 설계하는 일이 바로 루프 엔지니어링입니다. 거창한 기술이 아니라, "무엇이 되면 이 일은 끝난 걸까?"를 글로 또렷하게 쓰는 능력이죠.

프롬프팅과 비교하면 이해가 쉽습니다. 프롬프트는 매번 사람이 직접 시키는 방식이고, 루프는 검증 조건을 한 번 걸어두고 위임하는 방식입니다. 매번 시키기에서 걸어두고 맡기기로 넘어가는 것, 그게 전부입니다.

루프의 4가지 유형

Claude Code의 루프는 트리거와 멈춤 조건에 따라 4가지로 나뉩니다.

  • turn-based(턴 기반): 사람과의 대화로 굴러가고, 사람이 판단해 멈추거나 max_turns(도구를 쓰는 턴 수) 상한으로 멈춥니다. 가장 단순한 형태예요.
  • goal-based(목표 기반, /goal): 사람이 목표를 주면 조건이 달성될 때까지 반복합니다. "다 될 때까지" 돌리는 프리미티브죠. /goal은 2026-05-11 버전 2.1.139에서 도입됐습니다.
  • time-based(시간 기반, /loop·/schedule): 목표가 아니라 시계로 돕니다. /loop 5m은 5분마다 워크플로를 반복해서 상시 점검이나 야간 감사 같은 반복 스트림에 맞습니다. 다만 로컬 루틴은 내 컴퓨터에서 도니 랩톱을 닫으면 멈춥니다.
  • proactive(선제적, Routines): 스케줄이나 API 호출, GitHub 이벤트 같은 외부 신호로 시작되는 클라우드 자동화입니다. Anthropic 서버에서 돌기 때문에 랩톱이 꺼져 있어도 작동합니다.

maker≠checker: /goal이 스스로 채점하지 않는 이유

/goal의 진짜 강점은 채점 방식에 있습니다. 매 턴이 끝날 때마다 분리된 작은 평가 모델(기본 Haiku) 이 지금까지의 대화 기록을 읽고 "다 됐나?"를 판정합니다. 코드를 쓴 에이전트가 자기 결과를 스스로 채점하지 않는다는 뜻이에요. 이걸 maker≠checker(만든 쪽과 채점하는 쪽을 분리) 라고 부릅니다.

그래서 목표는 Claude가 명령을 실행해 결과로 증명할 수 있는 형태로 써야 강력합니다.

  • 좋은 예: "test/auth의 모든 테스트 통과", "Lighthouse 점수 90 이상" — 결정론적이라 판정이 명확합니다.
  • 나쁜 예: "코드를 예쁘게" 같은 주관적 목표 — 평가 모델과 싸우거나 턴만 태웁니다.

fresh context(새 맥락)의 2차 에이전트로 리뷰를 붙이면 편향이 더 줄어듭니다. 메인 에이전트의 추론에 물들지 않은 리뷰어가 결과를 검증하기 때문이죠. 내장 /code-review 스킬이나 GitHub Code Review를 쓰면 됩니다.

가드레일: 멈춤 조건과 비용 상한

루프에서 가장 흔한 실패는 무한 루프, 목표 표류(goal drift), 토큰 비용 폭발입니다. 예외적인 사고가 아니라 프로덕션에서 자주 나오는 일이에요. 그래서 어렵고 또 중요한 두 가지가 앞서 말한 "완료를 분명히 쓰기"와 "폭주하지 않게 상한 걸기"입니다.

  • 비용 상한: max_budget_usd로 지출 임계 기반 상한을 겁니다. 상한이 없으면 Claude가 스스로 끝낼 때까지 도는데, 잘 스코프된 작업엔 괜찮지만 오픈엔드 지시엔 위험합니다.
  • 비용 운영: 루틴은 더 작고 빠른 모델로 돌리고, 판단이 필요한 지점만 가장 강한 모델을 씁니다. 큰 실행 전엔 작은 슬라이스로 파일럿을 돌리세요. 감시 대상이 바뀌는 빈도에 맞춰 주기를 정하고, 필요 이상으로 자주 돌리지 않는 게 중요합니다.
  • 모니터링: /usage로 스킬·서브에이전트·MCP별 사용량을, 인자 없는 /goal로 지금까지의 턴·토큰을, /workflows로 에이전트별 토큰을 확인하고 언제든 중단할 수 있습니다.

어디서부터 시작할까요?

거창하게 시작하지 마세요. 지금 내가 하는 일 중에 "내가 병목인 한 가지"를 고르고, 그중 넘길 수 있는 조각을 찾습니다. 판단 기준은 단 하나예요. "검증 체크를 내가 글로 쓸 수 있나?"

검증 조건을 쓸 수 있는 반복 작업이 첫 루프로 가장 좋습니다. 버그 트리아지(분류), 이슈 정리, 의존성 업그레이드, 마이그레이션 같은 일이 대표적이죠. 여기에 스킬(skill, 우리 팀 기준으로 "좋은 결과"가 무엇인지 코드로 적어둔 것)로 품질 기준을 박아두면, Claude가 매 루프에서 그 기준으로 자기 출력을 검증합니다. 결정론 도구(스크립트)는 매번 단계를 추론하는 것보다 싸고 안정적이라는 점도 기억해 두세요.

QJC 관점: 작은 팀의 레버리지

퀀텀점프클럽(QJC)은 작은 기업이지만 큰 기업의 AI 전환(AX)을 돕고, 그 과정에서 Claude Code·Codex·Hermes 에이전트로 회사 운영체제를 직접 짭니다. 루프 엔지니어링은 이 운영 모델의 정확한 이름이에요. 대표가 매번 지시하는 대신, 검증 조건(스킬·게이트)을 걸어 반복 업무를 에이전트에게 위임하는 방식이죠.

"프롬프트하는 사람"에서 "루프를 짜는 사람"으로의 전환은 1인·소규모 기업이 대기업급 처리량을 내는 레버리지의 핵심입니다. 사람이 붙는 시간을 늘리지 않고도 처리량을 키우는 유일한 길이, 검증 가능한 루프를 설계하는 것이기 때문입니다.

마무리

정리하면 이렇습니다. 루프는 멈춤 조건까지 반복하는 에이전트이고, 루프 엔지니어링은 "어떻게 시작해서 언제 멈추는가"를 설계하는 능력입니다. 4가지 유형(turn·goal·time·proactive) 중 내 일에 맞는 걸 고르고, /goal의 maker≠checker 채점을 활용하되 목표는 증명 가능하게 쓰고, max_budget_usd로 상한을 걸어 폭주를 막으면 됩니다.

오늘 딱 하나만 해보세요. 내가 병목인 반복 작업 하나를 고르고, 그 완료 조건을 한 문장으로 써보는 겁니다. 그게 첫 루프의 시작입니다.

자주 묻는 질문

Q: 루프 엔지니어링과 프롬프트 엔지니어링은 뭐가 다른가요?

프롬프트 엔지니어링은 매번 좋은 지시문을 사람이 직접 쓰는 일이고, 루프 엔지니어링은 검증 조건을 한 번 걸어두고 반복 작업을 에이전트에게 위임하는 일입니다. 개입 단위가 문장에서 시스템으로 커진다고 이해하시면 됩니다.

Q: /goal은 언제 멈추나요?

평가 모델이 목표 달성을 판정하면 멈추고, 지정한 턴 수에 도달해도 멈춥니다. 매 턴이 끝날 때마다 별도의 작은 모델(기본 Haiku)이 결과를 채점하기 때문에, 테스트 통과 수나 점수 임계치처럼 결정론적인 조건일수록 잘 동작합니다.

Q: 루프가 폭주해서 비용이 새면 어떡하죠?

max_budget_usd로 지출 임계 기반 상한을 걸면 됩니다. 상한이 없으면 Claude가 스스로 끝낼 때까지 돌기 때문에, 오픈엔드 작업에는 상한이 특히 중요합니다. /usage/workflows로 실시간 사용량을 보며 언제든 중단할 수도 있습니다.

Q: 비개발자도 루프를 만들 수 있나요?

네. 코드보다 중요한 건 "완료 조건을 글로 쓸 수 있는가"입니다. 버그 분류나 이슈 정리처럼 검증 조건이 분명한 반복 작업을 하나 골라 완료 기준을 적어보는 것부터 시작하시면 됩니다.

참고자료