1788년, 제임스 와트의 증기기관에는 고질적인 결함이 있었다. 부하가 줄면 기관은 제멋대로 빨라졌고, 부하가 늘면 힘없이 느려졌다. 방직 공장의 기계는 회전이 빨라지면 실을 끊었고, 광산의 펌프는 회전이 느려지면 물을 퍼올리지 못했다. 그래서 늘 사람이 필요했다. 누군가 종일 기관 옆에 붙어 서서, 속도가 오르면 증기 밸브를 잠그고 속도가 떨어지면 다시 열었다. 기계는 강력했지만, 그 강력함을 한순간도 사람 없이 유지하지 못했다. 사람이 자리를 비우는 순간 기관은 길을 잃었다.

와트의 해법은 밸브를 더 정교하게 깎는 것이 아니었다. 사람을 기계에서 빼내는 것이었다. 그가 증기기관에 단 원심 조속기는 회전축에 매달린 두 개의 쇠공으로 이루어진 단순한 장치다. 기관이 빨라지면 원심력으로 쇠공이 바깥으로 벌어지고, 그 움직임이 연결된 밸브를 잠근다. 증기가 줄어 기관이 다시 느려지면 쇠공이 모이고 밸브가 열린다. 이 단순한 되먹임이 종일 밸브를 여닫던 사람의 일을 통째로 대신했다. 기계는 비로소 사람 없이도 일정한 속도로 스스로 돌기 시작했다. 와트가 한 일은 기계를 더 빠르게 만든 것이 아니라, 기계가 스스로를 다스리게 만든 것이었다.

이 장치의 진짜 핵심은 쇠공이 “아니오”라고 말할 수 있다는 데 있다. 기관이 너무 빨라지는 순간 조속기는 즉시 밸브를 잠가 제동을 건다. 이 되먹임이 없다면 어떻게 되는가? 기관은 폭주한다. 부하가 사라지는 순간 속도가 끝없이 치솟아 결국 스스로를 부순다. 조속기가 기계에 준 것은 속도가 아니라 멈출 줄 아는 능력이었다. 80년 뒤 제임스 클러크 맥스웰은 이 장치의 안정성을 수학으로 정리해 「조속기에 관하여(On Governors)」를 발표했고, 그것이 제어 이론의 출발점이 됐다. 다시 80년 뒤 노버트 위너는 같은 되먹임 원리 위에 사이버네틱스라는 학문을 세웠다. 위너가 그 이름을 그리스어 ‘키잡이(kubernetes)’에서 따왔다는 사실은 우연이 아니다. 자동 제어의 역사는 결국 사람이 키를 놓고도 배가 항로를 유지하게 만드는 방법의 역사였다.

여기서 한 가지를 분명히 해둘 필요가 있다. 사람을 기관에서 빼낸 일은 단순한 편의가 아니었다. 그것은 규모의 문제였다. 기관 하나에 사람 하나가 종일 붙어 있어야 한다면, 공장은 기관의 수만큼이 아니라 사람의 수만큼만 커질 수 있다. 자동화되지 않은 기계는 아무리 강력해도 사람의 손에 묶여 규모를 키우지 못한다. 조속기가 산업혁명을 가능하게 한 진짜 이유가 여기 있다. 그것은 기계를 빠르게 만든 것이 아니라, 사람 한 명이 여러 대를 동시에 거느릴 수 있게 풀어준 것이다. 사람이 루프 안에 갇혀 있는 한 기계의 속도는 사람의 속도에 묶이고, 사람이 루프 밖으로 나올 때 비로소 시스템은 사람의 손을 넘어 확장된다.

2026년 6월 8일 새벽, OpenClaw를 만든 페터 슈타인베르거가 X에 두 문장을 올렸다. 코딩 에이전트에게 더는 프롬프트를 치지 말라는 것, 대신 에이전트에게 프롬프트를 치는 루프를 설계하라는 것이었다. 칼날은 뒷문장에 있었다. 에이전트에게 프롬프트를 치는 루프를 설계하라. 이 짧은 게시물은 650만 조회를 기록했고, 일주일 동안 AI 코딩 업계 전체가 이 짧은 문장을 두고 다퉜다. Claude Code를 만든 보리스 체르니도 며칠 앞서 무대에서 같은 말을 더 깔끔하게 정리해 두었다. 이제 자신은 Claude에게 프롬프트를 치지 않으며, 여러 루프가 돌면서 Claude에게 프롬프트를 치고 무엇을 할지 정하고, 자신의 일은 그 루프를 짜는 것이라고 했다. 이것이 루프 엔지니어링이다.

반응은 둘로 갈렸다. 한쪽은 이것이 프롬프트와 컨텍스트를 잇는 다음 추상화 계층이라 환호했고, 다른 한쪽은 “모자를 씌운 크론잡”에 불과하다고 비웃었다. 정해진 시각에 스크립트를 돌리는 오래된 자동화에 새 이름표만 붙였다는 것이다. 그런데 양쪽 다 한 가지를 놓쳤다. 슈타인베르거가 말한 것은 1788년에 와트가 한 일과 정확히 같은 일이다. 사람을 루프에서 빼내는 것. 새로운 용어가 붙었을 뿐, 본질은 한 번의 답이 아니라 반복하는 시스템, 사람이 매번 시키는 것이 아니라 스스로 굴러가는 구조를 만드는 일이다. 솔직히 이것은 줄곧 해온 이야기와 정확히 같은 맥락이다. AI의 가치는 한 방의 똑똑한 답에 있지 않고, 반복을 통해 현장에서 실제로 작동하는 시스템에 있다.

사다리는 모델이 놓았다

이 흐름을 제대로 이해하려면 그것이 어느 날 갑자기 튀어나온 유행이 아니라 하나의 연속된 진화였음을 봐야 한다. 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로, 다시 하네스 엔지니어링을 거쳐 루프 엔지니어링에 이르는 이 사다리는 누군가의 영감으로 발명된 것이 아니다. 모델의 성능이 좋아지고 컨텍스트 윈도우가 넓어짐에 따라, 우리가 할 수 있는 일이 늘어나면서 자연스럽게 한 칸씩 올라온 것이다. 각 단계는 그 시점에 모델이 감당할 수 있었던 능력의 한계선이 그어준 자리다. 사다리를 놓은 것은 사람의 통찰이 아니라 모델의 성장이었다. 그러니 어느 단계가 한물갔다는 식의 선언은 대개 성급하다. 그것은 새 칸이 열렸다는 뜻이지 옛 칸이 무너졌다는 뜻이 아니다.

무엇이 2026년에 와서야 루프를 가능하게 했는가? 세 가지가 동시에 무르익었다. 첫째, 모델이 한 작업을 수십 분씩 자율적으로 밀고 갈 만큼 끈기가 생겼다. 예전에는 몇 번만 주고받아도 길을 잃던 에이전트가 이제는 긴 작업을 끝까지 끌고 간다. 둘째, 컨텍스트 윈도우가 책 한 권 분량을 넘기면서, 여러 번의 시도 기록을 통째로 안고도 일할 수 있게 됐다. 셋째, 도구를 다루는 능력이 안정됐다. 코드를 실행하고 파일을 고치고 외부 시스템에 연결하는 일을 모델이 스스로 판단해 수행한다. 이 셋이 갖춰지기 전에는 루프를 짜고 싶어도 짤 수 없었다. 사람이 한 발짝 물러나는 순간 에이전트가 곧장 무너졌기 때문이다. 능력의 한계선이 위로 올라간 뒤에야 비로소 사람이 그 위에 설 자리가 생겼다. 루프 엔지니어링이 2026년의 화두가 된 것은 누군가 그것을 발명해서가 아니라, 모델이 마침내 사람 없이도 한 바퀴를 돌 수 있게 되었기 때문이다.

처음의 프롬프트 엔지니어링은 의외로 소박한 목적에서 출발했다. 초기 모델은 작고 변덕스러웠기 때문에, 프롬프트는 사실상 헛소리를 막는 용도였다. 어떻게 물으면 덜 틀리는지, 어떤 문장을 앞에 붙이면 엉뚱한 소리를 덜 하는지, 역할을 어떻게 지정하고 예시를 몇 개 끼워 넣어야 모델이 궤도를 벗어나지 않는지를 다듬는 기술이었다. “단계별로 생각해보라”는 한 줄을 붙이면 답이 좋아진다는 식의 요령이 진지하게 공유되던 시절이다. 안드레이 카파시가 “가장 뜨거운 새 프로그래밍 언어는 영어”라고 말한 것이 바로 이 시절의 감각이다. 모델이 무엇을 해야 할지조차 잘 이해하지 못하던 때, 프롬프트는 좋은 답을 끌어내는 일이라기보다 나쁜 답을 막는 일에 가까웠다. 프롬프트 엔지니어링은 모델의 입을 단속하는 기술이었다. 모델이 약할수록 이 단속이 중요했고, 모델이 강해질수록 그 자리는 점점 작아졌다.

모델이 똑똑해지고 윈도우가 조금 넓어지자 다음 칸이 열렸다. 컨텍스트 엔지니어링은 질문을 잘 다듬는 차원을 넘어, 맥락적 데이터를 함께 실어 보낼 수 있게 했다. 관련 문서, 과거 대화, 검색으로 끌어온 자료, 도메인 지식을 입력에 함께 넣자 모델은 비로소 “주어진 상황 위에서” 답하기 시작했다. 검색 결과를 찾아 입력에 붙이는 RAG가 바로 이 단계의 대표 기술이다. 이 용어는 2025년 6월 토비 뤼트케와 안드레이 카파시가 공개적으로 지지하면서 빠르게 자리 잡았다. 카파시는 컨텍스트 엔지니어링을 “다음 단계에 꼭 필요한 정보로 윈도우를 채우는 섬세한 기술이자 과학”이라 불렀다. 그의 비유는 명쾌하다. 모델을 CPU라 한다면 컨텍스트 윈도우는 RAM이다. 프로세서가 아무리 빨라도 RAM에 엉뚱한 데이터가 올라가 있으면 소용이 없다. 무엇을 RAM에 올릴지 결정하는 일, 그것이 컨텍스트 엔지니어링이다. 프롬프트가 모델의 입을 단속하는 기술이었다면, 컨텍스트 엔지니어링은 모델에게 볼 자료를 쥐여주는 기술이다.

이 전환은 단순히 이름만 바꾼 것이 아니었다. 프롬프트가 지시라면 컨텍스트는 그 지시를 수행하는 데 필요한 모든 것이다. 용어가 자리 잡은 지 한 달 만에 1,300편이 넘는 논문을 분석한 첫 학술 서베이가 나오면서 컨텍스트 엔지니어링은 하나의 독립된 분야로 굳어졌다. 좋은 비유는 새 동료를 받아들이는 일이다. 아무리 유능한 사람이라도 회사의 맥락, 지난 결정, 관련 자료를 쥐여주지 않으면 제대로 일하지 못한다. 모델도 마찬가지다. 모델이 똑똑해질수록 부족한 것은 지능이 아니라 맥락이었고, 그 맥락을 어떻게 채우고 무엇을 덜어낼지가 결과를 갈랐다. 너무 적게 넣으면 모델은 정보가 부족해 헤매고, 너무 많이 넣으면 정작 중요한 것이 묻힌다. 적절한 균형을 찾는 일이 새로운 기술이 됐다.

윈도우가 더 커지고 모델이 한층 더 똑똑해지자, 우리는 단발성 응답이 아니라 에이전트가 일하는 환경 자체를 설명할 수 있게 됐다. 이것이 하네스 엔지니어링이다. 하네스란 모델을 감싸는 골격이다. 어떤 도구를 쓸 수 있는지, 어떤 순서로 행동하는지, 실패하면 어떻게 재시도하는지, 무엇을 목표로 삼는지를 규정하는 구조물이다. 이 개념은 하나의 공식으로 압축된다. 에이전트는 모델 더하기 하네스다. 모델은 하나의 입력일 뿐이고, 시스템 프롬프트와 규칙 파일, 도구와 샌드박스, 검증 장치와 복구 경로가 그 주위를 감싼 하네스가 나머지 전부다. 그래서 괜찮은 모델에 훌륭한 하네스를 얹으면, 훌륭한 모델에 엉성한 하네스를 얹은 것을 이긴다. 여기서부터 사람의 일은 좋은 질문 던지기에서 에이전트가 일하는 방식을 설계하기로 옮겨간다. 모델이 충분히 커진 덕에, 답을 받는 것이 아니라 행동의 규칙과 환경을 통째로 설명해줄 수 있게 된 것이다.

하네스 엔지니어링에는 인상적인 원리가 하나 있다. 래칫 원리라 불리는 것이다. 에이전트가 실수를 저지를 때마다 그 실수를 다시는 반복하지 못하도록 하네스에 규칙을 새긴다. 한번 조여진 하네스는 결코 풀리지 않는다. AGENTS.md나 CLAUDE.md 같은 기억 파일에 규칙이 한 줄씩 쌓이고, 에이전트는 시작할 때마다 그 파일을 읽으며 과거의 교훈을 물려받는다. 이것은 사고방식 자체의 전환이다. 이전에는 에이전트가 무엇을 할지를 사람이 일일이 정해주었다면, 이제는 에이전트가 움직일 수 있는 제약의 경계만 정해주고 그 안에서 무엇을 할지는 모델이 스스로 판단하게 한다. 명령에서 환경으로, 지시에서 설계로 무게중심이 옮겨간다. 사람은 더 이상 매 순간의 행동을 통제하지 않고, 행동이 일어나는 무대를 만든다.

그리고 마지막으로, 모델과 윈도우가 한 작업을 끝까지 자율적으로 밀고 갈 만큼 성숙하자 루프 엔지니어링이 등장했다. 하네스가 한 번의 작업을 어떻게 수행할지를 설계하는 일이라면, 루프는 그 작업을 목표가 진짜로 달성될 때까지 스스로 반복하게 만드는 일이다. 행동하고, 결과를 관찰하고, 무엇을 할지 판단하고, 다시 행동한다. 이 단계에 이르러 비로소 완벽에 가까운 자동화가 가능해졌다. 사람이 루프 안에 들어가 매번 프롬프트를 치는 것이 아니라, 루프가 사람을 대신해 에이전트를 굴리고, 사람은 루프 바깥에서 그 구조를 설계하는 자리로 올라선다. 1788년에 사람이 밸브 앞에서 물러나 조속기에게 자리를 내준 것과 정확히 같은 이동이다.

네 단계의 차이를 한 줄로 꿰면 이렇게 정리된다. 프롬프트 엔지니어링은 모델의 출력을 단속하는 일이었고, 컨텍스트 엔지니어링은 모델에게 볼 자료를 공급하는 일이었으며, 하네스 엔지니어링은 모델이 행동하는 방식을 규정하는 일이고, 루프 엔지니어링은 그 행동을 완결될 때까지 자율적으로 반복하게 하는 일이다. 앞의 둘이 한 번의 응답을 어떻게 더 좋게 만들 것인가의 문제였다면, 뒤의 둘은 에이전트가 어떻게 스스로 일하게 할 것인가의 문제다. 정확히 이 지점에서 사람의 역할이 입력을 만드는 사람에서 시스템을 설계하는 사람으로 질적으로 달라진다.

사실 루프 자체는 전산학에서 가장 오래된 개념이다. 모든 프로그램은 조건이 만족될 때까지 같은 동작을 반복하는 루프로 짜인다. 그러니 루프라는 단어에 새로움은 없다. 새로운 것은 루프 안에서 도는 것의 정체다. 전통적인 루프 안에서 도는 것은 정해진 명령이었다. 같은 입력에는 늘 같은 출력이 나오고, 한 바퀴가 무엇을 할지는 프로그래머가 미리 못 박아 두었다. 그러나 루프 엔지니어링의 루프 안에서 도는 것은 판단하는 에이전트다. 매 바퀴마다 무엇을 할지 그 자리에서 새로 정하고, 같은 상황에서도 다른 선택을 할 수 있다. 정해진 명령을 반복하는 것과 판단을 반복하는 것은 전혀 다른 일이다. 모자 쓴 크론잡이라는 조롱이 절반만 맞는 이유가 여기 있다. 겉보기에는 같은 반복이지만, 반복되는 알맹이가 죽은 명령에서 살아 판단하는 행위자로 바뀌었다. 같은 원을 돌더라도, 그 원을 도는 것이 톱니바퀴인지 사람인지에 따라 전혀 다른 기계가 되는 것과 같다.

포함하며 올라간다

이 진화에서 가장 자주 오해받는 대목이 하나 있다. 위 칸으로 올라가면 아래 칸이 쓸모없어진다는 생각이다. 루프의 시대가 왔으니 프롬프트는 죽었다는 식의 선언이 매번 반복된다. 그러나 실제 구조는 정반대다. 이 사다리는 위로 갈수록 아래를 버리는 것이 아니라 포함하며 올라간다. 좋은 루프 안에는 여전히 좋은 하네스가 있고, 좋은 하네스 안에는 잘 관리된 컨텍스트가 있으며, 그 안에는 여전히 잘 다듬어진 프롬프트가 있다. 사다리의 가장 높은 칸에 서 있다고 해서 아래 칸이 사라지는 것이 아니다. 다만 우리의 손이 닿는 추상화의 고도가 한 단계씩 올라갈 뿐이다.

조속기를 다시 떠올려보면 이해가 쉽다. 조속기가 사람을 밸브에서 빼냈다고 해서 밸브가 사라진 것이 아니다. 밸브는 여전히 그 자리에서 증기를 조절하고, 다만 그것을 여닫는 손이 사람에서 쇠공으로 바뀌었을 뿐이다. 마찬가지로 루프가 사람을 키보드에서 빼냈다고 해서 프롬프트가 사라진 것이 아니다. 프롬프트는 여전히 매 순간 에이전트에게 전달되며, 다만 그것을 작성하는 주체가 사람에서 루프로 바뀌었을 뿐이다. 슈타인베르거가 프롬프트를 치지 말라고 했을 때, 그것은 프롬프트가 필요 없어졌다는 뜻이 아니라 프롬프트를 치는 일을 사람이 직접 할 필요가 없어졌다는 뜻이다. 프롬프트는 죽지 않았다. 자동화됐을 뿐이다.

이 포함 관계를 이해하면 추상화 계층이 왜 중요한지 보인다. 추상화란 아래층의 복잡함을 감추고 위층에서 더 큰 단위로 사고하게 해주는 장치다. 프로그래머가 기계어를 직접 짜지 않고 고급 언어로 일하는 것, 운전자가 연료 분사 타이밍을 계산하지 않고 액셀을 밟는 것과 같다. 아래층이 사라진 것이 아니라 잘 동작하기에 신경 쓸 필요가 없어진 것이다. 루프 엔지니어링이 가능해졌다는 것은 그 아래의 하네스와 컨텍스트와 프롬프트가 충분히 안정적으로 동작하게 됐다는 뜻이다. 토대가 흔들리면 그 위에 아무것도 올릴 수 없다. 가장 높은 칸에 설 수 있다는 사실 자체가 아래 칸들이 단단해졌다는 증거다. 거꾸로 말하면, 아래가 부실한 채로 위로만 올라가려는 시도는 반드시 무너진다. 검증되지 않은 컨텍스트 위에 세운 루프는 빠르게 틀린 답을 향해 달려갈 뿐이다.

컴퓨팅의 역사 전체가 이 사다리의 반복이었다. 초기 프로그래머는 0과 1로 이루어진 기계어를 직접 다뤘다. 어셈블리어가 나오면서 사람은 그 위로 한 칸 올라섰고, C와 고급 언어가 나오면서 또 한 칸 올라섰으며, 프레임워크와 라이브러리가 나오면서 다시 한 칸 올라섰다. 그때마다 아래층이 사라진 것이 아니라, 잘 동작하기에 신경 쓸 필요가 없어졌을 뿐이다. 오늘도 모든 고급 언어는 결국 기계어로 번역되어 돈다. 사람은 매번 더 큰 단위로 사고하는 자리로 올라갔고, 기계는 매번 더 많은 세부를 떠맡았다. 프롬프트에서 루프로 이어지는 사다리는 이 오래된 이야기의 가장 최근 장면일 뿐이다. 다른 점이 있다면, 이번에 사람이 위임하는 것은 계산의 세부가 아니라 판단과 반복 그 자체라는 것이다. 기계가 이제 사람을 대신해 다음에 무엇을 할지 정하기 시작했다는 점에서, 이 한 칸은 이전의 어느 칸보다 멀다.

이 변화는 공장에 빗댈 수 있다. 이제 우리는 더 이상 코드를 쓰는 사람이 아니라, 코드를 만드는 공장을 짓는 사람이라는 것이다. 그 공장은 에이전트의 무리로 채워진다. 각 에이전트는 맡은 과제와 도구상자, 명세와 제약이라는 컨텍스트, 그리고 피드백 회로를 갖는다. 한 에이전트가 백엔드를 리팩터링하는 동안 다른 에이전트가 기능을 구현하고, 또 다른 에이전트가 테스트를 돌린다. 단 하나의 에이전트를 하나의 과제 위로 손잡아 끌고 가는 대신, 여러 에이전트를 병렬로 띄워 공장을 가동한다. 사람의 일은 부품을 깎는 것에서 생산 라인을 설계하는 것으로 바뀐다. 와트가 밸브를 깎는 장인에서 자기조절 기관을 설계하는 공학자로 올라섰듯이.

공장에는 공장만의 새로운 문제가 따라온다. 혼자 일하던 개발자에게는 가끔 거슬리는 예외에 불과했던 불안정한 테스트가, 마흔 개의 에이전트가 동시에 같은 테스트를 두드리는 순간 시스템 전체를 멈추는 병목이 된다. 한 대를 손으로 다룰 때는 그냥 넘어가던 결함이 병렬로 확장되는 순간 치명적으로 드러난다. 공장을 짓는 일은 부품을 깎는 일보다 어렵다. 개별 작업의 품질이 아니라 작업들이 서로 부딪히지 않고 흐르는 구조를 설계해야 하기 때문이다. 한 작업의 성공이 아니라 전체의 안정성이 새로운 목표가 된다.

여기서 한 가지 불편한 진실이 따라온다. 추상화의 고도가 올라갈수록 요구되는 능력은 줄어드는 것이 아니라 오히려 까다로워진다. 손으로 코드를 짤 때 필요한 것은 문법과 타이핑 속도였지만, 마흔 개의 에이전트가 동시에 돌아가는 공장을 설계할 때 필요한 것은 시스템 사고다. 복잡한 구조를 머릿속에 담고, 한 부분의 변화가 다른 곳에 어떤 파장을 일으킬지 예측하는 능력. 거대하고 모호한 목표를 에이전트가 안정적으로 수행할 만한 크기로 쪼개는 문제 분해 능력. 그리고 그 분해가 옳았는지 검증하는 안목. 너무 큰 과제는 길을 잃고, 너무 모호한 과제는 엉뚱하게 해석된다. 잘 쪼개고 그 쪼갬이 옳았는지 확인하는 일은 그 자체로 하나의 기예다. 루프가 사람을 단순 노동에서 해방한 대가로, 사람에게는 더 높은 차원의 판단을 요구한다. 사다리를 오를수록 일이 쉬워지는 것이 아니라, 일의 성격이 달라진다.

아니오라고 말할 수 있는 무언가

루프가 실제로 어떻게 도는지는 의외로 단순하다. 에이전트에게 모든 테스트를 통과시키라는 목표를 준다. 에이전트는 코드를 한 번 고치고, 테스트를 돌리고, 세 개가 실패한 것을 확인하고, 실패 메시지를 읽고, 다시 코드를 고치고, 또 테스트를 돌린다. 실패가 둘로 줄고, 하나로 줄고, 마침내 모두 통과하는 순간 루프는 스스로 멈춘다. 사람은 이 과정에 한 번도 끼어들지 않는다. 처음에 목표와 멈출 조건을 정해주었을 뿐이다. 예전 같으면 사람이 테스트 결과를 보고 다음에 무엇을 고칠지 매번 일러주어야 했던 일을, 이제는 루프가 통째로 떠맡는다. 이 단순한 한 바퀴가 수십 번, 수백 번 자율적으로 도는 것이 루프 엔지니어링의 실체다.

그렇다면 루프는 아무렇게나 짜도 되는가? 그렇지 않다. 잘못 설계된 루프는 토큰을 태우고, 영원히 돌고, 진전이 없는데도 진전했다고 착각한다. 이것이 비판자들이 모자 쓴 크론잡이라 비웃는 지점이고, 절반은 맞는 말이다. 종료 조건도 검증도 없는 루프는 정말로 비싼 크론잡에 지나지 않는다. 좋은 크론잡과 좋은 루프를 가르는 것은 정해진 시각에 돌아가느냐가 아니라, 목표를 향해 스스로 판단하고 멈출 줄 아느냐다. 좋은 루프는 네 가지를 갖춰야 한다.

첫째는 명확한 종료 조건이다. “앱을 더 좋게 만들어”는 무한 루프를 낳지만 “모든 단위 테스트를 통과시켜”는 진짜 출구를 준다. 앞의 명령에는 끝이 없다. 더 좋게 만드는 일에는 한계가 없으므로 에이전트는 영원히 무언가를 고치며 돈다. 뒤의 명령에는 분명한 결승선이 있다. 테스트가 전부 초록색이 되는 순간 루프는 멈춘다. 출구가 없는 루프는 목적지 없이 키를 놓아버린 배와 같다. 끝을 정의하지 못한 자동화는 자동화가 아니라 방치다. 루프를 짜는 일의 절반은 어디서 멈출지를 정하는 일이다.

둘째는 환경과 상호작용하는 도구다. 에이전트가 자기 코드를 직접 실행해보지 못하면 그 루프는 추측에 불과하다. 코드를 돌려 결과를 보고, 파일을 읽고, 명령을 실행하고, 외부 시스템에 연결할 수 있어야 비로소 에이전트는 자기 행동의 결과를 마주한다. 손을 쓰지 못하는 지능은 머릿속으로만 굴러간다. 머릿속으로만 짠 코드가 실제로 돌아갈지는 아무도 모른다. 직접 실행해 에러를 보고 고치는 순환이 있어야 추측은 검증으로 바뀐다. 도구가 있어야 루프는 세계와 닿는다.

셋째는 컨텍스트 관리다. 반복할수록 맥락이 쌓이므로, 이전 시도를 압축해 작업 기억으로 요약하고 불필요한 것은 쳐내야 한다. 윈도우가 가득 차도록 내버려 두면 루프는 자기가 무엇을 하려 했는지조차 잊는다. 수십 번의 시도가 그대로 쌓이면 정작 지금 중요한 것이 과거의 잡음에 묻힌다. 좋은 루프는 무엇을 기억하고 무엇을 버릴지 끊임없이 정리하면서 돈다. 기억의 위생이 곧 루프의 지속 가능성이다.

넷째이자 가장 중요한 것은, 루프 안에 “아니오”라고 말할 수 있는 무언가를 넣는 일이다. 테스트, 타입 체크, 진짜 에러. 반박할 것이 없는 루프는 에이전트가 혼자 자기 말에 동의하기를 무한히 반복하는 것일 뿐이다. 스스로 코드를 짜고, 스스로 잘했다고 평가하고, 스스로 다음으로 넘어간다면, 그것은 일하는 것이 아니라 자기최면을 거는 것이다. 여기서 와트의 조속기가 정확히 같은 말을 한다. 조속기의 본질은 기관에 속도를 주는 것이 아니라, 기관이 너무 빨라졌을 때 밸브를 잠그는 데 있었다. 그 잠그는 행위가 곧 아니오라고 말하는 것이었다. 그 되먹임이 없으면 기관은 폭주해 스스로를 부순다. 검증 장치가 없는 루프도 똑같이 폭주한다. 진전 없는 반복으로 토큰을 태우며 자기 환각 속을 끝없이 맴돈다. 피드백이 루프를 신뢰할 수 있게 만든다. 아니오라고 말하는 장치가 없는 자동화는 자동화가 아니라 폭주의 다른 이름이다.

이 네 번째 조건은 공학을 넘어 인식의 문제로 이어진다. 칼 포퍼는 반증할 수 없는 주장은 과학이 아니라고 했다. 어떤 결과가 나와도 옳다고 우길 수 있는 이론은 사실 아무것도 설명하지 못한다. 루프도 똑같다. 무엇을 만들어도 스스로 통과시키는 루프, 어떤 결과에도 아니오라는 답이 돌아오지 않는 루프는 일하는 것처럼 보이지만 아무것도 검증하지 못한다. 에이전트가 자기 코드를 짜고 자기 리뷰를 통과시켜 망가진 코드를 배포하는 장면은 드물지 않다. 그래서 루프 안의 아니오는 반드시 에이전트 바깥에서 와야 한다. 사람이 미리 짜둔 테스트, 타입 체커, 운영 환경에서 실제로 터지는 에러처럼, 에이전트가 제 입맛대로 바꿀 수 없는 단단한 기준이어야 한다. 반증 가능성이 과학을 과학으로 만들듯, 반박 가능성이 루프를 신뢰할 수 있게 만든다.

되먹임을 넣는다고 모든 문제가 풀리는 것은 아니다. 맥스웰이 굳이 조속기를 수학으로 분석한 진짜 이유가 여기 있었다. 당시 조속기 중 일부는 안정적으로 속도를 유지했지만, 일부는 끊임없이 흔들렸다. 너무 빨라지면 밸브를 과하게 잠갔다가, 그러면 너무 느려져 다시 과하게 열고, 빨라졌다 느려졌다를 반복하며 떨었다. 기술자들은 이 현상을 헌팅이라 불렀다. 되먹임이 있는데도 기계가 한 점에 머물지 못하고 양극단을 오가는 것이다. 맥스웰이 밝힌 것은 되먹임의 유무가 아니라 되먹임의 세기와 시점이 안정성을 가른다는 사실이었다. 너무 세게, 너무 늦게 교정하면 시스템은 진정되기는커녕 진동한다. 루프도 똑같이 헌팅한다. A를 고치면 B가 깨지고 B를 고치면 다시 A가 깨지는 일을 영원히 반복하는 에이전트를 본 적이 있을 것이다. 검증 장치를 넣었는데도 루프가 두 상태 사이를 오가며 수렴하지 못한다면, 그것은 되먹임이 없어서가 아니라 되먹임이 잘못 조율되었기 때문이다. 아니오라고 말하는 장치를 넣는 것만으로는 부족하다. 그 아니오가 시스템을 한 점으로 수렴시키는 방향으로 작동해야 한다. 좋은 검증은 틀렸다고 말하는 데 그치지 않고 어디가 얼마나 틀렸는지를 알려주어, 루프가 다음 바퀴에서 과녁에 더 가까이 가게 한다.

이 네 가지를 갖췄을 때 비로소 루프는 크론잡과 갈라선다. 종료 조건이 목적지를 정하고, 도구가 세계와 닿게 하고, 컨텍스트 관리가 기억을 지키고, 검증 장치가 폭주를 막는다. 이 넷이 맞물려 돌아갈 때 루프는 사람이 종일 밸브를 여닫던 일을 대신하는 조속기가 된다. 그제야 사람은 루프 바깥으로 걸어 나갈 수 있다.

그렇다고 모든 일을 루프로 만들어야 하는 것은 아니다. 루프가 비용을 회수하는 조건은 분명하다. 같은 종류의 작업이 반복되고, 그 결과를 자동으로 검증할 수 있고, 낭비되는 토큰을 감당할 예산이 있고, 에이전트가 숙련된 엔지니어가 쓸 법한 도구를 이미 갖추고 있을 때다. 이 가운데 하나라도 빠지면 루프는 얻는 것보다 더 많은 비용을 쓴다. 한 번만 하면 되는 일, 검증이 불가능한 일, 판단의 책임이 무거운 일까지 굳이 루프로 감쌀 이유는 없다. 조속기가 모든 기계에 필요했던 것이 아니라 일정한 속도를 오래 유지해야 하는 기계에 필요했던 것처럼, 루프도 반복과 검증이 핵심인 일에서 가장 큰 힘을 낸다. 도구를 손에 쥐었다고 모든 것을 그 도구로 두드릴 일은 아니다. 무엇을 루프에 맡기고 무엇을 사람의 손에 남길지 가르는 판단이, 루프를 짜는 능력만큼이나 중요한 능력이 된다.

사람이 병목이다

이 모든 이야기의 밑바닥에는 단순한 문제의식이 하나 깔려 있다. 사람이 병목이라는 것이다. 모델이 아무리 똑똑해지고 윈도우가 아무리 넓어져도, 매번 사람이 프롬프트를 쳐서 시켜야만 움직인다면 시스템 전체의 속도는 결국 사람의 손이 닿는 속도에 묶인다. 1788년의 증기기관이 사람이 밸브를 여닫는 속도에 묶여 있던 것과 같다. 기계는 사람보다 빠를 수 있었지만, 사람이 루프 안에 들어가 있는 한 그 빠름은 발휘되지 못했다. 루프 엔지니어링은 그 병목을 루프로 대체한다는 발상이다. 사람을 루프에서 빼내, 사람만이 할 수 있는 일, 즉 목적을 정의하고 구조를 설계하는 자리로 올려 보낸다.

역사는 같은 장면을 여러 번 보여주었다. 헨리 포드가 조립 라인을 도입했을 때, 그는 노동자를 더 빠르게 움직이게 만든 것이 아니라 노동자가 한자리에 서 있고 작업이 흘러오게 만들었다. 사람이 차를 따라다니는 대신, 차가 사람 앞으로 흘러오고 각자는 자기 자리에서 정해진 일만 했다. 병목은 사람의 이동에 있었고, 그 병목을 컨베이어가 대신했다. 생산성은 사람을 더 다그쳐서가 아니라 사람을 구조의 올바른 자리에 놓아서 폭발했다. 루프 엔지니어링이 하려는 것도 다르지 않다. 사람을 더 빠르게 프롬프트를 치게 만드는 것이 아니라, 프롬프트를 치는 일 자체를 사람에게서 들어내 시스템에 맡기는 것이다. 사람은 그렇게 비워진 손으로 더 높은 일을 한다.

여기서 자연스러운 불안이 따라온다. 루프가 일을 떠맡으면 사람에게는 무엇이 남는가? 와트의 조속기가 밸브를 여닫던 사람의 일을 없앤 것은 사실이다. 그러나 그 시대에 사라진 것은 밸브 옆에 종일 서 있는 일이었지, 공장을 짓고 무엇을 생산할지 정하는 일이 아니었다. 오히려 조속기가 한 사람이 여러 기계를 거느릴 수 있게 풀어주면서, 기계를 설계하고 공정을 짜는 더 높은 일이 폭발적으로 늘었다. 루프도 같은 자리에 서 있다. 사라지는 것은 키보드 앞에 붙어 매번 프롬프트를 치는 일이고, 늘어나는 것은 무엇을 만들지 정하고 루프를 설계하고 그 결과를 책임지는 일이다. 다만 이 이동이 모두에게 자동으로 좋은 것은 아니다. 밸브를 여닫던 사람이 공장을 설계하는 사람으로 곧장 올라서지는 못했듯, 프롬프트를 치던 손이 루프를 짜는 머리로 저절로 바뀌지는 않는다. 그 사이의 간극을 건너는 일은 끝내 각자의 몫으로 남는다. 도구가 사람을 밀어 올려 주기를 기다리는 사람과, 도구가 열어준 높은 자리로 스스로 걸어 올라가는 사람의 차이가 그 어느 때보다 크게 벌어진다.

이것은 추상적인 이야기가 아니다. 현장에서 직접 굴려 본 결과다. 최근에 맡은 한 프로젝트에서 3개월 동안 매주 분석과 개발, 배포와 피드백의 사이클을 반복했는데, 이 사이클 자체가 곧 하나의 루프였다. 현장에 전진 배치된 엔지니어가 과제를 발굴하고 운영 지식을 체계화하며 부서마다 제각각이던 표현 400건을 하나의 사전으로 정리한 것은, 루프 안에 아니오라고 말할 수 있는 검증 장치를 심는 작업이었다. 현장의 정책과 도메인 지식이 곧 그 루프의 조속기였다. 하네스를 계속 다듬은 것이 하네스 엔지니어링이었고, 컨텍스트가 일정 수준에 도달하면 자동으로 요약하고 압축하게 만든 것이 컨텍스트 관리였으며, 이 모든 사이클을 반복 가능한 구조로 묶은 것이 루프 엔지니어링이었다. 새 용어가 등장하기 전부터 이미 같은 일을 하고 있었던 셈이다. 용어는 현상을 뒤따라 붙는 이름표일 뿐, 현상 자체는 늘 먼저 와 있었다.

그 프로젝트에서 얻은 가장 중요한 교훈은 자동화의 대상이 작업이 아니라 반복이었다는 점이다. 한 번의 분석, 한 번의 개발, 한 번의 배포를 자동화하는 것은 어렵지 않다. 진짜 어려운 것은 분석에서 나온 결과가 다음 개발의 입력이 되고, 배포에서 얻은 피드백이 다시 다음 분석의 입력이 되는 그 순환 전체를 끊기지 않게 잇는 일이었다. 작업 하나하나는 누구나 자동화할 수 있다. 그러나 그 작업들을 목표가 달성될 때까지 스스로 돌아가는 하나의 순환으로 묶는 일, 그리고 그 순환이 헛돌지 않도록 매 바퀴마다 현장의 검증을 통과하게 만드는 일이 루프 엔지니어링의 본령이었다. 한 점이 아니라 원을 설계하는 일이다. 점을 잘 찍는 사람은 많지만, 점들이 스스로 원을 그리며 돌게 만드는 사람은 드물다.

루프가 충분히 성숙하면 그다음 단계가 보인다. 루프가 스스로 자신의 하네스와 모델 사용 방식을 개선하기 시작하는 자기개선 루프다. 에이전트가 같은 실수를 반복하면 그 실수를 막는 규칙을 하네스에 영구히 새기고, 그 규칙이 다음 루프부터 자동으로 적용된다. 앞서 말한 래칫 원리가 이것이다. 하네스는 조여지기만 할 뿐 결코 풀리지 않는다. 모든 실수가 영구적인 개선으로 남으니, 루프는 돌수록 똑똑해진다. 사람이 매번 같은 잔소리를 반복하지 않아도 시스템이 스스로 단단해지는 구조다. 이쯤 되면 사람의 일은 거의 전적으로 설계의 영역으로 옮겨간다. 무엇을 고칠지 일러주는 대신, 무엇이 잘못됐는지 스스로 발견하고 고치는 구조를 만든다.

비용의 무게중심도 함께 이동한다. 이제 비싼 것은 호출당 토큰이 아니라 루프 관리와 폭주하는 반복이다. 잘못 짠 루프 하나가 밤새 돌며 청구서를 부풀린다. 그래서 반복 횟수에 상한을 두고, 진전 없음을 감지하고, 예산을 설정한다. 루프를 멈출 줄 아는 것이 루프를 돌리는 것만큼 중요해진다. 여기서도 조속기의 교훈이 그대로 살아 있다. 자동 제어의 핵심은 가속이 아니라 제동이었다. 폭주를 막는 장치가 없으면 빠른 기계는 축복이 아니라 재앙이 된다. 빠르게 도는 루프일수록 멈추는 법을 더 정교하게 설계해야 한다.

비용의 문제에는 불편한 비대칭도 숨어 있다. 토큰이 넉넉한 쪽은 루프를 마음껏 돌리며 낭비를 감수하고도 빠르게 전진하지만, 토큰이 빠듯한 쪽은 같은 루프를 돌릴 엄두조차 내지 못한다. 루프 엔지니어링이 열어준 생산성의 도약이 누구에게나 평등하게 주어지지는 않는다는 뜻이다. 그래서 좋은 루프 설계는 단지 빠른 루프를 만드는 일이 아니라, 적은 토큰으로도 같은 목표에 도달하는 효율적인 루프를 만드는 일이기도 하다. 반복할 때마다 모든 것을 처음부터 다시 계산하는 루프는 돈을 태우지만, 잘 정리된 도구와 기억을 재사용하는 루프는 돌수록 싸진다. 결국 절약도 설계의 문제다.

결국 핵심은 단순하다. 모델이 똑똑해지고 윈도우가 넓어질 때마다 우리의 일은 한 칸씩 위로 올라왔고, 이제 그 끝에서 우리는 프롬프트를 치는 사람이 아니라 루프를 짜는 사람이 된다. 목적을 한 번 정의하고, 검증할 수 있는 피드백을 루프 안에 넣고, 일이 진짜 끝날 때까지 시스템이 스스로 돌게 하라. 작동하는 AX의 정체가 바로 이것이다. 똑똑한 한 번의 답이 아니라, 반복 속에서 스스로 답을 찾아가는 루프다.

위너가 사이버네틱스라는 이름을 그리스어 키잡이에서 따왔다는 사실을 기억하는가? 그 단어 kubernetes는 오늘날 우리가 컨테이너를 다루는 도구의 이름으로 매일 부르는 그 단어이기도 하다. 자동 제어의 역사는 처음부터 키잡이의 역사였다. 그리고 좋은 키잡이는 노를 직접 젓는 사람이 아니라, 배가 어디로 가야 하는지 정하고 폭주하지 않도록 키를 설계한 뒤 손을 떼는 사람이다. 와트가 밸브에서 손을 떼고, 슈타인베르거가 키보드에서 손을 떼는 동안, 변하지 않은 것이 하나 있다. 항로를 정하는 일은 끝내 사람의 몫으로 남는다는 것이다. 어디로 갈지를 모르는 루프는 아무리 정교해도 빠르게 길을 잃을 뿐이다. 루프를 짜는 사람은 일에서 물러난 사람이 아니라, 가장 높은 자리로 올라간 사람이다. 손을 떼는 일과 책임을 내려놓는 일은 다르다. 사람은 키보드에서 손을 떼지만, 키에서는 결코 손을 떼지 않는다.