기고 | '개념에서 의의까지' 데브옵스 따라잡기

CIO

데크옵스라는 용어의 정의를 추적하다 보면 ‘애자일’, 시스템 관리’ ‘린’(lean) 등의 유행어 집합을 접하게 된다. 결국 동어반복에 그치는 설명들이다. 여기 좀더 이해가 쉬운 해설을 제시한다.

데브옵스(DevOps)의 기본 개념은 개발자(Developer)와 운영자(Operator)라는 두 가지 역할을 동시에 수행한다는 것이다. 얼핏 단순한 복합 직무로 여겨질 수 있다. 그러나 사실 데브옵의 개념을 보다 잘 이해하기 위해서는 개발자와 운영자 두 직무가 지금까지 어떤 역할을 수행해왔는지를 잠시 생각해볼 필요가 있다.

운영자의 책무는 업타임(uptime)과 안정성을 보장하는 것이었다. 그 역할을 수행하는 가장 간단한 방법은 시스템의 통로를 걸어 잠그고 변화를 최소화하는 것이다. 이와 반대로 소프트웨어 개발자는 변화를 만들어내는 사람이다. 기본 역할에서부터 그 방향성이 정반대인 것이다. 즉, 데브옵스의 시작은 두 역할 사이의 벽을 허무는 것에서부터 출발한다.

여기 그 사례를 살펴보자.

수 년, 길게는 수십 년 전부터 시스템 관리자들은 반복적 작업과 설정을 자동화하기 위해 몇몇 스크립트(배시(bash), 펄(pearl), 오크(awk), 세드(sed))를 작성해왔다. 이들 스크립트는 코드지만, 시스템 관리자들이 작성하는 코드는 프로그래머들이 따라야 하는 방법론들 중 무엇도 따르지 않았다.

이는 어떤 요청이나 공식적인 테스트 프로세스, 배치 프로세스도 갖추지 않았으며 소스 코드 통제에도 포함되지 않았다. 어떤 작업 표준도 가지지 않으며 이들 코드는 생산 코드와는 다른 프로그래밍 언어를 취했다.

코드의 대상 가운데는 프로그래머가 재사용 가능한 것도 있었지만 프로그래머들은 그것의 존재를 알지 못했다. 두 직무 사이의 공동 작업 구조가 있었다면 지식과 활동, 근본적으로는 코드베이스의 공유까지 가능했을 것이다

시스템 관리 작업의 자동화와 반복은 프로그래머들이 가장 잘 할 수 있는 작업이다. 이런 문제의식에서부터 시작된 것이 오늘날의 데브옵스 트렌드라 할 수 있다.


Credit: ThinkStock

데브옵스라는 개념
구축과 배포, 유닛 테스트 재구동, 통합, 엔드 투 엔드 확인 작업 자동화, 가상 머신(VM) 생성… 모두 명확하고 정의 가능한 비즈니스 프로세스들이다. 실제로 시스템 관리자들은 이와 관련한 메뉴얼북이나 FAQ, 위키 페이지 등을 제작해 업무에 활용하기도 한다.

프로그래머는 자동화 하는 게 일이다. 그렇다면 개발자의 역할(자동화)과 운영(배치 및 유지)을 합쳐버리는 건 어떨까? 운영의 일부를 자동화하고 테스팅하는 두 역할을 병합한다는 것이야말로 데브옵스의 핵심을 이루는 개념이다.

분업을 중시했던 전통적인 IT 및 프로세스 엔지니어링 분야에 있어 데브옵스는 분명 부정적인 것으로 간주될 수도 있다. 그렇지만 수많은 워터폴(Waterfall) 프로세스 문서들은 스크럼이나 애자일 소프트웨어에 대해서도 비슷한 말을 하지 않았던가?

데브옵스의 두 가지 방식
첫 번째 방식은 개발자들이 짧게는 수 주에서 수 개월 정도 운영 과정에 참여하게 하는 것이다. 이론적으로는 인-옵 프로그래머(programmer-in-ops) 가 기존 코드베이스를 체크하고 주기적인 작업을 스마트한 방식으로 자동화 하며, 재사용 가능한 코드 라이브러리를 만들고, 코드를 통해 만들어 낸 가상 머신으로 물리적 머신을 대신할 수 있게 될 것이다.

이 방식은 얼핏 보기에는 분명 즉각적인 성과를 만들어낼 것처럼 보이기도 한다. 하지만 실제로는 프로그래머가 과중한 업무량에 지쳐 쓰러지고 실제 데브옵스 도입이 제한적으로 머물게 될 확률이 높다.

또 다른 방법은 개발 팀에 지원 책임을 높게 할당하는 것이다. 예를 들어 프로그래밍 팀에서 빌드에서 배치, 지원까지 모든 책임을 맡아 한 번에 2주씩 지원 업무를 경험하도록 하는 것이다.

이를 통해 개발자는 코드베이스에 대해 더욱 폭넓은 이해를 할 수 있게 되고 자신의 일을 지원하는 것이 얼마나 쉽지 않은 일인지도 알게 된다. (그렇지만 여전히 소규모의 운영 팀이 생산 서버나 데이터베이스 같은 인프라스트럭처를 지원해줘야 할 것이다.)


빌드 자동화
지속 통합(CI, Continuous Integration) 툴이야 말로 여기 언급된 것들 중 가장 널리, 많이 쓰이는 툴일 것이다. 일부 기업들은 빌드를 계속하기도 하지만 자동화 빌드의 잠재력은 컴파일 단계에서 그치지 않는다. 브랜치에 따른 로깅 및 태깅 빌드를 포함할 수도 있고, 커밋 넘버와 브랜치에 연결된 아카이브에 빌드를 저장할 수도 있으며, 빌드에 기능을 연결할 수도 있을 지도 모른다.

빌드가 완성되면 항상 모든 유닛 테스트를 진행할 수 있을 뿐 아니라 소프트웨어를 개발, 테스트, 및 스테이징 서버에 언제든지 배치할 수 있다. CI툴에서 웹 서비스나 GUI 엔드 투 엔드 체크를 통해 새로운 코드에 큰 결함은 없는지 살펴볼 수 있다.

그렇지만 이것이 지속적 전달(continuous delivery )은 아니다. 코드가 자동으로 프로덕션 코드가 되는 것은 아니다. (일부 기관들에서는 배치할 때마다 개발 환경을 업그레이드 하는 게 아니라 완전히 새로운 가상 서버를 구매하기도 하고, 프로그래머 당 하나 이상의 가상 환경을 만들기도 한다.)

결함으로 인해 발생하는 데미지가 해당 결함의 심각성과 그것이 얼마나 많은 사람들에게 노출되었느냐에 의해 결정된다고 한다면, 최대한 빨리 그 결함을 발견하고 수리하는 것이야 말로 피해를 최소화하는 방법일 것이다. 많은 사용자들이 발견하기 전에 문제를 먼저 발견하는 것이 쉽지만은 않지만, 시각적 모니터링과 대체로 어느 정도 도움을 받을 수 있다.

서버 로그에는 엄청난 분량의 정보가 들어 있다. 리퀘스트 처리에 얼마만큼의 시간이 걸리는지에서부터 시스템에 404, 500 에러가 얼마나 발생했는지까지 말이다. 이 에러들을 그래파이트(Graphite)와 같은 오픈소스 툴을 사용해 그래프로 시각적으로 표현하면 문제가 발생하는 즉시 이를 파악하고 조치를 취할 수 있다.

이러한 작업이 완성되고 나면, 프로덕션 롤아웃 단계는 웹 페이지, 혹은 최소한 명령행 인터페이스상에 자동화할 수 있다. 지속적인 배치 시스템은 여기서 프로덕션으로 한 단계만 더 나아가면 된다.

푸시 버튼 배치는 푸시 버튼 해결책으로 이어지게 되고 이는 프로덕션 모니터링과 만나 결함의 TTL(time to live)을 극적으로 줄이게 된다.

설정 플래그
설정 플래그(Configuration Flag)는 TTL을 줄이는 또 다른 메커니즘이다. 프로덕션 코드를 바꾸는 대신 새 코드에 “if(feature){}”을 적용해 코드를 바꾼다. 프로그래머는 플래그를 온 또는 오프로 저장한 디스크상의 파일을 바꾼다. 이는 코드를 변경하는 것이 아니므로 새로운 빌드/배치가 필요 없다.

노아 서스먼(Noah Sussman)의 “컨피그 플래그: 러브 스토리(Config Flags: A Love Story)”는 이 주제를 훨씬 깊이 있게 다루고 있다. 설정 플래그는 점진적인, 그리고 궁극적으로 폭넓은 고객 유형을 만족시키는 방안이 될 수 있다. 맨 처음에는 직원, 다음으로 직원들의 가족, 베타 테스터, 리스크 감내 고객, 다음으로는 정기 고객, 그리고 마지막으로 ‘기업’고객 및 리스크 회피적 고객 순으로 배포 범위를 넓혀나감으로써, 새로운 기능을 알려나가는 과정에서 시스템 관리와 피드백 수집의 이점을 누릴 수 있다.

그 구체적인 방법론은 다양하게 전개될 수 있지만, 대표적인 전략을 한 가지 소개하자면 2008년 출간된 “마이크로소프트의 소프트웨어 테스트 비법(How We Test Software in Microsoft)”에 소개되며 알려진 ‘생산 중 테스트(Testing in Production)’을 이야기해볼 수 있다.

이 아이디어들은 대부분 컨셉트에 그치지만, 그것을 실행할 방법은 상용, 오픈소스 시장에 다양하게 존재한다. 가장 흔히 이용되는 전략 중 하나는 퍼블릭/프라이빗 클라우드 내에 가상 서버 팜을 생성하는 것이다. 새로운 빌드를 생성하되 배치하지 않는 방식이다.

이 경우 시스템은 새로운 기기로 로드 밸런스를 조절해 보낼 수 있다. 이러한 서비스 ‘전환’은 사용자가 그 과정을 인식할 수 없도록 이뤄진다. 또한 혹 발생할 수 있는 심각한 문제에 대비해 전환 후 수 분 간은 기존 시스템 역시 대기하게 된다.

(실물 혹은 가상) 기기 셋을 설정하는 것은 다량의 스크립팅과 자동화를 요구한다. 이 과정을 지원하는 툴로는 셰프(Chef)와 퍼펫(Puppet)이 대표적으로, 모두 데브옵스 업무에 자주 사용되고 있다.

데브옵스에 관해 듣게 되는 가장 실망스러운 말은 데브옵스가 ‘새로운 역할’라거나, 이를 위해 제 3의 ‘팀’을 꾸려야 한다는 것이다. 일부 개발자들은 자동화 혹은 인프라스트럭처 작업의 구축/배치를 선택할 수도 있지만, 데브옵스라는 아이디어는 본래 공동 작업을 원칙으로 한다. 다른 이들이 이해하지 못하고, 신경도 쓰지 않는 모호한 디테일들을 다루는 특수직이 되어버린다면, 결국 데브옵스은 머지않아 자취를 감추게 될 것이다.

데브옵스 테스트는 당신의 팀이 어느 정도나 데브옵스을 받아들였는지, 그리고 앞으로 받아들일 수 있을지를 간단히 평가할 수 있는 도구다. 완벽하진 않지만 빠르고 간편하게 진행할 수 있으니 시험 삼아 참여해보자. 결국 미래는 당신이 써 내려가는 것이다.

* Matthew Heusser는 엑실리온 디벨롭먼트의 수석 컨설턴트다. ciokr@idg.co.kr