계절학기 수강신청을 하는 날이다. 수강신청 시작 30 분 전 쯤에 일어나 미리 컴퓨터를 켜둔다. URL 입력하는 시간도 줄이기 위해 브라우저를 미리 띄워 주소를 입력한다. 이제 시계가 정각을 가르킬 때에 엔터키만 누르면 된다.

정각 땡.

엔터키를 누르고 어서 첫 페이지가 뜨기를 기다린다. 느릿느릿 로그인 화면이 뜨면 로그인 정보를 입력하고 들어가기 버튼을 누른다. 부라우저는 한참을 버벅대고 나서야 수강신청 화면의 일부를 화면에 그려댄다.

그 와중에 강좌번호 입력란이 보이자마자 값을 입력한 다음, 조회 버튼이 있음직한 곳을 그냥 대충 클릭한다. 해당 강좌들의 정보를 달라는 요청이 웹서버로 보내졌을 터이다. 한참 시간이 흐른뒤 화면에는 페이지를 표시할 수 없다는 내용이 나타난다.

빌어먹을

잽싸게 창을 닫은 후 쿠키 파일들을 지우고 다시 로그인 시도를 하려고 브라우저를 연다. 그러나 이젠 로그인 페이지조차 뜨지 않는다.

한참을 이와 같은 반복작업을 한 후에야 비로소 내가 원하는 강좌를 조회할 수 있게 됐지만, 이미 모든 강좌의 인원이 다 찬 후다. 도대체 다른 얘들은 어떻게 수강신청을 한 걸까? 라는 의문이 생긴다.

나중에 초안지 들고 수강신청을 해도 가능할 것 같긴 한데, 나이도 많은 놈이 수강신청도 제때 못하고 신청서 들고가서 눈치볼 걸 생각하니 벌써부터 속이 터진다.

수강신청 시스템은 일년 중 며칠만 사용되고 첫 개시하는 날 부하가 엄청 많이 걸린다. 문제는 모든 요청을 동시에 처리하는 것은 이 시스템의 목적과 동떨어져 있다는 사실이다. 이 시스템의 가장 중요한 처리기준은 순차작업이어야만 한다. 작업 처리가 조금씩 늦어지더라도 먼저 온 사람은 반드시 먼저 서비스를 받게 해줘야 한다. 지금 처럼 수강신청 날 마다 시스템이 다운되는 상황하에서는 운이 좋은 사람이 서비스를 먼저 받는다.

수강신청 시스템은 웹 기반으로 되어 있다. 웹은 UI 를 만들기가 쉽다는 것과 connection 을 관리할 필요가 없다는 것등의  여러가지 장점이 있다. 그러나 지금처럼 반드시 먼저 들어온 작업을 먼저 처리해줘야 하는 경우라면 문제가 발생한다. 이를 위해서는 웹서버와 데이터베이스 사이에 작업을 큐잉해주는 미들웨어가 따로 필요하기 때문이다. 미들웨어는 주어진 프로젝트에만 쓸 수 있게 만들든 아니면 범용으로 만들든 개발비용이 싸지 않다.

그렇다면, 이 시스템의 개발은 웹이 아니라 어플리케이션을 선택했어야 한다. 이 경우 서버 프로그램을 따로 작성해야 하고 User Interface 를 만들어줘야 한다는 부가적인 작업들이 생기지만, 시스템 전체적으로는 아마 웹 보다 안정적이었을 것이다. 왜냐하면, 첫째로는 네트워크 트래픽이 감소될 것이고, 둘째로는 웹보다 기능의 확장이 용이하기 때문이다.

어쨋든 내가 반드시 들어야 되는 과목은 신청하질 못했고, 전산원에서 여전히 클릭을 해대며 '수강 인원 초과입니다.' 메세지만 보고 있다. 수강신청 시작 시간을 잘못 알아서 예정 시간보다 무려 한시간 반이나 일찍 일어났으나 성공하지 못하니 배알이 꼬이는 건 당연하다.