루프 엔지니어링이란? 프롬프트·컨텍스트 다음 단계로 넘어간 AI 에이전트 루프 설계와 하네스

핵심 메시지

• AI 개발의 병목이 프롬프트 문구에서 컨텍스트 구성으로, 다시 에이전트가 도는 루프 설계로 이동했다.
• 가장 흔한 실패 원인은 종료 조건을 설계하지 않아 생기는 무한 루프다.
• '하네스'라 불리는 모델 주변의 결정론적 코드가 실제 운영 성패의 대부분을 좌우한다.
• 루프가 길어질수록 컨텍스트가 쌓여 품질이 먼저 무너지는 '컨텍스트 부패'가 발생한다.
• 값싸고 신뢰할 만한 검증기가 있는 단계는 자동화하고, 없는 단계에 사람을 배치한다.

쉽게 이해하기

몇 년 전만 해도 AI 분야에서 가장 값나가는 기술은 프롬프트 엔지니어링이었다. 모델이 경직돼 있었기 때문에 문장을 어떻게 쓰느냐가 결과 품질을 실제로 바꿨다. 모델이 좋아지면서 병목은 문구에서 옮겨갔다. 추론 시점에 모델이 무엇을 볼 수 있는가, 즉 검색된 문서·대화 기록·메모리·도구 결과를 어떻게 조합하느냐가 관건이 되는 컨텍스트 엔지니어링의 시대가 왔다.

지금은 세 번째 국면이다. 모델은 스스로 프롬프트를 쓰고 도구 호출로 필요한 컨텍스트를 직접 끌어온다. 입력을 잘 만드는 일이 더 이상 희소한 기술이 아니게 된 것이다. 남은 희소 기술은 에이전트가 그 안에서 도는 루프를 설계하는 일이다. 단계 사이에 무엇을 하는가, 언제 자기 작업을 점검하는가, 언제 끝났다고 판단하는가, 실패하면 어떻게 되는가.

루프의 기본 구조 자체는 단순하다. 모델이 호출되고, 행동(대개 도구 호출)을 결정하고, 하네스가 그것을 실행하고, 결과가 관찰로 돌아와 컨텍스트에 덧붙고, 다시 모델이 호출된다. 온라인 쇼핑몰 고객지원 에이전트를 예로 들면 의도 분류, 주문 조회, 정책 대조, 답변 작성 및 발송·에스컬레이션이 각각 같은 루프를 한 바퀴씩 도는 과정이다.

여기서 거의 아무도 설계하지 않는 항목이 종료 조건이다. 이걸 의도적으로 정하지 않으면 에이전트는 완료할 수 없는 과제를 붙들고 도구를 계속 호출하며 토큰을 태운다. 완료 신호, 반복 횟수 상한, 비용·토큰 예산, 통과 시 종료하는 검증기 같은 장치를 운영 환경에서는 대개 여러 개 동시에 걸어둔다. 모델이 스스로 '끝났다'고 느끼는 감각은 온전히 신뢰할 수 있는 대상이 아니기 때문이다.

경제성도 루프 설계를 공학의 영역으로 만든다. 반복 한 번은 곧 모델 호출 한 번이므로 지연시간과 비용이 루프 길이에 비례해 늘어난다. 두 단계면 될 일을 열 단계로 도는 에이전트는 단지 느린 게 아니라 추론 비용이 열 배이고 문제가 생길 표면적도 열 배다.

주요 인사이트

• 가장 흔한 실수는 에이전트를 단일 지점 솔루션으로 취급하는 것이다. 답변 생성 품질이나 의도 분류 정확도 한 곳만 몇 주씩 붙들고 다듬는 식인데, 주문 조회 도구가 타임아웃 났을 때 처리 로직이 없으면 완벽한 분류기도 아무 소용이 없다. 모든 노드가 서로 의존하는 구조에서 한 노드만 최적화하면 얻는 게 거의 없다.
• 하네스 엔지니어링이 그래서 중요하다. 사람들은 모델의 비결정성에 매료돼 운영 에이전트가 여전히 대부분 전통적인 소프트웨어라는 사실을 잊는다. 도구 호출 실패 시 재시도, 데이터베이스가 느릴 때의 타임아웃, 잘못된 출력에 대한 폴백, 권한 없는 환불 약속을 막는 가드레일, 장애 재구성을 위한 구조화된 로깅과 추적이 모두 하네스다. 영상에서는 모델이 전체의 5% 정도일 수 있다는 표현까지 나온다.
• 평가 방식도 함께 바뀌어야 한다. 답변 하나가 좋았는가를 보는 것으로는 부족하고, 수천 건의 대화에서 안정적으로 티켓을 해결하는가, 조회가 실패했을 때 우아하게 성능이 떨어지는가 아니면 없는 주문번호를 지어내는가를 봐야 한다. 문장을 채점하는 게 아니라 스트레스 상태의 시스템을 채점하는 일이다.
• 루프가 돌수록 컨텍스트는 쌓이고, 하드 리밋에 닿기 훨씬 전에 품질의 벽에 부딪힌다. 이를 컨텍스트 부패라 부른다. 대응책은 이전 단계를 주기적으로 요약하는 컴팩션, 사실을 외부 저장소에 쓰고 필요한 것만 꺼내오는 외부 메모리, 그리고 흔히 잊히는 도구 결과 관리다. 수천 행짜리 조회 결과를 그대로 모델에 되던지지 말고 걸러내고 요약해서 넣어야 한다.
• 멀티 에이전트 구조가 존재하는 진짜 기술적 이유도 여기에 있다. 깨끗하게 범위가 좁혀진 컨텍스트를 가진 서브 에이전트에 한정된 과제를 맡기고 결과만 돌려받으면 주 루프의 컨텍스트가 가볍게 유지된다. 즉 멀티 에이전트 오케스트레이션은 역량 과시가 아니라 컨텍스트 관리 전략인 경우가 많다.
• 검증 비용의 비대칭성이 자동화의 경계를 정한다. 코드는 컴파일되고 테스트를 통과하거나 아니거나로 값싸고 신뢰할 만하게 검증된다. 코딩 에이전트가 빠르게 좋아진 이유다. 반면 환불 판단이 타당했는지는 자동으로 값싸게 확인할 방법이 없다. 값싼 검증기가 있으면 루프 안에 넣어 스스로 고치게 하고, 없으면 그 자리에 사람을 둔다.

자주 묻는 질문

관련 AI 소식