요즘 상담을 하다 보면 클라우드로 옮기면 서버 문제가 대부분 해결될 거라고 생각하는 분들이 많아졌습니다. 그런데 14년 동안 웹서버와 호스팅 인프라를 운영하면서 본 장애의 상당수는 서버 성능 부족보다 설정, 백업, 이전 절차에서 생겼습니다. 클라우드는 좋은 도구지만, 무조건 비싼 인스턴스를 고른다고 안정적이 되는 건 아닙니다.
클라우드는 성능보다 구조를 사는 방식입니다
웹호스팅은 정해진 공간을 빌려 쓰는 느낌이고, VPS는 작은 서버 한 대를 직접 관리하는 방식에 가깝습니다. 클라우드는 여기에 서버 복제, 스토리지 분리, 로드밸런서, 방화벽, 스냅샷 같은 운영 도구가 붙습니다. 그래서 클라우드를 쓴다는 말은 단순히 서버를 바꾼다는 뜻이 아니라 운영 구조를 직접 설계한다는 뜻에 가깝습니다.
문제는 이 구조가 익숙하지 않으면 비용만 늘어난다는 점입니다. 방문자 1천 명짜리 회사 소개 사이트에 고사양 서버와 관리형 데이터베이스, 로드밸런서를 모두 붙이는 경우를 종종 봅니다. 실제로는 저가 VPS나 기본형 클라우드 인스턴스 하나로 충분한 구간입니다. 반대로 하루 방문자는 많지 않은데 특정 시간에 예약, 결제, 이벤트 신청이 몰리는 사이트는 작은 서버 하나로 버티기 어렵습니다. 평균 트래픽보다 동시접속을 봐야 합니다.
서버 사양은 방문자 수가 아니라 동시접속으로 잡습니다
대략적인 계산은 단순하게 시작하면 됩니다. 하루 방문자 3천 명, 페이지뷰 1만 회인 블로그가 있다고 가정하겠습니다. 트래픽이 하루 종일 고르게 들어오면 큰 문제가 없지만 실제 사이트는 그렇지 않습니다. 보통 검색 유입은 특정 시간대에 몰리고, 광고를 태우면 10분 안에 평소 하루치 방문자가 들어오기도 합니다.
초기 기준으로는 동시접속 20명 이하라면 1코어 CPU, 메모리 1GB에서 2GB로도 충분한 경우가 많습니다. 워드프레스라면 캐시 플러그인과 이미지 최적화가 되어 있다는 조건입니다. 동시접속 50명 안팎이면 2코어, 메모리 4GB 정도를 봅니다. 쇼핑몰이나 회원 기능이 있으면 같은 접속자 수에서도 데이터베이스 부하가 커지므로 메모리를 더 넉넉히 잡는 편이 낫습니다.
- 개인 블로그, 회사 소개 사이트: 1코어, 메모리 1GB에서 2GB
- 일 방문자 수천 명 규모의 콘텐츠 사이트: 2코어, 메모리 2GB에서 4GB
- 예약, 결제, 회원 기능이 있는 서비스: 2코어 이상, 메모리 4GB 이상
- 이벤트성 트래픽이 있는 사이트: 서버 증설보다 캐시, CDN, 대기열 구조 우선 검토
사실 서버 사양보다 먼저 볼 건 응답 시간입니다. CPU 사용률이 낮은데 사이트가 느리면 서버를 키워도 별 효과가 없습니다. 데이터베이스 쿼리, PHP 설정, 이미지 용량, 외부 스크립트 지연이 원인인 경우가 더 많습니다. 서버가 작아서 느린지, 애플리케이션이 무거워서 느린지 구분해야 돈을 덜 씁니다.
클라우드 비용은 월 요금만 보면 틀립니다
클라우드 요금제 비교에서 가장 많이 놓치는 게 트래픽, 스토리지, 백업 비용입니다. 인스턴스 월 요금은 저렴해 보여도 외부 전송량이 많으면 전체 비용이 달라집니다. 이미지가 많은 사이트, 다운로드 파일이 있는 사이트, 동영상 썸네일을 많이 노출하는 사이트는 서버 요금보다 전송량 비용을 먼저 봐야 합니다.
예를 들어 페이지 한 번 열 때 3MB를 전송하는 사이트가 있습니다. 하루 페이지뷰 1만 회면 하루 30GB, 한 달이면 약 900GB입니다. 여기서 이미지를 절반으로 줄이면 서버를 바꾸지 않아도 월 전송량이 크게 내려갑니다. 실무에서는 서버 사양 업그레이드보다 이미지 압축, 브라우저 캐시, 정적 파일 분리가 비용 절감에 더 직접적일 때가 많습니다.
백업도 비용에 넣어야 합니다. 운영 서버 디스크가 50GB라면 스냅샷을 7일치만 보관해도 단순 계산으로 350GB 가까운 백업 공간이 필요할 수 있습니다. 증분 방식이면 실제 사용량은 줄지만, 그래도 무료라고 보면 안 됩니다. 저는 작은 사이트라도 최소한 일 단위 백업 7개, 월 단위 백업 2개 정도는 따로 둡니다. 장애는 오늘 난 서버에서만 끝나지 않습니다. 실수로 지운 데이터가 며칠 뒤 발견되는 경우도 많습니다.
이전할 때는 서버보다 순서를 먼저 잡아야 합니다
클라우드 이전에서 사고가 나는 지점은 거의 정해져 있습니다. DNS 전환, SSL 인증서, 데이터베이스 문자셋, 업로드 파일 누락, 크론 작업 누락입니다. 서버를 새로 만들고 웹페이지가 뜬다고 이전이 끝난 게 아닙니다. 예약 발송, 자동 결제, 로그 수집, 백업 스크립트까지 돌아야 운영이 넘어간 겁니다.
제가 쓰는 이전 순서는 단순합니다. 먼저 현재 서버에서 웹 루트, 데이터베이스, 설정 파일, 크론 목록을 따로 백업합니다. 그다음 새 클라우드 서버에 같은 런타임 버전을 맞춥니다. PHP, Node, 데이터베이스 버전이 달라지면 작은 플러그인 하나 때문에 화면이 깨질 수 있습니다. 테스트 도메인이나 로컬 hosts 설정으로 새 서버를 먼저 확인하고, 마지막에 DNS TTL을 낮춘 뒤 전환합니다.
- 이전 전: 파일, 데이터베이스, 설정, 크론, SSL 상태 확인
- 이전 중: 새 서버에서 로그인, 글쓰기, 결제, 파일 업로드 테스트
- 전환 직전: DNS TTL 단축, 원본 서버 쓰기 작업 제한
- 전환 후: 로그, 404, 500 오류, 메일 발송, 백업 성공 여부 확인
근데 여기서 많이 놓치는 게 원본 서버 보관 기간입니다. 새 서버가 잘 뜬다고 바로 기존 서버를 해지하면 곤란합니다. 최소 7일, 가능하면 14일은 원본 서버를 남겨두는 편이 안전합니다. 검색엔진, 일부 통신사 DNS, 외부 연동 서비스가 늦게 바뀌는 경우가 있기 때문입니다.
장애가 났을 때 먼저 볼 순서
사이트가 죽으면 서버부터 재부팅하는 분들이 많습니다. 급한 마음은 이해하지만, 재부팅은 증거를 지울 수 있습니다. 먼저 상태를 봐야 합니다. 웹서버가 떠 있는지, 디스크가 꽉 찼는지, 데이터베이스 연결이 되는지, 인증서가 만료됐는지 순서대로 보면 됩니다.
제일 흔한 건 디스크 100퍼센트입니다. 로그가 계속 쌓이거나 백업 파일이 같은 서버 안에 누적되면 어느 날 갑자기 로그인도 안 되고 데이터베이스도 멈춥니다. 그다음은 SSL 자동 갱신 실패입니다. 방화벽에서 인증 확인용 요청을 막았거나, 도메인 연결이 바뀌면서 갱신이 실패하는 경우가 있습니다. 트래픽 폭증이라고 생각했는데 실제로는 인증서 만료였던 일도 여러 번 봤습니다.
- 1순위: 서버 접속 가능 여부와 CPU, 메모리, 디스크 사용률
- 2순위: 웹서버와 데이터베이스 프로세스 상태
- 3순위: 최근 배포, 플러그인 업데이트, 설정 변경 이력
- 4순위: SSL 만료, DNS 변경, 방화벽 차단 여부
- 5순위: 외부 API, 결제 모듈, 메일 서버 지연
클라우드는 필요할 때 빨리 늘릴 수 있다는 장점이 있습니다. 다만 늘리기 전에 원인을 확인해야 합니다. 디스크가 꽉 찬 서버에 CPU를 올려도 장애는 그대로입니다. 느린 쿼리가 문제인 사이트에 로드밸런서를 붙여도 데이터베이스가 먼저 버팁니다. 운영에서 돈을 아끼는 방법은 싼 서버만 찾는 게 아니라, 어디에 돈을 써야 효과가 나는지 구분하는 데 있습니다.
처음 클라우드를 쓰는 사이트라면 작게 시작해도 됩니다. 대신 백업은 처음부터 잡고, 모니터링 알림은 켜고, 이전 절차는 문서로 남기는 게 좋습니다. 서버는 언제든 키울 수 있지만, 사라진 데이터와 놓친 설정은 나중에 훨씬 비싼 비용으로 돌아옵니다. 저는 아직도 새 서버를 만들 때 사양표보다 백업 경로를 먼저 봅니다. 그게 오래 운영해도 덜 흔들리는 방식이었습니다.
