클라우드 시대를 맞아 서비스의 지속적인 개발·배포가 중요시되면서 애자일, 데브옵스 등의 개념이 중요해지고 있다. 그러나 국내 기업·기관들은 오랫동안 워터폴 방식의 소프트웨어 개발방법에 익숙하기에 애자일, 데브옵스 등에 대해 생소해하거나 거부 반응이 심한 경우가 대부분이다. 변화하는 시장에 대비하기 위한 방법으로 IT서비스관리 국제표준인 ITIL v4가 받아들인 소프트웨어 개발 및 운영 관점에서 애자일과 데브옵스를 어떻게 구성해야 하는지 알아본다.

애자일 소프트웨어 개발 방법은 계획과 문서를 기반으로 개발 모형이나 모델에 따라 앞을 예측하며 개발하는 것이 아니다. 실질적인 코딩을 기반으로 일정한 주기에 따라 계속적으로 프로토타입을 형성하고, 필요한 요구 사항을 파악하며, 이에 따라 즉시 수정사항을 적용해 결과적으로 하나의 큰 소프트웨어를 개발하는 적응형(Adaptive Style) 개발 방법이다.

또한 데브옵스는 개발과 운영을 하나로 통합해 성공적으로 소프트웨어 개발을 수행하고 다시 연속적으로 운영으로 이어질 수 있는 환경을 만들어 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 문화를 말한다.

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

이처럼 데브옵스를 구성하는 필수 요소에는 애자일이 기본적으로 포함돼 있다.

데브옵스 구성 방법

개발과 운영의 통합이라는 데브옵스 개념 안에는 필수적으로 애플리케이션 생명주기관리(ALM: Application Life cycle Management)가 동반되며, 점진 반복적으로 서비스를 개선해 나가는 문화인 애자일 개발 방법 역시 포함된다.

데브옵스를 성공적으로 구현하기 위해서 변화하는 문화를 받아들이는 인식의 개선이 중요하지만, 그에 못지않게 이를 도와줄 수 있는 명확한 도구 선택도 뒷받침돼야 한다. 해당 도구들을 통해 반복되는 작업들을 자동화하는 것은 데브옵스의 기본 라이프사이클을 지원하는 강력한 지원자가 되기 때문이다.

아래 <표>는 애플리케이션 생명주기를 각 단계별로 지원하는 각종 도구 예시이다. 해당 도구들을 활용해 전체 애플리케이션 생명주기를 관리할 수 있는 데브옵스 환경을 구성해야 한다.

1. 계획/요구관리 도구

- 이슈/요구사항 관리를 위해 이슈트래킹시스템(ITS: Issue Tracking System)을 사용한다.

- 해당 시스템은 각 조직 내부의 다양하고 각기 다른 업무 프로세스를 자유롭게 설정해 업무를 수행할 수 있도록 지원할 수 있어야 한다.

- 기본적으로 이슈/요구사항에 대해 수정, 변경 등의 이력을 추적할 수 있어야 하며 해당사항을 쉽고 가시적으로 볼 수 있게 지원하는 도구를 선택해야 한다.

- 가장 중요한 것은 일원화된 커뮤니케이션 채널의 역할을 수행할 수 있도록 지원하고 모든 이슈 및 요구사항의 가시화 및 투명화로 직관적으로 상호 협업에 필요한 정보를 제공할 수 있는 시스템을 선택해야 한다.

2. 통합 IDE 개발 도구

- 이클립스와 같이 플러그인(Plugin)을 풍부히 제공하고 범용성이 높은 도구를 이용해 표준 개발환경을 구성해야 한다. 신규 개발자 유입 시 개발도구를 빠르게 개발자에게 배포할 수 있도록 구조를 설계해 러닝 코스트를 줄이는 것이 효과적이다.

3. 소스코드 형상관리 도구

- SVN, Git 등 소스코드를 리포지토리(Repository)에 버전별로 저장해 관리할 수 있는 도구를 사용해 소스코드를 관리한다.

- 소스코드 버전관리 도구를 활용해 개발단계에서부터 운영단계까지 통합적으로 관리하고, 개발 시 소스코드 변경 히스토리를 운영 단계에서 참고할 수 있도록 해야 한다.

4. 빌드/의존성 관리 도구

- 메이븐 등의 빌드 및 의존성 관리 도구를 이용해 빌드를 단순화시켜 관리한다. 필요하다면 개발에 사용되는 라이브러리의 저장소를 넥서스 등 사설 저장소를 이용해 구성하도록 한다. 해당 도구 역시 CI/CD 도구에서 사용가능한 도구를 선택하는 것이 중요하다.

5. 품질 검증 도구

- 필요한 검증 기준에 의해 품질 검증 도구를 구성한다. PMD 룰셋 점검이나 소나큐브 같은 정적 품질관리 도구를 이용해 기본적인 품질 점검이 가능하다.

- 점검도구 선택에서 중요한 것은 CI/CD 도구와 연계돼 관리할 수 있어야 한다는 것이다. CI/CD의 자동화 작업에 해당 도구 검증 절차를 작업화 시킬 수 있어야 전체적인 사이클이 끊어지지 않는다.

6. 지속적인 통합/배포 도구

- 데브옵스, ALM에서 가장 중요한 역할을 담당하는 도구로, 각종 빌드, 테스트, 배포 프로세스를 자동화해 소프트웨어 개발 생산성을 높이는데 도움을 준다.

- CI/CD도구는 개발자가 직접 SVN을 통해 소스코드를 체크아웃(Checkout)하고 빌드함으로써 목적물 파일이 생성되면 해당 파일을 FTP를 통해 서버에 업로드하고, SSH로 접속해 명령어 프롬프트를 이용해 배포를 하는 일련의 반복적인 작업들을 잡(Job)이라는 단위로 생성해 자동화 해주는 역할을 담당한다.

- 아래 <그림>에서처럼 실제 빌드, 테스트 등 ALM의 가장 중심이 되는 역할을 담당하기에 필수적으로 개방형 구조의 툴(Tool)을 선택해 연속성과 확장성을 보장받아야 한다. 개방형 구조 의 연결을 지원하지 않는 도구 선택은 향후, 지속적으로 변화하는 환경에 대응하기 힘들고, 해당 툴에 종속돼 지속적으로 비용이 발생할 가능성이 아주 크다.

- CI/CD 도구를 이용해 정형화되고 검증된 작업을 자동으로 수행하도록 함으로써 휴먼에러(Human Error)를 방지하고 배포 시 발생하는 문제를 빠르게 확인할 수 있으며, 장애시간을 최소화 할 수 있다.

- 하지만 이런 CI/CD 도구를 쓰기 전, 먼저 내부 구성원 간의 업무 프로세스 조율이 선행되지 않는다면 불완전한 CI/CD가 될 것이다. 완전한 CI/CD를 구현하기 위해 먼저 전체 흐름과 각 조직 간의 역할을 정의하고, 구성원 간의 의견을 수렴해 지속적으로 발전할 수 있는 업무 프로세스를 만들어야 한다.

- 배포 계획을 수립하고 해당 배포 계획에 포함될 요구사항을 배정해 관리자에게 결재를 얻는다. 다른 서비스와의 영향도가 높은 서비스의 경우 배포 담당자가 CI/CD 도구를 통해 수동으로 배포하고, 영향도가 미미한 서비스의 경우 시스템을 통한 자동 배포를 수행한다는 각 조직 업무 역할 간의 상세 정의가 필요하다.

7. 데브옵스 기반 운영/모니터링 도구

- 애플리케이션의 전체 생명주기를 통합해 모니터링 및 관리할 수 있는 도구를 선택해야한다.

- 전체 애플리케이션 생명주기 아키텍처를 통합할 수 있어야 정상적으로 데브옵스를 지원할 수 있기 때문에 툴 체인을 구성하는 각종 도구들과 반드시 연결될 수 있어야 한다.

- 해당 도구를 통해 전체 프로젝트의 진행 상황을 모니터링하고, 필요 시 이슈/요구사항의 생성부터 소스코드 개발, 운영 및 배포까지의 모든 이력을 추적하고 감시할 수 있는 역할을 수행한다.

데브옵스 성공 열쇠

지금까지 데브옵스 성공을 위해 필요한 사항들 및 데브옵스 툴 체인 구성도구 선택의 기준과 유의점에 대해 알아봤다. 그러나 실제로 이렇게 데브옵스를 구성하는 것은 결코 손쉽게 할 수 있는 일은 아니다. 지금까지 국내 여러 기업과 기관이 데브옵스를 시도했으나 적용하는데 실패하는 경우가 많았다.

시장분석기관 콜맨팍스 리서치(CPR: Coleman Parkes Research)의 ‘애자일과 데브옵스, 속도와 고객 가치 가속화’ 보고서에 따르면 한국 기업의 데브옵스 활용을 가로막는 주요 원인으로 ▲조직 문화 및 사고방식/변화 거부 ▲사내 기술 및 지식 부족 ▲적절한 기술 및 도구 통합 등이 꼽혔다. 조직의 문화 및 인식 개선과 적절한 기술 및 도구 통합이 데브옵스 도입 및 활용에 가장 큰 걸림돌임을 알 수 있는 대목이다.

이를 통해 데브옵스 성공의 열쇠는 크게 두 가지로 정의할 수 있다. 바로 문화 변화와 적절한 툴 체인의 활용이다. 조직 문화의 변화와 도구 지원은 상호 연관관계에 있다. 인식이 변화하면서 변화를 지원하는 편리한 도구를 찾을 수 있고, 편리한 도구의 지원은 인식의 변화를 앞당길 수 있는 촉매제가 되기 때문이다.

다행이 문화적인 부분은 국내에서도 널리 활용되고 있는 IT서비스관리 국제표준인 ‘ITIL’에서 애자일과 데브옵스를 받아들여 v4를 발표하기에, 조직 문화와 사고방식 변화 거부에 대한 부분이 상당히 완화될 것으로 기대된다.

이제 데브옵스를 준비하는 기업과 기관은 내부의 지속적인 교육과 실천으로 조직 내 문화 변화를 유도하고, 더 좋은 경험과 더 좋은 환경을 제공해 주기 위해 적절한 애플리케이션 아키텍처를 수립해 그에 맞는 툴 체인 구성에 고민과 노력을 기울여야 한다. 이 두 가지 노력이 병행된다면 데브옵스라는 선물상자는 자연스럽게 조직 내에 자리 잡게 될 것이다.