에이전트 루프(agentic loop)를 처음 실무에 붙여봤을 때 드는 느낌은 "이거 생각보다 쉽네"다. 목표를 주고, 멈출 조건을 달아두면 에이전트가 알아서 반복한다. Kiro나 Claude Code에서 Fix all issues on the PR. Keep going until it's all fixed. 한 줄이면 CI 빨간 불이 꺼질 때까지 루프가 돈다. dev.to의 Loop Engineering 아티클이 보여주듯, 테스트 패스/페일이라는 명확한 신호가 있을 때 이 패턴은 실제로 강력하다.
문제는 그 다음이다. 루프가 돌기 좋은 조건—명확한 정지 신호, 신뢰할 수 있는 입력, 안전한 실행 경계—을 갖추지 않으면 에이전트는 올바른 추론으로 잘못된 결론에 도달한다. 여기서 세 가지 설계 원칙이 갈린다.
1. 정지 조건은 상태로 증명되어야 한다
keep going until it's fixed는 좋은 출발점이지만, '고쳐졌다'는 상태를 무엇으로 판단하는지가 핵심이다. CI 테스트 통과처럼 기계가 측정할 수 있는 신호라면 루프는 안전하게 닫힌다. 그런데 정지 조건이 산문형 지시나 문서 속 묘사에 의존하기 시작하면 이야기가 달라진다.
dev.to의 'Don't Ask AI to Stop Guessing' 아티클이 기록한 사례가 정확히 이 지점이다. 자동화 에이전트가 유지보수 작업 중 핸드오버 노트의 "parked" 한 단어를 근거로 실제로 운영 중인 기능을 '비활성'으로 분류했다. 에이전트는 careless하지 않았다—노트를 읽은 인간이라도 같은 결론을 냈을 것이다. 루프의 정지 조건이 권위 있는 상태(authoritative source)가 아닌 편리한 요약(prose narrative)에 묶여 있었던 것이 문제였다.
프론트엔드 루프에도 같은 논리가 적용된다. keep going until the docs match the code라는 조건은, '문서가 코드와 일치한다'는 사실을 어디서 판단하는지를 먼저 명시해야 한다. 에이전트 판단에 맡기면 가장 유창하게 쓰인 문서가 진실처럼 읽힌다.
2. 데이터 소스에 계층을 설계하라
위 팀이 프롬프트 강화 대신 선택한 해법은 소스 계층화였다. production system of record → derived facts → cited override → narrative 순서로 우선순위를 코드에 박아두고, 상위 소스가 답을 갖고 있으면 하위 소스는 투표권이 없다. 특히 중요한 규칙은 부재(absence)도 권위 있는 소스에서 증명되어야 한다는 것이다. 문서가 언급하지 않았다고 해서 기능이 없는 것이 아니다.
이 원칙을 에이전트 루프 설계로 번역하면: 루프가 참조하는 컨텍스트 안에 두 개 이상의 '현실 묘사'가 존재한다면, 어떤 것이 이기는지를 루프 밖에서 선언해야 한다. 에이전트가 매 루프마다 어떤 소스를 믿을지 판단하게 두는 것 자체가 실패 확률을 내장하는 구조다.
3. 루프가 증명하지 못하는 경계를 테스트 인프라로 막아라
세 번째 함정은 실행 경계다. dev.to의 'Our CI mocked Stripe' 사례는 코딩 에이전트가 CI 파이프라인을 통과시켰지만 프로덕션이 깨진 상황을 기록한다. POST /v1/payment_intents에 대한 모킹은 요청 형태(shape)를 증명했지만, PaymentIntent ID가 다음 웹훅 단계로 체이닝되는지는 증명하지 못했다. 에이전트가 핸들러를 '수정'하고 루프를 닫았지만, 그 수정이 실제로 실행되는 경로를 한 번도 통과하지 않은 것이다.
이 팀이 도입한 해법은 MCP(Model Context Protocol)를 통한 실제 프로바이더 워크플로우 검증이다. FetchSandbox MCP를 IDE에 붙여 create PaymentIntent → confirm → webhook reconcile이라는 전체 생명주기를 에이전트가 PR을 열기 전에 로컬에서 먼저 통과시키고, 동일한 워크플로우를 CI에서도 headless로 실행한다. 에이전트 루프의 정지 조건이 "CI 초록 불"이라면, 그 초록 불 자체가 실제 경계를 커버하고 있는지를 먼저 설계해야 한다.
루프를 돌리기 전 세 가지 체크리스트
세 사례를 종합하면 에이전트 루프를 안전하게 설계하는 조건이 명확해진다.
① 정지 조건은 기계가 측정할 수 있는 상태여야 한다. 테스트 패스, exit code 0, diff가 없음—이런 신호는 에이전트가 오해 없이 판단할 수 있다. '문서가 맞아 보인다', '충분히 고쳐진 것 같다'는 루프의 정지 조건이 될 수 없다.
② 컨텍스트 안에 복수의 '현실 묘사'가 있다면 우선순위를 코드로 선언하라. 프롬프트에서 "authoritative source를 우선 참조해"라고 말하는 것과 아키텍처가 lower tier에 접근하는 경로를 차단하는 것은 다르다. 후자만이 루프의 누적 실행에서 살아남는다.
③ 루프의 정지 신호가 실제 실행 경계를 커버하는지 검증하라. 모킹이 통과한다고 통합이 검증된 것이 아니다. 에이전트가 수정하는 코드가 실제로 실행되는 경로—특히 멀티스텝 워크플로우, 웹훅, 상태 체이닝—는 루프 밖에서 별도로 증명되어야 한다.
루프 엔지니어링 자체는 하이프가 아니다. Addy Osmani가 정리한 것처럼, 스케줄 기반 자동화나 명확한 pass/fail 신호가 있는 반복 작업에서 에이전트 루프는 실제로 유용하다. 다만 루프를 빠르게 돌리는 것과 루프가 올바른 결론을 향해 수렴하는 것은 다른 문제다. 에이전트가 빠르게 반복할수록, 잘못 설계된 정지 조건과 신뢰할 수 없는 소스 계층은 오류를 더 빠르게 증폭시킨다.
프론트엔드 개발자 시각에서 에이전트 루프의 핵심 과제는 '얼마나 많은 반복을 자동화하느냐'가 아니다. 루프가 닫히는 조건, 루프가 읽는 소스, 루프가 증명하지 못하는 경계—이 세 가지를 먼저 설계하는 것이다. 그 구조가 잡혀야 비로소 에이전트는 워크플로우에 붙어서 돌아가는 것이지, 단순히 옆에서 빠르게 틀리는 것이 아니게 된다.