관련 통계자료 다운로드 SDLC에 따른 오류 수정에 드는 비용 글로벌 단일 시스템 환경에서 장애 예방을 위한 애플리케이션 거버넌스 -백운기 지티원 이사
글로벌 싱글 인스턴스(GSI) 환경이 유지보수 비용을 절감하고 업무 효율성을 향상시킬 수 있다는 사례가 보고되고 있지만 우리가 간과할 수 없는 커다란 위험도 존재한다. 즉 GSI 환경의 가장 커다란 위험 요소는 바로 시스템 장애로 인해 전 세계적으로 비즈니스가 마비될 수 있다는 점이다. 기업들은 이를 대비하기 위해 시스템 이중화, 재해복구 시스템 등 장애 발생 후 대책에 대해서 많은 대비를 하고 있지만 사전 예방책에 대해서도 관심을 기울일 때다. 바로 효과적인 애플리케이션 거버넌스를 통해서다. 사실 하드웨어 결함보다는 운영 중인 애플리케이션이나 시스템 환경 설정의 변경 오류로 인해 발생하는 장애의 비중이 크기 때문이다.
근래 들어 글로벌 기업의 CIO들이 가장 관심을 가졌던 주제 중 하나는 국내 사업장 및 해외 사업장들 전체의 업무 프로세스를 표준화하고 하나의 데이터베이스를 바라보는 단일 IT 시스템으로 통합하는 ‘GSI 구현’이 아닐까 생각한다. 그런 움직임의 일환으로 이미 여러 기업들이 GSI 전사적 자원관리(ERP) 시스템을 구축하고 여러 방면에서 효과를 보았다는 기사가 심심치 않게 보도된 바 있다.
전 세계에 걸쳐 각각 다른 환경에서 개발되고 운영되는 여러 애플리케이션 및 데이터베이스 인스턴스들은 IT 조직에게 유지보수 효율성과 비용 측면에서 심각한 부담으로 작용할 뿐만 아니라 데이터의 통합 이슈 때문에 비즈니스 자체의 효율성을 떨어뜨리는 것이 사실이다.
◇수정 후 연계 프로그램 반영 안돼 장애 발생=일반적인 구성의 GSI ERP 환경을 고려해 보자. ERP의 장점이 표준화된 업무 프로세스를 패키지 기반으로 도입할 수 있다는 것이기는 하지만 기본 패키지 영역 외에 추가 개발 및 커스터마이징이 상당 부분 일어나기 마련이다. 또한 ERP 시스템만 단독으로 활용되는 것이 아니라 복잡한 인터페이스 규칙에 의거해 기업애플리케이션통합(EAI), 서비스지향아키텍처(SOA) 기술 등을 기반으로 상당히 많은 수의 유관 업무 애플리케이션 시스템들과 연계되어 사용된다.
실제로 이런 환경에서는 비즈니스 로직을 담고 있는 ERP의 특정 커스텀 영역 소스 코드 혹은 데이터베이스 프로시저 및 오브젝트를 변경한 후, 테스트를 거쳐 운영 서버에 적용했을지라도 수정된 부분과 연계된 다른 프로그램들에 대한 고려가 누락되어 ERP 자체의 에러는 차치하고 다른 유관 시스템들에 이르기까지 장애가 전파되는 사례가 종종 발생한다. 이는 개발자의 지식과 경험에만 의지하기 때문이며 GSI 환경에서는 이런 문제의 피해가 특히나 더 심각하다.
이런 환경에서 애플리케이션의 장애를 예방하고 일정 수준의 품질을 유지하기 위해서 많은 기업들이 이미 실행하고 있는 대표적인 방안은 애플리케이션의 생명주기 관리(버전 관리 및 변경 관리, 릴리즈 관리 등 포함), 테스트 관리 및 자동화, 개발 표준 준수 강화, 애플리케이션 성능 관리 툴을 이용한 실시간 모니터링 등이다. 이들 모두 확실히 필요한 관리 포인트들이다. 그렇지만 다음과 같은 사항들도 고려해볼 필요가 있다.
우선 형식적인 애플리케이션 생명주기 관리는 장애를 예방하지 못하다. 거의 모든 기업들은 기본적으로 SR 접수로부터 분석 및 설계, 코딩, 테스트, 운영 이관에 이르는 유지보수 각 단계들을 워크플로 시스템화하고 결재 라인에 따라 소스 코드의 버전 관리, 변경 이력 관리, 릴리즈 관리 등을 수행한다. 하지만 이것이 형식적인 절차에만 그치고 개발자의 지식과 경험에만 의존하는 관행이 계속될 때는 문제 발생의 소지가 여전히 남아 있다. 사람은 항상 실수를 하게 마련이기 때문이다.
또 테스트 자동화는 개발 완료 후에 수행되며 모든 경우를 다 아우를 수 없다. 가능한 한 모든 테스트 케이스를 미리 정하고 런타임 동적 테스트를 자동으로 수행하게 함으로써 생산성을 높이고 품질을 향상시키려는 노력은 꽤 오래 전부터 수행돼 왔다. 하지만 나중에 발견한 문제를 수정하기 위해 개발 단계부터 다시 절차를 거쳐야 한다. 애플리케이션 성능 관리 툴에 의한 모니터링도 장애 및 에러가 발생한 것을 사후에 감지할 수 있으므로 비슷하다. 또한 테스트 케이스를 벗어나 예상치 못한 문제가 발생하는 경우에는 대책이 없다.
개발 표준이 제대로 지켜졌는지 적시에 검증할 방안도 필요하다. 관리자들은 개발자의 실력 편차에도 불구하고 일정 수준의 품질 유지를 위해 개발 표준 및 가이드를 따르도록 요구한다. 하지만 실제로 이를 검증할 만한 물리적인 시간과 방법도 마땅치 못하다.
◇잠재적 오류와 표준 준수 여부 점검=개발자의 손을 떠나기 전에 비교적 초기 단계부터 미리 애플리케이션 품질을 확보할 수 있는 방안들을 찾는다는 관점에서 종합적으로 애플리케이션 거버넌스 체제를 구축한 모 기업의 사례를 살펴보자.
요청 사항 관리, 버전 관리 및 변경관리는 기본적인 사항이며 여기에 더해서 비즈니스의 요청에 따라 애플리케이션을 수정할 때, 개발자의 지식과 경험에만 의존하지 않고 변경에 따른 영향 범위와 테스트 범위를 시스템적인 방법으로 개발자들에게 제공함으로써 장애를 사전에 예방하는 방안을 실행한다.
개발자가 수정 완료한 소스 코드를 버전 관리 시스템에 반입하기 전에, 잠재적 오류를 내포하고 있지는 않은지 혹은 중요한 개발 표준을 준수했는지 등을 자가 점검하도록 툴을 제공하고 의무화 한 후, 품질 팀에서는 취합된 전체 변경 소스를 주기적으로 동일 기준으로 점검하는 프로세스를 실행한다.
빌드 및 배포에 관련된 작업들을 자동화하고 관리함으로써 인적 실수에 의한 장애를 예방하며 테스트 케이스들과 각 프로그램을 연결해 놓고 특정 프로그램이 수정될 때 반드시 테스트 케이스들이 모두 테스트되어야만 다음 단계로 넘어가도록 정책을 실행하기도 한다.
산출물 문서는 어느 기업에서나 100% 시스템 오픈 후 얼마 지나지 않아 무용지물이 되고 만다. 중요 산출물에 대해서는 이를 일정 부분 최신 정보로 항상 현행화하기 위한 시스템적인 방법이 사용된다.
여러 기관들에서 애플리케이션 생명주기의 앞 단계에서 오류를 수정하면 그만큼 수정 비용을 많이 절감할 수 있다는 연구 결과를 내놓은 바 있다. 프로그램이 개발자를 떠나 다음 단계로 넘어가기 전에 취할 수 있는 방안들을 고려한 애플리케이션 거버넌스 체제가 제대로 실행된다면, 글로벌 싱글 인스턴스 환경과 같이 장애가 매우 중대한 이슈가 되는 곳에서 상당한 효과를 볼 수 있을 것이다.
◇가시성 확보하기 어려운 애플리케이션 환경=위 거버넌스 체제 중 애플리케이션 정적 분석 기술을 통해 성취할 수 있는 애플리케이션 거버넌스 활동들에 초점을 두고 살펴보자.
기업에서는 그동안 믿을 수 없을 정도로 복잡한 애플리케이션들을 유지 보수해 왔다. 애플리케이션 내의 로직은 매우 상이한 데이터베이스들과 COBOL, 4GL, 자바, 닷넷 등 여러 기술들을 복합적으로 사용한다. 애플리케이션 규모 또한 지속적으로 빠르게 증가하고 있다. 애플리케이션 유지보수 팀은 애플리케이션에 대한 가시성을 확보하기 힘들다.
애플리케이션의 본질적 속성은 지속적인 변경이다. 매일 쏟아지는 비즈니스 요구사항을 반영하기 위해서 소스 코드의 변경이 매우 빈번하게 발생한다. 빈번한 변경은 곧 실수로 인한 애플리케이션 장애 발생 확률을 높이고 만다.
그리고 코볼만 레거시 애플리케이션이 아니다. 포레스터 리서치에 따르면 최신 기술과 프로그래밍 언어가 적용된 애플리케이션일지라도 운영 환경으로 넘어간 이후 얼마 되지 않아서 레거시 애플리케이션이 되어버리는데 그 이유는 담당 개발자의 교체로 인해 애플리케이션 세부 지식이 증발하기 때문이다. 이런 레거시 애플리케이션에 대해서는 분석, 수정 및 테스트 등 소프트웨어 개발 생명 주기 작업들에 소요되는 시간이 더 길어진다. 더구나 에러가 보다 잦으며 이행 및 통합 포인트들을 놓치기 십상이다.
레거시 애플리케이션의 진짜 문제는 지식의 손실이다. 개발이 완료되고 난 후 얼마 지나지 않아 개발자들은 다른 임무를 수행하게 되거나 소스 코드 변경 후 이를 문서화 하는 일에 대해 신경 쓰지 않는다. 결국 해당 애플리케이션에 대해 경험이 풍부한 전문가와 정확한 산출물 문서가 부족하기 때문에 비용을 높이고 생산성이 저하된다. 산출물 문서는 무용지물일 수 있다. 새로운 개발자들과 설계, 분석가들은 그 애플리케이션이 어떻게 작동하는지 잘 이해하지 못하는 것이 당연하다. 그리고 소스 코드 혹은 데이터베이스의 어떤 부분을 변경했을 때 무엇이 영향을 받을지 알 수 없다. 품질 관리 요원들은 테스트 시나리오에서 영향 받는 객체들과 테스트 범위를 산정하는 일에 어려움을 겪는다.
프로그램을 모두 완성해서 실행을 해보고 이상이 없는지 테스트하기 보다는, 프로그램 실행 없이 소스 코드만을 자동으로 분석해서 원하는 정보를 얻어내는 기술을 정적 분석(Static Analysis)라고 한다. 이런 정적 분석 기술을 응용하여 변경 영향분석, 소스 코드 자동 검증(품질 측면과 보안 취약점 측면의 코드 인스펙션) 등의 특화된 분야의 툴들이 시장에 출시되어 있다.
현재 변경 영향 분석 툴은 주로 다양한 프로그래밍 언어들로 작성된 프로그램들과 데이터베이스 사이의 호출 및 피호출 관계를 상세한 수준에서 제공하는 데 특화되어 있다. 또한 소스 코드 점검 툴은 베스트 프랙티스 코딩 가이드 및 표준 준수 검증에 초점을 맞춘 품질 점검 분야와 애플리케이션 해킹 방지를 위해 소스 코드의 보안 취약점을 탐지하는 데 초점을 맞춘 분야로 양분되어 있고 점차 통합화 되어 가는 추세이다.
◇변경에 영향받는 요소 탐색=정적 분석 기술은 다음과 같은 장점들을 제공할 수 있다. 우선 잦은 변경으로 인한 애플리케이션 장애 발생 위험을 줄인다. 변경 영향 분석 툴은 사용자에게 변경되는 소스 코드와 연관 관계가 있는 요소들을 찾아주므로 개발자는 애플리케이션 및 데이터베이스 변경 시 실제적인 범위를 알아낼 수 있다. 또한 애플리케이션 변경이 영향을 미치는 영역에 대해서만 테스트를 집중하여 수행하도록 해줄 수 있다. 영향 분석을 수행하는 개발자들은 변경에 의해 영향 받는 요소들을 놓치지 않기 때문에 정확성과 신뢰성을 높일 수 있다.
또 보다 나은 협업과 애플리케이션 지식 공유가 가능하다. 변경 영향 분석 툴은 다양하게 분석된 정보들을 축적해 애플리케이션 지식기반을 구축한다. 따라서 애플리케이션 팀은 새로운 개발자를 영입하거나 담당자 교체 시 빠르게 지식을 전수할 수 있게 된다. 또한 시각화되고 투명한 애플리케이션 지식을 공유함으로써 개발자들, 관리자들, QA 요원들 사이의 보다 나은 협업을 이끌어낼 수 있다.
산출물의 현행화를 구현할 수 있는 것도 정적 분석 기술의 장점이다. 업데이트 되지 않는 산출물 문서의 부정확성 때문에 애플리케이션 팀은 일상적인 임무 수행에 있어 이들을 활용하지 않는다. 변경 영향 분석 툴은 지속적으로 애플리케이션 지식기반을 업데이트하고 이를 기반으로 자동화된 산출물 생성 기능을 제공한다. 그래서 애플리케이션 팀은 항상 최신의 산출물 문서를 활용할 수 있다.
정적 분석 기술을 이용하면 잠재적 오류 유발 코드를 검출하고 개발 표준을 준수했는지 검증이 가능하다. 소스 코드 자동 검증 툴은 베스트 프랙티스를 따르지 않았거나 기술 표준을 준수하지 않은 소스 코드 라인들을 자동으로 찾아줄 수 있다. 개발자는 사전에 코드의 품질을 측정해 보고 향후 에러를 유발할 수 있는 코드를 미리 찾아내어 대처할 수 있다.
실제로 싱글 인스턴스 ERP 환경을 구축한 어떤 기업에서는 철저한 애플리케이션 변경 관리 및 품질 관리를 실시했지만 ERP의 커스텀 영역을 수정하고 운영 서버에 적용한 후 유관 업무 시스템들에 장애가 전파되어 큰 곤란을 겪은 바 있다. 개발자의 경험에만 의존하여 변경 영향 분석 없이 프로그램을 수정했기 때문이다. 이에 대한 대비책으로 변경 영향 분석 툴이 변경관리 프로세스 안에 내재화 되었고 항상 변경 영향 분석 결과물을 개발자들이 공유하도록 하는 정책을 시행하고 있다.
어떤 기업에서는 차세대 프로젝트를 진행하면서 외부 개발자들의 개발 표준 준수를 확인하여 품질을 확보하기 위해 검수 조건의 일환으로 소스 코드 점검 툴을 활용하기도 한다. 물론 이 경우에는 소스 코드 점검 툴이 기업 고유의 개발 표준을 얼마나 잘 규칙화 하여 수용할 수 있느냐가 관건이다.
NIST(National Institute of Standards and Technology)에 따르면, 릴리즈 이후 발견되는 오류를 수정하기 위해서는 설계 단계에 비해 30배의 비용이 소요된다고 한다. 경험에 의하면 프로젝트 팀이 통합 테스트 단계에서 발견되는 오류들 때문에 전체 개발량의 30 ∼ 40%를 재개발하기도 한다. 따라서 애플리케이션 개발 생명주기 초기 단계에서 구사할 수 있는 정적 분석 기술의 활용과 같은 사전 예방책들을 검토하는 일은 매우 가치 있는 일이다.
kbaeg@gtone.co.kr
