Executive Summary

2026년 6월 2일, 클로드 코드를 만든 보리스 체르니가 한 인터뷰에서 이렇게 말했습니다. "나는 더 이상 클로드에게 프롬프트를 치지 않는다. 돌아가는 루프들이 있고, 클로드에게 프롬프트를 던지며 무엇을 할지 정하는 건 그 루프들이다. 내 일은 루프를 짜는 것이다." 이 한 문장이 며칠 만에 개발자 커뮤니티를 통과하며 '루프 엔지니어링(Loop Engineering)'이라는 이름을 얻었습니다. 이 글은 그 전환이 무엇이고, 무엇이 그것을 신뢰할 만하게 만드는지를 봅니다.

전환의 핵심은 사람의 자리가 바뀌는 데 있습니다. 프롬프트를 직접 치던 '조작자'에서, 에이전트에게 프롬프트를 던지는 시스템을 짜는 '설계자'로 옮겨갑니다. 체르니의 경우 최근 30일간 자신의 코드 기여 100%를 클로드 코드가 작성했고(259개 PR), 그가 속한 팀의 엔지니어 1인당 하루 머지 수는 200% 늘었습니다. 다만 루프가 혼자 돌수록 위험도 함께 자랍니다. 자기가 쓴 결과를 자기가 채점하면, 에이전트는 자기 답에 동의하며 무한히 반복하는 기계가 됩니다.

그래서 자율 루프를 신뢰하게 만드는 건 더 똑똑한 모델이 아니라 루프 밖에 쌓이는 두 가지 데이터 장치입니다. 하나는 완료를 따로 판정하는 검증자, 다른 하나는 어제의 루프가 배운 것을 오늘로 넘기는 영속 메모리입니다. 이 글은 이 두 장치가 왜 안전판인지를 따라갑니다.

주요 수치

출처: WorkOS, The New Stack

네 숫자가 이 전환의 무게를 보여 줍니다. 한 사람의 기여가 거의 전부 에이전트로 작성되고, 팀의 처리량이 배로 뛰고, 공개 코드의 상당 부분에 한 도구의 흔적이 남고, 새 사람이 합류하는 시간이 며칠로 줄었습니다.

100%

체르니의 코드 기여

최근 30일 기여 전부를 클로드 코드가 작성. 259개 PR

+200%

엔지니어 생산성

앤트로픽 엔지니어 1인당 하루 머지 수 증가

~4%

공개 커밋 점유율

공개 깃허브 커밋 중 클로드 코드가 남긴 비중

~2일

신규 온보딩

새 엔지니어 적응 기간이 수 주에서 약 이틀로

1

프롬프트를 치지 않는 개발자

보리스 체르니는 앤트로픽에서 클로드 코드를 이끄는 사람입니다. 클로드 코드는 그가 2024년 가을 사이드 프로젝트로 시작한 코딩 에이전트입니다. 그런 그가 2026년 6월 2일 한 인터뷰에서 자기 작업 방식이 또 한 단계 넘어갔다고 말했습니다. 더 이상 클로드에게 직접 프롬프트를 치지 않고, 루프들이 돌면서 클로드에게 프롬프트를 던지고 무엇을 할지 정한다는 것입니다. 그러면서 자기 일을 한 문장으로 요약했습니다. "내 일은 루프를 짜는 것이다."

체르니는 이 변화를 세 단계로 설명합니다. 처음에는 자동완성의 도움을 받으며 코드를 손으로 썼습니다. 다음에는 클로드 세션을 다섯에서 열 개씩 동시에 띄워 놓고 각각에 수동으로 프롬프트를 넣었습니다. 그리고 지금은 루프가 프롬프트를 대신 건넵니다. 수백 개의 에이전트가 깃허브와 슬랙, 트위터를 읽으며 무엇을 만들지를 스스로 정합니다. 사람은 그 안에서 입력하는 역할이 아니라, 루프가 돌아가는 모습을 지켜보는 역할로 물러납니다.

개발 방식의 세 단계 — 손코딩에서 루프 설계까지 1단계 · 손코딩 자동완성의 도움을 받아 코드를 직접 작성 사람이 모든 줄을 친다 2단계 · 병렬 프롬프트 세션 5~10개를 동시에 각각 수동으로 지시 사람이 프롬프트를 친다 3단계 · 루프 설계 루프가 에이전트에게 프롬프트를 던진다 사람은 루프를 짠다 추상화 수준이 한 칸씩 올라가며, 사람의 손이 닿는 지점이 코드에서 루프로 이동한다
▲ 보리스 체르니가 설명한 개발 방식의 세 단계. 사람의 역할이 코드 작성에서 루프 설계로 옮겨간다. | 페블러스 원본 도식

말로 끝난 선언이 아니었습니다. 체르니는 2025년 11월에 통합개발환경(IDE)을 삭제한 뒤 한 번도 다시 열지 않았다고 밝혔습니다. 최근 30일 동안 그의 코드 기여 100%는 클로드 코드가 작성했고, 그 분량은 259개의 풀 리퀘스트였습니다. 그가 속한 팀에서는 코드의 90% 이상이 클로드 코드로 작성되고, 엔지니어 1인당 하루 머지 수가 200% 늘었으며, 새 엔지니어의 적응 기간이 수 주에서 약 이틀로 짧아졌습니다. 공개 깃허브 커밋의 약 4%에 이 도구의 흔적이 남는다는 추정도 있습니다.

체르니의 발언은 며칠 만에 커뮤니티에서 이름을 얻었습니다. 6월 8일 개발자 피터 슈타인베르거가 X에 "이제 코딩 에이전트에게 프롬프트를 치지 말고, 에이전트에게 프롬프트를 던지는 루프를 설계하라"고 적었고, 이 글은 650만 회 넘게 읽혔습니다. 비슷한 시기에 구글 클라우드의 애디 오스마니가 같은 현상을 '루프 엔지니어링'이라 부르며 정리했습니다. 그는 "AI에서 가치의 단위가 응답에서 궤적으로 옮겨갔다"고 요약했습니다. 한 번의 답이 아니라, 여러 번의 시도가 쌓여 만드는 경로가 중요해졌다는 뜻입니다.

2

루프의 해부 — 메이커와 체커

그렇다면 루프란 무엇일까요. 루프 엔지니어링에서 말하는 루프는 스스로 할 일을 찾고, 실행하고, 결과를 검증하고, 배운 것을 기록한 다음, 다음 할 일을 정하는 자동 순환입니다. 사람이 매번 프롬프트를 넣어 주지 않아도 이 순환이 굴러갑니다. 오스마니와 실무자들은 이 루프를 다섯 개의 부품으로 나눕니다. 완료를 판단하는 목표 조건, 결과를 만드는 메이커, 결과를 검사하는 체커, 학습을 이월하는 메모리, 그리고 반복 횟수와 비용을 제한하는 토큰 경제입니다.

  • • 목표 조건(Goal): 루프가 언제 멈춰도 되는지를 정하는 완료 기준. 클로드 코드는 2026년 5월 추가된 /goal 명령으로 이 조건을 설정합니다.
  • • 메이커(Maker): 실제 코드나 결과물을 만들어 내는 에이전트.
  • • 체커(Checker): 메이커와 다른 모델이 결과를 검사하는 자리. 숙제를 제출한 사람이 직접 채점하지 않는다는 원칙입니다.
  • • 메모리(Memory): 이번 루프가 배운 것을 다음 루프로 넘기는 영속 파일.
  • • 토큰 경제(Token economics): 비용 한도와 반복 횟수의 상한. 단일 에이전트는 일반 채팅의 약 4배, 멀티 에이전트는 약 15배의 토큰을 씁니다.

이 가운데 가장 자주 빠뜨리는 부품이 체커입니다. 자기가 쓴 코드를 자기가 검증하면 관대해지기 때문입니다. 자기 답에 동의할 이유는 늘 충분합니다. 그래서 메이커와 체커를 다른 모델 인스턴스, 다른 지시문으로 분리합니다. 한 개발자는 X에서 이렇게 표현했습니다. "루프를 설계하는 건 절반일 뿐이다. 나머지 절반은 루프 안에 '아니오'라고 말할 수 있는 무언가를 넣는 것이다. 테스트든, 타입 체크든, 진짜 에러든. 밀어내는 것이 없는 루프는 에이전트가 자기 답에 계속 동의하는 기계일 뿐이다."

자율 루프의 한 바퀴 — 발견에서 기억까지 ① 발견 할 일을 찾는다 ② 메이커 결과를 만든다 ③ 체커 다른 모델이 검증 ④ 기억 메모리에 기록 목표 조건을 만족할 때까지 반복 체커가 '아니오'라고 말할 수 있어야 루프가 자기 답에 갇히지 않는다 사람은 이 순환 밖에서 목표 조건과 메모리를 설계한다
▲ 자율 루프의 한 바퀴. 메이커가 만들고, 별도 모델인 체커가 검증하고, 결과를 메모리에 남긴 뒤 목표 조건을 만족할 때까지 반복한다. | 페블러스 원본 도식

핵심: 루프의 진짜 부품은 모델이 아니라 그 둘레의 장치입니다. 무엇을 완료로 볼지 정하는 목표 조건, 결과에 '아니오'라고 말하는 체커, 학습을 남기는 메모리. 이 셋이 빠지면 자율 루프는 자기 답을 반복하는 기계로 미끄러집니다.

3

신뢰의 두 기둥 — 검증자와 메모리

여기서부터가 페블러스가 이 사건을 읽는 지점입니다. 자율 루프를 신뢰하게 만드는 것은 더 좋은 모델이 아니라, 루프 밖에 쌓이는 두 가지 데이터 장치입니다. 하나는 완료를 판정하는 별도의 검증자, 다른 하나는 학습을 이월하는 영속 메모리입니다. 둘 다 모델의 가중치 안이 아니라 루프 바깥의 파일과 게이트에 존재한다는 점이 중요합니다.

3.1완료를 판정하는 별도의 검증자

첫 번째 기둥은 검증자입니다. 루프가 스스로 "다 됐다"고 선언하지 못하게 막는 장치입니다. 클로드 코드에서 /goal로 완료 조건을 걸어 두면, 매 턴마다 별도의 빠른 모델이 그 조건이 충족됐는지를 독립적으로 채점합니다. 만든 에이전트와 채점하는 에이전트가 다른 모델, 다른 지시문이라는 점이 핵심입니다. 검증자가 없는 루프는 자기 결과에 동의하며 도는 기계가 되고, 검증자가 있는 루프는 '완료'라는 판정 자체가 하나의 데이터가 됩니다. 그 판정 데이터가 루프를 믿을 수 있게 만듭니다.

3.2학습을 이월하는 영속 메모리

두 번째 기둥은 메모리입니다. 에이전트가 같은 실수를 매 세션 반복하지 않게 하려면, 그 교정을 파일에 적어 두고 다음 세션이 시작할 때 자동으로 읽게 해야 합니다. 클로드 코드에서는 이 역할을 CLAUDE.md라는 파일이 맡습니다. 체르니의 표현으로는 "어제의 루프가 배운 것이 오늘의 루프로 전달된다"는 것입니다. 학습이 모델 가중치에 새겨지는 대신 외부 파일에 기록되므로, 사람이 읽고 고치고 버전을 관리할 수 있습니다. 루프의 신뢰 자산이 모델 안이 아니라 파일 시스템에 쌓인다는 뜻입니다.

루프 밖에 쌓이는 두 데이터 장치가 신뢰를 떠받친다 신뢰할 수 있는 자율 루프 ① 검증자 (Checker) 완료를 따로 판정하는 별도 모델 "완료" 판정이 곧 데이터가 된다 /goal — 매 턴 독립 채점 ② 메모리 (Memory) 학습을 이월하는 영속 파일 어제의 루프가 오늘로 전달된다 CLAUDE.md — 파일 시스템에 축적 둘 다 모델 가중치가 아니라 루프 밖의 데이터에 존재한다
▲ 자율 루프의 신뢰를 떠받치는 두 기둥. 검증자와 메모리는 모두 모델 안이 아니라 루프 밖의 데이터로 존재한다. | 페블러스 원본 도식

핵심 명제: 두 기둥의 공통점은 모델 바깥에 있다는 것입니다. 검증자는 완료라는 판정을 데이터로 남기고, 메모리는 학습을 파일로 남깁니다. 자율성이 커질수록 신뢰의 무게중심은 모델에서 루프 밖에 쌓인 데이터로 옮겨갑니다.

4

조작자에서 설계자로

그래서 사람의 역할이 옮겨갑니다. 프롬프트를 한 줄씩 치던 조작자에서, 루프 전체를 짜는 설계자로 넘어갑니다. 설계자가 정하는 것은 개별 답이 아니라 루프의 규칙입니다. 무엇을 완료로 볼지, 누가 그 완료를 검증할지, 무엇을 다음으로 넘길지. 같은 인터뷰에서 체르니는 그렇다면 사람에게 끝까지 남는 일이 무엇이냐는 질문에 "가치(values)"라고 답했습니다. 무엇을 만들 가치가 있는지, 어떤 결과를 좋은 것으로 부를지를 정하는 일은 여전히 사람의 몫이라는 뜻입니다.

보리스 체르니가 WorkOS × Acquired 인터뷰에서 '내 일은 루프를 짜는 것이다'를 발언하는 장면
▲ 2026년 6월 2일, WorkOS × Acquired Unplugged 행사에서 클로드 코드 개발자 보리스 체르니. 이 인터뷰에서 "내 일은 루프를 짜는 것이다"라는 발언이 나왔다. | Source: WorkOS × Acquired (YouTube)

데이터를 다루는 조직에게 이 전환은 실무 질문 하나로 좁혀집니다. 에이전트를 도입할 때 먼저 따져야 할 것은 "어느 모델이 더 좋은가"가 아닙니다. "완료를 판정할 기준 데이터가 있는가", 그리고 "지난 세션의 실패에서 배운 것이 다음 세션으로 전달되는 구조가 있는가"입니다. 이 두 가지가 갖춰지지 않으면, 아무리 좋은 모델을 얹어도 루프는 자기 답에 동의하며 돌거나 같은 실수를 반복합니다. 모델은 빌려 올 수 있지만, 검증 기준과 학습 기록은 조직이 스스로 쌓아야 하는 데이터입니다.

Editor's Note: 페블러스가 데이터를 AI-Ready 상태로 만드는 일에 집중해 온 이유도 여기에 닿습니다. 에이전트가 조언을 넘어 스스로 일하기 시작하면, 그 일을 믿을 수 있게 만드는 건 모델이 아니라 루프 밖에 쌓인 데이터입니다. 무엇을 완료로 볼지 판정하는 기준과, 어제의 실패를 오늘로 전하는 기록. 루프 엔지니어링이 던지는 질문은 결국 데이터의 질문입니다. 에이전트에게 무엇을 맡길지 정하기 전에, 그 판단을 떠받칠 데이터부터 믿을 수 있게 만들어 두었는지 묻게 됩니다.

R

참고문헌

1차 자료 — 발언·에세이

업계·보도·해설