5분간 150만 건. 지난 9월 한 마라톤 대회가 참가 신청을 받기 시작하자 아임웹으로 만들어진 사이트에 쏟아진 요청이다. 순간적으로는 초당 5000건을 넘어섰다.
이처럼 행사 접수나 한정 판매 등 특정 시점에 이용자가 집중되는 경우, 평소의 수십 배에 달하는 트래픽이 짧은 시간 안에 몰리기도 한다. 브랜드에게는 반가운 일이지만, 인프라 입장에서는 가장 긴장되는 순간이다. 갑작스러운 트래픽을 감당하지 못하면 접속 지연이나 서비스 중단으로 이어질 수 있어서다.
아임웹은 웹사이트나 쇼핑몰 제작부터 주문·결제, CRM 마케팅까지 브랜드의 온라인 비즈니스 운영 전반을 지원하는 플랫폼이다. 지금까지 아임웹을 통해 만들어진 사이트는 100만 개 이상이다. 그만큼 안정적인 서비스 운영은 고객의 비즈니스와 직결되는 과제다.
아임웹은 특정 사이트의 트래픽을 분리하고, 이상 징후를 감지하며, 장애 원인을 다음 개선으로 연결하는 운영 체계를 만들어왔다. 김용현 아임웹 인프라팀 리드를 만나, 대규모 트래픽에 대응하는 아임웹의 방식과 그동안의 변화를 들었다.
트래픽은 몰려도, 영향은 번지지 않게
김용현 리드는 아임웹의 인프라 구조를 ‘아파트’에 빗대 설명했다. “100만 가구가 전기와 수도를 함께 사용하는 아파트라고 생각하면 쉽습니다. 한 집에서 큰 잔치가 열렸다고 아파트 전체가 정전돼서는 안 되잖아요. 아임웹도 마찬가지입니다. 특정 고객에게 트래픽이 몰리더라도 다른 고객은 평소처럼 서비스를 이용할 수 있어야 합니다.”
아임웹은 트래픽이 몰리는 사이트를 별도 서버와 방어 규칙으로 분리해, 한 사이트의 영향이 다른 사이트로 번지는 것을 막는 구조를 운영하고 있다. 대응 방식은 트래픽을 미리 예상할 수 있는지에 따라 달라진다.
공동구매나 행사처럼 일정이 정해진 이벤트는 사전에 등록해 대비한다. 과거에는 담당자가 이벤트에 앞서 서버를 직접 늘렸지만, 지금은 과거 이벤트의 트래픽 데이터를 바탕으로 필요한 서버 규모를 산정하고 서버를 미리 확장하는 과정을 자동화했다. 이벤트가 끝나 트래픽이 안정되면 늘렸던 서버도 자동으로 줄어든다.
더 까다로운 것은 사전에 알 수 없는 트래픽이다. 별다른 예고 없이 특정 사이트의 트래픽이 급증하면 해당 사이트를 다른 고객과 분리해 영향을 격리한다. 여기서도 처리 가능한 수준을 넘어서면 대기열을 작동시켜 서버로 들어오는 이용자 수를 조절한다. 한 사이트의 갑작스러운 트래픽이 다른 사이트까지 영향을 미치지 않도록 단계별로 방어선을 두는 셈이다.
“트래픽이 몰리는 것 자체를 막을 수는 없습니다. 중요한 건 특정 사이트에 트래픽이 몰리더라도 그 영향이 다른 고객에게까지 번지지 않게 하는 것입니다.”
장애 대응도 시스템으로…25초 온콜부터 AI 포스트모템까지
트래픽 대응과 함께 아임웹이 바꾼 것은 장애를 발견하고 대응하는 방식이었다. 김 리드가 아임웹에 합류했을 당시 가장 먼저 확인한 과제 중 하나는 장애 상황을 빠르게 파악할 수 있는 데이터와 관측 체계였다. “장애가 생기면 일단 복구는 할 수 있었어요. 그런데 정확히 어디서 시작된 문제인지 확인할 수 있는 데이터가 충분하지 않았습니다.”
이에 서비스 상태를 실시간으로 파악할 수 있는 관측 체계를 구축했다. 현재 아임웹 인프라팀은 김 리드를 포함해 8명으로, SRE·DevOps·보안·데이터베이스·데이터 등 5개 전문 영역을 중심으로 운영된다. 이상 징후가 감지되면 온콜 시스템이 관련 담당자를 자동으로 호출하고, 장애 상황에서는 각 영역의 담당자가 동시에 서버와 데이터베이스, 보안 시스템 등을 살피며 원인을 좁혀간다. 긴급 알림에 응답하기까지 걸리는 시간의 중앙값은 약 25초다.
대응은 복구에서 끝나지 않는다. 이후 장애의 원인과 대응 과정을 분석해 재발 방지책을 찾는 ‘포스트모템’을 진행한다. 장애 대응 과정은 실시간으로 기록되며, AI가 이를 분석해 시간대별 대응 과정을 정리한 포스트모템 초안을 만든다. 담당자는 이를 토대로 원인을 분석하고 개선 과제를 도출한다. 과제마다 담당자를 지정하고 실제 조치가 완료될 때까지 관리하는 것도 이 과정에 포함된다.
“장애를 빠르게 복구하는 것만으로는 충분하지 않습니다. 왜 문제가 생겼는지 데이터로 확인하고, 같은 문제가 반복되지 않도록 구조 자체를 바꾸는 데까지 가야 합니다. 누가 대응하더라도 같은 수준의 결과가 나올 수 있는 체계를 만드는 게 목표입니다.”
5분간 150만 건 몰려도…다른 사이트 영향 없었다
이 같은 대응 방식은 실제 트래픽이 몰리는 순간에 효과를 드러냈다. 지난 9월 7일 오후 2시 인천마라톤 참가 신청이 시작되자 첫 5분간 약 150만 건, 순간적으로 초당 5,000건 이상의 요청이 몰렸다. 트래픽 증가에 맞춰 서버는 10대에서 60대까지 자동으로 늘어났다.
서버가 자동으로 늘어난 뒤 인프라팀은 전체 서비스의 상태도 함께 살폈다. 대규모 트래픽이 몰리는 동안에도 다른 고객 사이트의 서비스 지표에는 유의미한 변화가 나타나지 않았다. 김 리드는 “인천마라톤 외의 사이트들도 평소와 다름없이 운영되는 걸 확인했을 때, 준비했던 구조가 제대로 작동하고 있다는 걸 알 수 있었습니다”라고 말했다.
상품 판매가 집중되는 상황에서도 마찬가지였다. 지난 2월 한 고객사의 공동구매에는 한 시간 동안 640만 건 이상의 요청이 몰렸고, 순간적으로는 초당 약 1만7,000건까지 치솟았다. 오픈 후 25분 동안 약 1만2,000건의 주문이 이어지며 상품은 매진됐지만, 해당 사이트의 서비스는 중단되지 않았고 다른 고객 사이트에도 영향을 미치지 않았다.
개별 사례뿐 아니라 전체 서비스의 지표도 달라졌다. 서비스 요청이 정상적으로 처리된 비율을 뜻하는 ‘가용성’은 2025년 4분기 99.971%에서 올해 3분기 99.9985%로 높아졌다. 소수점 아래의 작은 차이처럼 보이지만, 정상 처리되지 않은 요청의 비율은 약 95% 줄었다. 100만 건의 요청으로 환산하면 약 290건에서 15건으로 줄어든 셈이다.
“무소식이 희소식”…고객이 인프라를 의식하지 않는 상태
아임웹은 현재의 안정성 지표를 유지하는 데서 그치지 않고, 문제가 발생할 가능성을 앞단에서 줄이는 작업도 이어가고 있다. 최근에는 고객사별 트래픽 상황에 따라 대기열 작동 기준과 입장 속도를 개별적으로 조정할 수 있도록 시스템을 개선하고, 지난 12일부터 모든 고객사에 적용했다. 이와 함께 기존 인프라를 쿠버네티스(Kubernetes) 환경으로 전환해 서버 운영 방식을 통합하고, 실제 서비스에 적용하기 전 충분히 검증할 수 있도록 스테이징 환경도 고도화하고 있다.
“안정성은 하루아침에 만들어지는 게 아닙니다. 문제를 하나씩 발견하고 개선하면서 쌓이는 거죠.”
결국 목표는 고객이 이런 과정 자체를 알 필요가 없는 상태다. 서버가 어떻게 확장되고, 트래픽이 어디로 분리되는지 의식하지 않은 채 사이트를 운영할 수 있어야 한다는 의미다.
“저희 팀에서는 ‘인프라는 무소식이 희소식’이라는 말을 자주 합니다. 고객이 서버가 몇 대인지, 트래픽이 어떻게 흐르는지 알 필요가 없어야 해요. 사이트를 운영하면서 인프라를 의식하지 않아도 되는 상태, 그게 저희가 생각하는 안정성입니다”
황지혜 기자 jhhwang@segye.com