1. 서론: 새벽 3시의 재앙, No space left on device 리눅스 서버 인프라를 운영하면서 겪는 가장 당혹스럽고 허탈한 장애 원인 중 1위는 단연 **디스크 용량 100% 고갈(Disk Full)**입니다. 웹 서비스 트래픽이 평소보다 조금만 급증해도 Nginx의 access.log나 Tomcat의 catalina.out 파일은 하루에 수 GB에서 수십 GB씩 눈덩이처럼 불어납니다. 디스크가 100% 차는 순간: 데이터베이스(MySQL, PostgreSQL)는 쓰기 작업을 거부하며 즉각 비정상 종료(Crash)됩니다. WAS는 세션 및 임시 파일을 생성하지 못해 500 에러를 뿜어냅니다. 관리자 터미널(SSH) 접속조차 PTY 할당 실패로 막혀버려 긴급 조치조차 어려워집니다. 이러한 참사를 사전에 방지하기 위한 리눅스 표준 솔루션이 바로 **logrotate**입니다. 이번 포스팅에서는 logrotate의 내부 동작 원리(시그널 방식 vs copytruncate), 파일 핸들의 비밀, 서버 3대장(Nginx, Apache, Tomcat)의 프로덕션 설정 템플릿, 그리고 디버깅 검증 기법까지 완벽히 정리합니다. ...

PuTTY로는 접속이 되는데 WinSCP에서만 SSH 키 인증이 실패하는 문제가 발생했습니다. 원인을 확인해 보니 PuTTY 0.75 이후 도입된 PPK v3 포맷 호환성 문제였으며, WinSCP 업데이트 및 PuTTYgen 다운그레이드 변환으로 완벽히 해결할 수 있었습니다.

1. 서론: 왜 WAS를 외부에 직접 노출하면 안 되는가? 웹 서비스를 처음 배포할 때 흔히 저지르는 실수 중 하나는 Spring Boot(내장 Tomcat)나 Node.js 같은 백엔드 WAS 애플리케이션을 공인 IP의 80/443 포트에 직접 바인딩하여 외부에 노출하는 것입니다. WAS는 복잡한 비즈니스 로직과 데이터베이스 트랜잭션을 처리하는 데 특화된 소프트웨어입니다. 이를 인터넷 최전선에 그대로 노출하면 다음과 같은 심각한 문제가 발생합니다: 느린 클라이언트 공격(Slowloris 등)에 취약: 대역폭이 좁거나 악의적인 클라이언트가 TCP 연결을 질질 끌 경우 WAS의 귀중한 작업 스레드(Worker Thread)가 묶여 전체 서비스가 마비됩니다. SSL 핸드셰이크의 연산 낭비: 무거운 비대칭 암호화 연산을 JVM이 직접 수행하느라 CPU 자원을 낭비합니다. 정적 리소스 서빙 비효율: 이미지, CSS, JS 같은 정적 정적 파일을 WAS를 거쳐 제공하면 불필요한 서블릿 오버헤드가 발생합니다. 무중단 배포 불가: 서버를 재기동할 때마다 클라이언트에게 즉각 연결 실패 에러가 노출됩니다. 이러한 문제를 완벽하게 해결하는 웹 인프라의 표준 관문이 바로 **Nginx 리버스 프록시(Reverse Proxy)와 로드 밸런서(Load Balancer)**입니다. ...

React, Vue, Angular와 같은 SPA(Single Page Application)를 빌드하여 Nginx 웹 서버에 배포한 후 가장 빈번하게 마주치는 문제가 있습니다. 바로 루트(/)에서는 페이지 이동이 잘 되는데, 특정 하위 경로(예: /mypage, /dashboard)에서 새로고침(F5)을 누르거나 주소를 직접 입력하면 404 Not Found 오류가 발생하는 현상입니다. 이 글에서는 이 문제가 발생하는 근본적인 원인과 Nginx의 try_files 지시어를 활용해 완벽하게 해결하는 방법을 정리합니다. 1. 문제 상황 및 증상 웹 애플리케이션을 빌드한 결과물(정적 파일)을 /var/www/html 또는 별도의 디렉토리에 두고 Nginx 기본 설정으로 서빙하는 경우를 예로 들어보겠습니다. ...