[Web Application Server] 전환 절차서 (WAS Winback 수행 절차)

본 포스팅은 WAS를 타 벤더사로 윈백 할 경우 참고할 자료입니다.

---

WAS를 타 벤더사의 제품으로 윈백을 수행하기 위해서는 어떠한 파트를 참고해야 할지를 고민해야 할 것입니다. 본 포스팅에서는 주요한 분야를 살펴보고, 전환을 위해서는 어떠한 과정을 수행해 나가야 하는지 살펴보도록 하겠습니다.

먼저 포스팅에 대한 개요입니다.
타 WAS로 운영중인 사이트를 전환하기 위해 필요한 절차와 Task를 기술하도록 하겠습니다.
여기서 제시하는 일반적인 Standard Flow에 따라 전체 공정의 90%정도가 비교적 쉽게 전환이 가능합니다. 하지만, 전환을 위한 사전 환경점검과 소스분석으로 정확한 M/M를 산정해야 하고, Risk분석을 통해 안정적인 전환방안을 수립해야 합니다.

- 본 전환 가이드는 전환을 계획하고 있는 고객에게 필요성과 전체 작업 공정을 투명하게 제공하여 빠른 의사결정을 유도하는데 목적이 있습니다.
- 본 전환 가이드는 작업을 어떻게 수행해야 하는지에 대한 합리적인 절차를 제시합니다.
- 본 전환 가이드는 각 단계별 체크리스트를 제공하여 Risk를 최소화 합니다.

다음으로 전환을 위한 Flow를 살펴보겠습니다.
WAS전환을 위한 전체 작업 흐름은 다음과 같습니다.

통상적인 WAS 전환은 ‘요구사항 수렴 및 분석’, ‘전환 및 테스트’, ‘교육 및 오픈’의 순서대로 진행되는 것이 일반적인 것입니다.

고객사의 환경이나 공수에 맞추어 각 단계는 유연하게 조정될 수 있습니다.

올바른 Win-Back 수행하기 위해서는 전략을 옳바르게 세워야 할 것입니다.
먼저 전환 목표를 수립한다.

다양한 목적을 가지고 전환을 진행하게 될 것이며 그러한 WAS를 선정하기 위해서는 일반적으로 아래와 같은 요구사항이 있을 것입니다.

Reference를 통한 안정적인 성능 보장을 목표로 한다.

- 유지보수 비용을 최소화 하는데 목적을 둡니다.

- 시스템과의 Integration 및 Interface 용이성이 좋아야 합니다.

- 각 요소들에 대한 다양한 방법으로 구성할 수 있으며 변경의 영향을 최소화 되어야 합니다.

- 안정적인 통합 인프라 구축 다양한 사이트 검증에 의한 제품의 안정성을 보장해야 합니다.

- 다양한 사이트 적용/운영 중, 고객의 특이상황을 고려한 섬세한 기능을 제공해야 합니다.

토탈 솔루션을 제공합니다.

- WAS 도입 이후, 새롭게 대두되는 클라우드, HTTP2.0 등의 기술 트렌드에 유연하게 대응해야 합니다.
- 신규 프로젝트 진행 시, 기존 자산 재활용에 의한 고객 투자를 보호해야 합니다.
- 타 시스템과의 원활한 연동을 해야 합니다.

고객 지원의 우수성이 제공되어야 합니다.

- 담당 SE 지원 및 24 X 365 기술지원을 위한 담당 조직을 구성해야 합니다.

- 교육센터 및 고객지원 전용 홈페이지 운영으로 고객의 기술능력 향상을 지원해야 합니다.

- Tech Portal 운영 : 온라인 메뉴얼, 튜토리얼, 테크니컬 기술지식, F&Q, Q&A 게시판을 운영해야 합니다.

- 고객지원센터, 기술지원실, R&D센터, 품질관리실, 컨설팅실 구분을 운영해야 합니다.

다양한 Specification 지원이 되어야 합니다.

- 무중단 서비스를 위한 어플리케이션 Hot Deploy 환경을 지원해야 합니다.
- 웹 기반의 비즈니스 로직이 되어야 합니다.
- 프로세스 설계를 지원해야 합니다.
- 실시간 모니터링을 지원해야 합니다.
- 웹 기반 과 Console의 관리 환경을 제공해야 합니다.
- JavaEE를 인증 받아야 합니다.
- WAS 자체 2-Phase Commit을 지원해야 합니다.
- DB와의 트랜잭션을 연동해야 합니다.
- SSL,HTTPS, X.509 등의표준 보안 인터페이스 제공해야 합니다.
- 장애사전감지 시스템 제공으로 장애사전방지 환경을 지원해야 합니다.
- 장애발생시 사용자에서 무중단서비스를 제공하는 Fail-Over 기능을 제공해야 합니다.
- 중앙집중방식과 분산방식의 클러스터링을 지원해야 합니다.
- 다양한 부하분산 방식으로 전체적인 시스템 성능을 향상해야 합니다.

그러면 이제 전환 수행을 위한 상세 Flow를 살펴 보겠습니다.
먼저 고객 미팅을 통해 아래와 같은 사항을 파악합니다.
- 전환 업무 수행 초입단계로, ‘고객 미팅’을 통하여 고객의 요구요건을 명확히 파악하는 것이 중요합니다.
- 고객과 전환 수행팀이 유기적으로 같이 움직일 수 있도록 유도하며, 최소한의 공수로 최대의 효과를 이끌어 낼 수 있도록 TFT성 임시조직을 구성하고, role을 분배하도록 해야 합니다.

다음으로 고객미팅 간 파악했던 요구사항을 정의합니다.

- 요구사항 정의 단계에서는, 고객의 요구요건에 대한 명확한 이해를 얻어내는 것이 중요합니다.
- 향후 변경의 소지가 다분한 고객요구의 특성을 감안해 볼 때, 그에 대한 근거자료도 마련하고, 또한 향후 전환 프로세스 정립의 방향을 결정할 때 도움이 될 수 있습니다.
- 도출된 고객 요구사항 항목들은 반드시 문서화 하여, 고객의 확인을 얻은 후 다음단계를 진행하도록 합니다.

요구사항이 정의 되면 다음으로 전환 목표를 설정해야 합니다.

고객의 요구사항이 명확해진 이후는, 향후 전환을 수행할 때 큰 목표가 되는 전환목표 설정하도록 해야 합니다.
복잡 다단한 여러 요소가 모여있는 시스템이 대부분임을 감안할 때, 올바른 전환목적의 설정은, 고객요구에 부합되는 정확한 분석자료를 도출할 수 있는 가장 올바른 지침이 될 수 있습니다.
전환에 있어서, 포인트가 되는 주요 Application 기능범주를 기록해 두어야 합니다.

다음으로 전환 범위 설정입니다.

전환을 수행할 전환 범위를 정하는 단계입니다.
전환 범위 설정 시, 시스템을 구성하고 있는 아키텍처를 참조하여, 실제 전환이 이뤄져야 하는 범주를 명확히 구분하고, 관련 아키텍쳐를 분석하고, 특이사항에 대해 미리 예측 가능한 사항은 도출시켜야 합니다.

 

범위가 결정되면 전환 일정을 위해 세부 협의를 진행합니다.

전환 수행에 필요한 전체 일정 및 세부 일정을 협의 하는 단계입니다.
보통, 실제 전환이 이뤄지는 시기 그 이전부터 전체 전환 일정에 대한 개략적인 정보를 영업부서 등을 통하여 얻어서, 시간 분배 등의 계획은 rough하게 작성해 가도록 합니다.
애초 계획된 전체 전환 일정이 맞는지 고객의 확인을 한번 더 얻고, 필요 시 소요일정을 늘리거나 줄이는 단계도 이 부분에서 이뤄져야 합니다.
정확한 공수 예측을 위해서는, 앞서 말한 사전단계를 통한 정확한 요구사항 정의가 필수가 됩니다.

 

위와 같이 일정까지 결정이 되면 실제 업무 파악에 들어가게 됩니다.

AS-IS 시스템 및 구성을 검토하고 실제 수행해야 할 기술파트 등을 도축해 나가야 합니다.

외형적인 현황 분석 및 내부자료를 활용한 현 부각 문제점을 도출하는 단계입니다.
보다 정확한 AS-IS에 대한 분석을 위해서, 가능한 보유하고 있고 제공되어 지는 각종 자료 및 Data를 최대한 활용합니다. 

각 파트 담당 현업들과 개별미팅을 진행하여, 각 요소에 대한 전문적인 의견을 나누는 시간을 갖는 것도 좋습니다.

다음으로 전환 방향을 산정합니다.

개략적인 AS-IS 시스템 및 구성검토가 끝난 후, AP구조에 맞추어 WAS 관점과 소스 관점에서의 전환 Factor를 도출합니다.

WAS 관점에서는 주요 확인해야 할 관점은 JSP/Servlet 이외에 EJB, JMS, Webservice등의 J2EE Specification을 사용하는 부분이 있는지 파악이 되어야 합니다.

소스 관점에서는 JDK Upgrade, 새로운 기술 도입, WAS Dependency library 사용 여부 등이 파악되어야 합니다.

위와 같이 윈백 계획이 수립되면, 실제 윈백 업무가 수행됩니다.

마지막으로 테스트 및 오픈에 대한 부분을 살펴보고 마무리 하도록 하겠습니다.
아래는 단위 테스트 방법에 대한 간략 내용입니다.

1. 실제 기술적 전환이 완료된 이후는, 단위테스트 및 부하 시험 등을 반드시 거쳐야 합니다.
2. Role을 분담하여, 각각 모니터링 한 Data들을 수집해야 합니다.
3. 기존 시스템에서 특히 문제가 되었던 포인트에 대한 반복 검증이 필요합니다.
4. 모든 테스트에 대한 주관은 고객사에서 진행하도록 합니다.
5. 전환에 참여한 SE는 ‘모니터링 및 문제점 지적’ 업무를 중점적으로 수행합니다. 

오픈 및 전환종료를 위해서 아래와 같은 모니터링을 수행해야 합니다.

1. 오픈에 관한 전반적인 수행은 고객사에서 진행하도록 해야 합니다.
2. 전환에 참여한 SE는 ‘모니터링’을 중점적으로 수행합니다. 

모니터링이 진행 된 이후 사후 관리르 통해 교육 및 추후 대응 방안에 대해 가이드 하고 프로젝트를 종료하게 됩니다. 

1. 전환 시, 특별하게 도출되었던 내용에 대해 고객교육을 수행해야 합니다.

- 이를 통해 장애 발생 시 고객 및 운영자가 선 조치를 수행할 수 있고, 자료를 수집할 수 있도록 가이드 해야 합니다.
2. 당사 SW 사용시 특별한 주의점을 고객교육을 통해 전달합니다.
3. 간단한 모니터링 방법을 고객에게 교육시켜야 합니다.

위와 같이 윈백을 수행하기 위해서는 여러 단계에 걸쳐 협의가 수행되고 계획하며, 작업 영향도를 분석하고 실제 전환를 수행하고 오픈 및 사후 관리를 하게 됩니다.

자 그럼 앞서 예고드린대로 다음 포스팅에서는 각 WAS 벤더사별 윈백 수행 시 유의 사항을 알아보겠습니다.

고맙습니다.