루프 엔지니어링: 프롬프트를 치는 사람에서 시스템을 설계하는 사람으로

AI 코딩 에이전트를 쓰다 보면 어느 순간 묘한 역전이 생깁니다. 처음에는 내가 일을 덜 하는 것처럼 느껴집니다. "이 파일 고쳐줘", "테스트 돌려줘", "에러를 보고 다시 수정해줘." 몇 번은 정말 빠릅니다. 그런데 오후가 지나면 다른 종류의 피로가 옵니다. 코딩은 줄었는데, 에이전트에게 다음 지시를 넣는 일이 계속 남아 있습니다.

문제는 에이전트가 약해서만 생기지 않습니다. 모델이 좋아질수록 오히려 더 또렷해지는 문제입니다. 모델은 한 번의 지시를 더 잘 처리합니다. 하지만 반복되는 일을 언제 시작할지는 별도의 설계 영역입니다. 무엇을 기억하고, 어떤 기준으로 통과시킬지도 시스템 밖에서 잡아야 합니다. 그 빈자리를 사람이 채우면 수동 프롬프팅이 되고, 시스템이 채우면 루프가 됩니다.

루프 엔지니어링은 그 차이를 다룹니다. 좋은 프롬프트를 쓰는 기술이 아니라, 좋은 프롬프트가 반복해서 실행될 수 있는 운영 구조를 설계하는 일입니다. 사람은 사라지지 않습니다. 대신 매번 운전대를 잡는 자리에서 내려와, 도로와 신호등과 정지선을 설계하는 자리로 이동합니다.

핵심 정리

1. 01루프 엔지니어링은 에이전트를 많이 돌리는 기술이 아니라, 반복 작업의 시작·상태·검증·중단 조건을 설계하는 방식입니다.
2. 02하네스 엔지니어링이 한 번의 agent run을 안전하게 만든다면, 루프 엔지니어링은 그 run들이 이어지는 운영 단위를 만듭니다.
3. 03좋은 루프의 핵심은 자동 실행보다 멈춤입니다. 통과, 재시도, 사람 호출 중 무엇을 선택할지 미리 정해져 있어야 합니다.
4. 04처음부터 L3 무인 자동화를 만들기보다, 읽고 보고하고 상태를 남기는 L1 루프에서 실패 방식을 관찰하는 편이 안전합니다.

용어 정리

하네스

에이전트 한 번의 실행을 감싸는 환경입니다. 읽을 파일, 쓸 도구, 테스트, judge, 실패 처리 규칙이 여기에 들어갑니다.

한 번의 실행을 안전하게 만드는 층

루프

비슷한 실행을 반복 가능한 운영 단위로 묶은 구조입니다. 트리거, 상태, 예산, 검증, 중단 조건을 포함합니다.

반복을 운영 가능하게 만드는 층

상태

지난 실행의 결과, 실패, 보류된 결정, 다음에 볼 신호를 채팅창 밖에 남긴 기록입니다.

에이전트가 잊어도 시스템이 기억하게 하는 장치

판정 게이트

실행 결과를 통과, 재시도, 중단, 사람 호출 중 하나로 보내는 결정 지점입니다.

루프가 폭주하지 않게 하는 정지선

하네스 위에 한 층 더 있다

하네스 엔지니어링은 모델을 감싸는 바깥 구조를 다룹니다. 어떤 파일을 먼저 읽힐지, 어떤 도구를 허용할지, 테스트를 어떻게 실행할지, 실패했을 때 재시도할지, 별도 judge를 어디에 둘지 같은 문제입니다. 좋은 하네스는 에이전트 한 번의 실행을 덜 위험하게 만듭니다.

하지만 실제 일은 한 번으로 끝나지 않습니다. 백로그는 매일 바뀝니다. 테스트 실패는 새로 생기고, 문서는 구현보다 늦게 따라옵니다. 배포 뒤에는 changelog와 회고도 남습니다. 이 반복 작업을 매번 사람이 채팅창에서 다시 설명하면, 하네스가 좋아도 운영 비용은 사람에게 계속 남게 됩니다.

루프 엔지니어링은 그 반복을 대상으로 삼습니다. 에이전트가 한 번 잘 일하게 만드는 것을 넘어, 그 일을 다시 맡길 수 있는 단위를 설계하는 쪽입니다. 언제 실행할지 정합니다. 이전 결과를 어디서 읽을지도 정합니다. 이번 run의 예산, 멈춰야 할 실패, 사람에게 돌려보낼 판단까지 함께 묶습니다.

여기서 자동화와의 차이가 생깁니다. 자동화는 보통 "사람이 하던 일을 기계가 대신한다"는 말로 이해됩니다. 루프 엔지니어링은 조금 더 운영적입니다. 사람의 판단을 없애는 것이 아니라, 사람이 개입해야 하는 위치를 명확히 옮깁니다. 매번 "다음에 뭐 해?"라고 묻는 사람 대신, 상태 파일과 검증자와 승인 게이트가 다음 행동을 제한합니다.

예를 들어 매일 아침 backlog를 훑고, 작고 테스트 가능한 작업 후보만 골라주고, 불확실한 작업은 사람에게 넘기는 흐름을 생각해볼 수 있습니다. 이건 단순 cron 작업이 아닙니다. 무엇을 읽고, 어떤 상태를 남기고, 어떤 기준으로 "오늘은 여기까지"라고 말할지가 정해져 있습니다.

작은 팀에게 이 차이는 큽니다. 프롬프트를 잘 쓰는 사람 한 명이 모든 반복을 붙잡고 있으면 병목은 사람 쪽에 그대로. 반대로 반복의 규칙이 외부화되면, 팀은 매번 지시하는 대신 루프 자체를 개선할 수 있습니다.

루프는 while문이 아니다

루프라는 말 때문에 while true 같은 장면이 먼저 떠오릅니다. 계속 돌고, 실패하면 다시 돌고, 언젠가 맞으면 끝나는 구조입니다. 그런데 실무에서 그런 루프는 대부분 위험합니다. 모델은 자신이 같은 실수를 반복하고 있다는 사실을 충분히 강하게 느끼지 못하고, 비용은 조용히 쌓이며, 결과는 "조금 더 그럴듯한 실패"가 되기 쉽습니다.

그래서 루프의 핵심은 반복 횟수가 아니라 멈춤 조건입니다. 무엇을 더 해도 안 되는지 미리 정해야 합니다. 어떤 증거가 없으면 통과할 수 없는지도 정해야 합니다. 어떤 위험이 보이면 사람에게 돌아와야 하는지도 기준에 들어갑니다. "잘 될 때까지"는 완료 기준이 아닙니다. "npm test가 통과한다", "문서와 구현의 불일치가 0개다", "검증자가 같은 결론을 독립적으로 확인했다"처럼 확인 가능한 문장이 기준입니다.

좋은 루프에는 실행 전 계약이 있습니다.

1. 01목적과 완료 기준을 쓴다
2. 02상태 파일에서 지난 결과를 읽는다
3. 03에이전트가 작은 단위로 실행한다
4. 04별도 검증자가 결과를 확인한다
5. 05통과, 재시도, 중단, 사람 호출 중 하나를 고른다

이 구조에서 가장 중요한 칸은 실행이 아니라 판정입니다. 많은 팀이 에이전트에게 일을 맡기는 데에는 빨리 익숙해집니다. 반대로 결과를 어떻게 받아들일지 정하는 데에는 훨씬 늦게 익숙해집니다. 결과가 나쁘면 재시도할 수 있습니다. 범위를 줄이는 선택지도 있습니다. 다른 도구 확인도 선택지입니다. 사람에게 돌려보내야 할 때도 생깁니다. 이 선택지를 정하지 않은 채로 루프를 만들면, 결국 사람이 뒤늦게 모든 판정을 다시 해야 합니다.

나쁜 루프는 사람을 없애지 않습니다. 사람을 마지막 쓰레기통으로 만듭니다. 실패한 결과, 불완전한 판단, 애매한 diff가 마지막에 한꺼번에 사람에게 옵니다. 좋은 루프는 그 반대입니다. 사람이 볼 필요가 없는 반복은 시스템이 처리하고, 사람이 봐야 하는 판단은 작은 묶음으로 빨리 되돌려줍니다.

그래서 루프 엔지니어링의 첫 질문은 "무엇을 자동화할까"가 아닙니다. "어디에서 멈출까"입니다.

상태는 채팅창 밖에 있어야 한다

루프가 한 번의 프롬프트와 가장 크게 다른 지점은 상태입니다. 채팅창 안에만 기억이 있으면, 루프는 매번 처음부터 다시 시작합니다. 어제 어떤 파일을 고쳤는지, 어떤 접근이 실패했는지, 어떤 테스트가 flaky였는지, 어떤 결정을 사람이 보류했는지 사라집니다.

사람은 이런 맥락을 머릿속으로 대충 이어붙입니다. 에이전트도 긴 컨텍스트가 있으면 어느 정도 따라옵니다. 하지만 운영 구조로 보면 그건 약한 기억입니다. 세션이 바뀌거나, 모델이 바뀌거나, 작업자가 바뀌면 맥락은 쉽게 끊깁니다. 루프가 반복될수록 이 끊김은 작은 불편이 아니라 품질 저하가 됩니다.

그래서 좋은 루프는 상태를 파일이나 외부 시스템에 남깁니다. STATE.md, loop.md, iterations.md, verdicts.md, debt.md 같은 이름은 취향 문제가 아닙니다. 에이전트가 잊어도 시스템이 기억하게 만드는 장치입니다. 중요한 것은 파일 이름보다 그 안에 무엇이 들어가느냐입니다.

상태에는 최소한 네 가지가 필요합니다. 지난 실행의 입력과 결과. 그 결과의 판정. 다음 실행에 넘길 제한입니다. "테스트 실패"라고만 적으면 다음 run은 다시 헤맵니다. "Windows에서만 실패했다. 원인은 path separator 가능성이 높다. 다음 run은 path.join 사용 여부부터 볼 것"처럼 남기면 루프는 학습합니다.

Cobus Greyling의 loop engineering repo가 state file과 verifier를 같이 보는 이유도 여기에 있습니다. budget과 run log까지 확인하는 것도 같은 맥락입니다. Formin의 Spec Kit extension은 maker와 checker를 나눕니다. 사람 sign-off를 별도 단계로 두는 방식도 같은 방향입니다. 루프의 산출물은 코드나 문서만이 아닙니다. 상태와 판정 기록.

상태가 없으면 재시도는 반복이 아니라 망각에 가깝습니다. 같은 문제를 다른 표현으로 다시 시도할 뿐. 상태가 있으면 실패도 다음 실행의 재료. 다음 run은 다른 출발점에서 시작합니다.

자동화보다 먼저 L1이 필요하다

루프 엔지니어링을 처음 들으면 바로 unattended automation을 떠올리기 쉽습니다. 밤새 에이전트가 돌아가고, 아침에 PR이 쌓여 있고, 사람은 approve만 누르는 장면입니다. 그 그림은 매력적이지만, 대부분의 팀에게 첫 단계로는 너무 큽니다.

먼저 필요한 건 L1입니다. 읽고, 정리하고, 상태를 남기지만 자동 수정은 하지 않는 단계입니다. L1은 겉보기에는 화려하지 않습니다. 코드를 바꾸지도 않고, PR을 만들지도 않고, 배포를 하지도 않습니다. 대신 루프가 무엇을 잘못 볼 수 있는지, 어떤 신호를 과대평가하는지, 어디서 사람 판단이 필요한지 드러냅니다.

대부분의 팀은 L3가 아니라 L1에서 이미 가치를 얻습니다. 매일 backlog를 정리해주고, PR의 막힌 지점을 찾아주고, 문서와 구현의 차이를 알려주는 것만으로도 충분히 쓸모 있습니다. 더 중요한 점은 L1이 루프의 실패 방식을 관찰하게 해준다는 것입니다.

예를 들어 이슈 triage 루프를 L1로 돌려보면, 에이전트가 오래된 이슈를 과하게 우선순위 높게 보는지 알 수 있습니다. 테스트 로그 요약 루프를 L1로 돌려보면, 실제 원인보다 마지막 에러 메시지에 끌리는지 보입니다. 문서 불일치 루프를 L1로 돌려보면, 단어 차이를 의미 차이로 착각하는지 확인할 수 있습니다.

이 단계에서는 실수해도 손실이 작습니다. 잘못 고른 작업은 사람이 버리면 됩니다. 틀린 요약은 다음 run의 상태 파일에 표시하면 됩니다. 하지만 실패 방식을 모르는 루프에 쓰기 권한을 주면, 그건 자동화가 아니라 방치입니다.

사람은 빠지는 게 아니라 위치가 바뀐다

루프 엔지니어링을 "사람 없이 돌아가는 AI"로 이해하면 반만 맞습니다. 더 정확히는 사람이 매번 키보드를 두드리는 자리에서 빠지고, 계약과 승인과 중단 조건을 정하는 자리로 이동합니다. 사람이 없어지는 것이 아니라, 더 앞쪽과 더 중요한 지점에 배치됩니다.

수동 프롬프팅에서 사람은 운전자에 가깝습니다. 매번 방향을 말하고, 결과를 보고, 다시 조향합니다. 루프 엔지니어링에서 사람은 설계자이자 관제자에 가깝습니다. 어떤 길은 닫아두고, 어떤 신호가 오면 멈추게 하고, 어떤 기준을 넘으면 다음 단계로 보내는지 정합니다.

사람이 해야 할 일은 줄지 않습니다. 종류가 바뀝니다.

• 무엇을 반복할 가치가 있는지 고른다.
• 완료 기준을 확인 가능한 문장으로 쓴다.
• 에이전트가 볼 수 있는 상태를 정한다.
• 검증자를 실행 주체와 분리한다.
• 위험한 결정을 사람에게 되돌아오게 만든다.

이 변화가 작아 보여도 실제로는 큽니다. 예전에는 일을 잘게 쪼개 직접 밀어 넣는 사람이 필요했습니다. 이제는 작은 팀도 운영 루프를 설계해 반복 작업을 시스템에 맡길 수 있습니다. 대신 그 시스템이 무엇을 하고 있는지 설명할 책임도 같이 커집니다.

그래서 루프 엔지니어링은 권한 설계와도 붙어 있습니다. 무엇을 읽을 수 있는지, 어디까지 쓸 수 있는지, 어떤 파일은 절대 건드릴 수 없는지, 어떤 비용을 넘으면 멈춰야 하는지 정해야 합니다. 루프는 반복되기 때문에 작은 권한 실수도 누적됩니다. 한 번의 에이전트 실행에서 괜찮았던 느슨함이, 매일 도는 루프에서는 사고가 됩니다.

좋은 루프는 사람을 귀찮게 하지 않으려고 숨기지 않습니다. 사람이 봐야 할 순간을 더 선명하게 만듭니다.

첫 루프는 작아야 한다

가장 좋은 첫 루프는 제품을 밤새 만드는 루프가 아닙니다. 읽기 중심이고, 검증이 쉽고, 틀렸을 때 피해가 작은 루프입니다. 처음부터 쓰기 권한을 주면 멋있어 보이지만, 루프가 어떤 식으로 실패하는지 배우기 전에 피해 반경을 키우게 됩니다.

좋은 첫 루프 후보는 반복적이지만 위험이 낮은 일입니다. README와 ROADMAP의 불일치를 찾는 루프, 테스트 실패 로그를 요약하고 원인 후보만 제안하는 루프, 오래된 이슈를 triage하고 다음 행동을 하나만 추천하는 루프, 배포 뒤 changelog 초안을 만들되 사람 승인 전에는 게시하지 않는 루프가 여기에 들어갑니다.

이런 루프는 화려하지 않습니다. 대신 상태 파일과 완료 기준을 연습하기 좋은 재료입니다. 검증자와 중단 조건도 같이 다듬는 자리. 무엇보다 결과 확인이 빠릅니다. 불일치 보고가 틀렸는지 바로 보입니다. 테스트 로그 요약의 과장도 드러납니다. 이슈 우선순위가 팀의 실제 감각과 맞는지까지, 사람이 빠르게 판정.

첫 루프에서 작게 잡을 것은 세 가지입니다. 입력 범위, 쓰기 권한, 반복 주기. 처음에는 repo 전체보다 폴더 하나를 권합니다. 자동 수정보다 보고서가 낫고, 매시간 실행보다 하루 한 번으로 충분합니다. 이렇게 작게 시작하면 실패 원인이 더 잘 보입니다.

작은 루프는 작은 성과만 내는 것이 아닙니다. 작은 루프는 큰 루프를 만들기 전에 필요한 언어를 줍니다. 어떤 상태를 남겨야 하는지, 어떤 검증자가 필요한지, 어느 지점에서 사람이 봐야 하는지. 팀이 직접 배우는 언어.

남는 질문

프롬프트를 잘 쓰는 사람은 여전히 중요합니다. 다만 능력의 모양은 달라집니다. 좋은 한 문장에서, 좋은 반복 구조로. 질문을 잘하는 능력은 사라지지 않습니다. 질문이 실행되는 자리를 설계하는 능력이 더해집니다.

앞으로 작은 팀의 차이는 "AI를 쓰는가"가 아니라 "어떤 루프를 운영하는가"에서 갈릴 가능성이 큽니다. 누군가는 에이전트에게 계속 다음 일을 설명하고 있을 겁니다. 누군가는 그 설명을 상태와 검증과 중단 조건이 있는 시스템으로 바꿔둘 겁니다.

여기서 중요한 태도는 낙관보다 운영 감각입니다. 루프를 만들 수 있다고 해서 곧바로 모든 일을 맡기지 않는 것. 모델이 한 번 잘했다고 해서 같은 방식으로 계속 잘할 거라고 믿지 않는 것. 사람이 보기 귀찮은 일을 숨기는 대신, 사람이 책임져야 할 결정을 더 잘 보이게 만드는 것.

루프 엔지니어링은 사람을 빼는 기술이 아닙니다. 사람이 계속 책임질 수 있는 방식으로 반복을 맡기는 기술입니다.