AI 에이전트는 아무것도 결정하지 못하게 했습니다

AI 요약

영상과 TV 콘텐츠는 편집, 효과, 색보정, 품질 검사, 납품 단계를 차례로 거칩니다. 한 단계가 밀리면 다른 작업을 뒤로 미뤄야 마감을 맞출 수 있지만, 고객이 승인한 작업이나 감독이 중요하다고 표시한 작업을 건드리면 안 됩니다. 다른 작업이 기다리는 항목을 늦추면 후속 작업까지 막힙니다. 보통 담당자가 여러 화면을 확인하며 급하게 판단하는 영역입니다.

Shot-Delivery Guardian은 이 과정을 감시하다가 마감 지연이 예상되면 원인을 찾고, 미뤄도 안전한 작업을 제안합니다. 다만 최종 선택은 AI에게 맡기지 않았습니다. AI는 상황을 조사하고 설명하지만, 실제 후보 선정은 짧고 고정된 Python 규칙이 수행합니다.

AI가 결정하지 못하는 후보 선정 규칙

score_bump_candidates 함수는 먼저 세 조건에 해당하는 작업을 후보에서 제외합니다. 고객이 이미 승인한 작업, 감독이 중요하다고 표시한 작업, 다른 작업이 결과를 기다리는 작업입니다. 남은 항목은 각자 마감까지 남은 여유 시간인 slack_hours를 기준으로 정렬하고, 여유 시간이 가장 많은 작업을 미룰 대상으로 고릅니다.

AI는 이 규칙을 실행하고 결과를 원문 그대로 보고합니다. 규칙에 반대하거나 후보를 바꾸거나, 더 확신하는 것처럼 표현할 권한은 없습니다. 돈이나 계약에 직접 연결된 판단을 고정 코드로 제한하고, AI에는 정보 수집과 설명만 맡기는 구조입니다.

여덟 개 구성 요소와 대기열

전체 시스템은 하나의 큰 프로그램 대신 intake, rendering, color, quality checks, delivery, scheduling, test generator, AI로 나눴습니다. 한 영역의 지연이 나머지 전체를 멈추지 않게 하려는 설계입니다. 구성 요소 사이에는 대기열을 두어 처리 속도가 서로 다른 작업을 분리했습니다.

여덟 구성 요소는 모두 같은 형식으로 현재 상태를 보고합니다. 덕분에 각 도구마다 별도의 보고 체계를 만들 필요가 없습니다. 모니터링도 세 종류로 나눴습니다. 첫 번째는 전체 backlog가 얼마나 심각한지 보여줍니다. 두 번째는 관련 작업 목록과 승인자, 마감 시각 같은 항목별 정보를 보여줍니다. 세 번째는 특정 작업의 처리 과정에서 어느 단계에 시간이 소요됐는지 추적합니다. 한 가지 모니터링만으로는 전체 상황을 설명할 수 없기 때문입니다.

AI가 세 모니터링 도구에 질문하고, 답변을 담당자가 이미 보고 있는 대시보드에 남기도록 공유 커넥터 하나를 사용했습니다. 도구마다 별도 연결을 구현하지 않았고, 사람이 로그인 버튼을 누르지 않아도 시스템이 자동으로 인증해 이상 징후가 생기면 바로 실행하게 했습니다.

AI의 역할과 실제 장애 대응

AI의 역할은 작업 상태를 사람이 5초 안에 행동으로 옮길 수 있는 설명으로 바꾸는 일입니다. backlog가 가득 차고 거의 처리되지 않는다는 신호를 읽은 뒤 첫 번째 도구, 두 번째 도구, 세 번째 도구를 차례로 확인하고 고정 규칙을 실행해 결과를 정리합니다. 단순한 스크립트도 이 순서를 실행할 수 있지만, 진행 중인 상황을 자연어로 설명하는 일까지 맡기기는 어렵습니다. 결과는 별도 화면이 아니라 담당자가 보던 대시보드의 메모로 표시됩니다.

실제 테스트 중에는 세 모니터링 도구 가운데 하나에 접근하지 못하는 장애가 실행 중간에 발생했습니다. 시스템은 빈 부분을 숨기거나 추측하지 않고 문제를 그대로 설명했습니다. 다른 도구에서 가져온 정보만으로도 마감까지 약 한 시간이 남은 특정 작업을 미뤄도 안전하다고 보고했습니다. 작성자는 모든 연결이 정상인 데모보다 이 사례가 설계를 더 잘 보여준다고 설명합니다. 고정 규칙은 AI가 모든 정보를 완벽하게 얻어야만 작동하는 구조가 아니기 때문입니다.

실환경 테스트 결과

실제 실행 시스템으로 진행한 테스트 5회 가운데 고정 규칙만 실행했을 때와 같은 답을 낸 경우는 3회였습니다. 일치율은 60%입니다. 문제를 조사하고 응답하는 데 걸린 평균 시간은 44초였습니다. 반면 고객 승인 작업, 후속 작업이 기다리는 작업, 감독이 중요하다고 표시한 작업을 잘못 미룬 사례는 한 번도 없었습니다. 작성자는 60%라는 수치를 올려 쓰지 않고 그대로 제시합니다. 규칙 위반 0건이 작업 선택 일치율보다 더 중요한 지표라고 봅니다.

코드는 GitHub에 공개했으며 MIT License를 따릅니다. 저장소 이름은 shot-delivery-guardian입니다.

dev.to 반응

• @brianainews — 제가 신뢰하는 수치는 규칙 위반 0건이고, 60% 일치율은 거의 부차적입니다. 샷을 고르는 주체가 규칙뿐이라면 모델은 증거를 가져오고 필터를 피해 말로 둘러대지 않으면 됩니다. 두 번의 불일치는 잘못된 결정이 아니라 입력 누락처럼 들립니다. 도구 하나가 실행 중간에 멈춘 데모를 프로듀서에게 보여주겠습니다. 추측하지 않고도 여전히 미뤄도 안전한 작업 하나를 지목했기 때문입니다.
  • @dannwaneri — 그 점이 정확합니다. 두 번의 불일치는 점수 산정 함수가 잘못 고른 게 아니라 에이전트 자체 출력이 최종 답을 쓰기 전에 끝난 경우로 추적됩니다. 필터에는 나쁜 후보가 들어온 적이 없고, 제때 후보를 전달받지 못했을 뿐입니다. 네, 저도 실행 중간 복구 사례를 앞세우겠습니다. 단순히 깨끗한 실행이 성공한 모습이 아니라, 실제로 무언가 고장 났을 때도 설계가 버티는 모습을 보여주기 때문입니다.

원문: dev.to / 번역·요약: Trawling