[Will] 창조본능, 프로그래머!

헉..  갑자기 블로그를 만들라니.. 없던 두통이 생기는 것 같았습니다.

그 당시의 저는 포스팅의 재미를 아는 블로거도 아니였고, 블로그 개발경험도 없는 상태였으니까요.. (지금은 개인 블로그를 운영중입니다.)
하지만, 인턴쉽 과정을 통해 익혔던 오픈소스 자바 프레임워크인 Struts2 그리고 Jquery와 같은 자바스크립트 라이브러리를 이용하여, 유연하고 효율적으로 동작하며, 크로스브라우저를 지원하는 웹 어플리케이션을 만들어 보고픈 개발자의 욕심이 슬그머니 얼굴을 내밀었습니다.

또, 아직 학생의 신분이었던 제가, 여러 블로거들과 소통 할 수 있는 하나의 플랫폼을 만드는 일이 정말 근사한 일이라 생각되었고, 늘. 프로그래머들끼리만 프로젝트를 진행하였는데,
이번 기회를 통해 HTML 개발자, 웹 기획자, 웹 디자이너 그리고 플래쉬 개발자 등 다양한 직종의 사람들과 작업 할 수 있다는 생각에 가슴 한켠에 뜨거운 무엇인가가 샘솟았습니다.

1. 개발자가 바라보는 블로그의 기획

2. 블로그의 전체 설계
 
PLUG는 MVC패턴의 오픈소스프레임워크인 Struts2로 개발되었고, Spring IOC를 사용하여 웹 컨테이너에 의해 객체의 수명주기를 보다 효율적으로 관리 할 수 있도록 구성하였으며, 트랜잭션 및 커넥션 풀링 기술도 Spring의 그것을 사용하였습니다.
MVC 패턴으로 개발하여, 추가적인 개발비용과 고민 할 요소들이 발생하였지만, 블로그를 오픈한 뒤에 기획자 및 유저의 요구사항을 반영하여 업데이트 할 때 마다, MVC 패턴을 따른 웹어플리케이션의 유연성과 유지보수의 편리한 장점들을 피부에 와닿을 정도로 느낄 수 있었습니다.

3. 블로그의 상세 기술

이밖에도 Fancy Url을 지원하기 위하여 UrlRewriter를 사용하였으며, RSS 피드를 구독하고 발행하기 위하여 Rome 모듈을 사용하였습니다.
블로그를 관리하는 관리자 페이지에는 불필요한 요청 횟수와 웹 리소스의 로드를 최소화하기 위하여 Ajax 탭 패널을 사용하여 그때그때 원하는 데이터만을 가져오도록 효율성을 극대화였으며, 특히, 관리자페이지의 대부분을 Ajax로 개발하면서, 사용자로부터 전달받는 이벤트(버튼 클릭 등)가 얼마나 소중한지, 그리고 페이지 전환의 비용이 얼마나 큰지를 체감하게 되었습니다.

4. 헤프닝

블로그를 개발하면서 몇 가지 작은 문제들이 있었습니다.
그중 가장 골치를 썩었던 부분이 Fancy Url 사용에 따른 한글 파라미터 처리 문제와 라이트박스와 연계된 에디터 문제였습니다.

한글 파라미터 처리 문제는 리퀘스트에 전달할 파라미터를 Fancy Url형식으로 전달 할 때, 해당 파라미터를 웹브라우저에서 Url로 인식하여 다른 캐릭터셋으로 인코딩하여 전달하는데서 발생하였습니다. 예를들어,  "http://blog.jceworld.com/plug/Search/Tags/이지홍" 이라는 형태의 Fancy Url이 있을때 이지홍이라는 한글이 웹브라우저에 의해서 utf-8로 인코딩되어 WAS의 앞단인 아파치에 전달되고, 아파치가 전달한 값을 받은 euc-kr로 설정된 톰캣은 해당 값을 비즈니스로직에서 사용 할 수 없게 만들어 버렸습니다. 이 문제를 해결하기위해 Url에 한글 파라미터를 전달할때 비즈니스 로직에서 파라미터값을 인코딩하는 작업을 선행하였, 한글 파라미터의 전달방식 또한 Fancy Url이 아닌 일반 QueryString 포맷을 따랐습니다.

그 다음, 에디터와 연계된 라이트박스 문제는, 포스팅에 이미지를 삽입하여 View 페이지에 해당 이미지를 클릭하였을때, 라이트박스 기능을 활성화 시키기 위하여 <IMG>태그를 <A rel="lightbox" href=".."></A> 태그로 감싸 삽입하게 되는데
문제는 사용자가 첨부한 이미지를 추가한 다음, 삭제하였을 때 발생하였습니다.
에디터에서  선택된 이미지를 삭제할때, <IMG>태그만을 삭제하고 <A>태그는 삭제하지 않아 해당 포스트의 이미지들을 겔러리형식으로 보여줄때 삭제된 이미지도 함께 보여졌습니다.
해당 문제의 해결책으로 다양한 방법들을 모색하였으며, 그 가운데 JDK 1.4버전부터 지원되는 String객체의 ReplaceAll 메소드에 정규표현식을 사용하여 <A>태그를 삭제하는 방법을 채택하여 해결하였습니다.
 
5. 신입 웹프로그래머분들에게 전하는 말

신입 웹프로그래머가 사이트를 개발하기전에 고려해야 할 가장 중요한 부분이 무엇이라고 생각하십니까?
얼리어답터인 저는, 기존 기술의 단점을 보완하고 새로운 기능을 추가한 기술들을 적극 도입하여 그것들의 신선함을 느껴보고 싶었습니다.
하지만, 기존 인프라에 대한 충분한 이해없이 새로운 기술을 맹목적으로 도입하는것은 위험한  생각이란걸 뒤늦게 깨달았습니다. 이러한 실수는 프로젝트 막바지에 이르러 테스트 서버에 PLUG를 오픈하였을때, 심각한 문제점들을 야기시켰습니다.
무슨말인지 감이 안잡히신다고요? 그러면 한가지 예를 들어 포스팅 작성시 파일 업로드 기능을 추가한다고 가정해 보겠습니다.
위에서 언급한 좁은 시야를 가진 개발자는 새로운 팝업창을 뛰우고 그 창에서 SUBMIT을 통해 파일을 업로드하는 기존의 방법을, AJAX 기술을 사용해서 팝업창이나 페이지 전환 없이 파일을 업로드 할 수 있는 기능으로 대체하려 할것입니다. 그리고 만약 그 방법이 성공한다면 그 결과물을 보며 뿌듯함에 행복해 하겠지요. 얼핏보면 당연한 이야기로 이해 할 수 있습니다만 만일, 회사에서 공통으로 사용하는 업로드 모듈이 있으며, 해당 모듈의 결과페이지에서 Redirect를 통해 업로드된 url 및 파일의 정보만을 되돌려주도록 구성되어 있다면 어떻게 하시겠습니까? 아마 최소한으로는, 이미 만들어놓은 기능을 뜯어고쳐 뒤늦게 회사의 공통 모듈과 연동 할 수 있도록 추가 개발을 하거나, 자신의 본래 기능을 포기하고 회사의 모듈을 연동하는 일이 불가피해 질 것입니다. 이밖에도 웹 서버의 로드벨런싱 환경을 처음 접하는 신입 개발자들이 클라이언트의 상태저장 방법과 SingleTon객체의 수명을 관리할때도 이러한 문제점들이 발생시킬 수 있습니다.
몇일밤을 지새 만든 기능들을 결국 무용지물로 만들거나, 심지어 더 나은 기술들을 그 이전 기술들로 퇴보시켜야만 하는 아픔을 겪지 않으려면 개발자는 만능이 되어야 합니다.
완벽하고 혁신적으로 동작하는 프로그램도 결국, 그 프로그램이 동작하는 환경에 대한 충분한 이해가 바탕이 되어야 한다고 생각합니다.

5. 버그에 대한 저의 생각

"Java.util.Arrays에 포함된 binarySearch 메소드가 ArrayIndexOutOfBoundsException 에러가 발생할 가능성을 포함하고 있음"을 아십니까?
얼마전까지만해도 저는, 제가 만든 프로그램에서 발생하는 버그에 매우 민감하게 반응하였습니다.
자신의 일에 완벽하지 못하고 더 신중하지 못해 버그를 발생 시킨다고 믿고 있었기 때문입니다.
하지만 어느 책에서 읽은 글들이 버그에 대한 제 태도를 좀 더 너그럽고 넓은 시야로 이끌어 주었습니다. 
"프로그래머에게 중요한 것은 정답을 찾는 능력이 아니라, 질문 그 자체를 정확하게 구성하는 힘이다."


6. 마치며

 PLUG를 개발한 시간들이 제게는 참 많은 것을 생각하는 시간이 되었습니다.
아침에 눈을 떠, 다음 날 아침이 찾아오기까지. "어떻게 하면 잘 만들수 있을까?" 만을 고민했었고, 시간이 갈수록 저의 부족한 면들을 하나 둘 만나게 되었습니다. 하지만, 그 와중에도 제가 분명히 알 수 있었던 것은 PLUG가 여러분 앞에 서비스 될때의 모습이었습니다. 처음 제가 개발한 프로그램을 서비스하게 되었던 뿌듯한 마음보다, 서비스되고 있는  PLUG를 볼때 더 애틋한 맘이 생깁니다.
앞으로, 잘못된 요청에 대한 처리 로직과 관리자페이지의 사용자 편의성을 증대하기 위한 UI개편 및 기능 추가 등 더 나은 서비스를 만들기위해 보완할 부분들이 남아 있지만, 항상 초심을 잃지 않고 더 나은 PLUG의 모습을 보여드리기 위해 노력해 나가겠습니다.