"노 프롬프트(No-Prompt)" 워크플로우: 빌더의 생산성을 극대화하는 Boris의 루프 기반 이론

"더 이상 Claude에 프롬프트를 직접 입력하지 않습니다. 이제는 루프가 돌아가고 있고, 그 루프가 Claude에 다음에 무엇을 할지 결정하도록 지시합니다. 제 역할은 루프를 작성하는 것이 되었습니다."

이 말은 Claude Code를 이끌고 있는 Boris Cherny가 공개적으로 한 발언입니다 (The New Stack과 Addy Osmani의 글에서 소개됨).

우리 중 상당수가 여전히 정확도를 높이기 위해 프롬프트를 다듬고 있는 동안, 그 도구를 만드는 사람은 이미 '프롬프터'의 자리에서 물러났습니다.

생각해보면, '사람의 턴'—화면 앞에 앉아 AI 응답을 기다리고, 확인하고, 다시 지시하는 과정—이 개입되는 한, 속도의 한계는 결국 여러분 손의 속도에 의해 결정됩니다.

루프 엔지니어링(Loop Engineering) 은 그 구조에서 사람의 턴을 제거하는 개념입니다. Boris는 이에 전적으로 몰입하고 있으며, 2024년 11월에 자신의 IDE를 삭제한 후 지금까지 열어본 적이 없다고 말합니다. 그는 지난 한 달 동안 Claude Code에 기여한 거의 모든 내용(보고에 따르면 200개 이상의 PR)이 Claude Code 자체에 의해 작성되었다고 주장합니다.

도구의 창시자는 직접 코드를 작성하지 않고, '루프가 제대로 돌아가고 있는지 지켜보는' 역할로 전환했습니다. 오늘은 이 개념을 단순한 느낌이 아닌 기술 명세 수준에서 분석해 보겠습니다. 저 또한 루프 쪽으로 전환하는 과정에 있으며, 전환할수록 제 손이 더 자유로워지는 것을 느끼고 있습니다.

https://note.com/nobel/n/n8192ec07d689

루프 엔지니어링은 역할의 변화를 의미한다

다시 말해, 여러분의 위치가 바뀝니다. 이전에는 사람이 지시하고, AI가 응답하고, 사람이 확인하고 수정하는 왕복 과정의 한가운데에 사람이 있었습니다. 루프 설계에서는 사람이 순환 메커니즘(루프)을 설계하는 역할을 담당하고, 시행착오와 결과 검증은 AI 쪽으로 넘어갑니다. 여러분은 완료되었다는 알림이 오기를 기다리기만 하면 됩니다.

Google의 Addy Osmani도 루프 엔지니어링(Loop Engineering)이라는 글에서 같은 내용을 언급하며, 이를 "프롬프트를 입력하는 사람을 대신해 프롬프트를 입력해주는 메커니즘으로 대체하는 것"이라고 설명했습니다. 영향력을 발휘하는 지점이 좋은 프롬프트를 작성하는 능력에서 AI가 여러분을 대신해 프롬프트를 작성하도록 하는 시스템을 설계하는 방법으로 옮겨갔습니다. 이것이 핵심입니다.

하지만 Addy 자신도 "아직 초기 단계이며 다소 회의적입니다. 토큰 비용에 정말 주의해야 합니다."라고 경고합니다. 이 함정에 대해서는 후반부에 다시 다루겠습니다.

/loop의 기술 사양

Claude Code에는 /loop(v2.1.72부터)라는 내장 스킬이 있습니다. 이것이 루프 엔지니어링의 가장 쉬운 진입점입니다. 온라인 설명에는 오류가 섞여 있는 경우가 많으므로, 공식 예약 실행 문서를 기반으로 핵심 사항에 집중하겠습니다.

전달하는 내용에 따라 동작이 달라집니다:

간격과 프롬프트를 모두 전달: /loop 5m check if the deployment is finished and let me know는 고정된 간격으로 실행됩니다.
프롬프트만 전달: /loop check if the CI passed and respond to review comments. Claude가 1분에서 1시간 사이의 간격을 스스로 결정합니다(자체 속도 조절).
아무것도 전달하지 않음 /loop: 내장 유지 관리 프롬프트(완료되지 않은 작업 계속, PR 관리, 가벼운 정리) 또는 여러분이 넣어둔 loop.md 파일이 실행됩니다.

간격은 30m처럼 처음에 넣거나 every 2 hours처럼 끝에 넣을 수 있습니다. 단위는 s / m / h / d입니다. 다른 명령어도 전달할 수 있습니다. 예를 들어 /loop 20m /review-pr 1234와 같이 입력하면 매번 저장된 스킬을 실행합니다. 중단하려면 기다리는 동안 Esc를 누르세요(자연어 요청을 통해 생성된 작업은 Esc로 중단되지 않으며, 삭제를 요청해야 합니다). 자체 속도 조절 모드에서 Claude가 작업이 완전히 끝났다고 판단하면 다음 실행을 예약하지 않고 종료됩니다.

자체 속도 조절 모드에는 미묘한 장점이 있습니다. 빌드가 거의 끝나가면 짧게 기다리고, 아무 일도 일어나지 않으면 더 오래 기다리는 등 자동으로 조정됩니다. 때로는 폴링 대신 "Monitor"라는 메커니즘을 사용하여 백그라운드 출력을 스트리밍하기도 하는데, 이는 고정된 간격으로 프롬프트를 실행하는 것보다 비용이 적게 드는 경우가 많습니다.

소스 기사에서 발견되는 일반적인 오해 하나를 바로잡겠습니다. 작업이 "생성 후 3일이 지나면 자동으로 삭제된다"고 쓰여 있는 경우가 있지만, 정확히는 반복 작업은 생성 후 7일이 지나면 만료됩니다(마지막으로 한 번 실행되고 사라집니다). 또한 /loop는 세션 범위 내에서 작동하며, 새 대화를 시작하면 사라집니다. 닫았더라도 만료되지 않았다면 --resume으로 돌아올 수 있습니다.

세 가지 스케줄링 방법이 있으며, 사용 사례에 따라 선택합니다:

Cloud (Routines): Anthropic 쪽에서 실행됩니다. 기기가 꺼져 있어도 실행됩니다. 최소 간격은 1시간입니다.
Desktop Scheduled Tasks: 사용자 기기에서 실행되며 로컬 파일에 접근할 수 있습니다.
/loop: 세션이 열려 있는 동안에만 실행됩니다. 최소 1분, 세션 중 폴링에 편리합니다.

역할 분담은 다음과 같습니다: 사람의 개입 없이 영구적으로 실행하려면 Routines나 GitHub Actions를 사용하고, 세션 중 모니터링에는 /loop를 사용합니다.

루프가 효과적인 일반적인 작업

"확인하고 조금 수정하는" 것을 반복하는 일상적인 작업은 일반적으로 루프에 적합합니다. 세 가지 일반적인 패턴이 있습니다:

버그 순찰(Bug Patrol): 문제나 테스트 실패를 감지하고, 원인을 읽고, 수정하고, 테스트를 실행하고, 정기적인 간격으로 PR을 생성합니다.
지속적 검토(Continuous Review): 코드 변경 사항을 모니터링하고 계속해서 문제가 될 만한 영역을 지적합니다. 사람은 제안을 수락할지 여부만 결정합니다.
문서 동기화(Document Sync): 소스 변경을 감지하고 README나 사양을 최신 상태로 유지합니다.

이 세 가지의 공통점은 "테스트 통과"나 "PR 생성"과 같이 목표를 명확하게 판단할 수 있다는 것입니다. 반대로, 판단 기준이 모호한 작업은 루프에 적합하지 않습니다. 중단 지점이 명확하지 않으면 계속 실행되면서 토큰만 소모하게 됩니다. 첫 번째 작업으로는 성공 또는 실패가 한눈에 명확한 것을 선택하는 것이 더 안전합니다.

"상태 파일"로 폭주 및 건망증 방지하기

루프에는 두 가지 두려움이 있습니다: 동일한 실패를 반복하는 것과 끝없이 토큰을 소모하는 것입니다.

이때 프로젝트에 단일 상태 파일을 두고 설계하는 것이 효과적입니다. STATE.md든 todo.md든, AI는 매 루프마다 현재 목표 / 완료된 항목 / 다음 단계 / 막힌 지점을 읽고 씁니다. 세션이 끊겨도 AI는 "자신이 어디에 있고 무엇을 목표로 하는지"를 잃지 않습니다.

이는 임의의 관행이 아닙니다. Anthropic 자체도 장기 실행 에이전트를 위한 효과적인 하네스(Effective harnesses for long-running agents)(2024년 11월)에서 거의 동일한 결론에 도달했습니다. 그들의 구성은 두 가지 역할을 사용합니다: 환경을 설정하는 초기화 에이전트와 세션당 하나의 기능을 진행하는 코딩 에이전트입니다. 진행 상황은 git 커밋과 claude-progress.txt 파일을 통해 세션 간에 전달됩니다. 긴 작업의 경우 요약을 통한 압축만으로는 충분하지 않습니다. 정책은 구조화된 파일에 한 번 작성한 후 컨텍스트를 재구축하는 것입니다.

제 운영에서는 tasks/state.md를 공유 상태의 허브로 사용하며, 브레인스토밍 쪽과 구현 쪽 모두 행동하기 전에 이를 읽습니다. 이는 "컨텍스트를 믿지 말고, 파일을 믿어라"라는 논문과 동일합니다. 간단하지만, 이것이 없으면 루프는 두 번째 바퀴에서 길을 잃습니다.

랄프 방법과 메이커/체커 분리

루프의 극단적인 버전인 "Ralph" 방법이 있습니다. Geoffrey Huntley에 의해 대중화되었으며, 원본 출처는 단순한 bash 루프입니다:

동일한 프롬프트를 계속해서 입력하고, 계획이 담긴 Markdown 파일을 디스크의 공유 상태로 사용하면, AI가 매번 그것을 읽고 "다음에 무엇을 할지" 스스로 결정합니다. 무모해 보이지만, 상태 파일이 있기 때문에 매 바퀴마다 전진합니다. Claude Code에는 완료 조건(완료 약속)이 충족될 때까지 동일한 프롬프트를 계속 제출하는 공식 ralph-loop 플러그인도 있습니다. 완료 선언은 진정으로 달성되었을 때만 해야 한다는 제약이 있습니다.

하지만 모든 것을 하나의 AI에 맡기면, AI는 자신이 작성한 코드에 대해 "좋아"라고 말할 것입니다. 이때 생성하는 AI(Maker)와 검사하는 AI(Checker)를 분리하는 것이 효과적입니다. 제 운영에서는 구현과 검증을 서로 다른 에이전트에 분리하고, 검증 쪽에는 구현 의도를 전혀 주지 않고 요구 사항만 보여주어 독립적으로 평가하게 합니다. 동일한 세션에서의 자체 검토는 필연적으로 관대해진다는 것을 어렵게 배웠습니다.

"다른 관점을 가진 검토 전용 에이전트"를 루프에 통합하는 것, 이 다층적 검사를 설계하는 것은 인간이 유지해야 할 역할 중 하나입니다.

3단계 설계 자율성

한 번에 모든 것을 맡기면 사고가 발생합니다. 참여 수준을 계층으로 나누는 것이 더 안전합니다:

L1 (수동): 사람이 프롬프트를 입력하고 각각을 확인합니다. 전통적인 방식입니다.
L2 (반자율 루프): 상태 파일을 따르고 /loop로 특정 작업 세트가 완료될 때까지 지켜봅니다.
L3 (상주): 사람의 개입 없이 Routines 또는 GitHub Actions를 통해 지속적으로 실행합니다.

L2부터 시작하는 것이 현실적입니다. /loop로 하나의 작업을 완료될 때까지 실행하고 동작을 관찰합니다. 신뢰할 수 있는 범위를 확인한 후 L3로 올라갑니다. 처음 몇 번은 사이드 화면에서 로그를 보면서 "어디에서 잘못된 판단을 내리는지" 지켜봤습니다.

함정 (먼저 알아두세요)

지금까지 좋은 점만 썼으므로, 여기서 막힐 수 있는 세 가지 사항을 말씀드리겠습니다:

토큰 비용: 루프는 실행될수록 더 많이 소모합니다. 이것이 Addy가 강조한 점입니다. 간격을 너무 짧게 설정하면 하룻밤 사이에 상당한 비용이 발생할 수 있습니다. 고정 간격보다는 자체 속도 조절이 더 좋습니다. 필요한 때에 기다리므로 낭비를 줄여줍니다.
되돌릴 수 없는 작업: 내장 유지 관리 프롬프트는 "대화에서 이미 허용된 범위 내에서" 푸시나 삭제와 같은 되돌릴 수 없는 작업만 수행합니다. 자신의 프롬프트를 작성할 때는 파괴적인 작업에 대한 경계를 직접 정의하는 것이 더 안전합니다.
7일 후 소멸: 반복 /loop 작업은 생성 후 7일이 지나면 만료됩니다. 더 오래 실행하려면 Routines 또는 Desktop 작업으로 전환하세요.

중급 사용자를 위한 참고 사항

/loop와 /goal은 다릅니다. /loop는 간격에 따라 실행됩니다. 조건이 충족될 때까지 매 턴마다 계속하려면 /goal을 사용하세요. 이벤트가 발생하는 즉시 반응하게 하려면 Channels를 통한 push를 사용하세요.
loop.md(.claude/loop.md 또는 ~/.claude/loop.md)를 배치하면 빈 /loop의 기본 프롬프트를 자신의 것으로 대체할 수 있습니다. "릴리스 브랜치 CI가 빨간색이면 수정"과 같은 일상적인 작업을 작성하는 데 유용합니다.
세션당 최대 50개의 예약 작업. CronList로 목록을 보고 CronDelete로 ID별로 삭제할 수 있습니다.

요약

이전에는 화면 앞에서 보내는 시간이 진전의 상한선이었습니다. 이제는 제가 잠을 자는 동안 상태 파일을 읽는 루프가 하나씩 기능을 진행시키고, 아침에는 그 진전 상황을 확인하는 것으로 하루를 시작합니다.

내용(프롬프트 정확도)을 개선하기 전에, 실행 방식(루프 분리, 상태 관리, 검증)을 설계하십시오. 영향력을 발휘하는 지점이 그곳으로 옮겨갔습니다. 이것이 Boris, Addy, 그리고 Anthropic의 하네스 이야기에서 공통적으로 나타나는 지점입니다. 이는 어려운 이론이 아니라, 루프를 시작하기 전에 중단 시점을 결정하는 것과 같은 단순한 설계의 꾸준한 축적이라고 생각합니다.