"더 이상 코딩 에이전트에게 프롬프트를 입력해서는 안 됩니다. 대신 에이전트를 대신해 프롬프트를 입력할 루프(Loops)를 설계해야 합니다." — Peter Steinberger

지난 11월, Claude Code의 제작자인 Boris Cherny는 자신의 IDE를 삭제했습니다. 사용을 중단한 것입니다. 최근 인터뷰에서 그는 명확하게 말합니다. "저는 더 이상 Claude에게 프롬프트를 입력하지 않습니다. 대신 스스로 무엇을 할지 결정하고 프롬프트를 입력하는 루프(loops)를 실행합니다. 제 일은 루프를 작성하는 것입니다." 그리고 그는 덧붙였습니다: 이것은 시장이 남은 한 해 동안 겪게 될 전환기라고 말입니다.

이 변화는 말하기는 간단하지만 그 결과는 엄청납니다. 이전에는 채팅 방식이었습니다: 프롬프트 입력 → 답변 → 수정 → 다시 프롬프트 입력. 인간이 모든 반복 과정의 병목(bottleneck)이었습니다. 이제 당신은 시스템을 한 번 설계하면, 시스템이 스스로 작업을 찾아내고, 에이전트에게 할당하며, 결과를 확인하고, 완료된 내용을 기록하며, 다음에 무엇을 할지 결정합니다. 당신 대신 시스템이 에이전트를 자극합니다.

추상화의 사다리 (The ladder of abstraction)

Daniel Demmel은 이를 사다리로 설명했으며, 프롬프팅은 가장 낮은 단계에 위치합니다:

1. 프롬프트 엔지니어링 (Prompt engineering) — 요청을 어떻게 표현할 것인가.
2. 컨텍스트 엔지니어링 (Context engineering) — 컨텍스트(context)에 무엇을 넣을 것인가.
3. 피드백 루프 엔지니어링 (Feedback-loop engineering) — 에이전트가 자신의 작업 결과(테스트, 로그, 실제 API 등)를 직접 확인하게 하는 것.
4. 하네스 엔지니어링 (Harness engineering) — 전체 장치를 실행하는 것: 무엇을 실행하고, 무엇을 검증하며, 언제 인간을 호출할 것인가.

트렌드는 이 사다리를 타고 올라가는 것입니다. 부품을 직접 깎는 것을 멈추고 조립 라인을 설계하기 시작하는 것입니다. 왜 지금 이 모든 것이 맞아떨어지고 있을까요? 모델이 매 반복마다 확인하지 않아도 신뢰할 수 있을 만큼 안정화되었고, 병렬 처리(parallelism) 비용이 저렴해졌으며, 인프라가 도구(tools)로 직결되었기 때문입니다.

루프의 해부 (Anatomy of a loop)

루프가 인간 없이 완결되는 이유는 단 한 가지입니다: 코드에 저렴하고 객관적인 오라클 (cheap, objective oracle) — 컴파일, 테스트, 린트(lint), 실행 — 이 존재하기 때문입니다. 에이전트는 자신이 어디서 틀렸는지 스스로 확인합니다. 이것이 폐쇄 루프(closed-loop)를 구축하는 방법입니다: 에이전트가 컴파일하고, 실행하고, 스크린샷을 찍고, 실제 키를 입력하며 스스로를 검증하는 것입니다.

루프 자체는 하나의 공식으로 요약됩니다: 작업 발견(find work) → 제한된 행동(bounded action) → 검증(verification) → 보고(report) → 에스컬레이션(escalation). 여러분은 각 루프에 대해 다음과 같은 한 페이지 분량의 계약(contract)으로 이를 공식화합니다:

trigger:  발생 조건
scope:    영향 범위 / 제외 범위
budget:   최대 시도 횟수 / 시간 / 파일
...

6가지 오케스트레이션 프리미티브 (Six orchestration primitives)

Anthropic은 에이전트가 특정 작업을 수행하기 위해 마치 블록을 조립하듯 하네스(harness)로 구성하는 6가지 패턴을 설명했습니다:

• 분류 후 실행 (Classify-and-act) — 유형에 따른 라우팅(routing). 입력되는 모든 것(이슈, 이메일, 티켓, 에러 등)을 분류하고, 각 유형을 고유한 핸들러(handler)로 보냅니다. 이는 루프의 전면에 있는 "디스패처(dispatcher)" 역할을 합니다. 모든 것을 동일하게 취급하지 말고, 실제로 무엇이 도착했는지 먼저 파악하십시오.
• 확산 후 합성 (Fan-out-and-synthesize) — 작업을 독립적인 조각으로 나누고, 각 조각을 별도의 깨끗한(clean) 컨텍스트에서 병렬로 해결한 다음, 결과를 하나로 다시 모읍니다. 이는 에이전트가 수십 명의 서브 에이전트(sub-agents)를 사용하여 대규모 코드베이스를 동시에 분석하는 방식이며, 이때 합성기(synthesizer)가 전체 그림을 조립합니다. 조각들이 서로 의존하지 않는 병렬성(Parallelism)을 활용합니다.
• 적대적 검증 (Adversarial-verify) — 별도의 회의론적 에이전트(skeptic agent)가 루브릭(rubric)에 따라 결과를 확인하며, 이 에이전트의 임무는 확인하는 것이 아니라 "반증(disprove)"하는 것입니다. 이를 통해 자기 선호 편향(self-preferential bias)을 제거합니다. 즉, 작성자가 자신의 작업에 직접 점수를 매겨서는 안 됩니다. 핵심적인 신뢰 패턴은 검증하는 사람이 수행한 사람이 아니어야 한다는 것입니다.
• 생성 후 필터링 (Generate-and-filter) — 많은 후보를 생성하고, 품질에 따라 필터링하며, 중복된 항목은 버립니다. 첫 시도에 단 하나의 정답을 추측하는 것보다 10개의 옵션을 생성하여 선택하는 것이 더 저렴할 때 유용합니다.
• 토너먼트 (Tournament) — 여러 에이전트가 서로 다른 방식으로 동일한 작업을 해결하고, 심판(judges)이 승자가 한 명 남을 때까지 이들을 쌍별(pairwise)로 비교합니다. 이는 솔루션 공간(solution space)이 넓고 어떤 경로가 최선인지 사전에 명확하지 않은 경우에 사용됩니다.
• 완료될 때까지 루프 (Loop-until-done) — 중단 조건(stop condition)이 충족될 때까지 에이전트를 생성합니다. 예: 더 이상 새로운 것이 발견되지 않음, 에러 0개, 목표 달성 등.

이것이 철저한 전수 조사(exhaustive sweep)를 수행하는 방법입니다. 예를 들어, 두 번 연속으로 결과가 비어 있을 때까지 버그를 추적하는 방식입니다.

여기서 핵심적인 점을 주목하세요: 거의 모든 프리미티브(primitive)는 검증 (verification) 단계에 의존합니다. 적대적 검증 (adversarial-verify) 체크, 필터 선택 (filter selects),

코드 에이전트(code agents)가 루프(loops) 내에서 작동한다면, 병목 현상의 위치가 이동합니다. 즉, 코드를 작성하는 것이 문제가 아니라, 루프가 스스로를 검증할 때 기준이 되는 계약(contract)의 품질이 병목이 됩니다. 루프의 성능은 당신이 정의한 "완료(done)\

주저하지 말고 이 논리를 끝까지 따라가 봅시다. 만약 요청자(requester)가 검증 가능한 (verifiable) 계약(contract)을 전달하고, 루프(loop)가 이를 구현 및 검증한다면 — 왜 시니어 엔지니어를 계속 고용해야 할까요?

이 질문에는 숨겨진 오류가 있습니다. 이 질문은 계약을 충족하는 아키텍처 자체가 모호하지 않다고 가정하고 있습니다. 단순한 사례라면 — 맞습니다. 하지만 복잡한 사례라면 — 아닙니다. 계약은 **무엇(WHAT)**과 수락 기준을 명시합니다. 하지만 그것이 어떻게(HOW) 수행되는지는 명시하지 않습니다. 즉, 데이터 모델(data model), 트랜잭션 경계(transaction boundaries), 락(lock)의 위치, 라우팅(routing), 네트워크 분할(network partition) 시의 동작, 마이그레이션 전략(migration strategy) 등은 포함되지 않습니다.

여기서 결론 전체를 관통하는 대칭성이 도출됩니다. 요청자(requester)는 의도 게이트(intent gate)를 소유합니다 — "이것이 올바른 기능인가"에 대한 오라클(oracle)은 존재하지 않습니다. 시니어(senior)는 아키텍처 게이트(architecture gate)를 소유합니다 — "이것이 올바른 설계인가, 부하 상황이나 레이스 컨디션(race condition), 공격 상황에서도 올바르게 작동하는가"에 대한 오라클 역시 존재하지 않습니다. 루프(loop)는 검증 가능한 중간 영역을 채웁니다. 어느 한쪽 게이트라도 제거하면 규모가 커질수록 '확신에 찬 오답(confident-wrong)'을 얻게 됩니다. 즉, 잘못된 기능을 만들거나, 얕은 테스트는 통과했지만 순진하고 보안에 취약한 아키텍처 위에 아름답게 묘사된 기능을 만들게 됩니다.

솔직하고 불편한 부분은 다음과 같습니다: 인원수(headcount)가 줄어듭니다. "명확한 사양(specs)을 구현하는" 엔지니어는 위험 지대에 놓여 있습니다. 반면 "아키텍트이자 루프 소유자(loop owner)"인 엔지니어는 그 어느 때보다 더 필요해집니다. 비즈니스 관점에서 이것이 바로 핵심입니다. 동일한 인원이 몇 배 더 많은 결과물을 만들어냅니다. 레버리지(leverage)입니다.

한 줄 요약: 루프는 모든 사람을 오라클이 없는 곳으로 — 즉, 더 높은 단계로 — 밀어 올리며, 오라클이 커버할 수 있는 중간 영역을 지워버립니다. 루프는 역할을 제거하는 것이 아니라, 역할 중 오라클로 커버 가능한 부분을 제거하는 것입니다. 요청자는 의도(intent)를 담당합니다. 시니어는 아키텍처를 담당합니다. 그리고 그 사이에서 루프가 작동하며, 양 끝단에서 계약(contract)을 검증할 수 있는 범위만큼 정확하게 실행됩니다.

Boris Cherny, Peter Steinberger, Addy Osmani, 그리고 Anthropic Engineering의 내용을 바탕으로 작성되었습니다.