프롬프트를 작성하지 마라. 루프(Loop)를 설계하고, 그 평가 결과를 내라.

Loop Engineering이라는 개념은 사상도 툴 대응표도 거의 완성되어 있다. 하지만 신기하게도, 그 '루프'를 실제로 계속 돌리는 운영 인프라(Production Infrastructure)에 대한 상상만은 각 AI 툴에 맡겨진 채 공백에 가깝다.

개념은 성숙해 있는데 운영 기반이 얇다——이 격차를, 굳이 AWS 서버리스(Serverless)로 메운다면 어떤 모습일지를 검토한 것이 본 기사이다.

참고로 본 기사의 AWS 구성은 **필자의 설계 제안(사고 실험)**이며, Loop Engineering 공식 권장 아키텍처(Architecture)가 아니다. 이 점은 본문에서도 반복해서 명시한다. 또한, 소속 조직을 대표하는 것이 아니다.

1. TL;DR

누가: Cobus Greyling이 cobusgreyling/loop-engineering이라는 레퍼런스 집합을 공개하며, Loop Engineering이라는 용어를 체계화했다. -
무엇을: AI 코딩 에이전트(Agent)를 '프롬프트로 움직이는' 것이 아니라, '루프(제어 시스템)를 설계하여 움직이는' 것을 위한, 툴을 넘나드는 패턴·체크리스트·CLI 군. -
본질: 레버리지(Leverage)의 지점이 개별 프롬프트에서, 에이전트를 시간축으로 통제하는 제어계(Control System)의 설계로 옮겨갔다는 주장이다. -
본 기사의 위치: 공식 구현이 아니라 '만약 AWS 서버리스에 올린다면'이라는 설계 사고 실험. -
AWS 매핑의 핵심: 원전의 '5가지 빌딩 블록(Building Blocks) + Memory'(자동화/루프 제어/워크트리/스킬 + 커넥터/서브 에이전트/상태)를 EventBridge·Step Functions·Fargate·DynamoDB·S3·Bedrock에 대응시킨다. -
주의사항: 이것은 제안일 뿐 공식 로드맵이 아니다. 무인 루프는 비용과 오류를 무인으로 늘리기 때문에, 검증 책임은 인간에게 남는다.

2. 개요

Loop Engineering 리포지토리는 사상(README·concepts), 툴을 넘나드는 프리미티브(Primitives) 대응표(primitives-matrix), 7가지 운영 패턴, 그리고 '자기 자신을 루프로 유지하는' 도그푸딩(dogfooding, .github/workflows/daily-triage.yml)으로 구성되어 있다. 인프라 상상은 의도적으로 경량이며, 스케줄링(Scheduling)은 각 툴 네이티브(Native)인 /loop · OS cron · systemd · GitHub Actions에 갇혀 있다.

본 기사는 다음 두 축으로 읽어 나간다.

개념의 매핑: 원전의 5 빌딩 블록 + Memory를 (일부를 본 기사 측에서 재구성한 후) AWS 서버리스의 각 서비스로 대응시킨다 (제5장). -
운영의 구현 이미지: 그 루프를 '돌리는 CI'와, 루프 기반 자체를 '배포하는 CI/CD'의 2개 층으로 나누어 설계한다 (제6장).

최신성에 관한 주석: AWS의 각 서비스 사양·요금·제한(Quota)은 변동한다. 본 기사의 서비스 선정은 집필 시점(2026년)의 일반적인 구성이며, 채택 전에 반드시 공식 문서에서 최신 사양을 확인해 주길 바란다.

3. 배경·계기 — "루프를 작성한다"라는 발언

계기는 개발자가 이제 프롬프트를 손으로 작성하지 않는다는 취지의 여러 발언이다. 원전 README는 두 실무자의 말을 인용하고 있다.

• Peter Steinberger (요약): 에이전트에게 직접 프롬프트를 입력하는 것이 아니라, 프롬프트를 내보내는 루프를 설계하는 쪽으로 돌아가라는 주장.
• Boris Cherny (Anthropic, Claude Code 책임자, 요약): 자신의 일은 루프를 작성하는 것이라고 말하고 있다.

개념의 계보로 정리하면 다음과 같은 흐름이 된다.

Agent Harness Engineering (Addy Osmani): 1개의 에이전트가 작동하는 환경(툴·문맥·권한·규칙)의 설계. -
Loop Engineering: 그 하네스(Harness)를 스케줄·상태·검증 체인(Verification Chain)으로 감싸 반복시키는 설계. -
본 기사의 "loop on managed infra": 그 루프를 매니지드(Managed) 클라우드 기반 위에서 운영하는 상상.

원전 스스로가 이 구분을 단적으로 적고 있다 (요약): 하네스는 단일 세션의 설정, 루프는 거기에 스케줄·상태·검증을 더한 것.

4. 개념 해설 — Before / After

한마디로 말하면, 루프(Loop)란 「하네스 (Harness) + 스케줄 (Schedule) + 상태 (State) + 검증 체인 (Verification Chain)」이다. 인간은 프롬프트 (Prompt)를 입력하는 대신, 이 제어계 (Control System)를 설계하고 판단을 스킬 (Skill)과 검증기 (Verifier)에 내장하는 쪽으로 역할을 전환한다.

Before (원전의 운영 형태)

• 개발자가 수동으로 프롬프트 (Prompt)를 입력하거나, 각 도구의 /loop를 실행한다.
• 스케줄 (Schedule)은 로컬 cron / systemd 타이머 / 단일 GitHub Actions 워크플로 (Workflow)이다.
• 상태 (State)는 STATE.md 등 리포지토리 (Repository) 내의 파일이다. 실례로, 원전은 자기 자신을 daily-triage.yml의 일간 워크플로 (Workflow)로 유지하고 있다.

사용자 (개발자)는 루프 (Loop) 안에 있다.

After (본 기사의 AWS 제안)

• 스케줄 (Schedule)과 이벤트를 관리형 이벤트 기반 인프라 (Managed Event Infrastructure)로 옮긴다.
• 루프 (Loop) 본체 (triage → 구현 → 검증 → 인간 게이트 (Human Gate))를 상태 머신 (State Machine)으로서 명시적으로 정의한다.
• 상태 (State)는 대화나 파일이 아니라, 내구성이 있는 관리형 스토어 (Managed Store)에 둔다.

개략적인 내용이며, 세부적인 서비스 선정은 조정이 필요하다. 사용자 (개발자)는 채점 결과와 인간 게이트 (Human Gate) 지점에 위치한다. 결과물의 최종 책임자는 "인간"이라는 점을 잊지 말아 주길 바란다.

5. 구성 요소의 분해 — 5가지 빌딩 블록 (Building Blocks) + Memory를 AWS로 사상하기

Loop Engineering의 핵심은 「5가지 빌딩 블록 (Building Blocks) + Memory」(원전 README: Automations/Scheduling · Worktrees · Skills · Plugins & Connectors · Sub-agents + Memory/State)와, 이를 8가지 도구로 전개한 대응표(원전 primitives-matrix)이다.

다음 표에서는 원전의 Skills와 Plugins & Connectors를 편의상 하나의 행으로 묶었으며, 대신 「Run-until-done / 루프 제어 (Loop Control)」라는 행을 본 기사 측에서 새로 추가했다. 이는 원전의 5가지 분류를 그대로 따르는 것이 아니라, AWS로의 사상 (Mapping)을 용이하게 하기 위해 본 기사에서 수행한 재구성이다. 여기서는 그 재구성된 프레임워크를 AWS 서버리스 서비스 (Serverless Services)로 사상한다. 반복하지만, 이는 본 기사의 제안이며 공식 구성은 아니다.

프리미티브 (Primitive, 원전)	루프 내 역할	AWS 서버리스 사상 (본 기사의 제안)
Automations / Scheduling	일정 cadence (주기)로 기동	EventBridge Scheduler (cron/rate 식). 이벤트 기반 (CI 실패, PR 이벤트 등)은 EventBridge Rules. 수동 실행은 Lambda URL 또는 API Gateway
Run-until-done / 루프 제어	검증이 성립할 때까지 반복	Step Functions (Choice / Retry / Map). 단, 원전의 loop-context가 가진 "동일 에러 N회 발생 시 에스컬레이션" 탐지는, DynamoDB에 시도 로그를 기록하고 Lambda로 판정하는 보조 로직이 필요
Worktrees	안전한 병렬 실행	Fargate (격리 컨테이너). git worktree를 사용하려면 컨테이너 간에 리포지토리를 공유하는 EFS 마운트, 또는 컨테이너 기동 시 S3에서 코드를 가져오는 부트스트랩 (Bootstrap)이 필요
Skills / Connectors	영속적 프로젝트 지식 + 실제 도구에 대한 도달	SKILL.md / AGENTS.md / CLAUDE.md를 S3에 보관하고, 컨테이너 기동 시 가져와서 지정된 경로에 배치. MCP 서버는 Lambda/Fargate의 사이드카 (Sidecar) 컨테이너로 기동. 인증 정보는 Secrets Manager, 외부 도달은 VPC / PrivateLink로 최소화
Sub-agents (maker/checker)	구현자와 검증자의 분리	Step Functions의 순차적 스테이트 (State)로 maker (Fargate) → checker (별도 Lambda/Fargate)를 분리. maker가 생성한 diff를 S3를 통해 checker에게 전달함으로써, checker는 maker의 컨텍스트를 전혀 가지지 않는 독립 채점이 가능해짐
+ Memory / State	대화 외의 내구적인 중추	DynamoDB (STATE.md 상당의 구조화된 상태 · 서킷 브레이커 상태 · kill switch) + S3 (loop-run-log JSON Lines · diff 아티팩트 · SKILL.md 등 정적 파일)

※ 비용 모니터링 (CloudWatch Billing Alarm, AWS Budgets의 예산 알람 등) 설정을 권장한다.

보충해야 할 점

• Scheduling: 원전의 dogfood (LOOP.md)는 Daily Triage 패턴에 대해 "Cadence: 1d weekdays (.github/workflows/daily-triage.yml)"라고만 기재되어 있으며, 구체적인 cron 구문은 1차 자료에서 확인할 수 없었다. 평일 일간(Daily)이라는 cadence를 EventBridge Scheduler에 대응시키고, 수동 기동 경로가 필요하다면 Lambda Function URL / API Gateway를 할당하는 것이 본 기사의 제안이다. -
• 루프 제어 (stagnation 탐지): --stagnation 3 (동일 에러 3회 발생 시 에스컬레이션)와 같은 "내용의 유사성에 의한 정체 탐지"는 Step Functions의 Retry만으로는 표현할 수 없으며, DynamoDB + Lambda의 보조 로직이 필요하다. -
• Worktrees: AWS 상에서는 컨테이너가 실행될 때마다 일회성으로 사용되고 상태를 유지하지 않으므로, EFS 공유 볼륨 위에서 git worktree add를 하는 방식과, 컨테이너 기동 시 shallow clone을 하는 S3 페치 (Fetch) 방식의 두 가지 선택지가 있다. 전자는 병렬 충돌 회피를 위해 네임스페이스 관리가 필요하며, 후자는 가볍지만 클론 시간이 레이턴시 (Latency)에 영향을 준다. -
• maker → checker: 원전의 checker는 maker와 완전히 별개의 세션에서 동작하며 "REJECT until proven"이 기본 스탠스 (starters/minimal-loop-claude/.claude/agents/loop-verifier.md)이다.

）。AWS에서 이러한 독립성을 유지하려면, diff를 S3를 통해 전달하고 Step Functions의 입력 JSON에 presigned URL을 포함하는 것이 적절하다. -
Human Gate: waitForTaskToken 패턴으로 표현한다. 리스크가 있는 변경 시 토큰을 발행하고, SNS/Slack을 통해 사람에게 통지하며, 승인이 돌아올 때까지 상태 머신(State Machine)을 멈춘다. -
LLM 실행 본체: Amazon Bedrock을 기본으로 설정하고, checker에는 maker와 다른 모델을 지정함으로써 '채점자가 채점 대상과 동일함' 문제를 회피할 수 있다.

6. 구현 이미지 — CI/CD를 2개 층으로 분리하기

코드는 제시하지 않고 설계의 골격만을 기술한다. 여기서 중요한 것은 'CI/CD'를 혼동하지 않도록 두 개의 층으로 나누어 생각하는 것이다.

층 1: 루프를 돌리는 런타임 (＝일일 운영 루프)

• EventBridge Scheduler가 cadence(예: 평일 아침)에 따라 루프를 기동한다. CI 실패 등의 이벤트는 EventBridge Rules를 통해 동일한 입구로 흘려보낸다. -
• Step Functions 상태 머신이 다음을 순차적으로 진행한다. -
  • Triage Lambda가 대상을 발견하고, DynamoDB의 상태를 읽고 쓴다. -
  • Fargate의 implementer가 격리된 워크트리(Worktree) 내에서 변경 사항을 생성한다. -
  • verifier(별도 모델)가 diff를 채점한다.
  • Choice 스테이트로 분기: 안전(허가 목록 내)하면 PR/커밋, 리스크가 있으면 waitForTaskToken으로 Human Gate를 거친다. -
  • 실행 기록을 S3 / DynamoDB에 추가한다.

Triage Lambda가 대상을 발견하고,

또한 원전의 LOOP.md에 따르면, Daily Triage 패턴은 "Phase: Report-only. Human reviews and decides actions."라고 명시되어 있으며, daily-triage.yml은 감사·상태 업데이트·사람에 대한 리포트까지 수행하는 것이지, 자동 PR을 생성하는 설계가 아니다. 자동 PR이나 머지(Merge)까지 파고드는 동작이 상정되어 있는 것은 PR Babysitter나 CI Sweeper 등 다른 패턴이며, 이들 역시 "no auto-merge(사람의 승인 없는 자동 머지는 하지 않음)"가 원칙이다.

따라서 본 기사의 Step Functions 상태 머신은, 원전의 daily-triage.yml이 실제로 수행하는 "감사 → 상태 업데이트 → 사람에 대한 리포트"라는 report-only 범위를 AWS 상에서 매니지드(Managed) 상태 머신으로 전개한 것으로 정의하는 것이 정확하다. 자동 PR 및 Human Gate를 거친 변경 적용까지 파고드는 부분은 원전의 daily-triage 패턴 그 자체가 아니라, 본 기사가 PR Babysitter 상당의 동작을 조합하여 확장한 제안이라는 점을 명시해 둔다.

원전 워크플로의 핵심은 "루프가 자신의 변경 사항을 마음대로 green(성공)으로 만들 수 없다"는 설계다. 이 불변 조건은 AWS 측에서도 반드시 지켜야 한다. verifier의 합격 여부를 Step Functions의 분기 조건으로 삼고, implementer 스스로는 합격 여부를 작성하게 하지 않는다.

층 2: 루프 기반을 배포하는 CI/CD (＝플랫폼의 출하)

• Step Functions 정의·Lambda·Fargate 태스크 정의·IAM·MCP 서버는 IaC로 관리하며, GitHub Actions 또는 CodePipeline으로 배포한다. -
• 일반적인 앱 CI/CD와 동일: lint → test → IaC plan → 승인 → apply.
• 층 1(루프의 내용물)과 층 2(루프 기반의 출하)를 섞지 않는 것이, 폭주 시의 격리(Isolation)와 권한 분리의 전제가 된다.

7. 정보원의 신뢰도와 주의사항

신뢰도: 높음 (본인 발언 및 1차 리포지토리에서 확인 가능)

원전 리포지토리 실물(README / docs/concepts.md / docs/primitives-matrix.md / daily-triage.yml), README가 인용하는 실무자의 발언(Steinberger, Cherny), Addy Osmani의 관련 개념, 태그라인 "Stop prompting. Design the loop. Get a score." —— 이들 모두 출처가 원전에 병기되어 있다.

신뢰도: 주의 요망 (본 기사의 해석 및 제안이며, 1차 정보가 아님)

본 기사의 AWS 구성 그 자체. EventBridge / Step Functions / Fargate 등으로의 매핑은 필자가 도출한 설계 제안이며, 리포지토리에는 AWS, Temporal, Lambda 등에 대한 기술은 일절 없다 (전체 검색으로 확인 완료). "Loop Engineering은 AWS를 사용한다"라고 오독하지 말 것.

원전 Caveats(주의사항)의 경고 (요약):

• 토큰 비용이 폭발할 수 있음. 서브 에이전트(Sub-agent)와 장시간 루프의 곱셈으로 비용이 급증한다.
• 검증 책임은 인간에게 남음. 무인 루프는 무인 상태 그대로 오류를 범한다.
• **이해 부채 (comprehension debt)**가 빠르게 쌓인다. 루프가 작성한 코드를 읽지 못하면 이해가 뒤처지게 된다.
• 동일한 루프라도 사람에 따라 결과가 반대로 나타날 수 있음. 루프는 이를 알아차리지 못한다. 알아차리는 것은 인간이다.

AWS에 올림으로써 새롭게 증가하는 주의점:

• 권한 최소화: Lambda/Fargate의 IAM 역할(Role)은 해당 단계에 필요한 최소 권한으로 제한한다. MCP 커넥터의 자격 증명은 Secrets Manager에 격리한다.
• 폭주 비용을 위한 서킷 브레이커 (Circuit Breaker): 원전의 loop-budget / loop-context가 가진 "상한선과 킬 스위치(Kill switch)" 사상을 Step Functions의 타임아웃, 실행 횟수 상한, 예산 알람(Budgets/CloudWatch)으로서 가드레일(Guardrail)화한다.
• 이것은 공식 구성이 아님: 채택 시에는 각 서비스의 최신 사양, 요금, 상한을 1차 정보로 확인할 것.

원전이 인용한 Addy Osmani의 말(요약)이 본질을 꿰뚫고 있다: 루프를 만들되, 단지 "버튼만 누르는 사람"이 아니라, 그대로 엔지니어로 남을 생각으로 만들 것.

8. 요약

• Loop Engineering은 "프롬프터로서의 자신을 루프(제어계)로 대체하는" 개념이며, 사상과 도구 대응표는 원전에서 완성되어 있다.
• 반면, 운영 인프라에 대한 가정은 각 도구 네이티브(native)의 cron/Actions에 국한되어 있으며, 그 부분을 AWS 서버리스(Serverless)로 채우는 것이 본 기사의 사고 실험이다.
• 5 빌딩 블록(Building blocks) + Memory는 EventBridge, Step Functions, Fargate, DynamoDB, S3, Bedrock로 솔직하게 매핑할 수 있다. maker/checker 분리와 인간 게이트(Human gate)는 Step Functions의 특기 분야다.
• CI/CD는 "루프를 돌리는 런타임(Runtime)"과 "루프 기반을 출하하는 CI/CD"의 2개 층으로 나누면 설계가 쉽게 무너지지 않는다.
• 단, 본 구성은 공식 권장 사항이 아니며, 비용, 검증 책임, 이해 부채, 권한 최소화라는 원전 유래의 리스크는 인프라를 바꾸더라도 사라지지 않는다.

참고 링크

1차 정보 (원전 리포지토리)

• Loop Engineering 리포지토리: https://github.com/cobusgreyling/loop-engineering
• README (태그라인, 5 빌딩 블록, Caveats): README.md
• Concepts & Vocabulary (Harness vs Loop, Adversarial Code Review): docs/concepts.md
• Primitives Matrix (도구 횡단 프리미티브 대응): docs/primitives-matrix.md
• 자기 유지 워크플로우 (dogfood): .github/workflows/daily-triage.yml

관련 발신

• Cobus Greyling – Loop Engineering (Substack 에세이): https://cobusgreyling.substack.com/p/loop-engineering
• Addy Osmani – Loop Engineering: https://addyosmani.com/blog/loop-engineering/

AWS 공식 문서 (본 기사의 매핑 대상. 채택 전에 최신 사양을 확인할 것)

• Amazon EventBridge Scheduler: https://docs.aws.amazon.com/eventbridge/
• AWS Step Functions: https://docs.aws.amazon.com/step-functions/
• AWS Lambda: https://docs.aws.amazon.com/lambda/
• AWS Fargate (Amazon ECS): https://docs.aws.amazon.com/AmazonECS/latest/userguide/what-is-fargate.html
• Amazon DynamoDB: https://docs.aws.amazon.com/dynamodb/
• Amazon Bedrock: https://docs.aws.amazon.com/bedrock/

본 기사의 AWS 구성은 필자(筆者)의 설계 제안이며, Loop Engineering 공식에서 권장하는 아키텍처가 아닙니다.

게시물은 개인적인 견해에 기반한 것이며, 소속 조직을 대표하지 않습니다.

토론 (Discussion)