이제 프롬프트를 작성하지 마라──「Loop Engineering」이라는 새로운 패러다임의 정체
요약
프롬프트를 직접 작성하는 단계를 넘어, 에이전트가 스스로 작업을 수행하도록 시스템을 설계하는 'Loop Engineering' 패러다임을 소개합니다. 단순 지시(Prompting)에서 시스템 설계(Loop Design)로 변화하는 AI 활용의 진화 과정을 다룹니다.
핵심 포인트
- AI 활용 패러다임이 프롬프트 엔지니어링에서 루프 엔지니어링으로 진화 중
- Loop Engineering은 에이전트를 호출하는 시스템을 설계하는 과정
- 프롬프트는 사라지는 것이 아니라 루프를 구성하는 부품으로 통합됨
- 미래의 핵심 인재는 프롬프트 작성자가 아닌 루프 설계자가 될 것
서론: 그 사람은 이제 프롬프트를 작성하지 않는다
어느 날, X의 타임라인을 훑어보고 있는데 이런 인용글이 흘러왔습니다.
Boris Cherny (Claude Code 책임자)
"I don't prompt Claude anymore. I have loops running that prompt Claude. My job is to write loops." (이제 Claude에게 프롬프트를 내지 않는다. Claude에게 프롬프트를 내는 「루프(Loop)」를 실행시키고 있다. 나의 업무는 루프를 작성하는 것이 되었다)
…잠깐만 기다려주세요. Claude Code를 만든 장본인이, 이제 Claude에게 프롬프트를 작성하지 않는다고?
처음 읽었을 때, 솔직히 "자기 홍보(Position Talk) 아닌가?"라고 생각했습니다. 절반은 농담이겠지 하고 말이죠. 하지만 Google Chrome의 엔지니어링 디렉터 Addy Osmani가 2026/06/07에 올린 Loop Engineering이라는 블로그를 읽고, Peter Steinberger의 연재글을 읽고, 자신의 수중 운영 상황을 살펴보며, 마침내 "아, 아마 진심으로 말하는 거구나"라고 납득했습니다.
지난 반년 동안, 제 주변에서도 실제로 그렇게 변하고 있기 때문입니다. 아침에 일어나면 모르는 PR(Pull Request)이 3개 생성되어 있고, 모르는 티켓이 2개 클로즈(Close)되어 있으며, 모르는 버그가 1개 수정되어 있습니다. 저는 아무런 프롬프트도 작성하지 않았습니다. 처음에는 기분이 이상했고, 지금도 조금 이상합니다.
이 기사에서는 현재 조용히 퍼져나가고 있는 「Loop Engineering」이라는 사고방식을 뉴스 요약·구현 내용·팀에 도입할 때의 주의점이라는 3개의 레이어로 정리합니다. 절반은 속보 메모, 절반은 내일부터 자신의 팀에서 사용할 수 있는 체크리스트라는 생각으로 작성했습니다.
1. AI 패러다임은 4세대로 변천했다
최근 몇 년간의 AI 활용 용어들을 나열해 보면, 레버리지(Leverage)가 「인간 → 시스템」으로 서서히 이동해 온 것을 볼 수 있습니다.
| 세대 | 기간 | 명칭 | 인간의 업무 | 가치의 원천 |
|---|---|---|---|---|
| 제1세대 | 2022 - 2024 | Prompt Engineering | 하나의 지시를 다듬음 | 지시의 질 |
| ... |
오해하기 쉬운 점은 "이전 세대가 사라지는가?"라는 문제입니다. 사라지지 않습니다. 프롬프트(Prompt)도 컨텍스트(Context)도 하네스(Harness)도 지금도 여전히 필요하며, 단지 루프(Loop)의 부품으로서 내부에 포함되었을 뿐입니다. 요리에 비유하자면, 불 조절 노하우가 필요 없어진 것이 아니라, 다만 냄비 앞에 계속 서 있을 필요는 없게 되었다는 이미지에 가깝습니다.
프롬프트를 잘 쓰는 사람이 아니라, 루프를 잘 설계하는 사람이 다음의 희소 인재가 될 것입니다. 아마도요.
2. Loop Engineering이란 무엇인가
Addy Osmani의 정의는 심플합니다.
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
즉, 자신이 에이전트(Agent)를 호출하는 쪽을 그만두고, 에이전트를 호출하는 역할을 기계가 하게 만드는 것입니다.
하나의 루프(Loop) 내용은 의외로 소박하며, 다음과 같이 쓸 수 있습니다.
당신이 목적을 정의한다
↓
AI가 완료될 때까지 반복한다
...
Harness와 Loop의 차이
이 부분은 자주 혼용되어 이야기되므로 표로 정리해 둡니다.
| 관점 | Harness Engineering | Loop Engineering |
|---|---|---|
| 대상 | 단일 에이전트 | 복수 에이전트 + 스케줄러 |
| ... |
공장에서 말하자면, Harness는 기계 한 대의 안전장치, Loop는 공장 전체를 돌리는 생산 관리 시스템입니다. Harness는 Loop의 전제 조건이므로, Loop가 Harness를 대체한다는 이야기가 아닙니다.
3. Loop를 구성하는 6가지 핵심 모듈
Addy Osmani는 처음에 Loop를 「5가지 파트」로 분해했고, 나중에 memory(기억)를 6번째로 추가했습니다. 이 부분이 서서히 효과를 발휘하는 구성이므로, 하나씩 살펴보겠습니다.
Automations (하트비트)
정기적으로, 혹은 어떤 이벤트에 의해 자동으로 기동하여 태스크를 집어 올리는 역할.
- 매일 아침의 CI 실패
- 쌓여 있는 issue
- 최근 커밋에 혼입된 버그
이러한 부분들을 인간이 일일이 체크할 필요가 없게 됩니다. 시스템이 이를 포착하여 triage(트리아지) 수신함에 자동으로 작성해 줍니다. 사소해 보이지만 효과적입니다.
Worktrees (방호벽)
여러 에이전트(Agent)를 병렬로 실행하기 위한 분리 레이어(Separation Layer).
각 에이전트가 독립된 git 브랜치를 가지며, 자신의 작업 영역에서 움직입니다. Codex와 Claude Code는 네이티브로 지원하며, 이것이 있으면 "두 에이전트가 같은 행을 동시에 수정하여 컨플릭트(Conflict)가 폭발하는" 사고가 발생하지 않습니다. 이 점이 은근히 효과적입니다.
Skills (기억 칩)
프로젝트의 사양, 빌드 절차, 과거의 의사결정을 하나의 파일에 새겨둔 것.
# Build Skill
- 의존성 설치: `pnpm install --frozen-lockfile`
- 타입 체크: `pnpm typecheck`
...
Loop가 기동할 때마다 이것을 읽어들이므로 지식이 쌓여갑니다. 매 라운드 처음부터 제로 추론(Zero-inference)을 강요받는 일은 없습니다.
Sub-agents (견제 메커니즘)
코드를 작성하는 에이전트는 거의 확실하게 자기 자신에게 높은 점수를 줍니다. 인간과 마찬가지입니다. 그래서 "결점을 찾는 전문 에이전트"를 별도로 실행합니다.
| 역할 | 업무 | 권장 모델 |
|---|---|---|
| Explorer | 코드베이스 조사·전제 조건 수집 | 고속 모델 |
| ... |
포인트는 Verifier(검증자)를 일부러 다른 모델로 설정하는 것입니다. 같은 모델이라면 자신의 맹점을 함께 놓치게 됩니다.
Connectors (팔)
MCP(Model Context Protocol)를 통해 현실 세계와 연결하는 통로. Linear, GitHub, 데이터베이스, Staging API, Slack.
Loop는 단순히 "제안"만 하지 않는다는 것이 특징입니다. PR을 만들고, 티켓을 업데이트하며, CI가 통과되면 스스로 Slack에 멘션을 보내는 단계까지 수행합니다. 이것이 있고 없고에 따라 체감되는 차이가 완전히 다릅니다.
Memory (가장 과소평가된 부품)
Addy의 글 중에서 "이것이 가장 과소평가되어 있다"라고 언급된 여섯 번째 요소. 읽었을 때 저도 "아, 그렇구나"라며 한 박자 늦게 납득했습니다.
markdown 파일, Linear 보드, 대화 외부에 존재하는 모든 상태 기록.
모델은 잊어버립니다. 리포지토리는 잊지 않습니다.
외부 상태가 없으면, 다음 날의 Loop는 게임을 처음부터 다시 시작해야 하는 상황에 처하게 됩니다. 이를 소홀히 하면 Loop는 "매일 같은 곳에서 같은 사고를 반복하는 존재"로 변질됩니다.
4. 하나의 Loop의 완전한 플로우
지금까지의 부품들을 조합하면, 하루의 루프는 다음과 같은 그림이 됩니다.
주목해야 할 점은, 인간이 처음에 설계한 이후 그 어떤 단계에도 프롬프트를 작성하지 않았다는 것입니다. 이것이 바로 "이제 프롬프트는 쓰지 않는다"의 정체입니다.
5. 검증 가능한 루프의 5단계 방법론
"그럼 구체적으로 어떻게 만드는데?"에 대한 이야기입니다. 핵심은 한 줄로 요약됩니다. 검증 가능한 루프 안에서 AI를 목표에 접근시키고, 정지 조건까지 달리게 하는 것. 그뿐입니다.
다만, 이 "검증 가능"이라는 부분이 가장 소홀히 하기 쉬운 지점이며, 여기서 대충 넘어가면 Loop는 편리한 난수 발생기에 불과하게 됩니다.
Step 1. 목표 계약 ── 우선 완료 기준을 결정한다
- 명확한 목표와 범위
- 정량화할 수 있는 수락 기준(Acceptance Criteria)
- 제약 조건 및 경계 조건
- 성공했을 때의 결과물 형식
예: 페이지 로딩 P95 < 1.5초, 에러율 < 0.1%, 테스트 전원 합격, 문서 업데이트 완료.
숫자로 떨어지지 않는 것은 Loop로 다루지 않는 것이 무난합니다.
Step 2. Agent의 실행 ── 여러 도구와 여러 인스턴스로 진행한다
- 태스크를 분해하여 계획을 수립
- 도구 호출 (코드, 검색, 커맨드)
- 필요하다면 여러 인스턴스로 병렬 실행
- 사고와 행동의 궤적을 기록
자주 사용하는 도구는 대개 고정되어 있습니다: 에디터, 터미널, 검색, 브라우저, 데이터베이스.
Step 3. 증거를 통한 피드백 ── 테스트, 로그, 스크린샷, CI
"작동합니다!"라는 말을 믿어서는 안 된다는 이야기입니다. 증거를 제시하게 만드세요.
- 자동 테스트 결과
- 실행 로그 및 에러 스택(Error Stack)
- 스크린샷 / 화면 녹화 / UI 스냅샷
- 성능 지표 및 모니터링 데이터
- CI/CD 상태 및 결과물
여기서 대충 처리하면 나중에 전부 되돌아옵니다. 제 경험상 그렇습니다.
Step 4. 정지 조건 ── 합격, 롤백, 인간에게 인계
| 정지 유형 | 조건 | 다음 액션 |
|---|---|---|
| 합격 | 모든 수락 기준을 충족함 | 딜리버리 (Delivery) |
| ... | ||
| 리스크 시그널 (Risk Signal)로 간주해야 할 것: 테스트 실패, 에러율 상승, 퍼포먼스 저하, 스코프 (Scope)가 멋대로 팽창할 때. |
Step 5. 경험의 환원 ── 규칙, skills, harness의 업데이트
- 성공 경험은 규칙(Rule)이나 템플릿(Template)으로 정립
- 실패의 교훈은 네거티브 룰 (Negative Rule)이나 체크포인트 (Checkpoint)로 정립
- skills를 업데이트 (도구 사용법, 자주 빠지는 함정)
- harness를 업데이트 (테스트 스위트 (Test Suite), 스캐폴드 (Scaffold))
- 지식 베이스 (Knowledge Base)와 동기화
이렇게 하면 다음 루프 (Loop)가 조금 더 빨라지고, 조금 더 안정화됩니다. 일 단위로는 차이가 보이지 않지만, 3개월 단위로 되돌아보면 상당히 달라져 있습니다.
6. Loop는 Cron이 아니다 ── 4가지 실행 방식 비교
"정기 실행이라면 지금까지 cron이나 GitHub Actions로 해왔어"라고 생각하는 분들께. 차이점은 크게 세 가지로 요약됩니다. 컨텍스트 (Context), 도구 (Tool), 피드백 (Feedback).
| 특징 | 수동 프롬프트 (Manual Prompt) | Loop | 시스템 Cron | GitHub Actions |
|---|---|---|---|---|
| 컨텍스트 | 매번 인간이 보충 / 이력 소실 | 세션 기억 유지 / 자동 계승 | 콜드 스타트 (Cold Start) / 기억 없음 | 콜드 스타트 (로그는 추적 가능) |
| ... |
무엇을 선택할 것인가?
선택하기 전에 스스로에게 질문해 보는 것이 좋습니다. 컨텍스트를 유지할 필요가 있는가? 태스크 (Task)가 도중에 변화하는가? 완료를 자동으로 판단해야 하는가? 아니면 고정된 스크립트로 충분한가?
단기 사이클이라면 Loop, 장기적으로 신뢰성이 필요하다면 Actions, 고정된 기계적 태스크라면 Cron. 대략 이 정도 감각이면 틀리지 않습니다.
7. 팀 도입: 6단계와 2개의 품질 게이트 (Quality Gate)
"개인으로 시도하는 건 알겠어. 팀에는 어떻게 도입하지?"라는 이야기입니다. 핵심은 "갑자기 전부를 Loop화 하지 마라"에 있습니다. 아마 대부분의 팀도 처음에는 작게 시작하는 것이 좋습니다.
태스크 선정
CI 복구, 회귀 검증 (Regression Verification), 로그 순회 점검 등이 정석입니다. 작고 명확하며, 효과를 정량화할 수 있는 것.
목표 계약 작성
입력 (AI에게 무엇을 줄 것인가), 출력 (무엇을 원하는가), 합격 기준 (숫자로), 금지 영역 (해서는 안 되는 것).
도구 연결
repo, 테스트 프레임워크 (Test Framework), lint, MCP, 이슈 트래커 (Issue Tracker).
센서 추가
테스트 결과, 스크린샷, 녹화, 퍼포먼스 지표, 에러 스택 (Error Stack), 커버리지 (Coverage). 여기까지 왔다면 품질 게이트 #1입니다. 증거가 갖춰지지 않는 한 다음으로 넘어가지 않는다는 라인을 긋습니다.
정지 조건 결정
합격, 타임아웃 (Timeout), 비용 상한, 리스크 트리거 (Risk Trigger), 인간 인계. 여기서 품질 게이트 #2입니다. 조건이 모호하면 사이클이 끝나지 않거나, 끝났는지 알 수 없는 것들이 양산됩니다.
경험 축적
규칙, 템플릿, skill, eval 케이스, 개선점. 다음 사이클이 조금 더 빠르고, 조금 더 정확해집니다.
해야 할 일
하지 말아야 할 일
우선순위는 단순합니다. 검증 가능 > 자동화 가능 > 확장 가능. 순서를 반대로 하면 나중에 전부 되돌아옵니다.
8. Loop 도입 체크리스트: 4가지 질문으로 Go/No-Go 판정
"이 태스크, Loop화 해도 괜찮을까?"라고 망설여진다면, 이 4가지 질문을 통과하면 대략 판정할 수 있습니다.
Loop에 적합한 태스크
- CI의 적신호 복구. 빌드와 테스트 실패를 자동으로 특정하여 수정
- 테스트 보완. 단위 테스트 (Unit Test)를 생성·보완하여 통과
- 로그 순회 점검. 이상 탐지, 분류, 복구 제안
- 문서 동기화. API, README, 인터페이스의 자동 업데이트
- 의존성 업그레이드. 버전 확인, PR, 회귀 (Regression)
주의해야 할 태스크
- 광범위한 리팩토링 (Refactoring). 롤백 (Rollback) 비용이 무거움
- 운영 환경의 권한 조작. 사고의 영향이 큼
- 보안에 민감한 변경. 권한 정책, 키 (Key), 액세스 제어
- 순수한 미적 판단. 객관적 기준이 없고 검증이 불가능함
망설여진다면, 우선 작게 시도하고 증거가 나온 뒤에 확장하십시오. 이것이 전부입니다.
Loop 시작 전에 결정해 둘 것
| 설정 항목 | 목적 |
|---|---|
| Owner (책임자) | 추적 가능성 (Traceability) 보장 |
| ... |
Loop Engineering의 중점은 '정지 조건 (Stopping Condition)'이지, '순환 횟수'가 아닙니다. 많이 돌린다고 해서 훌륭한 것이 아닙니다.
9. Loop의 3가지 함정 ── 매끄럽게 돌아갈수록 무섭다
여기서부터가 개인적으로 가장 중요하다고 생각하는 부분이며, Addy Osmani 도 기사 마지막에서 굳이 찬물을 끼얹고 있습니다. Loop에는 '매끄럽게 돌아가는 것 자체가 위험하다'는 역설이 존재합니다.
함정 1: 검증의 사각지대
Loop는 무인으로 작동하기 때문에, 무인인 상태 그대로 실수를 범합니다.
'done (완료)'은 자기 신고일 뿐, 증명이 아닙니다.
이를 타파하는 것이 Step 3의 증거 기반 (Evidence-driven) 방식이며, 증거가 나오지 않는 Loop는 실질적으로 자신만만한 난수 발생기에 불과합니다. 편리하지만, 신뢰해서는 안 됩니다.
함정 2: Comprehension Debt (이해의 부채)
Loop가 매끄러울수록, 스스로 생성시킨 코드에 대해 소원해지기 쉽습니다.
딜리버리 (Delivery)를 가속하는 한편, 괴리도 가속시킵니다.
이것은 정말로, 자신이 직접 쓰지 않은 코드가 나날이 늘어나다가, 어느 날 디버거 (Debugger)를 열었을 때 "이거 누가 썼더라…… 나였나?" 하는 순간이 찾아옵니다. 기술적 부채 (Technical Debt)와는 조금 다른, 새로운 종류의 부채라고 생각합니다.
함정 3: Cognitive Surrender (인지적 굴복)
가장 무서운 것입니다.
Loop를 실행시키고, 자신의 판단 기준을 갖는 것을 그만두며, 그것이 가져오는 모든 것을 그대로 받아들여 버리는 것.
"AI가 그렇다고 하니까..."가 입버릇이 되기 시작했다면 위험합니다. 이것은 정말 조금씩 침식해 들어오기 때문에, 반년에 한 번 정도는 자신의 리뷰 기준을 의식적으로 적어두는 것이 좋습니다.
새벽 3시에 에이전트 (Agent)가 코드를 주무르고 있는 옆에서, 정작 자신은 아무것도 이해하지 못하게 된 미래. 아마 완전히 피할 수는 없겠지만, 적어도 자각은 하고 있어야 합니다.
10. 마치며: 레버리지 포인트 (Leverage Point)는 이동했다
Boris Cherny가 말하는 것은 일이 편해졌다는 이야기가 아니라고 생각합니다.
그가 말하는 것은 레버리지 포인트가 이동했다는 이야기입니다.
| Before | After |
|---|---|
| 좋은 프롬프트를 작성하는 사람 | 좋은 루프를 설계하는 사람 |
| ... |
같은 Loop를 두 명의 엔지니어가 구성하더라도, 나오는 결과는 완전히 다를 수 있습니다. 차이를 만드는 것은 그 일을 정말로 이해하고 있는지, 아니면 Loop를 이해의 대체재로 삼고 있는지의 차이라고 생각합니다.
Loop Engineering은 Prompt Engineering보다 어렵습니다. 하나의 답을 내는 것과, 답을 계속해서 내놓는 기계를 만드는 것은 정말로 별개의 능력이기 때문입니다. 하지만 어려운 만큼 효과적입니다. 아마 앞으로 1~2년 안에, 이것을 할 수 있는 사람과 할 수 없는 사람의 차이는 꽤 명확하게 드러날 것입니다.
제 개인적인 감상을 마지막으로 덧붙이자면, Loop는 확실히 편리하며 자는 동안 일이 진행되는 것은 솔직히 기분이 좋습니다. 한편으로는 조금 서늘한 순간도 있습니다. 그 서늘함을 잊지 않는 범위 내에서 함께해 나가는 것이, 당면한 정답인 것 같습니다.
참고 문헌 · 소스
- Addy Osmani 『Loop Engineering』 — addyosmani.com, 2026.06.07
- Boris Cherny — Acquired Podcast 출연, 2026
- Peter Steinberger — X @steipete
- Anthropic Claude Code 공식 문서
이 기사의 바탕이 된 3가지 1차 정보 메모
- 메모 1: Boris Cherny의 발언과 패러다임 변천 (Prompt → Context → Harness → Loop)
- 메모 2: Addy Osmani의 블로그 요약 (Automations / Worktrees / Skills / Sub-agents / Connectors / Memory)
- 메모 3: 구현 방법론 (목표 계약 → Agent 실행 → 증거 피드백 → 정지 조건 → 경험 환원) 및 Loop vs Cron 비교, 팀 도입 체크리스트
속보 부분과 내일 팀에서 바로 사용할 수 있는 체크리스트 부분을 모두 한 기사에 담기 위해 이 세 가지를 섞었습니다.
Discussion
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기