blog-ideas/tus 서버 벤치마크.md

# 블로그 포스트 기획안

## 가제

- **.NET 9 vs .NET 9 Native AOT vs Go: tus 파일 업로드 서버 성능 비교**
    
- **대용량 파일 업로드 서버 성능 비교: .NET 9, .NET 9 AOT, Go**
    
- **tus 업로드 서버 벤치마크: 100MB부터 10GB까지, 누가 더 빠를까**
    

---

# 글의 핵심 메시지

이 글은 단순히 “누가 더 빠르다”를 말하는 글이 아니라,

- **대용량 파일 업로드 서버를 구현할 때**
    
- **.NET 9 일반 빌드 / .NET 9 Native AOT / Go 중 어떤 선택이 더 적절한지**
    
- **실제 tus 프로토콜 기반 업로드 시나리오에서 비교**하는 글
    

로 잡는 게 좋다.

즉, 핵심 질문은 이거다.

> “tus 기반 업로드 서버를 만들 때, 처리 성능과 자원 사용량 측면에서 어떤 런타임/구성이 더 유리한가?”

---

# 전체 글 구조

## 1. 서론

### 1-1. 왜 파일 업로드 성능이 중요한가

여기서는 너무 길지 않게 배경만 깔면 된다.

예시 흐름:

- 파일 업로드는 많은 서비스의 핵심 기능이다.
    
- 특히 100MB 이상 대용량 업로드에서는 단순 API 처리와 달리
    
    - 스트리밍 처리
        
    - 디스크 I/O
        
    - 네트워크 처리
        
    - 청크 단위 업로드 재개
        
    - 서버 메모리 사용량  
        같은 요소가 중요해진다.
        
- 이때 일반적인 multipart 업로드보다 **재개 가능한 업로드(resumable upload)** 가 필요한 경우가 많다.
    

### 1-2. tus를 아주 간단히 설명

여기는 정말 짧게.

예시:

- **tus**는 resumable upload를 위한 오픈 프로토콜이다.
    
- 업로드를 중단했다가 이어서 보낼 수 있고,
    
- 대용량 파일이나 불안정한 네트워크 환경에 적합하다.
    
- 클라이언트와 서버가 일정한 규약으로 업로드 상태를 주고받는다.
    

### 1-3. 왜 이 비교를 하려는가

여기서 비교 목적을 분명히 적는다.

예시:

- .NET은 생산성이 좋고, 최근에는 Native AOT로 경량 실행 파일도 만들 수 있다.
    
- Go는 전통적으로 네트워크 서버와 스트리밍 처리에서 강점이 있다고 알려져 있다.
    
- 그렇다면 **실제 tus 업로드 서버 시나리오에서는 어떤 차이가 발생할까?**
    

---

## 2. 비교 대상 소개

이 부분은 꼭 넣는 게 좋다.  
독자가 “정확히 뭘 비교하는지” 알아야 한다.

### 2-1. 비교 대상

- **.NET 9**
    
    - 일반 JIT 기반 서버
        
- **.NET 9 Native AOT**
    
    - Ahead-of-Time 컴파일 기반 서버
        
- **Go**
    
    - Go 기반 tus 서버
        

### 2-2. 왜 이 셋을 비교했는가

- 모두 서버 구현에 많이 쓰이는 언어/런타임
    
- 실행 방식이 서로 다름
    
- 파일 스트리밍, 메모리 사용, cold start, 처리량 측면에서 차이가 날 가능성이 있음
    

여기서 중요한 포인트 하나:

> Native AOT는 “모든 상황에서 무조건 빠른 기술”이라기보다,  
> **시작 속도 / 배포 단순성 / 메모리 특성**에서 장점이 있을 수 있고,  
> 스트리밍 업로드 처리에서는 일반 .NET과 차이가 크지 않을 수도 있다.

이 관점을 미리 깔아두면 글이 더 균형 있어 보인다.

---

## 3. 벤치마크 목표

이 섹션도 추가하는 걸 추천한다.

### 3-1. 확인하고 싶은 것

- 업로드 완료까지 걸리는 시간
    
- 평균 처리량(throughput)
    
- CPU 사용량
    
- 메모리 사용량
    
- 대용량 파일에서의 안정성
    
- 파일 크기 증가에 따른 성능 변화
    
- 파일 포맷 차이에 따른 영향
    

### 3-2. 가설

가볍게 적어도 좋다.

예시:

- Go가 메모리 사용량과 처리량 측면에서 강할 수 있다.
    
- .NET 9와 .NET 9 AOT는 순수 업로드 성능 자체는 큰 차이가 없을 수 있다.
    
- 파일 포맷 차이는 서버가 파일 내용을 해석하지 않는다면 크기 대비 영향이 제한적일 수 있다.
    

---

## 4. 벤치마크 환경

이건 **반드시 넣는 게 좋다.**  
없으면 글 신뢰도가 떨어진다.

### 4-1. 테스트 환경

- CPU
    
- RAM
    
- 디스크 종류 (SSD/NVMe/HDD)
    
- OS
    
- Docker 사용 여부
    
- 네트워크 환경
    
- 로컬 루프백인지, 같은 LAN인지, 원격 서버인지
    

### 4-2. 서버 설정 통일

- 모두 동일한 저장 디렉토리 조건
    
- 동일한 tus 프로토콜 옵션
    
- 동일한 청크 크기
    
- 동일한 동시 업로드 수
    
- 동일한 reverse proxy 유무
    
- TLS 적용 여부
    
- checksum / metadata 처리 여부
    
- 디스크 flush 정책
    

### 4-3. 측정 방식

- 각 테스트를 몇 회 반복했는지
    
- 평균/중앙값/최댓값/최솟값 중 무엇을 볼지
    
- 워밍업 테스트를 했는지
    
- 첫 요청과 반복 요청을 분리했는지
    

이건 진짜 중요하다.  
특히 .NET 일반 빌드는 JIT 영향이 있으니까 **워밍업 여부**를 써줘야 한다.

---

## 5. 벤치마킹 시나리오

여기서 네가 적은 1차/2차를 좀 더 정식 문서처럼 다듬으면 된다.

---

### 5-1. 1차 벤치마크: 파일 크기별 성능 비교

목적:

- 파일 크기가 커질수록 각 서버가 어떤 성능 특성을 보이는지 확인
    

대상 크기:

- **100MB**
    
- **1GB**
    
- **10GB**
    

측정 항목:

- 업로드 완료 시간
    
- 평균 처리량(MB/s)
    
- CPU 사용률
    
- 메모리 사용량
    
- 오류 발생 여부
    
- 업로드 중단/재개 시 동작 여부
    

해석 포인트:

- 작은 파일에서는 런타임 초기화 비용 영향이 클 수 있음
    
- 큰 파일에서는 네트워크/디스크 I/O가 병목이 될 수 있음
    
- 10GB 구간에서는 런타임 차이보다 구현 방식과 스트리밍 효율 차이가 더 중요할 수 있음
    

---

### 5-2. 2차 벤치마크: 파일 포맷별 성능 비교

여기서 한 가지 보강이 필요하다.

**파일 포맷 비교는 “같은 크기 조건”과 함께 가야 의미가 있다.**  
예를 들어 jpg 10MB와 mp4 10MB를 비교해야지, 단순히 서로 다른 크기의 파일을 비교하면 해석이 어렵다.

추천 방식:

#### 비교 파일 예시

- 텍스트 계열: txt, json, csv
    
- 압축 계열: zip
    
- 이미지 계열: jpg, png
    
- 미디어 계열: mp4
    
- 바이너리 계열: iso 또는 랜덤 바이너리
    

#### 주의점

tus 서버가 파일 내용을 분석하지 않고 **그냥 바이트 스트림으로 저장**한다면,  
파일 포맷 자체는 큰 의미가 없을 수도 있다.  
그래서 이 파트는 이렇게 써주는 게 좋다.

> 이 실험은 “파일 확장자 자체의 차이”보다도,  
> **압축 가능성, 데이터 패턴, 메타데이터 처리 여부, 프록시/스토리지 계층의 영향**이 결과에 반영되는지 확인하기 위한 것이다.

추천 질문:

- 서버가 포맷에 따라 다른 오버헤드를 보이는가?
    
- 랜덤 바이너리와 압축 파일의 차이가 있는가?
    
- 실제로는 파일 포맷보다 파일 크기와 I/O가 더 큰 변수인가?
    

---

## 6. 결과 정리 방식

이것도 미리 계획에 넣으면 글 쓰기 편하다.

### 6-1. 표

예시 컬럼:

- 서버 종류
    
- 파일 크기/포맷
    
- 평균 업로드 시간
    
- 평균 처리량
    
- 평균 CPU
    
- 피크 메모리
    
- 실패 횟수
    

### 6-2. 그래프

추천 그래프:

- 파일 크기별 업로드 시간
    
- 파일 크기별 throughput
    
- 서버별 메모리 사용량
    
- 서버별 CPU 사용량
    

### 6-3. 로그/관찰 내용

숫자만 말하지 말고 이런 것도 같이 적으면 좋다.

- 특정 서버는 큰 파일에서 메모리 스파이크가 있었는지
    
- 특정 서버는 재시도 시 더 안정적이었는지
    
- 특정 서버는 작은 파일에서 유독 빠른지
    

---

## 7. 결과 해석

이 섹션은 본론에서 아주 중요하다.  
단순히 표만 던지면 아쉽다.

예시 질문들:

- 왜 어떤 서버가 더 빨랐는가?
    
- 차이가 런타임 때문인가, 구현체 때문인가?
    
- 대용량 업로드에서는 CPU보다 디스크/네트워크 병목이 더 큰가?
    
- Native AOT가 기대만큼 차이를 내는가?
    
- 실제 서비스 선택 기준은 속도만으로 충분한가?
    

여기서 꼭 넣으면 좋은 문장:

> 업로드 서버 성능은 언어 자체보다도  
> **스트리밍 방식, 버퍼 처리, 디스크 기록 전략, 프록시 설정, 파일 시스템 환경**의 영향을 크게 받는다.

이 문장이 있으면 글이 훨씬 성숙해 보인다.

---

## 8. 결론

결론은 “누가 1등”보다 “언제 무엇을 선택할지”로 마무리하는 게 좋다.

예시 방향:

- 최고 처리량이 중요하다면 A가 유리했다
    
- 메모리 사용량과 단순 배포를 원하면 B가 매력적이었다
    
- 기존 .NET 생태계를 쓰고 있다면 일반 .NET 9도 충분히 경쟁력이 있었다
    
- Native AOT는 업로드 처리량 자체보다 배포/시작 속도 측면에서 의미가 컸다
    
- 실제 선택은 성능뿐 아니라 개발 생산성, 유지보수성, 생태계까지 고려해야 한다
    

---

# 지금 초안에서 부족했던 부분

네 초안에 추가하면 좋은 항목만 따로 뽑아보면 이거다.

## 꼭 추가 추천

- **비교 대상 소개**
    
- **벤치마크 목표**
    
- **테스트 환경**
    
- **측정 기준**
    
- **공정성 확보 방법**
    
- **결과 해석**
    
- **한계점**
    

---

# 한계점 섹션도 넣는 걸 추천

이런 글은 한계점을 직접 말해주면 오히려 더 신뢰를 얻는다.

예시:

- 네트워크 환경이 실제 인터넷 환경과 다를 수 있음
    
- 특정 tus 구현체의 완성도 차이가 결과에 반영될 수 있음
    
- reverse proxy, TLS, object storage 연결 시 결과가 달라질 수 있음
    
- 단일 업로드 기준과 동시 업로드 기준은 다를 수 있음
    

---

# 추천 목차 형태

아래 형태로 가면 블로그 글로 바로 쓰기 좋다.

## 목차

1. 왜 파일 업로드 성능을 비교하려고 했나
    
2. tus란 무엇인가
    
3. 왜 .NET 9, .NET 9 AOT, Go를 비교했나
    
4. 벤치마크 환경과 측정 기준
    
5. 1차 벤치마크: 100MB / 1GB / 10GB 비교
    
6. 2차 벤치마크: 파일 포맷별 비교
    
7. 결과 정리
    
8. 결과 해석
    
9. 실제 서비스에서는 무엇을 선택할까
    
10. 마무리
    

---

# 더 다듬은 기획안 문장 버전

네가 바로 문서에 붙일 수 있게 조금 더 자연스럽게 써보면:

## 글 주제

**.NET 9, .NET 9 Native AOT, Go 기반 tus 서버의 파일 업로드 성능을 비교한다.**

## 글의 목적

대용량 파일 업로드 서버를 구현할 때 어떤 런타임과 구성이 더 적합한지 확인하기 위해, tus 프로토콜 기반 서버를 대상으로 벤치마크를 진행한다.

## 서론

파일 업로드는 많은 서비스에서 핵심 기능이지만, 파일 크기가 커질수록 단순한 HTTP 요청 처리 이상의 요소가 중요해진다. 특히 대용량 업로드에서는 네트워크 안정성, 재시도, 스트리밍 처리, 디스크 I/O, 메모리 사용량이 모두 성능에 영향을 준다. 이런 문제를 해결하기 위한 대표적인 방식 중 하나가 resumable upload이며, tus는 이를 위한 오픈 프로토콜이다. 이번 글에서는 tus 기반 업로드 서버를 .NET 9, .NET 9 Native AOT, Go로 각각 구성하고 실제 업로드 성능을 비교해본다.

## 본론

### 1차 벤치마크

- 100MB
    
- 1GB
    
- 10GB
    

파일 크기 증가에 따라 업로드 시간, 처리량, CPU, 메모리 사용량이 어떻게 달라지는지 비교한다.

### 2차 벤치마크

서로 다른 파일 포맷을 대상으로 업로드 성능을 비교한다. 다만 tus 서버는 기본적으로 바이트 스트림을 저장하므로, 파일 포맷 자체보다는 데이터 패턴과 저장 계층의 차이가 결과에 어떤 영향을 주는지 확인하는 데 의미를 둔다.

## 결론

벤치마크 결과를 바탕으로 각 런타임의 장단점을 정리하고, 실제 업로드 서버를 선택할 때 성능 외에 어떤 요소까지 고려해야 하는지 함께 살펴본다.

---

# 개인적으로 추천하는 추가 실험

가능하면 이것도 넣으면 글이 훨씬 강해진다.

- **단일 업로드 vs 동시 업로드**
    
    - 1개 업로드
        
    - 3개 동시 업로드
        
    - 10개 동시 업로드
        

이유는 실제 서비스에서는 단일 파일보다 **동시성**에서 차이가 더 잘 드러나기 때문이다.

또 하나는:

- **중단 후 재개(resume) 테스트**
    
    - 1GB 업로드 중간에 끊고 재개
        
    - 각 서버의 안정성과 재개 정확성 비교
        

이건 tus의 핵심 장점을 직접 보여줄 수 있어서 글이 훨씬 살아난다.