릴리스 트레인

팀이 하나일 때 출시 날짜는 문제가 아닙니다. 다 되면 내보내면 됩니다. 팀이 여덟이 되면 이야기가 달라집니다. 여덟 팀이 각자의 속도로 일하는데 결과물은 하나의 제품으로 합쳐 나가야 하니, 누군가 준비되지 않으면 나머지 일곱이 기다립니다.

페이지덱이 팀을 여섯으로 늘린 뒤 이 상태가 됐습니다. 출시를 2월 말로 잡아 두면 한 팀이 2주를 더 달라고 하고, 그러면 전체가 3월 중순으로 밀립니다. 3월 중순이 되면 다른 팀에서 같은 요청이 옵니다. 지현이 세 번째로 날짜를 옮긴 뒤에는 아무도 그 날짜를 계획의 근거로 쓰지 않았습니다. 현우는 광고 일정을 잡지 못했고, 수아는 기업 고객에게 언제 된다고 말할 수 없었습니다.

기다리는 동안 다른 손해도 쌓였습니다. 한 기능을 기다리느라 이미 완성된 다섯 기능이 나가지 못하고 서 있었습니다. 만들어 뒀지만 고객에게 닿지 않은 것은 아무 값도 내지 못합니다. 릴리스 트레인은 이 두 가지를 한 번에 뒤집으려고 나온 방식입니다. 날짜를 기능에 맞추는 대신 기능을 날짜에 맞추고, 못 맞춘 것은 다음 편에 태웁니다.

날짜를 먼저 고정하고 그 뒤로는 날짜를 건드리지 않는 것이 이 방식의 출발점입니다. 다섯 단계입니다.

1. 출발 간격과 날짜를 못 박습니다. 2주나 4주에 한 번으로 정하고 분기 전체의 출발 날짜를 미리 공개합니다. 날짜가 달력에 박혀 있어야 각 팀이 무엇을 어느 편에 태울지 거꾸로 계산할 수 있습니다.
2. 태울 조건을 적어 둡니다. 완료 정의, 곧 작업을 끝났다고 부를 수 있는 공통 기준을 충족했는지가 기준이고, 여기에 통합 시점을 하나 더 붙입니다. 출발 사흘 전까지 합쳐지지 않은 변경은 태우지 않는다는 식입니다. 조건이 글로 없으면 출발 전날마다 협상이 벌어집니다.
3. 준비되지 않은 것은 다음 편으로 넘깁니다. 날짜를 옮기지 않는 것이 규칙의 전부입니다. 이때 쓰는 수단이 피처 플래그입니다. 코드를 켜고 끄는 스위치라서, 미완성 기능의 코드는 기차에 실어 보내고 스위치만 끈 채로 둘 수 있습니다.
4. 팀 사이에 주고받을 것을 미리 붙입니다. 결제 팀이 인증 팀의 결과를 받아야 하는데 그 사실을 출발 1주 전에 알면 이번 편은 이미 놓친 것입니다. 스크럼 오브 스크럼처럼 팀 대표가 모이는 자리에서 무엇을 언제 넘기고 받을지를 날짜로 적어 둡니다.
5. 출발한 뒤에 기록을 봅니다. 정시에 떠났는지, 다음 편으로 밀린 항목이 몇 개인지, 밀린 이유가 무엇인지를 세어 둡니다. 밀리는 항목이 매번 같은 팀에서 나오면 그 팀의 작업 크기나 의존 구조를 손볼 때가 된 것입니다.

팀이 넷에서 열 사이이고 결과물이 하나로 합쳐져 나가는 경우에 가장 잘 맞습니다. 날짜가 밖에 묶여 있을 때도 값이 큽니다. 모바일 앱은 심사에 며칠이 걸리고, 기업 고객에게는 변경 내용을 미리 알려야 하고, 고객 서버에 설치해 쓰는 제품은 담당자 일정을 잡아야 합니다. 이런 제약은 모두 날짜부터 정해야 풀립니다.

반대로 맞지 않는 자리도 분명합니다.

1. 팀이 하나면 필요하지 않습니다. 조율할 상대가 없으니 기차가 아니라 그냥 배포입니다.
2. 이미 각 팀이 하루에 몇 번씩 독립적으로 내보내고 있다면 기차는 속도를 떨어뜨립니다. 서로 붙어 있지 않은 서비스라면 굳이 같은 시각에 모아 태울 이유가 없습니다.

한계는 셋입니다.

1. 간격이 곧 최대 대기 시간입니다. 4주 간격이라면 출발 직후에 완성된 기능은 최대 4주를 기다립니다. 급한 것을 위한 예외 경로를 따로 두지 않으면 이 지연이 그대로 고객에게 갑니다.
2. 거절하는 사람이 필요합니다. 정시 출발은 태울 조건을 지켜야 성립하는데, 출발 전날 태워 달라는 요청을 거절할 권한이 아무에게도 없으면 조건은 첫 달에 무너집니다.
3. 한 번에 나가는 변경 덩어리가 커집니다. 여섯 팀의 3주치 변경이 한꺼번에 나간 뒤 장애가 나면 원인 후보가 수십 개입니다. 이 방식을 쓰는 팀이 기능별 스위치와 단계적 공개를 함께 쓰는 이유입니다.

SAFe처럼 층을 세우는 체계는 이 운영 방식을 규정집에 포함하고 있고, 그렇지 않은 조직도 이것만 떼어 쓰기도 합니다.

"이번 편 출발은 3월 12일이고 코드 프리즈는 9일입니다. 그때까지 안 합쳐지면 다음 편이에요."

날짜와 태울 조건을 함께 알려 협상 여지를 없애는 말입니다.

"그 기능은 이번 기차를 놓쳤습니다. 스위치는 꺼 두고 코드만 실어 보냅니다."

미완성 기능을 합치는 일은 계속하되 고객에게는 보이지 않게 하겠다는 뜻입니다.

"3월 편에 태우려면 인증 쪽 결과를 2월 26일까지 받아야 합니다."

팀 사이 의존을 날짜로 바꿔 못 박는 말입니다.

페이지덱은 4주 간격으로 출발하는 편을 하나 두고 분기 시작에 날짜 셋을 공개합니다. 지현이 태울 조건을 문서로 적고, 출발 전날 태워 달라는 요청을 거절하는 역할도 맡았습니다. 첫 두 달은 거절이 매번 있었고 세 번째 달부터는 거의 없어졌습니다.

태오는 지금 큰 기능을 처음부터 스위치를 달고 만들기 시작합니다. 현우는 출발 날짜가 고정되면서 광고 일정을 한 분기 앞서 잡게 됐습니다.

기차를 출시를 느리게 만드는 장치로 읽는 경우가 가장 많습니다. 준비된 기능이 날짜를 기다리는 모습만 보면 그렇게 보입니다. 하지만 이 방식이 겨냥하는 것은 빈도가 아니라 예측 가능성입니다. 날짜가 밀리지 않으면 밖에 있는 사람들이 그 날짜로 자기 계획을 세울 수 있습니다. 느려지는 것이 문제라면 답은 기차를 없애는 것이 아니라 간격을 4주에서 2주로 줄이는 것입니다. 이 오해를 그대로 두면 팀은 날짜를 다시 옮기는 쪽으로 돌아가고, 처음의 상태로 되돌아갑니다.

정시 출발이 품질을 떨어뜨린다고 읽는 오해도 흔합니다. 날짜에 맞추려면 덜 익은 것을 밀어 넣게 된다고 생각하기 쉽습니다. 실제 규칙은 그 반대입니다. 못 맞춘 것은 태우지 않고 다음 편으로 넘기므로, 날짜를 지키면서 조정되는 것은 범위입니다. 다만 태울 조건을 어기고 억지로 실어 보내기 시작하면 이 오해는 사실이 됩니다. 그때 무너진 것은 기차가 아니라 조건을 지키는 힘입니다.