지속적 배포

예전에는 배포가 행사였습니다. 개발이 끝난 코드가 바로 나가는 것이 아니라 한 달이나 분기 단위로 모였다가, 정해진 날 저녁에 담당자가 서버에 올렸습니다. 올리는 동안 서비스가 멈추는 일도 흔해서 사용자가 적은 새벽 시간을 골랐고, 금요일에는 아예 배포하지 않는 규칙을 둔 팀이 많았습니다. 문제가 터지면 주말 내내 붙잡혀야 하기 때문입니다.

이 방식의 진짜 비용은 밤샘이 아니라 묶음의 크기였습니다. 한 달치 변경 백 개가 한 번에 나가면, 다음 날 결제가 안 된다는 문의가 들어와도 백 개 중 어느 것 때문인지 알 수 없습니다. 원인을 찾는 데 하루가 걸리고, 되돌리려면 멀쩡한 아흔아홉 개까지 같이 내려야 합니다. 그러니 배포 전 검토가 점점 길어지고, 검토가 길어지니 배포를 더 몰아서 하게 되고, 묶음은 다시 커집니다.

페이지덱에서도 같은 일이 있었습니다. 태오가 화요일에 고친 오타 하나를 사용자에게 보여 주려면 다음 배포 창까지 2주를 기다려야 했고, 그 2주 동안 그 변경은 스무 명분의 다른 변경과 섞였습니다. 급하면 별도 승인을 받아 따로 올렸는데, 그렇게 끼워 넣은 배포가 오히려 사고를 냈습니다. 평소에 쓰지 않는 경로라 아무도 익숙하지 않았기 때문입니다.

지속적 배포는 이 순환을 반대로 돌립니다. 배포를 드물고 큰 사건으로 두는 대신 하루에도 몇 번씩 일어나는 일로 만들어, 한 번에 나가는 변경을 하나 단위까지 줄입니다. 변경이 하나면 문제가 생겼을 때 용의자도 하나입니다.

코드가 합쳐지는 순간부터 운영 서버에 반영될 때까지를 사람이 끼어들지 않는 한 줄로 엮습니다. 실무에서 도는 순서는 다섯 단계입니다.

1. 개발자가 자기 변경을 공용 줄기에 합칩니다. 지속적 통합이 이 자리를 맡습니다. 합치기 전에 동료가 코드를 훑어보는 코드 리뷰를 거치는데, 사람이 손대는 마지막 지점이 여기입니다.
2. 파이프라인이 자동으로 깨어나 빌드와 테스트를 돌립니다. 하나라도 실패하면 그 자리에서 멈추고 뒤로 넘어가지 않습니다.
3. 통과한 결과물을 운영과 비슷하게 꾸며 둔 환경에 먼저 올리고, 로그인·결제처럼 무너지면 안 되는 흐름 몇 개만 자동으로 눌러 봅니다.
4. 운영 서버로 내보냅니다. 서비스가 멈추지 않도록 롤링 배포처럼 서버를 조금씩 갈아 끼우는 방식을 씁니다.
5. 배포 직후 몇 분간 오류율과 응답 속도를 지켜보고, 기준을 벗어나면 자동으로 롤백합니다.

여기서 빠지면 안 되는 장치가 피처 플래그입니다. 코드는 나갔지만 기능은 꺼 둘 수 있게 하는 스위치입니다. 이것이 있으면 절반쯤 만든 기능도 꺼 둔 채로 합칠 수 있어서, 기능이 완성될 때까지 변경을 쌓아 두지 않아도 됩니다. 켜는 시점은 개발이 아니라 기획이 정합니다.

웹 서비스처럼 우리가 서버를 직접 쥐고 있고 사용자가 다음 접속에 새 버전을 받는 제품에 맞습니다. 반대로 앱 마켓 심사를 거치는 모바일 앱은 우리 손을 떠난 뒤에 며칠이 더 걸리므로 이 방식이 그대로 서지 않습니다. 고객사에 변경을 미리 알리기로 계약에 적어 둔 경우나 금융·의료처럼 배포마다 기록을 남겨야 하는 분야도 마찬가지입니다. 그런 팀은 마지막 버튼만 사람에게 남기는 지속적 전달에서 멈춥니다.

기술적으로는 세 가지가 먼저 갖춰져야 합니다.

1. 믿을 수 있는 테스트. 사람의 검토가 빠진 자리를 테스트가 대신하므로, 같은 코드에서 성공과 실패를 오가는 플레이키 테스트가 섞여 있으면 팀이 실패를 무시하기 시작하고 그 순간 안전장치가 사라집니다.
2. 무슨 일이 벌어지는지 밖에서 알 수 있는 상태. 오류율이 평소 0.2퍼센트에서 3퍼센트로 뛰었다는 것을 몇 분 안에 알아채지 못하면 자동 배포는 사고를 더 빨리 퍼뜨리는 통로가 됩니다.
3. 몇 분 안에 되돌리는 경로. 앞으로 가는 자동화만 만들고 뒤로 가는 길을 두지 않으면, 첫 사고에서 팀은 파이프라인을 꺼 버립니다.

"이거 머지되면 바로 나가는 거죠? 그럼 플래그 꺼 두고 합칠게요."

합치는 즉시 운영에 반영되니 기능은 스위치로 가려 두겠다는 말입니다.

"저희는 지속적 배포라 릴리스 날짜를 따로 잡지 않습니다."

배포 일정이라는 개념이 없고 준비되는 대로 나간다는 뜻입니다.

"테스트 커버리지가 이 정도로는 지속적 배포까지 못 갑니다."

자동 검증이 사람의 눈을 대신할 만큼 촘촘하지 않다는 판단입니다.

페이지덱이 이 방식으로 넘어간 건 태오가 오타 수정을 2주 기다린 일이 계기였습니다. 먼저 되돌리는 경로부터 만들고, 두 달 동안 스테이징까지만 자동으로 보내면서 파이프라인이 실제로 문제를 잡아내는지 지켜본 뒤 마지막 승인 단계를 뗐습니다. 지금은 규원이 대표 회의에서 배포 계획을 묻지 않습니다. 대신 지현에게 어느 기능의 플래그를 언제 켤 거냐고 묻습니다. 코드가 나가는 일과 사용자가 보게 되는 일이 분리되면서, 경영진이 신경 쓸 지점이 배포에서 공개 시점으로 옮겨 간 것입니다.

검증 없이 나가는 방식이라는 오해가 가장 많습니다. 사람의 승인이 사라진 장면만 보면 그렇게 읽히기 쉽습니다. 실제로는 반대입니다. 사람이 마지막에 한 번 훑어보던 일을 기계가 매번 대신해야 하므로, 이 방식을 쓰는 팀은 그렇지 않은 팀보다 테스트와 감시에 더 많이 투자합니다. 이 오해를 가진 채로 도입하면 자동화만 먼저 켜고 검증은 그대로 둔 상태가 되는데, 그 조합은 사고를 막던 마지막 관문만 걷어 낸 것과 같습니다.

사람 손을 떼니 위험하다는 걱정도 흔합니다. 승인 절차가 위험을 막아 준다고 느끼기 때문입니다. 다만 승인자가 실제로 보는 것은 변경 목록이지 코드 한 줄 한 줄이 아니고, 묶음이 클수록 그 목록은 더 형식적으로 읽힙니다. 나가는 변경이 하나면 문제가 생겨도 되돌릴 대상이 하나로 분명합니다. 이 걱정을 이유로 승인 단계를 유지하면 배포 간격이 다시 벌어지고, 묶음이 커지면서 원래 막으려던 위험이 도로 커집니다.