나는 회사에서 JSP로 만들어진 사이트를 유지보수 한다. 프레임 워크는 오래 전 회사에서 만든 것인데, 나름대로 폴더 구조만 잘 맞춰주면 로그도 잘 남고, DB 풀이나 객체 재사용에 대한 대비, 기본적인 JSP 내에서 사용해야 할 예를들어 자동 문자열 콤마라던가 기타 편리한 기능들은 잘 만들어져 있다.
내가 속한 회사는 사실 웹보다는 Active X 와 TR-transaction을 통한 금융 거래를 주로 하던 업체라 웹에 대해서는 단순히 viewer의 기능만 할 뿐이라 크게 신경쓰지 않았다. 허나, 최근들어 웹을 통한 거래가 많아지자 웹, 특히 WAS단과 DB에 대한 관심도가 높아져서 올 초 웹 전담 유지운영팀이 생기게 되었다.
기존에 웹 개발자들은 소수에 불과하였고, 서로 다른 팀에 있던 사람들이 모이다 보니 사실 유지보수 하는 사이트들도 준구난방, 하지만 사실 원천은 위에서 언급한 프레임워크를 사용한 파생 상품이고, 구조 또한 동일하다. 하지만 사람들이 자기 일을 관리하기에도 벅차기 때문에 아무도 이 프레임워크에 대해 신경쓰지 않았다.
그래서 처음 내가 한 일은 원천 소스를 찾는 일이었다. 다행히도 jdk 1.5로 컴파일된 버전을 찾긴 하였는데, 알고 보니 또 우리가 유지보수 하는 소스는 jdk 1.4로 컴파일 되어 있다. 내참.. 당장 원천 클래스 파일을 수정할 일은 없으므로 원천 소스를 가지고 있는 자체로 만족하고, jdk 1.4버전으로 향후 downgrade하기로 생각하고 일단 패스.
그리고 초창기부터 형상관리가 전혀 되지 않아 백업도 제각기이고 그나마 테스트 서버가 있어 그곳에서 마구잡이로 우선 에디트로 소스 수정을 하고 리얼 서버에 반영한다. 하지만 혼자 작업할 때에는 이게 참 좋겠지만, 문제는 얼마 전 내가 받은 신입 두명이 차례로 받아 작업한 사이트에서 발생한 것이다. 거래량으로 따지면 일순위인데 이 사이트를 신입급 둘이 유지보수 하고 했으니, 다른건 몰라도 소스가 2천줄 이상 되는 것, 자바스크립트 내에 보안도 되지 않은 상황에서 중요한 정보가 노출되는 것, 소스 상에 DB화 되지 않은 데이터가 배열로 박혀 있는 것(-_-;;) 등 아주 심각한 상황이 크게 발생해 있었다.
물론 지금이야 내가 수정해 놓아서 다행이긴 하지만, 또 다시 나는 이 서비스를 다른 분에게 인수인계 해야 하는 시점이 왔고, 그렇게 바로 인수인계 한다면 또 같은 상황이 발생할 것이라는 판단 하에 형상관리 시스템을 구축하기로 했다. 뭐 단순히 SVN만 생각했었는데, 결론적으로는 온갖 삽질 끝에 SVN+HUDSON+ANT 라는 구조를 잡았다.
SVN을 통한 버전관리, HUDSON을 통한 리얼 서버의 WAS에 통합, 그리고 윈도우 배치와 Ant 스크립트를 통한 배포환경을 만들었다. 개발자는 로컬에 환경을 세팅하고 커밋하면 Hudson에서 변경된 파일을 받고 Ant를 통해 자동으로 WAS의 루트에 Different Task를 통해 변경된 파일만 올리게 된다. 이 과정에서 WAS의 루트 중 바뀌는 파일은 Copy Task 이전에 Ant의 Zip Task를 통해 자동 백업하게 된다.
[개발자 로컬 -> 테스트 서버 배포과정]
1. 개발자 Commit -> SVN 저장
2. SVN을 통해 Hudson에서 최신 소스파일 저장
3. WAS 의 Root 중 변경된 파일만 비교하여 백업(Ant의 Different Task 및 Zip Task 사용)
4. 최신 소스파일 -> WAS의 ROOT로 이동(Ant의 Copy Task 이용)
그럼 일단 테스트에서 정상 작동 여부를 확인할 수 있고, 정상 작동시 리얼에 배포 과정을 거치는데 이 역시 사용자의 윈도우 배치파일을 실행함에 따라 아래 절차를 자동으로 수행한다.
[테스트 서버 -> 리얼서버 배포 과정, 리얼 서버는 L4로 구분되어 2대로 정의.]
1. 리얼 기존 파일 temp폴더로 내려받기. 만약 기존에 temp폴더에 내려받은 것이 있다면, 변경된(업로드할) 파일만 내려받기
2. temp폴더와 테스트 서버의 WAS Root를 비교하여 변경된(업로드할) 파일 자동 압축백업(Ant Zip Task)
3. 수정된 파일 -> temp 폴더로 이동(향후 1번 과정을 하면서 중복 다운로드를 하지 않기 위해)
4. 수정된 파일만 -> 리얼 업로드 (1,2번 서버)
약 3일간 고심해서 이렇게 세팅을 해 놓았는데 나름대로 만족하고 있다. 다만, 아직 리얼 이관을 실제로 해보지 못해서 좀 걱정이긴 하지만;; 확실히 자동화 작업은 많은 편의성이 있는가 하면 제대로 세팅해 놓지 않는다면 크나큰 문제가 발생할 것 같다. 그리고 그런 문제를 방지하기 위해서 메뉴얼 작업 역시 필수인 것 같다. 메뉴얼이 단순히 글로만 써놓은 그런 글이 아닌, 이미지를 통한 따라하기 방식으로 설명해 놓은 메뉴얼 말이다.
말이 나온 김에 메뉴얼에 대해 얘기해 보자면, 단순히 유지보수 운영 메뉴얼 같은 것들이 정보성 글들만 쓰인 것이 많은데, 많은 유지보수 업무를 도맡아 하는 사람들은 대부분 신입이다. 그들을 위해 나름 경력이 있는 개발자들은 절대 실수할 염려가 없는 이미지를 통한 따라하기 식의 튜토리얼을 만들면, 그 정도의 상급자들의 배려가 있으면 더 좋지 않을까 하는 아쉬움이 든다.
나야 물론 팀 작업을 위해 이런 자동화를 구축하는 것도 있지만 사실 다 내 개발의 편의를 위해서이다. 솔직히 운영하다 보면 저런 과정에서 쓸때없이 발생하는 문제가 많이 생긴다. “최신 소스 동기화” 작업이 안되있으면 말이다. 급한 오류건에 대해서 보통 일반적으로 리얼에서 작업해서 처리하는 경향이 많은데, 그러다가 자칫 잘모해서 비정상적인 소스가 리얼로 올라가게 된다면? 그야말로 얼마나 큰 문제점이 초래되겠는가? 이는 사용자의 편의가 생명인 웹 서비스에서 사활이 걸린 문제이기도 하다.
여튼 내가 아무리 유지보수만 전담해서 한다 하더라도, 한번의 작업을 참여하더라도 항상 끝 마무리는 제대로 하도록 하는 것이 좋겠다. 뒷사람을 생각하는 배려. 그것이 없다면, 뒷사람들이 얼마나 욕을 할 지는 정말 상상하기도 힘들다. 나 역시도 전에 개발한 사람의 욕을 무지하게 해댔으니 말이다. 배려라는 것이 다른데 있는 것이 아닌, 나의 주위에 나와 함께 하는 사람들에 대한 배려가 진정한 배려라는 사실. 이번 기회에 깊히 깨닫는 것 같다.
