“나는 더 이상 Claude에게 프롬프트를 넣지 않는다. Claude에게 프롬프트를 넣고 무엇을 할지 알아내는 루프를 돌릴 뿐이다. 내 일은 루프를 짜는 것이다.” Claude Code를 만든 Boris Cherny의 말입니다. 그런데 이 말을 자기 글 맨 앞에 인용한 개발자는, 정작 “나는 아직 이걸 잘 못한다”고 고백합니다.
Flask와 Jinja를 만든 개발자 Armin Ronacher가 “The Coming Loop”이라는 글을 발표했습니다. 요즘 개발자 사이에서 빠르게 번지는 ‘루프(loop)’ 방식, 즉 코딩 에이전트 위에 또 한 겹의 자동화를 얹어 사람 개입 없이 작업을 계속 돌리는 흐름에 대한 기록입니다. 그는 이 흐름이 분명히 다가온다는 데 동의하면서도, 환영하기보다 망설입니다. 그 망설임의 근거가 이 글의 핵심입니다.
출처: The Coming Loop – Armin Ronacher
두 개의 루프, 무엇이 새로운가
먼저 용어를 정리하면 이해가 쉬워집니다. 사실 코딩 에이전트 안에는 이미 루프가 하나 들어 있습니다. 모델이 도구를 부르고, 결과를 반영하고, 파일을 읽고 고치고, 테스트를 돌리고, 답을 내놓는 과정이죠. 우리가 오래 봐온 익숙한 ‘에이전트 루프’입니다.
요즘 화제가 되는 건 그 바깥을 한 겹 더 감싸는 루프입니다. Ronacher는 이 바깥 장치를 ‘하네스(harness)’라고 부릅니다. 에이전트에게 일을 시키고, 결과를 받아보고, 다시 일을 시킬지 말지 결정하는 관리자 역할이라고 보면 됩니다.
작동 방식을 단계로 따라가 보겠습니다.
- 작업을 대기열에 넣으면 에이전트가 하나를 집어 들어 처리합니다.
- 에이전트는 평소처럼 일하다가 “다 됐다”며 멈춥니다. (여기까지는 에이전트 루프와 같습니다.)
- 바깥의 하네스가 그 결과를 보고 “이게 정말 끝인가”를 다시 판단합니다.
- 아직 아니라고 보면, 같은 대화를 이어서 추가 지시를 넣거나, 맥락을 바꿔 새 대화를 처음부터 시작하거나, 아예 다른 기계에 작업을 넘깁니다.
핵심은 여기 있습니다. 보통은 모델이 “끝”이라고 말하면 사람이 받아서 검토합니다. 그런데 하네스 루프에서는 그 “끝” 신호를 사람이 아니라 또 다른 기계가 받아서, 계속할지 멈출지를 정합니다. 모델이 스스로 멈춘 지점을 넘어 작업이 계속 살아 있게 되는 겁니다. Ronacher는 이 방식 자체는 새롭지 않다고 짚습니다. Claude Code 초기부터 있던 패턴이지만, 최근 들어 부쩍 흔해지면서 개발자 사이 화제를 장악했다는 거죠.
어디서 통하고, 어디서 위험한가
Ronacher의 글이 흥미로운 건 루프를 무작정 띄우지 않는다는 점입니다. 그는 루프가 이미 놀랍도록 잘 작동하는 영역이 있다고 인정합니다. 한 언어에서 다른 언어로 코드를 옮기는 포팅, 여러 실험을 돌려보고 벤치마크로 거르는 성능 탐색, 보안 스캔 같은 작업입니다. 실제로 Bun을 Zig에서 Rust로 옮기는 작업이나 그가 직접 한 라이브러리 포팅이 그런 사례죠.
이 영역들엔 공통점이 있습니다. 새 코드를 짜기보다 이미 있는 코드를 변환하거나, 오래 유지할 필요가 없는 결과물(개념 검증, 아이디어, 조사 결과)을 만든다는 점입니다. 기계적으로 검증 가능하고 수명이 짧은 일에 루프가 빛을 발한다는 뜻입니다. 하네스는 다음 반복을 돌릴 ‘신호’만 있으면 되는데, 이런 작업은 그 신호를 만들기 쉽습니다. 그 신호가 꼭 객관적이거나 명확할 필요도 없습니다. 다음 한 바퀴를 돌릴 만큼만 쓸모 있으면 됩니다.
문제는 오래 유지해야 할 핵심 코드입니다. Ronacher는 현재 모델이 짜는 코드가 지나치게 방어적이고, 복잡하고, 국소적이라고 봅니다. 강한 불변 조건(invariant)을 세우는 대신 예외 처리를 덧붙이고, 잘못된 상태를 애초에 불가능하게 만들기보다 그때그때 막아내는 식이죠. Andrej Karpathy의 표현을 빌리면 모델은 “예외를 극도로 무서워”합니다.
이 습성을 루프에 넣으면 증폭됩니다. 반복할 때마다 작은 방어가 하나씩 쌓이면, 시스템은 겉으로는 더 견고해 보이지만 속으로는 점점 이해하기 어려워집니다. 사람이 덜 개입할수록 이 현상은 심해집니다. Ronacher는 오히려 지금의 하네스가 작년 가을보다 못한 코드를 내놓는다고 느낀다고 적습니다. 30분 넘게 사람 손을 거치지 않고 혼자 문제를 붙들고 있기 때문입니다.
소프트웨어가 기계에서 유기체로
Ronacher가 가장 깊이 우려하는 건 코드 품질 자체보다 ‘이해의 상실’입니다. 그는 자신이 기계를 이해하도록 배운 환경에서 엔지니어가 되었다고 말합니다. 한 겹을 벗기면 그 아래를 이해할 수 있는 층이 늘 있었고, 불변 조건이 어디 사는지, 어느 부분이 하중을 견디는지 아는 엔지니어가 있는 시스템이 좋은 시스템이었습니다.
그런데 코드가 루프로 만들어지고, 루프로 검토되고, 루프로 패치되고, 루프로 유지된다면, 그 코드를 더 이상 사람이 머릿속에 담지 못하게 됩니다. 그는 소프트웨어가 ‘결정론적 기계’에서 ‘유기체’로 옮겨간다는 비유를 씁니다. 우리는 시스템을 관찰하고, 모니터링하고, 안정시키지만, 더 이상 완전히 이해하지는 못하는 상태가 되는 겁니다. 마치 의사가 분산 시스템의 증상을 보고 가설을 세우고 “검사를 더 해보자”며 처방하듯, 이제 코드마저 그렇게 다루게 된다는 이야기입니다.
더 불편한 건 이 흐름에서 완전히 빠져나오기 어렵다는 점입니다. 내가 루프를 안 써도, 다른 사람은 내 소프트웨어를 향해 루프를 돌립니다. 보안이 대표적입니다. 공격자와 보안 연구자가 기계를 쉬지 않고 돌리면, 진짜 취약점과 잡음이 감당 못 할 양으로 밀려옵니다. 결국 방어하는 쪽도 기계로 맞설 수밖에 없어집니다. Ronacher는 curl 메인테이너들이 이미 대부분 AI가 만들어낸 보안 리포트에 짓눌리고 있는 현실을 예로 듭니다. 경쟁도 마찬가지여서, 다섯 명이 예전의 쉰 명 몫을 해내는 팀이 등장합니다.
메신저로 남지 않으려면
그가 정말 두려워하는 건 새로운 의존성입니다. 코드베이스가 기계의 참여를 유지보수 모델의 일부로 전제하게 되면, 그 기계에 대한 접근이 끊겼을 때 무슨 일이 벌어질까요. 트레이드 제한으로 강력한 모델을 못 쓰게 되거나, 비용을 감당 못 하게 되거나, 팀이 기계 없이 코드를 이해하는 마지막 능력마저 잃는다면 말입니다. 단순히 지갑에 대한 의존을 넘어, 인지적 의존이 생긴다는 겁니다.
그래서 Ronacher가 도달한 결론은 체념도 환영도 아닙니다. 루프를 할 것인가는 더 이상 질문이 아니라고 그는 말합니다. 분명히 하게 될 테니까요. 하네스 루프에서는 “완료” 신호조차 또 다른 기계에 전달될 뿐이어서, 자기 역할이 메신저로 줄어드는 것 같다고 그는 적습니다. 진짜 질문은 그 안에서 어떻게 판단을 포기하지 않을 것인가, 좋은 엔지니어링의 원칙을 어떻게 지킬 것인가, 책임 있는 사람이 어떻게 계속 감독할 수 있을 것인가입니다. 루프가 우리의 미래라는 걸 인정하면서도, 그 미래를 어떻게 ‘경계가 있고 버틸 만한’ 것으로 만들지를 그는 묻고 있습니다.
답글 남기기