OpenBao는 Vault에서 실제로 얼마나 갈라졌나 — v2.6 네임스페이스 봉인까지, 릴리스 노트로 확인한 분기점

들어가며 — 포크 2년, 감정 말고 릴리스 노트로
배경 — 어디서 갈라졌고, 소유권은 어떻게 움직였나
버전별로 본 실제 분기 — OpenBao가 더한 것들
네임스페이스 — Enterprise 기능이 넘어온 순간, 그리고 그 너머
반대 방향의 분기 — OpenBao가 빼는 것들
같은 방향으로 움직인 것 — 보안 기본값과 CVE 포팅
Vault 쪽에서 물리는 것 — CE 패치 절벽
그래서 무엇을 골라야 하나
마치며
참고 자료

들어가며 — 포크 2년, 감정 말고 릴리스 노트로

오늘(2026-07-17)은 OpenBao v2.0.0 GA가 나온 지 정확히 2년 되는 날이고, v2.6.0이 나온 지는 사흘입니다. 그리고 이 주제는 여전히 진영이 갈립니다 — 한쪽은 "BUSL 전환은 배신"이라 하고, 다른 쪽은 "포크는 기능도 지원도 못 따라온다"고 합니다. 라이선스 전환의 배경 자체는 오픈소스 라이선스 지형 정리 편에서 다뤘으니, 이 글은 다른 질문에 답합니다. 포크는 실제로 어디서 갈라졌나 — 마케팅 문구가 아니라, 양쪽 프로젝트가 스스로 발행한 릴리스 노트와 체인지로그, 커밋에서 확인되는 것만으로요.

같은 포크 가족인 OpenTofu가 업스트림 Terraform에 없는 기능을 먼저 출시하기 시작한 이야기는 OpenTofu의 dynamic lifecycle 편에서 다뤘습니다. 이 글은 그 시크릿 관리 버전입니다.

배경 — 어디서 갈라졌고, 소유권은 어떻게 움직였나

시간순으로 확인되는 사실만 늘어놓으면 이렇습니다.

Vault 저장소의 LICENSE 파일은 BUSL 1.1이고, 적용 대상을 "Vault Version 1.15.0 or later"로 명시합니다. 즉 1.14 계열이 마지막 MPL 코드베이스입니다.
OpenBao는 그 지점에서 갈라졌습니다. v2.0.0 릴리스 노트는 "OpenBao is fully API compatible with Vault 1.14.9"라고 못 박고, Enterprise 기능은 지원하지 않는다고 밝힙니다. GA는 2024-07-17이었고, 이 시점엔 웹 UI조차 빠져 있었습니다.
IBM의 HashiCorp 인수는 2025-02-27에 완료됐습니다(IBM 뉴스룸).
OpenBao는 2025-06-17에 LF Edge에서 OpenSSF 샌드박스 프로젝트로 이관됐습니다.
2026-03-26, Vault 저장소의 LICENSE에서 라이선서가 "HashiCorp, Inc."에서 "International Business Machines Corporation (IBM)"으로 바뀌었습니다(커밋 diff에서 그대로 확인됩니다 — 경쟁 제품 금지 조항의 보호 대상도 "IBM Corp's paid version(s)"로 바뀌었습니다).
2026-04-14, Vault 2.0.0이 나왔습니다. 1.0(2018) 이후 첫 메이저 번호 점프이고, FEATURES 목록에는 "IBM PAO License Integration" — IBM 라이선스 키로 Vault Enterprise를 쓰게 하는 기능 — 이 들어 있습니다.

인수 후 통합이 라이선스 파일과 기능 목록에까지 내려온 셈입니다. 이제 포크 쪽이 그동안 무엇을 쌓았는지 보겠습니다.

버전별로 본 실제 분기 — OpenBao가 더한 것들

전부 OpenBao CHANGELOG와 GitHub 릴리스에서 확인한 내용입니다. 날짜는 GitHub API의 릴리스 발행 시각 기준입니다.

v2.1.0  2024-11-29  트랜잭셔널 스토리지(GH-292), 마운트 테이블 크기 제한 제거(GH-622),
                    PostgreSQL 백엔드 부활 + 페이지네이션 LIST(GH-467)
v2.2.0  2025-03-05  PKCS#11 HSM 오토 언실(GH-889), 리스너 TLS의 ACME 자동 발급(GH-857),
                    재귀 목록 조회 SCAN 동사·ACL(GH-763), 웹 UI 복귀(GH-940), Raft 논보터(GH-741)
v2.3.1  2025-06-25  네임스페이스(GH-1165), 네임스페이스 UI(GH-1406),
                    PKI·JWT 인증의 CEL 정책(GH-794, GH-869), KMIP 오토 언실(GH-1144)
v2.4.0  2025-08-28  선언적 자기 초기화(GH-1506), 인라인 무토큰 인증(GH-1433),
                    LIST/SCAN 응답 필터링(GH-1389), 설정 파일 기반 감사 장치(GH-1700)
v2.5.0  2026-02-04  스탠바이 읽기 스케일링(GH-1986), OCI 이미지 기반 플러그인 배포(GH-1824),
                    미인증 rekey 엔드포인트 기본 차단(GH-2125, 브레이킹)
v2.6.0  2026-07-14  네임스페이스 봉인(GH-3297), 오토 언실 KMS 플러그인화(GH-2586),
                    sys/workflows(GH-2728), 인증된 루트 토큰 생성(GH-3041), distroless 이미지

여기서 두 가지 축이 보입니다. 하나는 Vault Enterprise 전용 기능의 오픈소스화입니다. 네임스페이스, HSM 언실, 스탠바이 노드 읽기 스케일링(업스트림의 performance standby에 해당)은 전부 Vault에서는 Enterprise 문서 트리에 있는 기능입니다. 다른 하나는 업스트림에 아예 없는 방향입니다 — 트랜잭셔널 스토리지, CEL 정책, 선언적 자기 초기화, 인라인 인증 같은 것들은 Enterprise 카탈로그를 베낀 게 아니라 포크의 독자 설계입니다. 프로젝트가 2026년 7월에 낸 트랜잭셔널 스토리지, 페이지네이션 LIST 해설 글이 이 차별화 축을 스스로 정리하고 있습니다(프로젝트 자체 서술이므로 그 점은 감안하고 읽으십시오).

네임스페이스 — Enterprise 기능이 넘어온 순간, 그리고 그 너머

가장 상징적인 분기는 네임스페이스입니다. Vault에서 네임스페이스는 멀티테넌시의 근간이자 Enterprise 구매 사유의 상당 부분인데, OpenBao는 v2.3.1(2025-06-25)에서 이걸 오픈소스로 출시했습니다. 체인지로그 표현이 흥미롭습니다 — "application API compatible with upstream's implementation". 경로 기반(/my-namespace/secrets)과 X-Vault-Namespace 헤더 라우팅을 모두 지원한다고 명시했고, 공식 발표 글은 "Vault Enterprise와의 API 호환을 유지해 매끄러운 이주 경로를 제공한다"고 적었습니다. 호환은 목표가 아니라 이주 유인책입니다.

그리고 사흘 전 v2.6.0은 한 발 더 나갔습니다. 네임스페이스 봉인(namespace sealing) — 네임스페이스 생성 시 별도의 Shamir seal을 구성해서, 릴리스 노트 표현으로는 "테넌트 스토리지를 서로 다른 암호학적 키 머티리얼로 파티셔닝"하고, 테넌트가 다른 테넌트에 영향 없이 자기 네임스페이스만 봉인해 접근을 차단할 수 있게 했습니다. 비교하자면 Vault Enterprise의 네임스페이스 잠금 API는 문서상 "locks the API" — API 레벨 차단입니다. 키 머티리얼 분리는 다른 층위의 격리이고, 이건 2025년 5월 발표 글에서 "탐색 중"이라던 항목이 1년여 만에 출시된 것입니다. 포크가 업스트림 카탈로그 따라잡기를 넘어 자기 로드맵으로 움직인다는 가장 구체적인 증거입니다.

물론 절제해서 읽어야 합니다. 네임스페이스 봉인은 이번 릴리스에 처음 나온 기능이고, 실전 검증 이력이 없습니다. 멀티테넌트 격리를 이것 하나에 걸기엔 이릅니다.

반대 방향의 분기 — OpenBao가 빼는 것들

이주를 고민한다면 이쪽이 더 중요합니다. OpenBao는 더하는 만큼 공격적으로 뺍니다.

스토리지 백엔드. OpenBao 문서에 있는 백엔드는 Raft, PostgreSQL, 파일, 인메모리(개발용)가 전부입니다. Consul, DynamoDB, S3 같은 Vault의 백엔드 목록은 포크 시점에 정리됐습니다. 심지어 파일 백엔드도 v2.6.0에서 폐기 예고됐고 v2.7.0에서 제거됩니다(GH-2849). Consul 스토리지 위에서 돌던 Vault를 그대로 들어 옮길 수는 없다는 뜻입니다.

클라우드 시크릿 엔진. AWS·Azure·GCP의 동적 크리덴셜 엔진은 OpenBao 코어에 없습니다. openbao-plugins 저장소의 외부 플러그인으로 제공되는데(인증: AWS/Azure/GCP/GitHub, 시크릿: AWS/Azure/GCP/GCPKMS/Nomad/Consul), 같은 README가 데이터베이스 플러그인 항목엔 "None available at this time"이라고 적고 있습니다 — 코어에 든 것(PostgreSQL, MySQL, Valkey 등) 외의 DB 엔진은 없다는 이야기입니다.

내장 seal과 배포판. v2.6.0은 오토 언실을 외부 KMS 플러그인 체계로 바꾸면서, 내장돼 있던 awskms·azurekeyvault·gcpckms·pkcs11 등의 seal을 v2.7.0에서 제거한다고 예고했습니다. HSM 전용 배포판 자체도 v2.7.0까지 단계적으로 폐지됩니다. LDAP·Kerberos·RADIUS 플러그인도 메인 바이너리에서 빠져 외부 플러그인으로 이동합니다(GH-3371).

방향 자체는 일관됩니다 — 코어를 줄이고 경계를 플러그인으로 미는 것. 하지만 운영자 입장에서 v2.6에서 v2.7로 올라가는 업그레이드는 seal 설정, 스토리지, 인증 방법이 한꺼번에 걸리는 지뢰밭이 될 수 있습니다. 릴리스 노트의 DEPRECATIONS 섹션을 이번만큼은 정말로 읽어야 합니다.

그리고 빠진 것 중 가장 큰 항목은 폐기 예고 목록에도 없습니다. 크로스 클러스터 복제 — Vault Enterprise의 performance/DR 레플리케이션에 해당하는 기능이 OpenBao에는 없습니다. v2.5.0의 스탠바이 읽기 스케일링은 단일 클러스터 안의 확장이고, 체인지로그 스스로 "결과는 최종 일관성"이라고 명시합니다. 다중 리전 액티브-액티브가 필요하다면 OpenBao는 현재 답이 없습니다.

같은 방향으로 움직인 것 — 보안 기본값과 CVE 포팅

분기만 있는 건 아닙니다. 보안 쪽에선 두 프로젝트가 여전히 얽혀 있습니다.

미인증 운영 엔드포인트 강화가 좋은 예입니다. OpenBao는 v2.3.1(2025-06)에서 미인증 rekey를 끌 수 있는 리스너 옵션을 넣고(CVE-2025-52894, 체인지로그가 업스트림 HCSEC-2025-11을 병기), v2.5.0(2026-02)에서 기본값을 차단으로 뒤집었으며, v2.6.0에서 인증된 루트 토큰 생성 엔드포인트를 추가했습니다. Vault도 2.0.0(2026-04)에서 sys/rekey와 sys/generate-root를 기본 인증으로 바꿨습니다. 누가 누굴 따라갔는지는 제가 판정할 수 없지만, 날짜는 위와 같습니다.

포팅 관계도 실재합니다. OpenBao v2.3.2(2025-08-07)는 업스트림 Vault의 HCSEC-2025 계열 보안 수정 8건(HCSEC-2025-13 등)을 이식하면서 자체 CVE 번호(CVE-2025-54996 등)를 붙였습니다. 포크 2년이 지나도 코드 계보가 겹치는 만큼, 한쪽의 보안 공지가 다른 쪽 사용자에게도 경보라는 뜻입니다. 어느 쪽을 운영하든 양쪽의 시큐리티 어드바이저리를 다 구독하는 게 맞습니다.

Vault 쪽에서 물리는 것 — CE 패치 절벽

Vault를 무료(CE)로 쓰는 팀이라면 Vault CHANGELOG의 릴리스 헤더 패턴을 직접 확인해 보길 권합니다. 관찰되는 사실은 이렇습니다.

1.21 계열의 CE 패치는 1.21.4(2026-03-05)가 마지막입니다. Vault 2.0.0이 GA된 2026-04-14부터 1.21.5는 "Enterprise" 표기가 붙어 나옵니다. 1.20 계열도 같은 패턴이었습니다 — 1.21.0이 나온 날(2025-10-22)부터 1.20.5는 Enterprise 전용.
즉 새 마이너가 나오는 순간, 이전 브랜치의 CE 보안 패치는 끝납니다. CE로 패치를 계속 받는 유일한 방법은 항상 최신 마이너로 올라타는 것입니다.
장기 지원은 명시적으로 유료 기능입니다. LTS 문서는 Enterprise 전용 알림과 함께 "기본 1년 유지보수 + LTS로 1년 연장"을 설명합니다.

이건 음모가 아니라 공개된 정책이고, HashiCorp/IBM의 권리입니다. 다만 "Vault CE니까 공짜로 안정 운영"이라는 셈법에는 업그레이드 트레드밀 비용이 빠져 있다는 점을 알고 골라야 합니다. 참고로 OpenBao도 영원한 무료 지원을 약속하는 조직이 아니라 OpenSSF 산하 커뮤니티 프로젝트입니다 — 2025-2026 로드맵 기준 지난 1년 커밋 741건, 기여자 287명(프로젝트 자체 집계)이 지속가능성의 전부입니다. 벤더 SLA가 필요한 조직이라면 그건 그것대로 냉정하게 봐야 합니다.

그래서 무엇을 골라야 하나

도구 비교 일반론은 시크릿 관리 도구 정리 편에 있으니, 여기선 이 포크 구도에 한정해 정리합니다.

OpenBao가 실질 후보인 경우

BUSL/벤더 종속이 조직 정책상 걸림돌이고, 스토리지가 Raft(또는 PostgreSQL)로 수렴 가능한 경우
멀티테넌시(네임스페이스)가 필요한데 Enterprise 라이선스 비용이 정당화되지 않는 경우 — 이 기능 격차 하나가 포크로 넘어갈 충분한 이유가 되는 조직이 실제로 있습니다
Kubernetes·JWT·PKI·KV·Transit 중심의 워크로드 — 이 경로는 코어에 다 있고, CEL 정책·자기 초기화처럼 업스트림에 없는 운영 편의까지 붙습니다

Vault에 남는 게 맞는 경우

다중 클러스터 복제(performance/DR)가 필요한 경우 — OpenBao에 대응물이 없습니다
AWS·Azure·GCP 동적 크리덴셜이 핵심 경로인 경우 — OpenBao에선 외부 플러그인 의존이 되고, 운영 부담과 성숙도 리스크를 스스로 져야 합니다
벤더 지원 계약과 LTS가 감사·규제 요건인 경우 — 그 요건 자체가 Enterprise 구매 사유입니다

어느 쪽이든 하지 말아야 할 것 — "API 호환이니 드롭인"이라는 가정. 스토리지 백엔드, seal 설정, 플러그인 구성이 다르고, OpenBao의 v2.7.0 폐기 일정까지 겹치면 이주는 드롭인이 아니라 프로젝트입니다. 이주 여부와 무관하게, 양쪽 릴리스 노트의 DEPRECATIONS와 SECURITY 섹션을 분기마다 읽는 것이 이 도메인의 최소 방어입니다.

마치며

포크 2년 차의 그림은 이렇게 요약됩니다. OpenBao는 Enterprise 전용이던 네임스페이스·HSM 언실·읽기 스케일링을 오픈소스로 가져왔고, v2.6.0의 네임스페이스 봉인처럼 업스트림에 없는 기능을 먼저 내기 시작했습니다. 동시에 코어를 공격적으로 덜어내서, Vault와의 표면적 호환성 아래에 실질적인 비호환 — 스토리지, 클라우드 엔진, seal — 을 쌓고 있습니다. Vault는 IBM 소유가 라이선스 파일 단위로 확정됐고, 2.0으로 번호를 올리며 CE 사용자에게는 최신 마이너 추적을, 장기 지원이 필요한 조직에는 Enterprise를 요구하는 구조를 유지합니다.

양쪽 다 합리적인 선택지가 되는 조직이 각각 존재합니다. 다만 이 공간의 글은 대부분 어느 한쪽의 이해관계 위에서 쓰입니다 — 이 글이 링크한 원문들처럼, 판단 근거를 릴리스 노트와 커밋으로 내려서 직접 확인하시길 권합니다.