루프는 모두에게 필요하지 않다

이번 주 AI 코딩 타임라인을 한 문장이 장악했다. "이제 코딩 에이전트에게 프롬프트하지 마라. 에이전트에게 프롬프트하는 루프를 설계하라." Peter Steinberger가 6월 7일 올린 트윗이고, 조회수는 220만을 넘겼다. 댓글창은 그 말이 정확히 무슨 뜻인지를 두고 싸움터가 됐고, 가장 많이 인용된 답은 "그와 Boris 말고는 아무도 모른다"였다. 한 문장이 수백만 조회를 먹는 동안, 그것을 퍼나르던 사람들조차 그게 뭔지 설명하지 못했다.

그 싸움을 유심히 봤다. 그런데 따라가야 한다는 조바심보다 먼저 든 질문은 두 개였다. 이게 cron과 뭐가 다른가. 그리고 대부분의 사람에게 정말 필요한가. 루프는 유용하다. 그 유용함은 진짜고, 작은 루프 하나를 직접 돌리고도 있다. 하지만 유용한 것과 모두에게 필요한 것은 다른 말이다.

이 글은 루프를 성과와 조건의 관점에서 읽는다. 기술의 최신성은 잠시 접어 둔다. cron과 무엇이 다른지 정의한 뒤, 왜 그것이 일하는 시스템을 짜본 사람에게는 낯설지 않은지, 어떤 환경에서만 레버리지가 되는지, 같은 루프가 왜 사람에 따라 정반대 결과를 내는지를 본다. 결론을 먼저 말하면 이렇다. 루프는 새 역량을 발명하지 않았고, 모두에게 필요한 것도 아니다. 그 둘을 분간하는 것이 지금 필요한 리터러시다.

루프는 결정자를 품은 cron이다

루프를 가장 정확하게 깎아낸 표현은 회의론자에게서 나왔다. 누군가 "루프야말로 미래"라고 띄우자 네 단어가 달렸다. "요즘 cron job이 이름을 거창하게 바꿨네." 이 빈정거림은 절반은 맞다. 스케줄링 계층은 cron이 맞다. Boris Cherny는 자기 루프를 실제로 cron 위에서 돌린다고 했고, Claude Code의 /loop도 내부적으로 cron을 쓴다. 타이머로 도는 무언가가 루프의 전부라면, 그건 1975년에 이미 발명됐고 새로 배울 것이 없다.

cron에 없던 것은 한가운데에 있다. cron job은 고정된 스크립트를 돌린다. 루프는 모델을 돌린다. 현재 상태를 보고, 다음에 뭘 할지 정하고, 그걸 하고, 됐는지 확인하고, 계속할지 말지를 정하는 결정이 그 안에 들어 있다. 그 결정은 모델의 몫이다. 하드코딩된 분기가 정하지 않는다. 루프의 최소 단위는 cron에 결정자를 한 명 앉힌 것이고, 흥미로운 공학은 전부 그 결정자가 절벽으로 달려가지 않게 감싸는 장치에 있다.

계보를 보면 새로움의 위치가 분명해진다. 2022년 ReAct 논문이 학술적 while 루프를 형식화했다. 모델이 추론하고, 도구를 부르고, 결과를 읽고, 끝날 때까지 반복한다. 2023년 AutoGPT는 거기에 목표를 주고 스스로 프롬프트하게 풀어놓았다가, 아무것도 끝내지 못하고 영원히 도는 것으로 악명을 얻었다. 2025년 Geoffrey Huntley의 ralph 루프는 같은 프롬프트 파일을 반복해 흘려보내는 bash 한 줄이었는데, 매 반복마다 컨텍스트를 고정된 앵커 파일로 되돌리는 규율이 핵심이었다. 2026년 봄 Codex와 Claude Code가 그것을 /goal 명령으로 제품화했다. 지금은 루프가 다른 루프를 감독하고 git에 상태를 박아 재시작에서도 살아남는다. 한 층씩 쌓였다.

다만 "유일한 차이는 결정자"라는 말은 최소 단위에서만 참이다. 완료를 별도의 검증 모델이 판정하고, 프로세스가 매 반복 자기 컨텍스트를 의도적으로 버리고, 루프가 루프를 감독하며 git 상태로 복구하는 순간, 그건 더 이상 cron의 의미론이 아니다. 원자 단위에서는 cron에 결정자를 더한 것이고, 조립된 시스템에서는 종류가 달라진다. 빈정거림이 절반만 맞는 이유가 여기 있다.

루프의 부품은 조직 운영의 부품과 같다

루프 담론이 새로워 보이는 이유는 부품에 새 이름이 붙어서다. 이름을 떼면 정체가 드러난다. 루프 엔지니어링을 다룬 한 글은 그것이 여섯 부품과 하나의 기억으로 이뤄진다고 정리했다. 스케줄로 도는 automation, 충돌을 막는 worktree, 지식을 적어 둔 skill, 도구에 연결하는 connector, 만드는 쪽과 검수하는 쪽을 가르는 sub-agent, 그리고 대화 밖에 사는 memory. 여섯을 우리말로 옮기면 이건 전부 사람을 데리고 일을 시켜본 사람의 어휘다.

automation은 정기 스탠드업이고 트리아지 회의다. 매일 아침 무엇이 깨졌고 무엇이 들어왔는지를 누가 시키지 않아도 훑는 장치다. worktree는 책임 분리다. 두 사람이 같은 파일을 동시에 건드리는 사고는 두 에이전트가 같은 파일을 동시에 쓰는 사고와 정확히 같은 문제고, RACI를 그어 본 사람이라면 설명을 들을 필요가 없다. skill은 온보딩 문서이고 SOP다. connector는 권한 부여다. 신입에게 계정을 열어 주지 않으면 그는 "이렇게 고치면 됩니다"라고 말만 하고 실제로는 고치지 못한다.

가장 중요한 부품은 sub-agent다. 만든 사람이 자기 결과물을 검수하면 너무 관대해진다. 다른 지시와 때로 다른 모델을 받은 두 번째 에이전트가 첫 번째가 스스로 넘어간 자리를 잡는다. 작성과 검토를 같은 맥락에서 한 사람이 하지 않는 것, 이건 좋은 작업의 첫 줄이다. 자기 작성을 자기가 승인하지 않는다. 루프가 sub-agent로 만드는 자와 검수하는 자를 가르는 것은 좋은 조직이 작성자와 리뷰어를 가르는 것과 같은 원리다. 루프의 부품 목록은 결국 잘 굴러가는 팀의 부품 목록이다.

그런데 이 대응이 가리는 칸이 하나 있다. 한계비용이 0에 가까워지면 인간 조직이 한 번도 가져본 적 없는 수가 열린다. 같은 일에 에이전트 100개를 동시에 띄우고, 통과한 하나만 남기고 아흔아홉을 비용 없이 버리는 투기적 병렬 탐색이다. ralph의 재시도와 오케스트레이션 루프가 정확히 이것이다. RACI도 인수인계도 본질적으로 사람의 노동이 희소하고 폐기 불가능하다는 제약을 다루는 기술인데, 희소성이 사라지면 관리할 대상 자체가 없어진다.

정확히 말하면 이렇다. 루프는 새 운영자 스킬을 발명하지 않았다. 그러나 희소성 없는 노동을 병렬로 던져 보는 새 수단은 발명했고, 그건 관리 어휘에 대응하는 칸이 없다. 환원이 닿지 못하는 자리는 여기 하나뿐이다.

그래서 어떨 때 쓰는가, 조건이 맞을 때만

부품을 다 이해해도 질문이 하나 남는다. 그래서 이게 나에게 필요한가. 도구가 시끄럽다고 모두가 그 도구를 들여야 하는 것은 아니다. 루프는 특정 조건이 갖춰진 환경에서만 레버리지가 된다. 조건이 없으면 그건 오버헤드일 뿐이다. 이 분간이 빠지면 루프는 비싼 cron이 된다.

루프가 값을 하는 조건은 네 가지다. 반복적이고 서로 독립인 일이 충분히 많고, 사람이 지켜보지 않는 동안에도 굴러가야 의미가 있고, 다 됐다를 코드로 쓸 수 있고, 그 모든 것을 받칠 토큰 예산이 있어야 한다. 네 조건이 갖춰지면 루프는 사람의 주의력을 인프라 시간으로 바꿔 준다.

하나라도 빠지면 직접 프롬프트하는 편이 더 빠르고 싸다. 일이 적거나 매번 다르면 루프를 짜는 시간이 일을 하는 시간보다 길다. 정지 조건을 코드로 못 쓰면 루프는 폭주한다. 토큰이 빠듯하면 청구서가 레버리지를 먼저 먹는다.

이건 추상적인 이야기가 아니다. 채용 공고를 매일 크롤해서 AI 네이티브 직무만 골라 알림을 보내는 작은 루프를 돌린 적이 있다. 그 일은 네 조건에 맞았다. 매일 반복되고, 내가 안 봐도 굴러가야 의미가 있고, 새 공고만 추려 보낸다는 정지 조건이 명확하고, 비용이 작았다. 반대로 조건이 애매한 일에는 루프를 얹지 않았다. 한 번 쓰고 마는 분석이나 매번 판단이 갈리는 기획 검토는 직접 프롬프트하는 편이 빨랐다. 무분별하게 이슈를 따라가는 대신 내 환경이 조건을 만족하는지를 먼저 묻는 것, 그것이 지금 생긴 리터러시다.

다만 이 네 조건은 고정된 필터가 아니다. 일의 양과 검증 자동화와 토큰 예산은 루프를 돌리는 오버헤드의 함수이고, 그 오버헤드는 지금 가장 빠르게 떨어지는 항이다. 버전 관리도, CI/CD도, 클라우드도 처음엔 특정 조건에서만 필요한 것으로 출발했다가 비용이 떨어지자 모두의 기본값이 됐다. 내 환경이 오늘 조건을 못 넘어도 반년 뒤엔 넘을 수 있다. 물론 모든 유행이 보편화되는 것은 아니다. 정리하면 리터러시는 조건을 한 번 묻고 끝내는 일이 아니라, 묻고 자주 다시 묻는 일이다.

루프는 배관이고, 닦을 것은 스킬이다

조건이 맞아 루프를 들였다고 끝이 아니다. 루프 담론에서 가장 정직한 문장은 비용에 관한 것이었다. 한 엔지니어는 이렇게 적었다. "올해 내가 출시한 모든 AI 에이전트는 for 루프 하나, LLM 호출 하나, JSON 파싱을 감싼 try/catch 하나다. 에이전트다운 유일한 부분은 월말의 청구서다." Uber는 연간 AI 예산을 넉 달 만에 태운 뒤 1인당 도구당 월 1,500달러로 한도를 걸었다.

모델이 코드를 거의 공짜로 써 주기 시작하자, 비용은 그 코드를 돌리는 루프로 옮겨 갔다. 이게 반전으로 소개된다. 그러나 사람을 부려 본 사람에게는 반전이 아니다. 관리는 늘 비쌌다.

비용이 관리로 옮겨 갔다는 말은, 닦아야 할 것이 루프가 아니라는 뜻이다. 루프는 배관이다. 잘 짜인 스킬을 흘려보내고 반복 실행하는 방법론이지, 그 자체가 자산은 아니다. 하네스가 엄청 중요해 보이다가도 손에 남는 것은 잘 쓰는 스킬 몇 개고, 시간이 갈수록 집중하게 되는 것은 그 스킬을 다듬는 일이다. 흥미로운 사실이 있다. 일주일을 들여 이 담론을 해부한 사람도 같은 자리에 도착했다. 루프는 배관이고 자산은 그것이 호출하는 스킬이라는 결론이다. 서로 다른 자리에서 같은 답에 도착했다는 사실 자체가, 이게 당연히 도달하는 생각이라는 증거다. 놀랄 일이 아니다.

이러한 이유로 성과는 도구 숙련도에서 갈리지 않는다. 같은 루프를 두 사람이 짜도 정반대 결과가 나온다. 한 사람은 자기가 깊이 아는 일을 더 빨리 하려고 루프를 쓰고, 다른 사람은 그 일을 이해하지 않으려고 루프를 쓴다. 차이를 만드는 것은 의도를 정확히 정의하고, 검증 가능한 정지 조건을 걸고, 다 됐다는 판정을 증거로 받치는 규율이다.

그런데 이 규율이 사람을 잘 부리던 모든 사람에게 그냥 전이되지는 않는다. 위임의 규율은 전이된다. 위임의 관계성은 전이되지 않는다. 믿고 알아서 맡긴다는 좋은 매니저의 본능은 판단력 없는 에이전트에게는 빈칸투성이 명세가 되고, 그게 폭주하는 루프와 청구서 폭발을 만든다. 전이되는 것은 위임의 규율이지 위임의 관계성이 아니고, 그 규율은 매니저의 것일 수도 엔지니어의 것일 수도 있다.

도구가 따라잡은 것은 오래된 역량이다

루프란 무엇인가에 대한 답은 프롬프트 엔지니어링의 죽음이 아니다. 레버리지 포인트가 코드를 쓰는 자리에서 일하는 시스템을 짜는 자리로 옮겨 갔다는 것이다. 일하는 시스템을 짜는 일은 새 기술이 아니다. 좋은 운영자가 사람을 데리고 늘 하던 일이다.

사실 이 결론의 대부분은 담론의 진지한 쪽과 갈리지 않는다. 검증은 사람 몫이라는 것도, 끝까지 엔지니어로 남으라는 것도 그들이 먼저 한 말이다. 진짜로 갈리는 지점은 하나다. Boris는 한 달의 PR 전부를 루프로 돌린다고 밝혔지만, 기본값으로 루프부터 돌리는 그 처방에는 반대한다. 네 조건을 통과하지 못하는 환경에서 그건 레버리지가 아니라 비싼 cron이다.

이 관점은 누가 앞서가는지를 바꾼다. 루프를 잘 짜는 사람은 일을 잘 나누고 잘 검증하던 사람이다. 자기 환경이 루프를 필요로 하는지 분간하는 사람이 헛돈을 쓰지 않는다.

한 가지는 인정해야 한다. 반복되고 독립적인 일이 충분한지를 지금 내 작업대를 기준으로 판정하고 있다. 루프를 더 깊이 굴려 본 사람은 같은 환경에서 더 많은 일을 루프에 맞다고 볼 것이다. 이 판단이 틀렸다면 반년 뒤 이렇게 드러난다. 조건이 안 맞는다고 흘려보낸 일을 누군가는 루프로 자동화해 성과를 내고 있거나, 토큰 값이 더 떨어져 네 번째 조건이 사실상 늘 참이 되어 있을 것이다.

같은 루프가 사람에 따라 정반대 결과를 낸다는 말은 결국 이런 뜻이다. 루프는 당신이 일을 얼마나 잘 아는지, 그리고 자기 환경을 얼마나 정확히 읽는지를 증폭한다. 깊이 아는 일에 조건을 갖춰 얹으면 가속이 되고, 모르는 일을 유행을 따라 얹으면 더 깊은 구덩이가 된다. 그러니 버튼만 누르는 사람이 아니라 끝까지 엔지니어로 남을 사람처럼 루프를 짜야 한다. 그리고 짜기 전에 한 번 물어야 한다. 나에게 이게 정말 필요한가.