개요
Spring의 복잡도와 WordPress의 무거움에 지친 개발자가 C로 직접 만든 블로그 엔진, Fly.Board를 살펴 봤다. HTTP/3(QUIC) over TLS 1.3 환경에서 실제 10,000개의 클라이언트 연결을 유지하며 측정한 결과가 흥미로워서 정리해 본다.
핵심은 단순함이다. 커스텀 프레임워크(CWIST), 자체 메모리 관리 도구(LibTTAK), 그리고 단일 바이너리로 구성되어 있다.
C10k 벤치마크
sudo -E /usr/bin/time -v ./fly_board로 측정했다.
| 항목 | 값 |
|---|---|
| 동시 연결 수 | 10,000 |
| 지속 시간 | 24분 46초 |
| 최대 RSS | 약 369 MB (368,644 KB) |
| 평균 CPU 점유율 | 약 93% |
| User time | 444.17초 |
| System time | 951.76초 |
| Major page faults | 0 (디스크 I/O 없음) |
| Minor page faults | 219,629 |
| Swaps | 0 |
| File system inputs | 0 |
| File system outputs | 89,208 (안전한 데이터 저장) |
| Voluntary context switches | 346,110,015 |
| Involuntary context switches | 1,690,588 |
| 종료 상태 | 0 (SIGINT 후 정상 종료) |
참고: HTTP/3(QUIC) over TLS 1.3 환경에서 실제 10,000개의 클라이언트 연결을 유지하며 측정한 값이다.
구조적 비교
개인 VPS 하나로 운영하는 블로그 엔진 입장에서 보면 기존 스택과 확연히 다르다.
WordPress: PHP-FPM + MySQL 기반. 페이지 하나 띄우는 데도 수십~수백 MB를 소모하며, C10k는 사실상 불가능하다. 보통 Nginx + Varnish + 다단 캐싱 레이어를 쌓아야 버틴다.
Spring Boot: JVM 힙만 기본 256~512MB, 운영에서는 1GB 이상이 일반적이다. DI 컨테이너, 리플렉션, GC 튜닝까지 “블로그 하나 띄우자”고 하기엔 복잡도가 과하다.
Fly.Board: idle 상태 20-22MB, C10k 상황에서도 369MB. 단일 바이너리에 캐싱 레이어 없이 C10k를 소화한다.
설계 포인트
- LibTTAK: 자체 메모리 관리 도구. 비동기 처리와 유사 GC Wrapper를 제공해서 C의 속도는 챙기면서 메모리 안전성을 어느 정도 확보했다. Major page faults가 0인 것이 그 증거다.
- NukeDB: SIGINT 수신 후에도 89,208개의 FS output으로 데이터를 안전하게 저장했다.
- 프로토콜 스택: HTTP/3(QUIC) + TLS 1.3을 커스텀 C 스택으로 지원. 이건 단순한 PoC 수준이 아니다.
- 연결당 메모리: 369MB / 10,000 = 약 37KB. 이 수치는 Nginx와 비교해도 밀리지 않는다.
아쉬운 점
System time이 User time의 2배 이상(951초 vs 444초)이다. QUIC + TLS 1.3 특성상 커널과 빈번히 교류하는 것은 맞지만, userspace 처리 효율을 더 끌어올릴 여지는 있다.
또한 SQLite 기반의 데이터 계층이 C10k 쓰기 부하를 감당할 수 있을지는 읽기 중심 벤치마크로는 검증되지 않았다. 댓글/게시글 동시 작성이 몰리는 상황은 별도로 봐야 한다.
결론
Fly.Board는 Spring이나 WordPress를 대체할 개발자 블로그 엔진으로 상당한 잠재력을 보인다. C10k를 단일 바이너리로 소화하고, 1GB VPS에서도 여유롭게 운영 가능한 메모리 곡선은 개인 호스팅 입장에서 매력적이다.
프로덕션 쇼핑몰이 아닌, 개발자가 직접 관리하는 블로그 엔진이라는 타겟에서는 기술적 완성도가 이미 높은 편이다. 장기적인 메모리 누수 테스트와 쓰기 부하 벤치마크만 추가로 거치면 충분히 실용적인 대안이 될 수 있을 것 같다.