서버 보안 업데이트가 두렵다면 AWS를 써야 하는 이유

 

서버 보안 업데이트, 마지막으로 하신 게 언제인가요? 저는 부끄러운 고백을 하나 하려고 합니다. IDC에 직접 구축한 서버를 13년 동안 단 한 번도 업데이트하지 못했습니다. 잘 돌아가고 있는 걸 괜히 건드렸다가 복구가 안 되면 어쩌나, 그 두려움 하나 때문이었어요. 이 글은 그때의 저 같은 분들, 그러니까 "업데이트해야 하는 건 아는데 손이 안 나가는" 개발자에게 드리는 이야기입니다.

"운영 중인 서버에 yum update 한 줄 치는 게 이렇게 무서운 일이었나요?" "패치했다가 서비스 죽으면 누가 책임지죠?" "AWS 쓰면 보안 업데이트 알아서 해준다던데, 진짜인가요?" "OS 업데이트를 꼭 해야 하나요? 지금 아무 문제 없는데요."

사실 저 질문들, 전부 예전의 제 머릿속에 있던 말입니다. 그런데 AWS로 넘어오고 나서 저는 서버 업데이트를 오히려 과감하게 하기 시작했어요. 서버를 한 대 더 띄워서 거기에 먼저 올려 보고, 로드밸런서로 트래픽을 조금씩 흘려 확인한 다음 문제없으면 넘기는 방식으로요. 두려움이 사라진 게 아니라, 두려움을 감당할 안전장치가 생긴 겁니다.

그래서 이 글에서는 두 가지를 같이 다룹니다. 하나는 "보안·OS 업데이트를 대체 왜 해야 하는가", 다른 하나는 "그 무섭고 되돌릴 수 없던 작업을 AWS가 어떻게 감당 가능한 일로 바꿔 주는가"입니다. 온프레미스/IDC 서버를 만져 본 분일수록 뒤쪽 이야기가 더 와닿을 거예요.

목차

1. 서버 보안 업데이트를 안 하면 실제로 벌어지는 일
2. 보안 패치와 OS 업데이트, 뭐가 다른가
3. 13년 동안 IDC 서버 업데이트를 한 번도 못 한 이유
4. 업데이트가 무서운 진짜 이유는 '복구가 안 된다'는 것
5. AWS가 대신 해주는 것 vs 그래도 내 몫인 것
6. 스냅샷과 AMI가 바꾼 것: 되돌릴 수 있다는 안정감
7. 서버를 한 대 더 만들어 올렸습니다
8. Patch Manager로 업데이트를 스케줄에 맡기기
9. 그래도 직접 서버를 쓴다면 최소한 이것만은
10. 자주 묻는 질문
11. 업데이트는 용기가 아니라 설계의 문제

1. 서버 보안 업데이트를 안 하면 실제로 벌어지는 일

"지금 잘 돌아가는데 왜 건드려?"라는 말에는 함정이 있습니다. 서버가 조용한 건 안전해서가 아니라, 아직 아무도 안 두드려 봐서일 뿐이거든요. 소프트웨어의 취약점은 시간이 지날수록 쌓이지, 저절로 사라지지 않습니다.

2024년 7월에 공개된 OpenSSH의 regreSSHion(CVE-2024-6387)이 좋은 예입니다. 인증도 하기 전에 원격에서 root 권한으로 코드를 실행할 수 있는 취약점이었고, 인터넷에 노출된 취약 서버가 1,400만 대 규모로 추정됐습니다. 더 섬뜩한 건 이게 2006년에 한 번 고쳐졌던 버그가 코드 변경 과정에서 되살아난 '회귀(regression)' 버그였다는 점이에요. 한 번 막았어도 업데이트를 안 하면 다시 뚫릴 수 있다는 걸 그대로 보여 준 사례죠.

SSH는 거의 모든 리눅스 서버에 기본으로 깔려 있습니다. 그 말은 "내 서버는 특별한 거 안 깔았으니 괜찮아" 같은 게 통하지 않는다는 뜻이에요. 기본으로 켜져 있는 것에서 구멍이 나면, 아무것도 안 한 서버가 제일 먼저 당합니다.

📌 방치된 서버의 진짜 위험 취약점 공개는 공격자에게도 똑같이 열린 정보입니다. 패치가 나온 그 순간부터, 아직 안 고친 서버들은 "여기 열려 있어요" 하고 지도에 표시되는 셈이에요. 스캐너가 하루에도 수천 번 인터넷을 훑고 다니니까요.

2. 보안 패치와 OS 업데이트, 뭐가 다른가

흔히 뭉뚱그려 "업데이트"라고 부르지만, 실무에서는 성격이 조금 다릅니다. 이 구분을 알아 두면 "지금 이걸 꼭 해야 하나"를 판단하기가 훨씬 쉬워져요.

반응형

구분	보안 패치	OS(버전) 업데이트
목적	알려진 취약점 구멍 막기	커널·라이브러리 세대 교체, 기능 개선
빈도	수시로, 취약점 공개될 때마다	몇 년에 한 번, 지원 종료 즈음
위험도	보통 낮음(같은 세대 안에서 교체)	높음(호환성 깨질 수 있음)
미루면	뚫릴 위험이 계속 커짐	지원 종료 후 패치조차 안 나옴

여기서 특히 무서운 건 표 맨 아랫줄입니다. OS 버전이 지원 종료(EOL)되면 그 뒤로는 아무리 심각한 취약점이 발견돼도 보안 패치 자체가 안 나옵니다. 즉 "보안 패치를 미루는 것"과 "OS를 안 올려서 패치가 나올 수조차 없게 방치하는 것"은 위험의 결이 다릅니다. 후자가 훨씬 답이 없어요.

3. 13년 동안 IDC 서버 업데이트를 한 번도 못 한 이유

솔직하게 말하면, 저는 IDC에 직접 넣어 둔 서버의 OS를 13년 내내 그냥 뒀습니다. 딱히 배짱이 좋아서가 아니라, 정반대였어요. 무서워서 못 건드린 겁니다.

이유는 세 가지쯤 됐던 것 같아요. 첫째, 잘 돌아가고 있는 서버를 굳이 건드릴 용기가 안 났습니다. 둘째, 잘못됐을 때 원래대로 되돌릴 방법이 마땅치 않았어요. 셋째, 이게 제일 컸는데 아무도 저한테 "그거 업데이트하세요"라고 말해 주지 않았습니다. 시키는 사람도 없고, 안 해도 당장 아무 일이 없으니, 자연스럽게 목록의 맨 뒤로 밀렸죠.

지금 와서 보면 이건 개인의 게으름이라기보다 IDC 시절의 구조적인 문제였습니다. 서버가 '한 대의 물리 장비'로 존재하는 순간, 그건 손대기 무서운 유일무이한 대상이 됩니다. 복제본도 없고, 어제로 되돌리는 버튼도 없으니까요.

4. 업데이트가 무서운 진짜 이유는 '복구가 안 된다'는 것

업데이트가 무서운 건 사실 업데이트 그 자체가 아닙니다. update 명령 한 줄은 몇 초면 끝나요. 무서운 건 "이걸 눌렀다가 서버가 안 뜨면, 되돌릴 방법이 없다"는 점입니다.

커널이 올라갔는데 드라이버가 안 맞아서 부팅이 안 되는 상황, 라이브러리 버전이 바뀌면서 애플리케이션이 조용히 죽는 상황. IDC의 물리 서버에서 이게 터지면 새벽에 데이터센터로 달려가거나, 원격 콘솔 붙잡고 식은땀 흘리며 몇 시간을 씨름하게 됩니다. 저도 그런 밤을 몇 번 겪고 나니, 아예 "안 건드리는 게 이기는 것"이라는 왜곡된 결론에 도달해 버렸어요.

💡 핵심은 '되돌리기' 업데이트를 못 하게 만드는 진짜 원인은 위험이 아니라 비가역성입니다. 언제든 5분 전으로 되돌릴 수 있다면, 사람은 훨씬 과감해집니다. 클라우드가 바꾼 게 바로 이 지점이에요.

5. AWS가 대신 해주는 것 vs 그래도 내 몫인 것

여기서 오해 하나를 짚고 가야겠습니다. "AWS 쓰면 보안 업데이트 알아서 다 해준다"는 말은 절반만 맞습니다. 어디에 뭘 올렸느냐에 따라 완전히 달라져요.

RDS(데이터베이스), Lambda, Fargate 같은 관리형 서비스는 밑단 OS 패치를 AWS가 책임집니다. 이건 진짜로 신경 안 써도 되는 영역이에요. 반면 EC2 위에 리눅스를 직접 올려 쓰고 있다면, 그 안의 OS 패치는 여전히 온전히 제 몫입니다. AWS는 그 서버 안에서 무슨 일이 벌어지는지 대신 챙겨 주지 않아요.

방식	OS 패치 책임	비고
RDS / Lambda / Fargate	AWS	관리형, 사실상 손 뗌
EC2 직접 운영	나	단, 되돌릴 수단은 넉넉함
IDC 물리 서버	나	되돌릴 수단도 내가 마련

그러니까 AWS의 가치는 "패치를 대신 눌러 준다"가 아닙니다. EC2를 쓰더라도 패치는 여전히 제가 하지만, 그 패치를 안심하고 누를 수 있게 만드는 판을 깔아 준다는 데 있어요. 이게 IDC와 가장 크게 갈리는 지점이고, 실은 사람의 심리를 바꾸는 차이이기도 합니다.

6. 스냅샷과 AMI가 바꾼 것: 되돌릴 수 있다는 안정감

EC2를 쓰면서 제가 제일 먼저 몸으로 느낀 건 스냅샷이었습니다. 업데이트하기 직전에 디스크 스냅샷을 하나 떠 두면, 무슨 일이 생겨도 그 시점으로 돌아갈 수 있어요. AMI(머신 이미지)를 떠 두면 아예 똑같은 서버를 통째로 다시 찍어낼 수도 있고요.

이게 별거 아닌 것 같아도, 심리적으로는 완전히 다른 세계입니다. IDC 시절엔 "잘못되면 끝"이었는데, 이제는 "잘못되면 되돌리면 됨"이 됐거든요. 되돌릴 수 있다는 사실 하나만으로 update 명령을 누르는 손가락의 무게가 달라졌습니다.

물론 스냅샷·AMI에도 스토리지 비용이 붙긴 합니다. 그런데 저는 이걸 비용이라기보다 '용기의 가격'이라고 생각하게 됐어요. 몇 달치 스냅샷 비용이 새벽에 데이터센터로 달려가는 한 번의 사고보다 훨씬 쌉니다.

7. 서버를 한 대 더 만들어 올렸습니다

AWS로 넘어온 뒤 제가 실제로 쓰는 방식은 이렇습니다. 업데이트할 서버가 있으면, 그걸 직접 건드리지 않고 똑같은 서버를 한 대 더 띄웁니다. 그 새 서버에 먼저 패치를 올리고, 잘 뜨는지, 애플리케이션이 정상인지 확인해요.

그다음 로드밸런서에 이 새 서버를 붙여서 트래픽을 아주 조금씩 흘려 봅니다. 에러율이나 응답 시간을 지켜보다가 문제가 없으면 트래픽을 점점 넘기고, 기존 서버는 내리는 거죠. 만약 새 서버가 이상하면? 그냥 로드밸런서에서 떼어 버리면 끝입니다. 사용자는 아무것도 못 느껴요.

이게 흔히 말하는 블루/그린 방식, 혹은 '서버를 고치지 말고 갈아 끼우는' 접근입니다. 거창한 이론처럼 들리지만 핵심은 단순해요. 살아 있는 환자를 수술하지 말고, 건강한 복제본을 만들어서 그쪽으로 갈아타자는 거죠. IDC에서 물리 서버 한 대를 붙잡고 벌벌 떨던 저에게는, 이게 거의 마법처럼 느껴졌습니다.

💡 이 가치는 겪어 본 사람만 압니다 서버 한 대를 몇 분 만에 복제하고, 로드밸런서로 검증하고, 아니다 싶으면 미련 없이 버리는 것. IDC에서 장비 한 대를 신주단지처럼 모시던 시절을 지나온 개발자라면, 이 '버릴 수 있음'이 얼마나 큰 자유인지 아실 겁니다.

8. Patch Manager로 업데이트를 스케줄에 맡기기

손으로 하는 것도 좋지만, 서버가 여러 대가 되면 결국 자동화가 답입니다. AWS Systems Manager의 Patch Manager는 EC2뿐 아니라 온프레미스 서버까지 대상으로, 빠진 패치를 스캔하고 설치하는 걸 스케줄에 맡길 수 있게 해 줍니다.

동작 방식을 아주 단순하게 정리하면 세 가지입니다. 어떤 패치를 승인할지 정하는 '패치 베이스라인', 언제 돌릴지 정하는 '점검 창(maintenance window)', 어떤 서버에 적용할지 묶는 '패치 그룹'. AWS 기본 베이스라인은 보안 등급이 높은 패치를 공개 7일 뒤 자동 승인하도록 돼 있어서, 검증 시간을 조금 두면서도 방치되지 않게 균형을 잡아 줍니다.

한 가지 정직하게 덧붙이자면, Patch Manager도 만능은 아닙니다. AWS가 패치를 대신 테스트해 주지는 않고, RHEL 7에서 8로 넘어가는 식의 메이저 OS 버전 업그레이드는 지원하지 않아요. 그래도 "빠진 보안 패치를 정해진 시간에 알아서 채워 넣는" 반복 노동을 사람 손에서 떼어 낸다는 것만으로도 충분히 가치가 있습니다.

9. 그래도 직접 서버를 쓴다면 최소한 이것만은

여러 사정으로 IDC나 자체 서버를 계속 써야 하는 분도 많죠. 그럴 때 예전의 저처럼 아예 손을 놓지는 않도록, 부담을 줄이는 방법 몇 가지를 적어 둡니다.

- 업데이트 전에는 무조건 백업이나 이미지를 먼저 확보하세요. '되돌릴 수 있다'는 상태를 스스로 만들어 두는 게 첫걸음입니다.

- 스테이징 서버를 하나 두고 거기서 먼저 패치를 검증하세요. 여의치 않으면 트래픽 적은 시간대라도 확보하고요.

- 전부 다 하려 하지 말고, 인터넷에 노출된 SSH 같은 핵심 표면부터 우선 챙기세요. 노출된 것부터 뚫립니다.

- unattended-upgrades 같은 자동 보안 업데이트를 커널 외 패키지에 한정해 켜 두는 것도 방법입니다. 다만 자동 재부팅 여부는 신중하게 정하세요.

완벽하게 하려다 아무것도 못 하는 것보다, 되돌릴 수단을 갖춰 두고 조금씩이라도 하는 편이 훨씬 낫습니다. 이건 제가 13년을 미루고 나서야 배운 거예요.

10. 자주 묻는 질문

서버 보안 업데이트를 안 하면 정말 문제가 생기나요?

당장은 아무 일도 없을 수 있습니다. 그게 함정이에요. 취약점이 공개되면 공격자도 그 정보를 똑같이 보고, 아직 안 고친 서버를 자동으로 훑습니다. regreSSHion 사례처럼 인증 전 원격 코드 실행이 가능한 구멍이 열려 있으면, 조용하던 서버가 어느 날 갑자기 남의 것이 될 수 있습니다.

OS 업데이트와 보안 패치는 같은 건가요?

다릅니다. 보안 패치는 같은 OS 세대 안에서 알려진 구멍을 막는 수시 작업이고, OS 업데이트는 버전 자체를 올리는 큰 작업입니다. 보안 패치는 상대적으로 안전하니 자주 하는 편이 좋고, OS 버전은 지원 종료 전에 계획을 세워 올리는 게 안전합니다.

AWS를 쓰면 보안 업데이트를 신경 안 써도 되나요?

서비스에 따라 다릅니다. RDS, Lambda, Fargate 같은 관리형 서비스는 AWS가 밑단 패치를 챙기니 사실상 손을 떼도 됩니다. 하지만 EC2에 직접 리눅스를 올려 쓴다면 OS 패치는 여전히 본인 책임입니다. AWS가 주는 건 '대신 해줌'이 아니라 '안심하고 할 수 있는 환경'에 가깝습니다.

직접 구축한 서버는 어떻게 안전하게 업데이트하나요?

핵심은 되돌릴 수단을 먼저 만드는 것입니다. 업데이트 전 백업이나 이미지를 확보하고, 가능하면 복제본이나 스테이징에서 먼저 검증한 뒤 적용하세요. 한 번에 다 하려 하지 말고 노출된 핵심 서비스부터 우선순위를 두는 것도 방법입니다.

11. 업데이트는 용기가 아니라 설계의 문제

13년 동안 서버 업데이트를 못 눌렀던 저를 돌아보면, 그건 제가 겁쟁이여서가 아니었습니다. 되돌릴 수 없는 구조 위에서는 누구라도 손이 굳게 마련이에요. 반대로 AWS로 넘어와 과감해진 것도 제가 갑자기 배짱이 생겨서가 아니라, 언제든 되돌릴 수 있는 판 위에 올라섰기 때문입니다.

그래서 저는 "왜 업데이트를 안 하냐"고 스스로를 다그치기보다, "어떻게 하면 업데이트가 무섭지 않은 환경을 만들까"를 먼저 고민하게 됐어요. 스냅샷, AMI, 로드밸런서 뒤의 복제 서버, Patch Manager 같은 것들은 결국 그 하나를 위한 장치들입니다. 되돌릴 수 있으면, 사람은 자연스럽게 안전한 쪽으로 움직이거든요. 혹시 지금도 update 앞에서 손이 멈추신다면, 명령을 누를 용기를 짜내기 전에 되돌릴 안전장치부터 만들어 보시길 권합니다. 순서가 그게 맞더라고요.

📚 함께 보면 좋은 글

SSL 인증서 유효기간 단축 - 1년에서 47일로, 무료 SSL 인증서 대응법

데이터는 어디에 저장될까 - CPU·메모리·하드디스크로 이해하는 Redis·MySQL·MongoDB

컴퓨터는 언제 발명됐을까 - "세계 최초"가 여러 개인 이유

우분투는 어쩌다 서버의 기본값이 됐을까 - CentOS를 떠나 우분투로 온 개발자 이야기

왜 서버 컴퓨터는 인텔 CPU만 쓸까? - 13년차 개발자가 풀어보는 x86과 ARM의 진짜 차이