IDE를 언인스톨한 개발자가 있다.

Boris Cherny, Anthropic의 Claude Code 책임자. 2025년 11월, 한 달 동안 사용하지 않았다는 사실을 깨닫고 삭제했다.

"I don't prompt Claude anymore. I have loops running. They're the ones prompting Claude and figuring out what to do. My job is to write loops."

(이제 Claude에게 프롬프트를 입력하지 않는다. 루프(Loop)가 돌아가고 있으며, Claude에게 지시를 내리는 것도, 다음에 무엇을 할지 판단하는 것도 루프가 한다. 나의 일은 루프를 작성하는 것이다.)

IDE를 삭제한 개발자가 무슨 이야기를 하고 있는 것일까. Context Engineering의 다음 이야기다.

프롬프트를 쓰지 마라, 루프를 작성하라

2026년 6월, "이제 에이전트(Agent)에게 프롬프트를 치지 마라. 에이전트에게 프롬프트를 주는 루프를 설계하라"라는 포스트가 X에서 화제가 되었다.

같은 주, Google의 Addy Osmani가 블로그를 통해 이를 체계화했다. Loop Engineering이라는 이름이 붙었다.

Prompt Engineering이 "AI에게 던지는 질문을 연마하는 기술"이라면, Loop Engineering은 "AI에게 질문하는 프로세스 그 자체를 설계하는 기술"이다.

프롬프트에서 루프까지

단번에 여기까지 온 것은 아니다. 단계를 밟아왔다.

Prompt Engineering— "어떻게 물어볼 것인가"에 집중했다. 1회성 상호작용의 정밀도를 높이는 기술. 질문 작성법을 아무리 연마해도, AI가 보고 있는 정보 자체가 부족하면 답변은 좋아지지 않는다.
Context Engineering— 그 지점을 공략했다. 질문이 아니라, AI가 추론할 때 보고 있는 정보 환경을 통째로 구축한다. 2025년에 확산된 개념으로, Anthropic이 문서로 정리해 두었다. 하지만 이것도 아직 "1회의 상호작용"이라는 틀 안에 머물러 있다. 환경을 정비해도, 모델 외부에 있는 도구나 검증 프로세스까지는 커버하지 못한다.
Harness Engineering— "Agent = Model + Harness"라는 관점이 등장했다. 모델의 외측(사용 가능한 도구, 제약, 피드백, 품질 체크)을 통칭하여 "하네스(Harness)"라고 부른다. 이 부분을 얼마나 잘 구축하느냐에 따라 결과가 달라진다. 다만, 하네스가 우수하더라도 인간이 매번 "다음은 이걸 해"라고 지시를 내리는 한 스케일(Scale)할 수 없다.
Loop Engineering— 이 벽을 허문다. 인간이 지시를 내리는 부분 그 자체를 자동화하여, 에이전트가 스스로 다음에 할 일을 결정하고 계속 움직이는 메커니즘을 만든다. ②의 판단 단계를 전부 바꾸는 것이다. 이전 결과에 따라 할 일이 달라지며, "이제 충분하다"라고 판단하면 스스로 멈춘다.

적합한 태스크, 적합하지 않은 태스크

모든 것을 루프로 만들면 되는 것은 아니다. 판단이 정형화될 수 있는 태스크는 루프에 태우기 쉽지만, 정답이 없는 판단은 인간이 할 수밖에 없다.

루프가 효과적인 태스크	인간이 해야 할 태스크
CI 실패 조사 및 수정	아키텍처 판단
...

왼쪽의 공통점은 "할 일이 정해져 있고, 결과를 검증할 수 있다"는 것이다. 오른쪽은 "무엇이 정답인지를 결정하는 행위" 그 자체다.

왼쪽에 해당되는 태스크를 찾았다면, 루프를 돌리기 전에 이것만은 결정해 두어야 한다.

• 몇 회차에서 멈출 것인가 (회수 상한 또는 시간 상한)
• 완료를 어떻게 판정할 것인가 (테스트 전체 통과, 태스크 리스트가 비어 있음, 커버리지 80% 초과 등)
• stuck(교착 상태)되면 어떻게 할 것인가 (중단, 다른 접근 방식 시도, 인간에게 전달)

이것만 결정되어 있다면 루프를 안전하게 돌릴 수 있다. 결정되지 않은 채로 돌리면, 멈출 타이밍을 몰라 결국 계속 지켜보고 있게 된다.

루프를 구성하기

루프를 구성하는 부품을 Claude Code로 구축하는 순서대로 살펴보자. 처음 3가지(Knowledge, State, Automations)가 갖춰지면 루프가 돌아가기 시작한다.

Knowledge (프로젝트 지식)— 루프의 판단 축. 몇 번을 돌려도 품질이 흔들리지 않는다. 프로젝트 루트에

CLAUDE.md

프로젝트 루트에

CLAUDE.md

를 둔다. # CLAUDE.md ## 프로젝트 개요 Express + React 태스크 관리 API. 포트 3001. ## 코딩 규약 - 테스트는 Vitest. 커버리지 80% 이상 - API 응답은 { data, error } 형식 ## 작업 절차 1. 먼저 STATE.md를 읽고 이전 상태를 파악한다 2. 태스크를 실행한다 3. 테스트가 통과하는지 확인한다 4. STATE.md를 업데이트한 후 커밋한다

절차의 1번과 4번이 루프의 핵심이다. 이것이 없으면 세션이 매번 리셋되어 반복이 이루어지지 않는다.

'규칙'이 아니라 '절차'로서 번호를 붙여 작성하는 것이 포인트다. 에이전트는 절차를 위에서부터 순서대로 수행하므로, 처음에 읽고 마지막에 쓰는 흐름이 자연스럽게 순환된다.

State/Memory (상태 관리)— 세션 간의 기억. 모델은 문맥을 잊어버리지만, 파일은 잊지 않는다. 마찬가지로 프로젝트 루트에 상태 파일을 둔다. 파일명은 자유다.

# STATE.md ## 진행 중 - 인증 API 리팩토링 (fix/auth 브랜치) - JWT 유효 기간으로 인해 테스트 실패 중 - refresh token 구현 미착수 ## 다음에 할 일 - 사용자 등록 플로우 테스트 추가 - 에러 핸들링 통일 ## 조사 메모 - JWT 유효 기간: 기본 1h이지만 세션 유지에는 짧음 → 15min + refresh token 이 정석

처음에는 직접 작성한다. 루프가 돌아가기 시작하면 에이전트가 매 회차마다 내용을 다시 쓴다.

상태 파일을 단순한 '메모장'으로 끝내지 않는 것이 좋다. 실패를 기록하고, 원인을 조사하여, 일반적인 규칙으로 승화시킨다. 이 사이클이 돌아가면 세션을 넘나들 때마다 점점 똑똑해진다.

지금까지 설명한 두 가지만으로도

• Sub-agents (검증의 분리) — 코드를 작성하는 에이전트와 검증하는 에이전트를 분리한다. 자신이 작성한 코드에 대한 채점은 관대해지기 마련이다. AI도 마찬가지다. .claude/agents/에 에이전트 정의를 둔다.

# .claude/agents/reviewer.md 코드 리뷰 전용. 구현은 변경하지 않음. 리뷰 관점: - 보안 리스크 - 성능 문제 - 테스트 커버리지 부족

Routine 지시문에 "리뷰에는 reviewer 에이전트를 사용하라"고 적거나, CLAUDE.md에 "PR 리뷰 시에는 .claude/agents/reviewer.md를 사용한다"라고 적어둔다.

루프(Loop) 안에서 명시적으로 참조함으로써, 작성하는 측과 검증하는 측이 서로 다른 컨텍스트 (Context)에서 동작하게 한다.

셀프 리뷰가 느슨해지는 것은 인간의 태만이 아니라 모델의 구조적인 약점이다. 독립된 컨텍스트에서 별도의 에이전트가 확인하는 편이 정밀도가 높아진다. 따라서 시스템적으로 분리한다.

• Connectors (외부 연동) — MCP (Model Context Protocol)를 통해 Issue 트래커나 Slack과 연결한다. 루프 안에서 완결되지 않으면 결국 인간이 중개하게 된다. 연결은 .mcp.json에서 설정한다.

{ "mcpServers": { "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "<your-token>" } } } }

에이전트가 PR을 열고, issue를 읽고, 커밋 히스토리를 확인한다. 인간이 브라우저를 통해 중계할 필요가 없다.

• Stop conditions (중단 조건) — 루프는 돌리는 것보다 멈추는 것이 더 어렵다. 아까 "돌리기 전에 결정해 둔다"라고 쓴 중단 판단을 코드로 구현하면 다음과 같다.

• 완료: 태스크 리스트가 비었을 때 → 자연스럽게 중단

• 회차 상한: 15회에서 강제 중단. 안전장치

• stuck 감지: 3회 연속으로 의미 있는 변경이 없을 때 → 같은 곳에서 막혀 있다고 판단하여 중단

• 인간에게 전달: 아키텍처 변경이나 보안 정책 등 판단이 필요한 상황에서 STOP 파일을 두고 인계

실제로 루프 스크립트를 작성하면, 다음과 같은 상수들을 처음에 결정하게 된다.

const MAX_ITERATIONS = 15; // 회차 상한 const NO_CHANGE_LIMIT = 3; // 변경 없음이 3회 지속되면 stuck const FAIL_LIMIT = 3; // 실패가 3회 지속되면 브레이커 const TOTAL_LIMIT_MS = 1800000; // 총량 상한 30분

회차마다 "변경이 있었는가", "테스트를 통과했는가"를 체크하여, 어느 하나라도 걸리면 멈춘다. 이 수치에 정답은 없으며, 프로젝트의 규모나 태스크의 입도 (Granularity)에 따라 달라진다. 처음에는 작게 (3회 정도) 시도해 보며 감을 잡은 뒤에 높이는 것이 좋다.

무인 운용의 리스크

다만, 루프가 강력해질수록 리스크는 경감되는 것이 아니라 증폭된다.

검증 책임은 사라지지 않는다

루프가 무인으로 동작한다면, 무인으로 실수한다. PR을 자동으로 열 수 있다면, 잘못된 PR도 자동으로 연다.

루프의 출력이 늘어날수록 리뷰 부하도 늘어난다. 생산 측이 편해진 만큼, 검증 측의 부하는 오히려 높아지고 있다. 아침에 일어났더니 PR이 30건 쌓여 있고, 전부 볼 기력이 없다. 하지만 보지 않으면 머지 (Merge)할 수 없다.

이해의 부패

코드 생산 속도가 올라가면 이해가 따라가지 못하게 된다. 자신이 파악하지 못한 코드가 늘어날수록, 문제가 발생했을 때 원인을 찾을 수 없다. 기술적 부채와는 별개의 부채 — 이해의 부채 (Comprehension Debt). 이것이 쌓이고 있다는 것을 깨달았을 때는 이미 늦은 경우가 많다.

반년 뒤에 운영 환경에서 장애가 발생했는데, 루프가 작성한 코드에 버그가 있다. 읽어본 적 없는 코드라 원인 파악에 며칠이 걸린다.

인지적 굴복

생각하기를 그만두고 결과에 의존하고 싶은 유혹. 루프가 너무 쾌적하면 "뭐 통과했으니까 됐지"라며 사고가 멈춘다. 자동화가 능력을 확장하는 것이 아니라, 생각하는 것을 회피하는 데 사용되기 시작한다.

테스트가 전부 통과했으니 머지한다. 하지만 그 테스트 자체도 루프가 작성하고 있다. 테스트가 허술하다는 사실을 알아차릴 수 없다. 이것이 가장 무섭다.

"루프를 구축하라. 하지만 단순히 실행 버튼을 누르는 사람이 아니라, 엔지니어로 남겠다는 의지를 가진 사람처럼 구축하라."

(ループを構築しろ。ただしボタンを押すだけの人間じゃなく、エンジニアとして留まるつもりで)

— Addy Osmani

편리해질수록, 생각하지 않게 된다. 나 자신도 그렇게 되어가고 있다.

루프의 현재 위치

서두의 Boris Cherny는 부품을 전부 연결하여 매일 루프를 돌리고 있다. 검증 수단을 제공하면 자신의 실수를 바로잡을 수 있다고 인터뷰에서 밝혔으며, Claude Code 팀 코드의 90% 이상이 Claude Code를 사용하여 작성되었다고 한다.

루프가 작성한 코드로, 루프 자신이 움직인다. 약간 SF 같다.

나의 경우, 아이디어 탐색 → 경쟁 조사 → 수익 설계 → 사양서라는 제품 개발 파이프라인을 Claude Code로 구축해 두었다. 각 단계마다 절차서가 있으며, 각각은 단독으로 작동한다. "경쟁 조사해줘"라고 하면 조사해주고, "사양서로 정리해줘"라고 하면 정리해준다.

다만, 지금은 하나가 끝날 때마다 내가 직접 다음 단계를 실행하고 있다. 아이디어 탐색이 끝나면 "그럼 경쟁 조사해줘"라고 직접 타이핑한다. 끝나면 "수익 설계로 들어가"라고 또 타이핑한다. 메커니즘은 갖춰져 있는데, 연결 고리가 나 자신이다.

이 부분을 Routine(루틴)으로 연결하고 싶다. 아이디어 탐색이 끝나면 API 트리거로 경쟁 조사를 시작하고, 그대로 사양서까지 흘려보낸다. 내가 판단하는 것은 "이 아이디어, 다음으로 진행해도 돼?"뿐이다. 아직 구축하지는 못했지만, 부품은 손에 쥐고 있다.

어디까지 자동화하고, 어디서부터 직접 할 것인가. 그 선을 긋는 것이 다음 과제가 되었다.

프롬프트를 입력하기 전에, 루프를 그린다. 그곳이 시작점이다.

Discussion