배포 권한을 모든 엔지니어에게 준 날

결제·정산 현장에서 배포 병목은 단순한 불편이 아니다

결제와 정산을 직접 운영하는 팀에게 배포 병목은 속도 문제가 아니라 리스크 관리 문제다. 우리 시스템에는 매일 정해진 시각에 실행되는 정산 배치 잡이 있고, PG사·은행 API와 실시간으로 연결된 결제 흐름이 있다. 이 환경에서 "핫픽스가 하루 이틀 대기"는 금전적 손실이나 정산 오류로 직결된다. UI 버그와는 차원이 다른 얘기다.

실제로 결제 실패율이 치솟는 상황을 떠올려 보자. 원인을 파악하고 수정 커밋을 올렸는데, 배포 담당자가 외근 중이거나 다른 긴급 업무에 묶여 있으면? 그 대기 시간 동안 실패는 계속 누적된다. 우리 팀이 단일 담당자 구조의 위험성을 가장 실감한 건 정확히 이런 순간들이었다. 배포 자율화는 DevOps 트렌드 이야기가 아니라, 결제 인프라를 운영하는 팀에겐 수익과 신뢰에 직접 연결된 운영 판단이다.

단일 담당자 구조의 숨겨진 비용 — 실제 수치로 보면

한 사람이 배포를 전담하면 표면적으로는 통제력이 높아 보인다. 실수를 한 곳에서 걸러낸다는 안도감이 있다. 하지만 실제로 계산해 보면 비용이 훨씬 크다.

우리 팀 기준으로, 배포 전담 구조를 운영했을 때 변경사항이 스테이징에 올라간 뒤 프로덕션에 반영되기까지 평균 1.5일이 걸렸다. 급한 건이 생겨도 최소 2~3시간은 기다렸다. 배포 담당자가 리뷰·배포 처리에 쓰는 시간이 하루 평균 1.5시간을 넘었고, 나머지 팀원들은 "배포 대기 중" 상태로 컨텍스트 스위칭 비용을 치렀다. 특히 정산 자동화 파이프라인처럼 변경이 잦고 빠른 피드백이 필요한 작업에서 이 대기 비용은 복리로 쌓인다. 트레이드오프를 명확히 하면: 단일 담당자 구조는 리뷰 일관성을 높이는 대신 병목·버스 팩터(bus factor 1)·담당자 번아웃이라는 세 가지 리스크를 동시에 안는다. 이 중 하나라도 터지면 팀 전체가 멈춘다. 반면 권한을 분산하면 개인의 실수 가능성은 다소 올라가지만, 시스템 전체의 회복 탄력성과 배포 속도는 극적으로 개선된다.

전제 조건 — 권한을 나누기 전에 만들어야 할 것들

권한을 그냥 나눠주면 혼란만 생긴다. 먼저 해야 할 일은 배포 담당자의 머릿속에 있는 절차를 텍스트로 꺼내는 것이다. 결제 시스템 특성상, 이 문서화는 일반적인 배포 가이드보다 훨씬 정밀해야 한다.

단순히 "어떤 명령어를 쓰는가"가 아니라, 결제 환경에 맞는 판단 기준이 포함된 체크리스트가 필요하다. 우리 팀은 배포 전 항목으로 다음을 고정했다: ① 해당 배포가 정산 배치 실행 시간대와 겹치는지 확인 (겹치면 배포 창 조정), ② 외부 PG 연동 엔드포인트 변경이 포함된 경우 샌드박스 테스트 결과 첨부, ③ DB 마이그레이션이 있을 경우 롤백 SQL 준비 여부 확인, ④ 배포 후 5분 내 결제 성공률 모니터링 대시보드 직접 확인. 이 리스트는 절차 문서가 아니라 "결제 서비스를 운영하는 팀이 무엇을 두려워하는가"를 반영한 것이다. 체크리스트 없이 권한만 주면, 자신 없는 팀원들은 결국 다시 한 명에게 확인을 구하러 간다. 자율화가 아니라 비공식 병목으로 되돌아가는 것이다.

스테이징부터 단계적으로 — HEDVION 팀의 실제 시나리오

처음부터 프로덕션 권한을 전원에게 주지 않았다. 스테이징 배포를 먼저 자율화하고, 각 팀원이 스테이징에서 단독 배포·확인을 최소 5회 이상 완료한 뒤에 프로덕션 권한을 부여했다. 중요한 기준은 횟수가 아니라 "실제로 문제가 생겼을 때 스스로 롤백까지 처리해 봤는가"였다.

구체적으로, 한 팀원이 정산 리포트 집계 로직을 변경한 배포를 스테이징에서 처음 혼자 진행했을 때, 배포 직후 집계 결과가 전부 0으로 찍히는 현상이 발생했다. 이전 구조라면 담당자에게 긴급 연락해야 했을 상황이었다. 하지만 롤백 절차가 이미 문서화돼 있었고, 그 팀원은 15분 만에 스스로 롤백하고 원인 분석을 완료했다. 이 경험이 프로덕션 배포 자신감을 준 실질적 계기가 됐다. 권한 부여 자체보다 "실수를 혼자 해결해 본 경험"이 진짜 자율화의 전제 조건이다.

실수가 났을 때의 원칙 — 결제 시스템에서의 특수성

권한을 분산하면 실수도 분산된다. 이걸 받아들이지 않으면 자율화는 시작도 할 수 없다. 다만 결제·정산 시스템에서는 실수의 종류를 더 섬세하게 구분해야 한다.

우리는 실수를 두 유형으로 나눴다. 첫째는 "빠르게 롤백하면 복구되는 실수" — 서비스 오류, 배치 실패, UI 버그 등. 둘째는 "롤백해도 데이터가 꼬이는 실수" — 정산 금액 오계산, 이중 결제 처리 등. 전자는 빠른 감지와 롤백 자동화로 대응하고, 후자는 배포 전 단계에서 막는 것을 원칙으로 했다. 결제 금액 관련 로직이 포함된 배포는 반드시 두 명 이상의 리뷰를 거치도록 프로세스에 명시했다. 자율화는 "누구나 배포할 수 있다"는 의미지, "아무 검토 없이 배포해도 된다"는 의미가 아니다. 실수 회고에서 가장 중요한 것은 "누가 실수했는가"가 아니라 "체크리스트의 어느 단계에서 이 실수를 막을 수 있었는가"를 논의하는 것이다. 그 논의가 체크리스트를 진화시키고, 체크리스트가 배포 자신감을 키운다.

바뀐 것, 그리고 지금 당장 써먹을 시사점

자율화 이후 우리 팀의 변화를 수치로 정리하면: 프로덕션 배포 주기가 주 2~~3회에서 하루 1~~2회로 단축됐고, 핫픽스 반영까지 걸리는 시간이 평균 4시간에서 40분 이내로 줄었다. 배포 담당자 한 명에게 몰리던 1.5시간/일의 부하가 팀 전체로 분산되면서, 각자의 배포 처리 시간은 15~20분 수준이 됐다. 수치보다 더 중요한 변화는 오너십이다. 코드를 작성하고 배포하고 모니터링까지 직접 처리하면, 코드 품질에 대한 태도 자체가 달라진다. "올려두면 누군가 배포해 주겠지"라는 심리가 사라진다.

지금 당장 할 수 있는 것들을 구체적으로 정리한다:

배포 절차 문서화부터 시작하라. 현재 배포 담당자에게 "배포할 때 머릿속에서 하는 체크"를 텍스트로 꺼내달라고 요청하라. 명령어뿐 아니라 "이 서비스에서는 이것을 봐야 한다"는 판단 기준까지 포함해야 한다.
결제·정산 특화 배포 금지 창을 정의하라. 정산 배치 실행 시간, 월말 마감 기간, 외부 PG 점검 시간대 등 배포를 피해야 하는 시간대를 명시하라. 이 목록 자체가 시스템 운영 지식의 핵심 자산이다.
스테이징 자율화를 먼저 2주간 운영하라. 프로덕션 권한 없이도 자율화의 80%는 스테이징에서 실습할 수 있다. 2주 뒤 팀원들의 배포 자신감과 문서의 빈틈을 함께 점검하라.
실수 회고를 짧게, 자주 하라. 긴 포스트모템보다 "15분 슬랙 스레드 회고"가 실제 행동 변화를 더 잘 만든다. 형식은 단순하게: 무슨 일이 있었나 → 체크리스트 어디서 놓쳤나 → 다음 배포 전 뭘 추가할 건가.
모니터링 링크를 체크리스트 마지막 항목으로 고정하라. 배포 완료 후 확인할 대시보드 URL을 체크리스트 맨 끝에 박아라. 확인을 "해야 하는 것"이 아니라 "배포 완료의 정의"로 만들면 생략되지 않는다.

배포가 위험한 행위가 아니라 일상적인 작업이 되는 순간, 팀은 더 자주, 더 작게 배포하게 된다. 그리고 더 작은 배포는 그 자체로 더 안전하다. 결제·정산 시스템에서 이 원칙은 선택이 아니다.

— by mings