[컴퓨터월드] 문종민 솔루션즈 아키텍트 매니저는 15년간 소프트웨어 아키텍트(Software architect)로 활동하면서 제조, 공공, 금융, 의료 등 다양한 산업분야의 시스템을 구축했다. 2017년 AWS 솔루션즈 아키텍트를 시작으로 현재 금융산업팀의 솔루션즈 아키텍트 매니저로 활동하고 있다. <편집자 주>

대부분 기업들은 이미 디지털 트랜스포메이션(Digital Transformation)을 추진했거나 현재 추진하고 있다. 이와 함께 데브옵스(DevOps) 또한 디지털 트랜스포메이션의 성공을 위한 핵심으로 자주 언급되고 있다. 그러나 데브옵스와 관련해서는 실제 의미하는 바를 이해하지 못하거나, CI/CD(Continuous Integration, Continuous Delivery, 지속적 통합/전달)를 위한 도구로 접근하는 경우가 많다. 이번 글에서는 디지털 트랜스포메이션과 데브옵스의 연관 관계와 데브옵스 접근 방식을 위한 필수 요소가 무엇인지 살펴보고자 한다.

디지털 서비스를 선호하는 고객의 수가 갈수록 늘어나고, 혁신적인 디지털 서비스를 제공해온 아마존(Amazon), 넷플릭스(Netflix), 에어비앤비(AirBnB), 몬조(Monzo, 클라우드 기반 영국 은행)와 같은 클라우드 기반 혁신 기업의 성공 사례가 이어지면서 디지털 트랜스포메이션은 더욱 가속화되고 있다.

소프트웨어는 비즈니스의 핵심적인 차별 요소다. 빠르고 안정적이고 편리한 소프트웨어의 제공이야말로 디지털 트랜스포메이션의 핵심이며 데브옵스는 빠르고 빈번하며 중단 없는 서비스 제공을 위한 하나의 방법론이다.

AWS를 비롯한 많은 데브옵스 서비스 제공 기업들은 데브옵스가 문화이자 관행(practice)이며 도구라고 강조한다. 전통적인 접근 방식을 사용하는 기업보다 훨씬 더 자주, 더 빠르게 배포하면서도 더 낮은 오류율을 보인다는 데브옵스의 효과는 이미 검증된 상태이지만 실제 기업들의 완전한 데브옵스로의 전환은 쉽지 않다.

DORA(DevOps Research and Assessment)가 발표한 ‘2021년 데브옵스 현황’ 보고서에 따르면 소프트웨어 배포에서 최정상급 팀이 최하위팀보다 973배 더 자주, 6,570배 더 빠르게 배포하는 것으로 나타났다. 다만 데브옵스는 도구만으로 완성되는 솔루션이 아니므로 현재 조직이 어떤 상태에 있는지에 대한 명확한 이해와 분석이 있어야만 향후 로드맵을 구성할 수 있다는 사실을 간과하지 말아야 한다.

데브옵스 이전의 IT

데브옵스의 이점을 이해하기 위해서는 먼저 IT가 동작하는 전통적인 방식을 살펴볼 필요가 있다. 기업마다 운영방식은 조금씩 다르겠지만 어느 정도 규모가 있는 기업이라면 개발 조직과 운영 조직이 나뉘어져 있으며 이들 조직은 각각의 역할을 수행한다.

개발팀은 비즈니스 요구사항이나 오류 사항을 접수받아 이를 각 개발자의 로컬 개발환경에서 개발, 테스트를 수행하고 이상이 없으면 소스 형상관리 시스템에 반영하게 된다. 형상관리 시스템에 반영된 코드는 주기적으로 개발서버에 배포된다.

운영서버로의 배포는 통상 약속된 시간(ex, 주 1회, 월 1회 사용자가 거의 없는 야간 시간 등)에 수행한다. 이때 개발서버와 운영서버 사이에 스테이징 서버를 두어서 최종적으로 이상이 없다고 판단될 경우 스테이징 서버에 반영된 것과 동일하게 운영서버에 반영되도록 한다. 또한 CI/CD를 기반으로 소스코드 작성 시 각종 테스트 툴을 활용해 코드 단위 테스트, 시큐어 코딩 점검 등과 같은 기능을 활용해왔다. 체계적인 운영 방식이지만 자세히 들여다보면 다음과 같은 어려움을 경험하게 된다.

ㆍ긴 배포 주기

약속된 운영 서버 배포일에 모든 개발팀이 대기하고, 배포는 운영팀 또는 배포 담당자가 수행한다. 배포 이후 기능 동작 여부를 테스트로 확인한다. 이 방식은 일정 기간 동안 서로 관련 없는 기능들을 모아서 한번에 배포하는 방식이다 보니 배포 주기가 길다.

ㆍ예기치 않은 오류

개발자가 로컬 환경에서 테스트 시 이상이 없어서 코드를 형상관리에 반영했고, 개발 환경에서도 이상이 없어 배포를 진행했음에도 스테이징이나 운영서버에서 오류가 발생하는 상황이 빈번하게 일어난다.

ㆍ타 업무 수정으로 인한 영향

초기 개발 시 잘 동작하던 기능에 추가적인 변경이 없었음에도 배포 후 갑자기 오류가 발생한다. 업무 간 호출 시 타 업무 테이블의 직접 액세스를 금지하고 API 호출을 하도록 규칙을 정하고, ‘코드 영향도 분석’ 툴을 활용하는 경우라면 그나마 오류 원인을 찾는 것이 용이하다. 그러나 타 업무 테이블을 직접 액세스 하는 방식으로 개발한 경우 오류 발생 시 근본적인 원인을 추적하기 어렵다.

ㆍ충분하지 않은 테스트 코드

개발자는 테스트 코드를 개발할 시간이 부족하거나 코드 빌드 시 테스트 코드 실패로 인해 배포 실패를 만드는 주범이 되기를 꺼려해서 충실한 테스트 코드를 작성하지 않는 경향이 있다. 이로 인해 형식적인 단위, 통합 테스트 코드는 빌드 테스트의 효과를 감소시킨다.

위와 같은 문제들로 배포가 한 번에 성공적으로 끝나는 경우보다 발견된 문제를 해결하고 반영하는 일이 수 차례 반복되어서 한 번의 배포가 일종의 큰 행사처럼 되는 경우가 많다. 또는 하나의 기능 문제로 인해서 관련 없는 전체 배포를 이전 상황으로 롤백(rollback)하는 경우도 발생한다. 이는 소프트웨어의 출시 속도를 늦추고, 결과적으로 디지털 트랜스포메이션을 저해하게 된다.

데브옵스로 얻고자 하는 것

우리가 데브옵스를 통해서 얻고자 하는 것은 결국 위와 같은 문제를 해결함으로써 보다 빠르고 안전하게 소프트웨어를 출시하는 것이다.

우선 기존의 방식보다 더 빠르고 안전하게 기능을 출시하려면 보다 작은 단위로 서버에 반영해야 한다. 여러 기능을 모아서 한번에 배포할 경우 실패할 확률이 높아지고 원인을 찾기 어렵다.

운영서버에 적용되는 변경 사항이 적을수록 진단과 수정이 쉬워진다. 이런 이유로 배포가 정기적인 큰 행사가 아니라 필요할 때마다 수행하는 일상 업무가 돼야 한다. 또한 배포 과정에서 운영팀이나 특정 배포 담당자에게만 의지해서는 안된다.

보다 작은 단위의 배포를 위해 개발과 운영을 결합해서 역할 단절을 최소화하고 개발팀에 오너십(Ownership)을 부여해서 전체 프로세스에 대한 책임을 지게 하자는 것이 데브옵스의 핵심이다. 이를 달성하려면 올바른 기술 뿐만 아니라, 전체 IT 부서의 재구성이 필요하다. 개발팀이 비즈니스 로직만 개발하는 것이 아니라 전체 프로세스에 참여하도록 기술을 확장하고 작업 방식을 근본적으로 바꿔야 한다. 이러한 문화적 변화가 새로운 기술의 채택 자체보다 훨씬 더 어렵다.

데브옵스가 문화의 변화에 관한 것이라고 하는 이유도 여기에 있다. 데브옵스의 도구는 이러한 문화를 강화하고 행동을 가속화하는 데 사용되는 수단이다. 또한 데브옵스의 조직 문화와 데브옵스를 위한 도구는 별개가 아니라 서로 깊이 연관되어 있다.

데브옵스 팀 구성 유형

실제 최근 업계의 가까운 소프트웨어 아키텍트로부터 잘못된 조직 구성이 커다란 실패로 이어지는 사례에 대해 들었다. 해당 조직에서 업무는 마이크로서비스 아키텍처(Microservice Architecture, MSA) 구조로 나누어 놓았으나 배포는 CI/CD를 통한 배포 자동화 수준으로 구성해 두고 전통적인 IT 운영 방식으로 개발과 배포를 진행했다. 이로 인해 장애가 발생하거나 새로운 단위 시스템이 추가되거나 구성의 변경이 있을 때 배포 담당자와 소프트웨어 아키텍트가 비즈니스 개발자를 찾아다니고 개별 시스템에 접속해서 원인을 파악하느라 많은 시간이 소요됐다.

차라리 모놀리식(Monolithic) 방식일 경우에는 기계와 일하는 시간은 길었지만 비즈니스 담당자와의 커뮤니케이션이 지금처럼 힘들지는 않았다고 했다. 이는 데브옵스에서 조직간 커뮤니케이션이 얼마나 중요한지와 이를 관리하기 위한 조직 구성이 필수적이라는 것을 보여주는 단적인 예이다.

그러면 개발과 운영을 결합하기 위해 데브옵스 조직을 어떻게 구성해야 할까? 여기에 정해진 답은 없다. 그러나 개발팀에서 운영까지 맡고 있으니, 운영 조직은 필요 없고 개발팀에서 모두 알아서 배포, 모니터링, 운영을 전담해야 한다는 것은 잘못된 이해이다.

실제 개발을 해보면 운영과 관련된 일은 기능 구현보다 우선순위가 낮아지기 때문에 이 방식은 데브(Dev)만 남고 옵스(Ops)가 점점 사라지게 되는 대표적인 안티패턴으로 인식된다. 중요한 것은 개발 조직과 운영 조직이 각자의 역할을 수행하되, 조직간 업무의 파악과 적극적인 커뮤니케이션을 주도하는 역할 또한 필요하다는 것이다. 그리고 개발 조직 인력과 운영 조직 인력이 공동의 목표를 설정하고 이를 달성하기 위해 협력하는 것도 중요하다.

이를 위해 현재 자신들의 조직 상태와 서비스에 대한 이해가 수반되어야 한다. 예를 들어 기업이 하나의 메인 시스템을 개발하는 스타트업인지, 여러 업무 시스템을 담당하는 각각의 개발팀이 있고 이와 완전히 구분된 큰 IT 운영 조직이 있는 기업인지에 따라 데브옵스 조직을 구성하는 방법은 다르다.

하나의 서비스마다 이를 개발하는 팀과 운영하는 팀이 구성되는 기업의 경우 일반적으로 원활한 협력을 구성하기가 상대적으로 용이하다. 최근에는 소프트웨어 개발팀의 이름을 아예 데브옵스 팀이라 칭하고 내부에서 개발인력, 운영인력, 그리고 그 둘을 결합하는 데브옵스 엔지니어로 구성하는 기업들이 많다. 일반적으로 메인 서비스 하나를 중심으로 비즈니스를 수행하는 스타트업 기업들에서 이러한 구성을 발견할 수 있다.

그러나 대형 금융회사나 제조회사와 같이 핵심 시스템을 중심으로 여러 서비스나 제품 별로 시스템을 구축해온 기업들은 하나의 큰 운영 조직과 여러 개의 개발팀으로 구성되어 있다. 이러한 경우 사일로(Silo)로 인한 단절은 더욱 심각하고 당장 운영 조직을 급진적으로 변경하기 어렵다. 이 경우에는 각 개발팀에 데브옵스 엔지니어를 배치해 기존 운영 조직과 긴밀한 커뮤니케이션을 만들어 가는 것이 중요하다.

이와 관련된 더 자세한 사항은 데브옵스 토플로지(https://web.devopstopologies.com/)를 참고하기 바란다.

데브옵스를 위한 핵심 관행

더 자주, 더 빠르게 소프트웨어를 출시하기 위해서는 강력한 기술과 도구가 필요하지만 데브옵스를 위한 관행 또한 매우 중요하다. CI/CD 배포 파이프라인이 잘 구성되어 있다면 소프트웨어를 자주 배포할 수 있으므로 데브옵스를 원활하게 수행할 수 있을 것처럼 보인다. 그러나 앞서 데브옵스 이전의 IT 에서 살펴봤듯이 실제 CI/CD 배포 파이프라인이 모든 문제를 해결해주지는 않는다. 데브옵스가 성공적으로 정착하기 위한 핵심 관행은 다음과 같다.

ㆍ테스트 기반 개발

CI/CD 파이프라인에서 소스 코드 빌드 시 테스트 코드를 실행함으로써 테스트 코드 통과 후 빌드의 성공으로 이어지도록 하는 방식은 이미 많은 기업에서 적용하고 있다. 그러나 경험으로 볼 때 테스트 코드를 충실하게 작성하는 개발자는 드물다. 비즈니스 로직 개발 때문에 바쁘기도 하지만 한번 작성된 테스트 코드도 상황에 따라 계속 변경되어야 하기 때문이다.

특히 테스트 코드 실패로 빌드가 수행되지 않는 경우를 피하기 위해 테스트 코드를 제대로 작성하지 않는 경우도 많다. 그러나 모든 기능을 수작업으로 테스트할 수도 없고 한 기능의 변경이 다른 기능에 영향을 미치는 상황이 빈번하게 발생하므로 이를 빠르게 파악할 수 있는 방법은 테스트 코드를 충실하게 작성하는 것이다. 단위 테스트, 통합 테스트 코드를 작성하고 테스트 코드 커버리지를 메트릭으로 측정해서 지속적으로 관리해야 한다.

ㆍ업무시간에 운영서버 배포

하루에도 수 차례 기능을 출시하기 위해서는 업무 시간 중이라도, 사용자 트래픽과 관계 없이 배포할 수 있어야 한다. 계획대로 사용자가 거의 없는 야간이나 업무시간 이후에 배포를 하는 방식은 배포 주기를 길게 만들고 배포 단위를 크게 만든다. 초기에는 업무시간에 운영서버에 배포한다는 것이 안전성 측면에서 어렵더라도 이러한 부분을 메트릭으로 측정해서 점진적인 목표로 삼고 실행해야 한다.

ㆍ지속적인 측정

통상 시스템 구축 후 서버 모니터링, 네트워크 모니터링, 애플리케이션 성능 관리(APM, Application Performance Management) 솔루션을 적용하고 모니터링을 수행한다. 그러나 여러 시스템 간의 연계로 이루어지는 기능이나 마이크로서비스 아키텍처에서 문제의 원인을 정확히 특정하기 위해서는 이러한 모니터링 솔루션이 개별적으로 생성하는 로그 분석만으로 빠르게 원인을 찾기가 어렵고, 사일로 형태로 수집된 정보를 기반으로 별도의 분석을 수행해야 한다.

비즈니스를 위해 더 민첩하게 대응하려면 모니터링을 넘어 시스템의 전체적인 옵저버빌러티(Observability)를 높이는 것이 중요하다. 따라서 필요한 메트릭을 선정하고 이 데이터들을 통합해서 수집하고 즉시 조치할 수 있도록 해야 한다.

ㆍ‘자동화, 자동화, 자동화’

기존의 전통적인 환경에서는 인프라 및 서버 구성을 한 후 개발을 수행한다. 그리고 앞에서 설명한 CI/CD 파이프라인을 구성한다. 그러나 최근에는 기존보다 더 다양한 형태의 아키텍처가 보편화 되었으며, 더 나은 방식이 있을 경우 신속하게 아키텍처를 변경하는 방식으로 진화하는 것이 필요하다. 또한 개발, 스테이징, 운영환경 외에도 여러 환경을 생성하는 작업도 빈번하게 발생한다.

이를 위해 코드형 인프라(Infrastructure as Code, IaC)와 같이 인프라 환경도 코드로 작성해서 생성, 관리하는 노력을 하고 있다. 이외에도 애플리케이션 라이프사이클 전반에 걸쳐 수작업으로 이루어지는 부분에 대한 지속적인 자동화 노력이 필요하다.

데브옵스를 위한 클라우드 기술

마지막으로 데브옵스를 위한 기술과 도구의 관점이 있다. 데브옵스 문화를 위한 조직, 관행을 뒷받침해주는 것이 기술과 도구가 바로 그것이다. 데브옵스가 클라우드의 전유물은 아니지만 기술과 도구의 관점에서 이를 뒷받침하는 클라우드 서비스는 데브옵스와 디지털 트랜스포메이션을 위한 중심으로 자리잡고 있다.

IT 애널리스트 회사인 프리폼 다이나믹스(Freeform Dynamics)에 따르면, 클라우드나 데브옵스를 별도로 적용했을 경우에는 소프트웨어 출시 속도가 약 50% 향상되지만 이를 같이 활용할 경우 81% 향상된다. 그 이유는 클라우드에서 제공하는 서비스의 활용으로 환경을 준비하는데 드는 시간을 줄이고 실제 고객에게 제공되는 제품과 서비스를 구축하는 데 집중할 수 있기 때문이다.

따라서 클라우드 서비스 제공 업체의 서비스가 가진 이점을 충분히 활용하는 것이 데브옵스의 효과를 높일 수 있는 방향이라 할 수 있다. 이를 위해 고려해야 할 클라우드 기술은 다음과 같다.

ㆍ완전 관리형 서비스

완전 관리형 서비스는 사용자가 가용성, 확장성을 고려하고 가상머신에 직접 소프트웨어를 설치하고 환경을 설정하고 운영하는 수고를 덜어준다. 클라우드 서비스 제공자가 고가용성, 성능, 지속적인 모니터링, 자가 복구 등의 기능을 제공하므로 사용자는 애플리케이션 개발에 집중할 수 있다.

ㆍ자동화

코드형 인프라(Infrastructure as Code, IaC)를 제공해서 사용자가 필요한 리소스와 인프라를 빠르고 효율적으로 구축할 수 있도록 한다. 또한 개발 및 테스트, 배포, 워크플로우, 구성관리 등의 프로세스를 자동화 할 수 있다.

ㆍ보안 및 거버넌스

빠른 개발 및 배포를 수행하면서도 거버넌스를 실현하고 가시성을 유지할 수 있는 랜딩 존(Landing Zone), 시스템 구성 정의 및 추적, 규정 준수(compliance) 유지 등의 기능을 제공한다.

ㆍ모니터링 및 로깅

클라우드 서비스와 네트워크 모니터링 뿐 아니라 클라우드 서비스의 사용을 추적하는 서비스, 마이크로 서비스 아키텍처를 이용해 구축된 분산 애플리케이션을 분석, 디버깅하는 서비스 등과 같은 다양한 모니터링 및 로깅 서비스를 제공한다.

ㆍCI/CD 서비스

애플리케이션 코드 버전 관리부터 빌드/테스트, 배포 자동화, 소프트웨어 출시 워크플로우 서비스를 제공하고 써드파티(third-party) 솔루션과의 통합을 지원한다.
 

데브옵스를 위한 준비

지금까지 디지털 트랜스포메이션을 위해 데브옵스가 수행해야 하는 역할과, 데브옵스 문화를 위한 조직 구성, 성공적인 데브옵스를 위한 관행, 데브옵스 효과를 높일 수 있는 클라우드 제공 기술 등에 대해 살펴보았다.

성공적인 데브옵스는 빠르고 안전하게 제품을 출시해서 비즈니스의 효과를 높이는 데 있다. 이러한 공통적인 이해를 출발점으로 기대효과와 성공의 매트릭을 수립하고 기업의 현재 상태를 확인해야 한다. 그리고 이를 기반으로 계획을 수립하되 도구에 집중하기보다 일하는 사람과 프로세스를 기반으로 데브옵스의 관행이 정착될 수 있도록 집중하고, 도구를 활용해 그 효과를 높여야 한다.

데브옵스는 일회성 프로젝트로 끝나는 것이 아니라 장기적인 관점을 바탕으로 지속적으로 개선해야하는 활동이다. 이를 위해 개발자, 운영 엔지니어뿐 아니라 조직 관리자 및 비즈니스 의사 결정권자의 의지와 후원도 필요하다.