지난 편에서 데브옵스의 본질과 조직문화가 데브옵스에 미치는 영향을 살펴봤어요. 이번 편에서는 지속적 배포의 핵심 원칙과, 이를 가능하게 하는 두 가지 기술적 기반을 다뤄요.
1. 지속적 배포: 배포 습관이 문화를 바꾸는 방법
조직문화는 합의나 설득만으로 바뀌지 않아요. 일상적으로 업무가 수행되는 방식이 실제로 바뀔 때 비로소 문화가 바뀌죠.
1) 행동이 먼저, 마인드셋은 나중에
많은 사람들이 갖고 있는 생각은 다음과 같을 거에요.
“사람들이 왜 중요한지 이해하면, 행동이 바뀔 거야.”
현실에서는 대개 반대예요. 더 안전하고, 더 빠르고, 더 효과적인 작업 방식을 경험한 후에 비로소 그 다음행동이 바뀌죠.
존 슈크(John Shook)는 이 현상을 이렇게 관찰했어요.
“제가 경험에서 배운 강력한 교훈은, 문화를 바꾸는 방법은 사람들의 생각을 먼저 바꾸는 것이 아니라, 사람들이 행동하는 방식(그들이 하는 일)을 먼저 바꾸는 것이었습니다.”
— 존 슈크
간단한 예시로 볼게요. “실패해도 괜찮아”라고 말하는 것은 거의 효과가 없어요. 하지만 실패가 작고, 눈에 보이며, 쉽게 복구할 수 있는 시스템을 만들면 이야기가 달라지죠. 실수가 더 이상 혼란이나 처벌로 이어지지 않는다는 것을 직접 경험하면, 행동이 자연스럽게 바뀌고 시간이 지나면서 문화도 바뀌어요.
문화는 문서만으로 만들어지는 게 아니에요. 조직 내의 프로세스가 조용히 특정 행동을 보상하고 다른 행동을 억제할 때 움직이는 거예요.
2) 지속적 배포(Continuous Discovery, CD)의 정확한 의미
지속적 배포는 “항상 배포한다”는 뜻으로 오해받곤 해요.
더 정확한 정의는 이래요. 어떤 변경이든 빠르고, 안전하고, 반복 가능한 방식으로 프로덕션에 배포하고 원할 때 사용자에게 노출할 수 있는 역량이에요.
여기서 “변경”에는 새로운 기능, 설정 업데이트, 버그 수정, 실험, 인프라나 보안 변경이 모두 포함돼요.
핵심은 속도 자체가 아니라 신뢰할 수 있는 속도예요. 지속적 배포가 꾸준히 실천되면 미묘한 변화가 나타나죠. 배포가 더 이상 기빨리는 행사처럼 느껴지지 않고, 서비스 장애가 조직 내 정치적 상황을 유발하는 것이 아니라 학습의 순간이 되며, 되돌릴 수 있는 범위가 넓어지면서 계획이 더 유연해져요.
3) 지속적 배포의 5가지 원칙
지속적 배포를 위해서는 어떤 도구를 쓰는지보다, 어떤 행동이 수반되어야 하는가를 이해하는 것이 도움이 돼요.
| 원칙 | 핵심 아이디어 | 행동이 어떻게 바뀌는가 |
|---|---|---|
| 프로세스에 품질 내재화 | 품질을 끝이 아니라 초기에 확인 | 맥락이 생생하고 수정 비용이 낮을 때 문제를 발견 |
| 작은 배치(batch)로 작업 | 각 변경의 크기를 줄임 | 실패를 이해하고, 범위를 제한하고, 복구하기 쉬움 |
| 반복 작업 자동화 | 배포에서 수동 단계를 제거 | 피드백이 빨라지고 배포가 예측 가능해짐 |
| 지속적으로 개선 | 개선이 일상 업무의 일부 | 팀이 큰 개선을 위한 특정 시기를 기다리지 않고 점진적으로 조정 |
| 모두가 시스템에 책임 | 책임을 역할 전체가 공유 | 업무 떠넘기기가 줄고, 장애 시 방어적 태도가 감소 |
원칙 1: 프로세스에 품질 내재화
품질은 가능한 한 초기에 문제를 드러내야 해요. 품질 점검을 앞으로 당기면, 실패가 감정적 사건이 아니라 일상적 신호가 되면서 제품 개발 과정 중 후반에 발생 가능한 혼란으로부터 보호하죠.
원칙 2: 작은 배치로 작업
작은 배치는 한 번에 잘못될 수 있는 범위를 제한해서 리스크를 줄여요. 변경을 이해하고 되돌리기 쉬우면, 빅뱅 출시와 같이 큰 비가역적 배포에 리스크를 감수하는 대신 가정을 지속적으로 안전하게 검증할 수 있어요.
원칙 3: 반복은 자동화, 판단은 사람에게
시스템이 커지면 수동 단계는 보이지 않는 지연과 불안을 만들어요. 자동화는 예측 가능한 마찰을 제거해서, 사람이 실제로 인간의 판단이 필요한 결정에 집중할 수 있게 해줘요.
원칙 4: 가끔이 아니라 지속적으로 개선
지속적 개선은 학습을 별도의 업무가 아니라 일상 업무의 일부로 다뤄요. 작고 꾸준한 조정이, 문제가 조용히 쌓이는 동안 큰 리셋(ex. 리팩토링, 리플래포밍)을 기다리는 것을 방지하죠.
원칙 5: 모두가 시스템에 책임
공유된 책임은 안정성과 속도가 “다른 팀의 문제”가 아니게 만들어요. 팀이 결과에 공동 책임을 지면, 조율이 개선되고 중요한 순간에 방어적 행동이 줄어들어요.
4) 지속적 배포를 가능하게 하는 기술 역량
원칙은 구체적인 기술 역량을 통해 실현돼요. 이 역량들은 그 자체가 목표가 아니라, 빠르고 안전하며 반복 가능한 변경을 가능하게 하기 위해 존재해요.
| 역량 | 존재 이유 |
|---|---|
| 버전 관리 | 모든 변경을 추적하고 되돌릴 수 있게 함 |
| 자동화된 테스트 | 회귀 오류를 초기에 낮은 비용으로 포착 |
| 배포 자동화 | 릴리스에서 두려움과 불일관성을 제거 |
| 지속적 통합 | 통합 문제를 작을 때 발견 |
| 보안의 조기 적용 | 늦은 시점의 고영향 리스크 발견을 방지 |
| 트렁크 기반 개발(Trunk-Based Development) | 고통스러운 병합 충돌을 줄임 |
| 테스트 데이터 관리 | 테스트를 신뢰할 수 있고 의미 있게 유지 |
| 느슨하게 결합된 아키텍처 (Loosly Coupled Architecture) | 전체 시스템 리스크 없이 독립적 변경 가능 |
| 팀 자율성 | 의사결정과 책임의 속도를 높임 |
2. 두 가지 핵심 기반: 포괄적 구성 관리(Comprehensive Configuration Management)와 지속적 통합(Continuous Integration, CI)
아이디어가 신뢰할 수 있게 되려면 구체적 기반 위에 정착해야 해요. 대부분의 데브옵스가 전환이 멈추는 이유는 팀에 의지가 없어서가 아니라, 두 가지 기반이 약하거나 오해받고 있어서예요.
하나는 변경이 정의되고 통제되는 방식이고, 다른 하나는 변경이 통합되고 검증되는 방식이에요. 이것이 각각 포괄적 구성 관리와 지속적 통합이에요.
1) 포괄적 구성 관리: “진실의 원천”이 사는 곳
“구성 관리”라고 하면 보통 인프라나 운영을 떠올려요.
실제로는 훨씬 넓은 질문에 답하는 거예요. “우리 시스템에 대한 진실은 어디에 있는가?”라는 질문이죠.
성과 좋은 팀에서는 답이 단순하고 일관적이에요. 모든 의미 있는 변경은 버전 관리에서 시작한다. 여기에는 애플리케이션 코드, 환경 설정, 빌드·배포 스크립트, 피처 플래그(Feature Flag)와 런타임 설정이 포함돼요. 핵심적인 것이 누군가의 기억, 슬랙 메시지, 수동 체크리스트에만 존재하지 않아요.
“포괄적”이라는 말이 사람의 개입이 전혀 없다는 뜻은 아니에요. 환경(개발, 스테이징, 프로덕션)이 명시적으로 정의되고, 빌드·테스트·배포가 자동화된 경로를 따르며, 변경이 의도에서 실행까지 추적 가능하다는 뜻이에요. 수동 승인은 존재할 수 있지만, 수동 실행이 기본값이어서는 안 돼요.
| 실행 모델 | 실제 운영 방식 | 장기적 효과 |
|---|---|---|
| 수동 실행 | 결과가 개인의 기억, 판단, 상황적 결정에 의존 | 일관성 없는 결과, 문서화되지 않은 단계의 숨은 리스크, 특정 개인 의존 |
| 자동화된 실행 | 동일한 단계가 압박이나 상황에 관계없이 동일하게 실행 | 반복 가능한 결과, 시스템 전체 가시성, 압박 상황에서도 행동할 수 있는 자신감 |
배포에 특정 영웅이 나타나야만 한다면, 시스템이 조직에 잘못된 행동을 심고 있는 거에요.
2) 구성 관리가 제품 성과를 형성하는 이유
제품 관점에서, 빈약한 구성 관리는 미묘한 문제를 일으켜요.
- “스테이징에서는 됐는데 프로덕션에서는 안 돼요”
- “어떤 버전이 라이브인지 확실하지 않아요”
- “이걸 쉽게 롤백할 수 없어요”
위와 같은 문제들이죠. 이런 이슈들은 학습을 늦추고 변경과 배포에 대한 두려움을 키워요.
반면, 강력한 구성 관리는 더 안전한 실험, 더 명확한 책임, 가정이 틀렸을 때의 빠른 복구를 가능하게 해요. 프로덕트팀이 시도할 수 있는 것의 역량을 조용히 높여주는 거죠.
여기서 비개발자의 역할! 비개발자가 직접 구성 시스템을 설계하지는 않지만, 그 시스템이 실무에서 활용되는 방식에 영향을 미쳐요. 구체적으로는 이런 영역에서 기여하죠.
- 환경(개발, 스테이징, 프로덕션) 간 차이가 왜 중요한지 명확히 하기
- 배포 결정 전에 롤아웃 조건을 명시적으로 정하기
- 출시 계획의 일부로 롤백 경로를 논의하기
이 작업이 제품 결정의 가역성을 형성해요. 구성 관리 규율이 강하면, 출시가 일방통행이 아니라 명확한 진입·퇴출 조건이 있는 관리된 결정이 돼요.
3) 지속적 통합(CI): 통합에서 발생하는 문제가 제품 자체의 문제가 되는 이유
대부분의 프로덕트팀에서 여러 사람이 같은 코드베이스에 동시에 작업해요.
서로의 작업을 밟지 않기 위해, 변경은 보통 별도 브랜치(branch)에서 이루어져요. 브랜치는 메인 코드의 임시 복사본으로, 병렬 작업을 가능하게 하고 미완성 변경이 제품에 너무 일찍 영향을 주는 것을 방지하죠.
문제는 브랜치가 너무 오래 분리되어 있을 때 시작돼요. 개발적인 가정과 추측이 분기하고, 의존성이 바뀌고, 맥락이 흐려지죠. 모든 것을 다시 병합할 때 팀은 각각이 독립적으로는 작동했어도 함께 놓으면 잘 맞지 않는다는 것을 발견하곤 해요.
CI는 이것을 방지하려는 거예요. 브랜치가 분리된 채로 머무는 시간을 바꿔요. 작은 변경을 자주 병합하고 테스트해서, 작업이 아직 생생하고 문제를 이해하기 쉬울 때 통합 고통을 줄이는 거죠.
작은 변경을 자주 병합하고, 자동화된 빌드와 테스트를 즉시 실행하며, 문제를 수정 비용이 낮을 때 감지하는 거죠. 핵심은 현실과의 조기 접촉이에요. 몇 주 후에 충돌을 발견하는 대신, 몇 시간이나 며칠 안에 발견하죠. 이것이 복리 효과를 만들어요. 배포 해서야 놀라는 일이 줄고, 개발 진행이 더 예측 가능해지며, 배포 일정에 대한 신뢰가 높아져요..
4) CI가 조직 전체에게 중요한 이유
CI가 없으면 이런 경험을 하곤 해요. 초반에 낙관적이었던 일정 계획이 막판에 밀리고, “거의 다 됐어요”라는 기능이 자동이 안 되며 배포 시기에 대해 예측 불가능해지죠.
CI가 있으면 팀은 진행 상황에 대한 더 명확한 신호, 범위가 위험할 때의 더 빠른 경고, “완료”에 대한 신뢰를 얻어요.
CI가 완료의 정의(Definition of Done)에 명확성을 강제하는 이유가 여기에 있어요. 테스트가 실패하면 작업은 완료가 아니에요. 통합이 깨지면 작업은 완료가 아니에요. 처음에는 엄격하게 느껴질 수 있지만, 이것이 제품 품질과 계획의 신뢰성을 모두 보호해요.
5) CI + 구성 관리가 함께 작동하는 방법
구성 관리는 시스템이 무엇인지를 정의해요. CI는 변경이 그 시스템에 안전하게 들어맞는지를 검증하죠.
둘 다 강하면 변경이 추적 가능하고, 피드백이 빠르며, 복구가 현실적이에요. 둘 중 하나라도 약하면 배포가 느려지고, 리스크가 조용히 쌓이며, 팀이 프로세스와 신중함으로 보상하게 돼요.
이것이 둘이 최적화가 아니라 기반인 이유예요.
다음 편에서는 배포 성과를 측정하는 DORA 메트릭과, 데브옵스 성숙도가 높아지면 제품 실행이 어떻게 달라지는지를 살펴볼게요.