시스템 설계 면접 질문

CDN은 지리적으로 분산된 엣지 서버 네트워크를 통해 콘텐츠를 사용자에게 더 빠르게 전달하는 기술입니다.

CDN은 다음과 같은 방식으로 성능을 향상시킵니다.

첫째, 지리적 분산을 통해 사용자와 가장 가까운 엣지 서버에서 콘텐츠를 제공합니다. 이렇게 하면 물리적인 거리가 줄어들어 응답 시간이 단축됩니다.

둘째, 엣지 서버는 콘텐츠를 캐싱하여 Origin 서버의 부하를 줄입니다. 동일한 콘텐츠 요청이 반복될 때마다 Origin 서버에 접근할 필요 없이 캐시된 콘텐츠를 바로 제공할 수 있습니다.

셋째, 대역폭 사용을 효율화합니다. 엣지 서버가 콘텐츠를 분산 처리하므로 Origin 서버의 대역폭 부담이 줄어들고, 사용자에게도 더 안정적인 속도를 제공합니다.

또한, HTTP/3와 같은 최신 프로토콜을 지원하여 더욱 빠른 전송 속도를 제공하기도 합니다. TTL(Time To Live) 설정을 통해 캐시된 콘텐츠의 유효 기간을 관리하여 최신성을 유지하면서도 효율성을 높입니다.

시스템 설계 면접에서 요구사항 분석은 설계의 첫 단추이자 가장 중요한 단계입니다. 본격적인 설계에 앞서 요구사항을 명확히 하는 이유는 크게 두 가지입니다.

첫째, 설계의 범위를 명확히 하기 위해서입니다. 어떤 기능을 구현해야 하는지, 즉 기능 요구사항을 정확히 파악해야 합니다. 또한, 시스템이 얼마나 빠르고 안정적이어야 하는지, 즉 비기능 요구사항(성능, 확장성, 가용성 등)을 정의해야 합니다. 이러한 요구사항 분석을 통해 불필요한 설계를 방지하고, 제한된 시간 안에 핵심적인 부분에 집중할 수 있습니다.

둘째, 성공적인 설계를 위한 기반을 마련하기 위해서입니다. 요구사항은 곧 시스템이 해결해야 할 문제이자 달성해야 할 목표입니다. 명확한 요구사항 분석 없이는 어떤 아키텍처를 선택해야 할지, 어떤 기술 스택을 사용해야 할지, 어떤 제약 조건 하에서 설계해야 할지 판단하기 어렵습니다. 이는 결국 잘못된 설계로 이어져 재작업이나 실패의 원인이 될 수 있습니다. 따라서 요구사항 분석은 설계의 방향을 설정하고, 효율적이고 효과적인 시스템을 구축하기 위한 필수 과정입니다.

기능 요구사항과 비기능 요구사항의 차이는 시스템이 '무엇을 하는가'와 '얼마나 잘 하는가'로 구분할 수 있습니다.

기능 요구사항은 시스템이 수행해야 하는 구체적인 동작이나 기능을 정의합니다. 예를 들어, '사용자는 로그인할 수 있어야 한다' 또는 '상품을 장바구니에 담을 수 있어야 한다'와 같이 시스템의 핵심적인 '기능'에 해당합니다.

반면에 비기능 요구사항은 시스템이 특정 기능을 수행할 때의 '품질'이나 '성능'에 대한 제약 조건을 나타냅니다. 예를 들어, '로그인 응답 시간은 1초 이내여야 한다' (성능), '시스템은 99.9%의 가용성을 보장해야 한다' (가용성), '사용자 데이터는 암호화되어야 한다' (보안), '인터페이스는 직관적이어야 한다' (사용성) 등이 이에 해당합니다.

간단히 말해, 기능 요구사항은 '무엇'을 할 것인지, 비기능 요구사항은 '어떻게' 잘 할 것인지를 설명한다고 생각하시면 됩니다.

규모 추정이란 시스템이 처리해야 할 예상 트래픽, 저장량, 대역폭 등을 미리 가늠하여 필요한 컴퓨팅 리소스, 스토리지, 네트워크 등을 산정하는 과정입니다.

설계 단계에서 규모 추정이 필수적인 이유는 다음과 같습니다.

첫째, 성능 보장입니다. 예상 트래픽을 고려하여 적절한 처리량과 지연 시간을 만족하는 시스템을 설계할 수 있습니다. 너무 적은 리소스는 성능 저하를 야기하고, 너무 많은 리소스는 낭비로 이어집니다.

둘째, 확장성 확보입니다. 미래의 트래픽 증가를 예측하고 이에 맞춰 시스템을 확장할 수 있도록 설계의 기반을 마련합니다.

셋째, 비용 효율성입니다. 필요한 만큼의 리소스를 정확히 산정하여 불필요한 지출을 줄이고 최적의 비용으로 시스템을 구축할 수 있습니다.

결론적으로, 규모 추정은 안정적이고 효율적인 시스템 설계를 위한 핵심적인 첫걸음입니다.

QPS는 초당 처리할 수 있는 요청 수를 의미합니다. 시스템의 처리 능력을 나타내는 지표죠.

평균 QPS와 피크 QPS를 나누어 추정하는 이유는 시스템의 안정적인 운영과 확장성을 고려하기 위해서입니다. 평균 QPS만으로 용량을 산정하면, 갑작스러운 트래픽 증가 시 시스템이 과부하되어 장애가 발생할 수 있습니다. 피크 QPS는 시스템이 최대로 부하를 받을 때의 요청 수를 의미하며, 이 기준에 맞춰 용량을 확보해야 사용자 경험 저하 없이 안정적으로 서비스를 제공할 수 있습니다. 즉, 최악의 상황을 대비하여 시스템의 탄력성과 확장성을 확보하는 것이 중요하기 때문입니다.

DAU 수치로부터 초당 요청 수나 저장 용량 같은 추정치를 도출하는 것은 시스템 설계의 핵심입니다.

먼저, DAU에 사용자당 평균 요청 수를 곱하여 초당 총 요청 수를 추정합니다. 이때, 사용자들이 특정 시간대에 몰리는 트래픽 패턴을 고려하여 피크 타임의 요청 수를 계산하는 것이 중요합니다. 예를 들어, DAU가 100만이고 사용자당 평균 5개의 요청을 한다면, 하루 총 요청 수는 500만입니다. 이를 초당 평균 요청 수로 환산하면 약 58건이 되지만, 피크 타임에는 이보다 훨씬 높을 수 있습니다.

저장 용량은 DAU에 사용자당 평균 데이터 생성량과 보존 기간을 곱하여 추정합니다. 예를 들어, 사용자당 하루 1MB의 데이터를 생성하고 1년간 보존한다면, 100만 DAU의 경우 연간 약 365TB의 저장 공간이 필요하게 됩니다.

이러한 추정치는 데이터베이스 부하, 캐싱 전략 수립, 그리고 시스템의 전반적인 확장성을 고려하는 데 필수적입니다.

로드 밸런서는 일반적으로 클라이언트와 서버군 사이에 위치하는 시스템의 진입점 역할을 합니다. 즉, 클라이언트의 요청이 직접 서버로 향하는 것이 아니라, 먼저 로드 밸런서를 거치게 됩니다.

이 위치에서 로드 밸런서의 주요 역할은 다음과 같습니다.

첫째, 트래픽 분산입니다. 들어오는 클라이언트 요청을 여러 대의 서버로 나누어 보내어 특정 서버에 부하가 집중되는 것을 방지합니다.

둘째, 고가용성 확보입니다. 만약 특정 서버에 장애가 발생하더라도, 로드 밸런서는 해당 서버로 더 이상 요청을 보내지 않고 정상적인 다른 서버로 트래픽을 우회시켜 서비스 중단을 최소화합니다.

셋째, 확장성 지원입니다. 서버를 추가하거나 제거할 때, 로드 밸런서는 이러한 변경 사항을 인지하고 새로운 서버 풀에 맞게 트래픽을 재분배하여 시스템의 확장성을 유연하게 지원합니다.

결론적으로 로드 밸런서는 단일 실패 지점을 제거하고 시스템의 안정성과 성능을 높이는 데 필수적인 구성 요소입니다.

로드 밸런서는 트래픽을 여러 서버에 분산시켜 서버의 가용성과 확장성을 높이는 역할을 합니다. 마치 교통 정리하는 경찰관처럼, 요청을 효율적으로 나눠주는 거죠.

주요 알고리즘으로는 먼저 라운드 로빈 방식이 있습니다. 서버들을 순서대로 돌아가면서 요청을 배분하는 가장 단순한 방식입니다. Least Connections 방식은 현재 연결 수가 가장 적은 서버에 요청을 보내 서버 부하를 균등하게 유지합니다. IP Hash 방식은 클라이언트 IP 주소를 해싱하여 특정 서버에 고정적으로 요청을 보내는 방식이고, 가중치 기반 방식은 서버 성능에 따라 가중치를 부여하여 요청을 분산합니다.

L4 로드 밸런서는 IP 주소와 포트 번호를 기반으로 트래픽을 분산하고, L7 로드 밸런서는 HTTP 헤더, URL 등 애플리케이션 레벨의 정보를 활용하여 더 정교한 트래픽 분산이 가능합니다.

캐싱 전략은 크게 읽기 전략과 쓰기 전략으로 나눌 수 있습니다. 읽기 전략으로는 Cache Aside와 Read Through가 있습니다. Cache Aside는 애플리케이션이 직접 캐시를 확인하고, 없으면 데이터베이스에서 가져와 캐시에 저장하는 방식입니다. Read Through는 캐시가 데이터베이스와 연동되어, 애플리케이션은 캐시에만 접근하는 방식입니다.

쓰기 전략으로는 Write Through와 Write Back이 있습니다. Write Through는 데이터를 캐시와 데이터베이스에 동시에 쓰는 방식이고, Write Back은 캐시에만 쓰고 나중에 데이터베이스에 비동기적으로 쓰는 방식입니다. Write Back은 성능이 좋지만 데이터 손실 위험이 있습니다.

캐시 교체 알고리즘으로는 LRU (Least Recently Used), LFU (Least Frequently Used) 등이 있습니다. LRU는 가장 오랫동안 사용되지 않은 데이터를, LFU는 가장 적게 사용된 데이터를 삭제합니다.

Cache Invalidation은 데이터베이스의 데이터가 변경되었을 때 캐시의 데이터를 최신 상태로 유지하는 문제입니다. TTL (Time To Live) 설정, 이벤트 기반 무효화 등의 방법이 있습니다.

데이터베이스 샤딩은 대규모 데이터베이스의 성능과 확장성을 향상시키기 위한 기술입니다. 쉽게 말해, 하나의 큰 데이터베이스를 여러 개의 작은 데이터베이스(샤드)로 수평 분할하여 데이터를 분산 저장하는 방식입니다.

샤딩은 주로 데이터베이스가 너무 커져서 쿼리 성능이 저하되거나, 단일 데이터베이스 서버의 용량을 초과하는 경우에 사용됩니다. 데이터를 여러 샤드에 분산함으로써 각 샤드의 데이터 양을 줄이고, 쿼리 처리량을 늘려 전체적인 성능을 향상시킬 수 있습니다. 또한, 특정 샤드에 장애가 발생하더라도 전체 시스템에 미치는 영향을 최소화하여 가용성을 높일 수 있습니다.

샤딩 키를 잘못 선택하면 특정 샤드에 데이터가 몰리는 Hotspot 문제가 발생할 수 있고, 샤드 수를 변경하는 재샤딩 작업은 비용이 많이 들 수 있다는 단점도 있습니다.

CAP 이론은 분산 시스템 설계 시 일관성(Consistency), 가용성(Availability), 분할 내성(Partition Tolerance) 이 세 가지 속성을 모두 만족할 수 없다는 이론입니다. 즉, 셋 중 두 가지만 선택해야 합니다.

일관성은 모든 노드가 같은 시간에 동일한 데이터를 보는 것을 의미하고, 가용성은 모든 요청에 대해 응답을 받을 수 있음을 의미합니다. 분할 내성은 네트워크 파티션이 발생하더라도 시스템이 계속 작동해야 함을 의미합니다.

실제 시스템에서는 분할 내성이 필수적이므로, 보통 일관성과 가용성 사이에서 트레이드 오프를 합니다. 예를 들어, 은행 계좌 시스템은 CP(일관성, 분할 내성) 시스템으로 설계하여 데이터의 정확성을 중요시합니다. 반면, 소셜 미디어 서비스는 AP(가용성, 분할 내성) 시스템으로 설계하여 사용자 경험을 우선시합니다. 상황에 따라 적절한 속성을 선택하는 것이 중요합니다.

마이크로서비스 아키텍처와 모놀리식 아키텍처는 각각 장단점이 뚜렷합니다.

모놀리식 아키텍처는 개발 초기 단계에 간단하게 구축하고 배포하기 용이합니다. 모든 코드가 하나의 저장소에 있고, 단일 프로세스로 실행되므로 개발 및 테스트가 비교적 간단합니다. 하지만 애플리케이션 규모가 커질수록 빌드 및 배포 시간이 길어지고, 특정 부분의 장애가 전체 시스템에 영향을 줄 수 있다는 단점이 있습니다. 또한, 기술 스택을 변경하기 어렵고, 특정 기능 확장을 위해 전체 시스템을 확장해야 하는 비효율성이 발생할 수 있습니다.

반면, 마이크로서비스 아키텍처는 각 서비스를 독립적으로 개발, 배포, 확장할 수 있어 유연성이 높습니다. 특정 서비스에 장애가 발생해도 다른 서비스에는 영향을 주지 않아 안정성이 높습니다. 또한, 각 서비스에 적합한 기술 스택을 선택할 수 있어 기술 다양성을 확보할 수 있습니다. 하지만 서비스 간 통신이 복잡해지고, 분산 시스템의 복잡성을 관리해야 하며, 데이터 일관성을 유지하기 어렵다는 단점이 있습니다. 초기 구축 비용이 높고, 서비스 간 통신 및 관리를 위한 인프라 구축이 필요합니다. 팀 규모가 커지고 서비스가 많아질수록 운영 복잡성이 증가합니다. 따라서 프로젝트의 규모, 복잡성, 팀 규모 등을 고려하여 적절한 아키텍처를 선택해야 합니다.

메시지 큐는 시스템 간의 비동기 통신을 가능하게 해줍니다. 예를 들어, 주문 시스템에서 주문을 받으면, 바로 결제 시스템을 호출하는 대신 메시지 큐에 주문 정보를 넣고, 결제 시스템은 큐에서 메시지를 꺼내 처리하는 방식입니다. 이렇게 하면 주문 시스템은 결제 시스템의 상태에 영향을 받지 않고 빠르게 응답할 수 있습니다.

메시지 큐를 사용하는 주된 이유는 시스템 디커플링과 확장성 확보입니다. 각 시스템이 독립적으로 동작하므로 유지보수가 용이하고, 트래픽 증가에 따라 메시지 큐를 중심으로 시스템을 확장하기 쉬워집니다.

Kafka와 RabbitMQ는 대표적인 메시지 큐 시스템입니다. Kafka는 로그 기반의 스트리밍 플랫폼으로, 대량의 데이터를 실시간으로 처리하는 데 강점을 가집니다. 반면 RabbitMQ는 AMQP 프로토콜을 기반으로 하는 큐 기반 메시징 시스템으로, 복잡한 라우팅과 메시지 전달 규칙을 설정하는 데 유리합니다. Kafka는 데이터 유실 방지에 초점을 맞추고, RabbitMQ는 메시지 전달의 신뢰성에 더 집중한다고 볼 수 있습니다.

API 게이트웨이는 클라이언트 요청을 받아 적절한 백엔드 서비스로 라우팅하는 역할을 합니다. 마치 건물의 현관문과 같다고 생각하시면 됩니다.

주요 장점으로는 첫째, 단일 진입점을 제공하여 클라이언트가 여러 백엔드 서비스의 위치를 알 필요 없이 API 게이트웨이만 호출하면 됩니다. 둘째, 인증, 인가, Rate Limiting, 로깅과 같은 공통 기능을 중앙 집중적으로 처리하여 각 백엔드 서비스의 부담을 줄여줍니다. 셋째, 여러 API를 조합하여 클라이언트에게 필요한 형태로 제공할 수 있습니다.

반면 단점으로는 API 게이트웨이가 Single Point of Failure(SPOF)가 될 수 있다는 점입니다. 또한, 트래픽이 집중되어 성능 병목이 발생할 수도 있습니다. 따라서 API 게이트웨이를 설계할 때는 고가용성과 확장성을 고려해야 합니다.

URL 단축 서비스 설계에 대해 말씀드리겠습니다.

먼저, 긴 URL을 받으면 해시 함수를 통해 짧은 고유 ID를 생성합니다. 이 ID는 Base62 인코딩을 사용하여 더 짧게 만들 수 있습니다. 해시 충돌이 발생하면, 충돌 해결 전략(예: 체이닝, 오픈 어드레싱)을 사용하여 새로운 ID를 생성하거나, 기존 ID에 추가 정보를 덧붙여 고유성을 확보합니다.

데이터베이스에는 짧은 ID와 원래 URL을 매핑하여 저장합니다. 읽기 중심 트래픽을 고려하여 캐싱 전략(예: Redis, Memcached)을 적용하여 데이터베이스 부하를 줄입니다.

만료 정책을 설정하여 오래된 URL은 자동으로 삭제되도록 관리하고, 대용량 처리를 위해 로드 밸런싱을 사용하여 트래픽을 분산합니다. 필요에 따라 데이터베이스 샤딩도 고려할 수 있습니다.

실시간 채팅 시스템 설계에 대해 말씀드리겠습니다.

가장 중요한 건 클라이언트와 서버 간의 실시간 양방향 통신입니다. WebSocket을 사용하는 것이 가장 효율적입니다. Long Polling에 비해 오버헤드가 적고 실시간성이 뛰어나기 때문입니다.

메시지 순서 보장을 위해 각 메시지에 고유한 시퀀스 번호를 부여하고, 서버에서 이 번호 순서대로 처리합니다. 읽음 처리는 각 메시지에 대한 ACK를 사용하여 구현할 수 있습니다.

오프라인 메시지는 Redis와 같은 캐시 서버나 메시지 큐(예: Kafka)에 저장해두었다가, 사용자가 다시 온라인 상태가 되었을 때 전달합니다.

확장성을 위해 Pub/Sub 모델을 사용하고, 메시지 브로커(예: Redis Pub/Sub)를 통해 메시지를 분산 처리합니다. 채팅 서버는 stateless하게 설계하여 필요에 따라 쉽게 확장할 수 있도록 합니다. 로드 밸런서를 통해 트래픽을 분산하는 것도 중요합니다.

네, 뉴스피드 시스템 설계에 대해 말씀드리겠습니다.

가장 먼저 고려할 점은 '팬아웃(Fan-out)' 방식입니다. 크게 '쓰기 시 팬아웃(Fan-out on Write)'과 '읽기 시 팬아웃(Fan-out on Read)' 두 가지 전략이 있습니다.

쓰기 시 팬아웃은 게시물을 작성할 때 팔로워들의 뉴스피드에 미리 넣어두는 방식입니다. 읽기 성능은 빠르지만, 팔로워가 많은 사용자의 경우 쓰기 성능에 부담이 될 수 있습니다.

읽기 시 팬아웃은 뉴스피드를 요청할 때 팔로잉하는 사람들의 게시물을 가져와 조합하는 방식입니다. 쓰기 성능은 좋지만, 읽기 성능이 느려질 수 있습니다.

팔로워 수에 따라 전략을 분기하는 것이 좋습니다. 팔로워가 적은 사용자는 쓰기 시 팬아웃, 많은 사용자는 읽기 시 팬아웃 방식을 적용할 수 있습니다.

캐싱 계층을 활용하여 뉴스피드 응답 속도를 높일 수 있습니다. 자주 접근하는 뉴스피드를 캐싱하여 데이터베이스 부하를 줄일 수 있습니다.

랭킹 알고리즘을 통해 사용자에게 가장 관련성 높은 게시물을 먼저 보여주는 것도 중요합니다. 시간, 좋아요 수, 댓글 수 등을 고려하여 게시물 순서를 결정할 수 있습니다.

데이터베이스 샤딩을 통해 데이터 저장 및 처리 성능을 향상시킬 수 있습니다.

CQRS 패턴을 적용하여 읽기/쓰기 모델을 분리하면 시스템 확장성과 유지보수성을 높일 수 있습니다.

분산 트랜잭션은 여러 서비스에 걸쳐 하나의 논리적인 트랜잭션을 처리해야 할 때 발생합니다. 2PC(Two-Phase Commit)는 간단하지만, 성능 저하나 데드락 문제 때문에 실제 운영 환경에서 사용하기 어렵습니다.

그래서 Saga 패턴을 많이 사용합니다. Saga는 여러 로컬 트랜잭션을 연결하여 전체 트랜잭션을 완성하는 방식입니다. Choreography 방식은 각 서비스가 메시지 이벤트를 통해 서로 통신하며 상태를 변경하는 방식이고, Orchestration 방식은 오케스트레이터라는 중앙 집중식 서비스가 각 서비스의 트랜잭션을 관리합니다.

Outbox 패턴은 트랜잭션과 메시지 발행을 원자적으로 처리하는 데 유용합니다. 서비스가 데이터베이스에 데이터를 저장할 때, 함께 메시지 큐에 발행할 메시지를 Outbox 테이블에 저장합니다. 이후 별도의 프로세스가 Outbox 테이블의 메시지를 읽어 메시지 큐에 발행합니다.

Saga 패턴을 사용할 때는 멱등성을 고려해야 합니다. 메시지 중복으로 인해 같은 로직이 여러 번 실행될 수 있기 때문입니다. 각 서비스는 멱등성을 보장하도록 설계되어야 합니다. TCC(Try-Confirm-Cancel) 패턴도 분산 트랜잭션을 위한 방법 중 하나입니다.

서킷 브레이커 패턴은 분산 시스템에서 장애가 연쇄적으로 확산되는 것을 방지하여 안정성을 높이는 디자인 패턴입니다. 마치 전기 회로의 차단기처럼, 특정 서비스에 장애가 발생하면 일정 횟수 이상 요청 실패 시 해당 서비스로의 호출을 즉시 차단합니다.

주요 상태는 세 가지입니다.

• Closed: 정상 상태로, 요청이 서비스로 전달됩니다.
• Open: 서비스 장애가 감지되어 요청이 즉시 실패 처리됩니다. 일정 시간이 지나면 Half-Open 상태로 전환됩니다.
• Half-Open: 차단된 서비스의 복구 가능성을 확인하기 위해 제한적인 요청을 허용합니다. 성공하면 Closed로, 실패하면 다시 Open으로 전환됩니다.

이 패턴은 장애 격리를 통해 전체 시스템의 안정성을 유지하고, 복구 시간을 단축하는 데 유용합니다. Hystrix나 Resilience4j 같은 라이브러리에서 이 패턴을 구현하여 마이크로서비스 환경에서 널리 사용됩니다.

자동완성 시스템 설계에 대해 말씀드리겠습니다.

가장 중요한 건 빠른 응답 속도와 관련성 높은 검색어 추천입니다. Trie 자료구조를 사용해서 prefix 기반 검색을 효율적으로 처리할 수 있습니다. 각 노드는 다음 문자를 가리키는 포인터를 가지고, 단어의 끝을 표시하는 플래그를 가집니다.

인기 검색어는 Redis Sorted Set에 저장하여 검색어 빈도수를 기준으로 정렬합니다. 사용자 입력 시 Trie에서 prefix 검색 후, Redis에서 인기 검색어를 가져와 합쳐서 결과를 보여줍니다. 캐싱 전략을 통해 latency를 줄일 수 있습니다.

다국어 처리를 위해 유니코드 기반 Trie를 사용하고, 언어별로 다른 가중치를 적용하여 검색어 순위를 조정할 수 있습니다. 예를 들어, 한국어 검색에서는 띄어쓰기 보정을 고려할 수 있습니다.

대용량 파일 업로드 시스템은 여러 핵심 요소로 구성됩니다. 먼저, 클라이언트에서는 파일을 작은 '청크'로 분할하여 업로드합니다. 이는 네트워크 불안정 시에도 전체 파일을 다시 보낼 필요 없이 실패한 청크만 재전송할 수 있게 하여 '재개 가능한 업로드'를 지원합니다.

서버에서는 각 청크를 임시로 저장하고, 업로드 완료 후 이를 합칩니다. 이때, 데이터 무결성을 위해 '체크섬'을 활용하여 파일이 손상되지 않았는지 검증합니다.

업로드 요청 시, 서버는 클라이언트에게 'Presigned URL'을 발급하여 직접 객체 스토리지(예: S3)에 파일을 업로드하도록 합니다. 이는 서버 부하를 줄이고 보안을 강화하는 방법입니다.

대규모 트래픽 처리를 위해 '로드 밸런싱'을 통해 여러 서버로 요청을 분산시키고, 업로드된 파일은 'CDN'을 통해 사용자에게 빠르게 전달될 수 있도록 합니다.

마지막으로, 업로드된 파일은 필요에 따라 '인코딩 파이프라인'을 거쳐 다양한 형식으로 변환됩니다.