일년에 한 두 번 폭주하는 사이트

철도청에서 운영하는 철도 예약 사이트인 코레일의 옛날 이야기다. 이 사이트는 일년에 두 번 사용자가 폭주했는데 평소의 100배 이상 사용자가 폭증했다. 설과 추석 근방이 그 시점이었다. 당시 이 사이트를 담당했던 사람들이 했던 고민이 생각난다. 3가지 정도였던 것 같다.




1. 사용자 폭주로 인해 시스템이 다운되는 현상을 어떻게 극복할 것인가?
2. 일년에 몇 주를 위해 과도한 시스템 투자를 하는 게 적절한가?
3. 그럼에도 불구하고 시스템 투자를 한다면 향후 ROI를 어떻게 확보할 것인가?


이 3가지 고민을 해결하기 위해 몇년 동안 고민을 했지만 적절한 대안을 찾기 힘들었던 것 같고 매년 설과 추석 즈음이 되면 서비스가 중단되거나 매우 느리게 동작하여 무용지물이 되는 일이 반복되었다. 결국 철도청 측은 코레일 시스템을 대폭 증가시키게 된다. 이미 예측은 했지만 그 몇 주의 폭주 기간이 지나면 시스템 자원은 과도하게 남아 돌았다. 그런데 더 큰 문제가 벌어지기 시작했는데, 시간이 지나면 지날수록 과거와 달리 목숨 걸고 코레일에서 예약하려는 사람들이 점차 줄어들기 시작한 것이다. 역귀성이나 고향에 가지 않고 시간을 보내는 사람도 많아졌기 때문이다. 그러니 시스템 자원은 더욱 남아 돌게 되었다. 어쩌면 Qubi라는 새로운 브랜드가 나오고 이들이 끝없는 광고 메일 보내기와 철도 여행 포털을 가장한 찌질한 사업 작풍을 갖게 된 요인에 이런 히스토리가 영향을 미쳤을 것이다.


모든 웹 서비스가 항상 사람들의 관심을 갖게 만드는 것은 아니다. 어떤 웹 사이트는 일년에 한 두번 정도만 집중적 관심을 받고 나머지 기간은 그다지 관심을 받지 못하기도 한다. 관심을 받는 시기와 그렇지 않은 시기의 편차가 얼마나 크냐는 웹 서비스를 기획하는 입장에서 매우 중요한 이슈다. 앞서 예시한 철도 예약 사이트의 경우 수백억 원에 달하는 비용 투자를 결정하는 중요한 사안이 되기도 했다. 이와 유사한 경험을 하는 웹 서비스는 어떤 것이 있을까?

- 국세청 웹 사이트 : 특히 연말정산 시기에 엄청난 트래픽이 폭주한다
- 철도청 웹 사이트 : 특히 명절 시기나 명절표 예매 시기에 폭주한다
- 입시 지원 웹 사이트 : 정시 지원, 합격자 발표 등 수험 관련 시기에 트래픽이 폭주한다
- 대학 수강 신청 사이트 : 일년에 두 번 수강 신청 시기에 트래픽이 폭주한다

이런 웹 사이트의 경우 일반적인 웹 사이트에 비해 평소 트래픽과 폭주 시기의 트래픽의 편차가 매우 크다. 대개의 웹 서비스 시스템은 사용자 폭주를 대비하여 상당한 여유분을 두고 인프라를 기획한다. CPU나 메모리, 저장공간 등 하드웨어와 그것의 배치 방식, 소프트웨어의 선정, 대역폭의 임대 등 모든 사항이 최대 사용 정도에 도달해도 서비스가 안정적으로 운영되도록 기획한다. 이 과정에서 시스템 엔지니어와 DBA, 아키텍트 등 전문적 식견을 가진 사람들의 예측이 필요하다. 그 예측에 의해 시스템에 투입될 비용을 결정하게 된다.

그럼에도 불구하고 문제가 쉽게 해결되지 않을 때 제 3의 대안으로 분산 처리 시스템이나 시스템의 공적 공유가 제안될 수 있다. 그러나 사업적 문제나 보안 문제, 혹은 시스템 자원 투자 문제 때문에 이 두가지 방법으로 문제를 해결하기 힘든 경우도 있다. 이런 경우 알면서 할 수 없이 과도한 시스템 자원 투자를 하게 되는 경우가 흔하다. 그 투자된 자원을 빨리 회수하기 위해 남아 도는 시스템 자원을 활용한 다양한, 그러나 분명 사업의 기본 방향을 뒤틀어 버리는 사업을 하는 경우도 흔하다. 예컨데, 100여 대의 엔터프라이즈 서버를 구매하여 트래픽 폭주 사태를 극복한 어떤 회사는 평소 10여 대의 서버만으로 충분히 서비스가 운용됨을 이미 알고 있었다. 그러나 트래픽 폭주를 견디기 위해 결국 100대를 구입했는데, 나머지 90대의 활용 방안으로 웹 호스팅 사업을 새롭게 진행하기로 했다. 그런데 그 회사는 웹 호스팅과 별 관계없는 사업을 하고 있었다. 웹 호스팅 사업 덕분에 회사의 사업 포트폴리오는 불필요하게 복잡해졌고 또한 불필요한 인원 투입과 개발 비용이 소모되었다.  

한편 전반적인 시스템을 적극적으로 혁신하지 않고 웹 서비스 기획의 관점에서 이런 문제를 해결하는 몇 가지 방법이 있다. 내가 예전에 사용했던 방법 중 하나는 클라이언트에게 많은 일을 넘김으로써 웹 서버나 DB 서버가 해야 할 일을 극적으로 줄이는 것이다. 사용자에게 받은 일부 정보를 기초로 서버 측에서 해야 할 일이 많을 때 그 기능 중 대부분을 클라이언트에게 넘기고 클라이언트가 그 작업을 수행하는 동안 웹 서버는 실시간 정보 노출을 하지 않고 다른 일을 하는 것이다.

만약 클라이언트를 개발하기 힘든 상황이거나 보안 문제 때문에 서버 측에서 모든 일을 실시간으로 처리해야 한다면 사용자가 입력한 정보를 매번 전송하는 것이 아니라 한번에 전송하는 인터페이스를 구현하는 방법으로 문제를 일부 해결할 수도 있다. 통합 입력 인터페이스는 이런 문제에 대한 해결 방안이 될 수도 있다. 사용자가 입력한 정보를 Step by Step으로 매번 확인하고 DB에 입력하는 것이 아니라 몇 개의 굵직한 정보 채널로 구분하여 동시에 입력하는 것이다. 웹 서비스 기획자가 고민해야 할 것은 그 정보 채널의 구분 기준이다. 이 지점에서 내가 가장 많이 제안하는 것은 "시스템 설계"에 따른 완결성이 아니라 "사용자 입장에서 가장 시간이 많이 지연되는 부분"을 고려하라는 것이다.

예를 들어 사용자가 기차표를 사기 위해 가장 많이 고려하는 부분이 출발 시간대라면 그 프로세스는 로그인을 하지 않고 볼 수 있도록 해야 한다. 로그인을 하고 시간대를 선택하면 다양한 웹 서비스를 추가로 지원할 수 있을 것이다. 그러나 사용자들이 시간대를 선택하는데 소요되는 시간이 평균 3분이고, 그런 사용으로 인해 전체 시스템 자원이 대부분 이용되고 있다면 과감하게 시간표 선택 부분을 로그인 전 단계로 이동시키거나 심지어 시간표 조회 페이지를 flash와 같은 형식으로 popup으로 띄워 프로세스를 떼 내 버릴 수도 있다.

일년에 한 두번 트래픽이 폭주하는 웹 사이트가 그리 흔한 것도 아니고, 어쩌면 웹 서비스를 기획하는 동안 이런 사이트를 단 한 번도 기획하지 못할 수 있다. 그러나 이런 특징과 해결 방안이 존재한다는 정도는 알아 둘 필요가 있을 것이다.


* updated 03.24 : 댓글에서 한 익명의 사용자가 이야기했듯 트래픽이 폭주하는 시기에 장비나 대역폭을 임대하는 방법도 있다. 그런데 문제는 사업 초기에 이런 것을 전혀 고려하지 않는 경우가 허다하다는 것이고, 설령 고려하더라도 꽤 오랜 시간의 실수를 반복한 이후라는 것이다.