열심히 썼지만 틀린 부분이 많을 것 같습니다. 잘못된 정보를 드렸다면 미리 죄송합니다.
혹시나 틀린 부분 발견하시면 댓글로 남겨주시면 정말 감사하겠습니다 :)

들어가며

처음에는 수강신청 페이지 로그인 화면만 봐도 손을 벌벌 떨었다.

지금까지 6번의 수강신청을 겪었다. 성공한 적은 한 번도 없었고, 몇 번은 아주 망했다.

해가 지나면서 수강신청 시스템에 대한 궁금증이 생겼다. 이것도 결국 그냥 웹사이트 아닐까 싶었다.

수강신청의 규칙은 사람이 정해놓은 꼭 따라야 하는 룰이지만 해당 구현물(=수강신청 페이지)도 그 룰을 충실히 따를까?

동시 접속 금지, 매크로 부정 사용 금지 등의 규칙이 수강신청 사이트에는 어떻게 적용되어 있을까?

어디서 수강신청을 시도해야 가장 빠를까?

여러 물음에 대해 고민한 흔적을 정리해 보았다.

기술적인 것들

웹사이트

주소 창에 뭔가를 써넣고 페이지가 보이면 무언가를 클릭해서 어떤 결과를 얻는다.

일반적인 웹사이트의 모습이다.

누군가가 구글에 접속하고자 주소창에 www.google.com을 써넣고 엔터 키를 누르면 보이지는 않지만 많은 과정을 거쳐 브라우저 화면에 구글 검색 창이 보이게 될 것이다.

그 때에 보이는 구글 로고는 결코 내 컴퓨터에 있던 것은 아니다. 그렇다면 어디에 있었을까? 구글 서버에 있었다.

사용자가 구글 서버에게 ‘검색 페이지 내놔!’라고 요청했기에 구글 서버가 해당 페이지를 내어 준 것이다.

해당 페이지는 HTML이라는 언어로 기술되어 있다.

Hyper Text Markup Language.
시각적으로 보이는 것들을 기술하는(마크업) 언어이다.
예를 들어, 화면 위쪽 가운데에 굵은 글씨로 ‘ABCD’라고 쓰인 하얀 종이를 생각해보자.
MS Word를 사용한다면 가운데 정렬에 굵은글씨 스타일을 적용하고 ‘ABCD’라고 쓰면 될 것이다.
HTML이라면 <title>ABCD</title>라고 쓰면 된다.
컴퓨터에 탑재된 웹 브라우저는 ‘ABCD’라는 글이 ‘title’로 감싸진 것을 보고, 이를 굵은 글씨로 화면 가운데에 표시해야 한다는 것을 알아차릴 것이다.

이 HTML로 쓰인 페이지를 사용자의 웹 브라우저(크롬이나 엣지 등등)가 해석하여 눈에 보이는 그래픽을 만들어 모니터에 그리는 것이다.

요청과 응답

사용자가 웹사이트의 주소를 타이핑하고 엔터를 눌러 ‘접속’하는 동작은 해당 서버에 HTTP GET / 요청을 보내는 것과 같다.

이게 무슨 소리냐면, 해당 주소의 웹사이트를 관리하는 서버에게 ‘너네 페이지의 홈 화면을 보여줘’라고 요청을 보내는 것이다.

요청을 받은 서버는 ‘/’ 주소(최상위)에 해당하는 페이지를 보내준다. 보통은 index.html일 것이다.

그렇게 서버에게서 전달받은 페이지에는 글도 있고 버튼도 있다. 버튼을 누르면 또 다른 요청이 서버로 전달된다.

마치 김밥천국(서버)에 가면 차림표(웹페이지)를 주고, 메뉴를 체크해 카운터에 접수하면 음식(또다른 페이지)이 나오는 것과 같다.

FAQ?

위에서는 웹 기술에 대한 기초를 살펴보았다.

이번 학기 수강신청 관련해서 많이 나온 물음들을 정리해 보았다.

동시접속 차단?

서버는 사용자의 로그인 정보를 기억하고 있다.

로그인을 하면 토큰(token)이라는게 발급되는데, 여러 곳에서 로그인을 하면 토큰이 여러 개가 발급된다.

서버는 이를 알아차리고 마지막에 발급된 토큰을 제외한 나머지 토큰을 모두 무효화시켜버린다.

즉 마지막에 로그인한 탭, 창, 또는 앱에서만 로그인이 유지되는 것이다.

피해갈 수 있는 방법이 있다. 서버가 ip를 체크하지는 않기 때문에 해당 토큰을 추출하여 다른 요청을 보낼 때에 같이 끼워서 보내면 된다. 중복 로그인 체크가 로그인 시점에만 일어나기 때문이다. 이 방법에서 로그인은 한 번만 일어나기 때문에 잡을 수 없다.

보안문자열

서버는 요청이 너무 빠르게 들어온다 싶으면 보안 문자열을 입력하라는 팝업을 제시한다.

이미지가 주어지고, 해당 이미지에 쓰인 글자를 읽어 키보드로 입력한 다음 확인 버튼을 누르면 이전에 보낸 요청이 재개된다.

충분히 피해갈 수 있다. 해당 동작이 이루어지는 코드를 잘 뜯어보면, 서버는 해당 이미지에 써있는 글씨와 내가 입력한 글씨가 일치하는지는 확인하지만, 내가 해당 글씨를 올바르게 입력해서 통과했는지는 관심이 없다. 다르게 말하자면, 채점은 하는데 시험지에 이름이 안 써있거나 이름을 안 본다. 0점 시험지를 내도 그게 나의 것이라는 사실에는 관심이 없으므로 나에게 아무 말도 하지 않는 것이다. 결국 이것도 간단하게 피해갈 수 있다.

대기열

수강신청 사이트에 접속하면 m명의 대기자 중 n번째라는 팝업이 뜬다.

사실 우리는 수강신청 서버와만 통신하는 것이라고 생각하지만, 실제로는 마우스로 로그인 버튼 또는 수강신청 버튼을 누를 때에 다른 서버에게 현재 대기자가 몇 명이나 있는지 물어보는 절차를 거친다.

웹 브라우저는 대기자가 없어질 때까지 기다리다가 때가 되면 사용자가 원하는 작업을 수행한다.

중요한 것은 대기 절차가 단지 ‘물어보는’ 절차라는 것이다. 실제로 본 서버에 요청을 전송하는 것에는 제한이 없다. 문지기가 있기는 한데, 문에서 50m 떨어진 곳에 있어서 문지기에게 말을 걸 필요도 없이 바로 들어갈 수 있는 것이다.

속도

수강신청을 어디서 하느냐에 따라 속도가 다르다고 하는 사람들이 있다.

결론부터 말하자면 물리적 거리에 따른 속도차이는 체감 못한다.

학교 서버실에서 수강신청 본 서버와 같은 스위치에 기가비트 랜을 연결하고 접속하는 것이라면 조금 빠를 수도 있겠다.

하지만 서버실 밖이라면 같은 대한민국 내에서 이뤄지는 통신에서 사람은 그 속도 차이를 체감하기 힘들다.

수강신청이 느리면 공유기 문제이거나 램이 부족하거나 드물게는 랜 케이블 연결 단자가 불안한 경우다.

좋은 컴퓨터를 쓰자.

마치며

너무 급하게 써서 정신이 없다.

수강신청 서버는 참 흥미로운 연구 대상이다.

비록 우아하지는 않아도 저예산과 마감 독촉이라는 극한 환경에서 이렇게 안정적으로 작동하는 서버 프로그램을 작성하는 것이 쉬운 일은 아니다. 그래서일까, 더 속을 뜯어보고 싶다.