[수강신청 꿀팁] 수강신청 서버 타이밍을 분석해보자

수강신청에서 정말 중요한 시간은 무엇일까

보통 수강신청 전에 네이비즘 같은 서버시계를 켜놓고 10:00:00.000을 기다린다. 처음에는 나도 “누가 더 정확한 시계를 보고 더 빨리 클릭하느냐”의 문제라고 생각했다.

 

그런데 구조를 뜯어보면 실제 문제는 조금 다르다.

내가 버튼에서 손가락을 뗌
        ↓
브라우저가 click 이벤트 처리
        ↓
수강신청 요청 전송
        ↓
네트워크 이동
        ↓
서버가 신청 가능 시간인지 판정
        ↓
성공 또는 실패 응답

 

즉 서버가 보는 것은 내 눈에 보인 10시 정각이 아니라, 내 요청이 서버의 시간 판정 로직에 도달한 순간이다.

이를 단순화하면 다음처럼 생각할 수 있다.

 

 

여기서 θ는 PC/보조시계와 신청 서버 clock의 차이, δ는 마우스를 뗀 뒤 요청이 서버 판정 지점까지 가는 데 드는 지연이다.

따라서 목표는 사실 “10시에 클릭한다”가 아니라 서버가 OPEN이 된 직후 내 요청을 판정하도록 만드는 것이다.

---

네이비즘 서버시계는 정확히 무엇을 보여주는가

 

네이비즘은 매우 편리하다. 화면에서 밀리초 단위로 시간이 계속 흐르고, 수강신청이나 티켓팅 직전에 누구나 쉽게 사용할 수 있다.

하지만 중요한 점이 하나 있다. 네이비즘이 보여주는 시간은 실제 수강신청 애플리케이션 내부의 Gate clock을 직접 화면에 연결한 것이 아니다.

 

웹에서 어떤 서버의 시간을 추정할 때는 대략 다음 요소들이 개입할 수 있다.

대상 서버 또는 앞단 프록시/CDN의 시계
        ↓
시간을 얻는 방식
        ↓
네트워크 왕복 지연과 jitter
        ↓
보정 로직
        ↓
내 브라우저에서 흐르는 표시 시계

 

따라서 화면에 10:00:00.123이 보인다고 해서 그 123 ms가 곧바로 “수강신청 백엔드가 현재 123 ms라고 판단하고 있다”는 뜻은 아니다.

 

이게 네이비즘이 부정확하다는 뜻은 아니다. 네이비즘은 연속적인 실시간 기준시계로 매우 유용하지만, 실제 신청 판정 clock과 동일하다고 가정하면 안 된다는 뜻이다.

---

서울과기대 수강신청 서버에서 직접 확인한 것

Chrome DevTools의 Network 탭을 켜고 수강신청 페이지에서 저장 버튼을 눌러봤다.

저장을 누르는 순간 첫 번째 JSONMain XHR 요청이 발생했고, Payload에는 다음과 같은 값이 포함되어 있었다.

sp_action: MainAction
sp_cmd: requestSuganggBasket

 

신청 가능 시간이 아닐 때 이 요청의 서버 응답에는 다음과 같은 정보가 실제로 포함되어 있었다.

{
  "ErrorMsg": "... 서버 시간 : 2026-08-11 14:53:33",
  "ErrorCode": "7"
}

이 점이 중요하다.

 

저 경고창에 표시되는 시간은 브라우저가 임의로 만든 숫자가 아니라 실제 requestSuganggBasket 요청에 대한 서버 응답 안에 포함된 값이었다.

 

즉 네이비즘처럼 외부에서 서버시간을 추정한 값보다, 이 시간은 실제 신청 처리 흐름에 훨씬 가까운 clock proxy라고 볼 근거가 있다.

⚠️

다만 “ErrorMsg에 출력하는 시계 = 실제 OPEN/CLOSED 조건문에서 사용하는 시계”라고 100% 증명된 것은 아니다. 같은 애플리케이션 흐름 안에서 나온 값이라 매우 좋은 단서이지만, 내부 구현까지 확인한 것은 아니다. 따라서 ‘정확한 절대시계’라기보다 실제 신청 로직에 더 가까운 기준이라고 표현하는 것이 맞다.

 

---

그럼 서버시간을 보면 네이비즘보다 무조건 더 좋은가

그렇지는 않다.

서버 응답은 14:53:33처럼 초 단위까지만 알려준다. 한 번의 응답만 보면 실제 판정 시점이 33.001인지 33.950인지 알 수 없다.

반대로 네이비즘은 밀리초가 계속 흐르기 때문에 실전에서 타이밍을 맞추기에는 훨씬 보기 좋다.

그래서 둘은 경쟁 관계라기보다 역할이 다르다.

도구	잘하는 것	한계
네이비즘	실시간으로 계속 흐르는 밀리초 기준시계	실제 신청 Gate clock과 동일한지 알 수 없음
수강신청 ErrorMsg 서버시간	실제 신청 요청 처리 흐름에 가까운 서버 clock 확인	초 단위라 한 번만 봐서는 ms offset을 알 수 없음

 

따라서 가장 합리적인 방식은 네이비즘을 실전 기준시계로 사용하고, 신청 서버의 ErrorMsg 시간을 교정·검증용으로 사용하는 것이다.

 

예를 들어 연습 중 네이비즘을 보고 특정 시점에 저장을 눌렀을 때 서버가 반복해서 같은 초를 반환한다면 둘 사이에 큰 오차는 없다고 볼 수 있다. 반대로 네이비즘에서는 이미 다음 초로 넘어갔다고 보이는데 서버 응답은 계속 이전 초라면, 두 clock 사이에 의미 있는 offset이 있을 가능성을 의심할 수 있다.

 

한 번의 샘플보다 여러 번 같은 방향의 차이가 반복되는지가 더 중요하다.

---

네트워크가 빠르면 끝일까

DevTools에서 실제 저장 요청 하나를 측정했을 때 전체 시간은 약 20 ms 수준이었고, 대부분은 Waiting for server response 구간이었다.

 

하지만 이 값을 단순히 반으로 나눠서 “서버까지 10 ms”라고 보면 안 된다.

해당 시간에는 대략 다음이 섞여 있다.

내 PC → 서버 전송
+ 서버 처리
+ 서버 → 내 PC 응답이 돌아오기 시작하는 시간

 

또 인터넷 경로는 반드시 대칭이 아니다. 가는 길이 5 ms, 오는 길이 15 ms일 수도 있다.

그래서 수강신청에서는 최저 ping 한 번보다도 지연이 얼마나 일정한가가 더 중요할 수 있다. 평균 15 ms인데 매번 14~16 ms라면 예측하기 쉽지만, 평균 10 ms인데 5~50 ms로 출렁이면 타이밍은 오히려 불안정하다.

---

의외로 중요한 것: 이 페이지는 ‘누르는 순간’보다 ‘떼는 순간’이 중요했다

직접 여러 번 확인했을 때 저장 버튼은 마우스를 누르는 순간에 바로 요청이 나가는 것이 아니라, 마우스를 뗄 때 최종 click이 발생하면서 요청이 시작되는 동작을 보였다.

 

웹의 일반적인 클릭 흐름도 대략 다음과 같다.

mousedown
   ↓
mouseup
   ↓
click
   ↓
JavaScript handler
   ↓
XHR 요청

 

따라서 서울과기대 해당 페이지에서는 실전 동작을 ‘언제 눌러야 하나’보다 ‘언제 손가락을 떼야 하나’로 생각하는 편이 더 정확하다.

이 점은 인간 반응시간 측면에서도 의미가 있다. 정각에 새로 버튼을 누르는 것보다, 버튼 위에서 미리 마우스를 누르고 안정적으로 유지한 다음 원하는 순간에 손가락 힘을 풀어 mouseup을 만드는 방식이 반복 동작의 편차를 줄이는 데 도움이 될 수 있다.

---

결국 사람이 줄여야 하는 것은 ‘반응속도’보다 ‘편차’다

사람의 시각 반응시간은 수십 ms가 아니라 보통 그보다 훨씬 큰 단위로 움직인다. 하지만 수강신청에서 더 문제인 것은 매번 정확히 같은 타이밍으로 움직이기 어렵다는 점이다.

예를 들어 어떤 사람이 평균적으로 150 ms 늦더라도 매번 거의 145~155 ms 범위라면 보정하기 쉽다. 반면 평균은 100 ms인데 어떤 때는 60 ms, 어떤 때는 190 ms라면 훨씬 예측하기 어렵다.

따라서 실전에서 의미 있는 연습은 “최대한 빨리 클릭”이 아니라 다음과 같다.

• 같은 화면 배치
• 같은 손가락 자세
• 같은 버튼 위치
• 같은 mousedown → hold → mouseup 동작
• 네이비즘의 같은 시각을 보고 반복 release

즉 속도를 최대화하기보다 동작의 jitter를 줄이는 것이 목표다.

---

실제로는 이렇게 세팅하면 된다

아래는 복잡한 계측을 하지 않고도 따라 할 수 있는 현실적인 절차다.

1. PC방에 도착하면

1. 가능하면 유선 연결 PC를 사용한다.
2. 다운로드, 게임 런처 업데이트, 스트리밍 등 불필요한 네트워크 사용을 끈다.
3. Chrome에서 수강신청 사이트에 미리 로그인한다.
4. 수강신청 화면과 네이비즘이 동시에 보이도록 창을 배치한다.
5. 신청 버튼의 위치를 확정하고 이후 창 크기·배율·스크롤을 되도록 바꾸지 않는다.

2. 신청 10~15분 전: 서버시간과 네이비즘 비교

F12 → Network를 켠 뒤 저장 버튼을 정상적으로 몇 차례 눌러본다.

첫 번째 JSONMain 요청에서 다음을 확인한다.

Payload
sp_cmd = requestSuganggBasket

Response
ErrorCode = 7
서버 시간 = YYYY-MM-DD HH:mm:ss

 

이때 네이비즘의 초와 ErrorMsg의 서버 초가 대체로 같은 방향으로 맞는지 본다.

 

목표는 밀리초를 정확히 계산하는 것이 아니다. 신청 서버가 네이비즘보다 눈에 띄게 한쪽으로 어긋나 있는지 확인하는 정도면 충분하다.

3. mouseup 연습

마우스 커서를 신청 버튼 위에 올린다.

버튼을 미리 누름
       ↓
손가락을 누른 상태로 고정
       ↓
네이비즘의 목표 시각 관찰
       ↓
목표 순간에 손가락 release

 

몇 번 반복하면서 같은 시각을 보고 비슷한 순간에 떼는 감각을 만드는 것이 중요하다.

정각에 갑자기 버튼을 새로 누르는 것보다 이 방식이 동작을 하나 줄여준다.

4. 신청 1~2분 전

이때부터는 실험을 그만두는 편이 낫다.

• 네이비즘을 마지막으로 새로고침한다.
• 한두번 정도만 더 타이밍 확인을 해보고 그대로 둔다.
• DevTools 조작을 멈춘다.
• 페이지 새로고침을 불필요하게 하지 않는다.
• 신청할 과목과 버튼 위치를 다시 확인한다.
• 마우스를 버튼 위에 고정한다.

직전까지 서버 요청을 반복해서 날리거나 화면을 바꾸다가 오히려 실전 상태를 망치는 것이 더 위험하다.

5. 실제 신청 순간

서울과기대 해당 페이지에서 확인한 동작을 기준으로 하면:

정각 직전
→ 버튼을 누른 상태로 유지

목표 시각
→ mouseup
→ click
→ requestSuganggBasket
→ 서버 판정

 

여기서 지나치게 “몇 ms 먼저 보내야 한다”는 계산에 집착할 필요는 없다. 네트워크와 서버 처리에는 순간적인 jitter가 있고, 너무 일찍 도착하면 신청시간 전으로 판정되어 바로 실패할 수 있다.

따라서 실전에서는 네이비즘을 안정적인 연속시계로 보고, 서버 ErrorMsg로 큰 offset이 없는지 미리 확인하고, 반복 연습한 mouseup 타이밍을 그대로 실행하는 것이 가장 단순하고 재현성 있는 전략이다.

---

세 줄 요약

1. 네이비즘은 밀리초 단위 실전 기준시계로 쓰되, 실제 신청 서버의 Gate clock과 동일하다고 가정하지 않는다.
2. 서울과기대에서는 실제 신청 요청 requestSuganggBasket의 응답에 서버시간이 포함되어 있어, 이를 네이비즘의 교정·검증 기준으로 사용할 수 있다.
3. 해당 페이지의 실제 입력 기준은 mouseup → click 흐름이므로, 버튼을 미리 누르고 목표 순간에 release하는 연습이 실전에서 더 일관될 수 있다.