성능테스트는 통과했다. 오픈날 시스템은 멈췄다

PMO 실전 노트 · Note 04

성능테스트는 통과했다.
오픈날 시스템은 멈췄다.

잘못한 게 없는데 터진 이유 · HFC Consulting

---

오픈 당일 오전 아홉 시. 시스템이 멈췄다.

PM은 전날 밤까지 최종 점검을 했다. 성능테스트 결과표를 다시 펼쳤다. 목표치를 넘었다. 응답시간, 처리량, 동시접속 — 모든 항목이 기준을 통과했다. 검수 도장도 찍혔다. 그런데 실제 사용자들이 몰리자 시스템이 버텨내지 못했다.

PM은 무엇을 잘못한 것인가. 아무것도 잘못하지 않았다. 그것이 문제였다.

노트북으로 실제 부하를 만들 수 없다

성능테스트는 부하를 인위적으로 만들어야 한다. 현장에서 쓸 수 있는 도구는 제한적이다. 노트북을 수십 대 연결하고, 부하 생성 도구를 돌린다. 그게 현실에서 만들 수 있는 최대치다. 그러나 오픈날 실제로 몰려드는 수천 명의 동시접속은 노트북 수십 대가 만들어내는 부하와 성격이 다르다.

테스트 환경과 운영 환경이 다르다. 테스트에서는 네트워크가 통제됐다. 운영에서는 예측하지 못한 경로로 트래픽이 들어온다. 테스트에서는 사용자 행동 패턴이 단순했다. 실제 사용자는 예상하지 못한 순서로 화면을 누른다. 세션이 쌓이는 방식도 다르다. 테스트에서 발견되지 않은 병목이 운영 환경에서 처음 드러난다.

검수 기준이 테스트 환경 기준이었다

성능 검수 기준은 대부분 이렇게 쓰인다. "동시접속 ○명 기준 응답시간 ○초 이내." 숫자는 명확하다. 그런데 그 숫자가 테스트 환경에서 측정된 것인지, 운영 환경을 가정한 것인지가 명시되지 않는 경우가 많다.

수행사는 테스트 환경에서 기준을 통과했으니 검수를 요청한다. 발주사는 숫자가 맞으니 도장을 찍는다. 그리고 오픈날 운영 환경이 처음으로 등장한다. 계약서에 없던 조건이다. 책임 소재를 따지기 시작하면 양측 모두 할 말이 있다. 검수는 통과했으니까.

구분	테스트 환경	운영 환경
부하 생성 방식	도구 기반 인위적 생성	실제 사용자 분산 접속
사용자 행동 패턴	시나리오 기반 단순 반복	예측 불가 다양한 경로
네트워크 조건	통제된 내부망	외부 트래픽 혼재
데이터 규모	샘플 데이터	실제 누적 데이터

PMO가 계약 전에 넣어야 할 한 줄

성능 검수 기준을 계약서에 명시할 때, 테스트 환경의 조건도 함께 명시해야 한다. "어떤 환경에서, 어떤 방식으로 부하를 생성하여, 어떤 기준을 충족한다"가 한 세트다. 조건 없는 숫자는 오픈날 분쟁의 씨앗이 된다.

더 나아가면, 오픈 전 단계적 트래픽 개방을 일정에 반영하는 것이 현실적인 방어다. 전체 사용자를 오픈 첫날 한꺼번에 받는 대신, 일부 사용자부터 순차적으로 개방하면서 실제 운영 환경에서의 성능을 확인하는 것이다. 이 과정 자체를 수행계획서에 단계로 넣어두면, 오픈날 장애가 프로젝트 실패가 아니라 검증 과정의 일부가 된다.

이 사례가 남긴 실무 원칙

성능테스트는 테스트 환경의 한계를 함께 기록해야 한다. 조건 없는 숫자는 검수를 통과시키지만, 오픈날을 보장하지 않는다. PMO는 그 간극을 계약서와 수행계획서에 미리 담아야 한다.

잘못한 게 없는데 터지는 상황이 있다. 그것은 PM의 실력 문제가 아니라 구조의 문제다. 구조를 설계하는 것이 PMO의 역할이다. 오픈 전에 그 구조가 제대로 잡혀 있는지 — 지금 진행 중인 프로젝트라면 지금이 확인할 시점이다.

※ 본 사례는 실제 경험을 바탕으로 재구성·익명화되었습니다.

HFC 컨설팅의 관점

성능 검수 기준 설계, 오픈 전 단계적 트래픽 개방 계획, 장애 대응 절차 수립 — 오픈을 앞두고 있다면 지금이 점검 시점입니다. 현재 상황을 보내 주시면 함께 살펴보겠습니다.

changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

---

📋 PMO 실전 노트 — 25년 현장 경험에서 건진 판단의 기록입니다.
◀ 이전 노트 Note 03 - 수행계획서는 킥오프 날 이미 낡아 있었다
코너 전체 보기 →