루프 엔지니어링으로 운영하는 AI 에이전트 피드백 구조

프롬프트는 배포 뒤에도 변한다

2026년 6월 첫째 주, 에이전트 개발 논의는 프롬프트 작성에서 루프 설계로 빠르게 옮겨갔다. Claude Code를 만든 Anthropic의 Boris Cherny는 “나는 더 이상 Claude에게 프롬프트를 쓰지 않는다. 내 일은 루프를 쓰는 것”이라고 말했고, 같은 시기 OpenClaw의 Peter Steinberger는 코딩 에이전트에 프롬프트를 주는 대신 에이전트가 프롬프트를 작성하는 루프를 설계해야 한다는 글을 올렸다. 이 글은 8백만 뷰를 넘겼다.

이 변화의 출발점은 간단하다. 한 번 잘 조정한 프롬프트가 계속 같은 성능을 낸다는 전제는 운영 환경에서 성립하지 않는다. 모델 제공자가 가중치를 갱신하면 동일한 입력과 프롬프트도 다른 출력을 낼 수 있다. 입력 데이터 분포가 바뀌면 기존 컨텍스트 가정이 흔들리고, 사용자가 예상하지 못한 방식으로 기능을 사용하면 원래 설계에 없던 요청이 누적된다.

이 상태를 구분하는 용어도 자리 잡고 있다.

프롬프트 드리프트(prompt drift): 프롬프트 자체를 수정하지 않았는데 출력 행동이 달라지는 현상
모델 드리프트(model drift): 모델 제공자의 갱신으로 동작 특성이 이동하는 현상
평가 점수 드리프트(eval-score drift): 루브릭 기반 점수의 이동 평균이 서서히 떨어지는 현상
프롬프트 회귀(prompt regression): 의도적으로 바꾼 프롬프트가 오히려 성능을 악화시키는 경우

드리프트는 관측으로 잡고, 회귀는 테스트로 찾아야 한다. 둘을 하나의 문제로 취급하면 원인과 처방이 뒤섞인다.

2026년의 전형적인 프로덕션 에이전트는 30개 프롬프트, 5개 모델 ID, 3개 리트리버, 12개 도구, 1개 플래너로 구성된다. 각각이 별도의 드리프트 표면이다. 전체 시스템의 집계 지표만 보면 개별 프롬프트의 열화는 평균값에 가려진다. 루브릭 점수 단위까지 내려가 감시해야 하는 이유다.

감시에서 재배포까지 이어지는 루프

arXiv에 공개된 2026년 루프 엔지니어링 실태 조사는 운영 가능한 루프의 요소를 다음처럼 정리한다. Addy Osmani가 제시한 자동화, 워크트리, 스킬, 플러그인·커넥터, 서브에이전트, 외부 상태와도 대체로 맞닿아 있다.

구성 블록	역할	부재 시 나타나는 문제
트리거·스케줄링	주기 또는 이벤트에 따라 실행 시작	사람이 매번 시작해야 하므로 루프가 되지 않음
목표·정지 조건	기계가 판단할 수 있는 완료 기준	무한 수정과 비용 폭주
상태·메모리	실행 사이의 결과 보존	매 회차마다 처음부터 다시 탐색
스킬·의도	프로젝트 지식의 영속적 인코딩	동일한 규칙을 매번 프롬프트로 설명
병렬 격리	동시 작업 간 충돌 방지	워크트리 없이 같은 파일을 동시에 수정
검증(maker/checker)	독립적인 주체가 결과 검증	자기 채점과 검증극
사람 감독·에스컬레이션	위험한 행위에 대한 게이트	무인 오류가 누적된 뒤 발견
예산·중지 제어	비용 상한과 변경 범위 제한	48시간에 8백만 토큰을 소진한 사례

조사가 보여준 채택 격차도 크다. 스캔한 36,710개 저장소 가운데 자율 에이전트 루프가 확인된 저장소는 217개(0.59%)였고, 이 중 189개는 Claude Code 기반이었다. 실무에서 자주 권고되는 커밋된 상태 파일은 36,645개 저장소 중 2개에서만 발견됐으며, 그 2개도 검증을 통과하지 못했다. 루프를 말하는 조직과 실제로 상태·검증·중지 조건을 구현한 조직 사이에는 여전히 큰 간극이 있다.

온라인 신호와 회귀 검증의 역할 분리

운영 루프는 품질 신호를 입력으로 받는다. 관측 대상은 보통 네 층으로 나뉜다.

출력 품질: LLM-as-a-judge 루브릭 점수, 검색 충실도(retrieval faithfulness), 환각 위험 점수의 시계열
실행 상태: 도구 호출 실패율, 스키마 오류율, 재시도 횟수, 정지 조건을 충족하지 못한 실행 비율
비용과 지연: 실행당 토큰, 실행당 소요 시간, 목표 달성까지 걸린 회차
사용자 반응: 명시적 평가인 엄지 표시와 재질문율, 세션 이탈, 수동 개입 빈도 같은 암묵적 신호

프로덕션 트래픽의 5~10%를 평가 모델로 온라인 채점하고, 회귀 테스트 스위트는 최소 주 1회 실행한다. 프롬프트 수정, 의존성 갱신, 제공자 모델 갱신 공지가 있을 때도 같은 스위트를 실행한다. 온라인 샘플링은 운영 중 드리프트를 발견하는 수단이고, 회귀 스위트는 변경이 낳은 회귀를 찾는 수단이다.

⤢✕

열화의 시작점을 찾아 처방하기

경보가 발생했다는 사실만으로는 무엇을 고쳐야 하는지 알 수 없다. 모델 변화, 데이터 변화, 사용자 행동 변화는 서로 다른 흔적을 남긴다.

모델 세대 변경은 특정 시점을 경계로 성능이 계단형으로 떨어지는 경우가 많다. 프롬프트와 데이터는 그대로인데 모델 ID가 달라졌거나 제공자의 릴리스 노트에 변경이 있다면, 프롬프트 재적합과 모델 ID 고정(핀) 정책을 검토해야 한다.

데이터 변화는 입력 길이 분포, 도메인 용어 빈도, 리트리버 상위 문서 구성이 천천히 움직이는 형태로 나타난다. 열화가 특정 세그먼트에 집중되는 경향도 있다. few-shot 예시 교체, 컨텍스트 큐레이션 규칙 갱신, 리트리버 재색인이 대응 수단이다.

사용 패턴 변화는 프롬프트가 전제하지 않았던 요청 유형에 실패가 몰린다. 신규 사용자군의 유입 또는 기능 출시와 시점이 겹치는 경우가 많다. 이때는 기존 프롬프트를 길게 늘리기보다 스킬과 라우팅 계층에 새로운 의도 분기를 추가해 커버리지를 넓힌다.

원인이 분명하지 않다면 실행 궤적에서 복구되지 않은 최초 실패 지점에 라벨을 붙인다. 증상은 연쇄될 수 있지만 처방은 연쇄가 시작된 지점을 향해야 한다.

트리거와 검증자를 별도로 설계한다

재학습과 개정은 하나의 조건에만 의존하면 안 된다. 루브릭 이동평균이 기준선 대비 N% 하락하는 임계 기반 트리거, 모델 갱신 공지·리트리버 재색인·도구 스펙 변경에 반응하는 이벤트 기반 트리거, 정기 회귀 스위트를 실행하는 주기 기반 트리거를 함께 둔다. 임계 기반만으로는 반응이 늦고, 주기 기반만으로는 사건에 즉시 대응할 수 없다.

피드백 구조에서 특히 중요한 것은 생성자와 검증자의 분리다. Osmani는 코드를 작성한 모델이 자기 숙제를 채점하기에는 지나치게 관대하다고 지적했다. 생성 에이전트와 다른 지시, 다른 모델, 다른 추론 강도를 가진 검증 에이전트가 완료 판정을 맡아야 한다. 그렇지 않으면 실질적 검증 없이 승인만 반복되는 검증극(verifier theater) 으로 흘러갈 수 있다.

사람 승인도 자동으로 안전을 보장하지는 않는다. 승인 요청이 지나치게 많으면 검토 피로가 쌓이고, 사람 게이트 역시 고무도장처럼 작동할 수 있다.

개선은 병행 비교로 확인한다

수정 뒤 결과가 좋아 보인다는 인상만으로 개선을 판정하면 안 된다. 최소한 다음 조건이 갖춰져야 한다.

기준선 점수가 있는 고정 회귀 스위트와 황금 데이터셋
변경 전후 순차 비교가 아닌 동일 기간의 병행 비교(A/B 또는 섀도 실행)
전체 평균뿐 아니라 사용자군별 성능을 확인하는 세그먼트 분해
품질 개선과 함께 비용·지연 회귀가 발생하지 않았는지 확인

루프 주기는 계층마다 다르게 운영하는 편이 현실적이다. 온라인 샘플 채점은 상시 수행하고, 회귀 스위트는 주 1회와 이벤트 발생 시 실행한다. 프롬프트 개정은 격주~월 1회, 아키텍처 수준 재설계는 분기 단위가 흔하다. 모든 활동을 하나의 주기로 맞추면 대개 가장 느린 계층에 맞춰져 감시가 둔해진다.

자동화는 되돌릴 수 있는 범위에서 시작한다

자동화 범위는 되돌릴 수 있는지 여부로 나눈다. 예시 교체, 임계 조정, 재색인처럼 복구가 쉬운 변경은 자동화할 수 있다. 외부 시스템에 부작용을 남기는 동작, 고객 대면 문구 변경, 권한 확대처럼 되돌리기 어려운 변경에는 사람 게이트가 필요하다.

예산과 중지 제어는 선택 기능이 아니다. 정지 조건이 부실한 루프가 48시간에 8백만 토큰을 사용한 사례가 보고됐다. 자동화 전에 비용 상한과 변경 범위를 제어할 수 있어야 한다.

프롬프트는 배포 아티팩트로 다뤄야 한다. 버전 태깅, 이전 버전으로 돌아갈 수 있는 즉시 복귀 경로, 어떤 지표가 어느 수준까지 악화되면 자동 롤백할지에 대한 기준을 사전에 문서화한다. 거버넌스는 프롬프트 수정 권한, 승인 대상 변경, 감사 로그의 저장 위치를 정하는 일이다. 무인 오류 누적, 이해 부채(comprehension debt), 인지적 항복(cognitive surrender)은 모두 이 통제가 비어 있을 때 커진다.

운영 체계에 루프를 심는 방법

처음 할 일은 프롬프트 인벤토리다. 코드, 설정, 노트북, 외부 SaaS에 분산된 프롬프트를 찾아 소유자, 사용 지점, 의존 모델 ID, 마지막 수정일, 연결된 평가셋 유무를 정리한다. 이 과정에서 평가셋이 없는 프롬프트가 절반 이상이라는 사실이 드러나는 경우가 많다. 인벤토리 없이 시작하면 이후 감시는 처음부터 표본 편향을 가진다.

각 프롬프트에는 대표 지표 1~2개와 경보 임계를 둔다. 지표가 너무 많으면 경보 피로가 생기고, 너무 적으면 열화를 놓친다. 온라인 채점과 실행 로그 같은 자동 신호, 사용자 피드백 위젯·지원 티켓 태깅·내부 사용자 리포트 같은 사람 신호는 하나의 이슈 추적기로 모아 동일한 큐에서 분류한다.

소유권도 명시해야 한다. 프롬프트별 오너와 개정 승인자를 지정하고, 개정 요청이 들어왔을 때 누가 회귀 스위트를 실행하는지 정한다. 비즈니스 지표인 과제 완료율과 재작업률은 루브릭 점수, 도구 실패율 같은 기술 지표와 연결해야 개선의 근거를 설명할 수 있다.

황금 데이터셋은 버전 관리하고, 프롬프트 변경 PR에서는 회귀 스위트가 CI로 자동 실행되게 한다. 병렬 작업은 워크트리 등으로 격리해 충돌을 막는다. 배포는 섀도 실행, 소규모 트래픽, 전면 배포 순으로 진행하며 각 단계에 승격과 롤백 기준을 둔다. 상태 파일을 저장소에 커밋해 회차 간 맥락을 잃지 않게 하는 작업도 이 범위에 포함된다. 하지만 앞서 본 것처럼 실제 구현에서는 거의 지켜지지 않는 항목이다.

마지막으로 변경 승인 절차, 감사 로그 보존 기간, 비용 예산과 초과 시 대응, 사람 개입이 필요한 행위를 정책으로 확정한다. Osmani의 경고처럼 “당신의 일은 작동을 확인한 코드를 출시하는 것이다.” 루프가 있다는 사실만으로 안전이 확보되지는 않는다. 프롬프트에서 시스템 아키텍처로 레버리지 지점이 옮겨갔을 뿐, 엔지니어링 판단은 더 많이 요구된다.

일회성 튜닝과 운영 루프의 차이

관점	루프 기반 지속 개선	일회성 튜닝
초기 비용	높음(감시·평가·배포 인프라)	낮음
누적 품질 손실	감시 주기 내로 제한	시간에 비례해 무제한 누적
운영 부담	상시(단, 자동화로 상수화)	사건 발생 시 급증, 예측 불가
원인 규명	시계열·세그먼트로 추적 가능	사후 추정에 의존
적합 영역	지속 운영되는 프로덕션 시스템	일회성 분석, 프로토타입

일회성 튜닝이 항상 잘못된 선택은 아니다. 수명이 짧고 재사용하지 않는 작업은 루프 구축 비용을 회수하기 어렵다. 판단 기준은 이 프롬프트가 앞으로 몇 번 더 실행될 것인가다.

자동 모니터링은 열화를 몇 시간 단위로 발견할 수 있다는 장점이 있다. 대신 임계가 너무 빡빡하면 오탐 경보가 쌓이고, 담당자가 경보를 무시하기 시작하면 감시 체계가 무력해진다. 사후 평가는 오탐 부담은 없지만 발견까지 수 주가 걸리며, 그 기간의 열화는 사용자에게 그대로 전달된다. 매출·안전에 직접 연결되는 소수 프롬프트에 실시간 경보를 두고 나머지는 주간 리포트로 묶는 중요도 계층화가 절충안이 된다.

버전 관리는 출력과 프롬프트 버전의 연결을 남기고, 롤백과 감사 대응을 가능하게 한다. 다만 승인 단계가 늘면 실험 속도는 떨어진다. 되돌리기 쉬운 변경은 즉시 배포할 수 있지만 버전 태깅은 남겨야 하며, 고객 대면 또는 안전 관련 변경만 승인 게이트를 통과시키는 방식이 가능하다. 태깅 없는 즉시 배포는 속도가 아니라 부채다.

기존 품질 관리 체계로 해석하기

루프 엔지니어링은 완전히 새로운 관리 체계라기보다 기존 운영 규율을 AI 시스템에 적용한 형태다. 황금 데이터셋과 회귀 스위트는 품질 보증(QA)에, 루브릭 점수·지연·비용의 지속 측정과 임계 경보는 성능 관리에, 프롬프트 버전 관리·승인 절차·롤백 정책은 변경 관리에 대응한다.

ITIL의 장애 관리와 문제 관리 구분도 여기에 적용할 수 있다. 개별 실행 실패를 복구하는 활동과 반복되는 열화의 근본 원인을 누적 사례에서 찾는 활동은 다르다.

기존 QA, 형상관리, 변경자문위원회(CAB) 체계에 프롬프트를 구성 항목(CI)으로 등록하면 승인 경로와 감사 절차를 재활용할 수 있다. 다만 프롬프트는 코드와 다른 위험을 가진다. 전통적인 소프트웨어는 코드를 바꾸지 않으면 동작이 바뀌지 않지만, 프롬프트는 아무 변경이 없어도 모델 갱신 때문에 동작이 달라질 수 있다. 변경 관리 트리거에 외부 의존 구성요소의 무고지 변경을 넣어야 하는 이유다.

기계 판정 가능한 완료 조건이 관건이다

현재 검증된 루프 엔지니어링 사례는 대부분 소프트웨어 엔지니어링에 집중돼 있다. API 마이그레이션, 테스트 스위트 수리, 백로그 소진처럼 완료 조건을 기계가 판정할 수 있는 작업에서 정교하게 작동하기 때문이다.

Stripe의 주당 1,300건 에이전트 작성 PR과 Mozilla Firefox의 한 달 423건 보안 수정 수치가 인용되지만, 독립 검증은 되지 않았다. 용어 역시 프롬프트에서 컨텍스트(context engineering), 하네스(harness engineering), 루프로 관심이 이동해 온 흐름의 최신 지점이며, 이미 그래프 기반 오케스트레이션을 다음 단계로 제시하는 논의도 나오고 있다.

앞으로의 쟁점은 루프 도입 여부가 아니다. 정지 조건을 기계가 판정할 수 있는 업무를 어디까지 확장할 수 있는지, 검증을 형식이 아니라 실질로 유지할 수 있는지가 관건이 될 전망이다. Cherny 역시 엔지니어가 불필요해진다고 말하지 않았다. 무엇을 만들지 결정하고, 고객과 대화하고, 팀을 조율하는 역할은 남으며 훌륭한 엔지니어의 중요성은 오히려 커진다는 단서를 남겼다.

프롬프트를 고정 자산이 아닌 운영 상태로 보면, 필요한 기반도 달라진다. 실제 자율 루프 채택률은 1%에 못 미치고 상태 영속화 같은 기본 권고도 거의 구현되지 않았다. 인벤토리, 평가셋, 버전 태깅, 롤백 정책 같은 기초 작업이 먼저 필요한 이유다.