서버 비용에 대한 문의

‘서버 비용이 얼마나 나오나요?’라는 질문은 개발을 의뢰받는 입장에서 가장 많이 받는 질문 중 하나다. 이 질문은 ‘이 서비스가 성공할까요?’를 묻는 만큼이나 답하기 어렵다. 그래서 ‘얼마 안나와요’, ‘나와도 $50/월 미만입니다’ 정도로 대답하거나, ‘서버비 걱정하실 정도면 서비스는 이미 성공한거예요’ 또는 ‘예산 한도를 설정해놓고 모니터링해보시라’고 대답한다. 성실하지 못한 답변이지만, 이 이상으로 답하기 어렵다. 개발 환경이라면 ‘몇 만원’ 수준 이하의 금액이 청구될 것이고, 실제 데이터가 들어가고 운영이 시작된다면 비용은 점진적으로 증가할 것이다. 이 때 어느정도까지 가파르게 증가할지는 판단하기 어렵다.

보통의 서버는 API 서버와 웹 서버, DB, 스토리지로 구성된다. API 및 웹 서버로 사용되는 EC2는 보통 t2.micro 단계부터 시작하고 점차 t2.small > t2.midium > t2.large 같은 식으로 늘려나간다. DB도 동일하다. 처음에는 RDS의 db.t2.micro에서 시작하고, 점차 늘려나간다. 스토리지는 개념이 좀 다르지만, 초기에는 금액이 매우 저렴하기 때문에 크게 고려할 대상은 아니다. 즉, 흔히 생각하는 트레픽이라는 개념보다는 데이터를 입출력하고, 연산할 때 필요한 컴퓨팅 규모를 어느정도로 잡을 것인가에서 가격 차이가 발생한다. 10,000명의 회원을 갖는 두 개의 서비스가 있다고 할지라도, 서비스의 종류와 처리하는 데이터의 양, 연산의 복잡도에 따라 달라진다는 것이다.

#1. B2C 모바일, 웹 서비스

일반적인 B2C 서비스라면 개발 단계에서 지출되는 ‘몇 만원’ 수준 또는 그 이하의 금액이 상당 기간 유지된다. 특히나 사진 몇 장, 글 몇 개를 작성하고 다른 사용자가 작성한 글을 확인하는 소위 ‘소셜’ 타입의 서비스라면 더욱 그렇다. 연산 작업도 거의 없고, 동시에 수용해야할 데이터 처리량도 적다. 아주 거대한 서비스가 되기 전까지 서버 비용은 서비스의 규모에 비해 ‘생각보다’ 작다. 커머스도 유사하다. 소소하게 운영되는 독립몰 형태의 커머스 서비스라면, 대부분의 방문자는 상품을 보는데 집중한다. 카트에 담고, 주문과 결제가 일어나는 액션은 전체 사용 시간 중 극히 일부분에 지나지 않는다.

따라서 아래 CPU 점유율에서 보듯, 매우 안정적으로 유지된다. (아래의 사례는 DAU 1,000명 정도 수준이다.) 이렇게 유지된다면 특정 시간대에 발생하는 병목현상이 드물기 때문에 서버를 증설할 (서버 사양을 높일) 이유가 적어진다. 그만큼 서버 비용도 안정적이고, 높지 않다.

#2. B2B 서비스 + 데이터 중심 서비스

반면 운영 중심으로 동작하는 서비스는 구조가 다르다. 특정 시간/날짜를 주기로 데이터 처리량이 꾸준히 증가한다. 그러다가 서비스 운영상의 이벤트가 발생하는 경우 CPU 점유율이 순간적으로 100%까지 도달할 수도 있다. 이 때 서버는 사용자들의 데이터 요청을 거부하고, 에러를 발생시킨다. 보통 time-out 에러가 뜨거나, 로딩바가 무한히 돌아가는 현상 등이 나타난다. 이런 서비스의 경우에는 피크 타임에도 100%가 되지 않도록 서버의 사양을 한 단계 높여주어야 한다. 이 때 비용이 기하급수적으로 늘어난다.

개발 단계에서 5만원 이하로 나오던 서버 비용이 실제 서비스를 런칭하면서 10만원을 넘게 되고, 사용자들이 가입을 시작하고 어느정도 (최소한의 수준에서) 서비스가 돌아가기 시작할 때 비용은 더 증가한다. 그 때 한 두 단계의 서버 사양 업그레이드가 발생하면 40~50만원 수준까지 서버 비용이 증가한다. 경험상 서버 비용이 10만원 이하일 때는 누구도 신경쓰지 않는다. 하지만 40~50만원을 넘어가게 된다면 ‘왜 이렇게 많이 나오냐’, ‘뭔가 잘못한거 아니냐’, ‘이런 얘기는 미리 알려줬어야하지 않느냐’, ‘뭔지는 모르겠지만 최적화를 진행해서 비용을 xx만원 이하로 줄여라’ 등 질문에서 비난까지 이어지는 다양한 피드백을 받게 된다.

그럼 왜 이런 현상이 생길까? 쇼핑 앱이 있다고 가정해보자. 보통 보여지는 상품 리스트는 ‘가격 높은 순’ 또는 ‘최신 등록 순’ 정도로 정렬해서 보여준다. 따라서 한 명의 사용자가 데이터를 요청할 경우, 처리 시간은 극도로 짧다. 그리고 한 번 처리된 리스트를 이리저리 둘러보느라 많은 시간을 소요하게 되고, 상품 하나를 눌러 세부 정보를 확인하는 정도로 동작한다. 있는 데이터를 보여주는 요청과 응답이 대부분이기에 서버는 매우 편안한 상태를 유지한다. 하지만 상품 리스트를 불러올 때마다 (페이지를 열 때마다) 사용자의 네비게이션 패턴을 실시간으로 분석하고, 그 결과에 따라 DB에 있는 수십만건의 상품과 비교하여 사용자에게 맞는 수십 개의 상품만을 뽑아내서 보여준다면 서버는 연산을 해야한다. 그 연산의 작업이 이제 막 개발되어 최적화가 안되어있다면, 한 번의 연산 작업은 수 초가 걸릴 수 있다. 그리고 한번의 연산 작업이 서버에서 진행되는 동안 다음 사용자가 동일한 연산을 요구한다면, 두 번째 작업은 첫 번째 연산이 끝나길 기다려야한다. 연산을 처리하는 속도보다 연산을 요청하는 수가 늘어나게되면 결국 어느순간 CPU 점유율이 100%에 도달하고, 서버는 소위 ‘죽는다’. DB 역시 비슷한 방식으로 문제가 발생한다.

처음 서비스를 만드는, 또는 의뢰하는 입장에서는 ‘서버 비용’에 대해 초기부터 고려하는게 어렵다. 따라서 두 가지 정도를 개발팀 (내부든, 외부든)에 요청하는 것이 좋다. 1) 몇 대의 서버/인스턴스를 사용할 것인지, 2) 만약 AWS 등 클라우드를 사용한다면 어떤 서비스들을 사용할 것인지, 3) 서버 중에 고사양이 필요한 서버가 있는지를 문의한다. 그리고 만들고자하는 서비스/시스템에서 통계치를 구하는 등, 계산식을 통해 실시간으로 수치를 만들어내는 기능이나 특정 시간에 주기적으로 자동 연산을 해야하는 기능들이 있는지 확인한다. 그리고 각 기능들이 서비스 성능에 영향을 줄 수 있는지를 개발팀에 구체적으로 문의한다.

그 후에 AWS에서 제공하는 가격 계산기를 활용해서 스스로 가격을 계산해본다. 이리저리 넣어보고 바꿔보면서 대략 어느 정도의 금액이 나올지 감을 갖는게 중요하다. ~$5인지, ~$50인지, ~$500인지에 대한 감이 있어야 하고, 그 수준의 금액 청구에 대해 마음의 준비를 해야한다. ‘서버비가 $100 이하였으면 좋겠어요’ 같은 선언적인 요청은 큰 의미가 없다. 일단 첫 달의 가격이 청구되고 나면, 그 후에는 다양한 방법을 통해 서버 비용을 줄여나갈 수 있다. 다만 시간이 걸리는 작업이고, 이 작업을 최초의 개발 단계에서 수행하기에는 무리가 있다는 점만 잘 이해하고 있으면 좋겠다. (개발비는 곧 개발 시간에 비례하는데, 월 $50을 줄이기 위해 개발 시간을 투자하는 것이 효율적인지 생각해보자는 의미다.)