Voithru의 이벤트 기반 아키텍처(EDA)를 통한 애플리케이션 현대화

보이스루는 ‘전세계 콘텐츠를 잇다’라는 슬로건 아래, 유튜브, 강의 등의 영상과 웹툰, 웹소설 등 뉴미디어 콘텐츠 번역을 전문으로 하는 콘텐츠 전문 번역 회사입니다. 보이스루는 다양한 콘텐츠 번역 과정에서 사람이 더 쉽고, 빠르게, 그리고 잘 번역할 수 없을까를 고민하며 이를 기술로 풀어내기 위해 노력하고 있습니다. Voithru의 주요 워크로드는 다양한 매체의 콘텐츠 번역, 수많은 파일 유형 처리 및 데이터 추출, 웹 브라우저 기반 에디터를 통한 파일 편집, TechQC 등을 활용한 품질 관리를 제공하는 통합 번역 관리 시스템입니다. 이 글에서는 보이스루의 번역 관리 시스템을 AWS 서비스를 활용해 현대화한 과정을 소개합니다.

Voithru의 번역 관리 시스템 소개

번역 관리 시스템이란?

Voithru는 2019년 유튜브 자막 번역 서비스로 시작하여 빠르게 성장, 독자적인 번역 프로세스를 구축했습니다. 현재 Voithru는 유튜브를 넘어 OTT, 웹툰, 웹소설 등 다양한 분야로 사업을 확장하고 있으며, 이 확장 과정에서 Voithru는 번역 프로젝트 매니저, 작업자, 고객을 위한 통합 번역 관리 시스템을 개발했습니다.

Voithru 번역 관리 시스템의 번역 워크플로우는 다양한 단계에서 파일 업로드와 처리가 이루어집니다. 원본 파일 수급, 작업자와 검수자의 작업 완료 파일 제출, 고객과 프로젝트 매니저의 직접 업로드 등 다양한 상황에서 파일 처리가 필요합니다. 특히 영상과 같은 대용량 미디어 파일을 다루거나 시리즈 형태의 대량 파일을 처리할 때는 한 번에 수백, 수천 개의 파일이 업로드될 수 있습니다. 또한, 작업자들의 선호 작업 시간과 납품 일정에 따라 특정 시간대에 파일 처리 요청이 집중되기도 합니다. 이러한 특성 때문에 Voithru의 번역 관리 시스템은 높은 유연성과 확장성이 요구됩니다.

Voithru의 번역 관리 시스템은 mov, srt, smi, psd, ai, indd, pdf, epub, clip 등의 매체에 맞는 다양한 파일 형식들을 다룹니다. 또한 웹 브라우저 기반의 번역 에디터를 비롯해 분석, TechQC등 파일의 데이터를 시스템에서 응용하기 위하여 각 파일 형식과 공정에 따라 필요한 파일생성, 추출, 변환 과정이 존재합니다. 이 번역 과정에서 생성되는 모든 데이터를 효과적으로 추출하고 활용하기 위해 여러 종류의 파일 처리 프로세스가 필요합니다.

번역 관리 시스템의 파일 처리 예시

Voithru의 다양한 파일 처리 프로세스 중 하나로, PSD(Photoshop) 파일을 처리하는 과정을 예로 들어보겠습니다. PSD 파일이 번역 관리 시스템에 업로드되면 우선 전처리 과정을 거칩니다. 전처리가 필요한 경우 PSD 추출 단계로 넘어가며, 그렇지 않으면 바로 이미지 리사이징 단계로 진행됩니다. PSD 추출이 완료되면, 텍스트 추출 성공 여부를 확인합니다. 텍스트 추출에 실패하면 이미지 추출을 시도하며, 이 과정도 실패할 경우 언어 감지 단계로 넘어갑니다. 텍스트 또는 이미지 추출이 성공하면, 프리뷰를 생성하고, 모든 과정이 끝나면 OCR 처리를 통해 최종적으로 이미지 리사이징 단계에 도달하게 됩니다.

기존 번역 관리 시스템의 문제점과 해결 방안 도출

Voithru의 기존 번역 관리 시스템은 Amazon EKS와 Amazon MQ 기반 이벤트 소싱과 코레오그래피 패턴을 활용한 마이크로서비스 아키텍처로 구성되어 있었습니다. 이 접근 방식은 초기에 효과적으로 작동했지만, 시간이 지남에 따라 몇 가지 중요한 한계점이 드러났습니다.

1. 코드 복잡성 증가: 여러 단계를 가진 파일 처리 워크플로우를 구현하기 위해 불필요한 단순 호출 코드가 많이 발생했습니다. 또한, 각 단계에 외부 API 연동 로직과 복잡한 분기 처리 로직이 추가되면서 전체적인 코드 복잡성이 크게 증가했습니다.
2. 유지보수의 어려움: 운영 중 워크플로우 변경에 신속하게 대응하기 어려웠고, 각 워크플로우를 시각적으로 파악하기 힘들어 유지보수에 상당한 어려움이 있었습니다.
3. 확장성 및 유연성 부족: 복잡한 워크플로우를 효과적으로 처리하기 위한 유연성과 확장성이 부족했습니다. 이로 인해 비즈니스 요구사항의 변화에 빠르게 적응하기 어려웠고, 새로운 기능을 추가하거나 기존 프로세스를 최적화하는 데 제약이 있었습니다.

이러한 문제를 해결하기 위해 Voithru는 AWS의 서버리스 서비스를 활용한 이벤트 기반 아키텍처를 도입하게 되었습니다. 이벤트 기반 아키텍처는 각 단계의 의존성을 줄이는 특징이 있지만, 번역 관리 시스템의 파일 처리 과정에서는 유기적인 워크플로우가 여전히 필요했습니다. 따라서, Voithru는 기존 아키텍처의 변경을 최소화하면서 AWS 서비스와의 결합에 용이한 서버리스 워크플로우 관리 서비스인 AWS Step Functions를 도입하였습니다.

기존 아키텍처에서는 모든 처리가 이벤트 기반으로 이루어졌으며, 아래 두 개의 스트림을 중심으로 동작했습니다.

• 이벤트 요청 스트림: 이벤트 수행을 요청하는 스트림
• 이벤트 결과 스트림: 이벤트 처리 결과를 보내는 스트림

모든 서버는 이벤트 요청 스트림을 구독하며, 자신이 처리해야 할 이벤트를 감지하고 해당 이벤트를 처리한 뒤 이벤트 결과 스트림으로 전송합니다. 그 후, 각 서버는 이벤트 결과 스트림을 구독하여 발생한 이벤트를 처리해야 할 경우 새로운 처리를 이벤트로 생성하고 이벤트 요청 스트림에 발행하는 방식으로 동작합니다.

이 구조에서 이벤트 스트림을 Amazon Kinesis Data Streams로 구성하였으며, 파일 처리 부분은 애플리케이션 외부로 분리하여 처리 로직을 단순화했습니다. 이를 통해 이벤트 결과 스트림을 기반으로 파일 처리를 수행한 후, 그 결과를 이벤트 요청 스트림에 다시 전송하는 방식으로 시스템을 결합하여 통합 작업을 용이하게 하였습니다.

AWS 서버리스 서비스를 활용하여 이벤트 기반 아키텍처 구축하기

이벤트 기반 아키텍처란?

이벤트 기반 아키텍처(Event-Driven Architecture, EDA)는 시스템에서 발생하는 이벤트를 중심으로 애플리케이션과 서비스를 구성하는 소프트웨어 설계 방식입니다. 이 아키텍처는 크게 이벤트를 만들어내는 생산자, 이벤트를 전달하는 라우터, 그리고 이벤트를 처리하는 소비자로 구성됩니다. 예를 들어, 사용자가 주문을 완료하면 ‘주문 완료’ 이벤트가 발생하고, 이 이벤트는 관련된 서비스(재고 관리, 배송 준비 등)에 전달되어 처리됩니다. 이런 방식으로 각 서비스는 독립적으로 동작하면서도 필요한 정보를 실시간으로 주고받을 수 있습니다. EDA는 특히 마이크로서비스나 복잡한 비즈니스 프로세스를 다루는 시스템에서 많이 사용되며, 시스템의 확장성과 유연성을 높이는 데 도움을 줍니다.

파일 처리 이벤트 연동 – Amazon EventBridge 커스텀 파이프라인

PSD 파일 처리 요청

Amazon Kinesis Data Streams에서 PSD-Extract-Requested 이벤트가 발생하면, 이 이벤트는 Amazon EventBridge로 전달됩니다. 이벤트 데이터에는 처리 성공 여부, 파일 처리 유형, 그리고 구체적인 처리 모드(예: PSD_EXTRACT)가 포함됩니다. EventBridge는 이 정보를 바탕으로 적절한 AWS Step Functions 워크플로우를 트리거하여 PSD 파일 처리 작업을 시작합니다.

PSD 파일 처리 완료 알림

AWS Step Functions에서 PSD 파일 처리가 완료되면, PSD-Extract-Completed 이벤트가 생성되어 Amazon EventBridge로 전송됩니다. 이 이벤트에는 처리 완료 상태 정보(예: “psdExtractCompleted“)가 포함됩니다. EventBridge는 이 이벤트를 다시 Kinesis Data Streams로 전달하여, 애플리케이션이 처리 결과를 확인하고 후속 작업을 수행할 수 있도록 합니다. 이러한 방식으로 파일 처리의 시작부터 완료까지 전체 프로세스가 이벤트 기반으로 연결됩니다.

파일 처리 워크플로우 구현 – AWS Step Functions

AWS Step Functions 도입의 주요 목적은 워크플로우 가시성 확보와 코드 작업 최소화였습니다. AWS Step Functions를 통해 작업 단계를 시각적으로 구성하여 전체 흐름을 쉽게 파악하고 실시간 모니터링을 통해 오류에 신속히 대응하도록 했습니다. 또한 AWS Step Functions에서 제공하는 네이티브 기능(작업 polling, wait, choice 등)으로 기존에 작성했던 단순 연동 코드를 줄이고 기능 추가나 로직 수정이 용이해졌습니다.

PSD 파일 처리 흐름

1. PSD 파일 처리 요청 이벤트를 시작으로 Step Functions 워크플로우가 시작됩니다. Node.js로 구성된 AWS Lambda 함수에서 PSD 데이터 추출을 시도합니다.
2. 이미지 추출이 실패했을 때, 실패 이벤트를 발생시켜 어플리케이션에서 사용자가 파일을 재업로드할 수 있는 유저플로우를 제공할 수 있게 합니다.
3. 텍스트 레이어 추출만 실패했을 때는 AI 서버에 요청하여 OCR을 통해 텍스트 추출을 시도합니다. 이 과정은 폴링 방식으로 주기적으로 결과를 확인하는 API에 요청하며, 매 루프에서 카운트를 하여 무기한으로 기다리지 않도록 처리합니다. 이처럼 간단한 처리는 별도 구성 없이 AWS Step Functions에서 단계를 추가하여 가능합니다.
4. 최종으로 성공하게 되면, Python으로 구성된 이미지 리사이즈 및 포매팅 작업을 수행하는 AWS Lambda 함수가 실행되며 Amazon EventBridge로 성공 이벤트를 발생시킵니다.

전환 결과

전체 시스템 구조도

1. 파일 업로드 이벤트
   1. API를 통해 파일 저장 이벤트가 발생하며, 실제로 API 요청은 API 서버가 이벤트 요청 스트림에 이벤트를 전송하는 것으로 시작됩니다.
   2. 파일 저장을 담당하는 파일 서버는 해당 이벤트를 수신하여 DB에 파일을 저장합니다. 이때 이벤트 소싱 패턴을 사용하여 이벤트와 그 이벤트가 반영된 스냅샷을 별도로 저장합니다.
   3. 저장 결과는 이벤트 결과 스트림으로 전송됩니다.
2. 파일 처리 이벤트
   1. 1.3에서 이벤트 결과 스트림으로 전송된 파일 저장 이벤트를 파일 처리 이벤트가 수신합니다.
   2. 분기 로직에 따라 필요한 파일 처리 생성을 위한 이벤트를 이벤트 요청 스트림에 보냅니다.
   3. 파일 처리 서버는 이벤트 요청 스트림에서 해당 이벤트를 수신하고, 1.2와 동일한 방식으로 DB에 저장합니다.
   4. 처리 결과는 이벤트 결과 스트림으로 전송됩니다.
3. 파일 처리
   1. EventBridge Pipe에서 2.4에서 발생한 파일 처리 생성 이벤트를 EventBridge로 전송합니다.
   2. Step Functions는 앞서 설명한 공정에 따라 파일 처리를 실행합니다.
   3. 처리 결과는 파일 처리 완료 이벤트로 이벤트 요청 스트림에 전송됩니다.
4. 파일 처리 완료 이벤트
   1. 파일 처리 서버는 이벤트 요청 스트림에서 파일 처리 완료 이벤트 수신하고, 1.2와 동일한 방식으로 DB에 저장합니다.

전환 효과

1. 코드 복잡도 감소: AWS Step Functions의 시각적 워크플로우 구성 도구를 활용하여 복잡한 파일 처리 로직을 간소화했습니다. 기존에는 여러 단계의 파일 처리 워크플로우를 구현하기 위해 불필요한 단순 호출 코드가 많이 발생했지만, Step Functions를 통해 각 단계를 시각적으로 구성하고 관리할 수 있게 되었습니다. 이로 인해 개발자들은 비즈니스 로직에 더 집중할 수 있게 되었고, 전체적인 시스템의 복잡도가 크게 감소했습니다.
2. 유지 보수 용이성 증가: 이벤트 기반 아키텍처의 특징인 느슨한 결합을 통해 시스템 유지 보수가 훨씬 쉬워졌습니다. Amazon EventBridge를 활용하여 이벤트 라우팅을 구현함으로써, 각 서비스 간의 의존성이 줄어들었습니다. 이로 인해 특정 서비스의 변경이 다른 서비스에 미치는 영향이 최소화되었고, 새로운 기능 추가나 기존 기능 수정 시 전체 시스템에 미치는 영향을 줄일 수 있었습니다. 또한, AWS Console을 통해 워크플로우를 시각적으로 모니터링하고 디버깅할 수 있게 되어, 문제 발생 시 신속한 대응이 가능해졌습니다.
3. 시스템 확장성 확보: AWS의 서버리스 서비스들을 활용함으로써 시스템의 확장성이 크게 향상되었습니다. Amazon Kinesis Data Streams를 이용한 이벤트 저장소 구현으로 대규모 데이터 스트림을 안정적으로 처리할 수 있게 되었고, AWS Lambda를 통해 필요에 따라 자동으로 확장되는 컴퓨팅 리소스를 확보했습니다. 특히, 피크 시간대의 대량 파일 처리 요청에도 유연하게 대응할 수 있게 되어, 시스템의 안정성과 성능이 크게 개선되었습니다. 이러한 확장성 확보로 인해 비즈니스 성장에 따른 시스템 확장 요구에 신속하게 대응할 수 있게 되었습니다.

결론

이 글에서는 Voithru의 AWS의 서버리스 서비스를 활용한 이벤트 기반 아키텍처(EDA)를 도입하여 번역 관리 시스템을 성공적으로 현대화한 과정을 소개했습니다. Voithru의 개발팀은 AWS Step Functions, AWS Lambda, Amazon EventBridge 등의 서비스를 활용하여 코드 복잡도 감소, 유지 보수 용이성 증가, 시스템 확장성 확보 등의 이점을 얻을 수 있었습니다. 이러한 개선을 통해 Voithru는 더욱 효율적이고 확장 가능한 번역 관리 시스템을 구축하였습니다. Voithru의 번역 작업 방식이 궁금하시다면 지난 Voithru의 GPT에서 Amazon Bedrock Claude Sonnet 3.5로의 전환 여정 게시글도 확인해보세요.