LMS 부하 테스트, 동시접속 1만 명을 버티는 법 — EBS부터 줌까지

2020년 4월 9일 오전 9시, 한국의 온라인 개학 첫날이었다. 전국의 학생들이 EBS 온라인클래스에 동시에 로그인했고, 화면은 75분 동안 멈췄다. 나흘 뒤인 4월 13일에는 26만 7,180명이 다시 접속 오류를 겪었다. 원인은 서버 성능 부족이 아니라, 트래픽 급증에 대비해 설치한 보안 장치가 오히려 병목을 만든 것이었다. 6년이 지난 2026년 5월에도 비슷한 장면이 반복됐다 — 이번엔 한국이 아니라 미국이었다. 해킹 그룹 셔니헌터스(ShinyHunters)가 대학 LMS 캔버스(Canvas)를 마비시키면서 하버드·펜실베이니아대·듀크대 등 9,000여 개 교육기관이 기말고사 기간에 접속 장애를 겪었다. 이러닝 플랫폼에게 "동시접속 1만 명을 버티는 능력"은 더 이상 선택이 아니라 서비스 존속의 문제가 됐다.

🕰️ 온라인 학습 시스템이 멈췄던 순간들 — 배경과 타임라인

이러닝 플랫폼의 트래픽 폭주 문제는 새로운 게 아니다. 대학 수강신청 시즌마다 서버가 먹통이 되는 건 한국에서 명절 기차표 예매·대입 원서 접수와 함께 오래된 "연례행사"로 꼽혀왔다. 다만 코로나19 팬데믹은 이 문제의 규모를 완전히 바꿔놨다. 2020년 3월 23일 EBS는 온라인 개학에 대비해 '2주 라이브 특강'을 편성했는데, 오전 9시 생방송 시작 직후 접속자가 몰리며 서버가 폭주해 화면이 검게 변했다. 이후 4월 9일 온라인 개학 첫날에도, 4월 13~14일에도 유사한 장애가 반복됐다. 교육부는 트래픽 증가에 대비해 넣은 외부 보안 장치가 오히려 병목현상을 일으켰다고 설명했는데, 이는 "장비를 더 넣는다고 안정성이 저절로 확보되지는 않는다"는 이러닝 인프라의 근본 교훈을 남긴 사례였다.

비슷한 시기 화상회의 플랫폼 줌(Zoom)은 정반대의 길을 걸었다. 2019년 12월 하루 1,000만 명이던 이용자는 2020년 4월 하루 3억 명 규모로 폭증했는데, AWS 엔지니어링팀과 함께 며칠 만에 수천 대의 EC2 인스턴스를 추가 투입하며 서비스를 유지했다. 클라우드 인프라를 미리 설계해둔 기업과 그렇지 않은 기업의 격차가 극명하게 드러난 시기였다. 그리고 2023년에는 한국 초중고 1만 2,000여 개 학교가 쓰는 4세대 나이스(NEIS)에서도 개통 이후 강제 로그아웃 등 장애가 이어져 교육부가 2주간 특별점검반을 꾸렸고, 2025년 9월에는 국가정보자원관리원 화재로 나이스를 포함한 정부 전산망 전체가 마비되는 사고까지 발생했다.

💻 원인 분석 — 왜 이러닝 플랫폼은 유독 트래픽 폭주에 취약한가

이러닝 플랫폼이 다른 웹 서비스보다 트래픽 폭주에 취약한 이유는 접속 패턴 자체에 있다. 쇼핑몰이나 뉴스 사이트는 하루 종일 트래픽이 완만하게 분산되지만, 학교·기업 교육은 "정해진 시각에 전원이 동시 접속"하는 구조다. 개학 첫날 오전 9시, 수강신청 오픈 시각, 사내 필수교육 마감일 같은 특정 시점에 트래픽이 순간적으로 몰린다. 업계에서는 이런 예정된 이벤트조차 평상시 대비 트래픽이 2배에서 25배까지 순식간에 치솟을 수 있다고 본다. 일반적인 오토스케일링·부하 테스트·캐싱 같은 표준 기법만으로는, 트래픽이 서버 증설 속도보다 더 빠르게 밀려드는 이런 순간을 완전히 방어하기 어렵다.

두 번째 원인은 동시 요청의 성격이다. 로그인·영상 스트리밍 시작·퀴즈 제출처럼 데이터베이스 쓰기(write)가 몰리는 구간은 단순 조회보다 훨씬 무겁다. EBS 사례처럼 트래픽을 거르기 위한 보안 장치나 로드밸런서 설정 자체가 병목이 되는 경우도 있다. 세 번째는 조직 구조의 문제다 — 아프리카 보츠와나대학교의 무들(Moodle) 도입 사례에서는 사용자·과목 수가 늘어나는 속도를 IT 부서의 서버 운영 전문성이 따라가지 못해 온라인 시험 자체가 파행을 겪었다. 즉 트래픽 폭주 대응은 순수 기술 문제이기 이전에, 조직이 인프라 전문성에 얼마나 투자하느냐의 문제이기도 하다.

네 번째 원인은 예측의 어려움이다. 쇼핑몰의 블랙프라이데이나 온라인 티켓 예매처럼 날짜가 사전에 공지되는 이벤트조차 실제 접속자 수를 정확히 맞추기 어려운데, 교육 현장은 여기에 변수가 하나 더 붙는다. 개학이나 시험 일정이 재난·정책 변경으로 갑자기 조정되면(코로나19 시기의 반복된 개학 연기가 대표적이다), 미리 세워둔 트래픽 예측 자체가 무의미해진다. 결국 "정확한 숫자를 맞히는 것"보다 "예측이 빗나가도 무너지지 않는 구조를 만드는 것"이 더 현실적인 목표가 된다.

📊 데이터로 보는 숫자 — 목표 동시접속자와 트래픽 배수

부하 테스트를 설계할 때는 감이 아니라 실측 데이터로 목표치를 잡아야 한다는 게 업계의 공통된 조언이다. 예상 피크 동시접속자 수를 기준으로 20~30%의 여유분을 더해 테스트하는 것이 표준 관행으로 꼽힌다. 가령 피크 시 500명 동시접속이 예상된다면 600~650명 규모로 테스트해야 실제 운영 중 여유를 확보할 수 있다는 것이다. 이 기준을 그대로 적용하면, "동시접속 1만 명"을 실제 안정적으로 버티려는 플랫폼은 최소 1만 2천~1만 3천 명 규모로 테스트를 설계해야 한다는 뜻이 된다.

부하 테스트 도구 간 동시성 처리 방식의 차이도 실제 테스트 설계에 큰 영향을 준다. JMeter는 스레드 하나가 실제 운영체제 스레드 하나를 점유하는 구조라 한 대의 테스트 서버가 감당할 수 있는 가상 사용자 수에 한계가 뚜렷하다. 반면 Locust는 이벤트 기반의 그린렛(greenlet) 구조를 써서 동일 사양의 서버 한 대로 JMeter 대비 약 5배 많은 동시 사용자를 시뮬레이션할 수 있다는 평가를 받는다. k6는 Go 언어의 고루틴(goroutine) 기반이라 CI/CD 파이프라인에 통합하기 유리하다는 평가다.

피크 시점의 트래픽 배수 추정치도 참고할 만하다. 업계에서는 예정된 이벤트(신제품 출시·특강 시작 등)라 하더라도 평상시 대비 트래픽이 짧은 시간 안에 2배에서 최대 25배까지 치솟을 수 있다고 본다. 이 범위를 이러닝 상황에 대입하면, 평소 500명이 접속하는 사내교육 플랫폼이라도 필수교육 마감 전날에는 순간적으로 수천 명에서 1만 명 이상까지 몰릴 수 있다는 뜻이다. "평소 트래픽의 몇 배까지 버텨야 하는가"라는 질문에 정답은 없지만, 최소한 이 배수 범위를 염두에 두고 목표치를 설정해야 한다는 것이 공통된 조언이다.

🔍 실패 사례 — EBS 온라인클래스와 국가 전산망 마비

EBS 온라인클래스는 앞서 다룬 대로 2020년 3월 23일, 4월 9일, 4월 13~14일 총 네 차례에 걸쳐 반복적으로 접속 장애를 일으켰다. 특히 4월 9일 장애는 오전 9시부터 10시 15분까지 약 75분간 지속됐는데, 원인이 "서버 자체의 처리 용량 부족"이 아니라 "트래픽 급증에 대응하기 위해 넣은 부가 장치의 병목"이었다는 점이 시사하는 바가 크다. 안정성을 높이려고 추가한 구성 요소가 오히려 전체 시스템의 새로운 취약점이 될 수 있다는 뜻이다.

2025년 9월 발생한 국가정보자원관리원 대전 본원 화재는 성격이 다른, 그러나 더 근본적인 교훈을 남겼다. 온나라시스템·나이스 등 정부 핵심 전산망이 한 곳의 물리적 데이터센터에 지나치게 의존하고 있었다는 사실이 이 화재로 드러났다. 트래픽 폭주가 아니라 단일 시설 장애만으로도 전국 단위의 교육행정 서비스가 통째로 멈출 수 있다는 것이 실증된 셈이다. 앞서 2023년에는 4세대 나이스 개통 이후 강제 로그아웃 현상이 이어져 교육부가 2주간 특별점검반을 구성해야 했다. 세 사례를 관통하는 공통점은 하나다 — 사전 부하 테스트와 다중화(리전 이중화·장애 조치 체계)가 갖춰지지 않은 상태에서 실제 이벤트를 맞이했다는 것이다.

🔍 성공 사례 — 줌의 30배 확장과 대기열 시스템

줌은 정반대의 사례다. 2019년 12월 하루 1,000만 명이던 이용자가 2020년 4월 하루 3억 명 이상으로 늘어나는, 불과 몇 달 만에 30배 폭증하는 상황에서도 서비스 중단 없이 버텨냈다. AWS와의 기존 파트너십 덕분에 필요할 때마다 하루에도 수천 대의 EC2 인스턴스를 투입할 수 있었고, 이후 오라클 클라우드와도 추가 계약을 맺어 하루 7페타바이트 규모의 처리 용량을 확보했다. 미리 클라우드 기반의 탄력적 인프라를 구축해뒀기 때문에 가능한 대응이었다.

한국의 대학 수강신청 시스템들이 최근 몇 년 새 도입한 대기열(waiting room) 시스템도 성공적인 대응 사례로 꼽힌다. 접속자를 메시지 큐라는 대기실에 순서대로 쌓아두고, 서버가 실제로 처리할 수 있는 속도에 맞춰 하나씩 꺼내 처리하는 방식이다. 모든 접속을 즉시 서버로 흘려보내는 대신 "안전하게 소화 가능한 속도로 조절"하는 이 완충 지대 하나만으로, 순간적인 트래픽 폭주가 서버 다운으로 이어지는 것을 막을 수 있다. AWS도 공식 파트너 블로그를 통해 자체 가상 대기실(Virtual Waiting Room) 아키텍처를 별도로 소개할 만큼, 대기열은 이제 표준적인 방어선으로 자리 잡았다.

🧭 전문가 시각 — 안정적 아키텍처를 보는 세 가지 관점

부하 테스트 실무자들은 "확장성은 서버를 더 넣는 문제가 아니라, 설계 초기부터 아키텍처·캐싱·로드밸런싱을 함께 고민해야 하는 문제"라고 강조한다. 서버 대수를 늘리는 것은 대응책의 일부일 뿐, 근본적으로는 요청이 시스템을 통과하는 경로 전체를 설계해야 한다는 관점이다. 이는 EBS 사례에서 "장치를 추가했지만 오히려 병목이 생겼다"는 결과와도 정확히 맞닿아 있다.

클라우드 아키텍처 전문가들은 여기에 한 가지 관점을 더한다 — 표준적인 오토스케일링·부하 테스트·캐싱이 기본이지만, 트래픽이 초 단위로 폭증하는 극단적 상황에서는 이 표준 대응만으로 부족할 수 있다는 것이다. 새로 투입되는 서버가 실제로 요청을 받을 수 있는 상태가 되기까지는 수 초에서 수십 초의 지연(콜드 스타트)이 있는데, 그 사이에도 요청은 계속 밀려든다. 그래서 오토스케일링과 별개로 대기열 같은 "속도 조절" 장치가 함께 필요하다는 의견이 나온다.

세 번째는 조직·거버넌스 관점이다. 보츠와나대학교 무들 사례에서 나타났듯, 아무리 좋은 도구를 도입해도 이를 운영할 내부 전문성이 없으면 트래픽이 늘어나는 속도를 따라잡지 못한다. 결국 세 관점을 종합하면 안정적인 이러닝 인프라의 조건은 ①아키텍처 설계 ②트래픽 속도 조절 장치 ③이를 운영할 조직 역량, 이 세 가지가 함께 갖춰져야 한다는 결론으로 모인다.

세 관점이 흥미롭게 겹치는 지점은 "장애는 기술 부족이 아니라 설계 사각지대에서 온다"는 것이다. EBS 사례의 보안 장치, 국가정보자원관리원 화재의 단일 데이터센터, 보츠와나대학교의 IT 인력 부족은 모두 겉으로는 서버 성능과 무관해 보이는 지점이었지만 실제 장애의 진앙이 됐다. 이는 부하 테스트를 설계할 때 "서버가 몇 명을 버티는가"라는 좁은 질문을 넘어, 로드밸런서·보안 장비·데이터센터 이중화·운영 인력까지 포함한 전체 시스템을 점검해야 한다는 뜻이다.

💡 핵심 정리 — "확장성은 서버를 더 넣는 문제가 아니라, 설계 초기부터 아키텍처·캐싱·로드밸런싱을 함께 고민해야 하는 문제다." 부하 테스트 실무자들이 공통적으로 강조하는 원칙이다.

⚖️ 반론과 한계 — 과잉 대비는 비용 낭비인가

모든 이러닝 플랫폼이 "동시접속 1만 명"을 상시 대비할 필요는 없다는 반론도 살펴봐야 한다. 소규모 사내교육 시스템이나 특정 학과 단위의 LMS라면, 연중 며칠뿐인 피크 시점을 위해 상시 대규모 인프라를 유지하는 것은 명백한 비용 낭비다. 클라우드 오토스케일링이 부상한 이유도 바로 이 지점 — 평소엔 최소 자원만 쓰다가 필요한 순간에만 확장하고 다시 축소할 수 있다는 유연성 때문이었다. 상시 대규모 인프라와 탄력적 오토스케일링 중 무엇이 합리적인지는 조직의 트래픽 패턴에 따라 달라지는 문제이지, 무조건 "크게 대비할수록 좋다"는 명제는 성립하지 않는다.

오토스케일링 자체의 한계도 짚어야 한다. 새로 투입된 서버가 실제 트래픽을 받기까지 콜드 스타트 지연이 있고, 트래픽이 초 단위로 폭증하는 상황에서는 이 지연 시간 동안 이미 장애가 발생할 수 있다. 또한 오토스케일링은 자원을 자동으로 늘리는 만큼 예상치 못한 비용 급증으로 이어질 위험도 있어, 상한선 설정과 모니터링 없이 무작정 켜두는 것은 또 다른 리스크다. 결국 부하 테스트와 인프라 설계는 "얼마나 크게"가 아니라 "우리 서비스의 실제 트래픽 패턴에 맞게 얼마나 정교하게"를 목표로 삼아야 한다.

🛠️ 부하 테스트 도구 비교 — JMeter vs k6 vs Locust

실제 부하 테스트를 시작하려는 담당자에게는 도구 선택도 중요한 의사결정이다. 세 도구 모두 무료로 쓸 수 있지만 성격이 다르다.

업계에서는 매 배포(PR)마다 핵심 API에 30초짜리 경량 테스트를, 매주 또는 주요 릴리스 전마다 전체 부하 테스트를, 그리고 매달 8시간 이상의 소크 테스트(soak test)로 메모리 누수 같은 장기 문제를 잡아내는 3단계 주기를 권장한다. 이런 자동화된 반복 테스트 없이 "누군가 생각날 때만" 실행하는 부하 테스트는 사실상 효과가 없다는 것이 공통된 지적이다.

🗺️ 실전 가이드 — 이러닝 플랫폼 부하 테스트 6단계

• 1단계 — 실제 피크 시나리오를 정의한다. 개학 첫날 오전, 필수교육 마감 전날 저녁처럼 트래픽이 몰리는 구체적 시각과 예상 인원을 먼저 특정한다.
• 2단계 — 목표치에 20~30% 여유분을 더한다. 1만 명이 목표라면 1만 2천~1만 3천 명 규모로 테스트를 설계해야 실제 운영 중 안전 마진이 생긴다.
• 3단계 — 로그인·영상 재생·퀴즈 제출처럼 쓰기(write) 부하가 큰 구간을 우선 테스트한다. 단순 페이지 조회보다 이 구간이 먼저 무너진다.
• 4단계 — 보안 장치·로드밸런서 설정도 테스트 범위에 포함한다. EBS 사례처럼 안정성을 위해 넣은 장치가 병목이 될 수 있다는 점을 전제로 검증한다.
• 5단계 — 대기열(큐) 도입 여부를 검토한다. 콜드 스타트 지연을 오토스케일링만으로 메우기 어렵다면, 순간 폭주를 흡수할 완충 장치를 별도로 둔다.
• 6단계 — 정기 주기로 반복한다. 배포마다 경량 테스트, 주요 이벤트 전 전체 테스트, 월 1회 소크 테스트로 나눠 자동화한다.

🇰🇷 한국 교육 현장에 주는 시사점

EBS 온라인클래스와 4세대 나이스, 국가정보자원관리원 화재까지 — 한국의 교육 인프라는 이미 여러 차례 트래픽 폭주와 시설 장애를 실제로 겪었다는 점에서 오히려 풍부한 교훈을 갖고 있다. 문제는 이 교훈이 개별 사고 이후의 임시 점검으로 끝나는 경우가 많다는 점이다. 4세대 나이스 장애 이후 교육부가 2주간 특별점검반을 꾸린 것처럼, 사고가 난 뒤에야 부하 테스트와 다중화를 점검하는 패턴이 반복돼 왔다.

기업 교육 담당자 입장에서도 시사점은 같다. 사내 필수교육 마감일, 신입사원 온보딩 시작일처럼 예측 가능한 피크 시점이 있다면, 사고가 나기 전에 그 시점을 가정한 부하 테스트를 정기적으로 실행하는 조직과, 트래픽이 몰릴 때마다 임기응변으로 대응하는 조직 사이의 격차는 결국 교육 서비스의 신뢰도로 이어진다. 특히 여러 사업장·지점을 둔 조직이라면 특정 날짜에 전 직원이 동시 로그인하는 경우가 잦은 만큼, LMS 도입 계약 전에 벤더에게 실제 부하 테스트 결과와 목표 동시접속자 수를 구체적으로 요구하는 것이 안전하다.

학원·협회처럼 특정 시험 일정이나 접수 마감일에 트래픽이 몰리는 업종도 마찬가지다. 대입 원서 접수, 자격시험 접수 마감 직전 몇 시간은 오랫동안 한국 교육 서비스가 반복적으로 겪어온 대표적인 폭주 구간이다. 이런 업종의 담당자라면 평시에는 필요 이상의 인프라 비용을 지불하지 않으면서도, 접수 마감 전 며칠만 집중적으로 대응력을 끌어올리는 탄력적 구조(오토스케일링+대기열 조합)가 특히 유효한 선택지가 된다.

❓ 자주 묻는 질문

Q1. 우리 회사 LMS는 몇 명 동시접속까지 버텨야 하나요?
전체 임직원 수가 아니라 "동시에 로그인할 가능성이 있는 최대 인원"을 기준으로 잡아야 한다. 여기에 20~30%의 여유분을 더하는 것이 표준 관행이다.

Q2. 오토스케일링만 켜두면 충분한가요?
충분하지 않다. 새 서버가 트래픽을 받기까지 걸리는 지연 시간(콜드 스타트) 동안에는 여전히 장애가 발생할 수 있어, 대기열 같은 속도 조절 장치를 함께 두는 것이 안전하다.

Q3. 부하 테스트는 얼마나 자주 해야 하나요?
배포마다 짧은 경량 테스트, 주요 이벤트 전 전체 규모 테스트, 월 1회 이상의 장시간 소크 테스트로 나눠 자동화하는 3단계 주기가 권장된다.

Q4. 작은 조직도 대기열 시스템이 필요한가요?
상시 대규모 트래픽이 없는 소규모 조직이라면 대기열까지는 과할 수 있다. 다만 특정 날짜(마감일·개강일)에만 트래픽이 몰리는 패턴이 있다면, 그 시점만 겨냥한 경량 대기열이 비용 대비 효과적일 수 있다.

Q5. 부하 테스트 도구는 무엇부터 시작하면 되나요?
Python에 익숙한 팀은 Locust, CI/CD 자동화를 우선한다면 k6, 이미 방대한 기능이 필요하다면 JMeter가 각각 적합하다는 것이 업계의 일반적인 평가다.

Q6. EBS나 나이스 같은 대형 사고는 왜 반복될까요?
트래픽 폭주와 시설 장애는 원인이 다른데, 두 경우 모두 "사고가 나기 전에 최악의 시나리오를 가정한 테스트"가 충분히 이뤄지지 않았다는 공통점이 있다. 사고 이후의 특별점검이 아니라 평시의 정기 점검 체계가 필요하다는 지적이 나오는 이유다.

🚀 결론 — 다음 단계

EBS 온라인클래스의 반복된 장애, 국가정보자원관리원의 화재, 그리고 캔버스를 마비시킨 사이버 공격까지 — 원인은 제각각이지만 공통된 결론은 하나다. 트래픽이든 재해든, 최악의 시나리오를 가정한 사전 테스트와 다중화 없이는 어떤 이러닝 플랫폼도 안전하지 않다는 것이다. 반대로 줌처럼 평소 탄력적인 클라우드 인프라를 갖춰두면, 예상을 뛰어넘는 트래픽 앞에서도 서비스를 지켜낼 수 있다는 것 또한 같은 사례들이 보여준다.

기업·기관이 LMS를 도입하거나 갱신할 때는 디자인과 기능만큼이나 "실제 동시접속 상황에서 얼마나 버티는가"를 구체적으로 검증해야 한다. NUGUNA의 LMS 기능이 실제 운영 환경에서 어떻게 안정적으로 동작하는지 궁금하다면 데모 체험으로 직접 확인하거나, 우리 조직의 예상 동시접속 규모에 맞는 구성을 상담 신청을 통해 논의해볼 수 있다.

📎 출처

• 뉴시스 — "'먹통 또 먹통' EBS 온라인클래스, 오늘도 접속오류 발생"(2020)
• 교육부 보도자료 — EBS 온라인클래스 운영상황 점검(2020)
• 나무위키 — 교육행정정보시스템(NEIS) 4세대 장애 경과
• 매일신문 — "잇따른 전산망 '먹통'에… 교육부, 4세대 나이스 특별점검 실시"(2023)
• 한국일보 — 국가정보자원관리원 화재로 인한 정부 전산망 마비(2025)
• Time, CBS News, Wikipedia "2026 Canvas data breach" — ShinyHunters의 Canvas LMS 공격 경과(2026)
• Amazon(AWS) Press Center — "AWS and Zoom Extend Strategic Relationship"(2020)
• AWS Partner Network Blog — Queue-it 가상 대기실 아키텍처
• TestGuild, QAInsights, PFLB — JMeter·k6·Locust 부하 테스트 도구 비교(2026)
• IntechOpen — 보츠와나대학교 Moodle LMS 운영 사례 연구