지속적 전달

배포가 분기에 한 번 있는 행사이던 시절이 있었습니다. 석 달 동안 쌓인 변경을 금요일 밤에 한꺼번에 내보내고, 팀은 주말 내내 연락을 받을 수 있게 대기했습니다.

문제가 생기면 원인을 찾을 수가 없었습니다. 한 번에 나간 변경이 300건이면 그중 무엇이 화면을 깨뜨렸는지 가려내는 데만 하루가 걸렸습니다. 이전 버전으로 되돌리자니 멀쩡한 299건까지 같이 사라졌고, 그래서 대개는 되돌리는 대신 급히 고쳤습니다. 급히 고친 코드는 다음 배포에서 또 다른 문제를 만들었습니다.

여기서 고리가 하나 생깁니다. 배포가 드물수록 한 번에 나가는 양이 많아지고, 양이 많을수록 위험해지고, 위험하니까 더 드물게 하자는 결정이 나옵니다. 지속적 전달은 이 고리를 반대로 돌리려고 만든 방식입니다. 내보내는 일을 준비가 필요한 행사에서 언제든 할 수 있는 평상시 상태로 바꾸면, 한 번에 나가는 양이 줄고 양이 줄면 위험도 줄어듭니다.

절차는 다섯 단계로 굳혀 둡니다. 코드가 합쳐진 순간부터 내보낼 수 있는 상태가 되기까지를 전부 기계에 맡기고, 사람이 손대는 자리를 마지막 한 번으로 줄이는 것이 이 다섯 단계가 하는 일입니다.

1. 자주 합칩니다. 각자 고친 코드를 하루에 한 번 이상 공용 가지에 합치는 지속적 통합이 전제입니다. 브랜치를 2주씩 따로 두면 합치는 날 충돌이 쌓여 그날부터 며칠간은 내보낼 수 있는 상태가 아닙니다. 이 전제를 규칙으로 못 박은 것이 트렁크 기반 개발입니다.
2. 합칠 때마다 기계가 검사합니다. 빌드와 테스트를 순서대로 엮어 둔 파이프라인이 돌고, 한 단계가 실패하면 뒷단계로 넘어가지 않고 그 자리에서 멈춥니다. 검사가 깨진 코드는 여기서 걸러집니다.
3. 결과물을 한 번만 만듭니다. 빌드가 뱉어 낸 아티팩트 하나를 검사에도 쓰고 운영에도 그대로 씁니다. 환경마다 새로 만들면 검사를 통과한 물건과 다른 물건이 올라갈 수 있습니다.
4. 운영과 닮은 환경에 먼저 올려 봅니다. 스테이징에서 핵심 기능이 살아 있는지 빠르게 확인하고, 여기서 걸린 문제는 고객이 겪지 않습니다.
5. 내보낼 수 있는 상태로 세워 둡니다. 여기까지가 기계의 몫이고, 버튼을 누르는 시점만 사람이 정합니다.

이 절차를 유지하려면 조건이 하나 더 필요합니다. 아직 완성되지 않은 기능이 공용 가지에 들어와 있어도 내보낼 수 있어야 합니다. 그래서 만들다 만 기능은 피처 플래그로 꺼 둔 채 배포합니다. 코드는 나가 있지만 사용자에게는 보이지 않는 상태입니다. 이 장치가 없으면 기능 하나가 끝날 때까지 몇 주씩 배포가 막히고 절차 전체가 멈춥니다. 플래그를 켜고 끄는 일이 배포와 분리되면서 내보내는 시점과 사용자에게 보이는 시점도 따로 정할 수 있게 됩니다.

내보내는 시점을 사람이 정해야 할 이유가 있는 팀에 맞습니다. 준비는 상시로 해 두되 마지막 판단은 남겨 두는 구조이기 때문입니다.

• 기업 고객에게 변경을 미리 알려야 하는 경우. 계약에 사전 공지 기간이 적혀 있으면 자동으로 내보낼 수가 없습니다.
• 출시 시점을 마케팅이나 영업 일정에 맞춰야 하는 경우. 기능은 2주 전에 준비돼 있어도 발표일에 켭니다.
• 승인 기록이 필요한 영역. 누가 언제 무엇을 내보냈는지 남겨야 하는 규제가 걸린 도메인이 여기 해당합니다.

한계도 분명합니다.

1. 자동 검사를 믿을 수 있어야 성립합니다. 테스트가 부실하면 언제든 내보낼 수 있다는 말이 사실이 아니게 되고, 팀은 결국 배포 전에 손으로 확인하는 시간을 다시 만듭니다.
2. 버튼을 누르지 않으면 이득이 거의 남지 않습니다. 준비는 매일 끝나 있는데 실제 배포가 분기에 한 번이면 한 번에 나가는 양은 예전과 같습니다. 도입했다고 말하기 전에 실제 배포 빈도를 먼저 봅니다.
3. 되돌리기 어려운 변경은 여전히 손이 갑니다. 데이터베이스 구조를 바꾸는 작업은 롤백으로 간단히 되돌아가지 않아서, 옛 구조와 새 구조가 한동안 함께 돌아가도록 나눠서 내보냅니다.

"이건 지속적 전달까지만 해 두고, 운영 반영은 공지 나간 다음에 누를게요."

준비는 지금 끝내 두되 실제 배포 시점은 고객 공지 일정에 맞추겠다는 뜻입니다.

"지금 메인에 있는 게 언제든 나갈 수 있는 상태인가요?"

절차가 실제로 지켜지고 있는지 확인하는 질문입니다.

"기능은 다 됐는데 플래그로 꺼 두고 먼저 내보냈어요."

코드는 이미 운영에 올라가 있고 켜는 일만 남았다는 보고입니다.

페이지덱에서는 기업 고객이 늘면서 이 방식으로 자리를 잡았습니다. 전에는 변경이 준비되는 대로 나갔는데, 계약서에 화면이 바뀌면 영업일 기준 5일 전에 알려야 한다는 조항이 들어가면서 그렇게 할 수 없게 됐습니다.

태오가 파이프라인을 스테이징까지 자동으로 가고 운영은 버튼을 누르는 구조로 바꿨습니다. 수아는 공지 일정을 관리하고 누를 날짜를 정합니다. 지현은 아직 켜지 않은 기능이 플래그 뒤에 얼마나 쌓여 있는지를 주기마다 확인합니다. 쌓인 것이 많으면 준비는 되어 있어도 사용자에게 도달한 것은 없다는 뜻이기 때문입니다.

언제든 내보낼 수 있다는 말을 자주 내보낸다는 뜻으로 읽는 경우가 많습니다. 두 문장이 비슷하게 들리고, 도입한 팀이 대개 배포를 자주 하게 되니 더 그렇습니다. 그런데 이 방식이 보장하는 것은 상태이지 횟수가 아닙니다. 매일 준비가 끝나 있어도 버튼을 분기에 한 번만 누르면 한 번에 나가는 변경량은 예전 그대로이고, 문제가 났을 때 범인을 찾기 어려운 사정도 그대로입니다. 이 오해를 그대로 두면 도구만 갖춘 채 얻는 것이 없는 상태가 오래 이어집니다.

도구를 깔면 도입이 끝났다고 여기는 것도 같은 문제입니다. 파이프라인을 세우고 스테이징 자동 배포를 붙이면 겉모습은 갖춰집니다. 하지만 브랜치가 2주씩 살아 있고 그 기간 동안 공용 가지가 내보낼 수 없는 상태라면 절차는 굴러가지 않습니다. 실제로 성립하는지는 아무 시점에나 지금 나갈 수 있느냐고 물어 확인합니다.