정보시스템 운영 및 유지보수 프로세스 구축

소프트웨어 공학에서 ‘60/60 법칙’이 있습니다. 즉, 소프트웨어를 유지보수하는데 드는 비용은 40~80% 정도 발생하며 (평균 60% 정도), 유지보수 비용 중에 60%가 새로운 기능으로 고도화시키거나 강화하는데 드는 비용이 든다는 것입니다. ^[1] ^[2] 따라서, 많은 기업이나 공공기관에서는 정보시스템 유지보수를 위해 운영 및 유지보수 프로세스를 마련하는데 다양한 도구와 기법을 적용하는데 비용을 지출하기도 합니다.

특히, 공공기관의 정보시스템 운영 및 유지보수는 통상 아웃소싱을 통해 수행하는 경우가 대부분이어서 2009년 12월에 행안부와 한국정보화진흥원에서 발행한 ‘IT 아웃소싱 운영 관리 매뉴얼’에는 서비스 수행관리 프로세스 내에 운영 및 유지보수 관리에 대한 가이드를 싣고 있습니다.^[3] 또한, ITIL의 SLA(Service Level Agreement)를 통해 IT에 관련된 서비스 제공자(service provider)와 IT 자산을 사용하려는 사용자측 사이에 일정 수준의 IT 서비스를 운영하고자 하는 내용을 문서화시켜(혹은 수치화시켜) 관리하려는 요구가 강하게 나타나고 있는 현실입니다.

소프트웨어 유지보수 표준들

표준에 있어서는 IEEE 12207인 소프트웨어 생명주기 프로세스 중에 기술 프로세스의 소프트웨어 운영 프로세스와 유지보수 프로세스로 포함되어 있으며, 이 내용에는 소프트웨어 유지보수 활동 및 작업에 대한 정의와 유지보수 계획 요구사항을 정의하고 있으며, ISO/IEC 14764에는 기존 IEEE 1219를 대체하면서 소프트웨어 운영자가 수행하는 백업, 복구, 시스템 관리와 같은 영역과 부가적으로 개발 및 품질 보증에 대한 책임을 지는 사람들을 위한 내용이 포함되어 있습니다.

최근에 3.0 발행을 준비 중인 SWEBOK(Software Engineering Body of Knowledge)에서는 5장 Software Maintenance 에서 여러 표준들에 대해 비교한 내용을 포함시키고 있으며, 유지보수에 특화된 활동으로 기존 시스템이 무엇을 수행하고 각 부분들이 어떻게 연결되어 있는지를 파악하는 프로그램 이해(program understanding), 개발조직에서 유지보수 조직으로 매끄럽게 연결되는 일련의 활동을 통제하는 전이(transition), 특정 요구에 대해 크기/공수/복잡도의 범위를 가늠하여 유지보수 조직이 수락할지 거절할지를 결정하는 변경 요구 수락/거절(modification request acceptance/rejection), 최종 사용자와 유지보수 조직이 요구에 대한 평가 및 우선순위, 변경 비용을 책정하는 유지보수 헬프 데스크(maintenance help desk), 잠재적인 변경에 의해 영향을 받는 영역을 식별하는 영향도 분석(impact analysis), 서비스와 품질 목표에 대해 명세화시키는 유지보수 서비스 수준 협약 및 유지보수 계약(maintenance SLA, maintenance licenses and contracts) 등 6가지 활동을 기술하고 있습니다.^[4]

knowhow_img1[그림 1] SWEBOK(V3.0)에서 정의한 유지보수 지식 분야

정보시스템 운영 및 유지보수를 위한 시스템의 필요성

그동안 조직에서 수많은 다양한 업무들을 정보시스템으로 만들면서 점점 더 많은 운영 및 유지보수 업무들이 나타나고 그 중요도 또한 많이 높아지고 있습니다. 결국, 시스템 변경이 발생할 수 있는 지점들은 이미 다양한 채널을 통해서 나타나고 있으며, 변경 요구의 발생에서부터 통제하여 관리하려는 요구가 강하고, 설상가상으로 그 크기나 변경 범위를 사전에 파악하지 못한다면 정보시스템은 더 많은 문제들을 낳게 되고 이를 회복하기란 상당히 많은 시간과 노력이 들기 마련입니다.

게다가 정보시스템에 변경을 요구하려는 조직이나 사용자, 그러한 변경 요구를 대응하려는 비즈니스 관련 조직, 개발 조직, 시스템 운영을 모니터링하고 유지하려는 조직 등이 서로 나뉘어져 있고, 이들 조직 간의 협업이나 업무 연결들이 다양한 결재를 통해 일어나고 있다면 수작업이나 오프라인 커뮤니케이션 만으로는 분명 한계가 발생하기 때문에 이와 관련된 시스템이나 도구를 도입할 수 밖에 없습니다.

정보시스템 운영 및 유지보수를 위한 프로세스를 지원하는 시스템은 위에서 언급한 운영 및 유지보수 프로세스를 수행할 수 있도록 기능을 제공해야 함은 물론이고, 해당 조직과 그 조직의 다양한 역할, 시스템을 유지하기 위한 형상관리도구와 같은 다양한 개발 도구들, 시스템을 모니터링하고 배포를 위한 ITSM(IT service management)과 같은 도구들과의 연계가 필요합니다. 또한, 해당 변경 요구를 효과적으로 통제하기 위해 관련 지표들을 제공함으로써 더욱 효과적인 정보시스템 운영 및 유지보수 프로세스를 운영할 수 있습니다.

대법원에서 수행한 통합운영관리도구 도입은 이러한 목적 하에 기존의 정보시스템 운영 및 유지보수 프로세스가 각 업무 영역마다 독자적으로 수행하던 내용을 하나의 플랫폼과 시스템으로 통합하여 수행하도록 구축했으며, 이미 특정 업무의 운영 및 유지보수 프로세스는 통합시스템을 통해 처리하고 있습니다. 이와 관련되어 여기서는 ‘Vizend for Maintenance’가 어떠한 기능을 가지고 이러한 프로세스를 처리하는지에 대해 간략하게 기술하고자 합니다.

기존 운영 및 유지보수 프로세스 분석

대법원의 운영 및 유지보수 프로세스는 크게 3가지 업무 시스템으로 구분되고, 각 업무 시스템별로 유사하지만 조금씩은 상이한 운영 및 유지보수 프로세스가 존재했고, 각 활동에서 연계되는 개발 환경 도구나 배포 및 모니터링 도구가 달랐습니다.

특히, 개발환경과 밀접하게 연계되어 있는 프로세스들은 소스/모듈 체크인/아웃 활동이 50% 이상을 차지하고 있었고, 실제 이 부분은 변경 요구를 처리하는 프로세스 상에서 가장 중요한 지점이기도 합니다. 또한, 각 활동과 관련된 결재 영역이 30% 이상을 차지하고 있어서, 형상관리 활동과 결재와 관련된 활동이 거의 80% 이상을 프로세스에서 진행하고 있었습니다.

프로세스는 내부적으로 어떠한 유형의 변경 요구를 처리할 것인가에 따라서 세부적인 절차가 다소 차이가 있으며, 크게 일반적인 변경 요구를 분석해서 관련 소스를 수정하여 최종 시스템에 반영하는 형태의 이관 변경 유형이 있으며, 통계 조회나 인프라 변경과 같은 소스에 대한 반영이 없는 인프라 관련 변경 유형, 그리고, 시스템의 내용을 확인하여 요구를 처리하는 문의응대 유형의 3가지로 구분할 수 있습니다. 이관 변경 유형의 경우에는 긴급한 경우 필수적으로 처리해야 할 활동을 생략하고 시스템 반영 이후에 이를 처리하도록 하는 경우도 있습니다. 또한, 기존의 이관이 잘못 반영되어 재처리를 위해 반영하는 경우도 있지만, 이 경우 역시 일반 이관 변경 유형의 절차와 크게 다르지는 않습니다.

다양한 프로세스를 지원하는 유연한 운영 및 유지보수 프로세스 관리

이를 위해서는 프로세스 자체를 유연하게 관리할 수 있는 기능이 별도로 필요하며, 프로세스 내의 활동들은 유기적인 형태로 서로 연결되어 제약할 필요가 있습니다. 즉, 위의 유형별로 필요한 활동을 구성하여 유연한 프로세스로 구성하고, 각 활동은 필수/선택 여부, 결재 여부, 선행 활동 등의 제약을 통해 프로세스 수행을 제어할 수 있어야 합니다. 예를 들어, 시스템 배포를 위해서는 변경된 소스나 모듈이 모두 형상관리도구에 체크인(커밋)이 되어있어야 하며, 관련 테스트나 검증이 완료되어 있어야 하므로 배포와 같은 활동이 사전에 개발 및 시험 활동들이 모두 완료처리가 되어 있어야만 진행할 수 있도록 제약되어야 합니다. 이러한 제약들은 모두 프로세스 관리를 통해 유연하게 적용하도록 해야 합니다.

프로세스 수행을 위해 해당 활동을 수행하는 사용자들은 역할로 구분되어 있으며, 각 역할에 맞는 활동을 수행하도록 구성해야 합니다. 예를 들어, 테스터의 경우에는 회귀시험과 같은 활동을 직접적으로 수행하고 그 결과를 해당 활동에 입력해야 하고, 그 결과를 받은 개발자는 이후 활동을 수행할 수 있어야 합니다.

특히, 시스템 배포 및 이관과 관련되어서는 배포/이관 조직과 이원화되어서 운영되는 형태가 대부분이어서 이 부분은 해당 시스템과의 연계를 통해 변경 요구를 배포/이관 요청의 한 형태로 변환하여 처리할 수 있도록 해야 합니다. 배포/이관과 같이 중요한 활동의 경우에는 관련 담당자의 결재가 필수이며, 결재 완료 여부에 따라서 이후 프로세스가 자동으로 수행할 수 있도록 처리가 되며, 배포/이관에 문제가 발생될 수 있을 만한 소지에 대해서는 사전에 모두 검토되어서 그 결과를 담당자에게 알려주어야 합니다.

비록, 모든 활동이 프로세스 관리를 통해서 자동화될 수는 없지만, 각 활동 내에서 수행하는 부분들을 일반화시켜서 관리함으로써 유지보수 처리 프로세스에 대한 유연성을 어느 정도 보장할 수 있는 부분이 있습니다.

[그림 5] 운영 및 유지보수 프로세스를 유연하게 관리할 수 있는 프로세스 관리 기능

유지보수 처리 프로세스를 평가·측정할 수 있는 지표

정보시스템 운영 및 유지보수 처리를 시스템으로 관리함으로써 부수적으로 얻을 수 있는 큰 장점은 공정 수행과 관련된 산출물을 일관되게 시스템적으로 관리할 수 있다라는 것입니다. 이러한 공정산출물들은 저장된 속성을 기반으로 수행한 프로세스를 평가할 수 있는 다양한 지표를 추출하여 관리할 수도 있습니다.

프로세스를 수행한 결과들로부터 다양한 지표를 추출하여 해당 변경 요구 처리 활동들이 어느 정도의 수준으로 수행되는지를 평가할 수 있습니다.

이러한 지표들은 크게 납기준수율, 평균처리 시간 등과 같은 일정과 관련된 지표, 긴급 변경 요구 비율, 평균 처리율, 평균 FP(Function Point) 등과 같은 규모와 관련된 지표, 견적오차율, 투입 공수, 생산성 등의 공수와 관련된 지표, Inspection 효과성, 결함 조치율 등과 같은 품질과 관련된 지표 등 4가지 영역으로 나뉩니다.

이들 중에 규모나 공수와 관련된 지표들은 해당 변경 요구에 대해서 규모나 공수를 사전에 예측할 수 있어야 하며, 이 부분은 많은 논란이 존재하는 영역이기도 합니다.

특히, 최근 기능점수(FP, Function Point)를 통해 규모나 공수를 산정하려는 제도를 적용하려는 움직임으로 운영 및 유지보수 업무 역시 FP를 적용한 규모나 공수 산정을 하려고는 하지만, SI와 같은 대규모 기능 구축이나 변경이 아닌 1주에서 1달 정도의 변경까지 FP를 적용한다는 것은 다소 무리가 있어 보이게 사실입니다. 하지만, 하나의 변경 요구를 독립된 프로세스로 수행하도록 하고, 그 요구의 상대적인 크기가 어느 정도 가늠할 수 있다면 FP를 적용하는 것도 가능하고 Vizend for Maintenance에서는 FP를 통한 산정 기능이 추가되어 있습니다. 이러한 수치들은 시간이 지날수록 축적된 데이터들을 통해 어느 정도 규모나 공수 산정을 위한 용도로 사용이 가능합니다.

공학적인 방식 이외에도 변경 요구의 크기를 다양한 공정 활동 데이터를 사용해서 가늠할 수만 있다면 규모 및 공수 예측은 어느 정도 가능합니다. 예를 들어, 변경 요구에 대한 유형, 관련 소스 크기(LoC 등), 시험사례, 참여 개발자 등은 해당 변경 요구의 크기를 어느 정도 통계적인 수법을 통해 가늠할 수 있는 좋은 후보가 될 수 있습니다.

시스템 반영을 위한 형상관리 활동과 배포/이관 활동과의 관계

운영 및 유지보수 프로세스 중에는 시스템의 변경으로 인해 반영하는 절차가 포함되어 있지만, 해당 지원 도구에서 이 부분을 어느 범위까지 지원할 수 있느냐에 따라서 지원도구의 복잡도는 증가하기 마련입니다. 특히, 형상관리 활동을 지원하기 위한 절차들은 버전별 형상 항목 배포를 고려해야 하며, 형상관리도구 내의 구조와 배포 항목과의 매핑에 대한 별도 관리를 필요로 합니다.

형상항목을 어떠한 형태로 관리하든지 상관없이 통상 지원도구를 통해 배포를 수행하는 경우에는 반드시 개발자가 관리하는 형상관리 영역과 시스템적으로 빌드 및 배포를 위한 형상관리 영역은 구분하도록 만드는게 시스템적인 문제를 최소화시킬 수 있습니다. 개발 조직에서 관리하는 형상관리 영역을 그대로 배포 수행하는 경우에는 해당 소스나 모듈이 시스템에 성공적으로 반영하기 전까지 관련 소스나 모듈 수정이 다소 제한적이라는 단점이 있는 반면에 개발 조직에서는 하나의 형상관리 영역만을 관리하면 된다는 장점이 있습니다. 하지만, 조직이 더욱 다양해지고 복잡해진다면 배포를 위한 형상관리 영역을 별도로 두어서 배포시 이 부분만을 고려하도록 하는 것이 더 나을 수도 있지만, 이 역시 개발 조직에서는 두개의 형상관리 영역을 관리하고 있어야 하고 배포를 위한 형상관리 영역에 소스 병합을 위한 지루하고 에러가 발생할 수 있는 작업을 해야한다는게 큰 단점입니다.

개발 조직이 형상관리 방식에 대해 더 많은 지식과 경험이 있다면 하나의 형상관리 영역에 브랜치나 태그 등을 통한 개발 및 배포를 고려해볼 수도 있습니다. 혹은 최근에 새로운 개념의 형상관리를 지원하는 Git을 사용한 개발과 배포를 이원화시킬 수도 있습니다. Git의 경우, fork나 clone의 기능은 이러한 요구를 충분히 포괄할 수 있을 것입니다. 다만, Git에 대한 개발조직의 학습이 필요하지만, 개발조직에서는 익숙한 형상관리를 사용하고, 이 형상관리를 Git과 연계하는 부분을 시스템적으로 구성하여 배포와 개발의 영역을 이원화시키는 방법도 가능할 것입니다.

[그림 8] 유지보수 프로세스 내에서 형상관리 도구 및 배포관리 도구와의 관계

어떠한 방식이 되었든 간에 시스템 반영시점의 배포에 관련된 소스코드의 버전을 직접 관리하는 것은 상당한 이점이 있습니다. 즉, 배포 시점의 형상항목에 대한 버전은 어떠한 방식으로든 관리가 되어야 합니다.

배포관리 도구와의 연계의 경우에는 빌드 절차를 배포관리 도구가 포함하느냐의 여부에 따라서 연계의 형태가 달라집니다. 빌드 절차를 포함하는 배포관리 도구의 경우에는 연계 자체가 큰 의미는 없지만, 빌드를 사전에 수행하고, 배포할 대상 모듈까지 연계하는 경우에 있어서는 배포 대상 모듈에 대한 관리를 같이 해야하는 기능이 있어야 합니다. 특히, 통합된 빌드 도구가 별도로 존재하지 않고 개발 조직 자체에서 빌드를 수행하는 경우에는 빌드 결과(모듈)를 형상항목으로 관리하는 경우도 발생하며, 이 빌드 결과를 어느 위치에 이관할 것인지에 대한 매핑 관리 역시 필요할 것입니다.

효과적인 운영 및 유지보수 처리 프로세스

정보시스템에 대한 운영 및 유지보수 처리 프로세스의 모든 부분을 지원도구를 통해서 관리하는 것은 어렵습니다. 하지만, 유지보수와 변경 절차에 적합한 유연한 프로세스를 통해서 시스템 개발 이외의 프로세스에 대한 부담을 줄이고, 시스템 반영과 관련된 품질을 높이는 기능이 제공된다면 좀 더 효과적으로 운영 및 유지보수를 처리할 수 있을 것입니다.