이터널 리턴 보이스 제작 워크플로우 통합 시스템.

01 · PROBLEM

PM이 ‘인간 라우터’가 되어버린 8단계 파이프라인

게임 캐릭터 보이스 제작은 번역팀, 사내 실무자, 외부 녹음 스튜디오가 얽힌 8단계 파이프라인입니다. 문제는 이 8단계가 Google Sheets, Gmail, Drive, Slack — 서로 연결되지 않는 4개의 도구에 흩어져 있었고, 그 사이를 잇는 유일한 연결고리가 PM의 수작업이었다는 점입니다.

모든 단계가 수동 라우팅 — 일정은 시트에 색칠하고, 발주는 Gmail에 매번 새로 작성하고, 녹음본이 도착하면 Drive 링크를 Slack에 복사해 나르고, 실무자들이 Slack에 남긴 셀렉 의견을 PM이 다시 메일로 옮겨 스튜디오에 전달했습니다. 콘텐츠 하나가 끝날 때까지 같은 정보가 사람 손으로 네 번씩 이사를 다녔습니다.

흩어진 커뮤니케이션, 불가능한 인수인계 — 어떤 콘텐츠가 지금 어느 단계인지, 스튜디오와 무슨 합의가 오갔는지가 메일함과 슬랙 쓰레드와 시트에 파편화되어 있어, 담당자가 아니면 현황 파악 자체가 불가능했습니다. 업무를 넘겨받을 다음 사람을 위한 구조가 존재하지 않았습니다.

시트 하나의 겸직 한계 — 스프레드시트 하나가 일정 트래커, 캐릭터 설정집, 성우 캐스팅 현황을 동시에 떠맡으며 구조적 한계에 도달해 있었습니다.

02 · APPROACH

도구를 하나 더 얹는 대신, 흐름 자체를 다시 설계하다

출발점은 앞서 만든 성우 녹음 일정 자동 등록 봇이었습니다. 8단계 중 ‘일정 등록’ 한 구간을 자동화해 실제로 운영해 보니, 마찰이 사라진 구간 옆에서 나머지 구간들의 수동 라우팅이 오히려 더 선명하게 보였습니다. 구간마다 봇을 하나씩 덧붙이는 방식으로는 결국 ‘봇들 사이를 잇는 일’이 또 PM의 몫으로 남는다는 것도요. 그래서 아이디어를 더 큰 맥락으로 확장했습니다 — 발주부터 셀렉 파일 정리까지, 흐름 전체를 한 곳에서 컨트롤하는 단일 시스템. 또 하나의 관리 도구를 추가하는 대신 흐름 자체를 다시 설계하기로 하고, 외주 개발 없이 직접 만들기로 했습니다.

스펙 주도 개발 — PM이 직접 만든다 — AI 코딩 에이전트를 페어 프로그래머로 두고, 기능마다 [브레인스토밍 → 설계 스펙 → 단계별 구현 플랜 → 구현 → 2단계 코드 리뷰]의 프로세스를 돌렸습니다. 실작업일 10일 동안 설계 스펙과 구현 플랜 문서 20여 건이 쌓였고, 모든 기능이 문서에서 출발해 코드로 끝났습니다.

단계별 출시 — 매 스테이지가 실무 투입 가능 — 전체를 5개 스테이지로 쪼개, 시트 대체(일정·캐릭터·캐스팅)부터 출시하고 Gmail 자동화, Drive·Slack 통합, 셀렉 워크플로우를 순차적으로 얹었습니다. 완성을 기다리지 않고 현장에 먼저 투입하는 구조입니다.

3-role 권한 모델 — PM(전체), 실무자(셀렉·열람), 스튜디오(캐스팅 정보만 보이는 락다운 화면)로 권한을 분리해, 외부 협력사까지 한 시스템 안으로 끌어들였습니다.

03 · SYSTEM

8단계 워크플로우가 앱 안에서 흐른다

단계	기존	시스템에서
러프 일정	시트 색칠	Gantt 스케줄 보드
스튜디오 발주	Gmail 수동 작성	템플릿 + 변수 자동 치환 → 원클릭 발사
일정·자료 협의	메일함에 파묻힘	쓰레드 뷰어 내장, 콘텐츠 카드에서 바로 답장
녹음본 공유	Drive→Slack 수동 복붙	파일 등록 + 슬랙 알림 (멘션 자동완성)
셀렉	Slack 의견 → PM이 메일로 중계	실무자가 앱에서 직접 듣고 분류
셀렉 파일 정리	Drive 수동 이동	”셀렉 완료” 클릭 → 폴더 자동 생성 + 일괄 복사 + 슬랙 알림

핵심은 셀렉 워크플로우입니다. 실무자가 셀렉 페이지를 열면 편집본 폴더의 음원이 자동으로 나열되고, 브라우저에서 바로 재생하며 셀렉본 / 업적 / 제외로 분류합니다. 진행 상태는 저장되어 언제든 이어할 수 있고, “셀렉 완료”를 누르는 순간 분류 결과대로 Drive에 폴더가 만들어지고 파일이 복사되며 슬랙으로 완료 알림이 나갑니다. 기존에 Slack 의견 취합 → PM 메일 중계 → Drive 수동 이동으로 이어지던 채널 라우팅 구간이 통째로 사라졌습니다.

기술적으로는 Next.js 15 + Supabase 기반의 풀스택 앱으로, Drive 음원을 서버 프록시로 스트리밍(HTTP Range 지원)해 토큰 노출 없이 재생하고, Slack 워크스페이스 멤버를 동기화해 @ 입력만으로 실제 핑이 가는 멘션을 완성하는 등 현장 사용감을 좌우하는 디테일에 공을 들였습니다. Cloudflare Workers에 배포해 운영 중입니다.

04 · IMPACT

10일, 1인, 실서비스

PM 1인이 실작업일 10일 만에 실서비스 배포까지 — 커밋 190+, TypeScript 약 12,000줄, DB 마이그레이션 22개. 별도 개발 리소스 요청 없이 기획자가 직접 설계하고 구현해 사내 배포까지 완료했습니다.

수동 라우팅의 구조적 제거 — 발주 메일 작성, 녹음본 링크 나르기, 셀렉 의견 중계, Drive 파일 정리 — PM의 손을 거치던 반복 구간이 시스템의 버튼 하나로 대체되었습니다.

인수인계가 가능한 업무로 — 콘텐츠별 진행 단계, 메일 쓰레드, 파일 위치가 한 화면에 모이면서, ‘담당자의 머릿속에만 있던 업무’가 누구나 이어받을 수 있는 구조로 바뀌었습니다.

05 · LEARNINGS

현장을 아는 사람이 직접 만들 때 생기는 일

AI 번역 시스템 프로젝트에서 “PM의 도메인 지식이 곧 AI의 품질”이라는 확신을 얻었고, 그 후로 일정 봇·Jira 자동화 같은 도구들을 직접 만들어 현장에 정착시켜 왔습니다. 이 프로젝트는 거기서 규모를 한 단계 더 밀어붙인 검증이었습니다 — 단일 기능 봇을 넘어, 권한 모델과 DB, 외부 협력사까지 품는 풀스택 운영 시스템까지도 PM이 직접 만들 수 있는가.

보이스 제작 파이프라인을 수년간 직접 굴리며 어느 단계에서 정보가 유실되고 누구의 야근으로 메워지는지를 피부로 알고 있었습니다. 그래서 요구사항을 누군가에게 ‘설명’할 필요 없이, 페인 포인트에서 곧바로 화면과 데이터 모델을 설계할 수 있었습니다. 외주가 압축 파일로 줄지 폴더로 줄지, 실무자가 셀렉을 끊었다 이어할지 같은 — 현장에 있지 않으면 스펙에 적을 수 없는 디테일들이 시스템의 완성도를 결정했습니다.

AI 코딩 에이전트는 그 설계를 코드로 바꾸는 속도를 극적으로 끌어올렸지만, 무엇을 만들지·어디까지 만들지·무엇을 만들지 않을지의 판단은 끝까지 사람의 몫이었습니다. 기획과 개발의 경계가 흐려지는 시대에, PM의 경쟁력은 ‘현장의 아픔을 시스템의 언어로 번역하는 능력’이라는 것을 몸으로 확인한 프로젝트입니다.