2015.06.22

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

Matthew Heusser | CIO

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

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

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

여기 그 사례를 살펴보자.

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

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

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

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


Credit: ThinkStock

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

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

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

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

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

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

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




2015.06.22

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

Matthew Heusser | CIO

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

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

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

여기 그 사례를 살펴보자.

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

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

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

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


Credit: ThinkStock

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

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

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

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

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

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

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


X