안녕하세요. 패키지형 블로그 PLUG를 개발한 JCE 미디어서비스실의 웹프로그래머 이지홍입니다.
처음 이곳에 글을 쓸 기회가 주어졌다는 소식을 들었을 때 신입 개발자인 제가 어떤 포스팅을
하면 좋을까 많은 고민을 했습니다. 하지만, 프로그래밍을 사랑하는 한 명의 개발자로써 제가
아는 내용을 여러 블로거분들과 함께 이야기 하고 싶은 마음으로, 이번에 PLUG의 개발과정에
대한 짧은 이야기를 포스팅하는 것이 좋겠다고 생각했습니다.

눈물 없이는 들을 수 없는…은 훼이크고.. 조금은 흥미로운 JCE 미디어서비스실의 블로그,
PLUG의 탄생과정, 이제 그 이야기를 시작해 보겠습니다^_^

인턴십 3개월 차, 어느날 오후. 저희 팀장님께서 말씀하셨습니다.
"지홍씨 인턴기간의 마지막 과제로 블로그를 만들도록 하세요!"

헉. 갑자기 블로그를 만들라니.. 평소 없던 두통이 생기는 듯 했습니다. 이런.
당시의 저는 블로그에 포스팅을 자주하거나, 그것에서 재미를 느끼는 블로거도 아니었고,
물론 블로그를 개발해 본 경험도 없었습니다. (지금은 개인 블로그를 운영 중입니다. 자잔)
급작스럽게 날아 들어 온 미션에 당황했지만, 인턴십 과정 동안 익혀두었던 오픈 소스
자바 프레임워크인 Struts2 그리고 Jquery와 같은 자바스크립트 라이브러리를 이용하여,
유연하고 효율적으로 동작하고, 또 크로스브라우저를 지원하는 웹 어플리케이션을 만들어
보면 어떨까 하는 개발자적 욕심이, 제 마음 속 깊숙한 어느 곳에서부턴가 스멀스멀 기어
나오는 것을 느낄 수 있었습니다. 또, 아직 학생의 신분이던 제가, 블로고스피어(blogosphere)와
소통 할 수 있는 플랫폼을 새롭게 만들어 낸다는 것이, 생각해보니 너무 근사한 일이라고
생각되었고요. 그리고 매번 프로그래머들끼리만 프로젝트를 진행하였는데, 이번 기회를 통해
HTML 개발자, 웹 기획자, 웹 디자이너 그리고 플래시 개발자 등 다양한 직종의 사람들과 작업
할 수 있다는 생각에 가슴 한 켠에 뜨거운 무엇인가가 샘솟았습니다.

개발자가 바라보는 블로그 기획
약 1개월 가량의 기획회의를 통해 PLUG의 컨셉이 블로그스러운 클래식함을 기본으로 하여
사이트 구석구석에 edge를 주는 방향으로 모아졌습니다. 저는 기획회의가 진행되는 동안
국내외의 웹사이트를 찾아보고, 최근 트렌드와 자바스크립트 및 Ajax 기술을 조사하였으며,
그 가운데 특히, 다음의 항목들을 유심히 살펴보았습니다.
 
웹사이트를 구성하는 UI와 사이트의 기능들이 크로스브라우저를 지원하는지의 여부.
자바스크립트의 코드 사이즈와 적용 및 수정의 용이성.
Ajax 사용시 "뒤로가기" "앞으로" 등의 history 기능을 대체 할 수 있는 방법.
Ajax 통신시 웹브라우저가 XML을 파싱해야하는 불필요한 비용을 배제하기 위한 방법.(JSON 사용)

블로그에 적용해보고 싶었던 새로운 기술과 현재의 웹트렌드를, 적어놓은 페이지만 해도
양이 엄청났을 겁니다. 욕심이 많아서죠. 하지만, 욕심처럼 모든 것을 다 블로그에 적용할
수는 없었습니다. 제 능력과 일정도 문제지만, 사용하게 될 기술이 블로그의 아이덴티티를
흐리는 장애요소가 되어서는 안 된다는 생각이 들었기 때문입니다. 다시 말해, 하나의 웹
사이트를 오픈 한다는 것은 개발자의 욕심뿐 아니라 제작에 참여하는 모든 구성원들의 의도를
담아낼 수 있어야 한다는 것이 더 중요하다고 보았기 때문입니다.

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

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

작은 문제들이 발생하다
블로그를 개발하면서 몇 가지 작은 문제들이 있었습니다. 그 중 가장 머리를 아프게 했던 부분이
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=".." mce_href=".."></A> 태그로 감싸 삽입하게 되는데 문제는 사용자가 첨부한 이미지를
추가한 다음, 삭제하였을 때 발생하였습니다. 에디터에서 선택된 이미지를 삭제할 때, <IMG>
태그만을 삭제하고 <A>태그는 삭제하지 않아 해당 포스트의 이미지들을 겔러리형식으로 보여줄
때 삭제된 이미지도 함께 보여졌습니다. 해당 문제의 해결책으로 다양한 방법들을 모색하였으며,
그 가운데 JDK 1.4버전부터 지원되는 String객체의 ReplaceAll 메소드에 정규표현식을 사용하여
<A>태그를 삭제하는 방법을 채택하여 해결하였습니다.

  
 
이지홍이 신입 프로그래머 이지홍에게
신입 웹프로그래머가 사이트를 개발하기전에 고려해야 할 가장 중요한 부분이 무엇인지 다시 한
번 생각해 보게 됩니다. 얼리어답터에 속하는 저는, 기존 기술의 단점을 보완하고 새로운 기능을
추가한 기술들을 적극 도입하여 그것들의 신선함을 느껴보고 싶었습니다. 하지만, 기존 인프라에
대한 충분한 이해 없이 새로운 기술을 맹목적으로 도입하는 것은 위험한  생각이란 걸 뒤늦게
깨달았습니다. 이러한 실수는 프로젝트 막바지에 이르러 테스트 서버에 PLUG를 오픈하였을 때,
심각한 문제점들을 드러내게 되었습니다.

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

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

PLUG를 개발한 시간들이, 저에게는 많은 것을 생각하는 시간이 되었습니다. 아침에 눈을 떠,
다음 날 아침이 찾아오기까지. "어떻게 하면 잘 만들 수 있을까?" 만을 고민했었고 (정말로!)
시간이 갈수록 저의 부족한 면들과 하나 둘씩 마주하게 되었습니다. 하지만, 그 와중에도 제가
분명하게 알 수 있었던 것은 PLUG가 많은 사람들에게 소개되는 그 순간이었습니다. 처음 제가
개발한 프로그램이 서비스하게 되었을 때의 뿌듯한 마음보다, 여러분이 보시고 있는 이 PLUG가
서비스되고 있는 모습을 바라볼 때 저는 더 애틋한 마음이 생긴답니다.

"프로그래머도 임상심리학 책을 읽어야 한다."

제가 항상 읽으며, 그리고 인상 깊게 간직하는 한마디처럼, 아무리 좋은 프로그램을 만들어도
정말 중요한 것은 "프로그램의 기능이 아니라 얼마나 많은 사람들로부터 사랑 받을 수 있는 가"일
것이라고 생각합니다. 앞으로 PLUG 내에 잘못된 요청에 대한 처리 로직과 관리자 페이지의 사용자
편의성을 증대하기 위한 UI개편 등 보완작업에 박차를 가할 예정이고요, 유저에게 사랑 받는
PLUG와 JCE 미디어서비스실. 그리고 프로그래머 이지홍이 되도록 노력하겠습니다. 더욱 발전하고
따뜻한 모습으로 성장하는 저희의 모습, 많은 관심을 가지고 지켜봐 주세요. ‘_’