온라인 시험 시스템 개발, 사용자는 전원이 같은 1초에 들어옵니다 — 시험을 여는 쪽이 정해야 할 6가지

온라인 시험 시스템 개발을 마치고 처음으로 시험을 여는 날의 풍경은 대개 비슷합니다. 오전 9시 정각 입실, 그 직전까지 접속자 수는 0에 가깝습니다. 담당자는 조용한 모니터를 보며 서버가 멀쩡한 것을 확인합니다. 그리고 9시 정각, 대기하던 응시자 전원이 같은 1초에 입실 버튼을 누릅니다.

그 다음 몇 분도 대개 비슷합니다. 로그인이 밀리고, 일부 응시자가 빈 화면을 보고, 고객센터 전화가 한꺼번에 들어옵니다. 조금 뒤에는 성격이 다른 질문이 올라옵니다. 감독관 화면에 특정 응시자의 이상 기록이 남았는데, 이 응시자를 어떻게 처리할지 답할 수 있는 문서가 조직 안에 없습니다. 시험은 이미 진행 중이고, 결정은 그 자리에서 내려집니다.

두 장면은 모두 개발이 끝난 뒤에 나타나지만, 원인은 전부 발주 전에 만들어집니다.

100건 이상의 프로젝트에서 확인한 두 가지

디비컨설팅은 100건 이상의 프로젝트를 수행했고, 50개 이상의 글로벌 파트너사와 함께 일합니다. 한국인 PM이 요구사항 정리와 주간 검수를 맡고, 검증된 글로벌 개발팀이 구현하는 IT 아웃소싱 구조입니다. 교육·평가 영역에서는 YEEP 온라인 창업체험교육 플랫폼, AI 봇아미 튜터링, 수학에심장을달다, 가천대학교 학사관리 시스템, 웅진컴퍼스 LMS 플랫폼 커스터마이징, SPEP 기업 교육 플랫폼을 만들었습니다.

이 작업들을 지나며 확인한 것은 두 가지입니다. 첫째, 시험 시스템의 트래픽은 평소 0에 가깝다가 시작 시각에 100%가 됩니다. 평균 동시 접속자를 기준으로 하는 일반적인 웹 플랫폼 용량 산정이 그대로 적용되지 않습니다. 둘째, 기술은 의심스러운 행동을 탐지할 수 있을 뿐 판정하지 못합니다. 불합격은 발주사의 규정에 따라 사람이 내리는 결정입니다. 규정이 문서로 존재하지 않으면 개발이 끝나도 시험을 열 수 없습니다.

아래 여섯 가지는 전부 이 두 문장에서 나옵니다. 그리고 여섯 가지 모두 개발사가 아니라 발주사가 정합니다.

시험 시스템이 무너지는 지점은 대체로 세 곳입니다

평소 0, 시작 시각에 100%

일반적인 서비스는 사용자가 하루에 걸쳐 들어옵니다. 시험은 그렇지 않습니다. 오랫동안 유휴 상태였던 시스템이 정해진 1초에 전체 응시자를 받습니다. 피크가 평균의 몇 배인지를 따지는 것이 아니라, 평균이라는 기준 자체가 의미를 잃습니다. 입실 직후와 제출 마감 직전, 이 두 구간만 버티면 나머지 시간은 한가합니다. 용량 산정도 비용 계획도 이 두 구간을 기준으로 이야기해야 합니다.

기능 검수는 통과했는데 시험을 열지 못합니다

화면은 전부 동작합니다. 문항이 뜨고, 답안이 저장되고, 점수가 계산됩니다. 그런데 “응시 중 이상 기록이 남은 응시자를 누가 어떤 기준으로 처리하는가”에 답할 문서가 없습니다. 이것은 버그가 아니라 규정의 부재이고, 개발사가 대신 만들어 줄 수 없는 종류의 공백입니다. 검수 체크리스트는 모두 통과했는데 시험 일정을 미루는 상황이 여기서 나옵니다.

응시자 화면만 설계되고 감독·채점·이의 화면이 빠집니다

요구사항을 정리할 때 먼저 떠오르는 화면은 응시자 화면입니다. 그러나 시험 운영에 실제로 필요한 화면은 그보다 많습니다. 감독관이 진행 상황을 보는 화면, 채점과 재채점을 처리하는 화면, 이의 신청을 접수하고 처리 이력을 남기는 화면, 결과를 공개 범위에 맞춰 내보내는 화면이 모두 필요합니다. 이 화면들은 견적이 만들어진 다음에 떠오르는 경우가 많고, 그때는 일정과 범위가 이미 고정되어 있습니다.

시험을 여는 쪽이 발주 전에 정해야 할 여섯 가지

1. 이 시험은 연습입니까, 판정입니까

결과가 참고용인 진단 평가나 모의고사와, 합격·불합격을 가르거나 채용·자격 결과로 이어지는 시험은 같은 시스템이 아닙니다. 후자가 되는 순간 응시자 본인 확인, 응시 기록 보존, 이의제기 절차가 전부 필수 항목이 되고 범위와 일정이 달라집니다. 이 한 줄을 확정하지 않은 채 응시 화면부터 시작하면, 중간에 성격이 바뀌면서 구조를 다시 잡아야 합니다. 나머지 다섯 가지는 전부 이 답에 따라 달라지므로, 요구사항 정의서의 첫 문장이 되어야 합니다.

2. 응시자 본인 확인을 어디까지 할 것인가

본인 확인에는 단계가 있습니다. 아이디와 비밀번호, 휴대폰 본인확인, 신분증 대조, 얼굴 확인 순으로 올라갑니다. 단계가 올라갈수록 비용이 오르고, 수집하는 개인정보의 범위가 넓어지고, 응시자의 거부감도 함께 커집니다. 어디서 멈출지는 1번이 정합니다. 참고용 진단 평가에 신분증을 요구할 이유는 없고, 자격 결과로 이어지는 시험을 아이디와 비밀번호만으로 여는 것도 어렵습니다. 어떤 정보를 수집하고 얼마나 보관할지는 법무 검토를 먼저 받아야 하는 사안이며, 개발 착수 전에 결론이 나 있어야 합니다.

3. 동시 접속을 설계로 감당할 것인가, 운영으로 분산할 것인가

응시자는 전원이 같은 1초에 들어옵니다. 여기서 정해야 할 것은 세 가지입니다. 부하 시험을 언제, 어떤 규모로, 누구 비용으로 수행할 것인가. 입실 시간에 폭을 두어 운영으로 분산할 것인가, 정각 입실을 유지하고 설계로 감당할 것인가. 장애가 발생했을 때 시험을 중단하는 기준과 재시험 절차는 무엇인가. 세 번째 항목은 기술 문서가 아니라 운영 규정에 들어가야 하고, 이것도 발주사가 씁니다. 출시 이후 장애가 났을 때 누가 어떤 등급으로 대응하는지는 서버 운영 유지보수에서 따로 정리했습니다.

4. 부정행위 — 탐지와 판정은 다른 일입니다

시스템이 할 수 있는 일은 기록입니다. 화면 전환이 몇 번 있었는지, 특정 구간에서 응답이 비정상적으로 빨랐는지, 같은 회선에서 여러 계정이 접속했는지를 남길 수 있습니다. 시스템이 할 수 없는 일은 그 기록을 부정행위라고 선언하는 것입니다. 무엇을 부정으로 볼지, 누가 최종 판정을 내릴지, 판정 근거 자료를 얼마나 보관할지, 응시자가 반박할 기회를 어떻게 보장할지는 전부 발주사의 규정입니다. 개발사가 정할 수 없고, 정해서도 안 되는 영역입니다.

규정 없이 탐지 기능만 붙이면 결과는 하나로 수렴합니다. 시험 당일 감독관 화면에 의심 구간이 쌓이고, 아무도 그것을 처리하지 못합니다. 기록은 남았는데 판단의 근거가 없으므로 그 기능은 운영 부담만 늘립니다. 개발이 끝나도 시험을 열 수 없다는 말은 이런 뜻입니다. 규정은 개발 일정과 무관하게, 조직 안에서 먼저 만들어져야 합니다.

5. 문항 보안은 개발 이슈가 아니라 권한 이슈입니다

유출은 대개 서버가 뚫려서 발생하지 않습니다. 볼 수 있는 사람이 너무 이르게, 너무 넓게 볼 수 있어서 발생합니다. 그래서 정해야 할 것은 암호화 방식이 아니라 권한입니다. 출제자·검토자·운영자가 각각 언제부터 문항을 볼 수 있는지, 시험 전 문항이 어디에 어떤 형태로 보관되는지, 열람 기록을 남길지, 응시 중 문항을 한꺼번에 내려줄지 한 문항씩 내려줄지를 정해야 합니다. 마지막 항목은 보안과 동시 접속에 동시에 영향을 줍니다. 한꺼번에 내려주면 요청 수는 줄지만 응시자 단말에 전체 문항이 올라가고, 한 문항씩 내려주면 노출은 줄지만 요청 수가 응시자 수와 문항 수를 곱한 만큼 늘어납니다. 어느 쪽을 택할지는 1번과 3번의 답에 따라 갈립니다. 외부 개발팀에 맡길 때 접근 권한을 어디까지 통제하는지는 외주 개발 보안에서 다뤘습니다.

6. 채점 이후는 누구의 화면에서 처리됩니까

시험은 제출로 끝나지 않습니다. 결과를 누구에게 어디까지 공개할지, 이의 신청을 어느 창구로 받을지, 재채점을 누가 승인하고 점수 정정 이력을 어떻게 남길지, 성적 산출 기준과 리포트 양식은 무엇인지가 남습니다. 응시자 화면보다 늦게 떠오르기 때문에 견적에서 자주 빠지는 항목입니다. 그리고 이의제기는 기록이 없으면 처리할 수 없으므로, 보존 범위를 정하는 2번·4번과 묶여 있습니다. 자동 채점 알고리즘이나 문항 추천 로직을 어떻게 설계할지는 이 글과 성격이 다른 문제이며, AI 튜터 개발에서 따로 다룬 적이 있습니다.

발주 방식 세 가지

시험 시스템을 만드는 방법은 크게 세 가지입니다. 국내 개발사에 맡기는 방식, 해외 개발팀에 직접 발주하는 방식, 한국인 PM을 사이에 두고 글로벌 개발팀이 구현하는 방식입니다. 비교의 기준은 단가가 아닙니다. 위 여섯 가지를 누가 한국어로 정리하고 매주 확인하느냐입니다. 시험 규정과 판정 기준은 개발 산출물이 아니라, 발주사 조직 안에 한국어로 존재하는 문서이기 때문입니다.

	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
시험 규정·판정 기준 문서화 책임	개발사	발주사 본인	한국 PM
규정 협의·검수 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
범위 누락·재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

해외 개발팀에 직접 발주하면 단가는 내려갑니다. 대신 시험 규정, 판정 기준, 이의 절차, 개인정보 처리 범위를 영어 문서로 옮기고, 매주 산출물을 검수하고, 시차를 두고 질문에 답하는 일이 전부 발주사 담당자에게 돌아옵니다. 이 업무는 겸직으로 처리되는 경우가 많고, 그래서 검수가 밀리고 빠진 범위가 늦게 드러납니다. 디비컨설팅이 말하는 국내 개발사 대비 평균 40~60% 비용 절감은 이 번역과 검수를 한국인 PM이 가져간 상태의 숫자입니다. 단가만 비교하면 이 업무량은 표에 나타나지 않습니다.

디비컨설팅이 이 과정을 다루는 방식

1. 상담 및 요구 분석 — 화면 목록보다 먼저 네 가지를 한국어 문서로 정리합니다. 이 시험이 연습인지 판정인지, 본인 확인을 어디까지 할 것인지, 부정행위 규정과 최종 판정 주체는 누구인지, 이의제기는 어떤 순서로 처리되는지입니다. 규정이 아직 없다면 이 단계에서 드러나고, 개발이 끝난 뒤에 드러나는 것보다 낫습니다.
2. 개발팀 구성 — 확정된 범위에 맞춰 전담팀을 2~4주 안에 구성합니다.
3. 프로젝트 개발 — 애자일 방식으로 진행하며 매주 한국어로 데모를 진행합니다. 감독 화면과 이의 처리 화면을 응시자 화면과 같은 순서 안에 넣어, 뒤로 밀리지 않게 합니다.
4. 테스트 및 배포 — 기능 테스트와 별도로 부하 시험과 실제 시험 시나리오를 범위에 포함합니다. 정각 입실 집중, 시험 중 네트워크 이탈과 재접속, 마감 직전 동시 제출, 감독관 개입과 기록 생성까지 실제 운영 순서대로 확인합니다.
5. 운영 및 유지보수 — 소스코드는 발주사에 귀속되고, API 명세와 DB 스키마, 배포 절차 문서까지 함께 전달합니다. 다음 회차 시험을 내부 인력이나 다른 팀이 운영할 수 있어야 하기 때문입니다.

실제로 만든 것, 그리고 만들지 않은 것

• YEEP 온라인 창업체험교육 플랫폼 — 응답 데이터를 실시간으로 분석하고 시각화 리포트로 역량을 진단하는 교육 평가 시스템. 응답을 수집해 결과를 산출하고 보고서 형태로 내보내는 흐름은, 시험 시스템의 채점·결과 구간과 구조가 같습니다.
• AI 봇아미 튜터링 — 딥러닝 문항 인식 기반 자동 문제 분석, 실시간 채점과 피드백.
• 수학에심장을달다 — 지식맵 기반 문제은행과 실시간 성취도 측정. 문항을 분류해 보관하고 꺼내 쓰는 구조를 다뤘습니다.
• 가천대학교 학사관리 시스템 — 평생교육·학위과정 운영을 위한 관리자 중심 웹 플랫폼. 역할별 권한과 승인 흐름, 그리고 특정 시점에 요청이 몰리는 학사 운영이 과제였습니다.
• 웅진컴퍼스 LMS 플랫폼 커스터마이징 — 클래스 관리, 과제 배포, 학습 데이터 분석.
• SPEP 기업 교육 플랫폼 — 기업 단위 교육 과정 관리와 글로벌 확장 구조.

교육·평가 영역의 경험은 위 여섯 건입니다. 삼성물산 홈닉, LS일렉트릭 테크스퀘어, GS건설 엘리시안 리조트, 직방 호갱노노도 수행했지만, 이 네 건은 시험 시스템이 아닙니다. 대규모 동시 접속과 복잡한 권한·승인 흐름이라는 같은 종류의 난이도를 다룬 프로젝트일 뿐이며, 그 이상으로 섞어서 말하지 않겠습니다. 덧붙여 디비컨설팅은 자격검정 시험 시스템이나 채용 필기시험 시스템, 감독 전용 제품을 만든 적이 없습니다. 평가·진단·채점·대규모 학사 시스템을 만들어 왔고, 이것이 시험 시스템에 인접한 경험이라고 설명하는 편이 정확합니다. 전체 수행 이력은 포트폴리오에서 확인하실 수 있습니다.

이런 기관에 적합합니다

• 판정 성격의 시험을 여는 기관 중, 부정행위 규정과 이의 절차가 이미 있거나 이번 프로젝트에서 함께 문서로 만들 의지가 있는 곳
• 응시 인원이 정해진 시각에 몰리고, 기존 시스템이 그 구간을 버티지 못한 적이 있는 곳
• 기존 LMS나 학사·회원 시스템에 시험을 얹었다가, 감독·이의 화면이 없어 운영이 막힌 곳
• 개발 종료 후 소스코드와 문서를 받아 내부에서 다음 회차를 운영해야 하는 곳

반대로, 권하지 않습니다

• 부정행위 규정과 이의 절차를 당분간 만들 계획이 없는 곳. 시스템이 완성되어도 판정의 근거가 없습니다. 개발보다 규정을 먼저 정하는 편이 낫습니다.
• 응시 인원이 수십 명 수준인 사내 설문이나 간이 테스트. 기성 도구로 충분하고, 그 편이 빠릅니다. 솔루션과 커스텀 개발을 가르는 기준을 먼저 보십시오.
• 감독 영상 분석이나 화면 감시처럼, 프록터링 제품 자체를 찾는 곳. 디비컨설팅이 만들어 온 영역이 아닙니다.
• 몇 주 안에 오픈해야 하는 곳. 전담팀 구성에만 2~4주가 필요하고, 부하 시험과 시험 시나리오 검증 기간이 따로 있어야 합니다.

자주 묻는 질문

부정행위 규정이 아직 없습니다. 개발을 먼저 시작해도 됩니까?

응시 화면이나 문항 관리처럼 규정과 무관한 범위는 먼저 시작할 수 있습니다. 다만 탐지 기능과 감독·이의 화면은 규정이 확정된 뒤에 설계해야 합니다. 무엇을 부정으로 볼지, 누가 최종 판정을 내릴지가 정해지지 않으면 그 화면의 요구사항 자체를 쓸 수 없습니다.

동시 접속은 몇 명까지 가능합니까?

숫자만으로는 답할 수 없는 질문입니다. 응시 인원, 문항 수와 제공 방식, 이미지·음성 파일 포함 여부, 입실을 정각으로 할지 폭을 둘지에 따라 결과가 달라집니다. 목표 인원과 입실 방식을 먼저 정하고, 부하 시험을 언제 어떤 범위로 수행할지를 계약 범위에 넣어 확인하시기를 권합니다.

부정행위를 시스템이 자동으로 걸러줍니까?

걸러주지 않습니다. 시스템은 의심 구간을 기록으로 남깁니다. 그 기록을 부정행위로 판정하는 것은 발주사의 규정에 따른 사람의 결정입니다. 이 구분이 흐려지면, 시험 당일에 처리하지 못하는 기록만 쌓입니다.

본인 확인은 어디까지 해야 합니까?

시험의 성격이 정합니다. 결과가 참고용이면 과한 확인은 비용과 응시자 거부감만 늘립니다. 합격·불합격이나 자격·채용 결과로 이어지면 확인 단계를 올려야 합니다. 어떤 개인정보를 수집하고 얼마나 보관할지는 법무 검토를 먼저 받은 뒤 결정할 사안입니다.

개발이 끝난 뒤 내부에서 운영할 수 있습니까?

소스코드는 발주사에 귀속되고, API 명세와 DB 스키마, 배포 절차 문서까지 인계합니다. 다음 회차 시험을 다른 팀이 운영하거나 내부 인력이 유지보수를 이어받는 상황을 기준으로 문서를 정리합니다.

정리

온라인 시험 시스템은 문항을 보여주는 화면이 아닙니다. 평소 0이던 트래픽이 정해진 1초에 100%가 되는 시스템이고, 기술이 남긴 기록을 사람이 규정에 따라 판정하는 시스템입니다. 앞의 문제는 설계와 운영 방식으로 나눠 풀 수 있고, 뒤의 문제는 발주사 조직 안에서만 풀 수 있습니다. 여섯 가지를 발주 전에 한국어 문서로 정리해 두면, 시험 당일 아침에 결정해야 할 일이 남지 않습니다.