Claude Code를 이끄는 Anthropic의 보리스 체르니는 요즘 Claude에게 프롬프트를 거의 쓰지 않습니다. 대신 그는 이렇게 말합니다. “내 일은 루프를 짜는 것이다.”

비슷한 시기, OpenClaw를 만든 피터 스타인버거도 X에 올린 글에서 같은 이야기를 했습니다. 코딩 에이전트에게 더는 프롬프트를 넣지 말고, 에이전트를 계속 돌게 만드는 루프를 설계하라는 것이었죠. Codex와 Claude Code, 서로 다른 회사에서 서로 다른 도구를 만드는 두 사람이 같은 결론에 다다랐다는 점이 눈에 띕니다.

가장 날카로운 반응은 이거였습니다. “그래서 그게 실제로는 뭘 어떻게 하는 건데?”

출처: Loop Engineering for AI Agents: Mastering Claude’s /loop & Codex – Analytics Vidhya

크론잡이라면 이미 수십 년 전부터 있었다

루프라는 말만 들으면 “그거 크론잡 아니야?”라는 반응이 나올 법합니다. 정해진 시간마다 스크립트를 실행하는 방식은 이미 오래전부터 있었으니까요.

차이는 루프 안에 있는 게 스크립트가 아니라 판단하는 에이전트라는 점이죠. 크론잡은 10분마다 같은 스크립트를 실행할 뿐입니다. 반면 루프 에이전트는 매번 실행 결과를 살펴보고, 이 실패가 일시적인 것인지 아닌지를 판단하고, 관련 로그를 뒤져보고, 지난 실행과 지금 상태를 비교한 뒤, 사람이 읽을 수 있는 요약까지 만들어냅니다.

이 차이는 AI 도구를 쓰는 방식이 세 단계를 거쳐 왔다는 이야기이기도 합니다. 처음엔 한 번 묻고 한 번 답을 받는 프롬프팅이었습니다. 다음은 에이전트에게 도구 사용을 맡기되 사람이 매 단계를 지켜보는 방식이었죠. 지금 오고 있는 단계는, 에이전트가 멈출 조건에 이를 때까지 스스로 반복하는 루프 엔지니어링입니다. 대신 이 단계는 권한을 얼마나 줄지, 비용을 어떻게 통제할지 같은 거버넌스 문제를 새로 요구하죠.

Claude Code의 /loop, 터미널 세션 안에서 계속 돈다

Claude Code는 이 개념을 /loop라는 명령으로 구현했습니다. 활성 세션 안에서 정해진 간격으로 같은 작업을 반복하게 만드는 방식이죠. 예를 들어 “5분마다 배포 상태를 확인해줘”라고 지시하면, 에이전트는 그 주기마다 상태를 관찰하고 판단합니다. 여기에 예약 실행을 위한 /schedule, 목표 달성을 조건으로 삼는 /goal 패턴까지 더해지면서 세 가지 방식의 반복 실행을 지원합니다.

OpenAI Codex도 비슷한 방향으로 움직입니다. 특정 스레드에 붙어 주기적으로 깨어나는 자동화와, 매번 새로운 세션으로 시작하는 독립 실행형 자동화를 모두 지원하죠. GitHub나 Slack을 주기적으로 확인해 결과를 트리아지 인박스에 모아두는 식의 활용이 대표적입니다.

이 루프가 실제로 도는 과정에는 몇 가지 요소가 함께 작동합니다. 무엇이 루프를 시작시키는지(수동 명령, 시간, 이벤트, 목표), 에이전트가 매 사이클에서 무엇을 참고할지(코드 변경 사항, 빌드 로그, 이슈 댓글 등 최신 컨텍스트), 그리고 진행 상황을 어떻게 검증할지(테스트 통과 여부 같은 확정적 검증, 혹은 “이 답변이 충분히 완전한가” 같은 AI 기반 판단)가 맞물립니다. 검증을 통과하면 계속하고, 실패하면 재시도하거나 사람에게 승인을 요청하는 식입니다.

무엇을 자동으로 맡기고 무엇을 사람이 봐야 하나

루프가 스스로 판단한다고 해서 모든 걸 맡겨도 되는 건 아닙니다. 로그를 읽거나 요약을 작성하거나 테스트를 돌리는 일은 자동으로 진행해도 되지만, PR을 병합하거나 프로덕션에 배포하거나 이메일을 보내는 일처럼 되돌리기 어려운 결정은 사람의 승인을 거치도록 설계하는 게 안전합니다. Anthropic도 명확한 중단 조건과 자가 검증 단계, 그리고 가능하면 확정적으로 확인할 수 있는 스크립트를 함께 두라고 권합니다.

실전에서 자주 쓰이는 예로는 PR을 주기적으로 확인해 CI 통과 여부를 판단하고 다음 행동을 제안하는 “PR 베이비시터”가 있습니다. 매번 사람이 들여다보지 않아도, 정말 봐야 할 순간에만 알림이 오게 만드는 식이죠. 하루 업무를 브리핑하거나 쌓인 메일함을 정리하는 용도로도 쓰입니다. 이런 루프를 여러 겹으로 쌓아 하나의 실전형 아키텍처로 만드는 방법은 이전에 따로 다룬 적이 있습니다.

이번에 짚은 건 그 아키텍처보다 한 단계 앞선 질문이었습니다. 애초에 왜 개발자들이 프롬프트 대신 루프를 짜기 시작했고, 그게 크론잡과 근본적으로 뭐가 다른가 하는 것이죠.