지금까지 AI 코딩 에이전트를 잘 쓰는 방법은 좋은 프롬프트를 쓰는 것이었습니다. 무엇을 만들지, 어떤 맥락인지, 어떤 제약이 있는지 직접 설명하고, 결과를 받아서 다음 프롬프트를 쓰는 식이었죠. 그런데 그 방식이 바뀌고 있습니다.

구글 엔지니어링 디렉터 Addy Osmani가 최근 블로그에 루프 엔지니어링(Loop Engineering) 개념을 정리했습니다. Claude Code를 이끄는 Boris Cherny의 말을 인용하며 시작합니다. “저는 더 이상 Claude에게 직접 프롬프트를 입력하지 않습니다. Claude에게 프롬프트를 입력하는 루프를 만들고, 그 루프가 무엇을 할지 파악하도록 합니다. 제 일은 루프를 작성하는 것입니다.”

출처: Loop Engineering – Addy Osmani

프롬프터에서 루프 설계자로

루프 엔지니어링의 핵심은 간단합니다. 내가 직접 에이전트에게 말을 거는 대신, 에이전트에게 말을 거는 시스템을 만드는 것입니다. 목적을 정의하면 AI가 완료될 때까지 반복하는 구조입니다.

2년 전까지만 해도 코딩 에이전트는 철저히 사람이 쥐고 있는 도구였습니다. 한 번 입력하고, 결과를 읽고, 다음 입력을 쓰는 식으로 모든 턴을 사람이 주도했죠. 루프 엔지니어링은 그 주도권을 시스템으로 이전합니다. 작업을 찾고, 분배하고, 검토하고, 다음 할 일을 결정하는 과정 전체를 시스템이 맡는 방식입니다.

이 구조는 특정 도구에 종속되지 않습니다. Osmani는 Codex와 Claude Code가 사실상 동일한 5가지 구성요소를 갖추고 있다는 점을 짚습니다. 어느 쪽을 쓰든 루프의 모양은 같습니다.

루프를 구성하는 5가지 요소

1. 자동화(Automations) — 루프의 심장 박동

루프가 단발성 실행이 아닌 실제 루프가 되려면 자동화가 필요합니다. 일정에 따라 저절로 실행되며 작업을 발굴하고 분류합니다. Codex는 자동화 탭에서 프롬프트, 실행 주기, 실행 환경을 설정하면 결과가 트리아지(Triage) 수신함으로 들어옵니다. Claude Code는 /loop, /goal, 훅(hooks), GitHub Actions를 통해 같은 역할을 합니다.

특히 /goal은 조건이 충족될 때까지 스스로 계속 실행하는 방식입니다. “auth 테스트 전체가 통과하고 린트가 클린한 상태”처럼 검증 가능한 완료 조건을 정의하면, 별도의 소형 모델이 매 턴마다 조건 달성 여부를 판단합니다. 코드를 만든 에이전트가 아닌 다른 모델이 완료를 판정하는 구조입니다.

2. 워크트리(Worktrees) — 병렬 작업의 충돌 방지

두 에이전트가 동시에 같은 파일을 수정하면 충돌이 납니다. 워크트리는 같은 저장소 히스토리를 공유하면서도 각자 독립된 작업 디렉터리에서 작업하게 해줍니다. 서로의 체크아웃을 건드리지 않으니 병렬 실행이 가능합니다. Codex는 기본 내장, Claude Code는 git worktree와 --worktree 플래그, 서브에이전트 설정으로 구현합니다.

3. 스킬(Skills) — 반복 설명을 없애는 프로젝트 메모리

에이전트는 세션이 끝나면 모든 것을 잊습니다. 다음 세션에 같은 프로젝트 맥락을 다시 설명해야 하는 구조입니다. 스킬은 이 문제를 해결합니다. 프로젝트 규약, 빌드 방식, “이 방식은 쓰지 않는 이유” 같은 암묵적 지식을 SKILL.md 파일로 정리해두면, 에이전트가 매 실행마다 읽어들입니다. Codex와 Claude Code 모두 동일한 형식을 씁니다.

스킬 없이 루프를 돌리면 루프는 매 사이클마다 프로젝트를 처음부터 파악해야 합니다. 스킬이 있으면 지식이 누적됩니다.

4. 플러그인과 커넥터(Plugins & Connectors) — 실제 환경과의 연결

파일시스템만 볼 수 있는 에이전트는 작은 루프밖에 못 만듭니다. MCP 기반 커넥터를 연결하면 이슈 트래커를 읽고, 데이터베이스를 조회하고, Slack에 메시지를 보낼 수 있습니다. Codex와 Claude Code 모두 MCP를 지원하므로 한쪽용으로 만든 커넥터가 다른 쪽에서도 작동합니다.

이 차이가 크게 느껴지는 순간은 분명합니다. “수정 사항은 이렇습니다”라고 말하기만 하는 에이전트와, PR을 열고 Linear 티켓을 연결하고 CI가 통과하면 Slack에 알림을 보내는 루프의 차이입니다.

5. 서브에이전트(Sub-agents) — 만든 자와 검토하는 자의 분리

루프에서 가장 중요한 구조적 원칙입니다. 코드를 만든 모델은 자기 코드를 너무 관대하게 평가합니다. 별도 지시를 받은 두 번째 에이전트가 첫 번째 에이전트가 놓친 부분을 잡아냅니다. Codex는 TOML 파일로 에이전트를 정의하고, Claude Code는 .claude/agents/에 서브에이전트를 구성합니다. 탐색 에이전트, 구현 에이전트, 검증 에이전트를 분리하는 방식이 일반적입니다.

/goal의 완료 판정도 이 원리로 작동합니다. 코드를 만든 에이전트가 아닌 별도 모델이 루프를 멈출지 결정합니다.

루프가 없애주지 않는 것들

Osmani는 루프의 가능성을 설명하면서도 세 가지 문제가 루프가 발전할수록 오히려 더 선명해진다고 짚습니다.

검증은 여전히 사람의 몫입니다. 감시 없이 돌아가는 루프는 실수도 감시 없이 만들어냅니다. 서브에이전트로 검증 구조를 만들어도 “완료”는 주장일 뿐 증명이 아닙니다.

이해도는 의도적으로 유지해야 합니다. 루프가 빠르게 코드를 만들수록, 내가 실제로 이해하는 코드와 저장소에 있는 코드 사이의 간격이 벌어집니다. 루프가 매끄러울수록 이 간격은 더 빠르게 커집니다.

그리고 편안한 자세가 위험한 자세가 됩니다. 루프가 알아서 돌아가면 그냥 결과를 받아들이고 싶은 유혹이 생깁니다. Osmani는 이를 “인지적 항복(cognitive surrender)”이라고 부릅니다. 루프를 판단력 있게 설계하면 가속제가 되지만, 생각을 피하기 위해 루프를 쓰면 반대 결과를 가져옵니다. 같은 행동, 반대 결과입니다.

레버리지 포인트가 프롬프트에서 루프 설계로 이동했다는 것, 그게 이 개념이 전달하는 핵심입니다.