필자가 처음에 WEB을 접했던건 아주 오래전이다. 아직 VT 기반의 통신이 주였고 많은 사람이 VT 기반의 통신을 시작하기 시작할때 였다. 당시에 두산에서 서비스 하던 인터피아라는 유료 계정 서비스를 이용하여 처음으로 UNIX SHELL을 접하게 되었고, 그 이후에 ppp 또는 slip 서비스를 이용해서 처음으로 WEB을 접했을때는 정말 놀라웠다.

단순히 TEXT 기반의 통신에서, 아니 활자 만으로 이루어져 있던 텍스트 북에서 삽화가 함께한 책을 처음 발견 했을때의 놀라움 정도랄까? 이미지와 함께 볼 수 있는 인터넷 문서라니! 하지만 그 이상도 그 이하도 아니었다. 아직 세상은 Client Side에서 작동되는 어플리케이션이 대세였고, 온라인은 텍스트 기반이었으며 당시에 접한 WWW은 나에게는 단지 그림책일 뿐이었다.

언제부터인가? VT 통신이 정점을 찍고 하향 곡선을 그리기 시작했다. 그리고 발전 가능성이 깊다고 기대 되어지던 WEB 세상은 하나 하나 늘어나기 시작하고 VT 망의 10년에 가까운 데이터와 커뮤니티를 가진 업체들은 그 힘을 조금씩 잃어 가기 시작했다. 그때 까지만 하더라도 WEB 은 정적이었고 유저의 시스템에서 돌아가는 어떤 시스템들 보다도 사용자의 편리성은 결여 되어 있었으며 만약을 위한 준비 조차 힘들게 보였다.

벌써 상당히 오래쓴 테터 툴스이지만 몇일 전에 새 글을 포스트 하다가 우연히 이 에디터의 기능이 눈에 들어왔다. 지금까지는 별 생각 없이 사용했지만 그 기능들을 내가 인지 하고 나서는 놀라움에 사로 잡혔다.

아니. 단 6년만에 이렇게 놀라운 발전이 있었나?

그렇다. 웹은 끊임 없이 발전했다. Windows Application이 Windows 95가 나오면서 MSDOS의 TEXT 기반의 시스템에서 GUI 시스템으로 변경 되고 나서의 발전 만큼이나, 유저가 소프트웨어를 직접 설치해서 사용하는 어플리케이션에는 절대 따라 오지 못할 것만 같았던 WEB이 이제는 Server Side에서도 충분한 처리를 하고 다양한 표현 방법을 가질 수 있게 구성된 HTML과 그것을 효과적으로 (물론 사용에는 조금 스트레스를 불러 오지만) 컨트롤 할 수 있게 해주는 Javascript 덕이다. (비록 Windows 에서는 재미를 보지 못한 Java지만 WEB 에서는 그 목적 이상을 달성한 Java에게 갈채를-_-)

큰 편리함이지만 큰 불편함이었던 마우스에 의존 하는 시스템, 즉 단축키 시스템에 의한 직접 호출 기능의 부족과 정적으로만 생각되어지던 이미 출판 되어 버린 문서와 같은 HTML의 동적 변환 ( HTML + JAVASCIPT 결합물인 Dynamic HTML), 어느 시스템에서도 동일한 환경을 보장하는 SSI 시스템까지.

이제 컴퓨터를 한다는 개념 자체가 온라인 상태에서의 어떤 행위를 이야기 할 정도로 그 의미가 변했다. 더 이상 오프라인, 사용자의 시스템에 국한 된 시스템은 더 이상 그 값어치를 지니지 못하고 모든건 옮겨 가고 있다. 아니 이미 거의 대부분이 옮겨져 버렸다. (이것은 10년 전에는 오프라인에서도 컴퓨터를 가지고 할게 많았지만 지금은 단 10분만 오프라인 상태에서도 컴퓨터로 할게 없다는 점에서도 알 수 있다 -_-)

아마도 이제 컴퓨터의 모든 시스템은 온라인 클라이언트화 될 것이고, Windows Application의 설 자리는 점점 잃어 갈 것이다. HTML과 Javascript 그리고 최근에 비약적 성장을 하고 있는 Flash 가 그 자리를 조금씩 대체 해 나갈 것만 같다.

DOS 시절 부터 유저 소프트웨어 프로그래머 였던 나로써는 조금씩 사라져 가는 과거의 향수와 더욱 더 편리하고 강력해지는 새 환경 변화속에서 묘한 기분을 느낄 수 밖에 없다..

완료 된지 시간이 조금은 지난 프로젝트. 게임으로 따지면 서비스가 시작된지 조금 된 게임들. 프로그램으로 따지면 최초 개발 이후 고객에 따라서 커스터마이징을 하고 있는 과정 정도에 있는 경우에 해당한다.

어떤 프로젝트든지 완벽한 문서와 모든 코드를 숙지 할 수 있는 교육 과정이 있다면야 문제 없지만, 현실적으로는 그런 일은 드물다. 아니 있을 수 없다고 해야 할런지..

완성된 프로젝트를 이어 받아서 커스터마이징 및 유지 보수, 추가 작업을 하다 보면 가끔은 이런 기능이 있으면 좋을 텐데 하고 관련 자료를 찾아서 적용 준비를 하다보면 평소에는 보이지 않던 파일명과 클래스명이 보이곤 한다. 혹시.. 라는 마음에 찾아 보면 역시나 oTL.. 이미 구현이 되어 있지만, 코드 깊은 곳에 묻혀 있어 알 수 없었다던가 특수한 경우에만 작동하게 되어 있다던지 하는 일이 있다.

나름 난감하다. 그 기간동안 이런게 있다는 사실을 몰랐다니! 아쉬워 해봐야 소용 없다.. 하지만 다른 숨겨진 기능을 찾기에는 유지 보수에도 시간이 부족하다. 결국 프로젝트를 구성하고 있는 모든 구성요소를 모른채 계속 일을 이어 갈 수 밖에 없다.

oTL

이런 일은 가끔 예상치 못한 문제를 낳기도 한다.

예를 들어서 게임에서는 유저의 시야권에 다른 케릭터가 접근하게 되면 해당 사실을 서버에게 알려준다. 그런데 완성되고 나서 몇년이 지난후에 새 개발팀이 해당 프로젝트를 맡아서 진행하다가 이미 시야에 들어온 유저의 데이터의 갱신이 필요한 일이 생겼다.

그래서 작업 방법을 고민하다가 시야에 유저가 들어왔을때 해당 사실을 통보해주는 모듈을 사용하여, 같은 UserID를 가진 User Object가 다시 전송되면 업데이트 되는 방식으로 구현. 서비스를 한동안 진행하던 중에 우연히 코드중에 유저의 정보만을 업데이트 시켜주는 현재는 자주 사용되지 않는 패킷 모듈이 있었음을 발견 한다.

그런데 문제는 서버에서는 유저 데이터를 업데이트 시켜줄때 사용하는 정보와 유저가 시야에 들어왔을때 사용 되는 데이터가 동일할 것으로 예상. 공통적으로 유저 정보를 보내는 모듈을 사용하고 있었다.

어느 한쪽이 패킷 규약이 변경되면 다른 한쪽 역시 같은 모듈을 사용하므로 같이 변경 되는 그러한 방식.
그런데 서버 개발자도, 클라이언트 개발자도 이것을 모르고 있었다는거.. 결국 패킷은 데이터가 밀리는 현상이 발생. 특정 유저의 경우에는 예상치 못한 값에 의한 클라이언트 크래쉬가 일어나게 되었다. ;

난감..

한참동안을 원인을 못찾다가 이런걸 발견 하게 되면 정말 가슴이 아프다. 왜 조금 더 꼼꼼하게 살펴 보지 못했을까.. 하는 아쉬움은 이미 늦어 버렸으니까..