루프 엔지니어링: 손을 떼도 스스로 굴러가는 코딩 에이전트 루프 설계하기
해당 블로그는 Hendrik Krack 원저자의 글 'Loop engineering: Designing loops you can actually walk away from'을 번역한 것입니다. 더 나은 이해를 위해서 약간의 의역이 반영되었습니다.
요즘 X에서 새로운 용어 하나가 빠르게 번지며 엔지니어링 커뮤니티의 관심을 끌고 있습니다. 바로 루프 엔지니어링(loop engineering)입니다.
핵심 개념은 단순합니다. 코딩 에이전트를 일일이 손으로 다루는 방식에서 벗어나자는 것입니다. 대신 실행을 알아서 처리하는 자율 루프를 설계해 두면, 여러분은 다른 일에 집중하거나 다음 루프를 설계할 여유를 얻습니다.
OpenClaw를 만든 Peter Steinberger가 이 논의에 불을 지폈고 Claude Code를 이끄는 Boris는 이런 말로 유명합니다. "저는 이미 수동 프롬프팅을 넘어섰습니다. 지금은 Claude를 이끌고 실행 경로를 대신 찾아 주는 자율 사이클을 설계합니다. 제 진짜 일은 루프 그 자체를 설계하는 일입니다."
업계의 무게중심은 2023년 초 프롬프트 엔지니어링에서 컨텍스트 관리로, 그리고 2025년 후반 힘을 얻은 하네스 엔지니어링(harness engineering)으로 옮겨 왔습니다. 2026년이 "에이전트 하네스의 해"로 불리기 시작할 무렵, 초점은 이미 한 번 더 이동해 있었습니다.
루프 엔지니어링은 어디에서 시작됐나
사실 완전히 새로운 발상은 아닙니다. 이미 지난 1월에 Geoffrey Huntley가 자신이 랠프 루프(ralph loop)라 부르는 방식으로 먼저 깃발을 꽂았거든요. 에이전트에게 같은 목표를 반복해서 던져 주고 몇 시간이고 돌리면서 아무도 자리에 앉아 있지 않은 상태로 스스로 할 일을 찾고 계획하고 해결하게 하는 방식입니다.
이 방식은 모델 내부의 컨텍스트에 기대는 대신 진행 상황을 git 히스토리와 파일, 외부 메모리로 관리해 보존합니다. 바로 이 외부 메모리 관리가 여전히 가장 큰 기술적 난관입니다. 간단한 bash 스크립트만 있으면 컨텍스트 윈도가 바닥난 순간 새 에이전트가 앞선 에이전트가 멈춘 지점을 그대로 이어받아 작업을 재개합니다.
Anthropic도 몇 달 앞서 연구 관점에서 같은 그림을 내놓았습니다. 교대 근무하듯 일하는 에이전트인데, 각 교대조는 이전 조의 기억이 전혀 없는 채로 출근해서 디스크에 남겨진 메모에 의지해 일을 이어 갑니다.
루프는 어떤 모습일까
프롬프트, 컨텍스트, 하네스 엔지니어링은 모두 매 턴마다 여러분이 직접 에이전트를 안내하며 손을 놓지 못하게 했습니다. 반면 루프 엔지니어링은 완전한 전환입니다. 자율적으로 돌아가는 시스템을 설계해 두면 여러분은 아예 자리를 비울 수 있고 사람이 루프 밖으로 완전히 빠집니다.
근본적인 차이는 누가 주도권을 쥐느냐에 있습니다.
- 프롬프트는 고립된 지시입니다. AI가 한 번 응답하고 멈춘 뒤 여러분의 다음 입력을 기다립니다.
- 루프는 재귀적인 목표입니다. 목적이 한 번 정해지면 시스템이 스스로 전체 회로를 돌며 목표가 온전히 이뤄질 때까지 멈추지 않습니다.
루프에 필요한 구성 요소는 무엇인가
실제 아키텍처로 들어가면 Addy Osmani가 가장 깔끔하게 정리해 뒀습니다. 다섯 개의 핵심 구성 요소에 전용 메모리 레이어가 하나 더 붙는 구조인데 플랫폼마다 부르는 이름은 달라도 그 아래에서 동작하는 원리는 같습니다.
- 자동화(Automations): 정해진 일정에 따라 할 일을 찾아내 여러분이 커피를 마시기도 전에 우선순위를 분류해 두는 장치입니다.
- 워크트리(Worktrees): 병렬로 도는 에이전트가 각자 자기만의 체크아웃을 갖기 때문에 둘이 서로의 파일을 덮어쓸 일이 없습니다.
- 스킬(Skills): 프로젝트의 지식을 한 번 적어 두는 곳입니다. 관례, 빌드 절차, 어렵게 얻은 "이렇게는 하지 마라" 같은 메모를 담아 두면 에이전트가 매 세션마다 처음부터 다시 추측하지 않습니다.
- 플러그인과 커넥터(Plugins and connectors): MCP 위에 만들어지며 루프가 파일 시스템을 넘어 실제로 쓰는 도구까지 닿는 통로입니다. 이슈 트래커, 데이터베이스, 스테이징 환경, Slack이 여기에 해당합니다.
- 서브 에이전트(Sub-agents): 코드를 작성한 모델이 그 코드를 채점하지 않게 합니다. 모델은 자기 작업에는 관대한 채점자이기 때문입니다.
- 상태(State): 여섯 번째 요소이자 과소평가하기 쉬운 조각인 디스크 위의 메모리입니다. 무엇이 끝났고 무엇이 다음인지 추적하는 파일이나 Linear 보드가 여기 해당합니다. 저장소는 그대로 남아 있어도 모델은 실행과 실행 사이에 매번 초기화되기 때문입니다.
제대로 도는 루프는 어떻게 설계할까
지난 2월에 저는 개인 프로젝트에 루프를 하나 엮어 봤습니다. 제가 손대지 않아도 얼마나 오래 굴러가는지 보고 싶었거든요. 출발점은 실제 사용자 피드백이었습니다. 루프가 새 요청을 끌어와 우선순위를 분류하고 그중 해 볼 만한 것마다 계획 초안을 잡았습니다. 그다음은 Claude가 구현을 작성하고 CodeRabbit이 디프가 깨끗해질 때까지 루프 안에서 리뷰를 돌렸으며 Claude가 테스트를 실행했습니다.
모든 게 문제없이 통과하면 루프는 CI를 기다렸다가 스스로 머지하고 머지 이후 배포 점검으로 결과를 다시 확인했습니다. 제가 한 일이라고는 무엇을 구현할 가치가 있는지 정하고 에이전트가 내놓은 결과물을 검증하는 것뿐이었습니다. 루프는 한 번 설계해 뒀을 뿐인데 계속 배포를 이어 갔습니다.
정작 이 전체를 지탱한 것은 지루한 요소였습니다. 바로 그 점이 핵심입니다. 모든 게 예약된 작업 하나와 상태 파일 하나로 돌아갔습니다. 무엇이 배포됐고 무엇이 실패했으며 무엇이 아직 열려 있는지 적은 평범한 마크다운 로그였죠. 덕분에 각 실행은 맨바닥에서 시작하지 않고 이어서 재개했습니다. 프로젝트의 관례는 에이전트가 매번 읽는 스킬에 담겨 있어서 아무도 설정을 처음부터 다시 유추하지 않았습니다.
제가 이 루프를 안심하고 내버려 둘 수 있었던 건 품질 게이트 덕분입니다. 테스트가 통과하고 CodeRabbit의 리뷰가 깨끗하게 돌아오기 전에는 아무것도 머지되지 않았습니다. 다시 말해 '완료'가 Claude가 자기 작업을 스스로 평가한 의견이 아니라 제가 믿을 수 있는 신호였다는 뜻입니다. 저는 루프를 작고 확인 가능한 변경에만 붙여 뒀습니다. 꼼꼼한 주니어라면 티켓 하나로 배포할 만한 종류였고 진짜 판단이 필요한 일은 제 몫으로 남겼습니다. 루프는 그런 판단을 내리지 않았습니다. 제가 이미 코드로 새겨 둔 판단을 저 없이 몇 번이고 반복해서 내렸을 뿐입니다.
CodeRabbit은 루프 엔지니어링에서 어떤 역할을 하나
CodeRabbit 쪽에서는 세 조각이 Claude Code와 맞물려 돌아갔습니다. 기획 에이전트는 다듬어지지 않은 피드백을 코딩 계획으로 바꿨고 CLI는 루프 안에서 곧바로 리뷰를 돌려 무엇이든 PR로 올라가기 전에 Claude가 지적 사항을 고치도록 했습니다. 그리고 리뷰 제품은 PR 자체에 대한 마지막 관문이었습니다. 전체 모습은 이렇습니다.
루프를 만들 것인가, 말 것인가
루프를 만들기 전에 그 작업이 애초에 그럴 값어치가 있는지부터 따져 보세요. 루프는 목표가 안정적일 때 보상이 큽니다. 코드베이스를 다시 쓰는 작업이라면 목표가 가만히 멈춰 있으니 검증기 하나(빌드가 되는가, 테스트가 통과하는가, 동작이 여전히 일치하는가)가 모든 반복을 감당합니다. 한 번 작성해 두면 끝까지 재사용됩니다. 하지만 조건이 계속 바뀌면 셈법이 뒤집힙니다.
실행할 때마다 '완료'의 정의를 새로 내려야 한다면 여러분은 배포 대신 검증기를 다시 쓰는 데 시간을 쏟게 됩니다. 그 유지 비용이 루프가 아껴 주기로 한 것을 그대로 갉아먹습니다. 목표가 안정적이면 루프를 만드세요. 목표가 움직이면 수동 프롬프트로 남겨 두세요.
관련해서 AI 에이전트를 신뢰하시나요에서 자율 루프에 판단을 맡길 때 무엇을 믿어야 하는지 짚어 봅니다. AI 에이전트의 기억상실증과 에이전트가 신뢰를 얻는 세 순간도 함께 보시길 추천 드립니다.