릴리스

소프트웨어를 CD나 설치 파일로 팔던 시절에는 내보내는 일이 1년에 한두 번 있는 큰 사건이었습니다. 한 번 찍어 보내면 되돌릴 수 없으니 반년쯤 기능을 모아 두었다가 한꺼번에 내보냈고, 그 날짜에 맞춰 개발과 검수와 광고가 전부 줄을 섰습니다. 내보내는 행위에 따로 이름을 붙일 이유가 없었습니다. 그날이 곧 제품이 세상에 나오는 날이었으니까요.

웹과 구독형 제품으로 옮겨 오면서 사정이 달라졌습니다. 사용자가 브라우저를 새로 고치면 어제와 다른 화면을 보게 되는 구조에서는 마음만 먹으면 하루에 열 번도 내보낼 수 있습니다. 그런데 자주 내보낼 수 있게 된 바로 그 순간부터, 무엇이 언제 나갔는지를 아무도 붙들지 못하는 문제가 생겼습니다.

페이지덱에서도 같은 장면이 반복됐습니다. 고객센터에 "어제까지 있던 공유 버튼이 어디 갔냐" 는 문의가 들어오는데, 답하는 수아가 그 버튼이 위치를 옮긴 줄 모릅니다. 개발팀에 물어보면 "그거 지난주 화요일에 올라갔는데요" 라는 답이 돌아옵니다. 올린 사람 입장에서는 올렸고, 받는 사람 입장에서는 통보받은 적이 없습니다. 코드를 서버에 올리는 일과 그 변화를 사람들에게 내놓는 일이 같은 행위로 뭉뚱그려져 있어서, 후자를 챙기는 사람이 아무도 없었던 것입니다.

릴리스는 그 뭉뚱그려진 덩어리에서 "사용자 앞에 내놓는 쪽" 을 떼어 내 이름을 붙인 말입니다. 코드가 서버에 올라가는 것은 배포이고, 그 코드가 실제로 사용자에게 닿아 새 기능으로 보이는 사건이 릴리스입니다. 둘을 나누자 그 사이에 결정과 준비를 끼워 넣을 자리가 생겼습니다. 이번에 무엇을 내보낼지 고르고, 누구에게 먼저 열지 정하고, 바뀐 내용을 어디에 알릴지 챙기는 일이 전부 그 자리에 들어갑니다.

이름이 붙자 세는 단위도 생겼습니다. 예전에는 "6월 버전" 처럼 반년 치 변경이 통째로 한 덩어리였지만, 이제는 목요일에 나간 릴리스와 그다음 주에 나간 릴리스를 따로 부를 수 있습니다. 문제가 생겼을 때 어느 릴리스부터 이상했는지 짚을 수 있고, 되돌린다면 어디까지 되돌릴지 정할 수 있습니다. 한 번에 나가는 양이 줄어든 것도 여기서 따라옵니다. 반년 치를 한꺼번에 내보내면 무엇이 문제를 일으켰는지 찾는 데만 며칠이 걸리지만, 이틀 치 변경 스무 개를 내보내면 후보가 스무 개뿐입니다. 작게 자주 내보내는 쪽이 오히려 안전하다는 판단은 이 계산에서 나왔습니다.

제품 축에서 출시 갈래는 만든 것을 사용자 앞에 내놓는 구간 전체를 맡습니다. 한 번 내보내는 행위 자체가 릴리스이고, 전체에 한꺼번에 열지 않고 1퍼센트에서 시작해 이상이 없으면 범위를 넓히는 방식이 점진적 출시입니다. 언제 누구에게 어떤 경로로 알리고 팔지까지 묶은 계획은 고 투 마켓이라 부르고, 반대쪽 끝에는 더 쓰이지 않는 기능의 제공을 끝내는 제품 일몰이 있습니다. 릴리스는 이 갈래의 가운데에서 실제로 문이 열리는 순간을 가리킵니다.

릴리스 아래에는 용어 일곱 개가 있고 두 갈래로 나뉩니다. 갈래를 가르는 기준은 서로 다른 질문입니다. 하나는 "지금 누구까지 쓸 수 있는가" 를 묻는 단계이고, 다른 하나는 "어떤 식으로 내보내는가" 를 묻는 방식입니다.

단계는 문이 열리는 폭에 이름을 붙인 갈래입니다. 다섯 개가 좁은 쪽에서 넓은 쪽으로 늘어섭니다.

1. 알파 — 회사 안 사람이나 극소수만 쓰는 초기 버전입니다. 기능이 반쯤 비어 있고 데이터가 날아가도 괜찮다는 전제로 엽니다. 페이지덱이라면 개발팀과 지현만 쓰는 상태입니다.
2. 클로즈드 베타 — 초대받은 사용자만 들어올 수 있는 시험 공개입니다. 대상을 고를 수 있으니 피드백의 성격을 통제할 수 있고, 문제가 생겨도 영향받는 사람이 몇십 명으로 묶입니다.
3. 얼리 액세스 — 정식 출시 전에 일부 고객에게 먼저 열어 주는 프로그램입니다. 클로즈드 베타와 대상 규모는 비슷하지만 성격이 다릅니다. 시험 삼아 써 보라고 부르는 것이 아니라, 먼저 쓰는 대가로 의견을 달라는 약속을 걸고 돈 내는 고객을 들입니다.
4. 오픈 베타 — 누구나 들어올 수 있지만 아직 완성 전임을 밝혀 둔 공개입니다. 베타라는 딱지가 곧 "여기서 문제가 나도 놀라지 마세요" 라는 사전 양해입니다.
5. 정식 출시 — 모든 고객에게 정식으로 제공하는 상태입니다. 여기부터는 고객 지원과 환불과 장애 대응이 다른 기능과 똑같은 수준으로 붙습니다. 딱지를 떼는 순간 약속이 생기는 것이라서, 팀이 가장 오래 망설이는 칸이기도 합니다.

다섯 칸을 다 밟아야 하는 것은 아닙니다. 작은 기능은 알파와 정식 출시 사이를 건너뛰고 바로 열리고, 결제나 권한처럼 잘못되면 되돌리기 힘든 것은 클로즈드 베타에서 두 달을 머뭅니다. 어느 칸에 얼마나 머무를지를 정하는 기준은 완성도가 아니라 이 기능이 틀렸을 때 생기는 손해의 크기입니다.

단계 딱지는 사용자에게 보내는 신호이기도 합니다. 같은 화면이라도 베타라고 적혀 있으면 사용자는 문제를 만나도 한 번은 넘어가 주고, 정식이라고 적혀 있으면 같은 문제에 환불을 요구합니다. 그래서 딱지를 떼는 결정은 개발이 끝났는지가 아니라 그 약속을 감당할 준비가 됐는지로 내립니다.

방식은 내보내는 방법 자체에 붙은 갈래입니다. 둘이 정반대 상황에서 쓰입니다.

• 소프트 런치 — 홍보를 붙이지 않고 조용히 먼저 여는 출시입니다. 기능은 다 되어 있는데 반응을 미리 보고 싶을 때 씁니다. 공지도 광고도 없이 화면에만 올려 두고, 들어온 사람들이 어떻게 쓰는지를 2주쯤 지켜본 다음 알릴지 말지를 정합니다.
• 핫픽스 — 급한 문제 하나만 고쳐 즉시 내보내는 배포입니다. 정해진 주기를 기다리지 않고 절차를 최소한으로 줄여 나갑니다. 결제가 안 되는 버그처럼 한 시간이 그대로 손해로 쌓이는 상황에서만 씁니다. 절차를 줄이는 것이 핫픽스의 목적이자 위험입니다. 평소에 릴리스를 더디게 만드는 그 단계들이 실수를 걸러 내던 장치라서, 핫픽스에는 문제를 고치는 변경 하나만 태우고 옆에 있던 것은 같이 내보내지 않습니다.

한 번의 릴리스는 대개 아래 순서로 흐릅니다. 어느 단계로 나가든 이 뼈대는 같습니다.

1. 범위 확정 — 이번에 무엇을 내보낼지 목록을 닫습니다. 지현이 맡고, 보통 릴리스 예정일 1주 전입니다. 여기서 닫지 않으면 마지막 날까지 항목이 들어와 검수할 것이 계속 바뀝니다.
2. 코드 동결 — 확정한 것 말고는 더 넣지 않기로 하는 시점입니다. 이 뒤에 들어오는 것은 다음 릴리스로 넘어갑니다.
3. 검수 — 만든 것이 의도대로 도는지 확인합니다. 기능이 제대로 도는지 보는 품질 보증은 태오 쪽이, 화면이 시안과 맞는지 보는 검수는 민서가 맡습니다.
4. 배포 — 코드를 운영 환경에 올립니다. 기술적으로는 여기서 끝이지만 사용자에게 보이는 것은 아직 아닐 수 있습니다. 피처 플래그, 그러니까 코드를 올려 둔 채 기능만 켜고 끄는 스위치를 써 두면 올리는 일과 여는 일을 따로 정할 수 있습니다.
5. 확인 — 연 다음 30분에서 몇 시간 동안 오류와 사용 지표를 지켜봅니다. 이상이 보이면 되돌립니다. 이전 버전으로 되돌리는 조치를 롤백이라고 하는데, 되돌릴 방법을 미리 정해 두지 않은 릴리스는 확인 단계에서 할 수 있는 일이 사실상 없습니다.
6. 알림 — 바뀐 내용을 사람들에게 전합니다. 사용자에게는 릴리스 노트로 나가고, 고객을 직접 만나는 수아와 현우에게는 그보다 먼저 나갑니다.

이 순서를 사람 손으로 매번 밟으면 자주 내보낼수록 사고가 납니다. 그래서 2~4번은 대개 자동으로 돌리는데, 코드 변경을 자동으로 검증하고 배포까지 잇는 체계인 CI/CD가 그 자리를 맡습니다. 자동화가 붙어도 1번과 6번은 남습니다. 무엇을 내보낼지와 누구에게 알릴지는 기계가 정해 주지 않습니다.

"이번 릴리스에 그거 태울 수 있어요? 못 태우면 2주 뒤로 넘어갑니다."

이번 주기의 범위가 곧 닫히니 지금 결정하라는 재촉입니다.

"코드는 어제 올라갔는데 아직 릴리스는 아니에요. 플래그로 꺼 뒀습니다."

배포는 끝났지만 사용자에게는 아직 보이지 않는 상태라는 뜻입니다.

"이건 다음 주기까지 못 기다립니다. 핫픽스로 내보내죠."

정해진 절차를 건너뛰고 오늘 바로 내보내자는 제안입니다.

페이지덱은 격주 목요일에 릴리스를 내보냅니다. 전주 목요일에 지현이 이번 주기에 나갈 항목을 닫고, 그 목록을 그대로 릴리스 노트 초안으로 만들어 수아와 현우에게 먼저 보냅니다. 수아는 그중 자기가 맡은 기업 고객이 물어볼 만한 항목에 표시해 두고, 현우는 바깥에 알릴 만한 것이 있는지 봅니다. 목요일 오전에 태오가 배포하고, 지현이 오후까지 오류 수치를 지켜본 다음 이상이 없으면 릴리스 노트를 공개합니다.

지난 분기에 이 순서가 한 번 깨진 적이 있습니다. 결제 화면 문제를 핫픽스로 급히 내보내면서 알림 단계를 건너뛰었는데, 그날 오후 수아에게 "결제 화면이 왜 바뀌었냐" 는 문의가 세 건 들어왔습니다. 고친 것은 맞고 고치는 것이 옳았지만, 고쳤다는 사실을 아는 사람이 개발팀뿐이었던 것이 문제였습니다. 그 뒤로 페이지덱은 핫픽스에도 한 줄짜리 내부 공지를 붙입니다.

릴리스와 배포를 같은 말로 아는 경우가 가장 많습니다. 실제로 많은 팀에서 두 말을 섞어 쓰니 그렇게 익히기 쉽습니다. 하지만 둘은 주어가 다릅니다. 배포는 코드가 서버에 올라가는 일이고, 릴리스는 그 변화가 사용자 앞에 열리는 일입니다. 피처 플래그를 쓰면 배포는 화요일에 하고 릴리스는 금요일에 하는 것이 얼마든지 가능합니다. 두 말을 섞어 쓰면 "올렸어요" 라는 한마디가 사람마다 다르게 읽힙니다. 개발팀은 배포를 끝냈다는 뜻으로 말했는데 세일즈는 고객에게 알려도 된다는 뜻으로 알아듣고, 아직 열리지 않은 기능을 고객에게 소개하는 일이 벌어집니다.

릴리스를 개발이 다 끝난 뒤에 붙는 마지막 절차로 보는 것도 흔한 오해입니다. 일정표에서 릴리스가 맨 오른쪽 칸에 그려지니 그렇게 보일 만합니다. 그런데 실제로 릴리스에서 가장 많은 시간을 잡아먹는 것은 배포 버튼을 누르는 10분이 아니라 무엇을 내보낼지 정하는 앞쪽입니다. 범위를 닫는 회의, 어느 단계로 열지 고르는 판단, 고객에게 뭐라고 설명할지 쓰는 일이 전부 개발이 끝나기 전에 시작돼야 합니다. 마지막 절차로 여기고 미뤄 두면 목요일 아침에 "이거 지금 내보내도 되는 겁니까" 를 그 자리에서 결정하게 되고, 그렇게 내린 결정은 대개 되돌리는 일로 이어집니다.