루프 엔지니어링: 프롬프트가 아니라 시스템을 짜라

2026년 6월, AI 코딩 도구를 실제로 만드는 두 사람이 며칠 간격으로 거의 같은 말을 내놨다. 앤트로픽(Anthropic)에서 Claude Code를 이끄는 보리스 체르니(Boris Cherny)는 출시 1주년 대담에서, 이제 자신은 Claude에 직접 프롬프트하지 않으며 루프(loop)들이 돌면서 Claude에 프롬프트하고 무엇을 할지 정한다, 자신의 일은 그 루프를 짜는 것이라는 취지로 말했다. 뒤이어 오픈소스 자율 에이전트 OpenClaw를 만든 피터 슈타인베르거(Peter Steinberger)는 X에 "당신은 더 이상 코딩 에이전트에 프롬프트하면 안 된다. 당신의 에이전트를 프롬프트하는 루프를 설계해야 한다"고 적었다. 도구를 파는 쪽의 수사로 흘려듣기 쉽지만, 이 문장들은 IT 실무자에게 개인 생산성 팁이 아니라 조직의 작업 단위·비용 구조·검증 체계를 다시 설계하라는 요구다.

이 전환에 이름을 붙인 사람은 이들이 아니다. 구글의 엔지니어링 리더 애디 오스마니(Addy Osmani)가 6월 7일 블로그에 올린 에세이 "Loop Engineering"이 명칭과 구성요소, 그리고 자율 워크플로를 하나의 개념으로 묶었다. O'Reilly Radar가 6월 22일 같은 글을 재게재하면서 담론은 개발자 커뮤니티 전반으로 번졌다. 이번 호가 던지는 한 문장은 여기서 나온다 — 당신이 최적화할 대상은 프롬프트가 아니라 루프다.

"말 잘 걸기"에서 "자율 시스템 짜기"로

오스마니의 정의는 간결하다. "루프 엔지니어링은 에이전트에 프롬프트하는 사람, 즉 당신 자신을 대체하는 것이다. 대신 그 일을 하는 시스템을 설계한다." 지금까지 우리가 익힌 프롬프트 엔지니어링(prompt engineering)이 '좋은 프롬프트를 쓰고 충분한 맥락을 건네는 법'이었다면 — 한 줄을 입력하고, 돌아온 것을 읽고, 다음 줄을 입력하는 일이었다면 — 루프 엔지니어링은 그 자리에 작은 시스템을 앉힌다. 일감을 찾아 나눠주고, 결과를 검사하고, 완료된 것을 기록한 뒤 다음 할 일을 스스로 정하는 시스템이다.

핵심은 최적화의 '단위'가 옮겨갔다는 것이다. 모델이 코드를 제법 잘 쓰게 되면서, 희소해진 기술은 더 이상 '코드를 잘 뽑아내는 영리한 한 문장'이 아니다. 이제 값어치가 나가는 것은 'AI를 올바른 방향으로 반복시키는 루프를 설계하는 능력'이다. 사람이 매번 프롬프트를 던지는 대신, AI 에이전트(agent)가 목표 달성까지 '실행-검증-수정'을 스스로 반복하도록 판을 짜는 일 — 이것이 루프 엔지니어링이 겨누는 패러다임이다. 프롬프트 엔지니어링이 "AI에게 말을 잘 거는 법"이라면, 루프 엔지니어링은 "AI가 스스로 작동하는 자율 시스템을 짜는 법"이다.

그렇다고 프롬프트가 사라진 것은 아니다. 루프 안에서도 에이전트에게 무엇을 어떻게 시킬지는 여전히 프롬프트로 전달된다. 다만 그 프롬프트를 이제 사람이 매번 손으로 치지 않고, 루프가 대신 친다. 프롬프트는 죽은 게 아니라, 더 큰 시스템의 한 부품으로 흡수됐다.

누가 촉발하고, 누가 이름 붙였나

이 대목에서 귀속을 정확히 해둘 필요가 있다. '루프 엔지니어링'이라는 용어와 체계를 만든 사람은 발언으로 불을 지핀 두 사람이 아니라 오스마니다. 체르니와 슈타인베르거는 "프롬프트 말고 루프를 짜라"는 메시지를 같은 시점에 던져 담론을 촉발했고, 그 메시지에 명칭·구성요소·/goal 워크플로라는 뼈대를 세워 하나의 개념으로 정립한 것이 오스마니의 에세이다. "체르니가 루프 엔지니어링이라는 말을 만들었다"고 적으면 사실과 어긋난다.

두 촉발자의 무게는 그들의 자리에서 온다. 체르니는 지금 가장 많이 쓰이는 코딩 에이전트 도구 중 하나인 Claude Code의 책임자다. 그의 발언은 Claude Code 출시 1주년 기념 대담 영상에서 나왔다 — 다만 유통되는 인용문의 워딩이 조금씩 다르게 돌아다니므로, 여기서는 축자 인용이 아니라 발언의 취지로 옮긴다. 슈타인베르거는 오스트리아 출신 개발자로 PDF 도구 PSPDFKit을 창업했고, 이후 메시징 플랫폼을 인터페이스로 쓰는 오픈소스 자율 에이전트 OpenClaw를 만들었다. OpenClaw는 GitHub에서 가장 빠르게 별을 모은 신규 저장소 중 하나로 알려졌으며, "제대로 설계된 루프가 실제로 어떤 모습인지 보여주는 참조 구현"으로 회자된다. 그는 2026년 2월 OpenAI 합류를 발표했고, OpenClaw는 재단으로 이관됐다. 즉 슈타인베르거의 현재 소속은 OpenAI이지 앤트로픽이 아니다.

주목할 점은 서로 다른 벤더의 실세 두 사람이 같은 시점에 같은 메시지를 내놨다는 사실 자체가 이 흐름에 신뢰를 실었다는 것이다. 동시에, 바로 그 지점에서 회의론의 씨앗도 함께 심겼다 — 토큰을 파는 회사의 사람들이 "토큰을 더 태우는 방식"을 권한다는 이해상충 말이다. 이 문제는 뒤에서 다시 다룬다.

/goal은 실제로 어떻게 도는가

추상적 구호에 그치지 않으려면 루프가 실제로 어떻게 도는지 봐야 한다. 오스마니가 드는 대표 워크플로는 Claude Code의 /goal이다. 사용자는 목표와 종료조건만 준다. 그러면 에이전트는 그 조건이 실제로 참이 될 때까지 반복한다. 예컨대 종료조건을 "test/auth 폴더의 모든 테스트가 통과하고 린트(lint) 오류가 없을 것"으로 걸어두고 자리를 비우면, 에이전트는 코드를 고치고 테스트를 돌리고 다시 고치기를 조건이 충족될 때까지 반복한 뒤 결과를 내놓는다.

이 워크플로에서 가장 중요한 설계는 채점을 누가 하느냐다. 매 턴이 끝날 때마다 별도의 작은 모델이 완료 여부를 검사한다. 코드를 작성한 에이전트가 자기 결과를 스스로 채점하지 않도록 분리한 것이다. 오스마니의 표현을 빌리면, "코드를 쓴 모델은 자기 숙제를 채점할 때 너무 후하다." 작성자와 채점자를 갈라놓는 이 '작성-검증 분리'가 자율 루프를 미덥게 만드는 핵심 장치다.

명령 이름도 구분해둘 만하다. The Neuron의 정리에 따르면 /loop은 정해진 주기로 프롬프트를 반복 실행하는 것이고, /goal은 측정 가능한 종료 상태에 도달할 때까지 지속하는 것이다. 자율 루프의 안전은 결국 이 종료조건(Stop Rule)의 품질에 달려 있다. 원칙은 하나다 — 종료조건은 사람이 아니라 기계가 판별할 수 있어야 한다. "괜찮아 보이면 멈춰라" 같은 주관적 지시는 금물이고, "모든 테스트 통과, 린트 클린"처럼 참·거짓이 명확히 갈리는 조건이어야 한다. 자율 루프를 실제로 운영하는 실무자들(Black Matter VC)은 여기에 하드 스톱 세 종을 덧붙이라고 조언한다. 반복 횟수 상한(통상 20회 시도 후 중단), 진척 정지 감지(같은 오류나 빈 변경이 반복되면 중단), 그리고 달러 예산 상한이다. "가드레일이 없으면 무한 루프와 예산 초과 청구가 발생한다."

이 루프를 조립하려면 몇 가지 부품이 필요하다. 오스마니는 자동화(Automations), 워크트리(worktree), 스킬(skill), 플러그인·커넥터(connector), 서브에이전트(sub-agent), 그리고 메모리(memory) 여섯 가지를 든다. 각 부품이 무엇을 하고 없으면 루프의 어디가 무너지는지, 오늘 어떤 도구로 구현하는지에 대한 자세한 부품 해부는 이어지는 '루프 해부' 섹션에 양보한다. 여기서는 한 가지만 기억하면 된다 — 이것들이 추상적 개념이 아니라 지금 당장 조립 가능한 구체적 부품이라는 점이다.

"그냥 while 루프 아니냐"

열광만 있는 것은 아니다. 레딧과 해커뉴스에서는 "그냥 LLM 호출을 붙인 while 루프 아니냐"는 비판이 큰 스레드로 번졌다(특정 화자를 지목할 수 있는 발언은 아니며, 커뮤니티에서 제기된 회의론으로 봐야 한다). 골자는 명명의 계보를 겨눈다. 프롬프트 엔지니어링 → 컨텍스트 엔지니어링 → 하네스(harness) 엔지니어링 → 루프 엔지니어링으로 이어진 연쇄 리브랜딩이며, 매번 이전 기술을 낡은 것으로 선언하면서 본질은 크게 달라지지 않았다는 것이다. 실제로 이 계보는 지지와 회의 양쪽의 근거가 된다. 지지 측에는 추상화 수준이 한 단계씩 올라간 자연스러운 진화로 보이고, 회의 측에는 같은 것을 새 이름으로 되파는 마케팅으로 보인다.

조건을 단 회의론도 있다. Flask를 만든 아르민 로나허(Armin Ronacher)는 자율 하네스가 포팅, 성능 탐색, 보안 스캔처럼 일회성·기계적 변환에는 유효하다고 인정하면서도, 현재 모델이 "지나치게 방어적이고 복잡하며 국소적으로만 추론하는 코드"를 내놓는다고 우려한다. 그는 "오늘의 무인 하네스가 작년 가을보다 못한 코드를 낸다"고까지 말했다. 다만 그조차 "이 완전 기계주도의 미래에서 완전히 빠지는 것은 선택지가 아닐 수 있다"고 덧붙인다. 회의하되 외면하지는 못한다는 것이다.

앞서 미뤄둔 이해상충도 여기에 얹힌다. 루프는 반복 구조라 필연적으로 토큰을 더 태우는데, 그 토큰을 파는 벤더의 실세들이 이 방식을 권장한다. 토큰 소비 자체를 미덕처럼 부추긴다는 비판이 나오는 이유다. 벤더의 권유는 "~라고 밝혔다"의 거리를 두고 받아들이는 편이 안전하다.

그럼에도 지지와 회의가 공통으로 수렴하는 지점이 있다. 기계가 산출물을 거부할 수 있는(테스트·린트로 판별 가능한) 작업에서만 루프가 안전하다는 것이다. CI 실패 분류, 의존성 업데이트, 린트 수정처럼 통과·실패가 또렷한 일은 적합하고, 아키텍처 재작성이나 인증·결제 로직, 프로덕션 배포처럼 '완료'가 주관적인 일은 부적합으로 갈린다. 루프를 어디에 걸 수 있고 어디엔 걸면 안 되는지의 경계가, 결국 검증 가능성에서 그어진다.

루프의 청구서

비용은 회의론이 아니라 현실이다. 오스마니 본인이 원문에서 "나는 회의적이며, 토큰 비용에 반드시 주의해야 한다"고 못박는다. 토큰이 풍족한지 부족한지에 따라 사용 패턴이 크게 달라지기 때문이다. 특히 작성-검증을 분리하고 서브에이전트를 여럿 돌리는 구조는 토큰을 더 태운다. 실무 정리에 따르면 에이전트의 토큰 소비는 표준 채팅 대비 약 4배, 멀티에이전트는 최대 15배에 이르는 것으로 알려졌다(원 측정 조건은 명시되지 않았다). 우버(Uber)에서는 2026년 AI 예산이 소진된 뒤 일부 팀이 AI 코딩 도구 하나당 월 1,500달러까지 쓴다고 전해진다(도구별 별도 집계).

대응책의 방향은 두 갈래다. 하나는 반복당 예산 상한을 두는 것 — 앞서 본 하드 스톱의 예산 축이다. 다른 하나는 긴 컨텍스트를 싸게 처리하는 저가·롱컨텍스트 모델을 쓰는 것이다. 그런 모델의 한 예로 100만 토큰급 컨텍스트를 저가에 제공하는 딥시크(DeepSeek) 계열이 시장에 나와 있다. 다만 이는 어디까지나 시장에 존재하는 대안의 예시일 뿐, "루프의 토큰 문제를 특정 모델로 푼다"는 처방이 오스마니 원문에 있는 것은 아니다(모델별 스펙과 대응 전략은 다음 섹션에서 다룬다). 요점은 모델 선택 이전에, 루프를 얹는 순간 토큰 예산이 제품 스펙의 한 줄이 된다는 사실이다.

그래서 이것은 개인의 생산성 팁이 아니라 조직의 비용 구조 문제다. 루프 하나를 더 얹는 결정은 언제나 값을 치른다. 그 값을 성능 향상이 넘어설 때에만 정당화된다.

그래서, 무엇을 다시 설계하나

이 전환은 개발자와 기획자의 일을 동시에 바꾼다.

개발자에게 최적화 대상은 '더 영리한 프롬프트 한 문장'에서 '루프를 도는 시스템'으로 옮겨간다. 튜닝할 것이 문구가 아니라, 루프 안에 무엇을 넣고 어디에 검증 게이트와 종료조건, 예산 상한을 걸지가 된다. 작업의 최소 단위도 달라진다. "AI에게 이걸 시킨다"가 아니라 "이 목표를, 이 종료조건으로, 이 검증자가 채점하도록 돌린다"가 한 덩어리의 작업이 된다.

기획자·PM에게는 제품 스펙에 '루프 설계'라는 새 항목이 들어온다. 세 가지 질문이 곧 요구사항이 된다. 첫째, 성공을 무엇으로 측정하는가 — 기계가 판별할 수 있는 종료조건이 스펙에 적힌다. 둘째, 어디까지 자율로 돌리고 어디서 사람이 검증·승인하는가 — 무인으로 도는 구간의 경계를 기능마다 정한다. 셋째, 실패하면 어떻게 감지·중단·에스컬레이션하고 비용 상한을 두는가 — 반복 상한·진척 정지·예산 상한이 명세가 된다. 요구사항 문서의 문장이 "AI가 X를 한다"에서 "AI가 X를 시도하고, Y로 검증하며, 실패 시 Z로 중단·보고한다"로 길어지는 이유가 여기에 있다.

그리고 이 모든 재설계의 밑바탕에는 원저자의 결론이 깔려 있다. 오스마니는 무인 루프의 위험을 이렇게 요약한다 — "방치된 채 도는 루프는 방치된 채 실수를 저지르는 루프이기도 하다." 루프가 저지른 실수도 무인으로 커진다는 것이다. 더 은근한 위험은 사람 쪽에 있다. 루프가 코드를 빨리 쏟아낼수록, 존재하는 것과 내가 실제로 이해하는 것 사이의 간극이 벌어진다(이해 부채). 그리고 루프가 알아서 도는 순간, 판단을 멈추고 돌려받은 것을 그냥 받아들이고 싶은 유혹이 생긴다(인지적 항복). 오스마니의 문장은 그래서 이렇게 맺힌다 — "루프는 (당신이 이해를 가속하는지 회피하는지) 그 차이를 모른다. 당신은 안다."

결론은 무인화가 아니라 엔지니어로 남기다. 오스마니의 마지막 문장을 그대로 옮기면 이렇다 — "루프를 짜라. 단, 그저 실행 버튼을 누르는 사람이 아니라, 계속 엔지니어로 남을 사람처럼 짜라." 다음 AI 기능을 기획할 때 첫 질문은 "어떤 프롬프트를 넣을까"가 아니어야 한다. "이 루프는 무엇으로 성공을 재고, 어디서 사람이 개입하며, 실패하면 어떻게 멈추는가"여야 한다. 프롬프트는 여전히 중요하다. 다만 그것은 이제 당신이 설계하는 루프 안의 한 부품일 뿐이다.