대시보드는 무슨 일이 있었는지 보여줍니다. 피드백 루프는 그에 대해 조치를 취합니다.
이 차이는 프로덕션 AI에서 중요합니다. 대부분의 팀은 시스템을 충분히 계측해 사후에 장애를 확인할 수 있습니다. 하지만 사용자가 오류를 만나기 전에 루프를 닫는 수정 경로를 구축하는 팀은 드뭅니다.
이 글에서는 프로덕션 피드백 루프가 실제로 무엇을 포함하는지, 구현할 가치가 있는 세 가지 루프 설계, 그리고 취약한 커스텀 인프라 없이 이를 연결하는 방법을 다룹니다.
프로덕션 AI에서 피드백 루프란 무엇인가
피드백 루프는 세 가지 요소로 구성됩니다:
- 입력 신호 — 무언가 잘못되었을 수 있음을 나타내는 측정 가능한 이벤트
- 분류 — 신호가 노이즈인지 실제 오류인지 판단하는 로직
- 수정 경로 — 업데이트된 컨텍스트나 파라미터로 시스템에 자동으로 재진입하는 액션
수정 경로가 루프와 알림을 구분하는 요소입니다. 알림은 사람에게 알립니다. 루프는 직접 행동합니다. 사람이 여전히 검토하지만, 시스템은 그들이 알아채기를 기다리지 않습니다.
수정 경로가 없으면 모니터링에 불과합니다. 모니터링은 필요합니다. 하지만 피드백 루프는 아닙니다.
구축할 가치가 있는 세 가지 루프 설계
1. 하트비트 체크
하트비트 체크는 고정된 스케줄로 알려진 입력을 시스템에 전송하고, 출력을 알려진 정상 기준선과 비교합니다.
예시: 10분마다 결정론적 예상 출력이 있는 테스트 프롬프트를 전송합니다. 응답이 정의된 임계값을 벗어나면 — 예를 들어 코사인 유사도가 0.85 미만이면 — 루프는 해당 실행에 플래그를 달고, 델타를 로깅하며, 다음 실제 요청을 폴백 모델이나 캐시된 응답으로 라우팅합니다.
이는 모델 드리프트, 업스트림 API 성능 저하, 오류를 발생시키지 않는 무음 장애를 잡아냅니다. 핵심은 테스트 입력을 안정적으로 유지하는 것입니다. 테스트를 변경하면 기준선을 잃습니다.
하트비트 체크는 레이턴시와 출력 일관성이 새로움보다 중요한 시스템 — 분류 작업, 구조화된 추출, 라우팅 결정 — 에 가장 잘 작동합니다.
2. 출력 분류 감사
모든 나쁜 출력이 하드 장애는 아닙니다. 일부 출력은 기술적으로 유효하지만 컨텍스트에 맞지 않습니다 — 주제를 벗어나거나, 불완전하거나, 자신 있게 틀린 경우입니다.
출력 분류 감사는 라이브 출력 샘플에 경량 보조 모델을 실행하고 루브릭에 따라 점수를 매깁니다. 루브릭은 단순할 수 있습니다: 출력에 필수 필드가 포함되어 있는지, 정의된 주제 범위 내에 있는지, 플래그된 패턴을 피하는지.
예시: 매 시간 출력의 10%를 감사합니다. 해당 샘플의 오류율이 5%를 초과하면, 루프는 버전 관리된 프롬프트 스토어에서 프롬프트 수정본을 가져와 배포 없이 교체합니다.
이 설계에는 두 가지가 필요합니다: 테스트된 폴백이 있는 버전 관리된 프롬프트 스토어, 그리고 기본 모델보다 빠르고 저렴한 스코어링 모델. 파인튜닝된 분류기나 소형 instruction-tuned 모델이 적합합니다. GPT-4가 GPT-4를 감사하는 것은 비용이 많이 들고 상관된 장애를 유발합니다.
3. 부하 하의 배치 크기 튜닝
AI 시스템은 부하 하에서 명확하지 않은 방식으로 성능이 저하됩니다. 처리량이 떨어지고, 레이턴시가 올라가며, 출력 품질이 하락합니다 — 종종 오류율이 급등하기 전에. 오류가 보일 때쯤이면 이미 피해가 발생한 상태입니다.
배치 크기 튜닝은 실시간 레이턴시 신호를 기반으로 시스템이 동시에 처리하는 요청 수를 조정합니다. 루프는 다음과 같이 작동합니다:
- 60초 롤링 윈도우에서 p95 레이턴시를 측정
- p95가 SLA 임계값을 초과하면 배치 크기를 20% 줄임
- p95가 연속 5개 윈도우 동안 임계값 미만을 유지하면 배치 크기를 10% 늘림
이것은 정적 설정이 아닌 제어 루프입니다. 시스템이 조용히 성능 저하되도록 두는 대신 품질 범위 내에 유지합니다.
위의 수치는 시작점입니다. 실제 SLA와 부하 하에서 관찰된 시스템의 레이턴시 곡선에 맞게 튜닝하세요.
취약한 인프라 없이 이를 연결하는 방법
독립적으로 실행되는 세 개의 루프는 세 개의 유지보수 표면을 만듭니다. 목표는 세 루프 모두가 쓰고 읽는 단일 이벤트 버스입니다.
각 루프는 구조화된 이벤트를 발행합니다: 루프 유형, 신호 값, 임계값, 취해진 액션. 중앙 라우터가 해당 이벤트를 읽고 우선순위 로직을 적용합니다 — 하트비트 장애는 감사 트리거보다 우선하고, 감사 트리거는 배치 크기 조정보다 우선합니다.
이렇게 하면 수정 경로가 충돌하지 않습니다. 하트비트 장애가 트래픽을 폴백 모델로 라우팅하면, 배치 크기 루프는 기본 모델이 아닌 폴백 모델의 레이턴시를 기준으로 동작해야 합니다.
이벤트 스키마를 플랫하고 버전 관리된 상태로 유지하세요. 복잡한 중첩 스키마는 루프 로직이 변경될 때 깨집니다. 버전 필드가 있는 플랫 스키마가 마이그레이션하기 더 쉽습니다.
이미 범용 워크플로우 오케스트레이터를 운영하고 있지 않다면 그 위에 구축하는 것을 피하세요. 새로운 오케스트레이션 레이어를 학습하고 유지보수하는 오버헤드는 대개 단순한 메시지 큐와 몇 개의 워커 비용을 초과합니다.
실제로 어떻게 보이는가
세 루프를 모두 실행하는 시스템은 인간 개입 없이 대부분의 오류 클래스를 발생 후 1~2분 내에 감지하고 수정할 수 있습니다. 사람은 이벤트 로그를 검토하고, 임계값을 튜닝하며, 프롬프트 수정을 승인합니다. 개별 장애를 트리아지하지 않습니다.
그것이 목표입니다: 소프트웨어의 속도로 자체 오류 수정을 처리하고, 인간의 판단이 필요한 결정만 표면화하는 시스템.
여기서는 단순함이 이깁니다. 6개월 동안 조용히 실행되며 사용자가 보기 전에 40개의 오류를 잡는 루프는, 아무도 행동하지 않는 아름다운 대시보드를 생성하는 정교한 옵저버빌리티 스택보다 더 가치 있습니다.