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

한동안 우리 팀의 배포는 한 사람이 담당했다. 다른 팀원이 코드를 올리면 그 사람이 검토하고 배포하는 구조였다. 처음에는 안전하다고 생각했다. 한 지점을 통과하면 실수가 줄어들 것 같았다.

그런데 실제로는 달랐다. 배포 담당자가 자리를 비우거나 다른 작업에 집중할 때, 변경사항이 며칠씩 쌓였다. 급한 수정이 있어도 배포를 기다려야 했다. 그 대기 시간이 팀 전체의 흐름을 끊었다.

그래서 우리는 배포 권한을 모든 엔지니어에게 주기로 결정했다.

전제 조건 — 배포 전 체크리스트

권한을 분산하기 전에 먼저 해야 할 일이 있었다. 배포 과정을 문서화하고, 체크리스트를 만드는 것이다. 어떤 환경에 어떤 순서로 배포하는지, 롤백은 어떻게 하는지, 배포 중 확인해야 할 항목이 무엇인지 명시했다.

문서가 없으면 권한을 줘도 아무도 자신 있게 배포하지 못한다. 첫 번째 할 일은 현재 배포 담당자가 머릿속에 가지고 있는 절차를 텍스트로 꺼내는 것이었다.

스테이징 환경부터 시작

처음부터 프로덕션 배포 권한을 주면 부담이 크다. 우리는 스테이징 환경 배포부터 시작했다. 각 팀원이 자신의 변경사항을 스테이징에 직접 올리고, 동작을 확인하는 과정을 반복했다.

이 과정에서 배포 도구와 절차에 익숙해지고, 작은 실수도 큰 부담 없이 해결하는 경험을 쌓을 수 있었다. 스테이징에서 충분히 연습한 이후 프로덕션 배포 권한을 단계적으로 부여했다.

실수가 생겼을 때의 원칙

권한을 분산하면 실수도 분산된다. 이것은 받아들여야 하는 사실이다. 중요한 것은 실수했을 때 빠르게 롤백할 수 있는 구조와, 실수를 팀 전체의 학습으로 전환하는 문화다.

누가 어떤 실수를 했을 때 그 사람을 탓하는 방향으로 가면, 팀원들은 다시 배포를 꺼리게 된다. 실수가 생기면 “왜 생겼는가”와 “다음에 어떻게 막을 것인가”만 논의했다. 이 원칙을 지키는 것이 실제로 가장 어려운 부분이었다.

바뀐 것

권한을 분산한 이후 변경사항이 배포되기까지 걸리는 시간이 크게 줄었다. 팀원 각자가 자신의 작업을 끝까지 책임지는 느낌도 강해졌다. 코드를 올리고 나서 배포까지 직접 확인하면, 작업에 대한 오너십이 달라진다.

배포는 위험한 행위가 아니라 일상적인 작업이 됐다. 그게 우리가 원했던 변화였다.

— by mings