한빛출판네트워크

저자: 『IT EXPERT, J2EE 웹 애플리케이션 설계와 구현: 레거시 시스템을 웹으로』의 저자 김종호

기간 업무 시스템을 웹으로 바꾸라굽쇼!!!

메인 프레임에서 클라이언트/서버 환경으로 바꾼지 얼마 안되어서 경영층에서는 어디에서 어떤 말을 듣고 왔는지 우리는 언제 웹으로 바꾸느냐고 묻는다. 마치 웹으로 시스템을 전환하지 못하면 글로벌 회사로 나아가는데 많은 문제가 있는 것으로 알고 있는 듯하다. 이런 분위기에서 "지금 시스템으로도 업무 처리하는데 문제가 없습니다"라고 말하려니 마치 시대에 뒤떨어진 사람 취급 받을까 나오던 말도 쏙 들어가 버린다. 속담 중에 "유행은 욕하면서도 따라 간다"라는 말이 있다. 개발자가 원하든 원하지 않든 어쨌든 세상은 바뀌고 있다. 점점 한 두 업체에서 기간 업무 시스템을 웹으로 전환하여 성공적으로 사용하고 있다. 가만히 있다가는 "경쟁사는 웹으로 업무를 하고 있는데 우리는 뭣하고 있었느냐"라는 말을 듣기 쉽상이다. 뭔가 대책을 세워도 빨리 세워야 할 시점이다. 그러나 막상 시작하려고 들면 그리 녹녹한 작업이 아님을 알 수 있다. "급히 먹는 밥에 체한다"는 말처럼 시작하기 전 체크리스트를 만들어 꼼꼼히 따져 봐야 한다. 그러나 체크리스트를 만들었다 하더라도 실제로 그 체크리스트를 하나하나 확인하려고 들면… "아는 것이 너무 없다는 것을, 경험 있는 사람이 너무 없다"는 것을 뼈저리게 느끼게 된다.

이 시점이 되면 가장 손쉽게 체크하는 방법이 레퍼런스 사이트를 찾아가 직접 물어보는 것이다. 아예 윗도리, 아랫도리, 체면 다 벗어던지고 단도직입으로 물어본다. "웹으로 기간업무 시스템을 개발하려면 무엇부터 체크해야 합니까?" 성질 급한 사람은 아예 이렇게 질문하기도 한다. "어떤 솔루션으로 해야 됩니까?" 돌려서 물을 틈도 없다. 물 한잔 마셔가며 천천히 한번 짚어보도록 하자. 먼저 해외 고수들의 잔소리부터 한번 들어보자.

---

참고 도서 IT EXPERT, J2EE 웹 애플리케이션 설계와 구현: 레거시 시스템을 웹으로 김종호 상세설명보기 목차보기 샘플챕터보기

---

덕 로젠버그(Doug Rosenberg)도 자신의 책 『Use Case Driven Object Modeling With UML』에서 OOAD를 잘하고서도 프로젝트에 실패하는 10가지 이유를 다음과 같이 들었다.

1. 위험이 가장 큰 프로젝트를 첫번째 객체지향 프로젝트로 선정함으로써 위험을 자초한다.
2. 프로젝트팀을 객체지향 개발 경험이 전혀 없는 사람들로만 구성한다.
3. 각 클래스별 단위 시험은 생략한 채 바로 통합 테스트로 가면서 잘 되기를 빈다.
4. 경험 있는 개발자들은 쓰임새를 기술하는데 주력하게 하고, 신참 개발자들에게 순차도를 맡긴다.
5. 분석/설계모델을 검토하는 일 따위는 신경쓰지 않는다.
6. 설계모델은 철저하게 쓰임새 모델과 별개로 유지한다.
7. 시스템의 쉬운 부분부터 먼저 개발한다.
8. OOP를 처음 접하는 개발자에게 툴만 던져주고 개발하라고 한다.
9. 작업 분석/설계한 모델은 무시한 채 코딩을 하고 코딩한 내용을 역공학해서 기존 모델에 반영한다.
10. 비주얼 모델링 도구가 멋진 코드를 생성할 것으로 생각하고 신참에게 코딩을 맡긴다.

프로젝트 끝나고 이 글을 읽었을 때가 생각난다. 정말 하나하나 읽을 때마다 지나온 날들이 주마등처럼 스쳐지나갔다. "미리 알았더라면 그렇게 고생하지 않았을 텐데…"라는 아쉬움이 너무 컸다. 그 때 결심했다. 작지만 소중한 나의 경험을 공유하겠노라고! 그리고 책을 썼다. 프로그램 짜던 실력으로 책을 쓰려니 스님이 소 잡는 마냥 잘 될 턱이 없다. 이를 악물고 도전해 보았다. 『J2EE 웹 애플리케이션 설계와 구현: 레거시 시스템을 웹으로』는 그 결과로 나온 내용이다. 물론 하고 싶었던 얘기를 이 책에서 모두 다 한 것은 아니다. 아쉬움이 남지만 독자들 손으로 이 책을 넘겨야 했다.

어쨌든 간에 덕 로젠버그에 얘기에 몇 가지 사족을 더 달고자 한다.

프로젝트에 맞는 방법론을 정립하라!
객체지향 방법론이든 정보공학 방법론이든… 방법론은 전쟁에서 장수가 쥐고 나가 적과 싸울 무기이다. 다른 사람이 쓰던 무기를 빌어서 나간다면 아예 죽을라고 작정하고 나간 것이라 해도 과언이 아닐 것이다. 전투마다 적이 다르듯 싸울 무기도 적에 맞게 조금씩 조금씩 가다듬어야 한다. 서양 사람들은 이에 대해 "Tailer(재단한다)"라는 표현을 많이 쓴다. 어쨌든 여러분 조직에 맞는 방법론을 개발하라. 기존의 방법론이 있다면 거기에 기초하라. 어줍잖게 "객체지향 언어를 쓰니 객체지향 방법론으로 해야 제대로지"하는 얕은 생각으로 화를 자초하지 마라. 객체지향 방법론도 많이 생소한데 벌써 CBD, e-CBD를 비롯하여 이론적으로는 너무 많은 것들이 시장에 나와있다. 새로운 방법론을 도입한다면 뒤에서도 말하겠지만 반드시 파일럿 프로젝트를 거쳐 검증을 받고 결과에 따라 보완해야 한다.

위험 요소 분석을 프로젝트 초기에 진행하라!
위험요소 분석을 진행할 때 참가자들에게 늘 해주는 말이 있다. "여러분들이 조기에 위험요소를 파악하여 공격하지 않으면, 위험요소가 여러분을 공격할 것입니다." 위험요소 분석을 할 때는 인정사정 봐줘가며 진행해서는 안된다. 그렇다고 해서 "하늘이 무너지면 어떡하냐"라는 식으로 진행하라는 것도 아니다. 현재 프로젝트 팀의 상황과 주변 환경에 대해 냉철하게 분석하여 위험 요소를 파악해야 한다는 말이다. 그리고 파악된 위험 요소는 관리되어져야 한다. 이를 "위험요소 분석서"로 요약 정리해서 관리하라. 당신 손에서 "위험 요소 분석서"를 놓는 순간 위험 요소가 여러분을 방문할 것이다.

파일럿 프로젝트를 먼저 시행하라!
지금까지 해보지 않았던 프로젝트를 할 때는 모든 것이 조심스럽다. 자신감만 가지고는 일이 되지 않는다. 오히려 일을 그르칠 수가 있다. 반드시 먼저 파일럿 프로젝트를 해보도록 하라. 파일럿 프로젝트를 평가하고 그 결과에 기초하여 주 프로젝트를 진행하라. 물론 파일럿 프로젝트를 선정할 때도 주의를 기울여야 한다. 위험요소 분석서에 있는 주요 위험 요소들이 포함된 업무를 가지고 파일럿을 해야지, 그렇지 않은 경우에는 오히려 안한만 못한 결과가 나타날 수도 있다. 파일럿 프로젝트를 수행하는 동안 초기에 식별된 위험 요소들을 하나씩 하나씩 극복하면서 이 내용이 본 프로젝트를 할 수 있다는 자신감으로 전환되도록 해야 한다.

프로그램 유형별 템플릿을 작성하라!
프로젝트를 진행하다 보면 중/고급 개발자들 간의 이동이 생길 수 있다. 특히 웹관련 프로젝트는 다른 프로젝트에 비해 인력 이동이 심한 편이다. 신입사원을 교육시켜 현장에 투입한 후, 바로 성과를 내기에는 많은 부담이 따른다. 반드시 이러한 부분도 위험요소로 식별이 되어 해결책을 만들어야 된다. 해결책의 하나로 프로그램을 유형별로 템플릿을 만들어 기본 교육만 받아도 바로 개발할 수 있도록 해야 한다.

개발자가 비즈니스 로직에 집중할 수 있는 환경을 만들어라!
웹 프로젝트를 하다보면 특히 복잡한 프로그램을 만들 때 메인 프레임 때나 C/S 때보다 오히려 공수가 많이 든다. 개발자 말을 빌어보면 이렇다. "이전에는 툴이 알아서 이런 것 다 해 줬는데 웹에서는 하나부터 열까지 우리가 개발을 다 해야 해요." 맞는 말이다. 이런 경우 새로운 솔루션 도입에 대하여 생각해 보아라. 할 수 있다는 것과 효과적으로 한다는 것은 별개의 문제다. 개발자들이 비즈니스 로직을 시스템화 하는데 모든 힘을 쏟을 수 있는 개발 환경을 만드는 것은 생산된 프로그램의 질과 바로 직결되는 문제이며 이는 프로젝트 성패에도 매우 중요한 문제가 된다. 개발과 솔루션 도입의 적절한 경계를 설정하여 일을 진행하도록 하라.

솔루션 제공업체(Solution Provider)에 전적으로 의존하지 마라!
솔루션을 도입한다는 것은 2가지 상반된 의미를 갖고 있다. 하나는 솔루션을 도입하여 손쉽게 위험요소를 극복한다는 것이다. 다른 하나는 솔루션을 도입한다는 것은 솔루션 업체에서 제공한 제품에 종속된다는 것을 의미한다. 영업사원이 하는 얘기와 엔지니어가 하는 얘기는 엄연히 다르다. 똑같은 말도 "어" 다르고 "아" 다른데 하물며 "A"라는 이야기를 물건을 팔려는 사람이 하는 얘기와, 기술적으로 지원해야 하는 사람이 하는 얘기와는 다를 수 밖에 없다.

"Web-Enabled냐 Web-Based냐"하는 말에 현혹되지 마라!
솔루션 업체들에게 개발팀에서 필요로 하는 기술에 대하여 프리젠테이션을 시키는 경우가 종종있다. 특히 경쟁이 치열한 경우 서로 저쪽 기술은 웹 기반 기술이 아니라 C/S기술을 웹에서 가능하게 만든 Web-Enabled 기술이다. 따라서 우리 기술이 우수하다. 이런 얘기들을 많이 한다. 또는 우리는 순수 자바 기술이고 저쪽은 코바로 연결하여 자바에서 사용하는 기술이다라는 말도 한다. 어느 것이나 말로서만 두고 보면 틀린 부분이 없다. 그러나 진짜 중요한 것은 솔루션을 도입하여 프로젝트를 성공적으로 진행하는 것임을 잊어서는 안된다.

유지 보수할 수 있는 시스템을 구축하라!
개발은 그럭저럭 끝이 났다. 개발팀은 철수하고 이제 유지 보수해야 할 일이 남아 있다. 프로그램마다 어디에 어떤 로직이 들어 있는지 명확히 구분되어 있지 않은 환경 하에서는 유지보수가 악몽일 수밖에 없다. 표준화되지 못한 코드는 처음부터 스파게티일 확률이 높다. 즉 스파게티 면발 한 줄을 포크로 댕겨보았을 때 접시 위에 있는 어느 부위가 꼼지락 거릴지 도무지 감을 잡을 수가 없는 경우처럼 프로그램도 한 부분을 수정하면 이것이 어디에 어떤 영향을 미칠지 모를 경우가 발생한다는 것이다. 사전에 유지 보수까지 고려하여 아키텍쳐를 설계하여야 한다.

모두 성공하는 웹 프로젝트가 되기를 기원하는 바이다.