CS for DEV

Theme

15. 프로세스와 배포 — 변경이 로컬에서 운영까지 도달하는 경로 ​

코드는 로컬에서 컴파일되는 순간 완성되지 않는다. 변경 하나가 실제로 가치를 내려면 여러 사람의 작업과 조율되고, 기계가 검증하고, 사용자에게 노출되고, 운영에서 관측되어야 한다. 이 챕터는 개인의 코드 변경을 기록·조율·검증·관측이라는 계약의 연쇄로 재구성하고, Git 객체 모델·개발 방법론·CI/CD·관찰 가능성을 그 경로 위의 각 단계로 다룬다.

학습 목표 ​

  • 코드 변경이 "로컬에서 동작함"에서 "운영에서 안전함"으로 이동하는 과정에 필요한 계약(기록·조율·검증·관측)을 구분한다.
  • Git의 내용 주소 객체 그래프를 근거로 협업 기록의 무결성과 브랜치 전략의 트레이드오프를 판단한다.
  • 개발 방법론을 규칙이 아니라 특정 조율·불확실성 문제에 대한 대응으로 해석하고 적용 조건을 판단한다.
  • CI/CD와 관찰 가능성 스택을 배포 위험을 자동으로 검증·통제·관측하는 하나의 피드백 시스템으로 설계한다.

배경: "로컬에서는 됐는데" 다음에 무슨 일이 일어나는가 ​

챕터 0의 주문 확정 API 장애를 이번에는 변경의 이동 경로로 다시 본다. 13:55에 재고 서비스 SDK가 업데이트되어 기본 재시도 횟수가 0회에서 2회로 바뀌었고, 14:05부터 p99가 400ms에서 9초로 치솟았으며 중복 주문이 0.3% 발생했다. 챕터 0에서는 이 장애를 진단했고, 챕터 14에서는 어떤 증거가 이 배포를 막을 수 있었는지 물었다. 이번 질문은 다르다. 이 변경은 누군가의 로컬에서 시작해 어떤 단계들을 거쳐 운영 환경에 도달했고, 각 단계는 무엇을 보장했나?

그 여정을 펼치면 이렇다.

text
개발자 로컬                  협업 기록              조율            검증           노출          관측
──────────                  ────────              ────            ────           ────          ────
lockfile 한 줄 수정  ──▶  commit (누가·언제·  ──▶  리뷰·머지  ──▶  CI 빌드·  ──▶  배포     ──▶  메트릭·로그·
"로컬 테스트 통과"        무엇을 바꿨나 기록)      (mainline로       테스트         (전체 노출)     트레이스
                                                  통합)                                        (사후 증거)

각 화살표는 변경에 대해 무언가를 보장하지만, 보장하지 못하는 것도 남긴다.

  • commit은 "누가, 언제, 무엇을 바꿨나"를 위·변조가 어려운 형태로 기록한다. 그러나 그 변경이 안전한지는 기록하지 않는다.
  • 리뷰·머지는 다른 사람의 작업과 이 변경을 하나의 mainline으로 합친다. 그러나 diff가 lockfile의 버전 숫자 하나라면, 리뷰어가 SDK 변경 이력 속 기본값 변화까지 추적하길 기대하는 것은 리뷰의 범위를 벗어난다(14.2).
  • CI는 정의된 테스트를 자동으로 돌린다. 그러나 "느린 의존성 주입" 같은 시나리오를 아무도 테스트로 명시하지 않았다면, CI는 그 위험을 관측할 수 없는 위치에 있다.
  • 배포는 변경을 사용자에게 노출한다. 전체에 한 번에 노출했다면 폭발 반경은 100%다. 1% 카나리였다면 같은 결함이 예산의 1.4%로 차단됐을 것이다(14.3).
  • 관측은 노출 이후 실제 동작의 증거를 남긴다. 평균만 보고 p99를 놓쳤다면, 눈이 있어도 잘못된 곳을 보고 있었던 것이다.

이 경로의 어느 단계도 그 자체로 장애를 막지 못했다. 그러나 경로 전체를 어떻게 설계했느냐가 "lockfile 한 줄이 전면 장애가 되는 시스템"과 "같은 변경이 카나리에서 수 분 만에 자동 롤백되는 시스템"을 가른다. 이 챕터의 대상은 개별 코드가 아니라 이 변경 전달 경로(change delivery path) 자체다.

핵심 개념 ​

변경은 기록되어야 조율된다 ​

여러 사람이 같은 코드베이스를 동시에 바꾸는 순간, 첫 번째 문제는 "누구의 버전이 진짜인가"다. 버전 관리 시스템은 이 문제를 모든 변경에 검증 가능한 정체성을 부여해서 푼다. Git은 파일 내용·디렉터리 구조·커밋을 각각 그 내용의 해시로 이름 붙이고, 커밋이 부모를 가리키게 해 변경의 이력 전체를 하나의 그래프로 만든다. 이 구조가 있어야 "이 두 사람의 변경을 어떻게 합치나(머지)", "이 변경을 어떻게 되돌리나(revert)", "장애를 만든 변경이 어느 커밋인가(bisect)" 같은 질문이 명령이 아니라 그래프 연산으로 답해진다. 15.1이 이 모델을 다룬다.

프로세스는 조율 비용에 대한 대응이다 ​

기록이 조율을 가능하게 하지만, 여러 사람과 여러 달에 걸친 작업을 어떤 리듬으로 조율할지는 별개의 문제다. 요구사항이 처음부터 확실한가 아니면 만들면서 알게 되는가, 통합을 얼마나 자주 하는가, 잘못 만들었을 때 되돌리는 비용이 얼마인가에 따라 답이 달라진다. 폭포수·애자일·린 같은 방법론은 유행이 아니라 각각 특정 실패에 대한 대응이다. 이들을 "무엇을 해야 하나"의 규칙으로 받으면 왜 하는지를 잃고, 원리는 사라진 채 의례만 남는다. 15.2가 방법론을 문제의식과 적용 조건으로 해석한다.

자동화와 관측은 검증과 노출을 통제한다 ​

사람이 손으로 빌드·테스트·배포하면 시스템은 사람의 실패율로 배포된다. 배포가 드물고 크고 수동이면, 14.3에서 본 악순환 — 큰 배포가 큰 장애를, 큰 장애가 더 무거운 절차를 부르는 — 에 빠진다. DevOps는 개발(변경을 원함)과 운영(안정을 원함) 사이의 벽을 자동화로 허무는 접근이고, 그 구현이 CI/CD 파이프라인·IaC·관찰 가능성 스택이다. 이 셋은 별개 도구가 아니라 검증을 자동화하고, 노출의 폭발 반경을 통제하고, 노출 이후를 관측하는 하나의 피드백 시스템이다. 15.3이 이 시스템을 설계한다.

챕터의 관점: 계약의 연쇄로서의 전달 경로 ​

세 문서는 대상이 다르지만 하나의 관점을 공유한다. 변경 전달 경로의 각 단계는 이전 단계로부터 무언가를 넘겨받아 새로운 보장을 추가하고 다음 단계로 넘긴다. 그리고 각 단계에는 그 보장이 성립하기 위한 계약이 있다.

text
1. 기록 계약 — 모든 변경은 위·변조 없이 식별·추적·되돌림이 가능한가
        │  (Git 객체 그래프의 무결성)
        ▼
2. 조율 계약 — 통합은 재작업과 충돌이 관리 가능한 배치 크기로 일어나는가
        │  (방법론이 정하는 통합 빈도·피드백 주기)
        ▼
3. 검증 계약 — mainline의 모든 변경은 자동으로, 싼 증거부터 검증되는가
        │  (CI 파이프라인의 게이트)
        ▼
4. 노출 계약 — 배포는 폭발 반경이 통제되고 가역적인가
        │  (배포 전략과 에러 버짓 정책의 집행)
        ▼
5. 관측 계약 — 노출 이후 시스템의 실제 상태를 미지의 질문까지 답할 수 있는가
        │  (메트릭·로그·트레이스)
        └──── 관측 결과가 앞 단계의 게이트·전략을 수정 ────▶ 1로

한 계약이 깨지면 다음 계약은 무의미해진다. 기록이 신뢰할 수 없으면 조율할 진실이 없고, 검증 없이 통합하면 mainline이 깨지고, 폭발 반경을 통제하지 않으면 관측은 이미 벌어진 피해를 보고할 뿐이다. 주문 확정 API 장애는 이 연쇄의 여러 지점 — 명시되지 않은 검증 계약, 통제되지 않은 노출 계약 — 이 동시에 약했던 결과다.

챕터 지도 ​

  1. 버전 관리의 내부는 Git을 명령어 모음이 아니라 내용 주소 객체 그래프로 재구성한다. blob·tree·commit·tag 네 객체와 참조(branch·HEAD·tag)를 plumbing 명령으로 직접 관찰하고, 머지·리베이스·reset을 그래프 위의 연산으로 예측하며, trunk-based·GitHub flow·git-flow 브랜치 전략을 통합 빈도와 배포 모델의 트레이드오프로 판단한다.
  2. 개발 방법론은 폭포수·애자일·린을 각각이 대응한 문제(요구 불확실성, 조율 비용, 피드백 지연)로 해석한다. 배치 크기와 피드백 주기를 프로세스 무게의 핵심 변수로 세우고, 애자일 선언의 원리가 형식화된 의례로 굳으며 원리를 배신하는 지점(cargo cult, 벨로시티 타게팅)을 판별한다.
  3. DevOps는 CI/CD·IaC·관찰 가능성을 하나의 피드백 시스템으로 설계한다. 파이프라인 각 단계가 사는 증거와 순서, 배포 전략별 폭발 반경, IaC의 선언적 모델과 드리프트, 메트릭·로그·트레이스 세 신호의 비용과 질문 범위를 다룬다.

이 챕터는 앞 챕터들이 정의한 목표를 전달하는 경로를 담당한다. 어떤 증거를 살지(테스트 수준)와 어떤 신뢰성 목표를 세울지(SLO·에러 버짓)는 챕터 14가, 무엇을 만들지(요구사항·아키텍처 결정)는 챕터 13이 담당한다. 배포가 여러 노드에 걸쳐 부분 실패하는 분산 원리는 챕터 10을, 커밋 서명·아티팩트 무결성의 암호 프리미티브는 챕터 3을 전제한다.

실무 관점: 경로 전체를 보지 않을 때의 함정 ​

한 단계의 강함으로 경로 전체를 판단할 때. "우리는 코드 리뷰가 철저하다"는 팀이 배포는 수동으로 하고 관측은 없을 수 있다. 전달 경로의 안전성은 가장 약한 계약이 결정한다. 리뷰가 잡지 못하는 위험(의존성 상호작용, 규모 의존 동작)이 검증·노출·관측 단계에서도 걸러지지 않으면, 리뷰의 철저함은 그 위험 앞에서 무력하다.

도구 도입을 경로 개선으로 착각할 때. Jenkins를 설치하고 Terraform을 도입해도, 개발자가 여전히 몇 주치 변경을 한 번에 머지하고 배포를 두려워하면 전달 경로는 개선되지 않았다. 도구는 계약을 집행하는 수단일 뿐이고, 계약(작은 배치로 자주 통합, 폭발 반경 통제)이 실제로 지켜지는지가 결과다. 이 결과는 15.2에서 다룰 DORA 지표(배포 빈도, 변경 리드타임, 변경 실패율, 복구 시간)로 측정된다.

속도와 안정성을 대립으로 볼 때. "빠르게 배포하면 불안정하다"는 통념과 달리, 자주·작게 배포하는 조직이 변경 실패율도 낮고 복구도 빠르다는 것이 대규모 연구(DORA)의 일관된 결과다. 원인은 이 챕터의 관점과 같다. 작은 배치는 폭발 반경이 작고, 자주 지나는 경로는 자동화·관측이 잘 갖춰지며, 가역적 배포는 실패를 값싸게 만든다. 속도와 안정성은 잘 설계된 전달 경로가 함께 사는 두 결과지 트레이드오프가 아니다.

정리 ​

  • 코드는 로컬에서 컴파일될 때가 아니라 기록·조율·검증·노출·관측을 거쳐 운영에서 안전할 때 완성된다. 이 챕터의 대상은 개별 코드가 아니라 변경 전달 경로 자체다.
  • 전달 경로는 계약의 연쇄다. 기록(무결성) → 조율(배치 크기) → 검증(자동 게이트) → 노출(폭발 반경) → 관측(미지의 질문). 한 계약이 깨지면 다음 계약이 무의미해진다.
  • Git은 변경에 검증 가능한 정체성을 부여해 조율을 가능하게 하고, 방법론은 조율의 리듬(통합 빈도·피드백 주기)을 정하며, DevOps 스택은 검증과 노출과 관측을 자동화한다.
  • 경로의 안전성은 가장 약한 계약이 결정한다. 도구 도입이 아니라 계약이 실제로 지켜지는지가 결과이고, 그 결과는 배포 빈도·리드타임·변경 실패율·복구 시간으로 측정된다.
  • 자주·작게·가역적으로 배포하는 잘 설계된 경로에서는 속도와 안정성이 트레이드오프가 아니라 함께 오는 두 결과다.

확인 문제 ​

  1. 어떤 팀이 "우리는 모든 PR에 시니어 두 명의 승인을 요구한다"를 전달 경로의 핵심 안전장치로 삼는다. 이 팀의 배포는 월 1회 수동이고, 배포 후 지표는 사용자 문의로만 확인한다. 이 경로에서 챕터 0의 주문 확정 API 장애 같은 의존성 변경 사고가 발생했을 때, 어느 계약이 약해서 피해가 커지는지 경로의 단계로 짚어라.
  2. 한 조직이 "안정성을 위해 배포를 분기당 1회로 제한"했다. 이 정책이 의도(안정성)와 반대 결과를 낳을 수 있는 메커니즘을, 배치 크기와 폭발 반경 개념으로 설명하라.
  3. "CI 도구와 IaC를 도입했으니 우리는 DevOps를 한다"는 주장의 문제를 지적하고, 전달 경로가 실제로 개선됐는지 확인할 지표 두 가지를 제시하라.
정답과 해설
  1. 약한 계약이 여러 단계에 겹쳐 있다. 검증 계약: 리뷰(사람)는 lockfile 버전 변경 뒤의 SDK 기본값 변화를 잡는 데 부적합하고, 이를 자동으로 잡을 통합 테스트(느린 의존성 주입)가 파이프라인에 없다. 노출 계약: 월 1회 수동 전체 배포는 폭발 반경이 100%이고 가역성이 낮다. 카나리·기능 플래그가 없어 결함이 전면에 즉시 도달한다. 관측 계약: 지표를 사용자 문의로만 확인하므로 p99·중복 주문율 같은 SLI를 배포 직후 관측하지 못해 감지가 늦다. 리뷰라는 한 계약이 강해도, 그 계약이 잡지 못하는 위험이 검증·노출·관측 어디서도 걸러지지 않으므로 피해가 전면 장애로 커진다.
  2. 배포를 분기당 1회로 제한하면 한 배포에 3개월치 변경이 쌓인다(배치 크기 증가). 큰 배치는 세 방향으로 위험을 키운다. 첫째, 변경 간 상호작용이 많아져 결함 확률이 올라간다. 둘째, 장애가 나면 3개월치 변경 중 어느 것이 원인인지 좁히기 어려워 진단·복구가 느리다(폭발 반경이 시간·범위 양쪽으로 커짐). 셋째, 배포가 드물면 배포 절차 자체가 자동화·연습되지 않아 그 자체로 위험한 이벤트가 된다. 결과적으로 "안정을 위한 배포 억제"가 배포당 위험을 키워 더 크고 진단이 어려운 장애를 만든다. 안정성은 배포를 줄이는 게 아니라 배치를 줄이고 폭발 반경을 통제해서 얻는다.
  3. 문제는 도구 보유를 경로 개선과 동일시하는 데 있다. CI 서버가 있어도 개발자가 몇 주치 브랜치를 몰아 머지하면 통합은 여전히 드물고 크며, IaC가 있어도 사람들이 콘솔에서 수동 변경(드리프트)을 하면 선언적 진실은 깨진다. 계약이 지켜지는지는 도구가 아니라 결과로 확인한다. 지표 예: (1) 배포 빈도와 변경 리드타임 — 실제로 자주·빠르게 통합·배포되는가. (2) 변경 실패율과 복구 시간 — 배포가 얼마나 안전하고 가역적인가. 이 지표가 개선되지 않았다면 도구는 있으나 계약은 지켜지지 않는 것이다.

참고 자료 ​

  • Manifesto for Agile Software Development (2001) — 방법론을 규칙이 아니라 가치와 원리로 보는 관점의 1차 자료로, 15.2의 출발점이다.
  • Nicole Forsgren, Jez Humble, Gene Kim, Accelerate (IT Revolution, 2018) — 배포 빈도·리드타임·변경 실패율·복구 시간(DORA 지표)과 전달 경로 성능의 관계를 대규모 연구로 확인한다.
  • Jez Humble, David Farley, Continuous Delivery (Addison-Wesley, 2010) — 변경을 반복 가능·가역적으로 운영 환경까지 전달하는 배포 파이프라인 개념의 기준 문서다.
  • Betsy Beyer 외, Google SRE Book — 전달 경로의 노출·관측 계약(점진적 배포, 관찰 가능성)을 신뢰성 관점에서 확인한다.