서버가 멈추기 직전, 당신을 구원할 긴급 처방전
혹시 지금 새벽 3시에 서버 디스크 용량 경고 알람을 받고 이 글을 읽고 계신가요? 아니면 배포 파이프라인이 "No space left on device"라는 끔찍한 에러 메시지와 함께 멈춰버려서 식은땀을 흘리고 계신가요? 저도 15년 전 주니어 시절, 똑같은 경험을 했습니다. 잘 돌아가던 이커머스 서버가 블랙프라이데이 행사 도중 갑자기 뻗어버렸는데, 원인을 찾아보니 어처구니없게도 로그 파일 하나가 디스크의 95%를 차지하고 있었습니다. 당시 저는 당황한 나머지 서버를 강제로 재부팅했고, 그로 인해 약 15분간의 서비스 중단과 수천만 원의 매출 손실이 발생했습니다. 그 허탈함과 당혹감은 아직도 생생합니다.
도커(Docker)는 현대 인프라의 핵심이자 정말 훌륭한 도구지만, 기본 설정의 '순진함' 때문에 운영 단계에서 배신을 때리는 경우가 종종 있습니다. 그중 가장 대표적인 것이 바로 '무제한으로 쌓이는 컨테이너 로그'입니다. 도커는 기본적으로 컨테이너의 표준 출력(stdout)과 표준 에러(stderr)를 JSON 파일 형태로 호스트 머신에 저장하는데, 별도의 설정을 하지 않으면 이 파일은 지구가 멸망할 때까지 커집니다. 실제로 제가 컨설팅했던 한 핀테크 스타트업에서는 단 하나의 결제 모듈 컨테이너가 디버그 모드로 설정된 채 배포되어, 2주 만에 150GB의 로그를 뱉어내 서버 전체를 마비시킨 적도 있습니다.
이때 많은 분들이 당황해서 rm 명령어로 로그 파일을 지워버리는 치명적인 실수를 저지릅니다. 하지만 이건 불난 집에 부채질을 하는 격입니다. 파일을 지웠는데 용량은 그대로인 유령 같은 상황을 마주하게 되니까요. 오늘은 서비스를 단 0.1초도 중단하지 않고, 즉시 디스크 공간을 확보하는 마법 같은 명령어 truncate의 활용법과, 다시는 이런 일이 발생하지 않도록 하는 근본적인 해결책(Log Rotation)까지 아주 깊이 있게 다뤄보겠습니다. 커피 한 잔 딱 준비하시고, 천천히 따라오세요. 이 글을 다 읽으실 때쯤이면 여러분은 '로그 관리의 마법사'가 되어 있을 겁니다.
💡 핵심 요약: rm 명령어로 로그 파일을 삭제하면 프로세스가 파일을 계속 잡고 있어 디스크 공간이 확보되지 않고, 도커 데몬을 재시작해야 하는 대참사가 벌어집니다. 반면, truncate는 파일의 껍데기(inode)는 유지한 채 내용물만 비워버리므로 서비스 중단 없이 즉시 용량을 확보할 수 있습니다.
도커 로그의 배신: 왜 디스크가 가득 찰까?
기본 로깅 드라이버의 함정 (JSON-file)
도커를 설치하고 아무런 설정을 건드리지 않았다면, 기본 로깅 드라이버는 json-file로 설정되어 있습니다. 이것이 의미하는 바는 단순하지만 무섭습니다. 컨테이너 내부에서 발생하는 모든 로그가 호스트 머신의 /var/lib/docker/containers/... 경로 아래에 .json-log라는 확장자를 가진 파일로 차곡차곡 쌓인다는 뜻입니다. 개발 환경에서는 로그를 쉽게 확인할 수 있어 편리하지만, 트래픽이 몰리는 운영 환경에서는 시한폭탄과 같습니다.
특히 Node.js나 Java Spring Boot 애플리케이션을 실수로 DEBUG 레벨로 켜두었거나, 무한 루프에 빠져 에러 로그를 초당 수백 개씩 뱉어내는 상황을 상상해 보세요. 텍스트 파일이라 가볍게 생각할 수 있지만, "티끌 모아 태산"이라는 말처럼 1KB짜리 로그가 100만 개 쌓이면 1GB가 되고, 이를 며칠 방치하면 수백 GB가 되는 건 순식간입니다. 제가 겪은 최악의 케이스는 잘못된 DB 커넥션 설정으로 인해 Connection Refused 에러 로그만으로 3일 만에 500GB SSD를 꽉 채워버린 경우였습니다.
이 현상이 무서운 이유는 '보이지 않는 곳'에서 은밀하게 일어나기 때문입니다. 개발자는 애플리케이션 비즈니스 로직에만 집중하느라 인프라 레벨의 로그 파일 용량을 간과하기 쉽습니다. 모니터링 시스템(Prometheus, Grafana 등)이 디스크 사용량 80% 경고를 보낼 때쯤이면 이미 대응하기에 늦은 경우가 많죠. 그래서 우리는 이 파일이 물리적으로 어디에 위치하는지, 그리고 시스템 레벨에서 어떻게 다뤄야 하는지 정확히 알고 있어야 합니다.
rm 명령어가 위험한 이유 (기술적 심층 분석)
"로그 파일이 크네? 그냥 지우면 되지!"라며 습관적으로 rm -rf 명령어를 날리는 순간, 여러분은 더 큰 늪에 빠지게 됩니다. 이를 이해하려면 리눅스 파일 시스템의 작동 원리인 Inode(Index Node)와 File Descriptor를 이해해야 합니다. 리눅스에서 파일을 지운다는 것은 파일의 이름(링크)을 지우는 것이지, 실제 데이터가 담긴 블록을 즉시 삭제하는 것이 아닙니다.
도커 데몬(dockerd)은 컨테이너가 실행되는 동안 로그 파일을 계속 '잡고(Open File Descriptor)' 있습니다. 여러분이 rm 명령어로 파일을 눈앞에서 사라지게 만들어도, 도커 프로세스는 여전히 그 삭제된 파일의 메모리 주소를 잡고 데이터를 계속 쓰고 있습니다. 결과적으로 ls 명령어로 보면 파일은 없는데, df -h로 확인하면 디스크 용량은 여전히 꽉 차 있는 기이한 현상, 이른바 '좀비 파일(Zombie File)' 현상을 목격하게 됩니다.
이 상태를 해결하려면 도커
댓글
댓글 쓰기