들어가며
안녕하세요. 보이스루에서 CTO를 맡고 있는 윤승현입니다.
보이스루는 콘텐츠를 세계로 퍼트리기 위해 콘텐츠 번역을 하고 있습니다.
유튜브, OTT 영상, 웹툰, 웹소설 등 여러 장르의 콘텐츠를 각국의 언어로 번역하고 있죠.
작업 관리 관점에서 번역 산업은 소프트웨어 개발과 프로세스가 매우 닮아있습니다.
개발 조직의 PM이 제품 기획과 관리를 담당하고 FE, BE, Designer 각각의 업무를 할당하는 것처럼
번역 프로세스도 번역 PM이 번역의 모든 과정을 기획하고 관리합니다.
또한 번역 프로세스는 여러 단계로 구성되어 있습니다.
웹툰 번역의 경우, 웹툰의 텍스트를 번역하는 번역 단계, 번역 결과를 다듬는 윤문 단계,
번역된 글과 원본 웹툰을 번역 웹툰으로 만드는 단계인 식자,
최종결과물을 검수하는 QA 단계로 구성됩니다.
Voithru TMS
소프트웨어 개발에는 JIRA와 같은 소프트웨어 개발 프로세스 솔루션이 존재하는데요.
간단한 개발은 노션의 칸반 기능 같은 다른 툴을 많이 사용하기도 하지만,
팀의 규모가 커질수록 그리고 운영 기간이 길수록 복잡한 업무 프로세스 운영과 히스토리 관리를 위해서는
개발 프로세스 솔루션 도입이 필수입니다.
미국의 빅테크 기업들이 엔지니어 조직의 인프라 및 백오피스, 개발자 도구에 대한 투자를 아끼지 않는 것도 이와 같은 맥락입니다.
개발자 도구와 개발 솔루션이 프로젝트에 큰 생산성 향상을 가져온다는 사실을 정확히 알고 적극 도입하고 있는 겁니다.
보이스루는 번역 PM 한 사람이 10개 내외의 번역 프로젝트를 동시에 관리하고 있습니다.
프로젝트는 여러 단계의 업무로 구성되어 있습니다. 그리고 여러 프로젝트에 동일한 번역가가 할당되기도 합니다.
한 명의 번역가가 월요일과 화요일에는 프로젝트 A에 할당되고, 수요일과 목요일에는 프로젝트 B에 할당되는 방식입니다.
보이스루 프로덕트 매니저(PM) 역할
PM이 자신의 번역 프로젝트에 번역가를 할당하려면 번역가의 현재 업무 상태와 스케쥴을 확인해야 하는데요.
이때 각 단계에 지연이 발생하기도 하고, 단계별 담당자와 상당한 커뮤니케이션이 필요합니다.
회사 규모가 커질수록 PM이 관리해야 하는 프로세스의 복잡도도 커집니다.
보이스루 번역 프로세스에는 소프트웨어 개발 프로세스 솔루션 JIRA와 같은 역할로, TMS(Translation Management Solution)가 있습니다.
이 솔루션은 프로젝트의 진행 정도를 한눈에 파악할 수 있고, 번역 담당자 관리, 번역물 파일 관리 등을 PM이 중앙에서 관리할 수 있도록 도와줍니다.
JIRA 내 이슈 기능처럼 각 단계가 완료되면 프로젝트의 다음 단계로 자동 이동 및 관리할 수 있는 워크플로우를 제공합니다.
TMS를 통해 PM의 작업 관리 효율은 향상됩니다. 특히 회사 규모가 커질수록 여러 프로젝트를 동시에 운영할 때,
번역 프로젝트 담당자의 일정 관리와 프로젝트 히스토리 관리 기능은 필수입니다.
TMS 개발 과정 그리고 어려움
https://voithru.com/service
그렇다면 보이스루는 어떤 TMS를 통해 콘텐츠 번역 프로세스를 관리하고 있을까요?
Totus는 보이스루의 TMS ver.2입니다.
기존 Hermes 프로젝트를 진행하면서 ver.1인 Minglo를 만들었고, 2년간의 운영 경험을 토대로 Mercury 프로젝트를 진행했는데요.
기존 ver.1 Minglo의 시스템은 유튜브 영상 번역 서비스인 Jamake의 번역물을 생성하는 TMS를 목적으로 만들어졌습니다.
현재 번역 PM은 TMS를 통해 기존 대비 5배 더 많은 양의 프로젝트를 관리하고 있습니다.
그 결과, 현재 보이스루의 번역 프로세스는 TMS에 매우 의존하고 있습니다.
TMS 도입 전, 번역 관련 데이터는 Google Sheets, Excel 등 다양한 도구와 형태로 번역 PM이 개별 관리해왔습니다.
각 번역 PM마다 필요한 데이터 형태로 데이터를 관리했는데요. 데이터의 형태 변경이 필요할 때마다 각각의 PM이 수정하고 있었습니다.
TMS 도입 이후 프로젝트 데이터 관리 역시 더 용이해졌습니다.
처음 만든 TMS ver.1 Minglo는 유튜브 영상 번역 프로세스 관리와 효율화를 제공하기 위해 개발되었습니다.
Jamake로 들어온 영상 번역 의뢰를 확인하고, 작업물 분배와 납품은 Minglo를 통해 진행했습니다.
TMS를 도입하기 전에는 작업물 의뢰 시, 먼저 작업자를 구인하고 카카오톡 메신저로 소통했는데요.
작업물을 작업자에게 일일이 전달하고 완료한 후 Jamake 시스템에 납품 처리하는 프로세스였습니다.
Minglo는 Jamake에 들어온 요청을 작업자가 설치한 App에 전송하여 작업물을 분배하고, 작업 완료시 자동으로 납품되는 프로세스를 제공했습니다.
기존 작업자 구인, 작업 분배, 작업물 납품을 개별 태스크로 진행했던 과거와 비교했을 때, 중간 관리자인 PM의 공수를 절약할 수 있었습니다.
보이스루의 번역사업이 확장되면서, 유튜브 외에도 OTT의 영상 번역, 웹툰 번역, 웹소설 번역도 TMS를 통해 해결해야 했습니다.
상 번역 작업이 시작된 이후 원본 영상이 편집되는 일이 발생해 번역 결과물을 교체해야 하는 일도 발생했습니다.
또한 웹툰, 웹소설의 경우 영상 번역 프로세스와 다른 프로세스를 만들어야만 했습니다.
TMS ver.2 Totus는 다양한 번역 플로우와 번역 대상이 바뀌는 등의 여러 특이 케이스를 처리하기 위해 개발됐는데요.
이제 번역 PM은 기존 Minglo에선 불가능했던 다양한 변칙 플로우들을 설계할 수 있고,
플로우의 자동화 진행과 원본 번역물 변경이 발생하더라도 번역을 이어 나갈 수 있게 되었습니다.
번역 PM에서 변경 니즈가 발생하면 TMS 내 PM으로 요구사항 접수, BE의 API 개발, FE의 Front 개발로 효율적인 프로세스가 구축되었습니다.
그런데 번역 PM 입장에서 개별적으로 파일을 관리하는 것보다 분명 효율성은 커졌지만, 여전히 TMS 변경 작업에는 어려움이 남았습니다.
Totus TMS에 의존적으로 번역 프로세스가 변경되면서 TMS의 변경 속도가 결국 회사 비즈니스의 발전 속도에 비례하는 상황이 발생했는데요.
기획 단계에서 번역 PM의 요구사항을 미리 잘 분석해 시스템을 개발하는 것도 방법이지만,
요구사항 분석을 아무리 잘하더라도 사용자 UI 상 프로세스 변경 요청은 자주 발생합니다.
또 성장하는 비즈니스에 따른 서비스 변경 사항은 필연적으로 발생하죠.
여러 프로젝트를 경험해보신 분들은 충분히 이해하실 거라 생각됩니다.
Rest API 기반 개발 플로우와 한계점
TMS 개발 요구 사항이 주로 들어오는 부분 중 가장 처리하기 어려운 부분은 데이터 View입니다.
Marketing Operations 도구로 유명한 Salesforce의 고객 관리 프로세스 View와 유사한데요.
데이터를 집계해서 보여주거나 현재 프로젝트 상황을 조회하는 페이지에서 데이터 추가 표현 요청 사항이 많이 발생합니다.
요구 사항을 해결하는 방식에는 몇 가지가 있습니다.
API에서 데이터를 추가해 내려주거나, FE에서 데이터의 연관 관계를 파악해 API를 여러 번 call하여 데이터를 가져오는 방식입니다.
FE에서 API 데이터의 연관 관계를 파악해 Data를 fetching하는 방법은 FE 개발자에게 많은 양의 코드를 작성하게 만들고,
이 방법은 Network 영향을 많이 받습니다.
결론적으로 API에서 데이터를 추가하는 방법은 REST에 맞지 않았습니다.
이는 더 많은 양의 정보를 Response에 전달하면서 관리가 어려웠습니다.
REST를 유지하기 위해 데이터를 내려주는 형태에 맞게 path를 만들어 전달해봤지만,
같은 Resource에 데이터를 전달하는 GET API 개수만 늘어났고, 결국 페이지마다 데이터를 내려주는 도메인을 만들어 내려줘야 했습니다.
PM의 요구 사항을 잘 분석하고, 그에 맞는 형태로 새로 API를 설계하고 내려주면 업무가 더 편해질 것 같았습니다.
하지만 빠르게 변하는 스타트업 사정상, 현업 프로세스는 월 단위로 변경되었고,
월 단위에 맞는 API를 만들어 내려주기에는 작업 속도가 더딘 상황이었습니다.
결국 TMS에서 실사용을 확신하기 어려운 기능은 논의를 통해 소거하고, CI/CD 가능한 기능 위주로 선별 개발을 진행했습니다.
하지만 아쉽게도 번역 PM 실무자는 자신들이 직접 관리했을 때 쉽게 데이터를 추가하고 붙일 수 있었던 자유가 사라져 불편해했습니다.
프로그램 개발 BE는 늘어나는 API 관리라는 불만 사항이, FE는 API 개발 소요 시간에 따라 Front 작업 기간이 너무 짧다는 불만 사항이 발생했습니다.
마치며
<GraphQL vs REST, 보이스루 API를 고민하다 ①>편은 여기서 마치겠습니다.
번역 소프트웨어 개발 솔루션의 필요성에서 출발해 보이스루의 TMS 소개와 개발 과정을 소개했습니다.
Rest API 기반 개발 플로우 상 한계점을 발견한 보이스루 테크팀은 GraphQL 사용을 시도하고 개발 플로우를 새로 작성하는데요.
이야기는 다음 편에서 이어집니다.
감사합니다.
Microservice Architecture
들어가며
안녕하세요. 보이스루에서 CTO를 맡고 있는 윤승현입니다.
보이스루는 콘텐츠를 세계로 퍼트리기 위해 콘텐츠 번역을 하고 있습니다.
유튜브, OTT 영상, 웹툰, 웹소설 등 여러 장르의 콘텐츠를 각국의 언어로 번역하고 있죠.
작업 관리 관점에서 번역 산업은 소프트웨어 개발과 프로세스가 매우 닮아있습니다.
개발 조직의 PM이 제품 기획과 관리를 담당하고 FE, BE, Designer 각각의 업무를 할당하는 것처럼
번역 프로세스도 번역 PM이 번역의 모든 과정을 기획하고 관리합니다.
또한 번역 프로세스는 여러 단계로 구성되어 있습니다.
웹툰 번역의 경우, 웹툰의 텍스트를 번역하는 번역 단계, 번역 결과를 다듬는 윤문 단계,
번역된 글과 원본 웹툰을 번역 웹툰으로 만드는 단계인 식자,
최종결과물을 검수하는 QA 단계로 구성됩니다.
Voithru TMS
소프트웨어 개발에는 JIRA와 같은 소프트웨어 개발 프로세스 솔루션이 존재하는데요.
간단한 개발은 노션의 칸반 기능 같은 다른 툴을 많이 사용하기도 하지만,
팀의 규모가 커질수록 그리고 운영 기간이 길수록 복잡한 업무 프로세스 운영과 히스토리 관리를 위해서는
개발 프로세스 솔루션 도입이 필수입니다.
미국의 빅테크 기업들이 엔지니어 조직의 인프라 및 백오피스, 개발자 도구에 대한 투자를 아끼지 않는 것도 이와 같은 맥락입니다.
개발자 도구와 개발 솔루션이 프로젝트에 큰 생산성 향상을 가져온다는 사실을 정확히 알고 적극 도입하고 있는 겁니다.
보이스루는 번역 PM 한 사람이 10개 내외의 번역 프로젝트를 동시에 관리하고 있습니다.
프로젝트는 여러 단계의 업무로 구성되어 있습니다. 그리고 여러 프로젝트에 동일한 번역가가 할당되기도 합니다.
한 명의 번역가가 월요일과 화요일에는 프로젝트 A에 할당되고, 수요일과 목요일에는 프로젝트 B에 할당되는 방식입니다.
보이스루 프로덕트 매니저(PM) 역할
PM이 자신의 번역 프로젝트에 번역가를 할당하려면 번역가의 현재 업무 상태와 스케쥴을 확인해야 하는데요.
이때 각 단계에 지연이 발생하기도 하고, 단계별 담당자와 상당한 커뮤니케이션이 필요합니다.
회사 규모가 커질수록 PM이 관리해야 하는 프로세스의 복잡도도 커집니다.
보이스루 번역 프로세스에는 소프트웨어 개발 프로세스 솔루션 JIRA와 같은 역할로, TMS(Translation Management Solution)가 있습니다.
이 솔루션은 프로젝트의 진행 정도를 한눈에 파악할 수 있고, 번역 담당자 관리, 번역물 파일 관리 등을 PM이 중앙에서 관리할 수 있도록 도와줍니다.
JIRA 내 이슈 기능처럼 각 단계가 완료되면 프로젝트의 다음 단계로 자동 이동 및 관리할 수 있는 워크플로우를 제공합니다.
TMS를 통해 PM의 작업 관리 효율은 향상됩니다. 특히 회사 규모가 커질수록 여러 프로젝트를 동시에 운영할 때,
번역 프로젝트 담당자의 일정 관리와 프로젝트 히스토리 관리 기능은 필수입니다.
TMS 개발 과정 그리고 어려움
https://voithru.com/service
그렇다면 보이스루는 어떤 TMS를 통해 콘텐츠 번역 프로세스를 관리하고 있을까요?
Totus는 보이스루의 TMS ver.2입니다.
기존 Hermes 프로젝트를 진행하면서 ver.1인 Minglo를 만들었고, 2년간의 운영 경험을 토대로 Mercury 프로젝트를 진행했는데요.
기존 ver.1 Minglo의 시스템은 유튜브 영상 번역 서비스인 Jamake의 번역물을 생성하는 TMS를 목적으로 만들어졌습니다.
현재 번역 PM은 TMS를 통해 기존 대비 5배 더 많은 양의 프로젝트를 관리하고 있습니다.
그 결과, 현재 보이스루의 번역 프로세스는 TMS에 매우 의존하고 있습니다.
TMS 도입 전, 번역 관련 데이터는 Google Sheets, Excel 등 다양한 도구와 형태로 번역 PM이 개별 관리해왔습니다.
각 번역 PM마다 필요한 데이터 형태로 데이터를 관리했는데요. 데이터의 형태 변경이 필요할 때마다 각각의 PM이 수정하고 있었습니다.
TMS 도입 이후 프로젝트 데이터 관리 역시 더 용이해졌습니다.
처음 만든 TMS ver.1 Minglo는 유튜브 영상 번역 프로세스 관리와 효율화를 제공하기 위해 개발되었습니다.
Jamake로 들어온 영상 번역 의뢰를 확인하고, 작업물 분배와 납품은 Minglo를 통해 진행했습니다.
TMS를 도입하기 전에는 작업물 의뢰 시, 먼저 작업자를 구인하고 카카오톡 메신저로 소통했는데요.
작업물을 작업자에게 일일이 전달하고 완료한 후 Jamake 시스템에 납품 처리하는 프로세스였습니다.
Minglo는 Jamake에 들어온 요청을 작업자가 설치한 App에 전송하여 작업물을 분배하고, 작업 완료시 자동으로 납품되는 프로세스를 제공했습니다.
기존 작업자 구인, 작업 분배, 작업물 납품을 개별 태스크로 진행했던 과거와 비교했을 때, 중간 관리자인 PM의 공수를 절약할 수 있었습니다.
보이스루의 번역사업이 확장되면서, 유튜브 외에도 OTT의 영상 번역, 웹툰 번역, 웹소설 번역도 TMS를 통해 해결해야 했습니다.
상 번역 작업이 시작된 이후 원본 영상이 편집되는 일이 발생해 번역 결과물을 교체해야 하는 일도 발생했습니다.
또한 웹툰, 웹소설의 경우 영상 번역 프로세스와 다른 프로세스를 만들어야만 했습니다.
TMS ver.2 Totus는 다양한 번역 플로우와 번역 대상이 바뀌는 등의 여러 특이 케이스를 처리하기 위해 개발됐는데요.
이제 번역 PM은 기존 Minglo에선 불가능했던 다양한 변칙 플로우들을 설계할 수 있고,
플로우의 자동화 진행과 원본 번역물 변경이 발생하더라도 번역을 이어 나갈 수 있게 되었습니다.
번역 PM에서 변경 니즈가 발생하면 TMS 내 PM으로 요구사항 접수, BE의 API 개발, FE의 Front 개발로 효율적인 프로세스가 구축되었습니다.
그런데 번역 PM 입장에서 개별적으로 파일을 관리하는 것보다 분명 효율성은 커졌지만, 여전히 TMS 변경 작업에는 어려움이 남았습니다.
Totus TMS에 의존적으로 번역 프로세스가 변경되면서 TMS의 변경 속도가 결국 회사 비즈니스의 발전 속도에 비례하는 상황이 발생했는데요.
기획 단계에서 번역 PM의 요구사항을 미리 잘 분석해 시스템을 개발하는 것도 방법이지만,
요구사항 분석을 아무리 잘하더라도 사용자 UI 상 프로세스 변경 요청은 자주 발생합니다.
또 성장하는 비즈니스에 따른 서비스 변경 사항은 필연적으로 발생하죠.
여러 프로젝트를 경험해보신 분들은 충분히 이해하실 거라 생각됩니다.
Rest API 기반 개발 플로우와 한계점
TMS 개발 요구 사항이 주로 들어오는 부분 중 가장 처리하기 어려운 부분은 데이터 View입니다.
Marketing Operations 도구로 유명한 Salesforce의 고객 관리 프로세스 View와 유사한데요.
데이터를 집계해서 보여주거나 현재 프로젝트 상황을 조회하는 페이지에서 데이터 추가 표현 요청 사항이 많이 발생합니다.
요구 사항을 해결하는 방식에는 몇 가지가 있습니다.
API에서 데이터를 추가해 내려주거나, FE에서 데이터의 연관 관계를 파악해 API를 여러 번 call하여 데이터를 가져오는 방식입니다.
FE에서 API 데이터의 연관 관계를 파악해 Data를 fetching하는 방법은 FE 개발자에게 많은 양의 코드를 작성하게 만들고,
이 방법은 Network 영향을 많이 받습니다.
결론적으로 API에서 데이터를 추가하는 방법은 REST에 맞지 않았습니다.
이는 더 많은 양의 정보를 Response에 전달하면서 관리가 어려웠습니다.
REST를 유지하기 위해 데이터를 내려주는 형태에 맞게 path를 만들어 전달해봤지만,
같은 Resource에 데이터를 전달하는 GET API 개수만 늘어났고, 결국 페이지마다 데이터를 내려주는 도메인을 만들어 내려줘야 했습니다.
PM의 요구 사항을 잘 분석하고, 그에 맞는 형태로 새로 API를 설계하고 내려주면 업무가 더 편해질 것 같았습니다.
하지만 빠르게 변하는 스타트업 사정상, 현업 프로세스는 월 단위로 변경되었고,
월 단위에 맞는 API를 만들어 내려주기에는 작업 속도가 더딘 상황이었습니다.
결국 TMS에서 실사용을 확신하기 어려운 기능은 논의를 통해 소거하고, CI/CD 가능한 기능 위주로 선별 개발을 진행했습니다.
하지만 아쉽게도 번역 PM 실무자는 자신들이 직접 관리했을 때 쉽게 데이터를 추가하고 붙일 수 있었던 자유가 사라져 불편해했습니다.
프로그램 개발 BE는 늘어나는 API 관리라는 불만 사항이, FE는 API 개발 소요 시간에 따라 Front 작업 기간이 너무 짧다는 불만 사항이 발생했습니다.
마치며
<GraphQL vs REST, 보이스루 API를 고민하다 ①>편은 여기서 마치겠습니다.
번역 소프트웨어 개발 솔루션의 필요성에서 출발해 보이스루의 TMS 소개와 개발 과정을 소개했습니다.
Rest API 기반 개발 플로우 상 한계점을 발견한 보이스루 테크팀은 GraphQL 사용을 시도하고 개발 플로우를 새로 작성하는데요.
이야기는 다음 편에서 이어집니다.
감사합니다.