"더 이상 코딩 에이전트(coding agents)에게 직접 프롬프팅을 해서는 안 됩니다. 대신 에이전트에게 프롬프팅을 수행할 루프(loops)를 설계해야 합니다."

이 문장을 보고 저는 빵 터졌습니다. Peter Steinberger는 6월 7일 X(구 트위터)에 이 12개의 단어를 올렸고, 24시간 만에 650만 명의 사람들이 이를 읽었습니다. 그리고 그로부터 5일 전, Claude Code의 책임자인 Boris Cherny는 WorkOS 이벤트 무대에서 정확히 똑같은 말을 했습니다. 거의 토씨 하나 틀리지 않고 말이죠.

제가 웃음이 터진 이유는, 저 또한 이름조차 붙이지 못한 채 몇 달 동안 이 방식을 실행해 오고 있었기 때문입니다.

요약(TLDR): Cherny는 Claude에게 프롬프팅하는 것을 그만두었습니다. 이제 그의 **직업(job)**은 자신을 대신해 Claude에게 프롬프팅을 수행할 **시스템(systems)**을 작성하는 것입니다. 만약 여러분이 /goal 명령어를 사용하고 작업이 완료될 때까지 자리를 비워본 적이 있다면, 여러분은 이미 이 방식의 한 버전을 수행하고 있었던 것입니다. 다만 그것이 무엇이라 불리는지, 그리고 여러분의 방식과 완전한 루프 엔지니어링 (loop engineering) 사이의 **격차 (gap)**가 실제로 얼마나 큰지는 모르고 있었을 뿐입니다.

나는 이것을 "알아서 하기 모드(Figure It Out Mode)"라고 불렀다

그 워크플로우는 단순했고, 어쩌면 부끄러울 정도로 단순했습니다. 저는 /goal에 목표를 설정하고, 프로젝트 규칙이 담긴 CLAUDE.md 파일을 던져준 뒤, Claude Code에게 저장소 컨텍스트(repo context)를 제공하고 자리를 떠났습니다. 20분 뒤, 때로는 2시간 뒤에 돌아왔습니다. 결과는 작동하는 기능이 있거나, 혹은 수정이 필요한 엉망진창인 상태 중 하나였습니다. 두 결과 모두 프로젝트를 전진시켰습니다.

어떤 원칙적인 신념을 가지고 이렇게 한 것은 아니었습니다. 그저 출력 스트림(output stream)을 지켜보는 것을 멈추고, Claude Code를 내가 업무를 위임할 수 있는 주니어 개발자(junior dev)처럼 취급하기 시작했을 때 자연스럽게 일어난 일이었습니다. 목표를 설정하고, 컨텍스트를 주고, 떠나는 것 말이죠.

이 모든 것에 붙여진 이름은 없었습니다.

그러다 Steinberger가 게시물을 올렸고, 제 피드의 절반은 고개를 끄덕였으며, 나머지 절반은 이것이 정말 새로운 것인지 아니면 단순히 단계가 추가된 프롬프팅일 뿐인지에 대해 논쟁했습니다. 그리고 5일 전의 Cherny의 영상이 퍼지기 시작했습니다. "저는 더 이상 Claude에게 프롬프팅하지 않습니다. Claude에게 프롬프팅을 하고 무엇을 할지 스스로 결정하게 만드는 루프(loops)를 실행하고 있습니다. 제 일은 루프를 작성하는 것입니다."

발견이 아닌 인지였습니다. 저는 이미 이 방식의 한 버전을 실행하고 있었습니다. 단지 이름이 붙었을 뿐입니다.

그 명명(naming)은 처음 읽었을 때 보이는 것보다 훨씬 더 중요합니다. 어떤 관행에 대한 용어가 없다면, 그것에 대해 의견을 나눌 수도 없고, 의도적으로 패턴을 개선할 수도 없으며, 자신이 그것을 잘하고 있는지 못하고 있는지도 알 수 없습니다. "알아서 해결하기 모드(Figure it out mode)"는 개인적인 약칭으로는 괜찮았습니다. 하지만 "루프 엔지니어링 (Loop engineering)"은 방법론을 구축할 수 있는 무언가입니다. 6월 2일과 6월 7일 사이에 개념이 변한 것은 아닙니다. 변한 것은 이제 동일한 대화에 참여하는 모든 사람이 같은 단어를 사용하게 되었고, 아직 이를 수행하지 않았던 사람들은 자신들이 무엇을 놓치고 있었는지 알게 되었다는 점입니다.

당신은 어느 단계에 있습니까?

AI 개발 자동화의 3단계

Cherny가 6월 2일 WorkOS Acquired Unplugged에서 설명한 내용은 개발자가 코딩 에이전트 (coding agent)와 협업하는 방식의 진화 과정을 3단계로 나눕니다.

1단계 (Rung 1): Claude를 자동 완성 (autocomplete)처럼 사용합니다. Copilot보다 똑똑하지만, 여전히 코드를 직접 작성하고, 모든 줄을 검토하며, 도구를 제어합니다. 에이전트가 보조할 뿐입니다. 당신이 모든 단계를 지시합니다.

2단계 (Rung 2): 5개 또는 10개의 Claude를 병렬로 프롬프팅 (prompting)합니다. 작업을 넘기고, 출력을 검토하며, 수동으로 그 사이를 라우팅 (routing)합니다. 여전히 루프 (loop) 안에 있으며, 단지 운전자가 아닌 더 바쁜 교통 관리자가 된 것뿐입니다. 스스로를 "AI에 능숙하다"고 생각하는 많은 사람이 이 단계에 머물러 있으며, 자신들이 3단계에 있다고 가정합니다.

3단계 (Rung 3): 당신은 루프 안에 전혀 있지 않습니다. 당신은 당신을 대신해 루프를 실행하는 시스템을 구축했습니다. Claude는 당신의 다음 메시지를 기다리지 않습니다. 당신이 한 번 정의해 놓은 조건, 검증 게이트 (verification gates), 그리고 재시도 로직 (retry logic)에 따라 실행됩니다. 당신의 역할은 "프롬프트를 작성하는 것"에서 "에이전트가 실패하거나, 성공하거나, 혹은 예상치 못한 상황에 부딪혔을 때 어떤 일이 일어날지 설계하는 것"으로 전환되었습니다.

2단계와 3단계의 차이는 프롬프팅 (Prompting) 기술의 문제가 아닙니다. 그것은 아키텍처 (Architectural)의 문제입니다. 프롬프팅을 더 잘한다고 해서 3단계에 도달할 수 있는 것이 아닙니다. 프롬프팅을 중단하고, 로직 (Logic)을 스스로 실행되는 무언가로 인코딩 (Encoding)함으로써 그 단계에 도달하게 됩니다. 이것을 타워 디펜스 (Tower Defense) 문제라고 생각하십시오. 모든 위치를 수동으로 방어하는 것을 멈추고, 당신 없이도 버텨낼 구조물을 배치하기 시작하는 것입니다. 프롬프팅은 직접 전투입니다. 루프 엔지니어링 (Loop engineering)은 기지를 떠나기 전에 포탑을 건설하는 것입니다.

격차는 이제 명확해졌다

6월 7일의 게시물은 트렌드 보고서가 아니었습니다. 그것은 측정값이었습니다.

한 분야의 최고 전문가들이 자신의 실무 방식이 변했다고 공개적으로 발표할 때, 이미 그렇게 하고 있는 사람들과 나머지 사람들 사이의 격차는 보이지 않는 상태에서 보이는 상태로 전환됩니다. 바로 그런 일이 일어났습니다. 이 방식은 이미 몇 달 동안 실행되어 왔습니다. 변한 것은 점수판이 공개되었다는 점입니다.

Karpathy의 AutoResearch 프로젝트는 기록된 것 중 가장 명확하고 구체적인 증거입니다. 그는 단일 GPU에서 하룻밤 사이에 50개의 ML (머신러닝) 실험을 수행합니다. 에이전트 (Agent)가 학습 코드를 수정하고, 실행하고, 결과를 읽고, 반복(iterate)하며, 루프 (Loop) 내에 인간의 결정은 개입하지 않습니다. 그는 정확히 이것을 위해 'AI의 루프 시대 (Loopy Era of AI)'라는 용어를 만들어냈으며, 이는 채널 평균 조회수인 약 8,500회를 훨씬 상회하는 875,000회의 조회수를 기록한 No Priors 팟캐스트 에피소드에서 언급되었습니다. 이는 연구 수준의 AI 팟캐스트에서 100배에 달하는 아웃라이어 (Outlier)입니다. 이를 이해하려는 갈망은 더 이상 이론적인 수준이 아닙니다.

Cherny 본인의 수치는 더욱 직접적입니다. 2025년 12월 이전 30일 동안 그가 작성한 개인 코드의 100%는 그가 직접 Claude에게 프롬프팅을 해서 만든 것이 아니라, 그가 설정해 둔 루틴 (Routines)에 의해 작성되었습니다. 그리고 2026년 6월의 업계 보고에 따르면, Claude Code는 GitHub의 모든 공개 커밋 (Public commits) 중 약 4%를 차지하고 있습니다. 전체 공개 GitHub 그래프의 4%는 거대한 발자국이며, 이는 세션마다 수동으로 프롬프팅을 해서 만들어지는 것이 아닙니다. 그것은 루프 (Loops)가 실행되고 있는 것입니다. 현 시점에서 프로덕션 코드 (Production code)를 배포하기 위해 개별 프롬프트를 실행하는 것은 에이전트 기반 개발 (Agentic development)에서의 "내 컴퓨터에서는 잘 돌아가는데"와 같은 수준의 이야기입니다.

개념보다 타이밍이 더 중요한 이유는 복리 논리 (compounding logic) 때문이며, 이 부분은 대부분의 설명 스레드에서 완전히 생략되는 대목입니다. 수동으로 프롬프팅 (prompting)을 하는 개발자는 시간이 지남에 따라 더 빠른 반복 (iteration)과 더 정밀한 결과를 얻으며 프롬프팅 실력이 향상됩니다. 이는 선형적인 노력 곡선 위에서의 선형적인 개선이며, 진정으로 가치 있는 일입니다. 하지만 루프 로직 (loop logic)을 인코딩하는 개발자는 구조적으로 완전히 다른 모델에서 작동합니다. 그들이 설계한 각 루프는 그들 없이도 실행됩니다. 그 루프에 가해지는 각각의 개선 사항은 향후 모든 실행에 자동으로 적용됩니다. 한쪽 궤적은 이미 수행하고 있는 업무를 개선하지만, 다른 쪽 궤적은 다음 루프를 설계하는 동안 해당 범주의 업무를 처리하는 시스템을 구축합니다. 이 두 궤적은 시작 단계에서는 거의 동일해 보입니다. 첫 1주일 동안은 구분할 수 없습니다. 차이는 몇 주에 걸쳐 가시화되며, 루프를 구축한 사람의 방향으로 복리 효과가 발생하며, 이는 더 빠른 프롬프팅만으로는 회복할 수 없습니다. 6월 7일의 순간이 명확하게 보여준 것이 바로 이것입니다. 점수판이 공개되었고, 이제 여러분은 지난 한 달간의 결과물만 보고도 자신이 어떤 궤적 위에 있는지 대략적으로 알 수 있습니다.

당신이 명명하지 않은 루프

Steinberger의 게시물이 퍼지기 시작했을 때 제가 관찰한 점은, 인지하며 고개를 끄덕이던 많은 개발자가 자신들이 이미 일부 작업에서 3단계(rung 3)에 도달해 있다는 사실을 전혀 모르고 있었다는 것입니다.

/goal은 이미 폐쇄 루프 (closed loop)입니다. 당신은 중단 조건 (stop condition)을 정의합니다. Claude는 그 조건이 충족되거나 심각한 오류가 발생할 때까지 반복 (iterate)합니다. 당신은 반복 사이에 결정을 내리지 않습니다. 이 기능은 2026년 5월 Claude Code v2.1.139에서 출시되었으며, 이를 조기에 파악하여 목표를 설정하고, 자리를 떠났다가 결과로 돌아온 개발자들은 기술적으로 이미 루프 엔지니어링 (loop engineering)을 수행하고 있었던 것입니다. 저는 /goal이 존재하기도 전부터 상세한 컨텍스트 (context)가 포함된 긴 세션을 사용하며 Claude가 작업에 집중하기를 바라며 이 방식을 실행해 왔습니다. 단지 그것에 이름을 붙이지 않았을 뿐입니다.

"/goal을 사용하고 떠난 것"과 실제 프로덕션 루프 (production loop)를 구분 짓는 3가지 요소는 다음과 같습니다: 품질 규칙을 인코딩하는 스킬 파일 (skill file), 해당 규칙에 따라 출력을 검증하는 검증 단계 (verification step), 그리고 결과물이 배포되기 전 새로운 시각으로 검토하는 리뷰 에이전트 (review agent)입니다. 여러분은 나머지 2개가 존재하는지도 모른 채 이미 이 중 1개를 사용하고 있을 수도 있습니다. 많은 개발자가 CLAUDE.md를 가지고 있습니다. 하지만 이를 검증 레이어 (verification layer)에 연결한 사람은 많지 않습니다. 그리고 리뷰 에이전트까지 추가한 사람은 훨씬 더 적은데, 바로 이 단계에서 빌드 에이전트 (build agent)가 수용 가능하다고 합리화했던 오류들을 루프가 잡아내게 됩니다.

Anthropic이 검증 비디오에서 보여준 전체적인 구조는 다음과 같습니다: 프로젝트의 타협할 수 없는 원칙들을 인코딩하는 SKILL.md, 렌더링된 출력을 해당 규칙과 대조하는 브라우저 검증 단계 (browser verification step), 그리고 무언가가 머지 (merge)되기 전에 검토하는 두 번째 에이전트입니다. 여러분이 이미 작성한 CLAUDE.md는 토대이며, /goal은 이를 바탕으로 실행되고, 리뷰 에이전트는 결과물이 배포되기 전에 출력을 통제합니다. 이 3가지를 연결하면 여러분이 자리에 없어도 돌아가는 루프를 갖게 됩니다.

이미 바이브 코딩 (vibe coding)에서 프롬프트에 프로젝트 로직을 인코딩하는 방식으로 전환한 분들에게, 이 루프는 동일한 아키텍처 (architecture)의 다음 레이어입니다. 암묵적인 프로젝트 규칙을 명시적으로 만들고, 사후에 출력을 눈대중으로 확인하는 것을 멈추려는 본능 말입니다. 루프는 단지 그 로직을 자율 모드 (autonomous mode)로 실행할 뿐입니다.

연관성은 거의 없지만 일단 여기에 적어둡니다. 제가 90년대에 코딩을 배웠을 때, 학교에는 공유된 Bull DPS 7000이 있었습니다. 오래된 메인프레임 (mainframe)이었죠. 한 번에 하나의 컴파일 슬롯 (compilation slot)만 사용 가능했고, 선착순이었습니다. 제가 알아낸 방법은 15초마다 컴파일러 큐 (compiler queue)를 폴링 (polling)하고 슬롯이 열리는 즉시 내 작업을 다시 제출하는 단순한 쉘 스크립트 (shell script)를 작성하는 것이었습니다. 제 코드는 항상 컴파일되었습니다. 제 반 친구들은 수동으로 새로고침을 하고 있었죠. 나중에 훨씬 지나서 친구들에게 이 사실을 고백했습니다. 미안해 친구들. 솔직히 말하면, 그렇게 미안하지는 않습니다.

직접 손으로 하기보다 재시도 (retry) 과정을 인코딩하려는 본능은 30년이나 되었습니다. 브랜딩만 새로워졌을 뿐입니다.

첫 번째 루프에는 대규모 군단이 필요하지 않습니다

3단계 (Rung 3)를 수행하기 위해 100개의 에이전트와 오케스트레이션 레이어 (orchestration layer)가 필요한 것은 아닙니다. 그것은 Karpathy가 밤샘 ML 실험을 위해 실행하는 버전입니다. 당신의 첫 번째 루프는 더 단순하며, 아마 오늘 바로 시작할 수 있을 것입니다.

최소한의 프로덕션 루프 (minimal production loop):

/goal "명세서(spec)에 있는 제품 필터링 기능을 구현하세요. 테스트 스위트 (test suite)를 통과하고 TypeScript 에러가 없을 때 완료합니다."

해당 작업에 대해 그것은 이미 3단계 (rung 3)입니다. Claude는 조건이 충족되거나 스스로 해결할 수 없는 에러에 부딪힐 때까지 실행됩니다. 당신은 그 중간 단계에 머물러 있지 않습니다. 핵심은 목표 (goal)에 포함된 "~할 때 (when)"라는 단어입니다. 왜냐하면 중단 조건은 당신이 나중에 보고 판단해야 하는 것이 아니라, 에이전트가 자동으로 검증할 수 있는 것이어야 하기 때문입니다.

검증 레이어 (verification layer)가 없는 루프는 그저 자동화된 추측에 불과합니다. 이를 프로덕션에서 사용 가능하게 만드는 업그레이드 단계는 다음과 같습니다:

2단계. 프로젝트의 타협할 수 없는 원칙들을 담은 SKILL.md를 추가하세요. 즉, 첫날 새로운 개발자에게 브리핑하는 방식 그대로 작성된, 당신의 실제 프로젝트를 위한 실제 규칙들입니다. 당신이 강제하는 컨벤션 (conventions), 항상 다시 발생하는 엣지 케이스 (edge cases), 아무도 기록해두지 않으면 3일 뒤 코드 리뷰 (code review)에서나 발견하게 될 사항들을 적으세요. 규칙이 구체적일수록, 루프는 작업을 시작하기 전에 당신의 문서를 실제로 읽은 사람처럼 동작할 것입니다.