1. 시작하며회사에서 프로젝트를 진행하면서 프론트엔드 팀원분들이 패치 후에도 브라우저가 이전 버전을 유지하는 문제로 어려움을 겪고 있었습니다.운영 서버에 배포할 때마다 강력 새로고침(Ctrl + Shift + R)을 해야만 최신 화면이 반영되는 상황이었습니다.이는 사용자 경험(UX)에도 영향을 미치고, 운영 과정에서도 번거로움을 유발했습니다.1.1 문제 상황패치 후에도 브라우저가 이전 버전의 화면을 유지함Nginx를 재시작하지 않으면 새로운 화면이 반영되지 않음사용자가 강제 새로고침을 하지 않으면 변경 사항이 보이지 않음배포 후 매번 "새로고침 해주세요!"라고 안내하는 번거로움이 존재운영 서버에 배포할 때마다 개발자나 운영팀이 직접 강력 새로고침을 해줘야 하는 상황이 반복되었고, 이는 근본적으로 Ngin..

1. 시작하며회사에서 진행한 프로젝트에서 Nginx 로그 파일을 관리할 필요가 있었습니다. 특히, 클라이언트 요청 값들을 검토해야 하는 상황이었는데, 로그 파일(access.log, error.log)이 지나치게 커져 있어 파일을 열어보는 것조차 어려운 상태였습니다.문제 상황은 다음과 같았습니다.access.log 파일이 6GB 이상 쌓여 있어 텍스트 에디터로 열 수 없음로그 파일이 커질수록 Nginx의 성능 저하 및 디스크 용량 증가 문제 발생오래된 로그 파일이 자동으로 삭제되지 않아 불필요한 용량 차지이를 해결하기 위해 Nginx 로그 파일을 일자별로 관리하는 방식이 필요했습니다.이번 글에서는 Windows 환경에서 로그 파일을 자동으로 일자별로 관리하고, 불필요한 오래된 로그를 자동으로 삭제하는 방..

1. 시작하며사이드 프로젝트를 운영하면서 백엔드 코드 변경이 빈번하게 발생했습니다. 신규 기능 추가뿐만 아니라 리팩토링 작업과 성능 개선을 포함한 지속적인 코드 품질 향상을 위해 이루어진 작업이었습니다. 하지만 배포 단계에서 서비스 중단이 발생할 가능성이 큰 문제가 되었습니다.서비스 중단은 사용자 경험에 직접적인 영향을 미칠 수 있으며, 특히 실시간으로 사용되는 서비스라면 이는 치명적일 수 있습니다. 서비스 운영 중에도 배포가 이루어지더라도 사용자에게 중단 없는 경험을 제공하는 것이 목표였습니다.이를 위해 무중단 배포 전략을 도입하기로 결정했습니다. 기존에는 간단히 Docker 컨테이너를 종료하고 새 컨테이너를 띄우는 방식으로 배포를 진행했지만, 이 과정에서 서비스가 일시적으로 중단되는 문제가 있었습니다..