이전 강의: 6강. 운영: 장애를 대하는 방식 이번 강의 키워드: Conway의 법칙, Inverse Conway Maneuver, DevOps Topologies, DevOps 팀 사일로, You Build It You Run It, Team Topologies, 인지 부하, Platform Engineering, 변경 승인 위원회, Westrum 조직 문화
들어가며
한 회사가 DevOps를 도입하기로 결정합니다. 가장 먼저 한 일은 "DevOps팀"을 신설하는 것이었습니다. 이 팀은 CI/CD 도구와 Kubernetes를 도입했습니다. 1년 뒤, 개발팀은 배포가 필요할 때마다 DevOps팀에 요청 티켓을 올리고, DevOps팀은 쌓인 티켓에 허덕이며, 운영팀은 여전히 따로 있습니다. 개발과 운영 사이의 벽을 허물려다가 벽을 하나 더 세운 셈입니다.
1강에서 DevOps는 도구가 아니라 구조적 순환을 뒤집자는 제안으로 출발했다고 했습니다. 2강부터 6강까지 기술 패턴을 살펴봤지만, 그 패턴들은 결국 사람과 팀이 일하는 방식 위에서만 작동합니다. 이번 강의는 그 토대를 다룹니다.
Conway의 법칙: 조직이 아키텍처가 된다
1968년 Melvin Conway는 『Datamation』에 실린 글에서 이런 관찰을 내놓았습니다. 시스템을 설계하는 조직은 그 조직의 소통 구조를 닮은 설계를 만들어낼 수밖에 없다. 이것이 Conway의 법칙입니다.
예를 들어 프론트엔드팀, 백엔드팀, DB팀이 나뉜 조직은 자연스럽게 세 계층이 뚜렷이 분리된 시스템을 만듭니다. 새 기능 하나를 내려면 세 팀이 모두 움직여야 하고, 팀 사이의 조율이 곧 시스템의 병목이 됩니다. 반대로 주문, 결제, 배송처럼 비즈니스 영역별로 팀이 나뉜 조직은 그 경계를 따라 서비스가 나뉘는 경향이 있습니다.
이 법칙이 DevOps에서 중요한 이유는, 개발과 운영이 조직적으로 분리돼 있으면 기술적으로도 "개발이 만든 것을 운영에 넘기는" 구조가 만들어지기 때문입니다. 1강의 혼돈의 벽은 기술 문제이기 전에 조직도의 문제였습니다.
ThoughtWorks 등에서 제안한 역 Conway 전략(Inverse Conway Maneuver)은 이 법칙을 거꾸로 이용합니다. 원하는 아키텍처가 있다면, 먼저 그 아키텍처를 닮은 팀 구조를 만들라는 것입니다. 시스템을 독립적인 서비스로 나누고 싶다면, 각 서비스를 끝까지 책임지는 독립적인 팀을 먼저 만드는 식입니다.
DevOps Topologies: 조직 구조의 안티패턴 카탈로그
그렇다면 개발과 운영은 조직적으로 어떻게 배치해야 할까요? Matthew Skelton이 시작한 DevOps Topologies는 이 질문에 대해 효과적인 구조와 함께 실패하는 구조(anti-types)를 정리한 카탈로그입니다. 대표적인 안티타입 몇 가지를 보겠습니다.
개발과 운영의 사일로(Dev and Ops Silos). 1강에서 본 전통적인 벽입니다. 코드는 벽 너머로 던져지고, 두 팀의 목표는 충돌합니다.
DevOps 팀 사일로(DevOps Team Silo). 도입부의 사례입니다. 개발과 운영 사이에 DevOps팀을 끼워 넣으면, 그 팀이 새로운 사일로가 됩니다. 개발팀은 여전히 운영을 모르고, 운영팀은 여전히 개발을 모르며, 그 사이에 티켓 대기열이 하나 더 생깁니다. Skelton은 DevOps팀이 존재하려면 한시적이고, 다른 팀이 스스로 할 수 있게 돕는 것이 목표여야 한다고 봅니다.
도구 팀으로서의 DevOps(DevOps as Tools Team). DevOps팀이 CI/CD 도구와 인프라 자동화만 담당하고, 개발과 운영의 협업 방식에는 손대지 않는 구조입니다. 도구는 좋아지지만 1강의 순환은 그대로입니다. 3강에서 본 "CI 극장"의 조직 버전입니다.
이름만 바꾼 시스템 관리자(Rebranded SysAdmin). 기존 운영팀의 이름만 DevOps팀으로 바꾸고, 하는 일과 협업 방식은 그대로인 경우입니다. 채용 공고의 직함은 바뀌었지만 달라진 것은 없습니다.
운영이 필요 없다는 착각(Dev Don't Need Ops). 클라우드와 서버리스가 운영을 대신해 준다고 믿고 운영 역량을 무시하는 구조입니다. 인프라 관리 부담은 줄어도 모니터링, 장애 대응, 용량 계획 같은 운영의 본질은 사라지지 않습니다. 6강의 내용이 여전히 누군가의 일이어야 합니다.
이 안티타입들의 공통점은 1강에서 정의한 안티패턴의 조건을 그대로 만족한다는 것입니다. 각각 그럴듯한 출발점이 있습니다. "전담 조직이 있어야 추진력이 생긴다", "전문가에게 맡기자", "클라우드가 알아서 해준다". 하지만 결과적으로 소통 구조는 바뀌지 않거나 오히려 복잡해집니다.
You Build It, You Run It
그렇다면 효과적인 구조의 핵심은 무엇일까요? 가장 간결한 표현은 2006년 Amazon CTO Werner Vogels가 한 인터뷰에서 남긴 말입니다. "만든 사람이 운영한다(You build it, you run it)."
서비스를 만든 팀이 그 서비스의 배포, 모니터링, 장애 대응까지 책임지는 구조입니다. 이렇게 하면 개발자는 자기 코드가 운영에서 어떻게 동작하는지 직접 겪게 됩니다. 새벽에 자기 서비스 때문에 호출을 받아본 개발자는 타임아웃과 구조화 로그를 챙기게 됩니다. 6강의 패턴들이 "운영팀의 요구사항"이 아니라 "내 문제"가 되는 것이죠. 피드백 루프가 한 팀 안으로 닫힙니다.
다만 이 원칙을 문자 그대로 모든 팀에 적용하면 새로운 문제가 생깁니다. 각 제품팀이 Kubernetes, 네트워크, 보안, 관측 스택, CI/CD를 모두 알아야 한다면 어떻게 될까요? 그 부담이 다음 절의 주제입니다.
Team Topologies: 인지 부하라는 제약
2019년 Matthew Skelton과 Manuel Pais는 DevOps Topologies의 경험을 바탕으로 『Team Topologies』를 썼습니다. 이 책의 출발점은 인지 부하(cognitive load)입니다. 한 팀이 동시에 이해하고 책임질 수 있는 양에는 한계가 있습니다. 이 한계를 넘으면 팀은 모든 것을 얕게 알게 되고, 품질과 속도가 함께 떨어집니다.
"You build it, you run it"을 지키면서 인지 부하를 관리하기 위해, 이 책은 팀을 네 가지 유형으로 나눕니다.
스트림 정렬 팀(Stream-aligned Team). 조직의 기본 단위입니다. 하나의 비즈니스 흐름(제품, 서비스, 사용자 여정)을 처음부터 끝까지 책임지고, 만들고 운영합니다. 나머지 세 유형은 모두 이 팀의 부담을 줄이기 위해 존재합니다.
플랫폼 팀(Platform Team). 스트림 정렬 팀이 인프라의 복잡성을 몰라도 빠르게 배포하고 운영할 수 있도록, 내부 서비스 형태의 플랫폼을 제공합니다.
활성화 팀(Enabling Team). 특정 기술 영역의 전문가들이 스트림 정렬 팀에 일정 기간 합류해 새 역량을 전수하고 빠집니다. 목표는 스스로 할 수 있게 만드는 것이며, 영구적으로 일을 대신해 주지 않습니다.
복잡 하위 시스템 팀(Complicated-subsystem Team). 영상 코덱, 수치 해석 엔진처럼 깊은 전문성이 필요한 구성 요소를 전담합니다.
팀 사이의 상호작용도 세 가지로 정의합니다. 새로운 문제를 함께 탐색할 때의 협업(Collaboration), 잘 정의된 인터페이스를 통해 서비스를 주고받는 X-as-a-Service, 한 팀이 다른 팀의 역량 향상을 돕는 촉진(Facilitating)입니다. 중요한 것은 이 상호작용 방식을 의도적으로 선택하고 바꾼다는 점입니다. 협업은 학습에는 좋지만 비용이 크니, 탐색이 끝나면 X-as-a-Service로 전환하는 식입니다.
이 틀로 보면 도입부의 "DevOps 팀 사일로"는 플랫폼 팀이 되지 못하고 티켓 처리 팀에 머문 상태, 또는 활성화 팀이 되지 못하고 영구적인 대행 팀이 된 상태로 진단할 수 있습니다.
Platform Engineering과 그 함정
최근 몇 년간 플랫폼 팀의 역할은 플랫폼 엔지니어링(Platform Engineering)이라는 이름으로 독립된 분야가 됐습니다. 핵심 산출물은 내부 개발자 플랫폼(Internal Developer Platform)입니다. 개발자가 새 서비스를 만들 때, 저장소 생성부터 파이프라인, 배포, 모니터링 설정까지 검증된 기본 경로를 셀프서비스로 이용할 수 있게 하는 것이죠. Spotify는 이런 권장 경로를 골든 패스(Golden Path)라고 불렀고, 자사의 개발자 포털을 2020년 Backstage라는 이름으로 오픈소스화했습니다.
골든 패스는 강제가 아니라 가장 쉬운 길이어야 합니다. 2~4강에서 다룬 IaC, 파이프라인, 불변 아티팩트, 시크릿 관리 같은 패턴을 각 팀이 매번 처음부터 구현하는 대신, 플랫폼이 기본값으로 제공하면 좋은 관행이 자연스럽게 퍼집니다.
하지만 플랫폼 팀에도 전형적인 안티패턴이 있습니다.
티켓 대기열로서의 플랫폼. 셀프서비스가 아니라 "플랫폼 팀에 요청하면 해준다"는 구조입니다. 도입부의 DevOps 팀 사일로와 다를 바 없습니다.
아무도 원하지 않는 플랫폼. 플랫폼 팀이 사용자인 개발자에게 묻지 않고 기술적으로 멋진 플랫폼을 만드는 경우입니다. 개발팀은 쓰기 어려운 플랫폼을 피해 각자 우회로를 만들고, 조직에는 플랫폼과 그림자 인프라가 공존하게 됩니다. 그래서 플랫폼 엔지니어링에서는 플랫폼을 제품처럼 다루라(Platform as a Product)고 강조합니다. 내부 개발자를 고객으로 보고, 사용성을 측정하고, 피드백을 받아 개선해야 한다는 뜻입니다.
강제된 단일 경로. 모든 팀이 반드시 플랫폼만 써야 하고 예외를 허용하지 않으면, 플랫폼이 감당하지 못하는 요구를 가진 팀은 멈춰 섭니다. 골든 패스는 권장 경로이지 유일한 경로가 아닙니다.
변경 승인 위원회: 안전장치의 역설
많은 조직에는 운영 변경을 승인하는 변경 승인 위원회(Change Advisory Board, CAB) 같은 절차가 있습니다. 여러 부서의 관리자가 모여 변경 요청서를 검토하고 승인하는 방식이죠. 직관적으로는 안전해 보입니다.
그런데 『Accelerate』의 DORA 연구는 흥미로운 결과를 보고했습니다. 이런 외부 승인 절차는 리드타임, 배포 빈도, 복구 시간과 부정적인 상관관계를 보였고, 정작 변경 실패율과는 상관관계가 없었습니다. 느려지기만 하고 더 안전해지지는 않았다는 뜻입니다.
이유는 1강의 순환으로 설명됩니다. 승인이 주 1회라면 변경은 한 주 동안 쌓이고, 위원회는 수십 건의 변경을 짧은 시간에 검토해야 합니다. 변경의 맥락을 가장 잘 모르는 사람들이 가장 큰 배치를 검토하는 구조입니다. 연구는 대안으로 동료 리뷰(peer review)와 자동화된 검증을 제시했습니다. 변경을 가장 잘 아는 사람이 작은 단위로 검토하고, 3~4강의 파이프라인이 기계적인 검증을 맡는 것이죠. 규제 때문에 승인 기록이 필요한 조직이라면, 파이프라인이 리뷰와 테스트 결과를 감사 기록으로 남기는 방식으로 요구를 충족할 수 있습니다.
조직 문화를 측정할 수 있을까
6강의 Blameless Postmortem은 결국 문화의 문제였습니다. 문화는 막연해 보이지만, DORA 연구는 사회학자 Ron Westrum의 조직 문화 유형론을 이용해 이를 측정했습니다. Westrum은 조직을 정보가 흐르는 방식에 따라 세 가지로 나눴습니다.
| 유형 | 지향 | 정보의 흐름 | 실패에 대한 반응 |
|---|---|---|---|
| 병리적 (Pathological) | 권력 | 정보를 숨긴다 | 희생양을 찾는다 |
| 관료적 (Bureaucratic) | 규칙 | 정해진 경로로만 흐른다 | 규정대로 처리한다 |
| 생성적 (Generative) | 성과 | 필요한 곳으로 자유롭게 흐른다 | 원인을 탐구한다 |
DORA 연구에서 생성적 문화는 높은 소프트웨어 전달 성과, 그리고 조직 성과와 연결돼 있었습니다. 표의 마지막 열을 보면 6강과의 연결이 분명합니다. Blameless Postmortem은 생성적 문화의 실천이고, 비난 문화는 병리적 문화의 증상입니다.
1강에서 경고했던 지표의 무기화도 여기서 다시 등장합니다. DORA 지표로 팀 순위를 매기고 성과 평가에 반영하는 순간, 정보는 숨겨지기 시작하고 조직은 병리적인 방향으로 움직입니다.
DevOps 전환에서 흔한 안티패턴
마지막으로, 조직이 DevOps로 전환하는 과정에서 자주 보이는 실패를 정리하겠습니다.
도구부터 사기. 문제를 정의하기 전에 도구를 도입합니다. 도구는 기존 프로세스를 자동화할 뿐이라, 나쁜 프로세스는 더 빠르게 나빠집니다.
빅뱅 전환. 전사가 한 번에 새 방식으로 바꾸려 합니다. 5강에서 빅뱅 릴리스를 경계했듯, 조직 변화도 작은 팀에서 시작해 효과를 보여주고 확산하는 편이 안전합니다.
직함으로서의 DevOps 엔지니어. DevOps를 특정 직무로 한정하면, 나머지 사람들은 "그건 DevOps 엔지니어 일"이라고 생각하게 됩니다. DevOps는 역할이기보다 모두가 공유하는 일하는 방식에 가깝습니다. (실무에서 이 직함이 인프라·플랫폼 엔지니어를 가리키는 말로 굳어진 것은 현실이지만, 그 직함이 조직 전체의 책임을 대신한다고 착각하는 것이 문제입니다.)
측정 없는 개선. 무엇이 나아졌는지 모른 채 변화를 계속합니다. 전환을 시작하기 전에 DORA 지표의 현재 값을 기록해 두고, 커밋에서 운영까지의 흐름을 단계별로 그려 어디서 시간이 새는지 찾는 가치 흐름 매핑(Value Stream Mapping)부터 하는 것이 좋습니다. 대부분의 조직에서 가장 긴 시간은 작업이 아니라 대기에서 나옵니다.
정리
Conway의 법칙은 조직의 소통 구조가 시스템 구조가 된다고 말합니다. 그래서 개발과 운영 사이에 DevOps팀을 끼워 넣거나 이름만 바꾸는 것은 벽을 허물지 못하고, 오히려 새 벽을 만듭니다. 효과적인 구조의 핵심은 "만든 사람이 운영한다"는 원칙이며, Team Topologies는 이 원칙을 지키면서 팀의 인지 부하를 관리하기 위해 스트림 정렬 팀을 중심에 두고 플랫폼 팀과 활성화 팀이 그 부담을 덜어주는 구조를 제안합니다. 외부 승인 절차는 안전해 보이지만 속도만 늦추기 쉽고, 생성적 문화와 작은 단위의 동료 리뷰가 실제로 안전을 만듭니다.
1강부터 7강까지 기술과 조직의 패턴을 모두 살펴봤습니다. 마지막 특별편에서는 이 모든 패턴이 가장 적용하기 어려운 환경, 외부 인터넷이 차단된 폐쇄망에서 무엇이 달라지고 어떻게 대응할 수 있는지 다룹니다.