루프 엔지니어링: 검증이 저렴한 곳에서 루프가 이깁니다

Claude Code를 만든 엔지니어 Boris Cherny는 낮 동안 세션 5~10개를 열어 두고 수백 개의 에이전트를 돌리며, 밤마다 수천 개를 돌립니다.² “저는 더 이상 Claude에 프롬프트를 쓰지 않습니다… 제 일은 루프를 쓰는 것입니다”라고 말하는 그의 영상 클립이 지난주 X에 퍼졌을 때, 대부분의 반응은 그 문장을 자율 소프트웨어 개발에 대한 예언처럼 다뤘습니다. 며칠 만에 Addy Osmani는 여기에 ‘루프 엔지니어링’이라는 이름까지 붙였습니다.⁷ 저는 그 클립의 출처가 된 대담 세 편의 전체 기록을 직접 확인했습니다. 기록이 들려주는 이야기는 훨씬 조용하며, 정작 그 조용한 버전이야말로 쌓아 올릴 가치가 있습니다. Cherny가 실제로 꼽은 루프는 하나같이 기계가 공짜로 확인할 수 있는 성공 조건을 갖고 있습니다. 무엇을 자동화할 수 있는지 결정하는 것은 루프를 짜는 능력이 아니라 검증 비용입니다. 저는 2월부터 실제 운영 환경에서 루프를 돌려 왔고, 제 로그는 이 기록과 일치합니다. 그 교훈을 호되게 가르쳐 준 두 건의 사고까지 포함해서요.

요약 / 핵심 정리

• 화제가 된 인용문은 Cherny의 Acquired Unplugged 인터뷰에서 나왔습니다. 여기서 그는 루프를 천공 카드에서 어셈블리로, 다시 고급 언어로, 그리고 프롬프트로 이어져 온 연속선상의 다음 단계로 설명합니다.¹ 그는 이 전환기에 짧은 유효기간을 붙입니다. “앞으로 몇 달, 어쩌면 올해 남은 기간 동안”이라고요.¹
• 작동 방식은 의도적으로 평범합니다. Sequoia 강연에서 Cherny는 /loop를 Claude가 cron으로 반복 작업을 예약하는 것이라고 설명합니다.² 그가 꼽은 루프들은 pull request를 돌보고, CI를 건강하게 유지하고, 30분마다 Twitter 피드백을 묶어 정리합니다.²
• 이 루프들은 전부 뒷정리 성격의 일입니다. 각각 기계가 확인할 수 있는 종료 상태를 갖습니다. CI 통과, PR 리베이스 완료, 피드백 군집화 완료. 그가 언급한 사례 중 사람 없이 기능을 만드는 루프는 하나도 없습니다.
• 루프를 작성하는 일 자체가 이미 모델 안으로 녹아들고 있습니다. Cherny는 최신 모델이 스스로 알아서 루프를 시작한다고 전하면서, 사용자가 루프를 직접 구성해야 하는 상황을 “제품 설계 문제”이자 “제가 일을 제대로 못 하고 있다는 뜻”이라고 표현합니다.⁵
• 이 유행어 밑에 남는 오래가는 기술은 따로 있습니다. 무엇을 사람 없이 자동화해도 안전한지 판단하는 능력입니다. 그 결정은 결국 검증 가능성을 따지는 판단이고, 루프 문법이 사라진 뒤에도 여러분 곁에 남습니다.

그가 실제로 한 말

모두가 공유한 그 클립은 Acquired의 라이브 인터뷰에서 나왔습니다. Cherny는 그 문장을 집안 내력으로 시작합니다. 그의 할아버지는 소련에서 천공 카드로 프로그래밍을 했고, 아버지는 어셈블리를 썼으며 “제가 Python을 쓴다고 하면 비웃었을 것”이라고요. 그다음이 널리 퍼진 대목입니다.

“이게 프로그래밍의 본질이라고 생각합니다. 추상화 수준은 언제나 올라가죠… 1년 전 제가 코딩하던 방식은 IDE에서 자동 완성의 도움을 받아 코드를 쓰는 것이었습니다. 11월에 저는 IDE를 지웠습니다. 쓰지 않고 있었으니까요… 그 시점에는 Claude를 다섯 개, 열 개쯤 병렬로 돌리고 있었고, 제 코딩이란 Claude에 프롬프트를 써서 코드를 작성하게 하는 일이었습니다. 지금은 한 단계 더 올라갔습니다… 이제 저는 Claude에 프롬프트를 쓰지 않습니다. 루프가 돌고 있습니다. 프롬프트를 쓰고 무엇을 할지 알아내는 쪽은 그 루프들이죠. 제 일은 루프를 쓰는 것입니다.”¹

Acquired Unplugged 인터뷰 전체 영상. 루프 이야기는 11:14부터 시작합니다.

전체 기록에는 있지만 어떤 클립에도 담기지 않은 대목이 둘 있습니다. 첫째, Cherny는 이 전환기의 시점을 직접 못 박습니다. 루프란 “앞으로 몇 달, 어쩌면 올해 남은 기간 동안 우리가 보게 될” 것이라고요.¹ 그는 종착지가 아니라 한 국면을 이야기하고 있습니다. 둘째, 이 논의의 출처를 좇는 분들을 위한 참고 사항입니다. 여러 화제의 게시물이 이 루프 이야기를 그의 1시간짜리 Y Combinator 팟캐스트 출연분으로 잘못 표기했습니다. 저는 해당 회차의 전체 기록을 확인했습니다. 루프에 대한 언급은 단 한 번도 없으며, 그 회차는 제품의 탄생 배경과 서브 에이전트를 다룹니다.⁶ 알맹이는 Acquired 인터뷰와 24분짜리 Sequoia 강연에 있습니다.

루프는 cron 작업입니다

작동 방식은 Sequoia 강연이 알려 주는데, 의도적으로 시시합니다.

“그냥 Claude가 cron을 써서 미래의 어느 시점에 작업을 예약하게 하는 게 전부입니다. 반복 작업이고요. 1분마다, 5분마다, 매일 돌릴 수 있습니다.”²

화제의 클립들이 빼놓은 기계적 세부 사항은 전부 Sequoia 강연에 있습니다. 루프 대목은 7:56부터입니다.

Cherny는 이런 루프를 수십 개 돌립니다. 그가 꼽은 것들은 이렇습니다. 자기 PR을 돌보는 루프(CI 수정, 자동 리베이스), CI를 건강하게 유지하는 루프(불안정한 테스트를 고칩니다), 그리고 Twitter에서 피드백을 끌어와 30분마다 군집화하는 루프.² 5월 Anthropic의 Code with Claude 행사에서 발표된 Routines는 같은 패턴을 서버 쪽으로 옮겨, 노트북을 닫아도 루프가 계속 살아 있게 합니다.² 키노트를 실시간으로 기록한 Simon Willison은 Anthropic 스스로 쓰는 표현을 남겼습니다. Routines는 “고차 프롬프트”라는 것입니다.¹² Cherny는 몇 달 전부터 /loop와 /schedule이 이 제품에서 가장 강력한 기능 두 가지라고 말해 왔습니다. 그가 제시하는 표준 입문용 예시는 PR을 돌보는 5분 주기 루프입니다.¹¹

이 패턴에는 더 투박한 조상이 있습니다. Geoffrey Huntley의 Ralph Wiggum 기법은 본인 표현으로 “Ralph는 Bash 루프”입니다. while true로 에이전트에 같은 프롬프트 파일을 영원히 먹이면서, 진행 상황은 반복 사이에 파일과 git 이력으로 남깁니다.⁹ 이제 Anthropic은 Ralph를 공식 플러그인으로 제공합니다. 에이전트가 종료하려는 시도를 가로채고, 완료 문자열이 나타나거나 반복 상한에 걸릴 때까지 프롬프트를 다시 먹입니다.⁹ The Register는 Cherny 본인이 Ralph를 쓴다는 사실을 확인해 주면서, 이 기법의 경제성이 어디로 향하는지에 대한 Huntley의 경고도 함께 인용했습니다. 에이전트 기반 코딩이 시간당 대략 10달러 수준이기 때문에, 스타트업들이 이 기법으로 기존 SaaS 사업을 복제해 더 싼 가격으로 잠식하리라는 것입니다.¹⁰ 이 계보가 중요한 이유는 이 아이디어의 실제 나이를 보여 주기 때문입니다. 루프는 컴퓨팅에서 가장 오래된 제어 구조이고, 그 구조 자체에는 새로운 구석이 전혀 없습니다.¹⁵

그가 꼽은 루프는 전부 뒷정리입니다

여기서부터가 이 논의가 건너뛴 관찰입니다. Cherny의 루프들을 다시 나열하고, 그 종료 상태를 보십시오.

각각은 기계가 확인할 수 있는 성공 조건을 갖고 있거나, 틀려도 비용이 들지 않는 결과물을 냅니다. 그가 든 사례 중에 “내가 자는 동안 기능을 만들어 둬”는 없습니다. 밤마다 수천 개의 에이전트를 돌리는 사람이 정작 자신의 개인 자동화를 CI 수리, 리베이스, 피드백 분류라고 설명합니다.

반례처럼 보이는 사례가 오히려 이 규칙을 증명합니다. Anthropic 자체 엔지니어링 팀은 에이전트 16개를 무한 루프로 2주간 돌려 Rust로 10만 줄짜리 C 컴파일러를 만들었고, 연산 비용은 약 2만 달러가 들었습니다.⁸ 컴파일러는 소프트웨어에서 가장 검증하기 쉬운 산출물입니다. 거대한 프로그램 테스트 모음이 제대로 컴파일되고 실행되거나, 그렇지 않거나 둘 중 하나니까요. 팀은 검증이 거의 공짜인 대상을 골랐습니다. 그런데도 이 실험을 진행한 Nicholas Carlini는 프로그래머가 자기 손으로 한 번도 확인하지 않은 소프트웨어를 배포하는 상황은 “실제로 우려스러운 일”이라고 썼습니다.⁸

이 분야에 ‘루프 엔지니어링’이라는 이름을 붙인 Addy Osmani의 글도 설계 쪽에서 같은 제약에 도달합니다. “사람 없이 돌아가는 루프는, 사람 없이 실수를 저지르는 루프이기도 합니다.”⁷ 그가 제안한 구조, 즉 검증자 에이전트를 따로 두어 만드는 쪽이 자기 작업을 스스로 채점하지 못하게 하는 방식은, 자연적으로 생기지 않는 저렴한 검증을 인위적으로 만들어 내려는 시도입니다.⁷

제 루프들이 제게 가르쳐 준 것

저는 2월에 밤새 돌아가는 에이전트 시스템에 대해 글을 썼습니다. 그때만 해도 이 기법을 점잖게 부르는 이름이 여전히 심슨 가족 캐릭터에서 온 농담이었죠.¹⁶ 그 이후로 제 환경에서 살아남은 루프들은 모두 같은 모양으로 수렴했고, 실패한 루프들이 성공한 루프들보다 더 많은 걸 가르쳐 줬습니다.

살아남은 루프들은 하나같이 점검하는 모양입니다. 매일 밤 도는 루프 하나는 그날의 커밋을 읽고, 변경된 파일을 실제 URL에 대응시키고, 영향받는 페이지를 전부 불러온 뒤 로딩 시간과 함께 통과/실패를 보고합니다. 보안 루프 하나는 밤새 엔드포인트를 지켜보고 아침 브리핑을 씁니다. 크롤 루프 하나는 제 사이트들 전반의 Googlebot과 Bingbot 활동을 읽고 색인 상태의 변화를 보고합니다. 이 중 무언가를 만들어 내는 루프는 하나도 없습니다. 각각은 관찰하고, 기대 상태와 비교하고, 보고합니다. 하나가 오작동해도 비용은 철 지난 보고서 한 장이지, 망가진 제품이 아닙니다. 아침에 읽는 데 몇 분이면 되는 이유는 결과물이 항목마다 둘 중 하나이기 때문입니다. 통과, 실패, 여기를 보라.

실패한 쪽은 행동하는 루프들이었습니다. 병렬 에이전트를 위해 git worktree를 자동으로 만들어 주는 격리 기능은, 자신이 없어도 된다고 판단한 임시 디렉터리를 두 번이나 지워 버렸습니다. 그 자동화의 폭발 반경 안에는 자기가 만들지도 않았고 이해하지도 못한 파일들이 들어 있었습니다. 예약된 캐시 비우기 작업 하나는 배포와의 순서가 어긋난 채 실행됐고, 그 결과 검색 크롤러들이 11시간 동안 멀쩡히 존재하는 페이지에 대해 404를 받았습니다. 원본 서버가 대체 응답을 내놓기도 전에 정상적으로 캐시돼 있던 응답을 비워 버렸기 때문입니다.¹⁶ 둘 다 모델이 나빠서 생긴 실패가 아닙니다. 둘 다 제가 선행 조건을 확정하지 않은 루프에 쓰기 권한을 준 탓입니다. 이제는 각각에 안전장치가 붙었습니다. worktree 자동화는 아예 차단했고, 캐시 비우기는 배포 검증을 통과한 뒤에만 실행됩니다. 여기서 뽑아낸 일반 규칙은 이렇습니다. 읽기만 하는 루프에는 일정이 필요하지만, 쓰는 루프에는 일정을 얻기 전에 순서 보장과 폭발 반경 제한이 먼저 필요합니다.

이 규칙은 사람들이 가장 믿기 어려워하는 Cherny 방식의 한 대목도 설명해 줍니다. “사실 지금은 제 작업 대부분을 휴대폰으로 합니다.” Claude 앱의 코드 탭으로 세션을 돌리면서 그가 한 말입니다.² 휴대폰은 코드를 검토하기에는 최악의 장소지만, 통과/실패 보고서를 읽기에는 충분히 좋은 장소입니다. 휴대폰 이야기는 사실 검증에 대한 이야기를 다르게 표현한 것입니다. 그의 루프들은 한눈에 승인하거나 반려할 수 있을 만큼 읽기 쉬운 결과를 내놓는데, 이는 루프가 돌기 전에 성공 조건을 먼저 설계해 뒀을 때만 가능한 일입니다.

검증 비용 사다리

이 주장이 맞다면, 무엇을 자동화할지 고르는 일은 질문 하나로 줄어듭니다. 결과를 누가 검증하며, 그 검증에는 얼마가 드는가? 어떤 작업에 일정을 붙이기 전에 제가 쓰는 사다리는 이렇습니다.

결정을 좌우하는 것은 두 번째 열이고, 거기에 작업 난이도는 등장하지 않습니다. 검증자가 공짜인 어려운 작업(불안정한 테스트)이, 검증이 비싼 쉬운 작업(사람이 승인해야 하는 한 줄짜리 문구 수정)보다 먼저 자동화됩니다. Cherny의 루프들, Anthropic의 컴파일러, 제 살아남은 루프들은 모두 이 사다리의 위쪽 절반에 앉아 있습니다. 반면 화제가 된 논평들은 아래쪽 절반을 전제로 삼았습니다.

이 사다리를 통과하는 모양은 규모와 무관하게 하나의 감독자 패턴처럼 보입니다.

일정을 얻을 자격이 있는 루프의 해부도. 검증자를 굵게 그린 이유는 그것이 하중을 지탱하는 상자이기 때문입니다. 검증자를 빼도 루프는 여전히 돌지만, 그 루프가 무슨 일을 했는지는 아무도 모릅니다.

돌릴 가치가 있는 가장 작은 루프는 읽기 전용이고, 스스로 검증하며, 한눈에 읽힙니다. 그래서 오늘 당장 써도 안전하고 내일부터는 지켜보기 지루해집니다.

# Nightly site check: observes and reports, never edits.
# Run it under a permission mode that blocks writes outside reports/.
while true; do
  claude -p "Read today's commits. For each changed file that maps to a live
    page, fetch the staging URL and confirm it returns 200 and renders its
    headline. Append PASS or FAIL per page, with the reason, to
    reports/site-check-$(date +%F).md. Write nothing outside reports/."
  sleep 86400
done

Claude Code 안에서라면 같은 루프가 한 줄입니다. /loop 24h 뒤에 지시문을 붙이면 끝입니다. 승격은 나중 일입니다. 보고서가 한 달 동안 지루했다면, 그때 비로소 그 루프는 사다리의 다음 칸을 고려해 볼 자격을 얻습니다. 그전에는 아닙니다.

남는 일

Sequoia 강연에서 가장 기묘한 대목은 자신이 낳은 유행어를 스스로 허무는 부분입니다. Cherny는 최신 모델들이 시키지 않아도 루프를 시작하기 시작했다고 말합니다. 그가 데이터 조회를 요청하면, 모델이 그 데이터가 시간에 따라 변한다는 점을 알아채고, 30분마다 도는 정기 보고서를 제안하고, 그 보고서를 Slack에 알아서 연결한다는 것입니다.⁵ 그의 결론은 이렇습니다. “도구를 더 잘 쥐는 법을 알아내는 건 사용자의 몫이 아닙니다… 사실은 제품 설계 문제이고, 제가 일을 제대로 못 하고 있는 것입니다.”⁵ X에서 회의론자들이 제기한 무한 후퇴 논증, 즉 오늘은 사람이 루프를 쓰지만 내일은 모델이 루프를 쓴다는 지적은 알고 보니 Anthropic의 로드맵이며, 이 유행어의 당사자가 직접 인정한 내용입니다.

그는 한 걸음 더 나아갑니다. “모델이 좋아지면서 하네스는 어느 정도 덜 중요해집니다.” 정렬이 개선될수록 권한 모드, 프롬프트 주입 방어, 사람이 개입하는 확인 지점이 흐려질 것이라는 예측입니다.³ 저는 이 거래의 절반에 대해 반대편에 서겠습니다. 안전을 위한 발판은 줄어들지도 모릅니다. 하지만 조율을 위한 발판은 일 그 자체가 되어 가고 있으며, 이는 그의 설명에서도 그대로 드러납니다. Anthropic 엔지니어들의 에이전트는 주인이 일하는 동안 Slack으로 서로 조율하고, “회사 어디에도 사람이 직접 쓴 코드가 더는 없습니다. SQL은 전부 모델이 씁니다.”⁴ 그 에이전트들이 무엇을 건드려도 되는지, 무엇을 완료로 볼지, 둘이 서로 어긋날 때 무슨 일이 벌어지는지는 누군가가 결정합니다. 그 결정 층위가 바로 진짜 에이전트 인터페이스이고, cron은 그중 쉬운 부분입니다.

그래서 오래가는 기술은 루프 문법이 아닙니다. 그건 모델이 이미 흡수하고 있습니다. 프롬프트 작성도 아닙니다. 그건 루프가 먼저 흡수했습니다. 오래가는 기술은 그 둘 아래에 깔린 판단입니다. 무엇을 사람 없이 자동화해도 안전한지 결정하는 일 말입니다. 그 결정은 언제나 검증 비용에 대한 질문입니다. CI 수리가 가장 먼저 자동화된 이유는 테스트 스위트가 이미 검증자였기 때문입니다. 피드백 군집화가 자동화된 이유는 틀려도 비용이 없기 때문입니다. 기능 개발이 버티는 이유는 검증에 여전히 사람이 diff를 읽는 비용이 들기 때문이며, Hacker News의 한 시니어 엔지니어는 여기서 생기는 함정을 명료하게 짚었습니다. 이 도구를 몰고 가려면 숙련된 판단력이 필요한데, 이 도구를 쓰면 바로 그 판단력이 깎여 나간다는 것입니다.¹⁴

Casey Newton이 Cherny와 진행한 Platformer 인터뷰는 “소프트웨어 엔지니어의 끝을 말하는 Claude Code의 창시자”라는 제목으로 실렸습니다. 이 인터뷰에서 Cherny는 ‘소프트웨어 엔지니어’라는 직함이 올해 안에 ‘빌더’ 같은 무언가로 녹아드는 한편, 에이전트를 통해 코드를 쓰는 사람의 수는 100배로 늘어날 것이라고 예측합니다.¹³ 그 전망에서 빌더란 루프를 고르는 사람입니다. 잘 고른다는 것은 아무것도 실행되기 전에 그것이 제대로 됐는지 어떻게 알 것인지를 먼저 알고 있다는 뜻입니다.

핵심 정리

코딩 에이전트를 돌리는 엔지니어에게: - 자동화 후보는 구미가 당기는 정도가 아니라 검증 비용을 기준으로 심사하십시오. CI 수리, 리베이스, 모니터링, 보고서 생성은 오늘 당장 공짜 검증자를 갖고 있습니다. 이것부터 자동화하십시오. - 읽기와 쓰기를 갈라서 적용하십시오. 읽기 전용 루프에는 일정만 있으면 되지만, 쓰기 권한이 있는 루프는 사람 없이 돌기 전에 명시적인 순서 제약과 폭발 반경 제한이 필요합니다. - 루프보다 보고서를 먼저 설계하십시오. 루프의 결과물을 휴대폰에서 10초 안에 반려할 수 없다면, 그 루프는 밤에 돌릴 준비가 되지 않은 것입니다.

팀 리드에게: - 유용한 병렬성의 상한은 에이전트 수가 아니라 여러분의 검토 대역폭입니다. 그 상한을 넘겨 에이전트를 늘리면 처리량이 아니라 검토되지 않은 병합이 늘어납니다. - 만드는 쪽과 확인하는 쪽을 분리하십시오. 자기 작업을 자기가 검증하는 에이전트는 정확하다고 주장할 뿐이지만, 다른 시야를 가진 별도의 검증자는 적어도 그 주장을 잡아낼 가능성이 있습니다.

도구를 만드는 사람에게: - Cherny는 사용자가 루프를 직접 구성해야 하는 상황을 제품 설계 실패라고 부르며, 모델들은 이미 스스로 루프를 시작하고 있습니다.⁵ 루프 작성 UX를 만든다는 것은 모델 공급자가 흡수하려는 층위를 겨냥해 짓는다는 뜻입니다. 더 오래 살아남을 표면은 검증입니다. 근거, 실행 기록, 그리고 받아들이고 반려하는 조작감 말입니다.

FAQ

참고 자료