한 줄 요약
1년 중 수능 끝난 17시 한 시점에 접속이 몰립니다. 그 한 시간을 위해 나머지 364일의 서버를 준비합니다
몰리는 시점
수능 종료 직후 17시
가채점 기능
평소 서버 이용률
21%
평시 사용량은 20
그래서 문제는
평균이 아니라 봉우리
평균만 보면 서버가 남아 보입니다
그래서 무엇을 하는가
검수를 자동으로
수만 개의 강의·교재 정보를 손으로 보지 않고 규칙으로 걸러냅니다
봉우리를 나눠 받는다
한 시점에 몰리는 접속을 대기열과 단계 개방으로 흩어 놓습니다
불만을 재현 순서로 옮긴다
'렉 걸려요'를 개발팀이 바로 따라 해 볼 수 있는 단계로 바꿔 적습니다
에듀테크의 시즌성 트래픽과 데이터 무결성을
게임 운영 방식으로 관리합니다.
데이터와 라이브 관제 경험을 바탕으로 한 문제 해결 전략을 아래 인터랙티브 데모를 통해 확인하실 수 있습니다.
👇
서비스 특성
인터넷 강의와 교재를 판매하는 앱은 트래픽이 연중 특정 일자에 집중됩니다.
대표적으로 수능 종료 직후인 17시에 가채점 기능으로 동시 접속이 몰립니다.
이 피크 구간의 트래픽을 어떻게 방어할지,
그리고 강의·교재 데이터 검수와 앱 리뷰 처리를 어떻게 자동화할지 다룹니다.
💡 전략 1. 수작업 데이터 검수 자동화
수만 개의 인강·교재 메타데이터 검수를 엑셀 함수 기반 파이프라인으로 처리해 소요 시간을 줄입니다.
자동화 체크리스트
- ✔️ VOD - 교재 코드 일치 여부 확인
- ✔️ 수강기간(음수) 오류 검출
- ✔️ 결측치 실시간 하이라이팅
💡 전략 2. 수능 당일 골든타임 트래픽 방어
시험 종료(17:00) 후 가채점 서비스에 몰리는 동시접속 트래픽. 서버 장애를 어떻게 막을까요?
💡 전략 3. 고객 VOC를 개발 요건(Jira)으로 번역
학생들의 감정적인 불편사항을 개발팀이 즉각 이해할 수 있는 '재현 스텝'으로 번역합니다.
"1.5배속 누르면 갑자기 멈추고 렉 걸려요.
ㅠㅠ"
"메인 화면 배너 누르면 자꾸 흰 화면만 떠요."
"결제하기 버튼이 키보드에 가려서 안 보여요 ㅡㅡ"
좌측의 유저 리뷰 카드를 클릭하면 개발팀 언어로 번역된 요건을 확인하실 수 있습니다.
타이틀
시나리오를 용량 기준으로 다시 보면
전략 2의 시뮬레이션에는 서버 용량선이 함께 그려져 있습니다.
시간대별 값을 용량 초과분으로 환산하면 완화안이 무엇을 해결하고 무엇을 남기는지 보입니다.
| 시각 | 평시 | 폭주 | 완화 후 | 용량 80 대비 |
|---|---|---|---|---|
| 15:00 | 10 | 12 | 12 | — |
| 16:00 | 12 | 15 | 15 | — |
| 16:40 | 15 | 30 | 30 | — |
| 17:00 | 20 | 95 | 75 | 초과 +15 |
| 17:30 | 18 | 85 | 50 | 초과 +5 |
| 18:00 | 15 | 40 | 30 | — |
| 19:00 | 12 | 20 | 15 | — |
피크 배수
4.75배
평시 20 → 폭주 95
완화 후 남은 여유
6.2%
75 대 용량 80
상시 증설 시 이용률
21.1%
평시 20 / 용량 95
증설이 아니라 우회를 택한 것이 맞는 판단입니다
폭주 피크를 감당하려면 상시 용량을 95 이상으로 두어야 합니다.
그런데 평시 사용량은 20이므로 이용률이 21%에 그칩니다.
1년 중 하루를 위해 평상시 8할을 비워두는 인프라를 유지하는 셈입니다.
그래서 가벼운 텍스트 뷰로 트래픽을 우회하는 접근이 합리적입니다.
용량을 늘리는 대신 한 요청의 무게를 줄이는 방향이고,
시즌성 스파이크가 뚜렷한 서비스에서 비용 효율이 훨씬 높습니다.
다만 완화안에 두 가지가 남습니다
여유가 6.2%뿐입니다
완화 후 피크 75는 용량 80에 대해 여유가 5입니다.
트래픽 예측이 조금만 틀리거나 응시 인원이 예년보다 많으면 다시 초과합니다.
전환 시점을 피크 도달 후가 아니라 사전으로 옮기는 편이 안전합니다.
16:40의 30 시점에서 이미 평시의 2배이므로, 이때 전환을 시작하면 피크를 더 낮출 수 있습니다.
17시 30분도 초과 구간입니다
폭주 시나리오에서 17:30의 값은 85로 용량을 초과합니다.
17시 피크만 보면 놓치기 쉬운 지점입니다.
완화안은 이 시점을 50까지 낮추므로 실제로 두 구간을 함께 처리하는데, 전환 유지 시간을 명시하지 않으면 17시만 넘기고 되돌릴 위험이 있습니다.
정상 UI 복귀는 값이 용량의 절반 아래로 내려온 뒤로 정해두는 편이 안전합니다.
자동화와 VOC 번역에서 남는 부분
검수 자동화는 규칙으로 잡히는 것만 걸러냅니다
주당 소요
40 → 10시간
75% 절감
연 환산
약 1,560시간
52주 기준 산술값
남는 10시간
사람의 판단
규칙 밖의 오류
체크리스트의 세 항목은 자동화에 적합한 형태입니다.
코드 일치 여부, 음수 값, 결측치는 모두 참과 거짓이 명확해 규칙으로 판정할 수 있고 오탐 위험이 낮습니다. 이런 항목을 고른 것이 이 자동화가 실제로 작동하는 이유입니다.
규칙으로 잡히지 않는 오류
- • 내용이 맞지 않는 연결 — 코드는 일치하지만 강의와 교재의 단원이 다른 경우. 형식 검증을 통과합니다
- • 값은 유효하지만 틀린 값 — 수강기간이 음수는 아니지만 상품 정책과 다른 경우
- • 누락되지 않은 오기재 — 칸이 채워져 있으나 내용이 잘못된 경우. 결측치 탐지로는 잡히지 않습니다
남는 10시간은 이 영역을 보는 시간으로 정의해두면 좋습니다.
자동화의 목표를 0시간으로 잡으면 규칙 밖 오류가 무검수로 남습니다.
절감의 상한을 명시하는 것이 자동화 제안의 신뢰도를 높입니다.
VOC 번역이 규모에서 작동하려면
감정적 표현을 재현 스텝으로 옮기는 접근은 개발팀 소통에서 효과가 분명합니다.
다만 데모의 세 건과 달리 실제 리뷰는 대량으로 들어옵니다.
규모에서 작동하려면 두 가지가 필요합니다.
번역 전에 분류가 필요합니다
모든 리뷰를 재현 스텝으로 옮길 수는 없습니다.
같은 증상의 반복 건수를 먼저 세어 다수 건부터 처리하면 한 건을 번역하는 노력이 여러 유저의 문제를 해결합니다.
단건 리뷰는 재현 가능성도 낮습니다.
재현에 필요한 정보가 리뷰에 없습니다
데모의 리뷰에는 기기 정보가 있지만,
실제로는 앱 버전과 발생 시점, 네트워크 환경이 빠져 있는 경우가 대부분입니다.
재현 스텝을 쓰려면 이 정보가 있어야 하므로, 앱 내 문의 경로에서 환경 정보를 자동 첨부하는 설계가 함께 가야 합니다.
스토어 리뷰의 제약: 스토어 리뷰는 되묻기가 어렵습니다.
추가 정보가 필요하면 답글로 앱 내 문의를 안내하는 동선이 필요하고, 이 과정에서 상당수가 이탈합니다. 따라서 스토어 리뷰는 증상 빈도를 파악하는 용도로,
재현 스텝 작성은 앱 내 문의 건을 기반으로 하는 편이 현실적입니다.
완화 곡선에서 70이 어디로 갔는지
앞에서 용량 초과분을 봤습니다.
이번에는 곡선 아래 총량과 시간대별 감소율을 보면 완화안이 무엇을 한 것인지가 더 분명해집니다.
| 시각 | 폭주 | 완화 후 | 감소율 | 구간 |
|---|---|---|---|---|
| 15:00 | 12 | 12 | 0% | 배포 전 |
| 16:00 | 15 | 15 | 0% | 배포 전 |
| 16:40 | 30 | 30 | 0% | 배포 전 |
| 17:00 | 95 | 75 | 21.1% | 시험 종료 |
| 17:30 | 85 | 50 | 41.2% | 감소폭 최대 |
| 18:00 | 40 | 30 | 25.0% | 25%로 수렴 |
| 19:00 | 20 | 15 | 25.0% | 25%로 수렴 |
폭주 총량
297
평시 102의 2.91배
완화 후 총량
227
평시의 2.23배
사라진 양
70
전체의 23.6%
세로축이 사람 수인지 서버 부하인지에 따라 뜻이 갈립니다
완화 수단은 무거운 동적 화면 대신 텍스트 기반 가채점 페이지로 우회하는 것입니다.
경량 페이지로 바꿔도 서비스에 들어오는 사람 수는 줄지 않습니다.
줄어드는 것은 요청당 서버가 하는 일입니다.
그런데 전략 설명은 이 값을 동시접속 트래픽이라고 부릅니다.
사람 수라면
70만큼이 서비스를 쓰지 못한 것이 됩니다.
수능 당일 가채점은 대체재가 있으므로, 못 들어온 유저는 다른 서비스로 갑니다.
장애는 막았지만 이용자는 잃은 결과입니다.
서버 부하라면
같은 사람이 가벼운 화면으로 서비스를 받은 것입니다.
아무도 잃지 않고 부하만 23.6% 줄였다는 뜻이므로 제안이 훨씬 강해집니다.
제안의 성격상 후자가 의도일 것입니다.
축 이름을 서버 부하로 적고 동시접속자 수는 폭주와 완화에서 같다는 점을 한 줄 덧붙이면, 같은 그래프가 이용자를 지키면서 장애를 막았다는 뜻이 됩니다.
지금 표기로는 읽는 사람이 반대로 해석할 여지가 남습니다.
감소율이 25%로 수렴하는 것이 경량 페이지의 실력입니다
시간대별 감소율이 0, 21.1, 41.2, 25.0, 25.0%입니다.
후반 두 구간이 정확히 25%로 같습니다.
상황이 안정된 뒤의 값이므로 이것이 경량 페이지가 실제로 줄이는 부하 비율로 읽힙니다.
17시의 21.1%는 왜 낮은가
전환이 막 시작된 시점이라 일부 이용자만 경량 화면을 받은 것으로 볼 수 있습니다.
가장 위험한 순간에 효과가 가장 약한 셈입니다.
17시 30분의 41.2%는 왜 높은가
전환이 완료된 데다 밀려 있던 요청이 함께 빠지는 구간이 겹친 것으로 보입니다.
일시적인 값이므로 성과로 제시할 때는 25%를 쓰는 편이 안전합니다.
이 이벤트는 사후 대응이 아니라 사전 배포가 가능합니다
시뮬레이션은 장애 위험을 감지한 뒤 비상용 웹뷰를 배포하는 순서로 그려져 있습니다.
그런데 수능 종료 시각은 몇 달 전에 공지되는 확정 일정입니다.
폭주 시점을 정확히 아는데 감지를 기다릴 이유가 없습니다.
17시 구간의 감소율이 21.1%에 그친 것도 전환이 그때 시작되기 때문입니다.
종료 30분 전에 경량 모드로 미리 전환해 두면 가장 위험한 17시 구간부터 25%가 적용됩니다.
95가 아니라 처음부터 71 수준으로 들어가므로 용량선에 훨씬 여유가 생깁니다.
사후 대응으로 그린 것이 제안을 낮춰 보이게 합니다
감지 후 대응은 언제 일어날지 모르는 장애에 쓰는 방식입니다.
시각이 정해진 이벤트에는 사전 전환이 맞고, 실행 난이도도 더 낮습니다.
버튼 순서를 사전 전환과 비상 대응 두 가지로 나눠 보여주면 운영 계획을 세울 줄 안다는 점이 함께 전달됩니다. 감지 대응은 예측하지 못한 다른 폭주를 위한 두 번째 장치로 남겨둡니다.
티켓 세 건이 서로 다른 세 조직으로 갑니다
전략 3의 예시 티켓은 세 건입니다. 담당 영역이 모두 다릅니다.
| 유형 | 내용 | 우선순위 | 담당 |
|---|---|---|---|
| 버그 | 배속 터치 시 프리징 | 높음 | 클라이언트 |
| 버그 | 배너 클릭 시 빈 화면 | 보통 | 웹 앱 개발 |
| 사용성 | 결제 버튼이 키보드에 가려짐 | 보통 | 사용성 · 프론트엔드 |
결제가 막히는 건이 보통으로 잡혀 있습니다
배속 터치 프리징은 높음, 결제 버튼이 가려지는 건은 보통입니다.
프리징은 사용 불편이고 결제 차단은 매출이 발생하지 않는 상태입니다.
어느 쪽이 급한지는 기준에 따라 갈리는데, 그 기준이 문서에 없습니다.
영향 범위로 볼지 매출 영향으로 볼지 복구 난이도로 볼지를 정해두지 않으면 번역은 되지만 순서는 담당자마다 달라집니다.
번역 다음은 분류 규칙입니다. 세 건이 세 조직으로 흩어지므로 어디로 보낼지와 어느 순서로 처리할지를 티켓 양식에 미리 넣어야 실제로 돌아갑니다.
전략 3의 재현 스텝은 개발팀이 바로 착수하게 해주지만, 어느 개발팀인지는 아직 사람이 판단합니다. 유형과 화면 위치로 담당을 자동 배정하면 전략 1의 자동화와 같은 성격이 됩니다.
이 절의 한계
- • 트래픽 수치는 대응 흐름을 보여주기 위한 시뮬레이션 값입니다. 총량과 감소율은 그 값을 그대로 계산한 것이며 실제 접속 데이터가 아닙니다.
- • 25%를 경량 페이지의 절감률로 읽은 것은 후반 두 구간이 같은 값이라는 관찰에 근거합니다. 문서가 그렇게 설계했다고 밝힌 것은 아닙니다.
- • 17시 30분의 41.2%를 대기 요청 해소로 본 것은 가능한 해석 중 하나이며 확인된 원인이 아닙니다.
- • 예시 티켓은 세 건뿐입니다. 우선순위 기준의 문제를 지적했지만,
실제 티켓 분포에서 같은 문제가 얼마나 자주 생기는지는 이 자료로 알 수 없습니다.
측정할 지표와 이 기록의 한계
측정할 지표
- • 피크 시점 최대 동시접속과 응답 시간 — 완화 전환 후에도 용량 대비 여유가 유지되는지
- • 전환 시점과 복귀 시점 — 사전 전환이 실제로 피크를 낮추는지 확인합니다
- • 검수 오류 유출 건수 — 자동화 통과 후 운영 중 발견된 데이터 오류. 절감 시간과 함께 봅니다
- • 증상별 리뷰 건수 — 같은 문제의 반복 규모. VOC 처리 우선순위의 근거입니다
- • 재현 성공률 — 작성한 재현 스텝으로 개발팀이 실제 재현한 비율
이 기록의 한계
- • 트래픽 수치는 시뮬레이션 값이며 실제 서버 지표가 아닙니다. 용량 80이라는 기준선도 상대값입니다.
- • 주당 40시간에서 10시간은 자동화 전후 비교 추정값입니다. 데이터 규모와 상태에 따라 달라집니다.
- • 연 1,560시간은 52주를 곱한 산술 결과이며 검수 물량이 연중 균등하다는 가정입니다. 시즌성이 있다면 실제 절감은 다릅니다.
- • 웹뷰 전환의 개발 공수와 사전 배포 준비는 다루지 않았습니다. 비상용 뷰는 미리 만들어 두어야 당일에 쓸 수 있습니다.
- • 리뷰 예시는 구조를 보여주기 위한 재구성이며 실제 접수 문안이 아닙니다.