Lekko

조정 가능한 값은 모두 그 값을 읽는 코드 바로 옆, 저장소 안에 있었다. 덕분에 설정을 풀 리퀘스트에서 검토할 수 있었고 잘못된 변경은 다른 커밋처럼 되돌릴 수 있었다. 업체 관리 화면을 클릭하는 방식은 코드 쪽에 흔적을 남기지 않는다.

SDK는 컴파일된 번들을 받아 규칙을 로컬에서 평가했다. 플래그 확인 한 번에 마이크로초가 걸릴 뿐 네트워크 왕복은 없었다. 제어 평면에 닿지 못하는 동안에도 서비스는 계속 돌았고, 호스팅 플래그에서 흔한 장애 경로가 사라졌다. 대신 평가 로직을 클라이언트가 떠안고, 규칙이 늘수록 번들도 커진다.

Lekko의 도구는 기존 코드베이스를 읽어 플래그 참조를 찾고 타입이 있는 대체안을 제안했다. 어떤 코드 경로도 더는 읽지 않는 플래그도 표시했다. 출시 후 몇 년씩 남는 잔재이며, 호스팅 업체가 이익을 보기 쉬운 플래그 부채에 대한 가장 분명한 답이었다.

프로덕트 매니저와 지원 리드는 저장소를 건드리지 않고 브라우저에서 승인된 값을 바꿀 수 있었다. 권한이 네임스페이스별 편집 범위를 정했고 모든 변경이 기록으로 남았다. 엔지니어가 안전하게 바꿀 수 있는 범위를 정하고 나머지 인원이 그 안에서 고르는 분업이었다.

값에는 선언된 타입이 있었고 CLI가 배포 전에 규칙을 검증했다. 문자열이 조용히 숫자를 대신해 운영에 들어가는 일은 없었다. 허용 범위와 목록도 정의의 일부였다. JSON 플래그 정의에서 오타로 한 번 당한 팀일수록 이 부분을 관리 화면보다 무겁게 본다.

접근 제어는 네임스페이스 단위였고 읽기, 편집, 관리 역할로 나뉘었다. 변경마다 누가 했는지, 이전 값이 무엇이었는지, 어느 커밋이나 세션이 만들었는지가 남았다. 규제를 받는 팀에서는 이 기록이 설정 변경을 당일에 내보낼지 일주일 승인을 기다릴지를 가르는 경우가 많았다.