date
slug
author
status
tags(최대 3개)
summary
type
thumbnail
category
updatedAt
들어가며
지난 6월 오전 10시, 한 고객사가 가수 앨범 예약판매를 열었습니다. 웹 서버 앞 로드밸런서(ALB)로 들어온 요청이 오픈 1시간 전 초당 60건 남짓에서 오픈 직후 초당 4,723건으로 뛰었습니다. 약 80배입니다.
이 예약판매가 열린 날 하루 매출은 약 8억 원이었습니다. 오픈 전후 1시간 반 동안 들어온 요청 123만 건 가운데 서버 오류(5xx)는 0건이었습니다.
그날 인프라팀은 슬랙에 이모지를 두 번 누른 것이 전부였습니다. 서버를 늘릴 때와 줄일 때 한 번씩 눌렀습니다. 트래픽을 전용 서버로 옮기고, 몇 대가 필요한지 계산하고, 끝난 뒤 되돌리는 일은 시스템이 했습니다.
이 시스템은 원래 이벤트 때 서버가 터질까 봐 인프라팀이 만든 내부 도구였습니다. 수개월에 걸쳐 고쳐 쓰다가 올해 7월, 프리미엄 상품 ‘아임터보(imturbo)’에 들어가 고객이 직접 예약해서 쓰는 기능이 됐습니다.
이벤트가 왜 플랫폼 전체를 흔들었는지, 그 고리를 어떻게 끊었는지, 반복되는 대응을 어떻게 시스템에 맡겼는지, 그리고 어떻게 상품화 했는지 다룹니다.
공유 서버 구조와 수동 대응
100만 사이트가 서버를 나눠 쓴다는 것
인프라 관점에서 아임웹은 자기 도메인을 연결한 100만 개의 사이트가 같은 플랫폼 위에서 돌아가는 구조입니다. 약 8만 개의 CloudFront 배포가 그 사이트들을 서빙하고, 하루 약 6억 3천만 건(초당 평균 약 7,300건)의 요청이 들어옵니다.
이 중 약 20%는 웹 방화벽이 공격이나 비정상 요청으로 걸러 내고, 나머지 약 5억 건이 서비스로 이어집니다. 그 뒤의 웹 서버는 고객사 등급에 따라 몇 개의 풀로 나뉘어 있고, 한 풀 안에서는 여러 고객사가 같은 서버를 씁니다.
이 구조에서 이벤트는 다른 고객사까지 영향을 끼칩니다. 어느 쇼핑몰이 할인 이벤트를 열어 트래픽이 몰리면 같은 풀에 있는 다른 고객사도 느려집니다. 한때 인프라팀의 목표가 "장애를 10분 안에 인지하고 대응하자"였을 만큼 장애가 잦았고, 이벤트는 그중 하나였습니다. 작년 하반기에는 한 고객사의 이벤트가 같은 풀의 다른 고객사들을 느리게 했습니다. 팀 안에서 이런 말이 나왔습니다.
모니터링 요청을 받을수록 시스템이 불안해지는 아이러니.
고객사가 이벤트를 미리 알려 주면 좋은 일이어야 합니다. 그런데 요청이 들어올수록 플랫폼 전체가 불안해졌습니다.
결국 사람이 대응하는 구조
이벤트 대응 기능은 사내 관리 도구에 이미 있었습니다. 다만 서버를 예약해 두면 이벤트가 끝나도 원복이 안 되는 식의 버그가 많아, 결국 사람이 직접 늘리고 줄였습니다. 몇 대를 늘릴지도 고객사의 트래픽을 본 게 아니라 "이벤트니까 이만큼"이라는 일괄 대응이었고, 요청이 들어오는 길도 제각각이었습니다.
안정성과 이벤트를 떼어 내기
유일한 정보는 이벤트 시작 시간
장애는 언제 발생할지 모르지만, 이벤트는 시작 시각이 정해져 있습니다. 당시 쓰던 지표 기반 오토스케일링은 트래픽이 몰린 뒤에야 움직였지만, 시작 시각을 알면 사전에 늘려 둘 수 있습니다. 그래서 장애 전체가 아니라 이벤트부터 고치기로 하고 방향 세 가지를 정했습니다.
- 요청 창구를 하나로 모으기: 이벤트 요청이 한 곳에 같은 모양으로 쌓여야 자동화가 시작됩니다.
- 이벤트 전용 공간을 분리하기: 이벤트 고객사를 전용 웹 서버 풀로 옮기면, 폭주가 옆 고객사의 웹 서버로 번지는 경로가 끊깁니다.
- 감이 아니라 데이터로 판단하기: 고객사가 지난 이벤트에서 실제로 얼마나 썼는지를 기준으로 삼습니다.
이벤트 고객사를 별도 풀로 옮기기
이벤트 전용 웹 서버 풀을 따로 두고, 이벤트 시작 1시간 전에 그 고객사의 CloudFront 배포가 바라보는 원본(origin)을 전용 풀의 로드밸런서로 바꿉니다. 고객 도메인은 그대로이고 트래픽이 도착하는 서버만 바뀝니다. 끝나고 1시간 뒤에는 원래 풀로 되돌립니다.
서버 앞에서는 이전부터 운영하던 대기열이 함께 일합니다. 한꺼번에 몰린 접속을 순서대로 들여보내, 서버가 받을 수 있는 만큼만 넘기는 장치입니다. 이 구조가 2025년 12월에 돌기 시작했고, 당시 전사 공지 제목이 "수동 대응은 이제 그만"이었습니다. 이때부터 이벤트 고객사는 일반 고객사와 다른 웹 서버에서 처리됩니다.
그전에는 이벤트가 있으면 고객사도 서버가 버틸지 마음을 졸여야 했습니다. 전용 풀로 옮긴 뒤로는 "안정적으로 잘 진행됐다"는 감사 인사가 돌아오기 시작했습니다.
예약 뒤의 일을 시스템에게 맡기기
요청 한 건이 들어오는 순서
운영팀이 슬랙 워크플로우로 이벤트를 신청하면 Jira 티켓이 자동으로 생깁니다. 이 티켓이 접수된 일정의 원본입니다. 시스템이 5분마다 티켓을 읽어 DynamoDB의 이벤트 목록에 반영하고, 시작이나 종료 시각이 바뀌면 그 변경도 함께 반영합니다.
매일 밤 12시에는 "오늘의 이벤트" 메시지가 슬랙에 올라갑니다. CX, 커머스, 인프라가 같은 스레드에서 준비합니다. 다음부터는 예약 시각에 맞춰 시스템이 옮기고 돌려놓습니다. 예약만 해 두면 원복이 되지 않던 옛 도구와 가장 다른 점입니다.
두 개의 작업, 하나의 목록
라우팅 작업은 Lambda가 맡아 전용 풀로 옮기고 되돌립니다. 용량 작업은 Kubernetes CronJob이 맡아 목표 대수 계산과 증설·감설 카드, 회고를 처리합니다. 둘은 같은 이벤트 목록만 읽고 자기 몫을 처리한 뒤 상태를 기록하며, 서로를 직접 부르지 않습니다. 라우팅 전환이 실패해도 증설 카드는 떠야 하고, 증설이 보류돼도 전환은 되어야 하기 때문입니다. 나중에 고객 예약을 이 목록으로 받을 수 있었던 것도 이 구조 덕분입니다.
서버 대수에 대한 고민
가장 오래 붙잡은 질문은 "전용 풀에 몇 대를 둘까"였습니다. 전환과 원복은 한 번 만들면 그대로 돌았는데, 서버 대수는 여러 차례 업그레이드했습니다. 처음에는 당번 담당자가 과거 지표를 눈으로 보고 정했고, 4월부터는 사내 에이전트에게 맡겼습니다. 참고할 지표를 개선하던 때라, 코드보다 프롬프트를 고치는 쪽이 빨랐습니다.
추천이 틀릴 때마다 먼저 정했어야 할 기준이 하나씩 드러났습니다. 넓은 시간 창의 평균은 피크를 2배에서 3.5배까지 희석해서 "가장 바쁜 5분"이 기준이 됐고, 대량 발송을 앞둔 고객사가 11대로 나온 뒤로 최소 보장 대수가 생겼습니다.
가장 오차가 컸던 것은 "서버 한 대가 초당 80건을 처리한다"는 가정이었습니다. 80건은 nginx가 HTTP를 받는 속도였고, 실제 병목은 요청을 처리하는 PHP-FPM 워커(PHP 코드를 실행하는 프로세스)였습니다. 서버당 워커 30개가 페이지 하나에 0.1초에서 2초씩 붙잡히니, 한 대가 안전하게 받는 양은 초당 12건 안팎이었습니다. 7배 차이입니다.
지금은 풀 전체 워커 점유, 가장 바쁜 서버의 포화도, 초당 요청 수로 각각 필요한 대수를 구하고 그중 가장 큰 값을 씁니다. 과거에 운영자가 둔 대수는 버리지 않고 산정 결과 옆에 참고값으로 보여 주되, 계산에는 넣지 않습니다. 그대로 넣으면 그때 넉넉히 잡았던 대수까지 물려받기 때문입니다.
회고로 다음 스텝 산정하기
기준을 정해도 지난 기록을 읽지 못하면 소용이 없었습니다. 당시 사내 에이전트가 데이터독을 조회하던 경로로는 보름이 지나면 기록을 꺼낼 수 없었고, 근거가 없으면 산정은 "최소 10대"로 떨어졌습니다. 4대면 충분한 고객사에 10대를 추천하기도 했습니다.
그래서 이벤트가 끝나면 시스템이 회고를 쓰게 했습니다. 다음날 새벽, 이벤트 앞뒤 구간을 5분 단위로 잘라 접속, 응답 시간, 서버 대수, 대기열, 주문, 매출 등 12개 지표를 모아 노션과 슬랙에 올리고, 6월 초부터는 데이터브릭스에 쌓습니다. 글 첫머리의 8억도 이 회고에서 나온 숫자입니다.
같은 고객사가 다시 이벤트를 열면 산정이 회고 기록을 읽습니다. 처음 오는 고객사는 넉넉한 최소 보장 대수로 받고, 다시 올수록 자기 기록으로 계산한 대수가 더 큰 몫을 합니다. 산정 기록이 남은 이벤트의 약 66%가 이력이 3회 미만인 고객사였으니, 이 차이가 중요했습니다.
기준이 정해지자 추론보다 계산에 가까워집니다. 6월 말에 사내 에이전트를 호출하던 자리를 CronJob이 대신했고, 현재 기준으로 공식 버전은 v17입니다. 고객이 예약한 이벤트도 담당자 판단 없이 대수가 나와야 했기에, 같은 입력에 같은 답이 나오고 틀리면 어느 줄이 틀렸는지 찾을 수 있는 쪽을 골랐습니다. AI는 지금도 Jira 티켓에서 예상 방문자나 대량 발송 같은 위험 신호를 읽고, 결과에 설명을 붙입니다. 최종 대수는 코드가 정합니다.
슬랙 카드 한 장, 이모지 한 번
늘리는 순간은 이렇습니다. 시작 30분 전 슬랙에 카드가 뜹니다.
A 고객사, 45대 준비할까요?
카드가 뜨기 전에 시스템이 세 가지를 먼저 확인합니다. 서버 그룹의 상한 여력, 서브넷에 남은 IP, DB 연결 수의 여유. 하나라도 부족하면 카드 대신 경고가 뜹니다.
승인은 이모지 하나입니다. 카드에
:scale-out:이 붙으면 서버가 늘어납니다. 9월 중순까지는 담당자가 눌렀고, 이후로는 사전 점검을 통과한 카드에 봇이 대신합니다. 봇 승인에 실패하면 사람이 누르고, 누가 승인했는지 카드에 기록합니다. 감설 카드는 아직 사람이 누릅니다.줄일 때는 한 번에 끄지 않습니다. 서버 그룹의 최소 용량 설정만 원래 값으로 내리고, 실제 대수는 손님이 빠지는 만큼 오토스케일링이 천천히 줄입니다. 같은 풀에 다른 이벤트가 진행 중이면 감설 승인은 막습니다.
사람이 하는 일도 그만큼 줄었습니다. 상반기에는 이벤트 두 건 중 한 건꼴로 팀 채널에서 그 고객사를 두고 대수와 일정을 논의했습니다(1~5월 140건 중 69건). 대수 계산과 증설을 시스템이 맡은 7월 이후에는 다섯 건 중 한 건으로 줄었고(71건 중 14건), 봇이 증설을 승인하기 시작한 9월 중순부터는 증설 대수를 정하고 승인하는 일에 사람이 한 번도 끼지 않았습니다.
내부 도구를 상품화 하기
내부 도구였던 이 시스템을 *아임터보에 결합했습니다.
*아임터보
고객사의 트래픽이 몰릴 때도 사이트가 버티도록 대신 관리해주는 아임웹의 유료 부가서비스
처음에는 운영팀이 슬랙으로 넣던 이벤트 일정을, 이제는 고객이 관리자 화면에서 직접 설정합니다. 뒤에서 대응은 같지만 그 대응의 주체가 달라졌습니다. 고객은 슬랙도, 담당자도 거치지 않습니다. 관리자 화면에 이벤트 날짜와 시간만 설정하면 그 시각에 맞춰 전용 풀 전환, 증설, 원복, 회고까지 해결합니다.
아임터보에 결합할 수 있었던 건 앞에서 만든 두 가지 덕분입니다. 고객 예약도 같은 이벤트 목록으로 받아, 전환부터 회고까지 뒤의 흐름을 그대로 재사용했습니다. 그리고 준비와 원복은 이미 시스템 몫이었습니다. 담당자가 매번 시각을 챙겨야 했다면 고객에게 열어 줄 수 없었습니다.
그 뒤로도 손은 계속 덜어 냈습니다. 9월부터는 증설 승인을 봇이 맡고, 10월부터는 승인 한 번에 웹 서버와 주문 서비스가 함께 늘고 함께 줄어듭니다.
지난 10개월을 돌아보며
작년 12월 자동 전환을 시작해 고객에게 예약을 열기까지, 이번 달 중순 기준으로 쌓인 결과입니다.
가장 크게 배운 것은 AI가 똑똑해지는 속도가 결국 운영 데이터가 쌓이는 속도라는 사실입니다. 사내 에이전트가 대수를 정하던 2분기까지, 추천이 틀린 날에는 늘 근거로 삼을 기록이 부족했습니다. 그래서 틀릴 때마다 기준을 하나씩 세우고, 이벤트가 끝날 때마다 회고를 쌓았습니다.
회고로 다음 산정을 고치고, 고친 산정이 다시 기록을 남깁니다. 운영하며 데이터가 늘고 판단이 정교해지는 것이 가장 큰 이점입니다. 고객에게 예약을 열어 준 뒤에도 버틸 수 있었던 이유이기도 합니다.
물론 개선할 여지도 많습니다.
- 대수 판단을 다시 AI에게 맡기는 재도전: 이제는 쌓인 회고 기록이 있으니, 그 데이터를 근거로 AI가 대수까지 정하고 그 결과가 다시 다음 판단의 근거가 되게 하려 합니다.
- 겹치는 이벤트의 총량 계산: 같은 시간대에 여러 이벤트가 겹칠 때 고객사별 산정을 더하는 게 아니라, 전용 풀 전체의 총량으로 계산해야 합니다. 사내 에이전트가 틀렸던 날 중 아직 못 푼 하나입니다.
- 비용과 매출을 함께 보는 주간 리포트: 이벤트 대응에 든 서버 비용과 그 이벤트의 매출을 나란히 놓고 봅니다.
- 주문 서비스 쪽 개선은 별도 글에서 다룰 예정입니다.
개인적으로는 감회가 남다릅니다. 반복되는 일을 보면 자동화부터 떠올리는 편인데, 그렇게 만든 자동화가 고객이 돈을 내고 쓰는 기능이 된 건 이번이 처음입니다. 앞으로도 상품으로 만나는 서비스가 된 만큼 품질을 더 챙기려고 합니다.
이승민A SRE Engineer
손이 떨리는 겁쟁이 SRE입니다. 끝없는 자동화를 추구합니다.