요약
11년째 개발 중인 오픈소스 기능 플래그 서버 Unleash가 HN에 소개됐습니다.
Unleash는 기능 플래그(코드를 다시 배포하지 않고 기능을 켜고 끄는 스위치)를 관리하는 플랫폼입니다. 개발자 이바르가 처음 만들었고, GitHub에서 별 1만 4천여 개를 받았습니다.
왜 중요한가
- 사용자 수로 요금을 매기는 상용 서비스 대신 자기 서버에 직접 설치해 쓸 수 있는 선택지입니다.
- 최종 사용자 데이터가 애플리케이션 밖으로 나가지 않게 설계해 데이터 외부 반출이 어려운 조직도 쓸 수 있습니다.
핵심 내용
- 점진적 출시, 카나리 릴리스(일부 사용자에게 먼저 내보내는 방식), 킬 스위치, A/B 테스트를 지원합니다.
- Docker 이미지나 Node.js 앱으로 배포하며, 로컬에서는 docker compose 명령 한 줄로 띄울 수 있습니다.
- Go, Java, Python, .NET 같은 백엔드와 React, iOS, 안드로이드 같은 프런트엔드용 공식 SDK를 제공합니다.
- 오픈소스판은 AGPL-3.0 라이선스이고 환경이 두 개로 제한되며, SSO와 역할 기반 권한은 유료 Enterprise에 있습니다.
- 오래 방치된 플래그를 찾아 주는 기능과, 프런트엔드 요청을 대신 받아 주 서버 부담을 줄이는 Unleash Edge도 있습니다.
HN 반응
- DB 조회 몇 줄로 직접 만들면 된다는 쪽과, 사용자 대상 지정·자동 롤백·운영 부담을 생각하면 전용 시스템이 낫다는 쪽이 맞섰습니다.
- LaunchDarkly의 월간 활성 사용자 기준 요금이 지나치게 비싸다는 불만이 이어졌고, Unleash 개발자는 요청 수 기준인 자사 클라우드 요금을 직접 소개했습니다.
그쪽 웹사이트를 한번 훑어봤습니다 [1]. 첫인상은 이랬습니다. 좀 어이가 없네, 이 정도는 나도 만들 수 있는데. 실제로 이미 만들어서 쓰고 있고요.
3분쯤 둘러본 뒤의 생각은 이렇습니다. 아, 이건 말이 되는구나. 사람들이 왜 돈을 내는지 알겠습니다. 가치 제안이 분명히 있네요.
[1] https://www.getunleash.io/
감사합니다. "이 정도는 나도 만들 수 있는데"에서 "아, 나머지 90%가 이거였구나"로 넘어가는 건 저희가 Unleash를 시작한 과정과도 꽤 비슷합니다. 직접 만드신 버전은 어떤 일을 하나요? 직접 만들 것인가 가져다 쓸 것인가, 그 선을 다들 어디에 긋는지 늘 궁금합니다.
기본적으로는 정적인 규칙에 따라 기능을 켜고 끄는 여러 방법입니다. 대부분은 설정값이고, 가끔 사용자 기준이나 URL 파라미터를 씁니다.
그쪽 플랫폼에는 그런 기능은 물론이고 규모가 큰 플랫폼에 쓸모 있을 만한 기능이 잔뜩 있습니다. 하지만 이미 복잡한 로드맵을 진행하는 중이라면 그걸 직접 개발하기는 골치 아플 겁니다.
설정값이라면 오래 돌아가는 기능 플래그로 구현하기보다 앱의 설정에 두는 편이 낫습니다.
기능 플래그는 원래 임시로 쓰는 것입니다.
글쎄요, 설정값도 임시일 수 있잖아요. 상수일 수도 있고 DB에서 가져올 수도 있고요.
멋진 받아치기네요!
흠, 5분 동안 둘러봤는데도 저는 여전히 뭔지 모르겠어요.
저는 팀을 위해 돈을 내고 씁니다. 솔직히 비싸지만 그만한 값어치는 한다고 생각합니다. 만드는 것까지는 괜찮겠지만 운영하고 지원하는 건 골치 아픕니다.
작은 스타트업이라면 그럴 필요가 없겠지만, 절차가 복잡한 대기업이라면 값어치가 있다고 봅니다.
저희도 직접 호스팅해 보려 했는데, 그 일에 인프라 인력을 배정하는 게 늘 고역이었습니다. 그래서 포기하고 팀들이 쓸 수 있게 돈을 내기 시작했더니 다들 아주 좋아합니다.
인프라 쪽에서 보면 이건 직접 호스팅하는 게 별로 말이 안 된다고 생각합니다. 메트릭도 마찬가지고요.
복잡도가 선형이 아니라서 리소스를 늘리면 한동안은 문제없이 돌아가다가, 어느 순간 Kafka 같은 걸로 메트릭을 큐잉해야 하는 지경이 됩니다. 바꾸기도 끔찍한데, API가 호환되지 않는 경우가 많고 말 그대로 모든 게 그걸 쓰기 때문입니다.
유지보수도 지긋지긋합니다. 모든 게 기능 플래그 시스템을 쓰다 보니 업그레이드하거나 백업 복구를 시험하려고 시스템을 내려도 괜찮은 시간대가 아예 없습니다. 사람들은 "토요일에 2시간 동안 시스템을 내리겠습니다"보다 "업체가 토요일에 2시간 동안 내려갑니다"를 훨씬 너그럽게 받아들입니다.
메트릭용으로 어느 업체에 돈을 내시기에 가격이 받아들일 만하다고 하시는지 모르겠네요.
저희는 시계열이 약 40만 개인데, 어떤 호스팅 업체로 옮기든 그게 곧바로 우리 인프라 비용 중 단일 최대 항목이 됩니다.
그래서 Victoriametrics로 직접 호스팅하고 있는데, 호스팅비는 월 100달러 미만이고 유지보수는 월 한 시간도 안 걸립니다(시간이 지나면서 단일 노드에서 클러스터로도 옮겼고요). 아주 수월합니다.
저희 사내 기능 토글 시스템에서 제가 가장 싫어했던 점은 이렇습니다.
토글과 재로드 가능한 설정 사이의 경계가 늘 모호합니다. 그게 토글인지는 사용자 피드백을 받기 전에는 확실히 알 수 없기 때문입니다. 토글의 0.5% 정도는 사용자 설정이나 운영팀의 비상 안전밸브로 영원히 남습니다. 작아 보이지만 CD를 공격적으로 돌리면 한 달에 한 번, 아니면 몇 주에 한 번은 이런 일이 생기니 사실상 늘 달고 사는 문제입니다.
오래된 토글을 추적하고 닦달하는 시스템이 필요합니다. 토글을 만든 에픽이 끝난 뒤에도 살아남으면 불멸의 존재가 됩니다. 그러다 정적으로 굳어 있어야 했던 토글을 몇 년 뒤에 건드려서 나이트 캐피털 사태 같은 일이 벌어지는 것도 볼 수 있습니다.
두 번째 문제는 제가 featureflip을 설계할 때 해결하려던 부분입니다. 죽은 플래그를 추적해서 저장소에 지워 달라는 풀 리퀘스트를 대신 올려 줍니다. LaunchDarkly를 쓰면서 늘 가장 골치 아팠던 점이거든요.
그래도 이건 이미 해결된 문제여야 할 것 같은데요.
제 전 직장 업무 중 하나가 복잡하게 꼬인 기능 토글 시스템을 정리하는 일이었습니다. 같은 일의 극히 일부만 하는 FOSS 라이브러리 위에 일부를 다시 만들었죠. 그 시스템은 배포 시간과 클러스터 밀도에 실질적인 영향을 줄 만큼 복잡해져 있었습니다.
원래 만든 사람에게 공평을 기하자면, 그를 별로 존중하지는 않았지만, 가장 뒤틀린 부분을 단순하게 만들려고 업스트림에 꽤 큰 PR을 몇 개 올려야 했습니다. 그는 버그나 어설픈 기능 몇 개를 우회하긴 했는데 빙빙 둘러 가는 길을 택했습니다. "추상화라면 뭐든 좋아하는 사람"이라는 말은 틀렸어요. 그가 제일 좋아한 건 추상화 하나를 세 개로 바꾸는 일이었으니까요. 게다가 책으로만 어려운 단어를 배운 부류라서, 65세 미만은 대화에서 한 번도 쓴 적 없는 뜻으로 단어를 썼습니다.
LLM이 이런 서비스의 조종을 울릴 거라고 하지 않았나요? 거의 힘들이지 않고 똑같이 만들어서 코드베이스도 직접 유지할 수 있다면서요?
AI 전도사들이 계속 그렇게 말하던데요.
어제 보니까 LaunchDarkly가 30억 달러짜리 회사라던데요. 말이 돼요?!
월간 활성 사용자가 100만 명이면, 무료 사용자까지 포함해도 LaunchDarkly에서 월 1만 달러쯤 나옵니다. 100만이 큰 숫자처럼 들리지만 "활성"은 익명 사용자의 방문 한 번일 수도 있습니다. 기능 플래그에 연 12만 달러는 터무니없는 항목입니다.
이런 SaaS 기업들이 이만큼 높게 평가받는 건 요청 기준이 아니라 MAU 기준으로 요금을 매기기 때문입니다. 저는 PostHog의 방식이 더 마음에 듭니다. 월 1억 요청에 약 2천 달러입니다 [*].
[] PostHog와는 아무 관련이 없습니다.*
Unleash Cloud 기준으로는 월 1억 요청이 235달러에 사용자 좌석당 75달러입니다(5,300만 요청 포함).
Launch Darkly는 MAU와 서버 사이드 연결 수는 물론이고 로그, 트레이스, 에러 건수까지 여러 항목에 걸쳐 사용량으로 요금을 매깁니다. 말도 안 되는 방식이고, 비용이 얼마나 나올지 실제로 예측할 수 있는 사람(행운을 빕니다)이라면 있는 힘껏 도망칠 겁니다.
기술만 놓고 보면 기능 플래그 시스템이 수십억 달러짜리 회사일 수는 없습니다. SaaS 종말이 정말 온다면 LD 같은 곳이 제일 먼저 당할 거예요.
LaunchDarkly 서비스가 하는 일을 너무 깎아내리는 것 같은데요.
대안으로는 뭘 추천하시나요?
이 분야에는 정액제나 거의 정액제에 가까운 요금을 받는 업체가 여럿 있습니다. 그런 예로 featureflip.io를 추천하겠습니다. ConfigCat도 많이들 쓰는 곳입니다.
저는 featureflip과 관련이 있는 사람인데, 합리적인 가격에 같은 기능을 상당 부분 제공합니다.
Posthog는 정말 끝내줍니다. 무료 티어가 말도 안 되게 후해서, 사용자의 91%가 한 푼도 안 낸다던가 그렇대요.
제가 관여하는 스타트업(MAU 5천 명쯤)에서도 쓰는데, 지금까지 한 푼도 낸 적이 없어서 계속 놀랍니다. 우리한테는 뼈대나 다름없는 도구인데도요.
플래그를 자기 DB에 넣으면 안 되나요?
전직 LD 엔지니어입니다. 저희가 보기에 고객 대부분이 하던 전형적인 실수였고, 규모가 조금 커지면 결국 LD나 경쟁 제품으로 갈아타야 했습니다. DB를 쓰는 것 자체는 괜찮지만 플래그 수에 따라 서버에 큰 부하가 걸릴 수 있습니다. 게다가 사용자나 세그먼트 단위 타기팅 같은 기능도 없습니다. 점진적 롤아웃이나 자동 롤백 같은 것도 없고요(네, 저희는 사내에서 그걸 썼고 덕분에 적어도 몇 번은 살았습니다).
저는 LD를 옹호하는 게 아닙니다. 어떤 것이든 기능 관리 시스템을 옹호하는 겁니다.
제가 바로 그 "전형적인 실수"를 설계했습니다.
이런 건 꽤 쉽게 떠올릴 수 있고, 아니면 다른 구현들이 어떤 어려움에 부딪혔는지 훑어보면 알려 줍니다. 저희 설계의 첫 번째 버전에도 그런 게 전부 있었습니다. 사용자를 타기팅할 수 있었고, 내부 사용자는 항상 구독시킬 수 있었고, 두 기능이 같은 세그먼트와 롤아웃 순서를 쓰게 할 수도 있었습니다.
DB 부하는 한 번도 문제가 된 적이 없습니다. 이미 연결돼서 다른 용도로도 쓰이는 DB 커넥션에서 말 그대로 SELECT 한 번 날리는 거니까요. 문제가 되더라도 나중에 캐싱을 덧붙이는 건 그리 어렵지 않습니다.
쿼리 하나의 단순함이 주는 이해하기 쉬움이, 기능이 몇 개 모자라더라도, 외부 서비스에 완전히 의존하는 복잡함보다 못하다는 말은 저한테는 한 번도 분명하게 와닿지 않았습니다.
결과적으로 저희 FF 시스템은 회사보다 오래 살았고, 회사가 문을 닫을 때 함께 퇴역했습니다.
글쎄요, 저는 일일 활성 사용자가 수백만인 서비스에 기능 플래그 시스템을 직접 만들었는데, 어렵지 않았고, 타기팅, 세그먼트, 점진적 롤아웃을 지원하도록 확장하기도 쉬웠고, 게다가 플래그는 캐시하기도 쉬워서 데이터베이스 부담도 크지 않았습니다. LLM이 나오기 한참 전에 한 일인데, 다른 일을 하면서 새 기능이 필요할 때마다 틈틈이 했고 엔지니어링 시간으로는 한 달쯤 들었습니다. 처음에 버킷팅용 해시를 잘못 골랐지만, 버킷에서 계단식 패턴이 나타나는 걸 금방 알아채고(하루 수백만 요청으로 측정할 수 있다는 장점이죠) 더 나은 해시로 바꿨습니다. 이렇게 하니 훨씬 좋았던 게, 서드파티 서비스에 왕복하지 않고도 백엔드 플래그를 쓸 수 있었습니다(그게 주된 동기였습니다. 요청에 지연을 더하지 않으면서 이런 통제권을 갖고 싶었거든요). 저는 지금도 launch darkly 같은 서비스가 이해가 안 됩니다. 그리고 요즘은 LLM이 있으니 "그냥 직접 만들어라"에 반박하기가 더 어렵습니다.
말씀드렸듯이 저는 LD를 옹호하는 게 아닙니다. 환경 변수나 DB 값 같은 순진한 구현 방식보다 기능 관리 시스템을 옹호하는 겁니다. 직접 만들 것인가 사 쓸 것인가는 별개의 논쟁이고요.
맞아요, 그리고 시중에 나온 기능 관리 시스템은 대부분, 아니 전부 이 문제를 이미 해결했습니다. 예를 들어 LD는 기본적으로 스트리밍 아키텍처로 200ms 안에 애플리케이션에 플래그를 밀어 줍니다. 클라이언트 쪽 애플리케이션(안드로이드/iOS/웹)은 로드할 때 CDN에서 플래그를 한 번만 받아 오니 나머지 부분은 쾌적하게 유지되고요. Unleash도 스트리밍 아키텍처 같은 걸 갖추고 있는 걸로 알고 있습니다.
거의 10년 전 일이라, 제 생각엔 그때는 선택지가 꽤 별로였어요.
DB가 다운되면 어떡하죠?
20년 전 제가 다니던 웹사이트 회사에서는 기능 플래그마다 Memcached 키를 돌렸기 때문에, 대부분은 세션당 한 번쯤만 DB에서 불러오면 됐습니다.
이런 걸 확장하는 건 대체로 해결된 문제입니다. DB가 죽었을 때도 웹사이트가 뜨게 하는 건 그렇지 않고요.