취미로 웹 애플리케이션을 개발하고 직접 서버에 배포하는 과정은 생각보다 복잡하고 비효율적입니다. 정적 파일(Static File) 제공, 캐시(Cache) 처리, 사용자 인증, 그리고 검색 기능 구현에 이르기까지, 기존 서버 환경에 맞춰야 하는 제약 때문에 개발자는 많은 어려움에 직면합니다. 간단한 배포를 목표로 시작했지만, 결국 여러 기술적 난관에 부딪히며 효율성을 포기하게 되는 경우가 많습니다.
예를 들어, 정적 파일을 리버스 프록시(Reverse Proxy)에 맡기면 성능은 좋지만, 컨테이너 환경에서는 파일 접근 경로를 설정해야 하는 복잡성이 생깁니다. 반대로 애플리케이션에 내장하면 저사양 하드웨어에서 자원을 불필요하게 소비합니다. 비인증 요청 캐시의 경우, 외부 캐시 솔루션은 기존 서버 구성에 통합하기 어렵고, 애플리케이션 내장 캐시는 세밀한 제어가 어렵거나 중복 캐싱으로 메모리 낭비를 초래합니다. 또한, 인증된 응답 캐시나 서버 사이드 렌더링(SSR) 프런트엔드(Frontend) 분리, 그리고 PostgreSQL만으로는 한계가 있는 일본어 검색 기능 구현 등은 모두 배포 과정을 더욱 복잡하게 만듭니다. 이러한 문제들은 결국 개발자가 모든 구성 요소를 하나의 도커(Docker) 컨테이너에 묶는 방식으로 해결하게 만듭니다.
이러한 단일 컨테이너 배포 방식은 초기 설치와 배포를 단순화하는 장점이 있지만, 근본적인 비효율성을 내포합니다. 사용자의 HTTP 요청이 기존 리버스 프록시, 컨테이너 내부의 리버스 프록시, 캐시, 그리고 백엔드(Backend) 또는 프런트엔드를 여러 HTTP 계층을 반복적으로 통과하게 됩니다. 이는 요청 처리 시간을 늘리고 불필요한 자원 소모를 유발합니다. 전문적인 규모에서는 각 구성 요소를 독립적으로 관리하고 최적화하지만, 취미 개발 환경에서는 배포의 단순성이라는 목표 때문에 이러한 비효율성을 감수하게 되는 것입니다. 결국, 취미 개발자들은 배포의 편의성과 시스템 효율성 사이에서 균형을 찾아야 하는 딜레마에 빠지게 됩니다.