Cut over : 운영 중이던 Service Application을 내리고 (Down) 다른 시스템으로 이관하는 일련의 행위
AS-IS환경 분석
요구사항 분석
Cloud 구성요소 및
변경요소 식별
Phase-1 Phase-2
핵심 구성요소 설계
부가 구성요소 설계
서비스 (대/내외)
연계 점검/설계
서버 생성
자원 구성
데이터 이관
Phase-3
응용 개발 및 수정
응용 단위/통합 테스트
가용성/성능 테스트
MIG환경
Readiness 점검
AMI/서버 생성
구성 점검
데이터동기화
운영 AP, SW
환경구성
응용환경 점검
인프라 점검
운영환경
Readiness점검
이관수행계획서 작성
이행계획서 검토 및
보완(관련조직)
리허설 환경
Readiness점검
리허설 수행
결함 점검
운영팀 인수인계
(이관>운영)수행
운영 소프트웨어
설정 및 점검
사전작업수행
AS-IS 시스템 OFF
NW 전환
AWS 시스템 기동
서비스 점검
OPEN
서비스 안정화
(D+3)
AMI/서버 생성
자원 구성
구성 점검
테스트
인수인계내역 업데이트
OPEN
서비스 안정화
(D+3)
Phase-4 Phase-5 Phase-6 Phase-7 Phase-8
D
O
W
N
T
I
M
E

?
▪ 현황 분석이 부족하면 전체
사업에 막대한 지장을
초래함
▪ 현황 분석 단계에서
애플리케이션의 기능 및
연관 관계의 파악이 중요
▪ 인력 및 수작업이 아닌
자동화를 통해 기능 및 IF
확인, 범위 확인
▪ 다양한 테스트를 통한 이행
단계 문제점의 사전 검증
▪ AS-IS 분석 부족으로 인해 중대 기능 누락
▪ 통합 테스트 단계에서 발견
▪ 프로젝트 기간 연장
▪ 33개월 → 40개월
▪ 오픈일정 9개월 지연
사례 1 ▪ 차세대 시스템 구축
▪ 업무 시스템 AS-IS 인터페이스 미식별
▪ 프로세스 및 인터페이스 전수 재조사
▪ 테스트 진행
▪ 전환 인건비 추가 투입 (대략 150% 추가
투입)
▪ 오픈일정 6개월 지연
사례 2 ▪ 금융 1차 U2L 전환
▪ AS-IS 분석 부실로 인해 상세화 단계에서
65%의 개발 규모 증가
▪ 테스트 단계에서 이슈화에 따른 대응이
늦어 구축비 증가 (100% 이상)
▪ 오픈 일정 3개월 지연
사례 3 ▪ OO 시스템 구축
고객사 Mission Pain Point 시사점 및 고려 사항 ?

업무적 관점
선정 평가 항목
업무 중요도 (업무등급)
업무시스템 활용도
표준 F/W 사용 가능 여부
비용절감(플랫폼전환,오픈소스
SW)
기술적 관점 선
정 평가 항목
플랫폼(OS) 종류
소프트웨어 구조
자원 요구량
자원 노후화 정도
정책적 요소 정책적 중요성
프로세스 및 조
직적 요소
조직 인지성
비용 경제성
기술적 요소
가용성 및 유연성
기술 용이성
업무 중요도
시스템 규모
서비스 대상
부하의 탄력성
비즈니스 요구
자원 사용률
자원 노후화
연계 시스템
사용 언어
프레임워크
시스템 구조
사용 OS
가상화 적용 여부
클라우드 전환 Biz 요
구
클라우드 전환
선정 기준
클라우드
도입적합성
자가진단
업무적 관점의
선정 요소
기술적 관점의
선정 요소
전환 시 경제적 효과성
전환 시 업무 영향도
전환 시 안정성 및 신속성
수준
공유 자원 활용에 따른 서버운영
및 관리 영향도
고객사
클라우드 전환 결정요소
Agile환경 및 Software Defined
Platform전환의 중요성
기업내부 전략과의 부합성

마이그레이션 내용
5. 동일한 상용WAS 버전에서는 업무 소스코드를 수정없이 리눅스
기반으로 이전하여 사용 가능하고 업그레이드 버전의 경우 일부
수정이 요구됨. DB전환 시 SQL에 대한 업무 코드 전환 필요
4. 유닉스에서 운영중인 미들웨어를 분석 후 오픈소스 기반의
JBoss/Wildfly/Tomcat 전환 환경으로 구성.
데이터소스, IP 하드코딩 변경, DB/OS변경으로 인한 한글깨짐, 3rd Party
솔루션 문제 해결 필요
3. Unix와 동일한 JDK버전을 사용하거나 오픈JDK를 활용하여 업그레이드
2. WebSphere에서 요구하는 OS 커널파라미터 및 쉘 환경설정을
리눅스에 맞게 구성하고 개선된 리눅스 커널 파라미터를 통해 성능 개선
1. 기존의 파티셔닝된 Unix 환경과 동일한 성능을 제공할 수 있게 사이징하고
적정한 vCPU 및 vMemory 자원기반으로 스케일-아웃 형태로 구성/배치
AIX / Windows
Unix Server
JDK
WebSphere
업무 App
운영체제
자바
미들웨어
애플리케이션
Amazon Linux
클라우드 환경
JDK
JBoss/Tomcat
업무 App
Amazon AWS
LPAR
파티션/가상화
2
3
4
5
1
IBM HTTP Server
Microsoft IIS
웹서버
conf/httpd.conf
conf/ssl.conf (v2.4.x)
conf/extra/* (v2.4.x)
• 정적파일(HTML, 이미지, CSS, 스크립트) 이관
• 소프트웨어 전환이 가장 쉬운 영역

리눅스에서 실행 될 수
있도록 애플리케이션
구축 및 테스트
포팅과 관련된사항확 인
포팅과 관련된 사항확인
UNIX상에서 GNU툴을
이용하여 C/C++
애플리케이션 구축
UNIX머신 상에서
리눅스용 애플리케이션
을
빌드 및 테스트
항목 내역
컴파일
▪ CPU 로직과 OS 지원 명령어의 차이에 따라 소스 코드 컴파일 시 오류가 발생할 수 있음
▪ 컴파일러 플래그, Makefiles, 빌드 절차, 소스 코드 변경 등이 필요함
라이브러리
▪ ANSI, C/C++ 등 표준 라이브러리가 벤더와 버전 별로 상이한 경우, 라이브러리 변환이 필요할 수 있음
(예: Unix 전용 C언어 라이브러리를 사용하는 경우)
Endian
▪ Unix에서 Big-Endian 방식인 경우, Linux의 Little-Endian 방식으로 변환이 필요할 수 있음
▪ Endian이란 CPU가 메모리에 데이터를 저장하는 방식을 의미함
POSIX
▪ POSIX (이기종 Unix 간 호환을 위해서 공통 API 준수) 기반이 아닌 경우에는 소스 코드는 변경이
필요함
Key Point!

▪ 리눅스 마이그레이션 시 재설치 및 데이터 로드
▪ 오라클 형태의 쿼리, 프로시저 수행
▪ TAC 형태의 클러스터 기능 지원
▪ 소스 스키마 및 프로시저 분석, 쿼리 변경 필요
▪ 애플리케이션 변경 및 기능 테스트 필요
예상 기간 및 내용
▪ 플랫폼 독립적인 부분으로 VM 설치만으로 기동
▪ 일반적인 경우 WAR당 3일 소요
▪ 리눅스용 C로 변환 필요- 재 컴파일 필요
▪ UNIX에서 시뮬레이션 후 리눅스 포팅
▪ 패키지 재설치 및 Add-On 소스 추가 필요
▪ 예) SAP, MQ, MDM 등
▪ Java는 플랫폼 독립적이라 소스 변경 요건이 적음
▪ 모듈당 전환/기동/테스트 기본까지 2일 소요
▪ 벤더 디스크립터에 대한 분석 및 추가 변환 작업 필요
▪ 보통의 경우 분석/변환/배포/테스트까지 5일 정도 소요
용도 유닉스 기반
Oracle
Oracle
Tibero
EDB
자체 개발 자바
DB 서버
WAS
응용 서버
WAR
EJB
자체 개발 자바
C/Tuxedo C/Tuxedo(Linux)
패키지 APP 패키지 App
리눅스 기반 난이도
下
中
下
中
下
上
下
상세분석필요
상세분석필요
상세분석필요
2일/모듈
3일/WAR
5일/업무
3일/모듈
2일/패키지
예상
소요일수
中
• 기존의 많은 U2C 프로젝트 진행 사항과 해당 내용을 기반으로 산정한 결과 리눅스로 전환 시 영역에 대한 난이도와
예상 소요 시간을 아래와 같이 나눌 수 있음

Cloud
Computing
CNA
PaaS
IaaS
SaaS
Container
12-factor
App
Multi-
tenant
MSA
Codebase
Continuous
Delivery
CI
CD
DevOps
Services
Domain-
Driven
Design
API
DB
Decomposition
SOA Bounded
Context
API
Gateway
Protocol
통신
포맷
API
Management
Authentication
Authorization
Control
Monitoring
API
token
Multi-
tenancy DB
Isolated
Shared Full
Shared
Semi
Shared
Configuration
Dev/Prod
parity
Services Isolation
Stateless
Processes
Build,
release, run
Backing
services
ESB

일반적인 절차
직접비 간접비
자산
소프트웨어
하드웨어
인건비
초기도입비
유지보수비
초기도입비
유지보수비
인건비
장애대응
운영자
TCO 주요 구성 항목

$
1 2 3 4 5
0
마이그레이션 거품
최적화 / 혁신
현재/아무것도 하지 않음
(성장 포함)
AWS 환경
투자 회수 기간
시간
비용

52%
57%
42.9% of
Cloud 확충
기업의 80%가 내년 말까지
코로나19 이전보다 두배 빠른 속도로
Cloud 중심 인프라 및
애플리케이션으로 전환 준비

정량적 평가
＊상세검토: 요구사항, 라이센스 확인
등의 세부 검토, BMT/POC 등을 거쳐
최종 의사결정
• 전환용이성 – 클라우드 환경으로의 전환 여부의 평가를 위해 아키텍쳐와
위험요소를 고려함
• 전환 효익 – 클라우드 환경으로의 전환 후 재무적 관점과 아키텍쳐 유연성,
워크로드 및 운영 효율성 등의 기술적 효익을 고려함
평가 항목
시스템 부하(5개 항목)
아키텍처(9개 항목)
재무(1개 항목)
전환 위험(5개 항목)
운영(3개 항목)
보안 및 통제(4개 항목)
• 전환 용이성 지수
• 전환 효익 지수
REHOST
기존 애플리케이션
클라우드 호스팅
•기존 아키텍처를 유지하고,
HW/OS만 변경 후 클라우드
환경으로 전환하는 단순한 인프라
변경
REFACTOR/REVISE
기존 애플리케이션
수정하여 전환
• Refactor: PaaS연동을 고려하여
소스코드 수정 또는 구성 변경
• Revise : 시스템 고도화 수준에
따라 소스코드 수정 및 확장
REBUILD
클라우드 플랫폼 기반의 애플리케
이션 고도화(재개발)
• 기존 애플리케이션을 폐기하고,
새로운 아키텍쳐(PaaS)기반으로
애플리케이션을 고도화
(재개발)하여 클라우드 전환
REPLACE
기존 업무 기능을
SaaS로 대체
• 기존 애플리케이션을 폐기하고,
SaaS(3rd Party)로 전환
• 기존 업무의 SaaS 대체 적합성
검토 필요
* 가트너 5R 클라우드 적합성 진단 방법론 사례

업무 적합
III
전환 최적
I
전환여부 선택
IV
기술 적합
II
High
Low
High
Low
기술 구현 용이성
업
무
효
과
성
전환여부 선택
▪실행이 어렵고, 업무 활용성이 낮음
▪환경 변화 등을 고려해 선택적으로 실행 함
▪업무의 클라우드 전환이 적합하고 활용성이 큼
▪기술적으로 클라우드 전환이 용이하여 짧은 시간
안에 가시적인 효과를 볼 수 있음
기술적합
업무적합
전환최적
III
IV
I
II
▪실행이 용이하고, 단기간에 가시적인 효과를 볼 수 있음
▪업무 활용성 및 경쟁우위 확보 수단으로서의 가능성은
높지 않음
▪업무의 클라우드 전환이 적합하고 업무에 미치는 영
향이 커서 반드시 전환되어야 함
▪전문적인 기술 및 전환 상세 설계가 요구됨
1.0 2.0 3.0 5.0 5.0
2.0
3.0
4.0
5.0

AS-IS TO-BE
UNIX
X86
UNIX
X86
U2L
P2C
V2C
전환 환경 준비
2
Unix 서버의
Linux
전환 케이스
x86 서버의
Cloud Zone
전환 케이스
최적화 및 안정화
4
전환 수행 및 검증
3
정보시스템 환경 조사
상세 영향도 평가
전환 대상 선정
TO-BE 인프라 용량 설계
서비스 전환 계획서 작성
이행 전 성능 측정
서비스 전환 작업
이행계획서 작성
전환 환경 구성
애플리케이션/데이터 포팅
서비스 테스트
시스템 모니터링
이행 후 성능 측정
성능 최적화
시스템 안정화
Virtual
Machine
Physical
Machine
현황분석
1
Cloud 마이그레이션 작업 시 Assessment, Analysis, Migration, Test, Verification 단계의 많은 비용이 소요됨

항목 내용
애플리케이션 부분 회고
• 소스 관리의 부재로 인한 최신 소스 확인 어려움
• 운영 인력의 지속적 교체로 인한 업무 시스템에 대한 전체 히스토리의 부재
• 예전 개발 방식으로 인한 업무 시스템별 패키징의 어려우며, 기존 애플리케이션 소스에 하드 코딩된 환경 설정이 상당수
존재
• 이관 후 AS-IS 시스템과 TO-BE 시스템의 문제에 대한 파악 어려움
• 기존의 CI/CD 기반이 구성되지 않아 이에 대한 프로세스 적용
인력 부분(R&R) 회고
• 전체 업무 전환 시 산발적 컴포넌트 이슈에 대한 부분을 해결하는 AA(Application Architect)의 부재
• 프로젝트 인원(고객사, ITO, 협력업체)과 업무 시스템 유관 부서와의 코디네이션의 주체
• 개발자가 명확한 작업 내용을 파악하지 못함(애플리케이션 패키징, 오류 수정, 기능 테스트 지원 등)
• 전체 업무 확인, 테스트, 오픈 리딩의 주체와 개발 배포를 위한 CI/CD 업무 담당 불명확성
• 커뮤니케이션에 대한 이력 관리 어려움 – 이슈 트래킹 시스템 등의 적용이 필요
확산 사전 준비 사항
• 전환 대상 업무시스템의 최신 반영된 소스 코드의 준비와 프로젝트 빌드/배포 프로세스를 관장할 애플리케이션 아키텍트
소싱
• 고객사, SI업체, ITO, 개발유지보수 업체, 전환 프로젝트 수행사 간의 명확한 R&R 정의
• 3rd Party 솔루션 벤더의 기술 지원에 대한 프로세스 및 지원 확약
• 업무 시스템에 대한 기능 확인을 담당하는 별도의 QA 조직 검토 필요
• PoC 수준의 사전 업무 시스템의 전환 테스트(난이도 상/하를 기준으로 패키징, 배포 작업을 수행하여 전체 프로젝트의 정
확한 공수 산정)
확산 진행 시 필요 사항
• 고객과의 커뮤니케이션을 포함하는 전체 호스트(PM)
• 애플리케이션 전환 시 각 태스크 및 커뮤니케이션을 위한 이력 관리 시스템(예: Redmine, JIRA 등)
• 3rd Party 솔루션 벤더에 대한 섭외 및 관리(로드러너, XecureWeb, 인증 모듈, SSO 등)
• 개발/배포 처리에 대한 업무 담당자 별도 지정
• 단위 테스트, 성능 테스트, 백업/복구 테스트 리딩 업무 담당자 지정

40

41

기존 및 신규 시스템 분석,
현행화가 필요한 고객
Assessment(Analyzer)
(현행 시스템 정보 수집 및 분석)
Migration
(Cloud 마이그레이션 지원)
현행 시스템 정보를 솔루션이 수집 및 파싱을 통해 현황 분석을 수행하고, Auto Discovery를 통해 자원을 관리하는 인벤토리 기능과
다양한 시스템 클라우드 환경으로 마이그레이션 자동화를 제공하는 Digital Transformation 솔루션입니다.
42

43
43
업무 시스템 인터페이스를 직관적인
시각화 그래프로 보여줌
시스템 연관 관계에 대한 상세 정보 제공
대상 업무 시스템 현황 분석 목록

44
마이그레이션 위저드 기능
마이그레이션 진행 상황/결과
타켓 클라우드 원격 프로비저닝