피처 플래그

한동안 배포와 공개는 같은 말이었습니다. 코드를 서버에 올리는 순간 그 안에 든 기능이 전부 사용자에게 보였으니, 만드는 쪽은 기능이 완전히 끝날 때까지 코드를 올릴 수 없었습니다. 새 편집기처럼 두 달 걸리는 작업이면 두 달치 코드가 별도의 작업 가지에 쌓였고, 그동안 다른 사람들이 같은 파일을 고쳐 두었기 때문에 합치는 날에는 충돌 목록만 수백 줄이 나왔습니다.

반대쪽도 막혀 있었습니다. 금요일 저녁에 배포한 화면에서 오류가 나면 되돌리는 방법이 다시 배포하는 것뿐이었습니다. 페이지덱에서도 태오가 이전 버전으로 되돌리는 절차를 밟는 동안 30분 넘게 사용자들이 깨진 화면을 봤습니다. 문제를 발견한 시각과 실제로 멈춘 시각 사이가 항상 그만큼 벌어져 있었습니다.

피처 플래그는 이 둘을 같은 방식으로 풉니다. 코드가 서버에 있는 것과 사용자가 그 기능을 보는 것을 다른 일로 만들면, 미완성 기능도 매일 올릴 수 있고 문제가 난 기능도 배포 없이 멈출 수 있습니다.

코드 안에 "이 플래그가 켜져 있으면 새 화면, 아니면 옛 화면" 이라는 분기를 하나 심어 두고, 그 켜고 끔을 코드 바깥에서 정하는 방식입니다. 플래그 값은 배포물 안이 아니라 별도의 설정 저장소나 플래그 관리 도구에 들어 있어서, 값을 바꾸면 재배포 없이 몇 초 안에 반영됩니다.

이 구조에서 세 가지가 따라옵니다.

1. 미완성 기능을 꺼 둔 채로 매일 본 줄기에 합칠 수 있습니다. 두 달치 변경을 한 번에 합치는 대신 하루치씩 합치므로 충돌이 그만큼 잘게 쪼개집니다.
2. 문제가 생겼을 때 끄기만 하면 됩니다. 되돌리는 배포에 30분이 걸리던 일이 스위치를 내리는 10초로 줄어듭니다.
3. 누구에게 켤지 고를 수 있습니다. 사내 계정에만, 전체의 1퍼센트에만, 유료 플랜에만 켜는 식으로 대상을 좁힐 수 있어서 카나리 릴리스처럼 소수에게 먼저 열어 보는 배포와 퍼센트 롤아웃처럼 비율을 단계적으로 올리는 배포가 전부 이 위에서 돌아갑니다.

무엇을 하려고 심었는지에 따라 플래그는 세 갈래로 나뉩니다. 릴리스 토글은 아직 안 끝난 기능을 감춰 두는 쪽이라 기능이 다 열리면 걷어냅니다. 실험 토글은 집단을 나눠 어느 쪽 결과가 나은지 비교하려고 쓰므로 실험이 끝나면 함께 사라집니다. 권한 토글은 요금제나 권한에 따라 기능을 여닫는 쪽이라 제품이 살아 있는 동안 계속 남습니다. 앞의 둘은 임시 시설이고 마지막 하나는 상설 시설이라는 차이가 관리 방식을 가릅니다.

플래그 없이도 같은 문제를 푸는 방법이 셋 있고, 각각 포기하는 것이 다릅니다.

1. 작업 가지를 오래 들고 있기. 기능이 끝날 때까지 별도 가지에서 작업하고 다 되면 합칩니다. 도구를 하나도 들이지 않아도 되지만, 합치는 날의 충돌이 그대로 남고 합치기 전까지는 다른 사람의 변경과 같이 돌아가는지 아무도 모릅니다.
2. 환경을 나누기. 사내에서만 접속하는 시험용 서버에 먼저 올려 봅니다. 여기서는 진짜 사용자와 진짜 데이터가 없어서, 계정 수가 많을 때만 드러나는 결함이나 특정 고객의 데이터에서만 나는 오류를 못 잡습니다.
3. 롤백으로 대응하기. 문제가 나면 배포 자체를 이전 버전으로 되돌립니다. 확실하지만 그 배포에 함께 실린 멀쩡한 변경까지 같이 되돌아가고, 이미 새 방식으로 쌓인 데이터를 어떻게 할지가 따라옵니다.

플래그가 치르는 값은 코드에 남는 분기입니다. 플래그가 둘이면 켜고 꺼진 조합이 넷, 열이면 천 가지가 넘어가는데 그걸 전부 시험해 보는 팀은 없습니다. 그래서 실무에서는 심는 날에 치울 날짜를 함께 적어 둡니다.

"그건 플래그 뒤에 넣고 일단 배포하죠. 언제 켤지는 다음 주에 정해도 돼요."

코드를 올리는 일정과 기능을 여는 일정을 따로 잡자는 제안입니다.

"지금 오류율 튀는데 새 편집기 플래그부터 끌게요."

원인을 밝히기 전에 영향을 먼저 멈추겠다는 뜻입니다.

"이 플래그 석 달째 100퍼센트인데 아직 코드에 남아 있네요."

임시로 심은 분기가 치워지지 않았으니 정리하자는 말입니다.

페이지덱이 새 편집기를 내보낼 때가 그대로 이 순서였습니다. 태오가 플래그를 심고 꺼 둔 채로 2주 동안 매일 배포했고, 지현이 사내 계정에만 켜서 먼저 써 봤습니다. 이상이 없자 1퍼센트, 10퍼센트, 25퍼센트로 비율을 올렸고 25퍼센트 구간에서 문서 저장이 간헐적으로 실패하는 문제가 드러나 그 자리에서 껐습니다. 이틀 뒤 고쳐서 다시 올렸습니다.

여기서 플래그가 한 일은 결정을 앞당긴 것이 아니라 결정을 미룰 수 있게 한 것입니다. 코드를 올리는 시점에는 언제 열지 정하지 않아도 되고, 여는 시점에는 이미 코드가 검증된 상태입니다.

플래그를 심어 두면 덜 검증해도 된다고 여기는 경우가 많습니다. 잘못되면 끄면 그만이라는 생각이 자연스럽기 때문입니다. 그런데 끄는 것은 앞으로의 노출만 멈추고, 켜져 있던 동안 벌어진 일은 그대로 남습니다. 새 저장 방식으로 저장된 문서 300건이 옛 화면에서 안 열리는 상태라면 플래그를 내려도 그 300건은 그대로입니다. 끄기가 쉽다는 것은 복구가 쉽다는 뜻이 아니라 노출이 멈춘다는 뜻뿐입니다.

치우지 않아도 되는 시설로 여기는 것도 흔합니다. 이미 100퍼센트로 열린 플래그는 아무 해도 끼치지 않는 것처럼 보입니다. 하지만 남아 있는 분기는 다음 사람이 이 코드를 읽을 때마다 "이건 아직 꺼질 수 있나" 를 따져야 하는 갈림길이고, 옛 경로가 함께 남아 있으면 그쪽도 계속 고쳐야 합니다. 플래그가 수십 개 쌓인 코드에서는 새 기능 하나를 넣을 때 어떤 조합에서 어떻게 보일지 아무도 답하지 못하게 되고, 결국 플래그를 심어 얻으려던 속도를 플래그가 도로 가져갑니다.