이제 에이전트에 프롬프트하지 않는다
— 루프 엔지니어링의 시대

지난 약 2년간 코딩 에이전트와 일하는 방식은 하나였습니다. 좋은 프롬프트와 충분한 컨텍스트를 주고, 결과를 읽고, 다음 프롬프트를 쓰는 것. 에이전트를 도구로 직접 손에 쥐는 방식입니다. 루프 엔지니어링은 그 손의 자리를 시스템으로 바꿉니다. 작업을 찾아 분배하고, 검증하고, 완료된 것을 기록하고, 다음 작업을 결정하는 작은 시스템을 만들어, 그 시스템이 에이전트를 찌르게 하는 것입니다. Cherny의 표현을 빌리면 "이제 Claude에 프롬프트하지 않는다. 루프가 Claude에 프롬프트하고 무엇을 할지 정한다. 내 일은 루프를 작성하는 것"입니다.

중요한 변화는 이것이 더 이상 도구의 문제가 아니라는 점입니다. 1년 전엔 루프를 원하면 bash 스크립트 더미를 직접 작성하고 유지해야 했습니다. 지금은 구성 요소가 제품 안에 그대로 탑재돼 있습니다. Steinberger가 나열한 목록이 OpenAI의 Codex 앱과 거의 정확히 일치하고, Claude Code와도 거의 동일합니다. 어느 도구가 낫냐를 다툴 이유가 없습니다 — 어느 쪽에서도 동작하는 루프를 설계하면 됩니다.

다섯 가지 구성 요소, 그리고 메모리

여섯 번째 요소는 메모리입니다. markdown 파일이든 Linear 보드든, 단일 대화 밖에 살면서 완료된 것과 다음 할 것을 보관하는 곳. 너무 단순해 보이지만 모든 장기 실행 에이전트가 의존하는 동일한 트릭입니다. 모델은 실행 사이에 모든 것을 잊기 때문에 메모리는 컨텍스트가 아니라 디스크에 있어야 합니다. 에이전트는 잊어도 repo는 잊지 않습니다.

하나의 루프는 어떻게 생겼는가

Osmani가 그리는 전형적인 루프는 이렇습니다. automation이 매일 아침 repo에서 실행되고, 그 프롬프트가 triage skill을 호출해 어제의 CI 실패·열린 이슈·최근 커밋을 읽어 결과를 상태 파일에 기록합니다. 할 가치가 있는 항목마다 격리된 worktree가 열리고, sub-agent 하나가 수정 초안을 만들면 두 번째 sub-agent가 프로젝트 skill과 기존 테스트 대비로 리뷰합니다. connector가 PR을 열고 티켓을 갱신하며, 루프가 처리하지 못한 것은 triage 인박스로 들어옵니다. 상태 파일이 전체의 척추입니다 — 무엇을 시도했고 통과했고 아직 열려 있는지를 기억해, 다음 날 아침 실행이 오늘 멈춘 지점에서 이어갑니다. 핵심은 그 단계들 중 어느 것도 사람이 프롬프트하지 않았다는 것. 한 번 설계했을 뿐입니다.

낯설지 않을 겁니다. 이 시리즈에서 다뤄온 S-Skills 하네스가 정확히 이 구조이기 때문입니다. PROJECT.md와 context.md가 상태 파일(메모리), 역할별 서브에이전트 병렬 디스패치가 worktree 위의 분업, 구현자 산출물을 보지 않는 독립 QA가 maker·checker 분리입니다. 루프 엔지니어링은 새로운 발명이라기보다, 장기 실행 에이전트를 굴려본 사람들이 각자 도달한 같은 결론에 이름이 붙은 것에 가깝습니다.

루프가 여전히 대신해 주지 않는 것

루프는 일을 바꿀 뿐 사람을 지우지 않습니다. 오히려 루프가 좋아질수록 더 날카로워지는 문제가 셋 있습니다. 첫째, 검증은 여전히 본인 몫입니다. 무인으로 도는 루프는 무인으로 실수하는 루프이기도 합니다. verifier를 분리하는 이유는 루프의 '끝났다'에 의미를 부여하기 위해서지만, 그래도 'done'은 증명이 아니라 주장입니다. 둘째, 이해는 방치하면 썩습니다. 직접 쓰지 않은 코드를 빨리 출하할수록, 존재하는 것과 실제로 이해하는 것 사이의 간극 — comprehension debt — 이 커집니다. 매끄러운 루프는 산출물을 읽지 않으면 그 간극을 더 빨리 키웁니다.

셋째가 가장 미묘합니다. 편안한 자세가 위험한 자세입니다. 루프가 스스로 돌면 의견 갖기를 멈추고 돌려받은 것을 그대로 받기 쉽습니다. 루프 설계는 판단을 갖고 하면 치료제고, 사고를 피하려고 하면 가속제입니다 — 같은 행동, 정반대의 결과. 같은 루프를 만든 두 사람 중 한 명은 깊이 이해한 일을 더 빨리 해내고, 다른 한 명은 일을 이해하지 않기 위해 씁니다. 루프는 그 차이를 모르지만, 당신은 압니다. 이것이 루프 설계가 프롬프트 엔지니어링보다 쉬운 게 아니라 더 어려운 이유입니다. Cherny의 요점은 일이 쉬워졌다는 게 아니라, 레버리지 지점이 옮겨졌다는 것입니다.

S-Skills는 이것을 /sj-loop으로 구현했다

S-Skills 하네스에는 이 글의 내용이 그대로 스킬로 들어 있습니다. /sj-loop에 "테스트 깨진 거 잡는 루프 만들어줘" 한 마디를 던지면, 목적 · 1회 반복 작업 · 기계 검증 가능한 정지 조건 · 상태 파일 · 가드레일을 갖춘 루프 프롬프트를 생성해 docs/sj-company/loops/에 저장합니다. "잘 되면" 같은 모호한 정지 조건은 저장 전에 재작성됩니다 — 정지 판단은 작업 결과 서술이 아니라 `npm test` 종료 코드 0처럼 실행 결과로만 합니다. 정지 신호조차 에이전트의 출력 문장이 아니라 상태 파일의 `status: DONE` 줄 하나입니다. 에이전트의 '끝났다'는 주장을 믿지 않고, 디스크에 남은 상태만 믿는 설계입니다.

실행은 세 단계 중 고릅니다. 드라이런(지금 1회만 돌려 루프 프롬프트 자체를 검증) → 세션 내 반복(Claude Code 내장 /loop으로 간격마다 재실행) → 클라우드 스케줄(/schedule cron routine, 노트북을 닫아도 돕니다). 무인으로 돌리기 전에 드라이런이 먼저인 것이 불변 원칙입니다. 그리고 어떤 루프도 PR 머지·프로덕션 배포를 자동 실행하지 못합니다 — 사람 게이트 문구가 없는 루프 프롬프트는 저장 자체가 거부됩니다. 같은 실패가 2회 반복되면 멈추고 triage-inbox에 기록하며, 루프가 또 다른 루프를 만드는 자기 증식도 금지됩니다. 스킬 첫 줄의 모토가 이 글의 결론과 같습니다. build the loop, stay the engineer.