2023년 3월 11일
공개 SW 마이그레이션 절차 및 고려사항
1. 공개 SW 마이그레이션의 개념 및 필요성
개념 | 필요성 |
---|---|
상용 라이선스 기반 솔루션을 공개 SW와 공개 SW 유지보수 방식을 적용한 정보시스템으로의 전환 정책 | – 비용 절감(H/W, S/W, 전력 및 냉방 등) – EOSL 등 더 이상 지원 불가능한 S/W 교체 – 시스템 통합 및 클라우드 등 신기술 도입 – 성능 향상 및 안정성 확보 |
- 공개 소프트웨어로의 전환 목적에 따라 마이그레이션 프로세스가 달라질 수 있으며, 공개SW 마이그레이션 시 선택 가능한 옵션과 장단점이 상이하므로 기획 단계에서 마이그레이션 목적과 추진 절차에 대해 고려 필요
2. 공개 SW 마이그레이션 추진 절차 및 단계별 수행 작업
(1) 공개 SW 마이그레이션 추진 절차
(2) 공개 SW 마이그레이션 단계별 수행 작업
단계 | 수행 작업 | 주요 내용 및 산출물 |
---|---|---|
[1단계] 진단 및 계획 | 1-1. 사업 환경 / 전략 확인 | – 내/외부 환경 분석 및 요구사항 수집 – 마이그레이션 범위 및 접근방법 결정 |
1-2. 대상 시스템 현황 분석/발굴 | – APP 상세속성 및 인프라 환경구조 파악 – 사전 질의서, 시스템 현황 분석서 등 | |
1-3. 마이그레이션 원칙 수립 | – 라이선스(기술지원)비용, 유지보수 정의 – 공개SW 완성도/기능성/신뢰도 등 정의 | |
1-4. SW 마이그레이션 과제 정의 | – 마이그레이션 모델 결정, 우선순위 정의 – 사용자 요구사항 정의서 | |
1-5. SW 마이그레이션 계획 수립 | – 목표 모델로 선정된 마이그레이션 사업에 대한 계획 수립 | |
[2단계] 마이그레이션 준비 및 배치 | 2-1. 이행 조직 구성 | – 엔지니어 / 운영 / 프로젝트관리 / 개발자 / 품질관리 조직 등 구성, 조직 구성도 |
2-2. To-Be 시스템 설계 | – 마이그레이션 리스크/재개발/일정수립 – To-Be 시스템 스펙/비용산정, 시나리오 | |
2-3. 마이그레이션 이행계획 작성 | – APP 작업 및 마이그레이션 일정 수립 – SW 구성, 이행계획서, 전환 일정 계획서 | |
2-4. HW / SW / NW 구성 | – 설계된 To-Be 시스템 기반 하드웨어 및 네트워크 구성 후 개발 소프트웨어 설치 | |
[3단계] 마이그레이션 수행 | 3-1. 서비스 APP 재개발 수행 및 이관 | – 소스 재개발, 서비스 포팅 및 문제 해결 – 개발 계획서, APP 이관계획서 |
3-2. 파일럿 테스트 | – 일부 시스템 선정 테스트 및 계획 조정 – 테스트 결과로 마이그레이션 일정 조정 | |
3-3. 마이그레이션 이행/테스트 | – 파일럿테스트기반 단계별마이그레이션 – 테스트 방법 및 일정 계획서 | |
3-4. 최종 서비스 운영 전환 | – 장애상황 대비방안수립, 최종검증 수행 – 운영자 교육 및 서비스 전환 계획서 | |
[4단계] 최적화 및 안정화 | 4-1. 시스템 모니터링 및 안정화 | – 안정화 기간 동안 시스템에 대한 모니터링을 통한 개선점 도출 |
4-2. 이행 후 성능 측정 | – 이행 후 성능 측정하여 이행 전과 비교 – 성능 비교 분석 결과서 | |
4-3. 최적화 작업 | – 상황에 따라 성능 최적화 작업 실시 |
- 효과적인 마이그레이션 수행을 위해 공개SW 마이그레이션 원칙 수립 시 호환성, 상호운용성, 확장성, 사용자 편의성, 투자 효율성 등을 고려
3. 공개 SW 마이그레이션 추진을 위한 고려사항
구분 | 고려사항 | 세부 검토 사항 |
---|---|---|
호환성 측면 | 운영체제 호환성 여부 | – 공개SW로 변경 시 기존 OS Ecosystem 전환 여부 – 응용 프로그램의 다양한 운영체제 지원 가능 여부 |
개발 언어 호환성 여부 | – 서비스 App 개발 언어의 다양한 운영체제 지원 여부 – 사례) java는 JDK 지원 시 다양한 OS 지원 가능 | |
상호운용성 측면 | 타 시스템 및 S/W 연동 | – 다른 시스템 및 S/W와의 연동 능력 고려 – 사례) 리눅스 SSSD 데몬 통한 Active Directory 연동 |
확장성 측면 | 시스템 확장 용이성 | – 시스템 확장 시 동일 기준 시스템 확장 가능성 – 사례) 리눅스 파일시스템은 최대 500TB 확장 가능 |
사용자 편의성 측면 | APP 개발 표준화 | – APP 표준화 기반 사용 편의성 및 관리 용이성 확보 – APP 개발 표준화로 시스템 간 개발, 운영이 용이 |
인터페이스 표준화 | – 동일 인터페이스 사용 시 관리용 S/W 표준화 가능 – Agent Module 단일화 및 유지보수 용이성 확보 | |
투자 효율성 측면 | 표준 기반 비용 절감 | – 시스템의 안전하고 신속한 구축, 향후 확장성 보장 – 표준 적용 기반 비용과 노력을 절감 가능 여부 검토 |
자원 재배치 기반 비용 절감 | – 자원 재배치 과정 기반 불필요 투자 억제 여부 검토 – 특정 시스템 업그레이드 시 고비용 발생 대응 가능 | |
부가 효과 | 정보 공동 활용 및 정보자원관리용이성 | – 정보 공동 활용과 정보자원 관리 용이성 확보 검토 – 전관적/전사적 차원의 자원관리 가능성 검토 |
- 성공적인 마이그레이션 이후 유지관리도 매우 중요하므로 유지관리 항목을 고려하여 운영 계획 수립 필요
4. 공개 SW 마이그레이션 이후 유지관리 항목, 검토 사항
구분 | 유지관리 항목 | 유지관리 검토 사항 |
---|---|---|
제품 지원 | 설치 및 기능향상 | – 초기 설치 및 환경설정, 메이저/마이너 기능향상 가능 여부 |
제품 수정/업데이트 | – 패치/Hotfix 등 제품의 오류 수정 업데이트 제공 가능 여부 | |
공개 SW Lic. 보증 | – 공개SW 라이선스 사용에 대한 법적 문제에 대한 보증 여부 | |
유지 관리 | 기본 유지관리 | – 고객지원 사이트 접속, 전화/이메일 등 원격일상지원 여부 |
긴급 장애지원 | – 장애나 긴급한 문제 해결 위한 점검 및 장애처리 지원 여부 | |
예방 지원 | – 시스템 장애 사전 예방을 위한 정기 점검 서비스 시행 여부 | |
교육 지원 | – 효과적 제품 운영/사용 위한 운영자/사용자 교육지원 여부 | |
성능 개선/튜닝 | – 운영시스템의 성능 개선과 튜닝 전문 서비스 가능 여부 | |
컨설팅 서비스 | 아키텍처 재설계 | – 운영시스템 아키텍처 재설계 위한 전문 서비스 가능 여부 |
기타 전문 서비스 | – 기타 운영시스템 환경 고도화 위한 전문 서비스 가능 여부 |
- 각 유지관리 항목에 대해 기존 / 표준 / 고급 서비스를 통한 온라인 및 온사이트 지원 가능 여부도 함께 고려
- 공개SW 기술지원 계약 시 24 x 365 또는 9-to-6 기술지원 등 시스템 중요도에 따른 유지관리 차별화 필요
[참고]
- 정보통신산업진흥원(NIPA), 공개SW 마이그레이션 가이드