프리뷰 배포

합치기 전에 코드를 살펴보는 절차는 오래전부터 있었지만 그 절차가 보는 것은 코드였습니다. 화면이 실제로 어떻게 보이는지 확인하려면 각자 그 변경을 자기 컴퓨터로 받아 실행해야 했습니다. 개발자가 아닌 사람에게는 그 방법이 아예 없었습니다. 개발 환경을 설치하고 해당 줄기를 받아 실행하는 과정이라 확인 한 번의 비용이 개발자에게도 작지 않았습니다.

페이지덱에서는 그 빈틈이 캡처 이미지로 메워지고 있었습니다. 민서가 화면을 보고 싶다고 하면 태오가 자기 컴퓨터에서 실행해 화면을 찍어 올렸습니다. 빈 목록, 문서가 하나 있는 상태, 스무 개가 있는 상태를 다 보려면 캡처가 세 장이었고, 그중 하나에 문구 수정을 요청하면 다시 세 장이 필요했습니다.

확인용 환경이 하나뿐이라는 문제도 있었습니다. 세 사람이 각자 작업을 그 한 곳에 올려 서로의 화면을 덮은 일이 있었습니다. 프리뷰 배포는 그 환경을 변경 하나마다 하나씩 만들어 주는 방식입니다. 확인할 대상이 늘면 주소도 함께 늘어나므로 순서를 기다릴 필요가 없어집니다.

변경을 올리면 자동으로 임시 환경이 만들어지고 그 주소가 리뷰 요청에 붙습니다. 여섯 단계로 돕니다.

1. 작업을 본류에서 갈라낸 줄기에 올리고 합쳐 달라는 요청인 풀 리퀘스트를 만듭니다. 이 요청이 환경을 만드는 방아쇠가 됩니다.
2. 자동 파이프라인이 그 변경만으로 빌드해 격리된 환경에 올립니다. 다른 사람의 작업은 섞이지 않습니다. 주소가 요청마다 다르게 만들어지므로 어느 변경의 화면인지는 주소로 구분됩니다.
3. 만들어진 주소를 그 요청의 댓글로 남깁니다. 사람이 찾아가지 않아도 눌러 볼 링크가 알림에 실려 오는 것이 이 방식의 실효를 만듭니다.
4. 그 환경이 어떤 데이터를 볼지 정합니다. 운영 데이터를 그대로 연결하지 않고 준비된 예시 데이터를 넣습니다. 이 단계가 절차의 절반이고, 여기서 데이터를 너무 적게 넣으면 확인의 값어치가 떨어집니다. 목록이 비어 있는 상태와 스무 개가 있는 상태를 미리 만들어 두면 상태별 확인이 링크 하나로 끝납니다.
5. 두 종류의 확인이 나뉘어 돌아갑니다. 코드는 코드 리뷰가 보고, 화면은 프리뷰 주소를 눌러 본 사람이 봅니다. 디자이너와 기획자가 개발자를 거치지 않고 확인하는 자리가 이때 생깁니다.
6. 합치거나 닫으면 그 환경을 자동으로 지웁니다. 지우는 규칙을 빼먹으면 몇 주 뒤에 쓰지 않는 환경이 수백 개 남고 비용이 그만큼 나갑니다.

화면이 있는 제품에서 변경이 잦을 때 맞습니다. 특히 확인할 사람이 개발자가 아닐 때, 그리고 변경을 올린 사람과 확인하는 사람이 다른 팀일 때 값이 큽니다. 문구 하나를 고치는 변경에도 주소가 붙으면, 고쳐 달라고 말하는 사람이 직접 보고 판단합니다.

맞지 않는 자리는 셋입니다.

1. 외부 시스템에 실제 영향이 가는 흐름. 결제나 메일 발송을 그대로 연결하면 확인하다가 실제 결제가 일어납니다. 시험용 창구가 따로 있어야 이 자리가 열립니다.
2. 데이터 구조를 바꾸는 변경. 저장 형태를 새로 옮기는 마이그레이션이 포함되면 격리된 환경에서 확인한 결과가 운영에서 그대로 재현되지 않습니다. 되돌리기도 어려운 종류의 변경이라 확인 절차를 따로 설계합니다.
3. 로그인 뒤에만 보이는 화면. 환경마다 계정과 권한을 미리 준비해 두지 않으면 링크를 눌러도 첫 화면에서 막힙니다.

한계도 분명합니다. 환경 수만큼 비용이 붙고, 데이터가 적으면 진짜 문제가 드러나지 않습니다. 목록이 10건일 때 빠른 화면이 1만 건에서 느려지는 일은 예시 데이터를 준비한 만큼만 잡힙니다. 무엇보다 프리뷰에서 잘 보였다는 사실이 운영에서 잘 돌아간다는 뜻은 아닙니다. 실제 전환을 안전하게 하는 일은 블루-그린 배포처럼 운영 쪽 전략이 따로 맡습니다.

"요청에 주소 붙었어요. 세 가지 상태 다 눌러 보실 수 있습니다."

확인을 캡처가 아니라 링크로 넘긴다는 뜻입니다.

"이 변경은 저장 구조를 바꿔서 프리뷰로는 확인이 안 됩니다. 따로 봅시다."

이 방식으로 덮이지 않는 변경이 있다는 지적입니다.

"지난달 환경이 140개 남아 있어요. 닫힌 요청 것은 자동으로 지우게 합시다."

만드는 규칙만 있고 지우는 규칙이 없다는 말입니다.

태오가 파이프라인에 이 단계를 붙인 뒤로 캡처를 주고받는 일이 없어졌습니다. 민서는 요청 알림에 붙은 링크를 눌러 직접 확인했고, 첫 주에 문구와 간격 문제 세 건을 합치기 전에 잡았습니다. 합친 뒤에 같은 것을 고치려면 요청을 다시 만들고 리뷰를 다시 받아야 했으니, 비용 차이가 그 자리에서 드러났습니다.

한 달쯤 지나 빈틈도 드러났습니다. 예시 데이터가 문서 10건뿐이어서 목록이 느려지는 문제를 아무도 못 봤고, 그 화면은 운영에 올라간 뒤에 느리다는 문의로 돌아왔습니다. 태오는 예시 데이터를 1만 건으로 늘렸습니다. 확인 환경의 값어치는 환경이 아니라 그 안에 든 데이터가 정한다는 것이 그때 정리됐습니다.

스테이징 환경을 대체하는 것으로 읽는 경우가 가장 많습니다. 둘 다 운영이 아닌 곳에서 미리 본다는 점이 같아서 그렇습니다. 하지만 이쪽이 보는 것은 변경 하나이고, 스테이징이 보는 것은 합쳐진 전체입니다. 운영과 비슷한 데이터 양과 연동을 갖춘 곳에서 마지막으로 확인하는 자리를 없애면, 각자의 변경은 다 잘 돌아가는데 합친 뒤에 깨지는 상황을 잡을 데가 사라집니다. 둘은 대체 관계가 아니라 순서입니다.

프리뷰가 괜찮으면 배포해도 된다고 읽는 것도 흔합니다. 실제 화면을 봤다는 사실이 확인을 마친 느낌을 주기 때문입니다. 그런데 격리된 환경에서는 드러나지 않는 것이 여럿입니다. 외부 시스템과의 연동, 데이터 양에 따라 달라지는 속도, 여러 사람이 동시에 쓸 때 생기는 충돌이 그렇습니다. 프리뷰는 합치기 전 확인이고 배포 판단은 그 뒤의 다른 절차입니다. 확인했다는 말을 쓸 때 무엇을 확인했는지 함께 적어 두면 이 착각이 줄어듭니다.