회사에서 작업하는 자바 웹 프로젝트 기반은 Spring 2.5 + ibatis + velocity + resin3.0.27 + oracle 이다. 뭐 아직 작업에 본격 투입된 지는 얼마 되지 않았지만, 뭐랄까.. 요즘 SI쪽의 대세가 자바라고 했던가? 마찬가지로 웹 쪽도 대부분의 대규모 서비스는 자바를 많이 사용하는 추세인 것 같다. (물론, 닷넷도 무시할 수는 없지만..)
10여 명의 중급 경력자들이 참여한 프로젝트에 잠시나마 파트타임으로 참여했었고, 지금은 그 프로젝트의 프로그래밍 유지보수 부분을 전부 담당하고 있다. 어차피 자바라는 게 객체기반이고, 초기 설정은 기존 개발자들이 추가해 놓아서 크게 내가 건드릴 설정 부분은 없고 벌써 3개월째 작업을 하다 보니 대부분이 익숙하다.
물론, 핵심 부분은 아직 건드리기에는 내가 미숙한 점이 많아서 부담스러운 부분이 많다. 그래서 우선 내가 일전에 파트타임으로 참여했던 부분부터 조금씩 역할을 크게 하는 방향으로 하고 있다. 유지보수이다 보니 우선 완제품이 나온 상태인지라, 초반에는 자잘한 업무가 많았는데, 갈수록 조금씩 기능 추가적인 부분이 많아지면서 이때부터 나의 스킬 향상을 위한 분석에 들어간 것이다. 왜 신입이 유지보수부터 하는 것이 최적인지 알 것만 같다.
지금 유지보수 작업이 들어간 3개월 동안 “내가 이것은 꼭 주의하고 명심해야 겠다” 라고 생각한 부분을 정리해 본다.
1. 백업의 생활화 혹은 앤츠를 통한 자동 빌드/백업 설정
우선, 웹 유지보수의 가장 중요한 것이 바로 백업이 아닌가 싶다. 나같은 경우 작업PC->테스트 서버->실 서버 의 3단계를 걸쳐 최종 작업물을 업로드 한다. 그래서 항상 백업 파일이 2개씩 생기는 편이다. 테스트 서버와 실제 서버에 파일명_날짜.vm 이런 형식으로 파일을 우선 백업하고, 업로드 하는 편이다. .class , .xml , .vm 등.. 그리고, 혹여나 신규 작업으로 말미암아 발생할 수 있는 에러상황이 발생할 때는 우선 바로 백업을 원복하고 다시 검토해 보는 게 최선인 것 같다.
앤츠의 설정 및 빌드 : http://guni.textcube.com/144
2. 작업 내용에 대한 기록 혹은 혼자 작업하더라도 SVN/CVS의 사용
최종 버전에 대한 기록. 이것 역시 백업과 같이 중요한 작업 중 하나이다. 왜냐면 유지보수를 하면서 변경되는 소스코드와 서비스 뷰, sql문, properties등이 있을 것이다. 그런 것들에 대한 히스토리가 없다면 일단은 추후에 인수인계가 제대로 안된다. 그리고 혼자서 소스파일 관리를 하다 보면 아무리 잘한들 소스코드가 꼬일 수 있다는 것이다.
혼자 작업하는데 SVN,CVS의 사용? 사실 상당히 귀찮은 작업이 될 수 있겠지만, 엑셀에 작업 히스토리를 기록하거나 주석으로 설명하는 것보단 훨씬 나은 듯 하다. 귀찮은 일이 많이 줄 수 있으니깐..
간단한 SVN 사용법 : http://www.hybrid.pe.kr/tt/246
간단한 CVS 사용법 : http://www.javajigi.net/pages/viewpage.action?pageId=174
3. 아무리 자신 있는 수정이라도 정책적인 부분은 상사의 승인을 받고 진행
이건 예전부터 느끼고 있었는데, 아무리 잘한다고 섯불리 나서다 보면 큰 책임을 감수해야 할 수도 있다. 내가 관리하는 사이트는 공공기관의 사이트인데, 최근에 아이핀 관련해서 도입해 달라고 요청이 왔다. 솔직히 주민번호 체크하는 방식이 아주 간단해서 아이핀 또한 그리 어렵지 않을 거다 생각했는데, “책임”이라는 것이 딱 떠오르다 보니 이 작업을 내가 책임지기는 어려울 것 같았다. 그래서 실장에게 작업이 힘들 것 같다고 이야기했다. 위에서는 외주를 준다고 하고는 내 책임을 벗어났다.
이처럼 책임 문제는 개발하면서 항상 염두해 놓아야 할 문제이다. 너무 당연한가? 자신이 기회를 잡았다고 좋아라 작업에 아무런 보고도 없이 들어갔다간 피박을 볼 수 있기 때문에, 업무에는 항상 책임이 따른다는 것을 잊으면 안 되겠다.
4. 9시~6시 중 서버 restart는 NO, 리부팅/리스타트는 7시 이후에.
윈도우 서버이다 보니 업데이트 등으로 리부팅을 할 수도 있고, WAS를 리스타트 해야만 적용되는 것들이 있다. 이런 것들은 빠른 작업반영을 위해서라면 필요한 과정이긴 하지만, 서비스되는 사이트가 5분만 접속이 안돼도 사람들은 서비스 회사에 전화를 하기 마련이다. 특히나, 그 과정에서 어떤 사람이 서비스를 사용하며 글을 작성하고 있을지 모르기 때문에 함부로 업무시간 내에 서버를 리스타트 하는 것은 위험한 행동이다. 고로, 회사에서 관리하는 사이트라면 리부팅은 최소한 저녁 6시 이후에 진행하는 것이 안전할 것이다.
이 정도가 내가 그간 느낀 핵심 포인트라 할 수 있겠다. 무엇보다, 유지보수는 개발과 비슷한 면이 있지만 “관리”에 있어서 이를 기록하고, 보고하고 하는 것이 가장 중요하다. 그리고, 끝없이 사이트를 체킹하면서 에러 사항을 찾아두고 전체 소스코드 및 사이트 구조, 프레임워크 구조, DB구조 등을 시간 날 때마다 분석해 두는 것 또한 다음번 추가작업에 있어서 작업 시간을 줄여주는 중요한 요인 중 하나이다.
이런 것들을 명심하며 나와 같이 초짜 웹사이트 유지보수 개발자 분들이 실수하지 않기를 바란다.
