앱스토어의 Bitwarden이 바뀐다 — 코드는 그대로인데 신뢰는 왜 흔들리나

이번 변경은 배포 경로의 정리인가, 오픈소스에서 오픈코어로 넘어가는 첫걸음인가?

도입

2026년 10월 9일, Bitwarden 커뮤니티 포럼에 「Published version update in app stores」라는 짧은 공지가 올라왔다. 작성자는 RyanL. 요지는 한 문장이다. 다음 릴리스부터 각 스토어에 게시되는 Bitwarden 앱은 상용 라이선스 빌드가 된다. 공지는 곧바로 안심시키는 문장을 덧붙인다. 아무런 조치도 필요 없고 앱은 지금과 똑같이 동작한다. GPLv3 빌드는 계속 GitHub에 업데이트되어 게시되며, 현재의 모든 기능은 두 버전 모두에서 쓸 수 있고, 무료 플랜도 유지된다.

다음 날인 10월 10일 이 공지는 「Bitwarden Dual License Model」이라는 제목으로 해커뉴스에 올라가 408점을 받았다. 반응은 차분하지 않았다. Elasticsearch, Terraform, Redis의 이름이 줄줄이 소환됐고, 「enshittification」이라는 단어가 여러 번 등장했으며, Vaultwarden으로 옮기겠다는 사람과 Apple Passwords로 가겠다는 사람이 같은 스레드에 섞였다.

흥미로운 것은 공지의 내용과 반응의 온도 차이다. 공지만 읽으면 바뀌는 것은 거의 없다. 같은 코드, 같은 기능, 같은 앱이다. 그런데 비밀번호 관리자라는 제품에서 사용자는 기능보다 먼저 「이 회사를 언제까지 믿을 수 있는가」를 읽는다. 이 글은 공지와 GitHub의 라이선스 문서를 근거로 실제로 무엇이 바뀌는지를 먼저 정리하고, 그다음 왜 이 작은 변경이 큰 불신을 불렀는지를 따져 본다.

무엇이 바뀌고 무엇이 바뀌지 않는가

먼저 사실관계다. Bitwarden에는 이미 두 개의 라이선스가 있었다. 클라이언트 리포지토리(bitwarden/clients)의 LICENSE.txt는 소스 코드가 GPL v3.0 또는 Bitwarden License v1.0 중 하나로 덮인다고 적고 있다. 기본값은 GPL v3.0이고, Bitwarden License 코드는 /bitwarden_license 디렉터리 안에만 있다. 서버 리포지토리의 LICENSE_FAQ.md도 같은 구조를 설명한다. 개인용 금고의 핵심 코드(데스크톱, 웹, 브라우저, 모바일, CLI)는 GPL 3.0, 메인 서버는 AGPL 3.0이며, 대규모 조직용으로 설계된 일부 모듈과 SSO 통합은 「소스 공개(source available)」형 상용 라이선스인 Bitwarden License를 따른다.

즉 「듀얼 라이선스」라는 해커뉴스 제목은 새로운 제도를 가리키는 것이 아니다. 실제로 한 HN 이용자는 링크된 페이지 어디에도 「Dual License」라는 말이 없고, 이 변경을 정확히 묘사하는 표현도 아니라고 지적했다(@josephcsible, 직접 인용은 아니고, 코멘트의 요지를 요약).

그렇다면 무엇이 새로운가. 공지에 나중에 덧붙여진 설명에 따르면, Bitwarden은 새 릴리스를 빌드할 때마다 이미 두 가지 버전을 만들어 GitHub에 올려 왔다. 상용 버전과 GPLv3 버전이다. 지금까지 앱스토어에는 GPLv3 버전을 올렸다. 그러다 보니 상용 기능이 필요한 플랜의 고객은 GitHub에 가서 상용 버전을 받아야 했는데, 회사 측 표현으로는 기업이나 정부 직원에게 그런 일을 기대할 수는 없다. 그래서 스토어에 상용 빌드를 올려 모든 사람이 같은 곳에서 자기가 돈을 낸(혹은 내지 않은) 기능을 받게 하겠다는 것이다. 포럼 질의응답에서는 Bitwarden 다운로드 페이지의 직접 다운로드 링크도 상용 라이선스 빌드로 바뀐다고 확인됐다.

바뀌지 않는다고 회사가 명시한 것도 정리해 두자. 스토어 클라이언트는 GitHub의 100% 공개 감사 가능한 코드에서 직접 빌드된다. 비공개로 전환된 코드는 없다. 상용 라이선스 코드조차 포크할 수 있다. 셀프 호스팅에는 변화가 없고, 이번 라이선스 변경은 Bitwarden을 재판매하는 쪽에 영향을 준다. 무료 플랜은 영구히 유지된다. 그리고 GPLv3 라이선스만 쓰고 싶은 사용자는 앱을 직접 내려받아 사이드로드하면 되지만, 그 경우 상용 라이선스로 제공되는 유료 기능은 쓸 수 없다.

여기까지가 공지의 표면이다. 그런데 포럼의 첫 질문에서 이미 균열이 보였다. grb라는 사용자가 두 버전 사이에 어떤 차이가 생기느냐고 묻자, RyanL은 일부 미래 컴포넌트가 상용 라이선스로 게시되어 그 빌드에만 존재할 것이며, 새로 개발되는 기능은 어느 라이선스를 적용할지 사례별로 평가한다고 답했다. grb는 곧바로 「현재의 모든 기능」이라는 문장에서 「현재」라는 단어가 상당히 무거운 짐을 지고 있다고 받아쳤다. 회사가 덧붙인 설명도 같은 방향이다. 새로운 엔터프라이즈 기능, 새로운 제품, 새로운 시장에서 전략적 경쟁 우위를 주는 항목은 상용 라이선스 뒤에 놓인다. 대부분은 비즈니스 플랜에만 해당하지만, 프리미엄 플랜의 일부 기능도 사례별 검토에 따라 상용 라이선스가 될 수 있다. 배경으로는 FedRAMP 관련 발표와 Privileged Controls 발표가 예시로 언급됐다.

정리하면 이렇다. 오늘의 코드와 기능은 그대로다. 바뀌는 것은 기본 배포 채널의 라이선스와, 앞으로 생길 기능이 어느 쪽에 놓일지를 회사가 사례별로 정한다는 원칙이다.

「소스 공개」라는 말의 범위와 신뢰의 조건

라이선스 본문이 말하는 것

공지에는 「Bitwarden은 여전히 오픈소스다」, 「상용 라이선스 코드도 포크할 수 있다」는 문장이 있다. 이 말이 정확히 무엇을 뜻하는지는 Bitwarden License 본문을 읽어야 알 수 있다. 클라이언트 리포지토리의 LICENSE_BITWARDEN.txt(2020년 9월 4일자 버전 1)를 보면, 제2.1조는 상용 모듈에 대해 오로지 내부 개발과 내부 테스트 목적으로, 그리고 비운영 환경에서만 쓸 수 있는 제한적·비독점적 라이선스를 부여한다. 제2.3조는 판매, 대여, 배포, 재라이선스 등 제3자에게 넘기는 행위와, 상용 모듈을 이용해 경쟁 제품이나 서비스를 만드는 것을 금지한다.

서버 리포지토리의 FAQ는 이 점을 숨기지 않는다. Bitwarden License는 OSI 정의상 오픈소스 라이선스에 해당하지 않으며, 운영 환경에서 쓰려면 유료 구독이 필요하다고 적는다. 그리고 이 방식이 Elastic과 Confluent 같은 회사의 라이선스 접근을 본뜬 것이라고 스스로 밝힌다. 해커뉴스에서 Elasticsearch와 Redis가 가장 먼저 소환된 것은 우연이 아니다. 회사 스스로 그 계보를 참조하고 있다.

그러니 「포크할 수 있다」는 말은 기술적으로는 참이지만 법적으로는 좁다. 상용 코드를 복제해서 읽고 내부에서 시험할 수는 있다. 그러나 그것을 운영 환경에서 쓰거나 남에게 배포하는 것은 이 라이선스로는 허용되지 않는다. 공개 감사 가능성은 유지되지만, 자유 소프트웨어의 의미에서 말하는 「수정해서 쓰고 나눌 자유」는 상용 영역에서는 사라진다.

이 경계가 처음 화제가 된 것도 아니다. 2024년 10월, bitwarden/clients 리포지토리에 「Desktop version 2024.10.0 is no longer free software」라는 이슈(#11611)가 올라왔다. 신고자는 데스크톱 클라이언트 빌드에 필요한 @bitwarden/sdk-internal 의존성의 라이선스에, Bitwarden이 아닌 소프트웨어(호환되지 않는 Bitwarden 구현 포함)와 함께 쓰일 애플리케이션을 개발하는 데 이 SDK를 쓰면 안 된다는 조항이 있다고 지적했다. Bitwarden 창업자 Kyle Spearrin(kspearrin)은 처음에는 SDK와 클라이언트가 별개의 프로그램이라고 설명하며 빌드 문제는 버그라고 답했다. 며칠 뒤에는 SDK 코드를 재편해, 클라이언트가 참조하는 sdk-internal 패키지를 새 리포지토리로 옮기고 GPL 라이선스만 쓰도록 했다고 밝혔다. 그리고 한 문장을 남겼다. 만약 앞으로 그 참조에 Bitwarden License 코드가 포함된다면, 웹 금고 빌드에서 하듯 클라이언트의 여러 빌드 변형을 만드는 방법을 제공하겠다는 것이다.

2026년 10월의 공지는 그 문장이 2년 만에 실행된 모습으로 읽을 수 있다. 빌드 변형은 이미 있었고, 이번에는 그중 어느 쪽이 기본 배포 채널에 올라가느냐가 바뀌었다. 이 연결은 공지 자체가 명시한 것은 아니며, 필자의 해석이다.

Vaultwarden과 셀프 호스팅 사용자

이번 논의에서 가장 구체적인 불안은 셀프 호스팅 쪽에서 나왔다. Vaultwarden은 Bitwarden 서버 API를 Rust로 다시 구현한 커뮤니티 서버로, 공식 Bitwarden 클라이언트를 그대로 붙여 쓸 수 있다. 셀프 호스팅 사용자 상당수는 서버만 Vaultwarden이고 클라이언트는 공식 앱이다.

해커뉴스에서 이 구조를 정확히 짚은 코멘트가 있었다. 약 15명 규모 팀에서 수년간 Vaultwarden을 운영했다는 이용자는, 지켜봐야 할 것은 서버가 아니라 클라이언트이며 클라이언트가 지렛대라고 썼다. 모바일 앱을 소스에서 빌드할 수 없게 되면 셀프 호스팅 이야기는 훨씬 빈약해진다는 것이다(@hn3ufz62f7, 직접 인용은 아니고, 코멘트의 요지를 요약). 다른 이용자는 Vaultwarden과 공식 macOS, iOS 클라이언트를 몇 년간 써 왔는데 iOS 앱 자동 업데이트가 서버와의 호환성을 깨뜨려 도커 인스턴스를 업데이트해야 했던 일이 있었다며, 장기적으로 이 조합에 머무는 것이 현명하지 않을 수 있다고 적었다(@fiatpandas, 직접 인용은 아니고, 코멘트의 요지를 요약).

포럼에서도 같은 질문이 나왔다. davidmayr라는 사용자는 MinIO 사례로 한 번 당한 경험을 언급하며, Vaultwarden 같은 제3자 팀이 계속 프로토콜을 쓸 수 있는지, 상용 브라우저 확장이 오픈소스 클라이언트와 계속 호환되는지를 물었다. Bitwarden 측 dwbit은 제3자 커뮤니티 서버에 대해서는 변화가 없으며 그들은 어떤 기능을 지원하고 구축할지 계속 선택할 수 있다고 답했다. 셀프 호스팅 사용자가 이류 시민이 되느냐는 Wreckage의 질문에는 셀프 호스팅에 변화가 없고 재포장해 재판매하는 쪽에만 영향이 있다고 답했다. 그러나 Wreckage는 미래가 더 걱정된다며, 앞으로의 기능이 셀프 호스팅 사용자에게도 제공되는지 다시 물었다. 셀프 호스팅 능력은 문제가 생겼을 때의 탈출 전략이라는 것이다. 필자가 확인한 시점의 스레드에서 이 질문에 대한 답은 보이지 않았다.

여기서 두 종류의 셀프 호스팅을 구분할 필요가 있다. Bitwarden이 엔터프라이즈 고객에게 파는 셀프 호스팅은 자사 공식 서버 스택이다. 이 부분은 유료 고객이 있는 제품이므로 쉽게 바뀌지 않을 것이다. 반면 Vaultwarden은 공식적으로 지원되는 경로가 아니다. ByteHaven이라는 블로그의 필자 PPB1701은 Vaultwarden이 Bitwarden이 용인해 왔을 뿐 지지한 적은 없는 공간에 있으며, 계산이 바뀌면 발표 없이 API가 조금씩 어긋나 호환성이 깨지는 식으로 용인이 끝날 수 있다고 썼다. 다만 그 자신도 그것이 임박했다고 보지는 않는다고 덧붙였다. 이는 한 블로거의 전망이지 확인된 사실이 아니다.

보안 제품의 라이선스는 왜 기능보다 먼저 읽히나

라이선스 변경 공지에 이토록 반응하는 이유를 단순히 「무료를 원하는 사람들의 불만」으로 정리하는 시각도 스레드에 있었다. 한 이용자는 enshittification이라는 말이 사실상 도구에 돈을 내기 싫다는 뜻이라고 비판하며, 기부로는 Bitwarden 같은 제품의 개발 자본을 감당할 수 없다고 주장했다(@rvz, 직접 인용은 아니고, 코멘트의 요지를 요약). 다른 이용자는 완전한 오픈소스가 더 좋긴 하지만 「모든 소스 공개, 상업적 이용에 일부 제한」도 훨씬 낫다며, 큰 기업이 코드를 가져가 유통력으로 압도하는 문제에 대한 현실적 해법은 라이선스 변경밖에 없어 보인다고 이해를 표했다(@dannyw, 직접 인용은 아니고, 코멘트의 요지를 요약).

이 반론들은 일리가 있다. 그러나 비밀번호 관리자에서 라이선스가 갖는 의미는 데이터베이스나 검색 엔진과 다르다. 이유는 세 가지다.

첫째, 감사 가능성과 검증 가능성은 다르다. 회사는 스토어 빌드가 100% 공개된 코드에서 빌드된다고 말한다. 그러나 한 HN 이용자는 오픈소스 채널을 계속 유지하더라도 이제는 빌드를 검증할 수 없게 될 것이라고 우려했다(@bigbaguette, 직접 인용은 아니고, 코멘트의 요지를 요약). 이 우려가 기술적으로 맞는지는 이번 자료만으로는 판단할 수 없다. 상용 빌드도 공개 코드에서 나온다면 원리상 재현 빌드로 확인할 수 있다. 하지만 상용 코드를 운영 환경에서 쓸 권리가 없는 제3자가 그 검증을 얼마나 적극적으로 할지는 별개의 문제다. 코드는 보이지만, 그 코드를 들고 무언가를 할 동기는 줄어든다.

둘째, 비밀번호 관리자의 핵심 가치는 이탈 가능성이다. 포럼의 zfJames는 언제든 셀프 호스팅을 선택할 수 있어야 한다는 것이 자신의 요구 조건이며, 그것이 비밀번호가 빠져나올 수 없는 상자에 갇히지 않게 하는 안전장치라고 썼다. 다른 사용자 Nail1684는 금고 내보내기가 없어질 징후는 없고 오히려 최근 모바일 앱에 Credential Exchange Protocol/Format(CXP/CXF)이 추가됐다고 반박했다. 이탈 경로가 데이터 형식 수준에서 보장된다면 라이선스는 덜 중요해진다. 실제 쟁점은 그 경로가 얼마나 오래 유지되느냐다.

셋째, 신뢰는 개별 사건이 아니라 패턴으로 판단된다. ByteHaven 블로그는 이번 공지 이전부터 Bitwarden에 일어난 변화를 나열해 왔다. 2026년 3월의 프리미엄 가격 인상, 2월의 CEO 교체(Fast Company 보도를 인용), 4월 중순 개인용 페이지에서 「Always free」 문구가 사라진 일, 5월의 사내 가치 GRIT의 재정의 등이다. 이것들은 그 블로거가 정리한 내용이고 필자가 하나하나 원출처로 확인한 것은 아니다. 다만 해커뉴스에서 이 글이 최상위 코멘트로 다시 소개되었다는 사실(@rsyring)은, 사용자들이 이번 공지를 단독으로 읽지 않았다는 것을 보여 준다. 라이선스 공지는 그 자체로는 작아도, 이미 쌓여 있던 의심 위에 놓이면 「마지막 퍼즐 조각」으로 읽힌다.

전망과 시사점

앞으로 볼 지표는 비교적 분명하다. 첫째, GPLv3 빌드에 새 기능이 실제로 얼마나 들어가는가. 회사는 사례별로 평가한다고 했고, HN의 한 이용자는 그 말이 오픈코어 개발의 전통대로 「새 기능은 OSS 버전에 들어가지 않는다」는 뜻이라고 해석했다(@PunchyHamster, 직접 인용은 아니고, 코멘트의 요지를 요약). 어느 쪽이 맞는지는 다음 몇 번의 릴리스 노트가 답할 것이다. 상용 전용 기능이 엔터프라이즈 관리, 정부 대응, 권한 통제 같은 조직용 영역에 머문다면 개인 사용자에게는 체감 변화가 거의 없을 것이다. 반대로 프리미엄 개인 기능이 상용 쪽으로 넘어가기 시작하면 지금의 불안은 현실이 된다.

둘째, 제3자 클라이언트의 성장이다. HN에서는 Android에서 Keyguard와 Vaultwarden 조합으로 옮겼다는 이용자(@0l)가 있었고, Bitwarden 공식 클라이언트가 늘 「잠재력은 상상할 수 있을 만큼은 좋지만 거기에 도달하지는 못하는」 상태였으니 커뮤니티가 대체 클라이언트를 만들 계기가 필요했다는 의견(@lucideer)도 있었다(둘 다 직접 인용은 아니고, 코멘트의 요지를 요약). 서버를 다시 구현한 Vaultwarden이 이미 있으므로, 클라이언트까지 독립하면 공식 생태계 의존도는 크게 줄어든다. 다만 보안 소프트웨어의 클라이언트를 누가 장기간 유지하고 감사할 것인지는 또 다른 신뢰 문제를 낳는다.

셋째, AI 시대의 라이선스 실효성이라는 논점도 스레드에 등장했다. 상용 기능을 만들면 누군가가 곧바로 그 기능을 LLM으로 오픈소스 쪽에 재현할 것이라는 주장이다(@charcircuit, @rvz, 직접 인용은 아니고, 코멘트의 요지를 요약). 흥미로운 관점이지만, 비밀번호 관리자에서 「빠르게 재현된 기능」이 신뢰를 얻는 데는 코드 작성보다 훨씬 긴 시간이 걸린다. 재현 비용이 내려가도 검증 비용은 그만큼 내려가지 않는다.

조직의 관점에서 정리하면, 지금 당장 할 일은 많지 않다. 공식 스토어 앱을 쓰는 개인 사용자에게 공지 시점의 변화는 사실상 없다. 다만 셀프 호스팅을 탈출 전략으로 삼고 있다면, 그 전략이 공식 클라이언트와의 호환성에 얼마나 기대고 있는지 한 번 점검해 둘 가치는 있다. 그리고 내보내기 형식(CXF 포함)으로 실제로 금고를 꺼내 다른 도구에 넣어 보는 리허설은, 어떤 라이선스 공지보다도 구체적인 안심을 준다.

결론

이번 Bitwarden 공지를 문자 그대로 읽으면, 이미 존재하던 두 개의 빌드 중 어느 쪽을 앱스토어에 올리느냐를 바꾼 배포 정책 변경이다. 코드는 계속 공개되고, 현재 기능은 양쪽에 다 있으며, 셀프 호스팅에도 변화가 없다고 회사는 반복해서 말한다. 그 설명들은 GitHub의 라이선스 문서와도 대체로 맞는다.

그러나 공지의 무게는 「현재」라는 단어에 실려 있다. 미래의 기능이 어느 쪽에 놓일지는 사례별로 정해지고, 그 결정권은 회사에 있다. 그리고 그 결정이 놓이는 상용 라이선스는 OSI 기준의 오픈소스가 아니며, 운영 환경 사용과 재배포를 허용하지 않는다. 2024년 SDK 논쟁에서 예고된 빌드 변형이 이제 기본 채널이 됐다.

비밀번호 관리자를 고를 때 사람들은 기능 목록보다 이탈 경로를 먼저 본다. 이번 변경이 이탈 경로를 직접 막지는 않는다. 다만 그 경로가 회사의 선의에 얼마나 의존하는지를 다시 보이게 만들었다. 당신의 금고를 내일 다른 도구로 옮겨야 한다면, 그 절차는 지금 몇 단계이고, 그중 몇 단계가 Bitwarden의 결정에 달려 있는가.

출처: