물레방아는 사람이 지키고 서 있지 않아도 돈다. 물이 떨어지는 자리에 바퀴를 걸어 두면, 물살이 알아서 바퀴를 돌리고 바퀴가 알아서 곡식을 빻는다. 방앗간 주인이 한 일은 곡식을 떠넘기는 노동이 아니라, 물과 바퀴와 맷돌이 맞물려 저절로 돌아가는 구조를 한 번 세운 것이다. 그러고 나면 그의 일은 바뀐다. 빻는 사람에서, 물이 마르지 않는지 바퀴가 헛돌지 않는지 지켜보는 사람으로.
요즘 AI를 다루는 사람들 사이에서도 비슷한 전환이 일어나고 있다.
프롬프트에서 루프로
2026년 6월, 개발자들 사이에서 한 문장이 돌았다. “이제 코딩 에이전트에 프롬프트하지 마라. 너의 에이전트를 프롬프트하는 루프를 설계하라.” 한 트윗이 며칠 만에 수백만 조회를 넘기며 **루프 엔지니어링(loop engineering)**이라는 말을 퍼뜨렸다. 흐름은 이렇게 정리됐다. 명령을 잘 쓰는 시대(prompt engineering)에서, 모델에게 무엇을 보여줄지 설계하는 시대(context engineering)를 지나, 이제 에이전트가 도는 사이클 자체를 짜는 시대로 넘어간다는 것이다. 각 단계는 앞 단계를 버리는 게 아니라 한 겹 감싼다. 한 번의 명령 위에, 그 명령이 보는 정보 환경을 얹고, 다시 그 위에 그것이 반복해 도는 루프를 얹는다.
루프의 골격은 단순하다. 행동하고, 결과를 관찰하고, 다음을 판단하고, 다시 반복한다. 사람이 매 턴 끼어들어 다음 프롬프트를 치는 대신, 루프를 한 번 짜 두면 그게 에이전트를 굴린다. Anthropic에서 Claude Code를 이끄는 보리스 처니는 이렇게 말했다. “나는 더 이상 Claude에게 프롬프트하지 않는다. Claude에게 프롬프트하는 루프들을 돌린다. 내 일은 루프를 짜는 것이다.” 방앗간 주인이 빻는 사람에서 지켜보는 사람으로 옮겨 간 것과 같다.
읽으면서 묘한 기분이 들었다. 나는 그 이름이 붙기 전부터 이미 대여섯 개의 루프를 굴리고 있었기 때문이다.
나는 여러 분야에서 루프를 굴린다
누가 먼저랄 것도 없는 일이다. 그 트윗을 올린 사람들도, 나도, 각자 필요해서 했을 뿐이다. 다만 한 가지는 달랐다. 그들 대부분이 코딩 한 분야에서 루프를 쌓았다면, 나는 같은 패턴을 여러 갈래에 걸쳐 돌리고 있었다.
하나는 투자다. 실제 자금으로, 삼십 분에 한 번씩 에이전트가 시장을 살펴 살지 팔지 판단하고 근거를 기록한다. 또 하나는 지식 정리다. 몇 시간에 한 번씩 그동안 쌓인 날것의 기록을 읽어 정돈된 위키로 추려 둔다(지난 글에서 쓴 그 위키가 바로 이 루프의 산물이다). 글감 발굴 루프는 하루 한 번 새 주제를 던지고, 내가 무시한 패턴을 학습해 다음 제안을 다듬는다. 일에서는, 작업물을 올릴 때 또 다른 에이전트가 그 결과물을 요구사항 문서에 비춰 “이 요구를 정말 충족했는가”를 판정하게 해 둔다.
분야는 제각각이지만 골격은 똑같다. 트리거(언제 도는가), 행동(무엇을 하는가), 검증(잘됐는지 누가 보는가), 정지(언제 멈추는가). 그리고 분야가 이렇게 다른데도, 늘 같은 두 곳에서 막혔다.
첫째, 검증기
첫 번째는 검증이다.
작업물을 요구사항에 비춰 판정하는 그 루프를 떠올려 보자. 핵심은 판정하는 쪽과 만든 쪽을 분리하는 데 있다. 무언가를 만든 모델에게 “이거 잘했어?”라고 물으면, 사람이 자기 숙제를 채점할 때처럼 너그러워진다. 그래서 판정은 만든 모델이 아니라 다른 모델, 다른 지시문을 쥔 별도의 판정자(LLM-as-judge)가 맡는다.
그런데 막상 굴려 보니 정작 어려운 건 판정자를 똑똑하게 만드는 게 아니었다. 판정자가 흔들릴 때, 대개 판정자가 멍청해서가 아니라 기준이 모호해서였다. 요구사항 문서가 두루뭉술하면 같은 작업물도 어떤 날은 통과, 어떤 날은 반려로 갈렸다. 판정의 품질을 올리려고 손을 대다 보면, 결국 고치게 되는 건 판정자가 아니라 요구사항을 적은 내 문장이었다. 무엇을 충족으로 볼지 내가 또렷하게 못 적으면, 판정자도 또렷하게 판정할 수 없다.
이게 루프 엔지니어링에서 자주 회자되는 한 문장의 실감이다. “병목은 모델이 아니라 검증기다.” 루프는 내가 검증 기준에 담아 둔 판단을 그대로 증폭한다. 그래서 검증기의 수준이 곧 루프 전체의 천장이 된다. 가장 무서운 경우는 따로 있다. 틀린 기준을 향해 부지런히 굴러가는 루프는, 자신만만하게 결과물을 망가뜨린다. 빠르게, 일관되게, 틀린 방향으로.
둘째, 멈춤
두 번째는 멈춤이다.
투자 루프에서 한동안 거래가 한 건도 일어나지 않은 적이 있다. 처음엔 시장이 잠잠한가 보다 했는데, 들여다보니 아니었다. 안전하게 만들려고 “이럴 땐 사지 마라”는 가드레일을 하나씩 더했더니, 그렇게 쌓인 규칙들이 스스로 불어나며 점점 빡빡해진 것이다. 어느새 거의 모든 상황이 “사지 마라”에 걸렸다. 루프는 멀쩡히 돌고 있었지만, 사실상 아무 일도 하지 않는 상태로 스스로를 잠가 버렸다.
정지 조건이 없는 루프는 반대로 폭주한다. 되밀어 줄 제동이 없으면 에이전트는 자기 자신에게 끝없이 동의하며 같은 일을 반복하거나, 수도꼭지를 잠그지 않은 듯 비용을 흘려보낸다. 어떤 회사는 가드 없는 루프에 연간 예산을 몇 달 만에 태우고서야 1인당 지출 상한을 걸었다고 한다. 똑똑함은 가운데에 있고, 멈춤과 폭주는 양 끝에 있다. 루프 엔지니어링의 절반은 가운데를 키우는 일이 아니라, 양 끝을 다루는 일이다.
그래서 사람의 검증은 어디로 가는가
여기서 당연한 질문이 생긴다. 루프가 나를 “매번 프롬프트 치는 사람”의 자리에서 빼낸다면, 사람의 검증은 언제 이뤄지는가. 답은, 검증이 사라지는 게 아니라 자리를 옮긴다는 것이다. 매 턴 끼어들어 즉석에서 확인하던 일이 세 군데로 흩어진다.
먼저 설계할 때다. 루프를 짜는 순간 나는 검증 기준과 정지 조건을 미리 못 박는다. 매번 하던 판단을 규칙으로 응결시키는 것이다. 앞서 검증기 이야기가 이 자리였다. 다음은 돌아가는 중간이다. 민감한 결정에는 루프가 사람 앞에서 멈추도록 관문을 남겨 둔다. 마지막은 끝난 뒤다. 루프가 내놓은 결과물을 사람이 읽고 받아들인다.
문제는, 옮긴 자리마다 새 비용이 붙는다는 것이다. 검증을 설계 단계의 규칙으로 옮기면, 그 규칙이 틀렸을 때 루프는 틀린 줄도 모르고 부지런히 굴러간다. 사후 검토로 옮기면, 이번엔 내가 읽어 낼 수 있는 양이 병목이 된다. 그리고 읽지 않고 통과시키면, 결과물은 쌓이는데 그걸 떠받치는 이해는 내 안에 남지 않는다. 전에 쓴 것처럼, 생각의 실행은 넘겨도 이해는 넘겨지지 않는다. 검토를 건너뛴 자동화는 그 빈자리를 정확히 키운다.
사실 이건 낯선 이야기가 아니다. 에이전트가 믿고 딛을 진실에는 사람이 승인한 검증의 관문이 필요하다는 것(단일 진실), 자동으로 쌓인 지식이 개인에겐 맞아도 조직의 기준이 되려면 그 관문을 통과해야 한다는 것(LLM Wiki). 루프 엔지니어링은 같은 질문을 또 다른 렌즈로 묻는다. 자동화가 깊어질수록, 사람의 검증은 사라지는 게 아니라 더 적은 수의, 더 중요한 자리로 옮겨 간다. 관건은 그 자리를 어디에 두고 그 비용을 감당할 수 있느냐다.
지켜보는 사람
루프를 짠다는 건 일을 자동화하는 일처럼 보이지만, 실은 내 판단을 어디에 박제할지를 정하는 일이다. 무엇을 충족으로 볼지, 언제 멈춰야 하는지, 어떤 결과는 반드시 내가 눈으로 봐야 하는지. 그 결정들을 미리 구조에 새겨 넣는 일이다. 루프는 내가 새겨 넣은 판단만큼만 똑똑하고, 딱 그만큼만 안전하다.
물레방아를 세운 사람은 빻는 노동에서 풀려났지만, 물과 바퀴를 지켜보는 책임에서까지 풀려난 것은 아니다. 오히려 그의 일은 더 적은 횟수의, 더 중요한 판단으로 옮겨 갔다. 물이 마르면 바퀴는 멈추고, 둑이 무너지면 바퀴는 폭주한다. 루프를 굴리는 사람의 자리도 거기다. 매 알갱이를 빻는 자리가 아니라, 무엇이 잘 돌고 무엇이 어긋나는지를 끝내 지켜보는 자리.