피처 플래그 릴리스 노트: 무엇을, 언제 말하는가
4분 분량
기능 요청에서 루프를 닫는다는 것은 그것이 출시된 깔끔한 순간이 있다고 가정한다. 피처 플래그는 그 순간을 없애버리고, 바로 그 점이 피처 플래그 릴리스 노트의 타이밍을 어렵게 만든다. 코드는 머지되고, 플래그는 존재하며, 그 이후 며칠에서 몇 주 동안 그 기능은 프로덕션에서 동시에 살아 있으면서 그것을 쓰고 싶어 할 거의 모든 사람에게, 종종 애초에 요청했던 바로 그 사람에게조차 보이지 않는다. 너무 일찍 알리면 아직 존재하지 않는 기능과 마주치게 된다. 너무 늦게 알리면 신뢰를 쌓아야 했을 루프가 대신 잊힌 것처럼 읽힌다.
왜 플래그는 “출시하고, 알린다”라는 평소의 순서를 깨뜨리는가
하나의 사건을 최소 두 개로 나누기 때문이다. 코드가 라이브가 되는 것과, 특정 계정에 대해 플래그가 켜지는 것이다. 피드백 루프를 닫는 모든 프로세스는 이 둘이 함께 일어난다고 가정하는데, 이는 대부분의 릴리스에는 맞지만 단계적 출시, 타겟팅, 또는 긴급 차단 스위치로 쓰이는 플래그 뒤에 있는 모든 것에는 틀렸다. 고객 피드백 루프 닫기는 체인지로그 항목이 승인되고 게시되는 바로 그 순간에 요청자에게 알리는 것을 설명한다. 그 단계는 항목 게시와 기능 사용 가능이 같은 순간인 경우를 위해 쓰여 있으며, 플래그는 정확히 그 둘이 같지 않은 경우다.
| 순간 | 사실인 것 | 요청자에게 이미 알려야 하는가 |
|---|---|---|
| 코드 머지됨, 플래그는 어디서든 꺼짐 | 기능은 존재하지만 아무도 쓸 수 없다 | 아니다 |
| 요청자의 계정에 플래그가 켜짐 | 기능이 존재하고 그 특정 사람이 쓸 수 있다 | 그렇다 |
| 그 사람을 제외하는 출시 비율에 플래그가 켜짐 | 기능이 존재하지만 그 사람은 여전히 쓸 수 없다 | 아니다 |
| 플래그가 완전히 제거되고 기능이 그냥 켜져 있음 | 기능이 모두에게 존재한다 | 아직 알리지 않았다면 그렇다 |
누군가에게 언제 알려야 하는지에 대한 진짜 규칙은 무엇인가
플래그가 그들의 계정에 켜졌을 때 알려라, 코드가 머지되었을 때도 플래그가 만들어졌을 때도 아니다. 이 하나의 규칙이 위 표의 모든 줄을 다루는데, 요청자에게 정말로 중요한 유일한 사실, 즉 지금 당장 가서 그것을 쓸 수 있는가에 알림을 묶어두기 때문이다. 머지나 플래그 생성에 묶인 알림은 사실상 엔지니어링 진행 보고서이며, 기능을 요청한 사람은 진행 보고서를 원하는 게 아니라 언제 확인하러 가면 되는지 알고 싶어 한다.
그것은 요청자가 조기 접근이나 특별한 접근이 필요하다는 뜻인가
꼭 그런 것은 아니며, 그것을 강제하는 것은 그 자체로 문제를 만든다. 부하나 안정성 때문에 플래그가 점진적으로 출시되고 있다면, 단지 루프를 더 빨리 닫기 위해 한 계정을 대기열 맨 앞으로 옮기는 것은 애초에 출시가 단계적인 이유를 훼손한다. 정직한 선택지는 이렇다. 요청자의 계정이 자연스럽게 출시에 도달할 때까지 기다렸다가 그때 알리거나, 긴급성이 그것을 정당화한다면 알림을 보내고 싶은 마음의 부작용이 아니라 출시를 소유한 누군가의 진짜 결정으로서 의도적으로 그들에게 플래그를 먼저 켜주는 것이다.
플래그가 출시 메커니즘이 아니라 긴급 차단 스위치라면 어떤가
그러면 안전한 가정이 뒤집힌다. 릴리스를 단계화하기 위해서가 아니라 기능을 빠르게 끌 수 있도록 만들어진 플래그는 보통 그 기능이 생성되는 순간 완전히 라이브가 되도록 의도되었다는 뜻이며, 플래그는 순서를 위해서가 아니라 안전을 위해 존재한다. 그 경우 배포 시점에 요청자에게 알리는 것이 옳으며, 플래그 없는 다른 어떤 릴리스와도 같다. 플래그의 존재는 루프가 언제 닫히는지를 바꾸어서는 안 되는 운영상의 세부 사항이다. 중요한 구분은 플래그가 무엇을 위한 것인가이지, 하나가 존재하는가가 아니다.
플래그는 피처 플래그 릴리스 노트가 말해야 할 내용을 바꾸는가
그것은 항목이 언제 게시되는지를 바꾸지, 무엇을 담는지를 바꾸지 않는다. 플래그가 계정의 100%에 대해 켜진 바로 그 순간에 게시된 항목은 정확히 평범한 체인지로그 항목처럼 읽히며, 그래야 맞다. 나중에 그것을 찾는 독자는 플래그가 한때 관여했다는 사실을 알 이유가 전혀 없다. 하지 말아야 할 것은 플래그가 작은 출시 비율에만 켜져 있는 동안 게시하는 것인데, 공개 체인지로그 항목은 플래그 없는 계정을 포함해 그것을 읽는 모두를 찾을 수 없는 기능을 찾아 헤매게 만들기 때문이다. 이것은 같은 문제의 더 나쁜 버전이며, 한 요청자 규모가 아니라 제품 전체 규모로 일어난다. 이 타이밍 규칙이야말로 피처 플래그 릴리스 노트와 평범한 항목 사이의 유일한 차이다. 내용은 같고, 게시일만 움직인다. 릴리스 노트 작성법은 여기에도 적용되는 “조치 필요 없음” 원칙을 다룬다. 독자는 이것이 자신에게 해당하는지 알아야지, 그것이 어딘가에 존재한다는 것만으로는 부족하다.
제품 업데이트 이메일은 플래그가 걸린 기능을 다르게 다뤄야 하는가
그렇다, 주로 다시 쓰는 대신 미루는 방식으로. 제품 업데이트 이메일 템플릿은 표적화된 알림과 넓은 다이제스트를 다룬다. 플래그가 걸린 기능은 표적화된 알림의 타이밍을 보내기 전에 수신자 자신의 플래그 상태와 맞춰봐야 하는 경우이며, 넓은 다이제스트는 그것을 전혀 쉽게 할 수 없다. 이것은 아직 출시 중간에 있는 모든 것에 다이제스트가 잘못된 채널인 또 다른 이유이기도 하다.
FAQ
플래그는 존재하지만 아직 그 사람에게 켜지지 않았을 때 요청자에게 기능이 “곧 나온다”고 말해야 하는가? 진짜로 가까운 날짜가 붙어 있을 때만, 그리고 그때도 아껴서 해야 한다. 날짜 없는 “곧”은 충분한 시간이 지나면 침묵과 똑같이 읽히며, 마찬가지로 추적하고 지켜야 할 두 번째 약속을 만든다.
플래그가 루프를 닫을 만큼 충분히 진행되었는지는 누가 결정하는가? 알림을 소유한 사람이 아니라 출시를 소유한 누구든지다. 출시를 가진 사람은 “계정의 100%“가 임박했는지 아니면 아직 몇 주 남았는지 안다. 루프를 닫는 단계를 고정된 달력 날짜가 아니라 그들의 상태에 묶어두는 것이 알림을 정직하게 유지한다.
영구적인 플래그(결코 완전히 제거되지 않는) 뒤의 기능도 언젠가 공개 체인지로그 항목을 받는가? 그렇다, 그 제품에서 “일반 공개”가 의미하는 것에 도달하는 순간이다, 설령 플래그 자체가 운영상의 이유로 영원히 코드에 남아 있더라도. 체인지로그 항목은 독자에게 있어서의 가용성에 관한 것이지, 그 가용성이 어떻게 구현되는지에 관한 세부 사항이 아니다.
플래그가 제거되고 기능이 출시 대신 폐기되면 어떻게 되는가? 그것은 거절이지, 출시 알림이 아니며, 다른 어떤 거절과도 같은 정성을 받을 자격이 있다. 기능 요청을 거절하는 방법은 그 메시지가 무엇을 말해야 하는지를 다룬다. 정직하게 루프를 닫는다는 것은 때때로 그것을 거절로 닫는다는 뜻이다.
피처 플래그 릴리스 노트는 평범한 항목과 별도의 템플릿이 필요한가? 템플릿은 바뀌지 않으며, 게시 전에 게이팅 단계만 하나 추가된다. 코드가 머지되었다는 것만이 아니라 요청한 계정의 플래그 상태를 확인하고, 그 확인이 통과할 때까지 항목을 보류하라. 항목에 관한 나머지, 즉 문구, 길이, FAQ 원칙은 다른 어떤 릴리스 노트와도 같다.
이 글의 기술적 내용은 독립적으로 검토되지 않았습니다. 잘못된 부분이 있으면 알려 주세요. 바로잡겠습니다.