루프 엔지니어링이란 무엇인가: 코딩 에이전트를 프롬프트 대신 스스로 도는 루프로 설계하는 법

핵심 메시지

• 루프 엔지니어링은 사람이 매번 프롬프트를 던지는 대신, 에이전트가 스스로 상태를 보고 다음 행동을 정해 반복하도록 설계하는 방식이다.
• 루프가 성립하려면 두 가지가 먼저 있어야 한다. 루프를 시작시키는 트리거와, 언제 멈춰도 되는지 알려주는 검증 가능한 목표다.
• 정해진 순서를 그대로 실행하는 크론잡·자동화와 달리, 루프는 의사결정자가 루프 안에 있어 재시도·롤백·중단을 스스로 판단한다.
• 발표자는 루프를 자동화·워크트리·스킬·플러그인·서브에이전트 다섯 조각과 메모리로 나눠 설명하며, 그중 스킬이 가장 저평가돼 있다고 지적한다.
• 가장 큰 실패 요인은 모호한 목표와 비용이다. 최대 반복 횟수와 예산 같은 강제 중단 장치가 없으면 루프는 자신만만한 '토큰 소각로'가 된다.

쉽게 이해하기

요즘 코딩 에이전트를 쓰는 과정은 프롬프트를 쓰고, 파일 접근을 허용하고, 테스트를 돌렸다가 무언가 깨지면 오류 메시지를 다시 붙여 넣는 일의 반복이다. 발표자는 20분쯤 지나서야 자신이 떠넘기려던 바로 그 과정을 감시하고 있었다는 걸 깨닫는다고 말한다. 루프 엔지니어링은 그 감시자 역할을 그만두자는 발상으로, 에이전트에게 일일이 지시하는 대신 에이전트를 프롬프트하는 루프 자체를 설계한다. 발표자는 프롬프트 엔지니어링에서 컨텍스트 엔지니어링, 하네스를 거쳐 루프 엔지니어링으로 이어진 흐름이 결국 모두 맥락과 프롬프트로 모델을 최대한 잘 조종하려는 같은 시도라고 정리한다.

그렇다면 매시간 같은 프롬프트를 돌리는 크론잡과는 무엇이 다를까. 결정적 차이는 의사결정자가 루프 안에 있다는 점이다. 크론잡은 고정된 스크립트를 실행하지만, 루프는 현재 상태를 보고 다음 행동을 고르고 결과를 확인한 뒤 계속할지, 재시도할지, 되돌릴지, 멈출지를 에이전트가 정한다. 이것이 가능해진 이유는 모델이 목표와 보상 신호를 이해할 만큼 좋아졌기 때문이다.

다만 루프가 작동하려면 최소 두 가지가 필요하다. 하나는 트리거다. 풀 리퀘스트가 열리거나, CI가 깨지거나, 정해진 시각이 되거나, 슬랙 메시지가 오는 것처럼 루프를 깨우는 신호다. 다른 하나는 검증 가능한 목표다. '테스트가 모두 통과하고 CI가 초록색'처럼 결정적일 수도 있고, 리뷰어 역할의 모델이 명세와 결과물을 대조하는 식일 수도 있다. 어떤 형태든 확인 장치가 없다면 그것은 루프가 아니라 그냥 토큰을 태우는 기계라고 발표자는 못 박는다.

구성 요소는 다섯 조각에 메모리를 더한 형태로 소개된다. 스스로 깨어나는 자동화, 병렬 작업이 서로를 덮어쓰지 않게 하는 워크트리, 프로젝트 규칙을 매번 다시 추측하지 않게 하는 스킬, 깃허브나 슬랙 같은 외부 도구를 실제로 다루게 해 주는 플러그인, 그리고 작성자와 심판을 분리하는 서브에이전트다. 발표자는 특히 스킬이 여전히 크게 저평가돼 있다고 강조한다. 재사용할 스킬이 없는 루프는 실행할 때마다 프로젝트를 처음부터 다시 파악하느라 토큰을 태우지만, 잘 정리된 스킬이 있으면 실행이 쌓일수록 이득이 복리로 붙는다는 것이다.

실제 모습은 이렇다. 아침마다 루프가 깨어나 어제의 CI 실패와 열린 이슈, 최근 커밋을 읽고 할 만한 일을 짧은 상태 파일로 적는다. 이슈 하나에 대해 별도 워크트리를 열어 한 에이전트에게 수정을 맡기고, 다른 에이전트가 프로젝트 스킬과 테스트를 기준으로 그 결과를 검토한다. 테스트가 통과하면 PR을 열고 티켓을 갱신하며, 실패하면 오류를 한두 번 되먹인다. 막히면 멈추고 사람의 받은편지함에 문제를 올려 둔다. 일곱 번 지시하는 대신 일곱 단계짜리 시스템을 한 번 설계해 두는 셈이다.

주요 인사이트

• 이제 어려운 것은 프롬프트 자체가 아니라 그 주변이다. 어떤 맥락을 보여줄지, 어떤 도구를 쓰게 할지, 무엇을 '완료'로 볼지, 실패하면 어떻게 할지, 그리고 멈추기 전까지 얼마를 쓰게 둘지가 진짜 설계 문제다.
• 스킬은 한 작업에 하나씩, 최대한 조밀하되 작고 깔끔하게 쓰는 편이 좋다. 그런 다음 에이전트에게 색인을 만들게 하면, 매번 '어떤 스킬을 열어라'라고 지시하지 않아도 목록을 보고 필요한 것만 골라 쓰게 된다.
• 검증은 에이전트가 '다 됐다'고 말하는 것보다 강해야 한다. 테스트 실행, 타입 검사, 리뷰어 에이전트, 명세와 변경분 대조처럼 외부에서 확인할 수 있는 장치가 필요하다.
• 코딩은 합격·불합격 신호가 뚜렷해 오히려 쉬운 축에 든다. 목표가 흐릿한 창작이나 전략 업무를 '잘 만들어라' 수준의 기준으로 루프에 넘기면 끝없이 다시 쓰기만 반복할 수 있다.
• 비용은 아키텍처의 일부다. 발표자는 자기 루프를 직접 실행해 지켜보고 잠든 사이에는 돌리지 않는다고 말하며, 최대 반복 횟수·진전 없음 감지·하루 예산 같은 하드 브레이크를 권한다.

자주 묻는 질문

관련 AI 소식