Node.js백 엔드 서버 개발자 주니어의 동영상 쇼츠 서비스 프로젝트 기술적 의사 결정

BackEnd

1. NestJs를 선택한이유 vs Express

1. 구조화와 확장성

• NestJS는 모듈 기반 아키텍처를 제공하므로, 프로젝트를 기능 단위로 잘게 나누어 관리할 수 있습니다.
  • 동영상 업로드, 처리, 검색, 사용자 관리 등의 기능을 모듈로 분리하여 개발과 유지보수를 쉽게 할 수 있습니다.
• 쇼폼 콘텐츠 프로젝트는 기능 추가(예: 추천 알고리즘, 댓글 기능 등)가 빈번할 가능성이 높으므로, NestJS의 구조화된 방식이 장기적으로 유리합니다.
• Express는 구조를 사용자가 설계해야 하며, 프로젝트 규모가 커질수록 코드 복잡도가 증가합니다.

2. TypeScript 지원

• NestJS는 TypeScript를 기본 지원하며, 강력한 정적 타입 검사와 IDE 자동 완성 기능을 제공합니다.
  • 동영상 메타데이터, 사용자 정보, 파일 처리 등 복잡한 데이터 구조를 다룰 때 오류를 줄이고 개발 속도를 높입니다.
• Express는 TypeScript를 사용할 수 있지만, 설정이 추가적으로 필요하며, NestJS처럼 TypeScript와 완전히 통합된 경험을 제공하지는 못합니다.

3. 유연한 확장 및 통합

• NestJS는 Express를 기반으로 동작하지만, 필요에 따라 Fastify로 전환하여 성능을 높일 수도 있습니다.
• AWS SDK, FFmpeg, 데이터베이스(PostgreSQL, MongoDB)와 같은 외부 라이브러리를 통합하기 쉬운 구조를 제공합니다.
  • 예: 동영상 파일 업로드 API, AWS S3와의 연동, Atlas Search 기반 검색 API를 구현하는 데 적합.
• Express도 유연하지만, 이러한 통합 작업을 NestJS보다 체계적으로 관리하려면 추가적인 설계가 필요합니다.

4. 개발 생산성

• NestJS는 **의존성 주입(Dependency Injection)**을 기본적으로 제공하여 서비스 간의 의존성을 관리하기 쉽게 만듭니다.
  • 동영상 처리 서비스, 사용자 인증 서비스 등 여러 서비스가 서로 독립적으로 동작하도록 구현할 수 있습니다.
• Express는 의존성 관리가 기본 제공되지 않아, 대규모 프로젝트에서는 DI 관련 프레임워크를 추가로 도입해야 할 수 있습니다.

5. 테스트와 유지보수

• NestJS는 내장 테스트 지원(Jest 기반)을 제공하여 단위 테스트 및 통합 테스트를 쉽게 작성할 수 있습니다.
  • 쇼폼 콘텐츠 작업에서는 API의 정확성과 동영상 처리 로직의 안정성이 중요하므로, 테스트가 필수입니다.
• Express는 테스트 작성에 필요한 라이브러리와 설정을 사용자가 추가적으로 구성해야 하며, 유지보수와 테스트 작성이 더 번거로울 수 있습니다.

6. 성능

• 기본적으로 Express는 NestJS보다 경량화되어 초기 성능이 약간 더 우수할 수 있습니다.
  • 하지만 쇼폼 콘텐츠 프로젝트는 동영상 파일 처리나 데이터베이스 요청 등 백엔드 로직의 무게가 더 크기 때문에 이 차이는 실제 프로젝트 성능에 큰 영향을 주지 않습니다.
• NestJS는 Fastify를 선택할 경우 Express보다 높은 성능을 낼 수도 있어, 성능 문제에 대응할 유연성이 높습니다.
  
  
  따라서 
  
  동영상 업로드 요청 처리, 메타데이터 분석 및 저장, 클라이언트 API 제공을 위한 백엔드 서버로 사용되었습니다. NestJS는 모듈 기반 구조를 제공하므로 API와 서비스 로직을 분리하기 용이하며, TypeScript 지원으로 프로젝트 유지보수가 쉬워졌습니다. 동영상 메타데이터(업로드 시간, 크기, 사용자 ID 등)를 분석한 후 Amazon RDS에 저장하고, 이를 클라이언트가 요청할 때 API를 통해 제공합니다. 대량의 요청을 효율적으로 처리할 수 있는 비동기 기반 구조로, 업로드된 동영상이 많아도 안정성을 유지합니다.

참고자료:
https://www.youtube.com/watch?v=p29wLfPlxqo
https://puk0806.tistory.com/95
https://jaejade.tistory.com/99
https://kimmangyu.tistory.com/entry/NestJs-Express%EC%99%80-NestJs%EC%B0%A8%EC%9D%B4
https://diane073.tistory.com/260

 

[Nest.js] Node.js와 Nest.js에 대한 이해

 

[NestJs] Express와 NestJS차이

 

[Nest.js] Express와 비교했을 때 Nest.js의 장점이라고 생각한 것

 

[Nest]NestJS란? Express 차이점, NestJS Start

 

2. TypeORM을 선택한 이유 vs Prisma

TypeORM 

풍부한 기능 지원 (Full ORM)

• TypeORM은 완전한 ORM으로, 데이터베이스 작업을 객체 지향적으로 처리할 수 있습니다.
  • 엔터티(Entity) 정의, 관계 설정, 쿼리 작성 등 모든 데이터 작업을 코드로 구현할 수 있습니다.
  • Prisma와 달리 데이터베이스에서 직접 동작하는 SQL 쿼리를 생성해 디테일한 제어가 가능합니다.
• 동영상 쇼폼 콘텐츠 프로젝트에서는 동영상 메타데이터, 사용자 정보 등 복잡한 관계형 데이터 모델을 다룰 수 있어 유리합니다.

2. SQL 레벨의 제어

• TypeORM은 SQL 쿼리를 필요에 따라 작성하거나, 자동으로 생성된 SQL 쿼리를 세밀히 조정할 수 있는 유연성을 제공합니다.
• 프로젝트 초기 단계에서는 간단한 메타데이터 저장, 이후 단계에서는 **고급 데이터 작업(복잡한 JOIN, 필터링)**이 필요하므로, SQL 제어가 가능한 TypeORM이 적합합니다.

3. 엔터프라이즈급 기능

• TypeORM은 엔터티 관리, Lazy/Eager Loading, 관계 매핑과 같은 기능을 내장하여 대규모 프로젝트에 적합합니다.
• 동영상 메타데이터와 사용자 데이터를 다루는 프로젝트에서 1:N, N:M 관계를 쉽게 설정하고 관리할 수 있습니다.

4. TypeScript와 긴밀한 통합

• TypeORM은 TypeScript 네이티브로 설계되어, 강력한 타입 검사와 코드 자동 완성 기능을 제공합니다.
• 데이터베이스 스키마와 엔터티 간의 매핑이 일관되어, 데이터 구조를 추적하기 쉬워집니다.
  
  TypeORM의 단점
  • 마이그레이션 관리 복잡성:
    • 대규모 데이터베이스를 사용할 경우 Prisma보다 마이그레이션 관리가 번거로울 수 있습니다.
  • 퍼포먼스 문제:
    • TypeORM은 Prisma보다 무거운 쿼리를 생성하는 경향이 있어 대규모 데이터 작업에서 성능이 다소 떨어질 수 있습니다.

Prisma

1. 개발 생산성 향상

• Prisma는 자동 생성된 데이터베이스 클라이언트를 통해 데이터 작업을 간소화합니다.
  • Prisma Schema를 기반으로 SQL 쿼리를 자동 생성하며, 복잡한 쿼리를 작성할 필요 없이 직관적인 API로 데이터베이스 작업이 가능합니다.
• 쇼폼 콘텐츠 프로젝트에서 빠르게 데이터 작업을 구현할 때 유리합니다.

2. 마이그레이션 관리의 용이성

• Prisma는 데이터베이스 마이그레이션 관리를 쉽게 할 수 있는 도구를 제공합니다.
  • Prisma CLI를 사용하면 데이터베이스 스키마 변경(컬럼 추가, 관계 수정 등)이 간단하고 안정적으로 수행됩니다.
  • 데이터 모델이 자주 변경되는 초기 개발 단계에서는 Prisma가 더 적합합니다.

3. 데이터베이스 다중 지원

• Prisma는 PostgreSQL, MySQL, MongoDB 등 여러 데이터베이스를 지원하며, 이를 단일 클라이언트에서 관리할 수 있습니다.
• 쇼폼 콘텐츠 프로젝트에서 MongoDB(태그, 로그)와 PostgreSQL(메타데이터)을 모두 사용하는 경우 Prisma가 더 유리합니다.

4. 안전한 쿼리 작성

• Prisma는 SQL Injection 방지를 위해 쿼리를 자동으로 생성하며, 타입 안전성을 보장합니다.
• 동영상 검색, 필터링과 같은 작업에서 SQL Injection에 대한 위험을 줄일 수 있습니다.

Prisma의 단점

• 고급 쿼리의 한계:
  • Prisma는 매우 직관적인 API를 제공하지만, 복잡한 SQL 쿼리를 작성하거나 최적화하는 데 있어 제한이 있습니다.
  • 프로젝트가 성장하며 더 복잡한 데이터 로직이 필요할 경우 TypeORM만큼 세밀하게 조정하기 어렵습니다.
• 러닝 커브:
  • Prisma는 Schema와 CLI에 익숙해지기까지 시간이 걸릴 수 있습니다.

TypeORM 을 선택한 이유는 

프로젝트에서 타입 안정성을 높이기 위해 TypeORM과 Prisma를 비교한 결과, TypeORM이 관계형 데이터베이스의 복잡한 관계 설정을 잘 관리하고 TypeScript와의 호환성도 뛰어나 우리 프로젝트에 적합하다고 판단했습니다.
TypeORM의 Entity 기능을 통해 데이터베이스 구조를 명확히 정의하고, 타입 오류를 사전에 감지할 수 있어 개발 효율성을 높일 수 있었습니다.
따라서, TypeORM 를사용하여 복잡한 쿼리와 관계 설정을 효과적으로 처리하고 타입 안정성을 유지했습니다.



참고자료:https://www.youtube.com/watch?v=hAUE-gK80f0
https://www.youtube.com/watch?v=8WoeGcJ_nNM
https://www.prisma.io/docs/orm/more/comparisons/prisma-and-typeorm

 

 

https://octoping.tistory.com/37

https://velog.io/@developer119/Type-Orm-VS-Prisma

Type Orm VS Prisma

 

[번역] TypeORM vs Prisma

 

Prisma ORM vs TypeORM | Prisma Documentation

 

3 .AWS SDK 를 선택한 이유 vs api GateWay

1.SDK 란 무엇인가 ?

소프트웨어 개발 키트(SDK)는 개발자를 위한 플랫폼별 구축 도구 세트입니다.
특정 플랫폼, 운영 체제 또는 프로그래밍 언어에서 실행되는 코드를 만들려면 디버거, 컴파일러 및 라이브러리와 같은 구성 요소가 필요합니다.
SDK는 소프트웨어를 개발하고 실행하는 데 필요한 모든 것을 한 곳에서 제공합니다. 또한 SDK에는 문서, 튜토리얼 및 가이드와 같은 리소스와 더 빠른 애플리케이션 개발을 위한 API 및 프레임워크가 포함됩니다.


2.SDK 의 이점은 무엇인가 ??

1.효율적인 개발

SDK는 애플리케이션에 통합할 수 있는 사전 빌드된 구성 요소와 라이브러리를 제공하여 개발 효율성을 높입니다. 이러한 구성 요소를 통해 개발자는 이전에 처음부터 코딩 및 디버깅하는 데 소요되던 시간을 크게 절약할 수 있습니다. 

2.더 빠른 배포

SDK는 개발자가 애플리케이션을 빠르게 구축하고 통합할 수 있는 도구를 제공하여 더 빠르게 배포할 수 있도록 합니다. SDK는 여러 플랫폼을 지원하는 경우가 많기 때문에 개발자는 여러 장치 또는 운영 체제에 빠르게 배포할 수 있습니다.

3.통합

SDK는 개발자가 소프트웨어 애플리케이션을 빌드, 테스트 및 배포할 수 있도록 사전 빌드된 모듈, 구성 요소, 패키지 및 도구를 제공합니다. 다른 시스템 및 서비스, 코드 샘플 및 튜토리얼, 디버깅 도구, 코드 라이브러리와의 개발, 테스트 및 통합을 간소화합니다. 

4.비용절감

SDK는 애플리케이션 개발에 필요한 시간과 리소스를 줄여줍니다. SDK는 사전 빌드된 구성 요소와 도구 라이브러리를 제공하여 개발자가 기능을 빠르게 구축할 수 있도록 합니다. SDK는 새 애플리케이션을 만드는 데 필요한 시간과 비용을 줄여줍니다. 또한 애플리케이션 배포 및 유지 관리와 관련된 비용을 줄여 설치 프로세스와 업데이트를 단순화합니다.

SDK와 API의 차이점

API는 애플리케이션이 서로 통신할 수 있도록 하는 일련의 프로그래밍 명령입니다. API는 일반적으로 일련의 요청과 응답을 통해 애플리케이션이 데이터에 액세스하고 데이터를 공유할 수 있는 방법을 제공합니다. 예를 들어 웹 API를 사용하면 사용자가 웹 사이트에서 제품을 검색할 수 있으며 API는 이에 대한 응답으로 관련 정보를 제공합니다. 개발자는 API를 사용하여 애플리케이션을 소셜 미디어 네트워크 또는 결제 프로세서와 같은 타사 서비스와 통합합니다. API는 두 애플리케이션 간의 통신 브리지입니다. 반면 SDK는 타사 도구를 개발자 환경에 제공합니다. 

 

SDK 작동방법

ps.
또한 저희는 웹 개발에서 사용하였지만 모바일 앱,클라우드 컴퓨팅, 사물인터넷 IoT , 게임 개발에서도 사용할 수 있다고합니다.

Amazon API Gateway는 규모와 관계없이 REST 및 WebSocket API를 생성, 게시, 유지, 모니터링 및 보호하기 위한 AWS 서비스입니다.
API 개발자는 AWS 또는 다른 웹 서비스를 비롯해 AWS 클라우드에 저장된 데이터에 액세스하는 API를 생성할 수 있습니다.
API Gateway API 개발자는 자체 클라이언트 애플리케이션에서 사용할 API를 생성할 수 있습니다. 또는 타사 앱 개발자가 API를 사용하도록 제공할 수도 있습니다.

API Gateway는 다음과 같은 RESTful API를 생성합니다.

• HTTP 기반.
• 상태 비저장 클라이언트-서버 통신을 활성화합니다.
• 표준 HTTP 메서드(예: GET, POST, PUT, PATCH, DELETE)를 구현합니다.

API Gateway는 애플리케이션이 Amazon Elastic Compute Cloud(Amazon EC2)에서 실행

중인 워크로드, AWS Lambda에서 실행 중인 코드, 웹 애플리케이션, 실시간 통신 애플리케이션과 같은 백엔드 서비스에서 데이터, 비즈니스 로직 또는 기능에 액세스할 수 있게 해주는 “정문” 역할을 합니다.


따라서 숏폼 프로젝트에서 대량의 동영상 처리 요청(업로드, 변환)을 비동기적으로 관리해야 할수있으며 
S3, RDS, DynamoDB 등 여러 AWS 서비스를 코드로 직접 통합하고있어 호환성에서 더욱 좋고 
현재 동영상 파일 업로드 후 S3 저장 및 Lambda 호출. 하는 방식으로 작동할 수 있습니다. 
또한 클라이언트 요청 관리를 하지는 않기 때문에 API Gateway를 쓰지 않아도 됩니다.

동영상 쇼폼 콘텐츠 프로젝트에서 대량 데이터 처리, 다중 AWS 서비스 통합, 커스텀 로직을 사용할수 있습니다.
만약 클라이언트 요청이 간단하며, Lambda와 S3를 중개하는 HTTP API가 필요하다면 API Gateway를 선택하는 것이 더 효율적이라고 생각됩니다.

참고자료 : 
https://aws.amazon.com/ko/what-is/sdk/
https://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/welcome.html
https://aws.amazon.com/ko/compare/the-difference-between-sdk-and-api/

SDK란 무엇인가요? - SDK 설명 - AWS

 

Amazon API Gateway란 무엇입니까? - Amazon API Gateway

 

https://www.reddit.com/r/aws/comments/1f553gs/should_i_use_aws_sdk_or_api_gateway/?rdt=60812

From the aws community on Reddit

 

SDK와 API 비교 - 개발자 도구 간의 차이점 - AWS

4.SSE(Server-Sent Events) 선택이유 vs Websocket 

 

SSE(Server-Sent Events)

SSE 선택 이유

1. 단방향 실시간 데이터 전송:
   • 클라이언트에서 데이터를 지속적으로 요청하지 않고, 서버가 필요한 시점에만 클라이언트로 데이터를 푸시할 수 있습니다.
   • 동영상 처리 상태 업데이트, 처리 완료 알림 등 단방향 실시간 알림이 주된 요구사항일 때 적합합니다.
2. 간단한 설정:
   • HTTP 기반이므로 설정이 간단하고, 추가적인 프로토콜이나 라이브러리가 필요하지 않습니다.
   • WebSocket처럼 별도의 서버 핸들링 없이, 기존 HTTP 서버를 확장해 SSE를 구현할 수 있습니다.
3. 브라우저 기본 지원:
   • 대부분의 최신 브라우저에서 기본적으로 SSE를 지원합니다.
   • 클라이언트 측 구현이 간단하며, EventSource API로 쉽게 SSE를 사용할 수 있습니다.
4. HTTP/2 지원:
   • HTTP/2를 사용하면 SSE가 다중 스트림을 통해 효율적으로 데이터를 전송할 수 있습니다.
   • WebSocket은 HTTP/2와의 완전한 호환성이 부족한 경우가 있어, HTTP/2 환경에서 SSE가 더 유리할 수 있습니다.
     
     단방향 이벤트 스트림:
     • 서버가 클라이언트에 이벤트(예: 업로드 완료 알림)를 보낼 때 사용.
     • WebSocket처럼 쓸데없는 양방향 연결이 필요하지 않아 자원을 절약.

 

• 양방향 통신:
  • WebSocket은 양방향 통신을 지원하여 클라이언트와 서버가 서로 데이터를 주고받을 수 있습니다.
  • 동영상 쇼폼 콘텐츠 프로젝트에서 사용자와 서버 간 실시간 상호작용(예: 실시간 채팅, 동영상 처리 중 추가 요청)이 필요한 경우 적합합니다.
• 저지연 실시간 데이터 전송:
  • WebSocket은 연결 초기 단계 이후에는 지속적으로 데이터를 전송할 수 있어, 지연 시간이 매우 짧음.
  • SSE는 HTTP 기반이라 데이터 전송 시 헤더가 반복되지만, WebSocket은 연결이 유지되는 동안 데이터 전송 효율이 더 높습니다.
• 대규모 동시 연결 지원:
  • WebSocket은 많은 클라이언트가 동시에 연결되더라도 성능 저하 없이 실시간 데이터를 주고받을 수 있습니다.
  • 동영상 플랫폼에서 많은 사용자가 실시간으로 상태를 업데이트받거나 데이터를 전송해야 할 때 적합.
• 프로토콜 독립성:
  • WebSocket은 TCP 기반 프로토콜을 사용하므로, HTTP뿐만 아니라 다른 네트워크 환경에서도 유연하게 동작합니다.

실시간 채팅, 대규모 실시간 알림, 대규모 다중 연결 등으로 이용할수도 있겠습니다.

 

비교 :

따라서 

동영상 쇼폼 콘텐츠 프로젝트는 알림기능을 SSE를 통해서 구현하려고하는데 이는 동영상 업로드나 처리 상태를 사용자에게 실시간으로 전달하기위해서 입니다.

단방향 실시간 데이터 전송만 하더라도 설정이 간단하고 브라우저 지원도 우수하며
유지 보수 또한 상대적으로 복잡하지않고 HTTP/2 환경에서도 효율적으로 동작하기떄문에 실시간 채팅이나 대규모 실시간 알림등에 적합한Websocket 보다 SSE 를 선택하였습니다. 

 

참고자료 :

https://surviveasdev.tistory.com/entry/%EC%9B%B9%EC%86%8C%EC%BC%93-%EA%B3%BC-SSEServer-Sent-Event-%EC%B0%A8%EC%9D%B4%EC%A0%90-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B3%A0-%EC%82%AC%EC%9A%A9%ED%95%B4%EB%B3%B4%EA%B8%B0
https://www.youtube.com/watch?v=JQoPuXAf92U

웹소켓 과 SSE(Server-Sent-Event) 차이점 알아보고 사용해보기

 

 

 

5. ffmpeg 선택이유 vs HandBrake 

 

FFmpeg 선택 이유

1.1. 다목적 멀티미디어 프레임워크

• FFmpeg는 단순한 변환 도구가 아니라, 인코딩, 디코딩, 변환, 필터링, 스트리밍까지 지원하는 멀티미디어 프레임워크입니다.
  • 동영상 압축, 해상도 조정, 썸네일 생성, 자막 삽입, 포맷 변환 등 다양한 작업이 가능.
• HandBrake와의 차이:
  • HandBrake는 주로 동영상 변환(특히 파일 포맷 변경)에 특화되어 있지만, FFmpeg는 광범위한 작업(예: 오디오 추출, 병합, 스트리밍 설정 등)까지 지원.

1.2. 대량 처리에 최적화

• FFmpeg는 CLI(Command Line Interface) 기반으로 대량 처리 작업을 스크립트로 쉽게 자동화할 수 있습니다.
  • 동영상 여러 개를 일괄 처리하거나, 일정 주기마다 자동으로 변환 작업을 실행 가능.
• HandBrake와의 차이:
  • HandBrake는 GUI 중심으로 설계되어 있어, CLI 지원이 제한적이며, 대량 작업의 효율성이 낮음.

1.3. 포맷 및 코덱 지원

• FFmpeg는 거의 모든 동영상 및 오디오 포맷(MP4, MKV, AVI, MOV 등)과 코덱(H.264, H.265, VP9 등)을 지원합니다.
  • GPU 가속 인코딩(NVIDIA NVENC, AMD VCE 등)을 통해 고성능 변환 작업을 지원.
• HandBrake와의 차이:
  • HandBrake도 주요 포맷과 코덱을 지원하지만, FFmpeg만큼 다양하고 유연한 포맷과 하드웨어 가속 옵션을 제공하지는 않음.

1.4. 고급 커스터마이징

• FFmpeg는 동영상 변환 시 다양한 필터(예: 해상도 조정, 비율 변경, 자막 추가)를 조합하여 복잡한 작업을 처리할 수 있습니다.
  • 동영상 워터마크 삽입, 특정 구간 잘라내기, 프레임 속도 변경 등 세부적인 작업 가능.
• HandBrake와의 차이:
  • HandBrake는 GUI 중심으로 간단한 작업(해상도 변경, 포맷 변환 등)에 적합하지만, 고급 설정은 제한적.

2. HandBrake 선택 이유

2.1. 간단한 사용법

• HandBrake는 GUI 기반으로 설계되어 있어, 기술적인 지식이 적은 사용자도 손쉽게 동영상 변환 작업을 수행할 수 있습니다.
  • 드래그 앤 드롭 방식으로 파일을 추가하고 간단한 설정으로 작업 가능.
• FFmpeg와의 차이:
  • FFmpeg는 CLI 기반으로 설정이 복잡할 수 있지만, HandBrake는 GUI를 통해 접근성을 제공합니다.

2.2. 동영상 포맷 변환에 특화

• HandBrake는 주로 포맷 변환(예: MKV → MP4)과 같은 간단한 작업에 최적화되어 있습니다.
  • 기본 제공되는 사전 설정(Preset)을 사용하면 고품질의 결과물을 빠르게 생성 가능.
• FFmpeg와의 차이:
  • FFmpeg는 설정과 명령어 작성이 필요하지만, HandBrake는 간단한 클릭만으로 작업 완료.

2.3. 오픈소스와 커뮤니티 지원

• HandBrake는 무료 오픈소스 프로젝트로, 초보자도 쉽게 사용할 수 있도록 풍부한 문서와 커뮤니티를 제공합니다.
  • FFmpeg와의 차이:
    • FFmpeg도 오픈소스이지만, 사용자 친화적인 문서와 인터페이스는 HandBrake가 더 우수.

결론은 ffmpeg을 선택했습니다. 물론 HandBrake가 더 간단하고 러닝커브가 적지만
쇼폼 콘텐츠 특성상 다수의 사용자가 업로드한 동영상을 처리해야 하므로 대량 처리 자동화가 필수인데
이는 CLI를 기반으로 다수의 영상을 처리할 수 있는 ffmpeg이 더 적합한 하나의 이유이고 
이에비해 HandBrake는 GUI 기반으로 대량 작업하기는 어렵고 CLI도 지원은 하나 제한적입니다.
또한 프로젝트 고도화와 확장성 부분에서도 썸네일 생성,워터마크 삽입,해상도 변경 등 세밀한 작업에서 다양한 코덱과 포멧을 지원하는 ffmpeg 이 더 적합해 보입니다. 

• FFmpeg는 동영상 쇼폼 콘텐츠 프로젝트에서 대량 처리, 포맷 다양성, 고급 작업 커스터마이징이 요구될 때 가장 적합합니다. 특히 자동화와 GPU 가속 지원은 대규모 작업을 효율적으로 처리하는 데 필수적입니다.
• HandBrake는 간단한 포맷 변환 작업에 적합하며, 기술 지식이 적은 사용자가 수동으로 변환 작업을 수행할 때 유리합니다. 그러나 대규모 플랫폼에서는 자동화와 고급 작업의 제한으로 인해 적합하지 않습니다.

아래는 유사 기술과의 비교 입니다.

 

참고자료:https://www.hitpaw.com/video-converters-tips/ffmpeg-vs-handbrake.html
https://www.videoconverterfactory.com/tips/ffmpeg-vs-handbrake.html

FFmpeg vs. HandBrake: Which One Is Right for You?

 

[FFmpeg vs HandBrake] What’s the Difference and Which One to Choose?