
HashiCorp 가 Terraform 을 BSL 로 바꿨고, Redis 는 SSPL 로 갔다가 AGPL 로 돌아왔고, Elastic 도 같은 길을 먼저 걸었다. 잘 쓰던 라이브러리의 라이선스가 어느 날 바뀌는 일이 2023년 이후 반복되고 있다. 왜 이런 일이 계속 생기고, 의존성 목록에 이런 프로젝트가 있을 때 개발자는 뭘 해야 하나. 이 글의 답은 이렇다. 라이선스 변경은 배신이 아니라 클라우드 사업자가 만든 구조의 결과이고, 되돌린 사례가 둘이나 나온 지금 개발자가 볼 것은 라이선스 문구가 아니라 그 프로젝트를 누가 소유하는가다.
바꾼 회사 셋, 되돌린 회사 둘
HashiCorp 는 2023년 8월 10일 Terraform 1.6 부터 MPL 2.0 을 BSL 1.1 로 바꿨다. 소스는 볼 수 있지만 경쟁 서비스에 쓸 수 없는 라이선스다. 몇 주 안에 OpenTofu 포크가 나왔고, 9월 중순 리눅스 재단 산하로 들어갔으며, 2025년 4월에는 CNCF 프로젝트가 됐다. IBM 은 64억 달러에 HashiCorp 를 사들여 2025년 2월 27일 인수를 마무리했고, 그 뒤로 Terraform 의 라이선스와 로드맵 투명성에 대한 우려는 오히려 커졌다.
Redis 는 2024년 3월 BSD 를 버리고 SSPL 로 갔다. 같은 달 Valkey 포크가 시작됐고 AWS, 구글, 오라클이 붙어 리눅스 재단 아래 자리 잡았다. 그리고 2025년 5월 1일 Redis 는 Redis 8 부터 AGPL 을 다시 선택지에 넣었다. 창시자 살바토레 산필리포가 2024년 11월 돌아온 뒤의 결정이었다. Elastic 이 먼저였다. 2021년 AWS 와의 갈등으로 Apache 2.0 을 버렸던 Elastic 은 2024년 8월 29일 AGPL 을 추가하며 "다시 오픈소스"라고 선언했다. 창업자 셰이 배넌은 당시 이유를 이렇게 썼다. "AWS 와 그들의 서비스가 만드는 시장 혼란 때문에 문제가 있었고, 다른 모든 선택지를 시도한 뒤 라이선스를 바꿨다."

바꾸는 이유는 하나, 클라우드가 돈을 가져간다
세 회사의 사정은 같다. 오픈소스로 사용자를 모았는데, 그 사용자에게 돈을 받는 쪽은 관리형 서비스를 파는 클라우드였다. Elasticsearch 를 AWS 가 팔고, Redis 를 ElastiCache 가 팔고, Terraform 을 각종 플랫폼이 감쌌다. 개발한 회사는 지원과 기능 개발 비용을 지고, 매출은 남이 가져간다. 배넌의 말대로 "다른 모든 선택지를 시도한 뒤"의 결정이라는 걸 나는 믿는다. 이 회사들이 나쁜 게 아니라 허용적 라이선스와 하이퍼스케일러가 만나면 이 결과가 나온다.
레드몽크의 스티븐 오그레이디가 2026년 3월 25일 정리한 데이터가 이 흐름을 보여준다. 2014~2017년 사이 업계는 카피레프트에서 허용적 라이선스로 넘어갔고 2022년 허용적 라이선스 비중은 82% 까지 올라갔다. 그런데 2025년에는 73% 로 내려왔다. 허용적 라이선스로 클라우드에 당한 경험이 쌓이면서 추가 조건을 붙이는 쪽으로 되돌아오고 있다는 뜻이다. AGPL 이 그 타협점이다. OSI 승인 오픈소스이면서, 네트워크로 서비스하면 소스를 공개해야 하니 클라우드가 마음대로 감싸기 어렵다.
포크가 응징한다, 숫자로 보인다
되돌린 회사가 둘이나 나온 이유는 포크가 실제로 커뮤니티를 가져갔기 때문이다. 퍼코나가 2025년 12월 5일 낸 분석에 따르면 Redis 의 핵심 기여자 24명 중 9명이 라이선스 변경 후 기여를 멈췄다. 같은 기간 Valkey 의 기여자는 18개월 만에 18명에서 49명이 됐고, 2025년 월평균 PR 은 Redis 42개 대 Valkey 80개, 이슈는 24개 대 40개였다. 포크가 원본보다 활발해졌다. Redis 가 AGPL 로 돌아온 게 산필리포의 신념 때문인지 Valkey 때문인지는 알 수 없지만, 순서는 분명하다. 포크가 먼저 컸고 복귀가 뒤따랐다.
Terraform 도 비슷하다. IaC 플랫폼 Scalr 가 2026년 중반 자사 데이터로 집계한 바로는 실행의 63%, 신규 워크스페이스의 72% 가 OpenTofu 였다. 자사 고객 기준이라 업계 전체로 일반화하긴 어렵지만, 방향은 읽힌다. BSL 전환 3년 만에 포크가 신규 채택의 다수가 됐다.
반론: 그래도 회사는 먹고살아야 한다
라이선스를 바꾸지 않았으면 그 회사들은 어떻게 됐을까. 포크를 응원하는 쪽은 이 질문에 답을 잘 안 한다. 퍼코나 창업자 바딤 트카첸코조차 Redis 의 AGPL 복귀를 두고 "긍정적 방향이지만 이 라이선스의 실질적 제약을 알아야 한다"고 했다. AGPL 은 서비스로 배포하는 순간 소스 공개 의무가 생기므로, 기업 입장에선 BSL 만큼이나 부담스러울 수 있다. 오픈소스로 돌아왔다고 해서 자유롭게 쓸 수 있는 건 아니다.
이 반론은 맞다. 그래서 내 결론은 "라이선스를 바꾸는 회사를 쓰지 말라"가 아니다. 문제의 핵심은 라이선스 문구가 아니라 한 회사가 바꿀 수 있느냐다. Valkey 와 OpenTofu 는 리눅스 재단 소속이라 어느 회사도 혼자 라이선스를 바꿀 수 없다. Redis 와 Terraform 은 한 회사의 이사회가 결정한다. AGPL 로 돌아왔어도 그 구조는 그대로다. 한 번 바꾼 회사는 다시 바꿀 수 있다.
개발자가 할 일은 의존성 목록에 소유자 열을 추가하는 것이다
첫째, 의존성 라이선스 감사를 자동화한다. SBOM 을 뽑고 BSL, SSPL, ELv2 처럼 OSI 미승인 라이선스가 들어오면 CI 에서 경고하게 한다. 지금 쓰는 버전이 문제없더라도 다음 메이저에서 바뀔 수 있으니 버전 고정만으로는 부족하다.
둘째, 핵심 인프라 의존성에는 라이선스 열 옆에 소유자 열을 둔다. 재단 소속인지, 단일 벤더인지. 단일 벤더 프로젝트는 그 회사의 매출 구조까지 봐야 한다. 클라우드가 그 회사 제품을 관리형으로 팔고 있고 그 회사가 상장사라면, 라이선스 변경은 시간 문제다.
셋째, 새로 고를 때는 포크 쪽 기여 추이를 본다. 기여자와 PR 수가 원본을 넘어선 포크는 이미 사실상의 본류다. 라이선스는 문서이고, 커뮤니티는 실체다. 2023년 이후의 사례들이 가르친 건 그 둘이 갈릴 때 결국 실체가 이긴다는 것이다.
참고 자료
- 레드몽크, 2026년 오픈소스 라이선스 현황 (2026-03-25)
- 퍼코나, 라이선스 변경 후 커뮤니티 침식: 오픈소스의 힘을 정량화하다 (2025-12-05)
- The Stack, Redis 가 오픈소스로 돌아오다 (2025-05-01)
- Elastic 블로그, Elasticsearch 는 다시 오픈소스다 (2024-08-29)
- Scalr, OpenTofu vs Terraform (2026-09-04 갱신)
- Cloud Magazin, OpenTofu vs Terraform: IBM 인수가 인프라에 뜻하는 것 (2026-03-22)
- Encore, 2026년의 Terraform: IBM, OpenTofu, IaC 의 미래 (2026-01-22)
'IT' 카테고리의 다른 글
| Playwright intercepts pointer events 해결 (0) | 2026.09.14 |
|---|---|
| AI 반도체 거품 논쟁, 매출 1조 달러와 캡엑스 6천억 달러 사이 (0) | 2026.09.14 |
| Playwright 파일 업로드, input 없는 사이트 처리법 (0) | 2026.09.13 |
| 프론트엔드 프레임워크 2026, 시그널이 표준이 되고 논쟁은 끝났다 (0) | 2026.09.13 |
| 티스토리 이미지 업로드 URL 만료, 서명 주소를 저장하면 안 되는 이유 (0) | 2026.09.12 |