네이버 클라우드 1GB 마이크로 서버 최적화: Nginx 정적 파일 분리로 Spring Boot 병목 해결

안녕하세요. 달팁(DalTip) 입니다.

1인 창업으로 웹 서비스를 준비하거나, 홀로 모든 시스템을 구축해 나가는 개발자라면 서비스 기획만큼이나 뼈저리게 다가오는 고민이 하나 있으실 겁니다.
바로 매달 고정적으로 지출되는 '서버 인프라 비용' 문제입니다.

▲ 언제나 고민되는 인프라 비용

저 역시 달팁을 처음 구성할 때 어떻게 서버를 구축할지 참 많이 고민했습니다.

물론 아주 오래전 넷북으로 웹서버와 FTP 서버를 개인적으로 구축해본 경험은 있었지만, 달팁은 실제 외부 사용자들을 대상으로 서비스해야 했기 때문에 특히 보안 관점에서 상용 클라우드 서버를 이용하는 것이 더 적합하다고 판단했습니다.

그렇게 가성비 좋은 클라우드 아키텍처를 알아보던 중, 네이버 클라우드(NCP)의 '마이크로 서버'와 '10만 크레딧 이벤트'를 확인하게 되었습니다.
"초기 트래픽이 적은 구간 동안 비용 부담을 최소화하면서 서비스를 올릴 수 있겠다"는 판단에 달팁은 이곳에 첫 둥지를 틀게 되었습니다.

▲ 100,000 할인 크레딧

▲ 1년간 무료 마이크로 서버

하지만 이 매력적인 선택의 이면에는 '1GB RAM'이라는 가혹한 하드웨어의 한계가 기다리고 있었습니다.
달팁은 JDK 21, Spring Boot 4.x.x 기반의 최신 프레임워크로 개발되어 있습니다. 한정된 물리 자원 속에서 WAS(Tomcat)와 DB(MySQL)를 단일 인스턴스에 함께 구성하다 보니, 늘 메모리 부족이라는 시한폭탄을 안고 있는 상황이었습니다.

🚨 한계점 노출: 서버 프리징(Freezing) 발생

그러던 며칠 전, 1GB 메모리의 구조적 취약점이 적나라하게 드러나는 이벤트가 발생했습니다. 에디터에 6장의 이미지(약 1.5MB)를 첨부하고 게시글 저장 버튼을 누르는 순간, 로딩이 하염없이 돌면서 서버에 심각한 프리징(Freezing) 현상이 발생한 것입니다.

▲ 1. 사건 당시 서버 모니터링 로그 화면

최소한의 서비스 안정성마저 위협받는 상황이라 급히 원인 분석에 들어갔습니다. 로그와 지표를 교차 검증한 결과, 병목의 근본적인 원인은 Tomcat과 MySQL 간의 치열한 메모리 쟁탈전과 이로 인한 스왑(Swap) 발생이었습니다.

🛠️ 생존을 위한 아키텍처 튜닝: WEB / WAS 분리

요즘처럼 하드웨어 자원이 풍부한 시대에, '고작 1.5MB 파일 처리에 서버가 뻗었다'고 하면 헛웃음이 나올 수도 있습니다. 하지만 중요한건 1.5MB 파일 크기 자체가 문제가 아니었다는 점입니다.

진짜 범인은 물리적 RAM(1GB)이라는 극단적인 제약 속에서 DB와 WAS가 한 몸으로 묶인 채 정적 파일 처리를 위해 디스크 I/O까지 톰캣이 모두 감당해야 했던 '구조적 병목'에 있었습니다.
가뜩이나 버퍼 풀이 모자란 MySQL과 힙 메모리가 타이트한 톰캣이 작은 I/O 발생에도 스와핑(Swapping)을 일으키며 시스템 전체가 흔들렸던 것이죠.

물론 사비를 들여 서버 RAM 스펙을 올리는 것이 가장 쉬운 해결책일 겁니다. 하지만 최소 비용으로 최대 효율을 이끌어내야 하는 1인 창업의 숙명 상, 인프라 확장에 앞서 아키텍처 레벨에서 할 수 있는 최선의 부하 분산을 먼저 단행하기로 했습니다.

그 첫 번째 단계로, Nginx를 WEB 서버로 앞단에 세우고 정적 파일(이미지 등) 응답 처리를 완전히 위임하는 정석적인 튜닝을 적용했습니다.

# nginx.conf 예시 설정 코드
server {
    # 정적 파일(이미지)은 WAS(Tomcat)를 거치지 않고 WEB(Nginx)이 직접 처리
    location ^~ /upload/ {
        alias [이미지 저장 경로 ex) /path/to/upload/]; 
         
        sendfile on;      # OS 커널 레벨 파일 직접 전송 (Zero-Copy)
        tcp_nopush on;
        expires 30d;      # 클라이언트 브라우저 캐싱 적용
    }

    # 나머지 API 비즈니스 동적 요청만 WAS(Tomcat)로 전달
    location / {
        proxy_pass http://127.0.0.1:8080; 
    }
}

▲ 인프라가 척박할수록 최적화는 생존의 문제가 됩니다.

물론 Nginx를 도입했다고 해서 1GB RAM이라는 물리적인 한계 자체가 사라지는 것은 아닙니다. 여전히 백그라운드 프로세스나 무거운 쿼리가 돌면 스왑(Swap) 영역을 모니터링하며 타이트한 자원 싸움을 벌여야 하죠.

하지만 적어도 톰캣에서 감당하던 파일처리 리소스를 줄이면서, 미니 서버가 감당해야 할 불필요한 I/O 병목을 걷어내고 최소한의 숨통을 트여준 것에 의의가 있습니다.

▲ 튜닝 이후 I/O 부하가 일정 부분 완화된 모습

1인 개발과 저사양 인프라 운영은 결국 이처럼 끊임없는 타협과 아키텍처 튜닝의 연속입니다.
완벽한 해결책은 아니더라도, 한정된 자원 속에서 극한의 쥐어짜기를 통해 돌파구를 찾아가는 이 경험기가 같은 고민을 안고 계실 개발자분들께 작은 힌트가 되었기를 바랍니다.

* 더 쾌적한 인프라 환경을 마음껏 누릴 수 있도록, 달팁 서비스가 앞으로 쑥쑥 성장했으면 좋겠습니다.

🚀 달팁의 영상과 이미지 리소스는 '쇼츠빌더'를 통해 제작됩니다.

서버 장애로 멈춘 심장을 다시 뛰게 해줄 1인 개발자 생존 필수템

※ 이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

이상, 한정된 자원 속에서도 끊임없이 생존을 모색하는 달팁이었습니다!