Anthropic의 엔지니어들은 매달 8만 달러의 급여를 받습니다. 이 엔지니어들은 이제 1년 전보다 하루에 8배 더 많은 코드를 병합합니다. 모델이 더 똑똑해져서가 아닙니다. Claude에게 프롬프트를 입력하는 것을 멈추고, 대신 Claude에게 프롬프트를 입력하는 시스템을 구축하기 시작했기 때문입니다.
Anthropic에서 Claude Code를 총괄하는 Brian Cherny는 이렇게 말합니다. "저는 더 이상 Claude에게 프롬프트를 입력하지 않습니다. Claude에게 프롬프트를 입력하고 무엇을 해야 할지 결정하는 루프(loop)를 실행하고 있죠. 제 일은 루프를 작성하는 것입니다."
대부분의 개발자는 이 말을 읽고도 실제로 무엇을 의미하는지 감을 잡지 못합니다. 이 글을 다 읽을 때쯤이면 여러분은 그 의미를 이해하게 될 것이며, 이번 주말에 첫 번째 루프를 구축하는 데 필요한 모든 것을 얻게 될 것입니다.
루프란 무엇인가
프롬프트는 단일 지시 사항입니다. 루프는 AI가 목표를 달성할 때까지 계속해서 작업하는 과정입니다.
차이점은 누가 운전대를 잡느냐에 있습니다. 프롬프트를 사용하면 모든 단계를 수동으로 Claude에게 지시해야 합니다. 루프를 사용하면 목표를 한 번 정의하기만 하면 시스템이 스스로 전체 주기를 실행합니다. 작업을 찾고, 실행하고, 결과를 확인하고, 다음 단계를 결정하는 모든 과정을 여러분이 자리에 없어도 스스로 처리합니다.
1프롬프트 | 당신이 입력하고, Claude가 답하고, 다시 당신이 입력함2루프 | 시스템이 작업을 찾고, Claude가 실행하고,3 | 시스템이 결과를 확인하고, 완료될 때까지 반복함
모든 실제 루프에는 5단계가 있습니다:
1발견(Discover) | 해야 할 일을 찾음2계획(Plan) | 수행 방법을 결정함3실행(Execute) | 작업을 수행함4검증(Verify) | 목표와 비교하여 확인함5반복(Iterate) | 완료되지 않았다면? 결과를 다시 입력하고 재시도함
이 중 세 가지 단계가 실제 작업의 대부분을 수행합니다.
검증은 루프의 핵심입니다. 결과에 대한 실제 확인 과정이 없다면 그것은 루프가 아니라 에이전트가 스스로 동의하며 반복하는 것에 불과합니다. 확인은 객관적이어야 합니다. 통과하거나 실패하는 테스트, 컴파일되거나 되지 않는 빌드, 0 또는 0이 아닌 값을 반환하는 린터(linter)여야 합니다. "검토"를 요청받은 두 번째 에이전트가 되어서는 안 됩니다. 두 명의 낙관주의자가 서로 동의하는 것은 검증이 아닙니다.
상태(State)는 루프가 학습하게 만드는 요소입니다. 매번 AI는 자신이 무엇을 시도했는지 기억해야 합니다. 그렇지 않으면 똑같은 실수를 영원히 반복하게 됩니다. 실제 루프는 대화 외부에서 기록을 유지합니다. 무엇이 완료되었고, 무엇이 실패했으며, 다음은 무엇인지 기록합니다. 에이전트는 세션 사이에 내용을 잊어버리지만, 파일은 잊지 않습니다.
정지 조건(Stop condition)은 루프를 정상적으로 유지합니다. 종료 조건이 없는 루프는 성공하거나, 고장 나거나, 예산을 모두 소진할 때까지 실행됩니다. 모든 진지한 루프에는 성공과 하드 리밋(hard limit)이라는 두 가지 정지 방법이 있습니다. 이것이 없다면 여러분은 조용히 비용을 청구하는 기계를 만든 셈입니다.
무언가를 만들기 전 4가지 조건 테스트
루프는 다음 네 가지 조건이 모두 충족될 때만 비용 이상의 가치를 창출합니다. 하나라도 빠지면 수동 프롬프트로 남겨두세요.
1조건 1 | 작업이 최소 매주 반복됨2 | 매주보다 적다면 설정 비용을 회수할 수 없음34조건 2 | 잘못된 출력을 자동으로 거부할 수 있음5 | 테스트, 빌드, 린터, 타입 체크 등6 | 자동화된 관문이 없다면 모든 diff를 직접 검토해야 함78조건 3 | 에이전트가 작업을 처음부터 끝까지 수행할 수 있음9 | 작업 도중 절반을 다시 당신에게 넘기지 않아야 함1011조건 4 | 완료 여부가 객관적이며, 주관적 판단이 아님12 | 품질이 취향의 문제라면 여전히 사람이 더 잘함
좋은 첫 번째 루프 예시:
1CI 실패 분류 | 매일 밤, 실패 분류 및 수정안 작성2의존성 업데이트 | 매주, 업데이트 스캔 및 PR 생성3린트 및 수정 패스 | 모든 PR마다 스타일 수정 자동 적용4이슈를 PR 초안으로 | 테스트 커버리지가 강력한 코드베이스에서
나쁜 첫 번째 루프 예시 (사람이 직접 해야 하는 경우):
1아키텍처 재작성 | 주관적 판단 필요, 루프가 방향을 잃음2인증 또는 결제 코드 | 되돌릴 수 없는 실수는 비용이 너무 큼3프로덕션 배포 | 사람의 승인 관문이 필요함4모호한 제품 작업 | 완료 여부가 객관적이지 않음
5가지 구성 요소
모든 작동하는 루프는 5가지 부분으로 조립됩니다. Claude Code는 이 5가지를 모두 제공합니다.
1 - 자동화 (심장 박동)
이것이 루프를 단순한 일회성 실행이 아닌 실제 루프가 되게 합니다. 트리거가 일정이나 이벤트에 따라 작동하여 작업을 Claude에게 전달하고, 여러분이 일일이 확인하지 않아도 결과를 가져옵니다.
1/loop | 주기에 따라 프롬프트를 재실행2/goal | 작성한 조건이 참이 될 때까지 계속함3hooks | 에이전트 수명 주기 지점에서 명령을 실행4cron | GitHub Actions를 통해 노트북을 닫은 후에도 실행
가장 중요한 것은 /goal입니다. 별도의 작은 모델이 조건 충족 여부를 확인하므로, 코드를 작성한 에이전트가 스스로를 평가하지 않게 됩니다.
1/loop 30m /goal "test/auth의 모든 테스트가 통과하고 린트가 깨끗함."2src/auth에서 실패를 스캔하고, 수정을 작성하고, 목표가 달성되면 PR을 엽니다.
2 - 기술(Skills) (프로젝트 지식을 한 번만 작성)
기술은 매 세션마다 동일한 프로젝트 컨텍스트를 반복해서 설명하는 것을 멈추는 방법입니다. SKILL.md 파일에는 루프가 실행될 때마다 읽는 지침, 규칙, 관례가 담겨 있습니다.
기술이 없으면 루프는 매 주기마다 프로젝트 전체를 처음부터 다시 파악해야 합니다. 기술을 사용하면 의도가 축적됩니다. 관례, 빌드 단계, 이전에 잘못되었던 점들이 한 번 작성되어 영원히 읽히게 됩니다.
1skills/2 ci-triage.md - 분류 규칙, 수정 패턴, 에스컬레이션 기준3 frontend.md - Tailwind, Next.js, SEO, 접근성 규칙4 security.md - 인증 패턴, 입력 검증, 절대 수정 금지 목록5 deps.md - 업데이트 규칙, 호환성 체크, 롤백 패턴
자동화는 기술을 이름으로 호출합니다. 반복되는 작업은 아무도 업데이트하지 않는 일정 속에서 썩어가는 대신 유지 관리 가능한 상태로 유지됩니다.
3 - 하위 에이전트 (작성자와 검사자를 분리)
어떤 루프에서든 가장 유용한 구조적 요소입니다. 코드를 작성하는 에이전트와 확인하는 에이전트를 분리하세요.
코드를 작성한 모델은 자신의 작업에 대해 너무 관대하게 평가합니다. 다른 지침을 가진 두 번째 에이전트(때로는 더 강력한 모델)가 첫 번째 에이전트가 스스로 합리화했던 오류를 잡아냅니다.
1작성 에이전트 | 빠르고 저렴한 모델 - 탐색, 구현, 초안 작성2검사 에이전트 | 강력한 모델, 높은 노력 - 검토, 검증, 거부
1.claude/agents/2 explorer.md | 읽기 전용, 빠른 모델, 해야 할 일을 찾음3 implementer.md | 수정안 작성, 테스트 실행4 reviewer.md | 보안 감사, 코드 품질, 객관적 관문
하나의 모델, 세 명의 전문가. 여러분이 지켜보지 않아도 루프가 실행되며, 검증자가 존재하기 때문에 안심하고 자리를 비울 수 있습니다.
4 - 커넥터 (제안이 아닌 행동을 위해)
"여기에 수정안이 있습니다"라고 말하는 루프와, PR을 열고 티켓을 연결하며 CI가 통과되면 Slack에 알림을 보내는 루프의 차이입니다.
1GitHub | 리포지토리 읽기, 브랜치 생성, PR 오픈, 웹훅 반응2Linear | 티켓 업데이트, PR 연결, 검증 통과 시 항목 닫기3Slack | 분류 결과 게시, 에스컬레이션 시 사람에게 알림4Sentry | 실시간 알림 조사, 빈번한 문제에 대한 수정안 작성
커넥터가 없으면 루프는 자신이 무엇을 할 것인지 설명만 합니다. 커넥터가 있으면 실제로 수행합니다.
5 - 상태 파일 (에이전트는 잊지만 파일은 잊지 않습니다)
너무 단순해 보이지만 모든 작동하는 루프의 척추와 같은 부분입니다. 대화 외부의 마크다운 파일에 무엇이 완료되었고, 무엇이 실패했으며, 다음은 무엇인지 기록합니다.
1# 루프 상태 - ci-triage23## 마지막 실행42026-06-09 03:30 UTC - 7개 실패 분류됨, 3개 수정안 작성, 4개 에스컬레이션56## 진행 중7- claude/fix-auth-token-refresh - 로컬 테스트 통과, CI 대기 중89## 오늘 완료10- claude/bump-axios-1.7.4 - 병합됨, CI 통과1112## 사람에게 에스컬레이션됨13- src/billing/refund.ts - 3가지 테스트 실패, 근본 원인 불명1415## 배운 점16- 2026-06-08: Windows 러너에서 PowerShell이 TLS 문제 발생. bash 사용.17- 2026-06-07: tests/e2e/checkout은 Stripe 웹훅 시크릿 필요. 없으면 건너뜀.
내일 실행 시 이 파일을 읽고 재개합니다. 이 파일이 없으면 모든 실행이 처음부터 다시 시작됩니다.
실제 루프의 모습
CI 실패 분류는 검증이 자동화되어 있고 잘못된 출력의 위험이 낮기 때문에 가장 좋은 첫 번째 루프 중 하나입니다.
1트리거 | 매일 새벽 3시 또는 CI 실패 이벤트 발생 시2기술 | ci-triage.md3상태 읽기 | STATE.md - 어제 실패한 것, 수정된 것
루프 실행 과정:
11단계 | 커넥터를 통해 GitHub에서 CI 실패 읽기22단계 | 각각 분류: 환경 / 일시적 오류 / 버그 / 의존성 / 인프라33단계 | 수정 가능한 실패마다 워크트리를 열고 구현 에이전트 파견44단계 | 검토 에이전트가 테스트 및 보안 규칙에 따라 수정안 확인55단계 | 관문 통과 - PR 오픈 및 Linear 티켓 연결66단계 | 관문 실패 - 사람의 분류 받은 편지함으로 에스컬레이션77단계 | STATE.md 업데이트88단계 | 밤사이 요약 내용을 Slack에 게시
아침에 일어나면 Slack 메시지, 어려운 문제만 모인 분류 받은 편지함, 이미 자동화된 검토를 통과한 PR 세트를 확인하게 됩니다. 여러분은 단 한 단계도 직접 프롬프트를 입력하지 않았습니다.
비즈니스 전체에 복리로 작용하는 루프
가장 강력한 버전은 하나의 루프가 아닙니다. 여러 루프가 공유 아티팩트 시스템에 기록하여 서로에게서 배우는 구조입니다.
SuperDesign에서는 지원, SEO, 제품 성장, 광고를 루프가 담당합니다. 각 루프는 고유한 트리거와 워크플로우를 가지지만, 모두 동일한 공유 신호 저장소에 기록합니다.
지원 루프는 5명의 사용자가 내보내기 방법을 묻는 것을 감지하고 신호를 생성합니다:
1종류: 신호2제목: 내보내기 기능을 찾기 너무 어려움3빈도: 54카테고리: 마찰5태그: [피드백, 가격, 전환]
SEO 루프는 트래픽은 높지만 전환율이 낮은 페이지를 감지하고 다른 신호를 생성합니다. 제품 성장 루프는 분석 데이터와 함께 두 신호를 모두 읽고, 내보내기 마찰이 원시 데이터가 시사하는 것보다 더 큰 문제임을 파악합니다. 두 개의 독립적인 소스가 동일한 문제를 확인했기 때문입니다. 광고 루프는 키워드 격차를 찾아 SEO 루프에 직접 전달합니다.
1지원 루프 | 마찰 발견, 신호 작성2SEO 루프 | 콘텐츠 격차 발견, 신호 작성3제품 루프 | 두 신호를 읽고 우선순위 식별4광고 루프 | 키워드 격차 발견, SEO 루프에 전달
이 루프들은 고립된 자동화가 아닙니다. 비즈니스가 무엇을 배우고 있는지에 대한 공유 지식 기반 위에서 작동합니다. 각 루프는 다른 모든 루프를 더 똑똑하게 만듭니다. 이것이 바로 복리 효과입니다.
아무도 경고해주지 않는 실패 사례들
랄프 위검(Ralph Wiggum) 루프. 완료되었을 때만 완료 신호를 보내야 하는 에이전트가 너무 일찍 신호를 보냅니다. 루프는 절반만 완료된 상태에서 종료되고, 아무것도 생산하지 않으면서 계속 실행되고 비용만 청구합니다. 해결책: "좋아 보이네요"라는 부드러운 판단이 아닌, 객관적으로 작업을 실패시킬 수 있는 강력한 관문을 두는 것입니다.
긴 세션 동안의 목표 표류. 47번째 턴쯤 되면 컨텍스트가 요약되면서 제약 조건이 사라집니다. 해결책: 에이전트가 매 실행 시작 시 다시 읽는 상주 AGENTS.md를 두는 것입니다.
이해 부채. 루프가 여러분이 작성하지 않은 코드를 더 빨리 배포할수록, 존재하는 것과 여러분이 이해하는 것 사이의 격차는 커집니다. 정말 아픈 비용은 토큰 비용이 아닙니다. 팀원 중 아무도 읽어본 적 없는 시스템을 디버깅해야 하는 날이 올 때입니다. 해결책: 루프가 여는 모든 diff를 읽으세요.
인지적 항복. 자신의 의견을 형성하는 것을 멈추고 루프가 반환하는 것은 무엇이든 받아들이려는 유혹입니다. 루프를 설계하는 것은 판단력을 가지고 할 때는 치료제가 되지만, 생각하기 싫어서 할 때는 가속제가 됩니다. 같은 행동이지만 결과는 정반대입니다.
복리로 늘어나는 토큰 비용. 루프가 반복될 때마다 전체 컨텍스트를 다시 읽고, 통과할 때마다 쌓이는 양이 늘어납니다. 승인된 변경당 비용을 추적하세요. 승인율이 50% 미만이면 루프는 절약하는 비용보다 더 많은 비용을 발생시킵니다.
실제로 작동하는 빌드 순서
프로덕션에서 살아남는 루프를 배포하는 사람들은 모두 같은 방식으로 합니다:
11단계 | 먼저 하나의 수동 실행을 신뢰할 수 있게 만듦22단계 | 기술로 변환 - 지침을 SKILL.md에 저장33단계 | 기술을 루프로 감싸기 - 관문과 정지 조건 추가44단계 | 그 후에 일정을 잡음
수동으로 신뢰성을 확보하지 못한 것을 예약하는 것은 여러분이 자는 동안 루프가 폭주하게 만드는 지름길입니다. 한 번 증명하세요. 강화하세요. 그런 다음 자동화하세요.
중요한 지표는 토큰 사용량이나 시도한 작업 수가 아닙니다. 승인된 변경당 비용입니다. 루프가 10개의 결과를 주고 여러분이 6개를 거부한다면, 여러분은 루프가 절약해 주어야 할 검토 작업을 직접 하고 있는 것입니다.
이미 일어난 변화
2024년의 레버리지는 프롬프트에 있었습니다. 더 나은 프롬프트, 더 나은 출력, 더 나은 개발자. 2026년의 레버리지는 한 층 위인 시스템에 있습니다. Claude가 무엇을 작업할지, 언제, 어떤 관문을 거칠지, 실행 사이에 어떤 상태가 유지될지 결정하는 시스템입니다.
Anthropic 엔지니어들이 하루에 8배 더 많은 코드를 병합하는 이유는 Claude에게 질문하는 더 나은 방법을 찾았기 때문이 아닙니다. 질문하는 것을 멈추고, 대신 Claude에게 질문하는 시스템을 구축했기 때문입니다. 그들이 잠든 밤에도, 지속적으로 말이죠.
루프는 작업을 더 쉽게 만들지 않습니다. 작업이 일어나는 위치를 옮깁니다. 프롬프트를 입력하는 것에서 프롬프트를 입력하는 시스템을 설계하는 것으로, 도구를 쥐고 있는 것에서 공장을 짓는 것으로 말입니다.
대부분의 개발자는 계속해서 수동으로 프롬프트를 입력하며 왜 격차가 계속 벌어지는지 궁금해할 것입니다. 소수의 개발자는 주말을 투자해 첫 번째 루프(하나의 자동화, 하나의 기술, 하나의 상태 파일, 하나의 관문)를 구축하고 다시는 예전으로 돌아가지 않을 것입니다.
