폐쇄망 영상 저작 도구

원고를 넣으면 장면 → 이미지 → 내레이션 → mp4까지 LLM·이미지 생성·TTS를 모두 자체 기계의 로컬 모델로 만드는 영상 저작 도구다. 고객 GPU 서버로 반입할 수 있는 형태를 목표로 한 사내 PoC였다. 핵심은 GPU 한 장에서 세 엔진을 안전하게 교대시키는 미디어 게이트웨이와, 그 교대를 실측으로 확인한 야간 전체기능 검증이다.

• 당시 구성에서는 LLM과 이미지 모델(FLUX, 약 22GiB)을 GPU 메모리 48GiB 한 장에 함께 올려 두기 어려워(도커 VM 안 LLM 실사용 27.56GiB 기록) 두 모델을 번갈아 올리는 교대가 필요했다.
• 개발용 맥의 도커 VM에서는 GPU 가속(Metal)을 쓸 수 없어 컨테이너 안 LLM은 프리필이 멈춘 듯 느렸고, 이미지는 장당 수 분이 걸렸다.
• 「언로드 명령을 보냈다」와 「메모리가 실제로 비었다」가 다를 수 있었고, 다른 앱이 추론 서버를 직접 부르면 처리 중인 요청 위에서 모델이 내려갈 수 있었다.

구현·문서는 AI 에이전트(Claude Code 실행·Codex 검증)가 했다. 아래는 결정·지시 기록이 있는 것이다.

• 게이트웨이를 단일 관문으로 두고 엔진을 교대시키는 방식을 결정했다.
• 개발용 맥에서는 LLM만 네이티브(MLX)로 돌리고 서버 쪽은 전부 도커로 두기로 결정했다.
• 모델 선택과 동시성 구조 분석(통합 VLM으로 교대 자체를 없앨 수 있는지)을 지시했다.
• 전체기능 검증 시나리오·야간 작업 계획·후속 실행계획을 지시했고, 리소스 대시보드의 실용 범위를 확정했다.

1. 앱은 GPU를 모르고, 게이트웨이가 교대를 조정한다 — 앱은 OpenAI 호환 요청(글·이미지·음성)만 보내고, 게이트웨이가 처리 중 요청 계수·비우기·임대로 교대 순서를 정한다. 경합 조정 주체를 한 곳에 모아야 「동시 실행 0」을 증명할 수 있다. 대가로 교대마다 왕복 지연이 생기고 게이트웨이가 단일 실패점이 된다.
2. 명령이 아니라 실제 상태를 확인한다 — LLM 쪽은 프로세스 목록이 빌 때까지 기다리고, 이미지 엔진 쪽은 해제 요청에 즉시 「성공」을 돌려줘 믿을 수 없으므로 엔진을 패치해 노출한 해제 카운터가 오를 때까지 기다린다. 관측 지점이 없으면 만들어서라도 노출시켰다.
3. 환경마다 교대 방식을 나눈다 — 서버는 GPU 패스스루로 도커가 그대로 되므로 컨테이너 재시작, 개발용 맥은 도커 VM에서 가속이 안 되므로 LLM만 네이티브로 두고 모델 언로드로 교대한다.
4. 프롬프트 순서를 고쳐 캐시를 살린다 — 약 9,000토큰 템플릿이 가변값 뒤에 있어 편집할 때마다 캐시가 깨지고 다시 읽는 데 약 100초가 걸렸다. 템플릿을 시스템 프롬프트로 고정하고 가변값을 사용자 메시지로 옮겨, 코드 변경만으로 같은 접두 재요청이 21.7초에서 0.8초가 됐다(실측).

• 리소스 대시보드(2026.07): 수집기·화면·리포트를 스택과 분리했고, 세 단계 모두 Codex 게이트 통과로 닫혔다(19회차까지, 4회 반려 뒤 역할 교대 1회). 실스택 수동 검증 뒤 로그 수집 범위를 허용 목록으로 제한했다.
• 분산·성능(2026.07): 맥 2대 분산 배포 런북과 프리픽스 캐시 분석이 나왔다.
• 야간 전체기능 검증(2026.08): 본인이 지시한 시나리오로 브라우저 자동화 검증을 돌렸다. 신규 버그 3건이 나왔고, 이미지가 0장 나오던 버그는 장면이 15개를 넘어 장면 구성이 시간 초과되면 대체 변환이 이미지 지시를 통째로 버리는 것이 원인이었다 — 5줄 수정으로 고쳐졌다. 스트리밍 응답이 첫 바이트를 못 받으면 약 178초·300초에서 끊기는 원인도 규명됐다.
• 분석·인계(2026.08): 사용자 매뉴얼·통합보고서, 동시성·모델 선택 분석, 재구축 체크리스트와 반입용 묶음이 나왔다. 이후 주력은 강의 영상 생성 서버로 옮겨 갔다.

• 교대 왕복 27.7초, 동시 실행 구간 0(LLM 종료 1.495초 뒤 이미지 시작, 실측).
• 전체기능 검증 PASS 38·FAIL 6·BLOCKED 2·SKIP 4·범위 외 1·기록 6.
• 대시보드 시험 유닛 136/136·e2e 8/8·실스택 스모크 10/10·리포트 스모크 7/7.
• 후속 분석(별도 구성): 통합 VLM 19.1GiB + FLUX 22.2GiB = 41.3/48GiB(문맥 32k 전제, 65k면 초과)로, 개발용 맥에서는 두 모델이 공존할 수 있다는 결과가 나왔다(제안 — 미적용).
• 사용자 효과는 근거가 없다.

• 검증 시점의 이미지 서버는 stub(절차적 도형)이라 이미지 품질은 검증하지 않았다 — 보고서 첫머리에 이 전제를 적었다.
• FAIL 6·BLOCKED 2가 남은 검증이다. 다중 사용자 대기 큐가 없고 렌더 동시성은 1이다.
• 다른 앱도 게이트웨이를 거치게 하자는 안은 제안으로만 남았다.
• 반입 묶음은 원본과 분할본 152GB가 중복 보관됐고, 7월 묶음은 이후 디스크 정리로 지웠다(다시 만들 수 있음). 고객 서버 현장 설치 기록은 없고, 서비스 대상도 문서상 확인되지 않았다.

• 앱: Node 웹앱·에이전트형 워크플로(장면 구성·의도 파악)
• 게이트웨이: OpenAI 호환 계약(글·이미지·음성) → 로컬 엔진, 처리 중 요청 계수·비우기·임대
• 엔진: Gemma 4 26B(MoE, 맥 MLX·서버 도커), ComfyUI + FLUX.1-schnell fp8, Supertonic TTS
• 렌더·운영: HTML 장면 → Chromium → FFmpeg libx264, Docker compose, Tailscale 고정 주소, 리소스 대시보드(수집기 + Next.js·Recharts)

• 도구가 한 일: Claude Code가 게이트웨이·앱·대시보드 구현과 문서를, Codex가 게이트 검증을 맡았다. 야간 전체기능 검증은 브라우저 자동화(gstack)로 돌렸고, 버그 수정은 원격 검증 루프로 확인했다.
• 본인이 한 일: 교대 구조와 실행 환경 결정, 분석·검증 지시, 대시보드 범위 확정.
• 결과를 읽는 방식: 입증된 것(경로·교대)과 아닌 것(이미지 품질)을 나눠 보고서에 적었고, 검증 시나리오는 「요약 → 상세 → 따라하기」 형식으로 남겨 같은 검증을 다시 돌릴 수 있다.