Language 사이트 유지보수 및 개선방법

http://myhome.naver.com/hanuldt한달간 통계사이트 유지보수를 하면서 느낀 경험을 얘기해보기로 한다. 이전에도 유지보수
경험이 없던 것은 아니지만 이번에 조금 절실히 생각한 바가 있어 글을 써보기로 했다.
업체를 통해서 들어간 것이 아니고 혼자서 개인사업자 자격으로 작업한 것이라서 이 글을
읽는 이와 입장이 다를 수는 있겠지만 어떤 방식으로든 도움이 되리라는 생각으로 이 글을
써본다.

조언편
맨 먼저 조언을 하나 해본다면 과욕을 부리지 말라는 것이다. 내 능력이 이만큼 할 수
있으니까 한번 해보겠다며 자신감을 내보이다 보면 시간 내에 정해진 내용을 끝내지 못하는
경우가 있을 수 있다. 정해진 내용을 마치지 않은 상태에서 요청하지 않은 이런 것도 해주지
않았느냐고 반문할 수는 있겠지만 상대편이 인간성이 별로라면 피박을 쓰는 건 개발자의 몫이
되고 말 것이다. 나는 그나마 인간성이 좋은 사람을 만나게 된 것 같아 다행이다. 개발을
하다보면 진도가 잘 나가기도 하고 그것을 기준으로 삼아서 얼마만큼은 내가 할 수 있을
거라는 예상을 할 수 있지만 상대편에게는 그런 마음을 아주 조금만 드러내면 좋을 것 같다.
어디에선가 소위 삽질을 할 거리가 있어서 며칠간을 삽질만 하다가 보내는 경우가 있으니
진도가 빠른 것은 이때를 위한 시간 저축이라고 생각하자.
둘째도 역시 과욕을 부리지 말자는 얘기다. 자신이 개발했던 것이든 남이 개발했던 것이든
특히 남이 개발한 것일 경우에 완전히 뜯어고치고 싶은 생각이 드는 경우가 있다. 내 경우는
복잡하게 만드는 것을 싫어하는 편이다. 간단하게 누구나 이해할 수 있는 수준에서 코드를
만들려고 노력한다. 예를 든다면 if ~ else 구문이 계속 중첩되어 있는 문장을 상당히
싫어한다. 소스를 만든 사람이 처음부터 그렇게 할려고 한 것은 아니겠지만 그런 소스를 한참
쳐다보다보면 정신이 혼미해지고 답답함이 치밀어 오르다가 잠시 진정을 하고 더 간단하게
만들 수 있는 방법이 없나 한참 고민을 하게 된다. 하지만 조금만 참도록 하자. 일단 기존의
것을 크게 고치지 않은 상태에서 주어진 부분(이게 또 애매하긴 하다. 처음에 얘기했던 것
보다 요구하는 게 많아지는 게 보통의 경우인 것 같다.)을 먼저 해나가는 게 좋은 선택일
것이다.
셋째는 자신이 작업하고자 하는 사이트에 대한 관련정보를 많이 알아보고서 시작하는 것이다.
나는 얼핏 겉모습만 보고서 별게 없겠지 하면서 이게 왜 한달이나 시간을 잡은 것일까
했는데, 막상 들어와서 보니까 로직이 꽤 복잡하다는 것을 알게 됐다.

개선방법편
당연히도 나는 개발자라서 기획이나 고객 차원에서 개선방법을 이야기할 수는 없다. 개발자
차원에서 어떻게 쉽게 유지보수를 할 수 있고 또한 차후에도 유지보수가 쉽고 확장성이 있는
방법을 나름대로 찾아본 것이다.
개발기간이 길다면 어떻게 개발할 것인가 고민을 많이 해도 되겠지만, 기간이 턱없이 짧다면
그것을 요구하는 사람이 높은 품질이 필요없으니 돌아가게만 하면 된다는 생각을 가지고 있는
것 같으니 그냥 노가다를 해버리면 그만일 수도 있다. 하지만 노가다를 하는 가운데서도
생산성을 살리는 방법을 찾아보자는 것이다.
내가 처음 직장생활을 할 때 별 쓸모도 없는 인간이라고 사장이 생각해서인지 노가다성 일을
가끔 내게 시켰다. 그럼 그 일을 그냥 묵묵히 참고 하면서 시간을 때우느냐, 아니면 노가다를
조금 편하게 하는 방법을 찾을 것이냐 선택의 기로에 선다. 그러면 내 경우는 조금이라도
방법이 있는 것 같으면 후자로 선택을 하는 경우가 많았다. 그래서 노가다를 편하게 하고
나머지 시간을 놀거나 책보거나 하면서 보냈던 기억이 있다.
여기에 있는 방안들은 기존에 생각하고 있었던 바와 이번에 유지보수에 들어가면서 주어진
시간도 많지 않은데 내가 쓸데없이 욕심을 부리고 고민을 해서 나름대로 찾아본 방안이다.
개발기간이 많은 이들에게나 짧은 이들에게도 쓸모가 있을 것이라 생각한다.

첫째, 기능은 분리하되 창구는 통일하라.
기능 분리는 말할 필요도 없이 소스를 복잡하게 만들지 말자는 이야기다. DB 관련 클래스에
다른 패러미터를 받아서 파싱하는 기능까지 넣을 필요가 없는 것이다. 소스가 복잡해지면
기능 수정 또는 추가 내지 에러를 고치려면 소스를 만든 사람이라고 해도 머리가 상당히
복잡해질 수밖에 없다. 기능분리는 차츰차츰 해보다보면 익숙해지는 문제이기도 하지만
처음부터 염두에 두고 있어야만 하는 문제이다. 분리하는 가운데서도 통합해야 할 것은 해야
한다. 표를 하나는 HTML페이지로 보여주고 또 하나는 엑셀로 보여준다고 할 때 각각의
파일로 작성하는 경우가 많고 나도 전에는 그렇게 했었다. 하지만 이번 통계 사이트의
경우는 대부분의 통계표가 엑셀 파일로도 저장이 되게 되어 있었고 페이지도 따로 만들어져
있었다. 이 경우 처음에 하나의 에러를 고쳐야 할 때 두 개의 JSP파일(HTML생생 파일과
XLS생성 파일)을 동시에 고쳐야 했고 어쩌다 둘다 고치기는 했는데 업로드는 하나만 하고
하는 경우도 생길 수 밖에 없었다. 창구를 통일하지 않으면 어디선가 샐 가능성이 있는
것이다. 그래서 생각한 것이 패러미터 print에 excel로 값이 넘어온 경우에는 contentType을
엑셀로 지정하고, 아닌 경우에는 HTML로 지정하는 것이다. JSP파일 맨 위에 contentType을
정하는 코드만 넣으니 따로 엑셀 파일 생성 JSP 파일은 필요없게 되었고 에러 가능성도
없어졌다.

둘째, XML을 이용하라.
비슷한 유형인데 제목이나 색, 그림 정도만 다른 페이지들이 여러개가 있을 수 있다. 내
경우에는 매 통계페이지 앞에 년도를 선택하는 페이지가 20개가 넘게 있었다. 그 페이지에는
해당 통계에 해당하는 제목이 있을 뿐이었다. 그리고 각 Form의 action 정도가 달랐다.
그래서 이 페이지들은 통일성 있게 한 페이지로 만들고 해당 제목과 action은 XML파일에
지정하여 값을 가져오는 형태를 취했다. 그럼으로써 관리해야 하는 JSP페이지가 훨씬 많이
줄어들었다. 혹 제목을 바꾸자는 요구가 있으면 XML파일만 바꾸면 되는 것이다. 이 역시
창구를 통일하는 예에 해당할 것이다.

셋째, SQL코드는 따로 관리하라.
내 경우는 역시 XML을 이용하였다. 내가 작업한 곳이 통계사이트라서 그런지 SQL문이 상당히
복잡해지는 경우가 또한 많았다. 40라인이 넘는 SQL코드를 StringBuffer를 생성해서 계속
append해가고 그러면 별 문제 없겠지만 역시나 단순하지 않은 SQL코드라서 속도가 만족치
못할때나 혹 값이 맞지 않게 나올 때 다르게 바꾸어봐서 적용을 시켜야만 했다. 바꿔볼
때마다 새로 괄호 쒸워서 append하는데 혹시 SQL코드 내에 있던 괄호하고 자바코드내의
괄호하고 혼동돼서 그 때문에 SQL에러가 나오는 경우를 누구나 한 번쯤은 겪어 봤을 것이다.
그래서 결국 이도 역시 XML 파일에 지정하고 그 안에 들어가는 argument만 자바 파일에서
바꾸는 형태를 취했다. 그럼으로써 새로운 SQL코드를 테스트 할 때는 xml파일만 바꾸면
가능하게 되었다. 오라클에서 SQL PLUS로 테스트해보고 그대로 XML파일에 복사를 하면 되는
것이다. 어떤 이들의 코드를 보면 SQL 코드만 따로 모아서 자바 파일로 만들어 놓는 경우가
있는데 SQL을 바꿀 때마다 새로 컴파일 해야 하기도 하고, 라인 수가 많은 SQL 코드를
만들때는 역시 +나 아니면 StringBuffer에 append해야 하므로 생산성 면에서 그다지 훌륭한
편이 못된다.

넷째, 로깅 API를 활용하라.
JDK1.4에는 로깅 API가 있다고 하지만 아직은 실제에서 써 볼 기회가 없었고 이번에는
아파치 프로젝트의 Log4J를 이용하였다. 기존에는 내가 간단하게 만든 LogWriter를
이용하였는데 로깅API를 이용하면 로그 파일에서 볼 수 있는 정보의 옵션도 많기도 하고
속도도 괜찮은 편이다. 디버깅시에 로깅API의 의미는 필수불가결하다고 밖에는 더 할말이
없다.

다섯째, 컴파일시 Make나 Ant를사용하라.
예전에 Orion Server를 처음 써볼때 EJB 개발방법에서 Ant를 이용한 설명이 있었는데
그대로 따라하니까 마지막에 ant만 도스 창에서 입력해보니까 되는 것을 보고서 꽤 놀랐던
기억이 있다. 무슨 마법 같다고나 할까. 그러다가 잊고 있었는데 이번에 유지보수에
들어가니까 이미 기존에 만들어진 패키지가 상당히 많아서 이를 각 패키지마다 따로따로
컴파일하는 게 막막했다. 그래서 결국은 Ant를 써보기로 했는데 생각보다 사용하는 게
복잡하지도 않았고 상당히 유용했다. 한번 build.xml을 만들어두고 한 패키지를 build.xml에
추가한 것 외에는 그저 컴파일시에 활용하기만 하면 되었다.

여섯째, JDK1.2이상이라면 Vector보다는 ArrayList를 이용하라.
이전에 공개게시판을 만들 때도 처음에 Vector를 이용하다가 값이 자꾸 이상하게 넘어오는게
마음에 걸려서 ArrayList로 바꾸었더니 별 문제가 발생하지 않았었다. Vector나 Vector를
변수로 갖는 클래스를 세션값에 넣고 이를 다시 가져올 때 제대로 가져오지 못하는 경우도
가끔 생긴다. 즉 Deserialize하지 못하는 경우가 있는데 Vector의 불안정성이라고 할까. 또한
Cache기능을 사용하기 위하여 Hashtable에 넣을 때도 Vector나 Vector를 변수로 갖는
클래스는 들어가지 못하고 에러를 발생시킨다. 누가 왜 그러냐고 내게 묻는다면 나는 해줄
말이 이 말 밖에 없다. "내가 안 만들었는데요." 누가 장황하게 이 이유에 대해서 설명을
한데도 알아들을 자신도 없다. 나는 자바 전문가가 아니다. 혹 동네장기 전문가라면 모를까.
하지만 장기도 안 둔지 오래니 이제는 이도 아닐 것 같다.

일곱번째, SQL을 적절히 사용하라.
프로그래머는 DB에 대한 지식을 그다지 중요하게 생각지 않는 편이 많은 것 같다. 하지만
속도가 중요시되는 시스템에 이르러서는 생각이 바뀌어야 한다. 내 경우가 통계사이트에
이르러서야 적어도 SQL정도는 좀 더 알아야 겠다는 생각이 들었다. 기존의 통계처리 코드를
들여다보았을 때 SQL문을 2백 몇 번을 실행하는 경우가 있는데(웬만한 건 이 정도이고 그
이상 SQL문을 실행해서 결과를 가져오는 것도 있다.) 속도를 체크해보니 27초 정도가
걸렸다. 한번 SQL문을 실행하고서 Vector에 그 결과값을 계속 차곡차곡 쌓아나가는
형태였다. 사용자가 많은 편이 아니고 그래도 통계를 내는 건데 이 정도는 참으라고 얘기할
수 도 있지만 해도 너무한다는 생각이 들어 한나절이 걸려 똑같은 결과를 만들어낼 수 있는
하나의 SQL문을 만들었다. SQL문 실행 속도는 오라클 관련 어플리케이션인 TOAD에서 실행
시켜보니 1초가 걸렸고 관련 빈과 JSP까지 별도로 만들어 실제 실행을 시켜보니 5초가
걸렸다. 실행속도가 5분의 1이 안 되도록 만들 수 있었던 것이다. 말하자면 그동안
어플리케이션 서버나 DB 그리고 사용자에게 참고 기다릴 줄 아는 인내심을 키워준 코드가
있었다.

기존의 사이트는 2년전에 JDK1.1.6기반에서 만들어졌다. 그때와 개발환경이 많이도 다르고
더 많은 기술과 정보가 있는 만큼 기존의 개발자들과 나를 단순비교하여 그들의 능력을
의심할 이유는 어느 곳에도 있지 않으며 나 또한 스스로가 뛰어나다고 생각한 적이 없다.
뛰어나지는 않고 다만 달리기는 좀 하는 편이다. 2년전에는 나는 그저 걸음마를 뗀
수준이라고 해야 할 정도였다. 다만 느낀 바가 있음을 그리고 조금이라도 자바 개발자들에게
도움이 되고자 이 글을 쓰게 된 것이다.

아껴둔 조언이 한가지가 남아 있다.
기존의 코드에서 많은 것을 배워라.
2년전에 SK Telecom에서 작업을 할 때 특히 기존의 코드를 바꾸면서 배운 점이 많았고 이를
근거로 해서 공개게시판을 제작했었다. 남이 만든 소스를 답습할 게 아니라 개선시켜가다
보면 자신의 실력이 부쩍 향상됨을 느낄 수 있을 것이다. 또한 잘 만들어진 소스를 분석
하다보면 언젠가 그 이상의 것을 만들어낼 수 있는 능력이 생길 것이다.

마지막으로 나의 바램을 적어본다면 이러한 것이다. 마이크로소프트웨어에 실린 어느
개발자의 글을 보고 웹 개발이란 이런 것이구나 하고서 그 글에서 내가 배운 점이 많았는데
1년전에는 그가 바로 내가 올린 공개소스게시판에서 배울게 많다고 써놓은 글을 보고 감회가
남달랐다. 그 사이에 내 실력이 그만큼 향상된 증거인 셈이다. 하향 평준화가 아닌 상향
평준화가 되는 그런 개발자 커뮤니티를 꿈꾸면서 이 글을 이만 마치도록 한다.