사내 영상 하이라이트 쇼츠 자동 제작 서비스

사내 영상을 올리면 AI가 하이라이트 구간을 고르고 보안 심의를 거친 뒤, 검수자가 승인한 구간만 쇼츠로 렌더하는 사내망(외부 인터넷이 막힌 고객 사내 네트워크) 전용 웹 서비스다. 7일 기획과 pilot 구현을 거쳐 고객사 개발서버 2대(CPU 앱 서버·GPU 추론 서버)에 설치했고, 두 서버 모두 현장 합격 판정 전이다.

• AI 판정을 승인 근거로 쓰지 않으면서(사람 검수 필수) 심의 근거와 감사 기록을 남겨야 했다.
• 원본 영상은 사내 전용이라 허용된 곳 밖으로 나가면 안 됐다.
• 가동 중인 기존 서비스에 영향을 주지 않고 올려야 했다.
• 서버에 인터넷이 없어 반입 묶음으로만 설치할 수 있고, 현장에서 발견한 결함을 그 자리에서 고칠 수 없었다.

구현·시험·문서는 AI 에이전트가 했다 — 실행자 Claude Code, 독립 검증자 Codex. 아래는 기록이 남은 본인 행동만이다.

• 기획: PRD 결정표의 결정을 확정했고(사외 공개 관련 2건은 다음 단계로 미결), 동시 사용성 검토를 요청해 같은 날 결정했다.
• 원칙: 원본 반출 통제는 「허용 목록 밖으로 한 바이트도 안 나간다」 하나만 코드가 지키게 했고, 저장소 정리 실패 때 서비스를 재기동하는 설계 대신 작업 단위 격리를 택했다.
• 배포·디자인: 기존 서비스를 바꾸지 않는 개발서버 배포 구성 5가지를 정했고, 디자인 시안을 골라 기존 화면 옆 병행판으로 가게 했다.
• 확인: 로컬·매뉴얼·설치 문서에서 결함 13건을 보고하고 기능 문의 30건을 남겼다.
• 검증 운용: 「검증은 2회만」 지시를 넘겨 보정이 6차까지 가자 지적해 멈췄고, 상한 예외는 건별로 승인했다.
• 현장: 두 개발서버의 설치 명령을 서버에서 직접 실행했다.

1. 원본 반출 통제는 코드가 「목록 밖 차단」 하나만 지킨다 — 어떤 추론 주소를 허용할지는 운영 정책이라 운영자에게 두고, 코드는 목록 밖 전송 차단만 맡겼다. 원본 영상은 어떤 추론 주소로도 보내지 않는다.
2. 기존 서비스를 건드리지 않는 배포 구성 — 쇼츠 전용 Redis를 따로 두고, 음성인식은 GPU 서버에 새로 올렸다. CPU 추정 속도로는 앱의 처리 시한을 맞추기 어려워 GPU를 골랐고, 추정치라서 현장 측정 3회와 합격선(RTF 0.25 이하)을 함께 정했다. 기존 서비스에 미치는 영향을 줄이는 쪽을 택했고, 현재 쇼츠 작업은 한 번에 1건으로 제한한다.
3. 고장이 나도 재기동하지 않는다 — 저장소 정리 실패는 해당 작업만 격리하고 관리 화면 [다시 시도]로 복구한다. 이 묶음은 Codex 검증 exit 0으로 닫혔다. 영구 기록은 디스크가 정본이고 Redis는 다시 만들 수 있는 색인이다.
4. 디자인은 색이 아니라 화면 구조부터 — 색만 바꾼 시험에서 접근성 위반 822건 중 812건이 색 대비였다(측정). 그래서 시안 구조를 그대로 적용하고, 기존 화면 옆에 같은 데이터를 쓰는 새 화면을 병행했다.

• 기획(2026.09): PRD·기획서가 7일 만에 나왔고 Codex 계획 검증 7회와 문서 검증 1회를 거쳤다. 1차 범위는 사내 쇼츠만으로 줄였다 — 사외 공개는 정책 합의가 먼저다.
• 구현(2026.09): 구현 6일 시점에 시험 924개가 됐다. 초기 게이트가 세 번 반려로 멈췄다가, 3차부터 검증 주체를 바꾸는 방식(2-AI 개발 방법론)을 들인 뒤 프로젝트 첫 Codex 통과(exit 0)가 나왔다.
• 기능 확장(2026.09~10): 산출물 확장·세로 크롭 동의·자막 영역 가림·AI 심의 지시 편집이 더해졌다. 키워드가 구간을 강제로 만들던 방식은 한 영상에서 쇼츠가 22개 나온 뒤 본인이 수정을 요청했고, 해결안으로 폐지됐다.
• 배포 연습(2026.10): 실서버 판을 재현한 로컬 연습 호스트 2대에서 기존 서비스의 상태 확인 31회가 모두 정상이었고 설치 전후 구성이 같았다(연습 실측). 연습이 잡은 결함 19건은 반입 전에 고쳐졌다. Codex 패키지 검증은 3회 모두 반려였고, 마지막 반영은 재검증 없이 회귀 160 통과·0 실패로만 확인했다.
• 설치(2026.10): GPU 서버는 설치 단계 통과·음성인식 측정·기존 서비스 불변 확인으로 「설치 완료, 합격 아님」, CPU 서버는 「설치 완료·현장 합격 아님」으로 판정됐다.
• 현장 결함(2026.10): 현장 브라우저 환경과 연습 환경의 차이로 영상 제출 오류가 났다. 화면만 바꾼 수정판으로 고쳤고, 결함 재현·교체·복구를 연습 환경에서 확인했다. 현장 종합 검증은 남았다.

• 본 저장소 cargo test 1,229 통과·0 실패(2026.10, 로컬) — 개발서버 현장 결과가 아니다.
• GPU 서버 음성인식 RTF 0.019~0.020(3회, 대상 음성 약 230초, 현장 실측)으로 기준인 0.25 이하를 충족했다.
• 개발서버 단계(2026.09 말~10월)의 검증 중 Codex exit 0은 디자인 1회를 포함해 9회다. 나머지는 검증 횟수 상한, 본인 지시(user_directed), 「반려 뒤 수정·시험만 수행」으로 닫았다.
• 사용자 효과는 근거가 없다 — 현장 합격 전이고 실제 사용 기록이 없다.

• 두 서버의 현장 합격 조건을 충족했다는 증거가 아직 모두 기록되지 않았다 — 동시 부하 시험을 포함한 현장 종합 검증이 남았다.
• 동시 부하 시험은 하지 않았고, 응답시간·동시 사용자 수치는 없다.
• 오류 패치는 Codex 검증 3회가 모두 반려(치명 5 → 2 → 1)였고, 마지막 수정은 시험·연습만 하고 재검증 없이 반입을 준비 중이다 — 결과 미확정.
• 28분 영상은 기본 처리 시한에서 실패했다. 시한을 늘려 맥 연습에서는 끝까지 갔지만 현장 성공은 확인되지 않았고, 도구별 시한 분리는 다음 판으로 미뤘다.
• 쇼츠 작업은 한 번에 1건으로 제한하며, 동시 부하 검증은 남았다. 저장소 커밋이 0건이라 판 갈래를 소스 사본으로 관리했다.
• 다음 단계(계획): 오류 패치 적용 → 디자인 패치 적용 → 매뉴얼 갱신.

• 백엔드: Rust/Axum 단일 프로세스, 워커 단계 파이프라인, 관리 API
• 저장: 디스크 정본(fsync·승격 저널) + Redis 색인(AOF), 감사 해시 사슬
• AI: llama.cpp Gemma 4 26B-A4B(vision), whisper.cpp large-v3-turbo(CUDA)·mlx-whisper, tesseract OCR
• 화면: Vite + TypeScript, vitest, axe 접근성 검사
• 배포: Docker compose 오프라인 번들(설치·업그레이드·되돌리기 스크립트), 조각 + SHA-256 반입 묶음, 화면만 바꾼 파생 이미지 수정판

• 도구가 한 일: Claude Code가 PRD·기획서 초안, 구현, 시험, 매뉴얼·설치 문서를 맡고, Codex가 1·2차 독립 검증과 수정 가이드를 냈다. 3차부터는 역할을 바꿔 Claude가 검증하고 Codex는 보정안만 냈으며, 일부 작업은 Codex 구현·Claude 검증으로 돌렸다.
• 교대가 찾은 것: Codex가 두 번 본 뒤에도 남아 있던 「점검 모드에서 감사 복구가 돌아 크래시 뒤 기동이 막히는」 치명 결함을 3차 교대 검증에서 찾았다.
• 대체 검증의 한계: Codex 사용량 한도 때 다른 모델(Qwen)로 3회 대체 검증했지만 통과 확정 권한은 주지 않았고, 같은 날 Codex 최종 검증을 받았다.
• 본인이 한 일과 기록 원칙: 결정·결함 보고·검증 상한 운용·현장 설치는 본인이 했다. 「통과」는 Codex exit 0일 때만 쓰고, 설치 완료와 현장 합격은 서로 다른 상태로 기록했다.