프롬프트 엔지니어링은 죽었다. 루프 엔지니어링(Loop Engineering)의 시대가 왔다.

환상을 깨뜨린 한 마디

며칠 전, Anthropic의 Claude Code 개발을 이끄는 엔지니어 Boris Cherny가 남긴 짧은 한 마디가 소프트웨어 커뮤니티에 조용히 충격파를 던졌습니다.

공개 패널 토론에서 Cherny는 세계에서 가장 정교한 코딩 AI를 만드는 사람들이 실제로 자신들의 모델과 어떻게 협업하는지에 대한 베일을 벗겨냈습니다. 그가 한 말은 단순히 현상 유지를 부정하는 것을 넘어, 새롭게 떠오르던 하나의 학문 분야가 구식이 되었음을 선언했습니다.

“나는 더 이상 Claude에게 프롬프트를 입력하지 않습니다. Claude에게 프롬프트를 입력하고 무엇을 할지 결정하는 루프(loops)를 실행합니다. 나의 일은 루프를 작성하는 것입니다.”
Boris Cherny · Anthropic, Claude Code

이 말을 곱씹어 보십시오.

세계 최고의 개발자 모델을 직접 다루는 사람이 당신에게 핸들에서 손을 뗐다고 말하고 있습니다. 그는 채팅창에 앉아 완벽한 지시문 문단을 작성하지 않습니다. 그는 AI가 스스로 대화하고, 자신의 실수를 판단하며, 폐쇄된 자율 회로 안에서 이를 수정하도록 강제하는 코드를 작성합니다. 그는 모델을 조종하는 기계를 구축하고, 그 후 모델이 스스로 운전하게 둡니다.

만약 당신이 여전히 LLM으로부터 적절한 코드 블록을 끌어내기 위해 프롬프트를 미세 조정(fine-tuning)하는 데 하루를 보내고 있다면, 그의 메시지는 잔혹할 정도로 명확합니다. 당신은 이미 사라져 버린 세상을 최적화하고 있는 것입니다.

패러다임의 전환: 마이크로매니지먼트에서 시스템 아키텍처로

이것이 왜 지각 변동인지 이해하려면, 불과 몇 년 만에 생성형 AI와의 관계가 어떻게 진화했는지 살펴보십시오.

1단계 — 선형적 프롬프트 (인간이라는 병목 현상)
최근까지 업계 전체가 프롬프트 엔지니어링(prompt engineering)에 집착했습니다. 우리는 LLM을 똑똑하지만 주의력이 쉽게 산만해지는 주니어 개발자처럼 취급했습니다. 워크플로우는 선형적이고, 취약하며, 전적으로 수동적이었습니다.

이 패러다임에서 인간은 병목 현상 (bottleneck) 입니다. 프롬프트를 작성하고, 출력을 읽고, 구문 오류 (syntax error)를 찾아내어 다시 채팅창에 붙여넣고, 모델이 다섯 단계 뒤에 문맥 (context)을 잊어버리지 않기를 기도합니다. 생산적인 것처럼 느껴지지만, 이는 소모적이고 확장 불가능한 마이크로매니지먼트 (micromanagement) 일 뿐이며, 당신이 잠든 동안에는 절대 실행될 수 없습니다.

2단계 — 루프 엔지니어링 (Loop engineering, 자율 회로)
Cherny가 설명하는 것은 루프 엔지니어링 (loop engineering)입니다. 즉, 인간이 실행 루프 (execution loop)에서 완전히 벗어나는 에이전트 워크플로우 (agentic workflows)입니다. 당신은 운전대를 놓습니다. 대신 트랙을 건설하고, 기계가 그 트랙을 돌게 만듭니다.

문제를 해결하기 위해 프롬프트를 작성하는 대신, AI를 실행과 검증의 자동화된 사이클 안에 내장하는 프로그래밍 방식의 루프 (programmatic loop)를 작성합니다:

목표 (The goal). 인간이 하나의 상위 수준 목표를 설정합니다 — "이 API 엔드포인트를 구축하고 테스트 커버리지 (test coverage) 98%를 달성하라."
행동 (The action). AI가 코드의 초안을 생성합니다.
검증 (The verification). 컴파일러 (compilers), 린터 (linters), 단위 테스트 (unit tests), CI와 같은 자동화된 환경이 코드를 실행하고 모든 오류를 잡아냅니다.
자기 수정 (The self-correction). 실패 시, 시스템은 스택 트레이스 (stack trace)를 캡처하여 이를 새로운 지침으로서 AI에게 다시 전달하고, 다시 시도하도록 명령합니다.

당신이 목표를 설정함
│
▼
AI가 코드를 작성함 ─▶ CI가 모든 체크를 실행함 ─▶ 통과(green)? ─▶ ✦ 배포 완료
▲ │
│ ▼ (실패/red)
└── AI가 로그를 읽고 스스로에게 다시 프롬프트를 입력함

이 루프는 기계의 속도로 작동하며, 검증 기준이 충족될 때까지 수십 번의 반복을 거치며 스스로 수정하고 스스로 치유(self-healing)합니다. 당신은 단 한 번의 후속 작업도 타이핑하지 않았습니다. 당신은 프롬프트를 작성한 것이 아니라, 트랙을 건설했고 모델이 스스로 모든 바퀴를 돌린 것입니다.

진정한 기술은 코드를 작성하는 것이 아닙니다. 판사 (judge)를 작성하는 것입니다.
여기 거의 모든 사람이 놓치는 부분, 그리고 이것이 게임의 전부인 지점이 있습니다. 루프의 어려운 점은 코드를 생성하는 것이 아닙니다. 모델은 이미 그 부분에서 무서울 정도로 뛰어납니다. 어려운 점은 그 코드가 정말 괜찮은지 여부를 결정하는 것입니다.

루프(loop)에 강력하고 무자비한 검증기(verifier) — 실제 테스트, 정적 분석(static analysis), 거짓말을 거부하는 컴파일러(compiler) — 를 부여하면, 루프는 진정으로 작동하는 결과물로 수렴합니다. 반대로 약한 검증기를 부여하면, 똑같은 루프가 자신만만하고 보기 좋게 포맷된 쓰레기를 무한히 쏟아내며, 아무런 의미도 없는 초록색 체크표시를 향해 환각(hallucination)을 일으키며 나아갈 것입니다.

따라서 향후 10년의 기술은 프롬프트 제작(prompt-craft)이 아닙니다. 그것은 검증(verification)을 설계하는 것, 즉 AI가 절벽으로 떨어지지 않고 안전하게 스스로와 대화할 수 있게 해주는 방탄 유효성 검사 시스템(bulletproof validation systems)을 설계하는 것입니다. 이는 적절한 단어를 찾아내는 것보다 더 어렵고, 희귀하며, 훨씬 더 가치 있는 종류의 엔지니어링입니다.

철학에서 프로덕션으로: 우리가 루프를 설계한 방식
기술계의 나머지 사람들이 소셜 미디어에서 Cherny의 인용구를 두고 논쟁하는 동안, 진짜 과제는 화려하지 않습니다. 즉, Anthropic의 내부 실험실 밖에서, 프로덕션(production) 환경에서 실제로 작동하는 루프 엔지니어링 인프라를 어떻게 구축할 것인가 하는 점입니다.

단일 모델 주위에 루프를 닫으면 다음과 같은 현실적인 벽에 빠르게 부딪힙니다: 컨텍스트 윈도우(context-window) 저하, 환각의 죽음의 소용돌이(hallucinatory death spirals), 그리고 프로젝트 전반에 걸친 메모리(memory)의 부재입니다. Fractera에서 우리는 지난 1년 동안 Cherny의 철학을 단순한 예측이 아닌 아키텍처 설계도(architectural blueprint)로 취급했으며, 정확히 이러한 실패 모드(failure modes)에서 살아남을 수 있는 Fractera 개발 루프(Fractera Development Loop)를 구축했습니다.

이 프로세스에 대하여: https://github.com/Fractera/ai-workspace

프로덕션급 루프의 구조
루프를 실제 소프트웨어에 적용 가능하게 만들려면, 하나의 AI가 스스로와 대화하는 단계를 넘어 진화해야 합니다. 오케스트레이션(orchestration), 특화된 에이전트(specialized agents), 그리고 지속적인 메모리 중추(persistent memory spine)가 필요합니다:

멀티 에이전트 오케스트레이션 (Multi-agent orchestration, Hermes). 단일 모델을 무한히 루프(loop)시키는 대신, 우리의 오케스트레이터는 상위 수준의 명령을 분해하고 각 마이크로 태스크(micro-task)에 가장 적합한 에이전트를 배정합니다. 즉, 어려운 로직에는 Claude Code를, 리팩토링(refactoring)에는 Codex를, 빠른 탐색에는 Gemini를 사용하는 식입니다.

그래프 메모리 중추 (Graph-memory spine, LightRAG). 자율 루프(autonomous loop)에서 가장 큰 위험은 건망증 효과(amnesia effect)입니다. 고집스러운 버그를 해결하기 위해 루프를 15번 반복하다 보면, 에이전트는 전체 아키텍처(architecture)를 놓치게 됩니다. 지식 그래프 RAG (Knowledge Graph RAG)는 지속적이고 지워지지 않는 메모리 역할을 하여, 루프를 도는 모든 에이전트가 코드베이스의 실제 규칙과 스타일을 계속해서 교차 참조할 수 있게 합니다.

불변의 검증 루프 (An immutable verification loop). 루프는 테스트 및 배포(test-and-deploy) 스위트가 오류 0개를 반환할 때만 종료됩니다. 배포에 실패하면, 로그는 그래프 메모리에 의해 즉시 문맥화(contextualized)되어 자동 치유를 위해 에이전트 링(agent ring)으로 다시 던져집니다.

소프트웨어 엔지니어의 새로운 직무 기술서
우리는 코드를 작성하는 단계에서 벗어나, 프롬프트(prompt) 작성을 지나, 인지 파이프라인(cognitive pipelines)을 구축하는 단계로 직행하고 있습니다. 이제 기술(craft)은 명령(instruction) 그 자체가 아니라, 그 명령이 실행되는 시스템입니다.

그리고 이것은 공짜가 아닙니다. 루프와 함께 두 가지 새로운 비용이 발생합니다. 이해 부채(Comprehension debt): 에이전트가 보이지 않는 곳에서 파일을 300번이나 쓰고 다시 쓰는 동안, 당신의 코드베이스에 대한 이해도는 조용히 침식됩니다. 코드는 작동하지만, 당신은 더 이상 왜 작동하는지 확신할 수 없게 됩니다. 그리고 순수 컴퓨팅 비용(raw compute): 하나의 버그를 잡기 위해 100번의 침묵 속 시도를 반복하는 루프는 토큰(tokens)을 통해 실제 돈을 태워버릴 수 있습니다. 이 시대에 승리하는 엔지니어들은 비용 대비 품질(cost-versus-quality)을 청구서에 찍히는 깜짝 놀랄 비용이 아니라, 의도적인 설계 결정(design decision)으로 다룹니다.

프롬프트 엔지니어링(prompt engineering)의 시대는 공식적으로 끝났습니다. 남은 유일한 질문은 Cherny가 이미 스스로에게 던졌던 질문입니다: 당신은 여전히 AI에게 말을 걸려고 노력 중입니까, 아니면 AI가 스스로 실행될 수 있게 하는 루프를 구축하고 있습니까?