2년 동안 AI 에이전트에서 더 나은 결과를 얻으려면 더 좋은 프롬프트를 작성하는 것만이 방법이었다.
그 시대는 조용히 막을 내리고 있다. 세계 최고의 엔지니어들은 한참 전에 프롬프트 작성을 멈추고 루프 작성을 시작했다. 즉, 에이전트에 프롬프트를 입력하고, 결과를 확인하고, 작업이 완료될 때까지 계속 실행하는 시스템을 말이다.
Karpathy 의 자동화 스크립트는 그가 20년간 수동으로 튜닝하면서 놓쳤던 20개의 최적화를 발견했다. Claude Code 를 만든 Boris Cherny 는 올해 단 한 줄의 코드도 작성하지 않았다. Anthropic 의 엔지니어들은 이제 2024년보다 하루에 거의 8배 더 많은 코드를 병합하고 있다.
그 누구도 더 똑똑한 내용을 입력한 것이 아니다. 그들은 아예 입력하는 것을 멈췄다.
여기서 루프가 정확히 무엇인지, 언제 필요하고 언제 필요하지 않은지, 그리고 첫 번째 루프를 구축하는 방법을 설명한다.
사람이 잠든 사이 700번의 실험
2026년 3월. Andrej Karpathy 가 세 개의 파일을 GitHub 에 푸시한다. 약 630줄의 코드였다.
한 파일에는 모델이, 다른 파일에는 점수 평가가, 그리고 나머지 파일에는 에이전트가 탐색할 것과 건드리지 말아야 할 것을 지시하는 내용이 담겼다. 에이전트는 훈련 파일만 건드릴 수 있었다. 그 외에는 아무것도 할 수 없었다.
사이클은 의도적으로 지루하게 설계되었다. 코드를 읽고, 변경을 제안하고, 5분 동안 훈련하고, 점수가 향상되었는지 확인하고, 향상되었다면 변경을 유지하고, 그렇지 않으면 되돌린 후, 다시 시작하는 것이 전부였다.
그는 이미 20년간 수동으로 튜닝한 모델을 대상으로 삼았다. 그리고 이틀 동안 실행했다.
700번의 실험을 실행했다. 20개의 개선점을 찾아냈다. 그중 하나는 어텐션 메커니즘에서 누락된 스칼라 승수(scalar multiplier)였는데, 미묘해서 어떤 린터(linter)도 절대 잡아내지 못할 버그였지만, 꼼꼼한 엔지니어라면 발견했을 수도 있었고 실제로는 발견하지 못한 그런 종류의 것이었다.
Shopify 의 CEO는 같은 방법을 내부 모델에 하룻밤 동안 적용했다. 그는 이전 모델의 절반 크기 모델에서 19%의 품질 향상을 얻은 채로 잠에서 깼다.
핵심 통찰은 "AI 가 더 똑똑해졌다"는 것이 아니다. 인간은 12번째 실험 후면 지친다. 하지만 루프는 전혀 지치지 않는다.
루프는 스케줄에 맞춰 실행되는 프롬프트가 아니다
대부분의 사람들은 "루프"라는 말을 듣고 cron 작업을 떠올린다. 하지만 그것은 핵심을 완전히 놓치는 것이다.
프롬프트는 하나의 명령어다. 루프는 AI 가 목표에 도달할 때까지 누군가 앉아서 지켜보지 않아도 계속해서 작업을 수행하는 목표 그 자체다. AI 는 스스로 계획하고, 실행하고, 결과를 검증하고, 그 결과를 다시 입력으로 넣고, 반복한다.
다섯 단계: 발견(discover), 계획(plan), 실행(execute), 검증(verify), 반복(iterate). 이 중 세 단계가 실제 작업을 수행한다.
검증자(verifier)는 루프의 핵심이다. 출력에 대한 진정한 게이트(gate)가 없다면, 그것은 루프가 아니라 에이전트가 자신의 숙제를 영원히 채점하는 것에 불과하다. 게이트는 통과하거나 실패하는 테스트, 컴파일되거나 충돌하는 빌드, 0 또는 0이 아닌 값을 반환하는 린터와 같은 것이다. 의견을 가진 두 번째 에이전트가 아니다.
상태(state)는 루프가 학습할 수 있게 만드는 요소다. 별도의 파일, Linear 보드, 프로젝트 로그 등 대화 외부에 무엇을 시도했고 무엇이 실패했는지 기록하는 공간이 있어야 한다. 다음날의 실행은 처음부터 다시 시작하는 대신 이전 기록을 이어받아 진행된다.
중단 조건(stop condition)은 루프를 정상적으로 유지한다. 모든 실제 루프에는 두 가지 종료 지점이 있다: 목표 달성 또는 하드 캡(hard cap) 발동. 이것을 생략하면 밤새 아무것도 얻지 못하고 실행되는 기계를 만든 셈이다.
이 세 가지 중 하나라도 빠지면 루프를 구축한 것이 아니다. 비싼 스크립트를 만든 것에 불과하다.
루프를 구축하기 전에 확인해야 할 네 가지 조건
루프는 다음 네 가지 조건이 동시에 충족될 때만 그 비용을 정당화한다. 하나라도 빠지면 설정 비용이 얻는 이익보다 더 크다.
- 작업이 적어도 주 1회 이상 반복된다. 그보다 적으면 설정 비용을 상쇄할 수 없다.
- 작업을 자동으로 실패 처리할 수 있는 무언가가 있어야 한다. 테스트, 타입 검사, 린터, 빌드 등.
- 토큰 예산이 낭비를 감당할 수 있어야 한다. 루프는 컨텍스트를 다시 읽고, 재시도하고, 탐색한다.
- 에이전트가 시니어 엔지니어 수준의 도구를 가지고 있어야 한다. 로그, 재현 환경, 자신이 작성한 코드를 실행하고 무엇이 잘못되었는지 확인할 수 있는 능력.
솔직한 부분, 즉 루프를 판매하는 사람이라면 절대 말하지 않을 부분은 이것이다: 대부분의 사람들은 아직 무거운 버전이 필요하지 않다. 소비자 요금제로 중요한 작업에 대해 밤새 검증 루프를 실행하려고 하면, 생산성 향상이 오기도 전에 토큰 비용 청구서가 먼저 도착한다.
좋은 첫 번째 루프는 지루한 것들이다. CI 분류. 의존성 업데이트. 린트 및 수정 작업. 불안정한 테스트 재현. 강력한 테스트가 이미 갖춰진 코드베이스에서 이슈에서 PR 초안 작성까지.
나쁜 첫 번째 루프는 흥미로운 것들이다. 아키텍처 재작성. 인증 코드. 결제. "완료"가 판단에 의존적이고 인간이 여전히 검토해야 하는 모든 것.
루프를 실제로 만드는 다섯 가지 구성 요소
모든 실제 루프는 동일한 다섯 가지 요소로 조립된다. Claude Code 와 Codex 는 이제 이 모든 기능을 제공한다.
첫 번째는 자동화(automation)다. 심장박동과 같은 역할이다. 스케줄이나 이벤트에 따라 루프를 실행하는 무언가다. /loop 는 일정한 주기로 실행된다. /goal 은 사용자가 정의한 조건이 실제로 충족될 때까지 계속 실행된다. 심장박동이 없으면 루프는 한 번 실행하고 잊어버리는 스크립트에 불과하다.
두 번째는 스킬(skill)이다. 에이전트가 실행할 때마다 읽는 claude-md 파일에 저장된 프로젝트 지식이다. 이것이 없으면 루프는 매 사이클마다 컨텍스트를 처음부터 다시 유추한다. 있으면 의도가 누적된다. 루프는 사용자의 코딩 규칙, 빌드 단계, 3개월 전 사건 때문에 절대 하지 말아야 할 것을 알게 된다.
세 번째는 하위 에이전트(sub-agents)다. 제작자(maker)와 검사자(checker)는 동일한 모델이어서는 안 된다. 코드를 작성한 모델은 자신의 작업을 너무 관대하게 평가한다. 기사를 작성한 모델은 자신의 약한 부분을 놓친다. 작성자는 빠르고 저렴하게. 검토자는 느리고 엄격하게. 이 분리가 품질의 대부분을 결정한다.
네 번째는 커넥터(connectors)다. 루프는 풀 리퀘스트를 열고, 티켓을 닫고, CI 가 통과하면 채널에 알린다. 이것이 "여기 제안된 수정 사항이 있습니다"라고 말하는 에이전트와 PR 이 이미 병합되었다는 보고서를 아침에 기다리고 있는 것의 차이점이다.
다섯 번째는 검증자(verifier)다. 잘못된 작업을 자동으로 실패 처리하는 테스트, 타입 검사, 또는 빌드다. 다른 모든 것은 부수적인 것이다. 이 구성 요소가 루프가 사용자에게 도움이 되는지 아니면 단지 비용만 지출하게 하는지를 결정한다.
이것들을 함께 쌓아 올리면, 진지한 팀들이 이제 대규모로 운영하는 것을 얻을 수 있다. 수십 개의 루프가 각자 하나의 좁은 작업을 담당하며, 모두가 잠든 사이에 나란히 실행된다. 한 엔지니어는 이런 방식으로 플릿 루프를 사용하여 약 6일 만에 전체 코드베이스를 한 언어에서 다른 언어로 재작성했다. 이 작업은 수동으로 하면 거의 1년이 걸렸을 작업이었다.
루프가 조용히 실패하는 경우
루프는 충돌하지 않는다. 조용히 비용을 청구한다. 언급할 가치가 있는 두 가지 실패 패턴이 있으며, 루프가 더 좋아질수록(쉬워지는 것이 아니라) 두 패턴 모두 더 악화된다.
첫 번째는 랠프 위검(Ralph Wiggum) 루프다. 엔지니어 Geoffrey Huntley 가 문서화했다. 에이전트가 너무 일찍 작업이 완료되었다고 판단하고, 절반만 완료된 작업에 대해 완료 신호를 보내면 루프는 만족한 채로 종료된다. 객관적인 게이트가 없으면 루프는 다음 날 밤에도 계속 실행되고, 계속 비용을 지출하며, 아무도 수락하지 않을 작업을 계속 생성한다.
해결책은 더 똑똑한 에이전트가 아니다. 더 멍청한 게이트다. 통과하거나 실패하는 테스트. 컴파일되거나 컴파일되지 않는 빌드. 의견이 없는 무언가.
두 번째는 더 미묘하다. 이해 부채(comprehension debt)다. 루프가 사용자가 작성하지 않은 코드를 더 빨리 전달할수록, 저장소에 포함된 내용과 사용자가 실제로 이해하는 내용 사이의 격차는 더 커진다. 순조롭게 실행되는 루프는 그 격차에 대해 복리 이자를 청구한다. 팀 내 누구도 읽어보지 않은 시스템을 디버깅해야 하는 날이 오면, 그 비용은 토큰 비용보다 훨씬 더 크다.
인지적 항복(cognitive surrender)도 함께 따른다. 루프가 스스로 실행될 때, 의견 형성을 중단하고 무엇이든 돌아오는 대로 수용하고 싶은 유혹이 생긴다. 판단력을 가지고 루프를 설계하는 것이 치료법이다. 생각을 피하기 위해 루프를 사용하는 것은 가속제가 된다. 같은 행동, 반대되는 결과.
두 사람이 동일한 루프를 구축하고 정반대의 결과를 얻을 수 있다. 한 사람은 자신이 깊이 이해하는 작업에서 더 빠르게 움직이기 위해 사용한다. 다른 사람은 작업을 전혀 이해하지 않기 위해 사용한다. 루프는 그 차이를 모른다. 하지만 당신은 안다.
열 개가 아닌 하나의 루프로 시작하라
모든 사람이 저지르는 실수는 첫날부터 전체 시스템을 구축하려는 것이다. 열 개의 루프, 대시보드, 플릿. 주말이 되면 어떤 루프가 무엇을 했는지 알 수 없어서 시스템이 붕괴된다.
하나부터 시작하라. 가장 성가신 반복 작업, 습관적으로 매일 아침 확인하는 작업을 선택하고, 그 단일 작업을 루프로 전환하라. 며칠 동안 실행해 보라. 어디서 지나치게 확장하는지 지켜보라. 어디서 놓치는지 지켜보라. 조정하라. 그런 다음 두 번째를 추가하라.
도구보다 순서가 더 중요하다. 먼저 하나의 수동 실행을 안정적으로 만드는데, 빠르게가 아니라 안정적으로 만드는 데 집중하라. 그 실행을 claude-md 스킬로 전환하라. 스킬을 객관적인 게이트와 하드 중단 조건을 가진 루프로 감싸라. 그리고 나서야, 비로소, 스케줄에 올려라. 순서를 건너뛰고, 수동으로 안정적으로 만들지 않은 것을 스케줄링하는 것은, 정확히 당신이 잠든 사이에 루프가 폭발하는 방법이다.
루프가 작동하는지 여부를 결정하는 지표는 소비된 토큰, 시도된 작업, 또는 열린 PR 이 아니다. 허용된 변경당 비용(cost per accepted change)이다. 허용된 변경 비율이 50% 미만이라면, 루프가 제거하려고 했던 검토 작업을 당신이 여전히 수행하고 있는 것이며, 루프는 손해를 보고 있는 것이다.
Karpathy 는 훈련 코드 작성을 중단했다. Cherny 는 프롬프트 작성을 중단했다. 둘 다 생각하는 것은 멈추지 않았다. 이 글에서 한 가지만 얻어간다면, 그것을 얻어가길 바란다. 루프는 지루한 95%를 처리하는 시스템이며, 당신은 실제로 위험을 수반하는 5%에 모든 집중을 유지할 수 있다.
당신은 여러 에이전트로 구성된 플릿 비용을 지불하면서 하나의 채팅 창만 사용하고 있다.
제 텔레그램 채널을 팔로우하고 구독해 주세요: https://t.me/+75nMf005jRpjMDU1
