Bitwarden에서 비밀번호를 빼라? 라이선스 변경 논란의 진짜 쟁점

오픈소스 비밀번호 관리자에 무슨 일이

비밀번호 관리자, 다들 하나쯤은 쓰고 계시죠. 1Password, LastPass, Dashlane 같은 상용 서비스도 있고, Bitwarden처럼 오픈소스이면서 무료로 쓸 수 있는 서비스도 있어요. 특히 Bitwarden은 "오픈소스니까 신뢰할 수 있다", "코드를 검증할 수 있다", "자체 호스팅(self-hosting, 자기 서버에 직접 설치해서 운영하는 거예요)도 가능하다"는 이유로 개발자들 사이에서 인기가 많았어요. 그런데 최근 OSNews에 "Bitwarden에서 비밀번호를 빨리 빼라"는 자극적인 제목의 글이 올라오면서 커뮤니티가 시끄러워졌어요.

문제의 발단은 Bitwarden이 자사 클라이언트 SDK(Software Development Kit, 개발에 쓰는 도구 모음이에요) 일부를 기존의 GPL 라이선스에서 자기들만의 새로운 "Bitwarden License"로 바꾸려고 한 것에서 시작됐어요. 이게 왜 문제냐면, 새 라이선스는 "Bitwarden 서버와 함께 쓰는 경우에만" 자유롭게 쓸 수 있고, 그 외의 용도(예를 들어 누군가가 Bitwarden과 호환되는 자체 서버를 만든다거나)에는 제한이 생기거든요.

무엇이 바뀌었고, 왜 논란인가

구체적으로 살펴볼게요. Bitwarden은 클라이언트(앱과 브라우저 확장)와 서버를 분리해서 운영하는데, 서버 측에는 이미 두 가지 버전이 있었어요. 공식 서버와, 커뮤니티가 Go 언어로 다시 구현한 "Vaultwarden"이라는 비공식 서버예요. Vaultwarden은 리소스를 훨씬 적게 먹어서 라즈베리파이 같은 작은 기기에서도 잘 돌아가거든요. 자체 호스팅하는 사람들 사이에서 사실상 표준에 가까웠어요.

그런데 Bitwarden이 클라이언트 코드의 핵심 부분을 새 라이선스로 바꾸면, 이 클라이언트가 Vaultwarden 같은 서드파티 서버에 붙어서 동작하는 게 라이선스 위반이 될 수 있다는 우려가 나온 거예요. 즉, "오픈소스 클라이언트는 오픈소스 서버 어디든 붙어서 동작해야 한다"는 자유 소프트웨어의 정신이 흔들리는 것 아니냐는 비판이죠.

Bitwarden CTO는 "이건 오해다, 자체 호스팅을 막을 의도가 없다, 라이선스 문구를 명확히 하겠다"고 진화에 나섰고, 실제로 일부 문구가 수정되긴 했어요. 하지만 한 번 신뢰가 흔들린 커뮤니티의 우려는 쉽게 가라앉지 않고 있어요. 글의 저자는 "비슷한 패턴을 우리는 이미 너무 많이 봤다"는 점을 강조해요.

오픈소스의 '엔터프라이즈화' 패턴

사실 이런 일이 처음이 아니거든요. Elastic은 자사 검색 엔진 Elasticsearch를 Apache 2.0에서 SSPL(Server Side Public License)로 바꿨다가 커뮤니티 반발로 OpenSearch라는 포크(fork, 원본을 복제해서 별도로 발전시키는 프로젝트예요)가 갈라져 나왔어요. MongoDB도 비슷한 길을 갔고, HashiCorp는 Terraform을 BSL(Business Source License)로 바꾸면서 OpenTofu라는 포크를 낳았죠. Redis도 최근에 비슷한 라이선스 변경을 했다가 Valkey라는 포크가 생겼고요.

이런 변화에는 공통된 패턴이 있어요. 처음엔 진짜 오픈소스로 시작해서 커뮤니티의 신뢰와 무료 마케팅을 얻고, 사용자가 충분히 쌓이면 "AWS 같은 클라우드 거대 기업이 우리 코드로 돈 벌어가니까 우리도 보호 장치가 필요해"라는 논리로 라이선스를 조이는 거죠. 회사 입장에서는 생존 전략이지만, 자체 호스팅 사용자나 작은 경쟁 서비스 입장에서는 뒤통수를 맞은 셈이 돼요.

Bitwarden의 경우 아직 그 정도로 극단적인 변화는 아니에요. 하지만 "비밀번호"라는, 가장 민감한 데이터를 다루는 서비스라는 점에서 사용자들의 경계심은 훨씬 더 클 수밖에 없어요. 비밀번호 관리자는 한번 의존하기 시작하면 옮기기가 정말 어렵거든요. 수백 개의 계정 정보가 한 곳에 모여 있으니까요.

대안에는 뭐가 있나

그래서 글에서 추천하는 대안과, 일반적으로 거론되는 옵션들을 정리해볼게요. 가장 자주 언급되는 건 KeePassXC 예요. 이건 완전히 로컬에서 동작하는 비밀번호 관리자로, 데이터베이스 파일을 직접 관리하고 동기화는 클라우드 드라이브로 처리하는 방식이에요. 클라우드 의존도가 없는 대신 모바일 동기화 같은 부분은 직접 설정해야 해서 좀 번거롭죠.

그 다음은 Proton Pass. 스위스의 Proton Mail 회사가 만든 건데, 이쪽도 오픈소스를 표방하고 있어요. 다만 비교적 신생이라 성숙도는 Bitwarden보다 떨어진다는 평가가 있고요. 그리고 1Password는 상용이지만 보안 기록과 UX 측면에서 평판이 좋고, 한국 사용자들 사이에서도 점유율이 높은 편이에요.

자체 호스팅을 고집한다면 앞서 말한 Vaultwarden 이 여전히 잘 동작해요. 이번 사태로 오히려 "Bitwarden 서버 의존도를 줄이자"는 흐름이 강해지고 있고요.

한국 개발자에게 주는 시사점

이 사건이 우리에게 주는 교훈은 두 가지예요. 첫째, 데이터를 어디에 맡길 때는 '이주 가능성(portability)' 을 항상 염두에 둬야 한다는 거예요. Bitwarden은 다행히 JSON이나 CSV로 모든 비밀번호를 내보낼 수 있어요. 이런 export 기능이 잘 갖춰진 서비스를 선택하는 게 중요해요. 둘째, "오픈소스"라는 라벨만 보고 안심하지 말고, 라이선스가 실제로 어떻게 작성되어 있는지 한 번쯤 확인해보는 습관이 필요해요. Apache 2.0, MIT, GPL은 다 다르고, BSL이나 SSPL 같은 "소스 사용 가능(source-available)" 라이선스는 진짜 오픈소스가 아니에요.

개발자로서 우리가 만드는 서비스에도 이건 시사하는 바가 커요. 사용자에게 "우리는 오픈소스입니다"라고 했다가 나중에 라이선스를 바꾸는 건, 단기적으로는 비즈니스 이익을 줄지 몰라도 장기적인 신뢰 자산을 갉아먹는 행위예요.

마무리

핵심을 한 줄로 정리하면 이거예요. Bitwarden 자체가 당장 쓸 수 없게 된 건 아니지만, 라이선스 변경 흐름은 '오픈소스가 영원하지 않다'는 사실을 다시 일깨우는 사건이다. 만약 자체 호스팅 사용자라면 Vaultwarden 호환성 변화를 주시하고, 일반 사용자라면 적어도 정기적으로 데이터를 export해두는 습관을 들이는 게 좋겠어요.

여러분은 어떤 비밀번호 관리자를 쓰고 계신가요. 오픈소스라는 점이 선택의 결정적 이유였나요, 아니면 그냥 편해서 쓰고 계신가요? 그리고 이런 라이선스 변경 흐름에 대해서는 어떻게 생각하시나요?