클라우드 시대를 맞아 서비스의 지속적인 개발·배포가 중요시되면서 애자일, 데브옵스 등의 개념이 중요해지고 있다. 그러나 국내 기업·기관들은 오랫동안 워터폴 방식의 소프트웨어 개발방법에 익숙하기에 애자일, 데브옵스 등에 대해 생소해하거나 거부 반응이 심한 경우가 대부분이다. 이에 국내에서도 활용되고 있는 ITIL에서 애자일과 데브옵스를 받아들일 수 있도록 업데이트됨으로써 개발과 운영이 하나로 이어질 수 있는 환경이 마련될 것으로 기대된다.

‘IT 인프라스트럭처 라이브러리(ITIL: IT Infrastructure Library) v4’가 2019년 1분기에 공식 발표된다. ITIL이 마지막으로 업데이트된 것이 지난 2011년인데, 이후 소소한 변화 외에 특별한 변경이 없던 ITIL 프레임워크가 크게 바뀌었다.

새 버전은 ITIL v3의 기존 프레임워크를 유지하면서 가치 창출과 프로세스 자동화, 성과 개선을 중심으로 기존 개념을 확대한 것이 특징이다. 특히 전사적인 협업과 커뮤니케이션을 장려하고, 애자일(Agile)과 데브옵스(DevOps: Development + Operations)를 ITIL 프레임워크에서 받아들일 수 있도록 변화한 점이 눈에 띈다.

ITIL의 역사

애자일과 데브옵스가 대체 무엇이기에 IT서비스 국제표준에서 이들 문화를 수용해 가치를 공유했는지 말하기 이전에 ITIL의 뿌리를 좀 더 살펴보기로 하자.

1980년대 영국의 중앙 컴퓨터 및 전기 통신국(CCTA: Central Communications and Telecommunications Agency)은 ‘기업들이 IT서비스를 정의, 기획, 지원 및 제공하는데 필요한 실용적이며 간편한 프레임’을 위해 일련의 권고 사항들을 고안해냈다. CCTA의 권고 사항에 기반해 IT서비스 관리 실행 방식에 대한 책을 모아 놓은 총서로 시작된 ‘ITIL v1’은 처음 발행된 1986년부터 1996년까지 30권 이상의 책으로 구성돼 출판됐다.

2000년~2001년에 나온 ‘ITIL v2’는 매니지먼트, 애플리케이션, 서비스 등 IT 다방면의 프로세스 가이드라인들을 관련된 책끼리 묶은 것으로, 8권의 도서로 통합돼 출판됐다. 그리고 2001년 4월, 영국 CCTA는 영국 조달청(OGC: Office of Government Commerce)으로 통합됐다.

2007년 5월에 OGC는 현재 ITIL 2007 에디션으로 알려져 있는 ‘ITIL v3’를 발표했다. 이는 26가지 프로세스와 기능으로 구성돼 있으며 아래와 같은 5가지 핵심 프로세스를 다루고 있다.

- 서비스 전략(Service Strategy)
- 서비스 설계(Service Design)
- 서비스 이전(Service Transition)
- 서비스 운영(Service Operation)
- 지속적인 서비스 개선(Continual Service Improvement)

2011년 7월, ITIL은 또 한 번의 업데이트를 거쳤다. 기존에 분명하게 정의되지 않았던 프로세스들을 확실히 정의한 가이드라인이 포함됐으며, 이전 버전들에서 문제가 됐던 일관성 부재 및 다양한 오류들을 수정해 현재의 ‘ITIL v3’가 완성됐다.

그럼 지금부터 ‘ITIL v4’의 가장 큰 변화의 중심인 애자일과 데브옵스에 대해 살펴보겠다.

애자일과 데브옵스

애자일 방법론은 소프트웨어 개발방법에 있어서 아무런 계획이 없는 개발방법과 계획이 지나치게 많은 개발방법들 사이에서 타협점을 찾고자 하는 방법론이다. 전통적인 개발방법인 워터폴(Waterfall) 개발방법은 건설에서 차용한 개발방법으로, 요구 정의 → 분석 → 설계 → 구현 → 테스트 → 이행의 단계로 이뤄진다.

워터폴 개발방법은 앞 단계가 완료되기 전까지 다음 단계를 진행하지 못한다는 점뿐만 아니라 개발 후반부에나 결과물의 확인이 가능하기 때문에 고객의 요구사항에 맞춰 변화하기 힘들다는 단점을 갖고 있다.

반면 애자일 개발방법은 소프트웨어 개발을 제조업의 조립 라인처럼 점진 반복적으로 개발하는 방식이다. ‘이터레이션(Iteration)’이라는 짧은 주기 동안 개발하고 피드백 받는 과정을 계속 반복하며 개발을 진행하는 방식이기 때문에, 궁극적으로 실제 필요한 소프트웨어가 나올 확률이 높아진다.

즉 애자일 개발방법론은 계획을 통해서 주도해 나갔던 과거의 방법론과는 다르게 앞을 예측하며 개발을 하지 않고, 일정한 주기를 갖고 끊임없이 프로토타입을 만들어내며, 그때그때 필요한 요구를 더하고 수정해 하나의 커다란 소프트웨어를 개발해 나가는 방식이라고 할 수 있다.

데브옵스는 소프트웨어 개발과 운영의 합성어로 소프트웨어 개발자와 IT 전문가 간의 소통과 협업, 통합을 강조하는 개발환경 또는 문화로 정의된다. 소프트웨어 개발 조직과 운영 조직 간의 상호 의존적 대응이 강조되며, 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 문화를 말한다.

이는 개발과 운영을 통합해 수행하는 조직에서 이미 검증되고 반복되는 작업들의 자동화를 통해 서비스를 빠른 시간 안에 개발하고 배포함으로써 실제 업무 수행자들이 좀 더 높은 수준의 서비스 개선 활동에 집중할 수 있도록 한다. 이를 통해 효율성을 높이고, 실제 서비스를 이용하는 고객 관점에서 기업이 제공하는 서비스의 수준을 보다 빠른 시간 안에 효과적으로 높일 수 있도록 하는 것이 데브옵스의 궁극적인 목적이다.

효과적인 IT서비스 개발·운영 관리

개발과 운영의 통합이라는 개념 안에는 필수적으로 애플리케이션 생명주기관리(ALM: Application LifeCycle Management)가 동반된다. 그리고 점진 반복적으로 서비스를 개선해 나가는 문화인 애자일 개발방법 역시 빠질 수 없다. 그럼 데브옵스를 이용해 효과적으로 IT서비스 개발·운영을 관리할 수 있는 방법을 살펴보자.

애플리케이션 라이프사이클의 각 단계를 담당할 수 있는 각종 오픈소스들로 툴 체인(Tool Chain)을 구성하고 그중 지속적인 통합과 지속적인 배포를 담당하는 CI/CD(Continuous Intergration/Continuous Delivery) 도구를 이용해 통합과 배포를 자동화한다.

이슈/요구사항 관리를 위해 이슈트래킹시스템(ITS: Issue Tracking System) 또는 ITSM(IT Service Management)을 사용해 관리하고, 해당 요구사항 구현을 점진 반복적으로 구현한다. 이렇게 구현된 소스코드는 지속적인 통합도구를 통해 빌드 및 정적 검증을 수행하며 통합한다.

통합된 목적물을 지속적인 배포 도구를 이용해 자동화하고 각 서버에 배포하며, 다시 서비스 운영 단계로 들어가 라이프사이클을 반복해 수행한다. 데브옵스를 구현할 툴 체인으로 전체 애플리케이션 라이프사이클 아키텍처(Application Lifecycle Architecture)를 수립·구성해 계획, 요구관리 단계에서 엔드유저의 요구를 투명하게 기록 관리한다.

업무담당자는 점진 반복적인 개발을 통해 구현하고, 검증된 CI/CD 도구를 이용해 빠르게 통합, 배포할 수 있어 엔드유저에게 서비스를 딜리버리(Delivery)해 지속적으로 빠르게 서비스를 발전시켜 나가는데 활용한다.

ITIL v4가 미칠 영향

애자일과 데브옵스는 우리나라 공공 및 기관에서 아직 생소하거나 거부 반응이 많다. 심지어 애자일은 많은 기업 담당자나 개발자들 사이에서 실용성이 없거나 우리나라의 현실과 맞지 않는 개념이라고 여기기까지 한다.

반면 ITIL은 2000년 외국계 합작사들을 중심으로 우리나라에 도입되기 시작한 이후 꾸준히 발전해 왔다. 그리고 정부 및 많은 기업에서 ITIL v3 개념을 구현한 ITSM 솔루션을 사용하고 있다. 하지만 현재 많은 기관에서 사용하고 있는 ITSM은 한계점이 존재한다.

ITIL은 대부분 초창기 IT 인프라를 효율적으로 관리하기 위해 사용자 측에서 요구해 SLA(Service Level Agreement) 계약 형태로 시작됐다. 처음 국내에서는 SLA 기반의 사례를 찾기 어려웠기에 측정과 관리가 쉬운 IT 인프라 환경에서 가능한 것들을 우선적으로 적용하며 시작된 것이다. 이후 인프라 위주의 사례와 인프라 중심의 지표관리, SLA 측정 항목 등이 중점으로 초점이 맞춰져 있다 보니 ITSM 솔루션도 이에 초점이 맞춰져 발전했다.

상황이 그렇다 보니 인프라와 서비스를 통합적으로 관리하는 기관에서 도입한 ITSM 솔루션조차도 인프라 관점에 집중돼 있다. 소프트웨어 관리 노하우나 지표 등은 적용되지 않은 상태여서 많은 IT 관리자들이 ITSM을 통한 소프트웨어나 서비스 관리에 어려움을 느끼고 있다. 이는 대부분의 민간 기업도 마찬가지이다.

그중 가장 큰 어려움은 서비스 개선이나 변경에 대한 빠르고 다양한 요청들을 기존 ITIL에서 활용해 관리하기 힘들다는 것이다. ITIL의 초점이 변경관리위원회(CAB: Change Advisory Board)에 맞춰져 있다 보니 의사결정의 절차가 복잡했고, 그것은 엔드유저의 요구가 실제 서비스로 반영되기까지 필연적으로 많은 시간이 소요된다는 문제점을 동반했다.

두 번째는 관점 차이다. IT서비스가 개발을 거쳐 서비스가 시작된 이후에는 운영이 진행된다. 개발은 문제가 발생했을 때 빠르게 수정하고 패치하는 것이 목적이지만, 운영은 안정적인 서비스가 목적이기 때문에 변화를 기피한다. 변화로 인해 서버에 장애가 생기면 운영이 곤란해지기 때문이다. 이러한 관점 차이는 필연적으로 대립을 야기한다.

세 번째는 유연성의 부족이다. 최근 서비스 측면을 중심으로 IT와 IT 시스템에 엑세스해야하는 부서가 증가하면서 IT 부서와의 커뮤니케이션이 점점 더 중요해지고 있다. 하지만 기존의 ITIL v3에서는 이러한 사항을 유연하게 반영하는데 한계가 있었다.

네 번째는 ITIL v3를 준용한 ITSM 도입까지 높은 비용이 발생한다는 것이었다. IT서비스 관리의 체질을 개선해 질을 높이는데 많은 비용이 발생했기에, 자금적인 여유가 부족한 기업에서는 ITSM을 도입해 관리하기 어려운 구조였다. 그러다 보니 실제로 ITSM이 대·중소기업에서 범용적으로 사용되지 못했다. 많은 곳에서 널리 사용하면서 나올 수 있는 더 좋은 베스트 프랙티스(Best Practice), 더 좋은 관리지표에 대한 경험도 부족한 상태가 반복되는 문제가 발생했다.

이러한 어려움을 대체할 해법으로 애자일과 데브옵스가 포함된 ITIL v4가 발표되면, 우리나라 정부 및 많은 기업이 이를 따를 것으로 예상된다. 그리고 이에 맞춰 많은 ITSM 솔루션들도 애자일과 데브옵스 개념을 구현할 것이다.

그렇게 되면 현재 어려움을 겪고 있는 ITIL v3 기반의 운영에 해결책이 될 것이다. 소프트웨어 개발과 운영이 별도의 프로젝트 관리도구가 아니라 ITIL v4가 적용된 IT서비스 관리도구를 통해 관리될 것이다. 말 그대로 데브옵스, 개발과 운영이 하나로 이어져 지속적이고 빠른 서비스가 제공되는 것이다.

새로운 해법 통해 다양한 변화에 대비해야

현재 시장은 AI, 블록체인, 4차 산업혁명, 소셜네트워크서비스(SNS), 유튜브(YouTube) 등이 등장하면서 빠르게 변화하고 있다. 새로운 기술의 생성·소멸의 주기와 그로 인한 고객의 니즈 역시도 시시각각 다양하게 변화하고 있다.

기업들은 각종 디지털 미디어나 소셜미디어 등 더 확대된 온라인 노출 덕분에 고객으로부터 과거 그 어느 때보다도 많은 피드백을 받고 있다. 이미 고객이 모든 서비스의 중심으로 자리매김했고, 기업은 변화의 방법과 시기를 파악하기 위해 고객들의 의견에 귀 기울여야 한다.

이제 기업은 고객과의 단절을 제거하고, 기업이 제공하는 서비스의 가치를 정의하는 것부터 요구사항을 정의하는데 이르기까지 고객을 적극적으로 참여시켜야 한다. 이를 위해서 지속적인 피드백과 점진 반복적인 순환 고리를 만들어야 한다. 이것이 ITIL v4가 애자일과 데브옵스를 받아들여 변화하게 된 이유이자 동시에 해법인 것이다.

이제 ITIL v4를 준비하는 기업과 기관은 이전처럼 특정 솔루션이나 제품에 종속되는 것이 아니라 각종 개방형 구조의 도구들로 툴 체인을 구성해 관리의 리스크와 비용을 낮추고, 접근성과 확장성을 높여 고객과 조직원이 기업의 서비스 개선에 참여하기 쉬운 형태로 튼튼한 토대를 구성해 변화하는 시장에 대비해야 할 것이다.