데브옵스

만드는 쪽과 굴리는 쪽 사이에 선 벽을 허물자는 데서 출발했습니다. 갈라져 있던 두 일을 한 흐름으로 잇습니다. 무엇을 하는 일이냐는 물음의 답이 한 문장이 아니라 목록으로 열립니다.

쉽고 빠른 이해

이 구역이 무엇을 다루나 — 만드는 사람과 운영하는 사람 사이를 가르던 벽을 없애고 개발과 운영을 하나의 흐름으로 잇는 자리입니다. 변경을 작게 자주 내보내고 그 결과를 서로 나누는 일이 여기서 다뤄집니다.

왜 한 문장 정의가 안 서나 — 이 자리는 하나의 기술이 아니라 문화와 자동화와 측정과 공유 같은 여러 관행이 뒤섞인 묶음이라, 어느 하나만 떼어 정의로 삼을 수 없습니다.

안에서 무엇으로 갈리나 — 어느 문서를 보느냐에 따라 관행의 묶음으로 보기도 하고, 개발과 운영을 잇는 결합으로 보기도 하고, 문화와 도구를 아우르는 조합으로 보기도 합니다. 서비스 운영을 세부까지 어떻게 굴릴지는 이 구역이 정하지 않고, 그 일은 옆 구역이 받습니다.

상세

Google 이 펴낸 SRE(Site Reliability Engineering, 사이트 신뢰성 엔지니어링) Workbook 1장은 데브옵스를 IT(Information Technology, 정보 기술) 개발과 운영과 네트워킹과 보안 사이를 가르는 사일로, 곧 앞에서 말한 벽을 허물려고 만들어진 느슨한 관행과 지침과 문화의 묶음이라고 적습니다. 건물을 설계하는 사람과 짓는 사람이 한 팀으로 묶여 함께 일하는 자리에 견줄 수 있습니다. 그 묶음을 CALMS라는 약자로 줄여 부릅니다 — 문화(Culture)와 자동화(Automation)와 린(Lean, 낭비를 줄이는 경영 기법)과 측정(Measurement)과 공유(Sharing) 다섯 낱말입니다. 정의의 몸통이 이미 이렇게 묶음입니다.

이 다섯 낱말은 John Willis 와 Damon Edwards 와 Jez Humble 이 정리했다고 같은 장이 적습니다. 공유와 협업이 이 운동의 맨 앞에 있다고 적습니다. 데브옵스식 접근에서는 먼저 무언가를 개선합니다. 흔히 그 개선은 자동화로 이뤄집니다. 그 결과를 측정한 뒤 동료와 나눈다고 적습니다. 그렇게 해서 조직 전체가 나아진다고 적습니다. CALMS 원칙 전부를 뒷받침하는 것은 문화라고 덧붙입니다.

한 문장 정의가 안 서는 이유가 여기서 드러납니다. 같은 장은 데브옵스 철학의 요소들 가운데 어느 하나도 서로에게서 쉽게 떼어지지 않는다고 적습니다. 그리고 그것이 본질적으로 의도된 설계라고 적습니다. 다만 비교적 따로 떼어 이야기할 수 있는 핵심 생각이 몇 있다고 덧붙입니다. 그것들을 소제목으로 갈라 나열합니다.

핵심 생각	한 줄 요지
사일로를 더 두지 않는다	운영 팀과 개발 팀을 따로 두는 배치에 대한 반작용입니다
사고는 정상이다	개인의 고립된 행동 하나만의 결과가 아니라, 일이 결국은 잘못되고 말 때를 대비한 안전장치가 빠져 있어서 일어나는 결과이기도 하다고 봅니다
변경은 점진적이어야 한다	변경은 작고 잦을 때가 가장 낫습니다

첫 번째 생각의 배경에는 지식이 부서마다 극단으로 갈리고 각자 제 몫만 최적화하려는 유인이 생기며 협업이 사라지는 문제가 있습니다. 이런 배치가 실제로 사업에 나빴던 경우가 많았다고 같은 장은 적습니다.

세 번째 생각이 어디로 이어지는지도 같은 장이 적어 둡니다. 작고 잦은 변경이라는 전략은 더 작은 변경의 자동화된 테스트와 잘못된 변경의 믿을 만한 롤백과 맞물린다고 적습니다. 그래서 지속적 통합과 지속적 전달 또는 지속적 배포 같은 변경 관리 방식으로 이어진다고 적습니다.

경계

SRE

서비스를 어떻게 굴릴지를 세부 수준에서 정하는 일도 이 구역인가. 아닙니다 — 그 처방은 SRE 가 받습니다. Google SRE Workbook 은 데브옵스가 어떤 의미에서 더 넓은 철학이자 문화라고 적습니다. SRE 보다 넓은 범위를 바꾸기 때문에 맥락에 더 민감하다고 적습니다. 운영을 세부 수준에서 어떻게 굴릴지에 대해서는 비교적 말이 없다고 적습니다. 예를 들어 서비스를 정확히 어떻게 관리할지를 처방하지 않는다고 적습니다. 대신 더 넓은 조직 안의 장벽을 허무는 데 집중하기를 택한다고 적습니다.

같은 책은 둘을 겹쳐 보는 한 줄도 남깁니다. 어떤 면에서 class SRE implements interface DevOps 라고 적습니다. 인터페이스가 지켜야 할 규약만 정하고 클래스가 그것을 실제로 구현하듯, SRE 가 데브옵스라는 규약을 구체적으로 구현한 사례에 가깝다는 말입니다.

플랫폼 엔지니어링

사내 개발자에게 쓸 인프라 바닥을 깔아 주는 일도 이 구역인가. 아닙니다. CNCF(Cloud Native Computing Foundation, 클라우드 네이티브 컴퓨팅 재단) 플랫폼 백서는 플랫폼 엔지니어링이 데브옵스가 약속한 부서 간 협업에서 영감을 받아, 기업 안에서 그 협업을 구체적인 형태로 드러낸 자리로 나타났다고 적습니다. 그 협업을 실제로 만드는 일은 플랫폼 엔지니어링이 받습니다.

이견

이 구역을 무엇으로 정의하느냐가 문서마다 갈립니다. 셋을 나란히 놓으면 정의의 주어가 서로 다릅니다.

Google SRE Workbook 은 관행과 지침과 문화의 느슨한 묶음이라고 적습니다. 주어가 묶음입니다. 그 묶음의 요점을 CALMS 로 줄인 사람들로 John Willis 와 Damon Edwards 와 Jez Humble 을 짚습니다.

Microsoft 공식 문서는 데브옵스가 개발(Dev)과 운영(Ops)을 결합해 애플리케이션의 기획과 개발과 전달과 운영에서 사람과 프로세스와 기술을 하나로 묶는 것이라고 적습니다. 주어가 결합입니다. 예전에 사일로로 갈려 있던 역할들, 곧 개발과 IT 운영과 품질 엔지니어링과 보안 사이의 조율과 협업을 가능하게 한다고 이어 적습니다.

AWS(Amazon Web Services, 아마존 웹 서비스) 공식 문서는 데브옵스를 문화 철학과 관행과 도구의 조합이라고 적습니다. 주어가 조합입니다. 그 조합이 조직의 전달 역량을 높여 준다고 적습니다. 전통적인 소프트웨어 개발과 인프라 관리 프로세스를 쓰는 조직보다 더 빠른 속도로 제품을 진화시키고 개선한다고 적습니다. 목적을 정의 안에 같이 박아 둔 쪽입니다.

팀을 어떻게 두라는 말인지에 대해서도 AWS 공식 문서가 한 가지 정답을 적지 않습니다. 그 문서는 데브옵스 모델 아래에서 개발 팀과 운영 팀이 더는 사일로로 갈려 있지 않다고 적습니다. 때로는 두 팀이 하나로 합쳐져 엔지니어가 애플리케이션 수명주기 전체에 걸쳐 일한다고 적습니다. 어떤 조직에는 개발 팀과 운영 팀이 아예 따로 없을 수도 있다고 덧붙입니다. 엔지니어가 둘 다 할 수도 있다고 적습니다.

어느 쪽이 맞는지는 여기서 판정하지 않습니다. 한쪽은 무엇을 허무는 묶음이냐로 정의합니다. 다른 쪽은 무엇과 무엇을 잇는 결합이냐로 정의합니다. 또 다른 쪽은 무엇을 조합해 무엇을 얻느냐로 정의합니다.

상세

경계

SRE

플랫폼 엔지니어링

이견

관련 항목

변경이 흐르는 길

바탕을 코드로 다루는 기법

돌아가는 것을 보는 방법

전달 성능을 재는 지표

데브옵스 철학을 이루는 핵심 개념

데브옵스와 자리가 겹치는 이웃 영역

정의나 근거를 대는 기관