약 8분 읽기
정신 놓고 있다가 큰코다쳤던 SSL 갱신 이야기
여러분, 혹시 웹사이트 운영하면서 SSL 인증서 갱신, 제때 챙기고 계신가요? 저는 얼마 전까지만 해도 ‘설마 90일 만에 만료되겠어?’ 하며 안일하게 생각하다가, 제 손으로 직접 사이트를 몇 시간 동안 다운시키는 대형 사고를 쳤습니다. 바로 Let’s Encrypt SSL 인증서 갱신을 깜빡했기 때문이죠. RPA 엔지니어로서 자동화가 생활화된 저인데도 이런 실수를 하다니, 정말이지 스스로에게 실망이 컸습니다. 오늘은 이 삽질 경험을 통해 어떻게 n8n을 활용해 Let’s Encrypt SSL 인증서 갱신을 빈틈없이 자동화했는지, 그 과정을 솔직하게 공유해 드리려고 합니다.
90일 만료, 그 무서운 진실
Let’s Encrypt는 무료로 SSL 인증서를 발급받을 수 있어 많은 분들이 애용하고 계실 겁니다. 저 역시 개인 서버에 운영 중인 블로그와 몇몇 서비스에 Let’s Encrypt를 사용하고 있었는데요. 문제는 이 인증서의 유효기간이 90일이라는 점입니다. 물론 Certbot 같은 도구를 사용하면 갱신이 비교적 간편하지만, 이걸 수동으로 90일마다 챙기는 게 생각보다 쉽지 않더라고요. 바쁘게 개발하고 서버 관리하다 보면 어느새 갱신일을 훌쩍 넘기기 십상입니다. 저도 그랬습니다. 정신없이 업무를 처리하다 보니 어느 날 아침, 갑자기 제 블로그에 접속이 안 되는 황당한 상황을 맞닥뜨렸습니다. 브라우저에 ‘안전하지 않은 연결’이라는 빨간 경고창이 뜨면서 말이죠. 정말이지 식은땀이 줄줄 흘렀습니다.
부랴부랴 서버에 접속해서 Certbot 명령어를 실행해 갱신을 시도했지만, 이미 만료된 인증서 때문에 한동안 정상적인 서비스가 불가능했습니다. 몇 시간 동안 제 블로그를 기다려주신 몇 안 되는 방문자분들께 너무나 죄송한 마음이었죠. 이 사건을 계기로 ‘무조건 자동화해야겠다’는 강력한 의지가 생겼습니다.

수동 갱신의 한계, 그리고 자동화의 필요성
Certbot은 갱신 명령어를 실행하면 대부분 자동으로 처리해주지만, 몇 가지 설정이나 Nginx 같은 웹서버 설정 변경이 필요한 경우가 있습니다. 또한, 갱신 자체도 잊지 않고 주기적으로 실행해야 하는 번거로움이 있습니다. 특히 저처럼 개인 서버를 여러 개 운영하거나, 다양한 서비스를 운영하는 경우라면 이 수동 갱신은 분명 병목 현상을 일으킬 수밖에 없습니다. ‘이런 단순 반복 작업을 왜 내가 직접 하고 있어야 하지?’라는 생각이 머릿속을 떠나지 않았습니다. RPA 엔지니어로서 이런 비효율은 용납할 수 없었죠. 그래서 떠올린 것이 바로 제가 직접 구축해서 사용하고 있는 n8n 워크플로우였습니다.
n8n, 왜 Let’s Encrypt 갱신 자동화에 적합했을까?
제가 n8n을 선택한 이유는 여러 가지가 있습니다. 첫째, 시각적인 워크플로우 구성이 가능하다는 점입니다. 복잡한 스크립트를 작성하는 대신, 노드를 연결하는 방식으로 자동화 로직을 설계할 수 있어 직관적이고 이해하기 쉽습니다. 둘째, 다양한 서비스와의 연동성입니다. SSH, HTTP Request, Cron 등 서버 관리 및 외부 서비스 연동에 필요한 노드를 기본적으로 제공하기 때문에 별도의 라이브러리 설치 없이도 원하는 기능을 구현할 수 있습니다. 셋째, 개인 서버에 직접 설치 및 운영이 가능하다는 점입니다. 클라우드 기반의 자동화 툴도 많지만, 제 민감한 서버 정보를 외부로 전송하는 것이 꺼려졌기 때문에, Docker로 제 서버에 직접 구축한 n8n이 가장 적합했습니다. 무엇보다 무료라는 점도 매력적이었고요.
Let’s Encrypt 인증서 갱신 자동화에 n8n이 딱이라고 생각한 이유는 다음과 같습니다.
- 정확한 스케줄링: Cron 노드를 이용해 90일이 되기 전, 특정일에 자동으로 갱신 작업을 실행하도록 설정할 수 있습니다.
- SSH를 통한 원격 실행: SSH 노드를 사용하여 제 웹서버에 접속, Certbot 명령어를 실행하고 결과를 확인할 수 있습니다.
- Nginx 재시작 자동화: 인증서 갱신 후에는 Nginx 설정을 다시 로드하거나 재시작해야 웹서버가 새로운 인증서를 인식합니다. 이 과정 역시 SSH 노드를 통해 자동화할 수 있습니다.
- 오류 처리 및 알림: 만약 갱신 과정에서 문제가 발생하면, 이메일이나 슬랙 등으로 즉시 알림을 받아 상황을 파악하고 빠르게 대처할 수 있습니다.
n8n 워크플로우, 어떻게 만들었을까?
제가 구축한 n8n 워크플로우는 크게 다음과 같은 단계로 구성됩니다.
- Cron 노드: 80일차 되는 날, 오전 3시에 워크플로우가 실행되도록 설정했습니다. 90일 만료 전에 미리 갱신하는 것이죠.
- SSH 노드 (Certbot 실행): 설정된 SSH 접속 정보를 이용해 제 웹서버에 접속합니다. 그리고 `sudo certbot renew –nginx` 명령어를 실행하여 Let’s Encrypt 인증서를 갱신합니다. 이때, `–nginx` 옵션은 Nginx 설정을 자동으로 감지하고 갱신 후 Nginx를 리로드하는 과정을 포함합니다. (물론, 때로는 이 리로드만으로 부족해서 별도의 재시작 명령이 필요할 때도 있습니다.)
- SSH 노드 (Nginx 재시작 – 필요시): 만약 `certbot renew –nginx` 명령이 Nginx 재시작까지 빈틈없이 처리하지 못하는 경우를 대비해, 별도의 SSH 노드를 추가하여 `sudo systemctl restart nginx` 명령을 실행하도록 구성했습니다. 이 부분은 서버 환경이나 Certbot 버전에 따라 다를 수 있습니다.
- If Node (결과 확인): Certbot 명령어 실행 결과를 분석하여 성공했는지, 실패했는지 판단합니다.
- Email/Slack 노드 (알림): 갱신이 성공하면 ‘SSL 갱신 완료’라는 간단한 메시지를, 실패하면 오류 메시지와 함께 상세 정보를 담아 저에게 알림을 보냅니다.
초기 설정 시 몇 가지 시행착오가 있었습니다. 예를 들어, SSH 접속 권한 문제로 명령이 실행되지 않거나, Nginx 설정 파일의 경로를 잘못 지정하는 바람에 갱신이 실패하는 경우도 있었습니다. 특히, Certbot이 Nginx 설정을 자동으로 감지하고 리로드하는 과정이 항상 완벽하지는 않다는 것을 알게 되었습니다. 그래서 저는 좀 더 확실하게 하기 위해, Certbot 갱신 명령 실행 후 별도로 Nginx를 재시작하는 단계를 추가했습니다. 이런 ‘삽질’ 덕분에 제 서버 환경에 잘 맞는 안정적인 자동화 워크플로우를 만들 수 있었습니다.

자동화, 그래서 얼마나 편해졌다고?
이 워크플로우를 구축하고 나서부터는 정말이지 마음이 편해졌습니다. 더 이상 90일마다 갱신일을 체크하며 불안해할 필요가 없습니다. n8n이 알아서 정해진 시간에 작업을 수행하고, 결과까지 저에게 알려주니까요. 실제로 몇 번의 갱신이 자동으로 문제없이 이루어졌고, 덕분에 저는 단 한 번도 사이트 다운을 겪지 않았습니다. 개인 서버 운영에 있어 이처럼 든든한 지원군이 또 있을까 싶습니다.
RPA 엔지니어로서 자동화는 제 일상이자 철학입니다. 반복적이고 오류 발생 가능성이 높은 작업은 기계에 맡기고, 우리는 더 창의적이고 중요한 일에 집중해야 합니다. Let’s Encrypt SSL 인증서 갱신 자동화는 그 좋은 예시라고 생각합니다. 여러분도 만약 수동 갱신 때문에 스트레스를 받고 있다면, n8n과 같은 자동화 툴을 활용해 보시는 것을 적극 추천합니다. 처음에는 조금 어렵게 느껴질 수 있지만, 한번 구축해 놓으면 그 편리함은 이루 말할 수 없을 것입니다.
앞으로의 계획
이번 경험을 발판 삼아, 앞으로 개인 서버 운영에 필요한 더 많은 작업들을 n8n으로 자동화해 나갈 계획입니다. 예를 들어, 정기적인 백업 자동화, 로그 파일 분석 및 알림, WordPress 블로그의 게시물 자동 발행 등 다양한 아이디어를 구상 중입니다. ISA 계좌로 ETF 자동 투자하는 것처럼, 서버 운영도 자동화로 효율을 높여나갈 생각입니다.
여러분도 혹시 자동화 아이디어가 있다면 댓글로 공유해주세요! 함께 더 나은 서버 운영 환경을 만들어나가면 좋겠습니다.