OPA는 지금 누가 유지하는가 — Styra 팀 Apple 합류, 그 후 11개월의 검증 가능한 기록

• 들어가며 — "Apple이 OPA를 인수했다"는 어디까지 사실인가
• 2025년 8월 20일, 공지의 정확한 내용
• 그래서 인수였나 — 확인 가능한 것과 불가능한 것
• 그 후 11개월, 릴리스는 멈추지 않았다
• Styra 도구들의 서로 다른 운명
• 거버넌스 산수 — 메인테이너 전원이 한 회사 소속이 되면
• open core 사용자가 이 사건에서 점검할 것
• 그래서 당신은 무엇을 해야 하나
• 마치며
• 참고 자료

들어가며 — "Apple이 OPA를 인수했다"는 어디까지 사실인가

2025년 8월 말, 인가(authorization) 스택에 OPA를 깔아 둔 팀들 사이에 소문이 돌았습니다. "Apple이 Styra를 인수했다", "OPA가 Apple 것이 됐다". 정책 엔진은 한번 깔면 인프라 깊숙이 박히는 물건이라, 이런 소문은 대충 넘기기 어렵습니다. 그런데 이 문장들은 정확하지 않습니다 — 그리고 어디가 어떻게 부정확한지가 실무자에게는 중요합니다.

이 글의 사실관계는 전부 1차 소스로 확인했습니다. OPA 공식 블로그의 공지 원문, GitHub API로 조회한 릴리스·커밋·저장소 메타데이터, 저장소의 MAINTAINERS.md와 GOVERNANCE.md 원문, 그리고 공용 DNS 리졸버 조회 결과(2026-07-17 기준)입니다. 소문 채점부터 시작해서, 11개월이 지난 지금 OPA가 실제로 어떤 상태인지까지 기록합니다.

2025년 8월 20일, 공지의 정확한 내용

공지는 Apple이 아니라 OPA 블로그에서 나왔습니다. Note from Teemu, Tim, and Torin to the Open Policy Agent community — OPA를 만든 사람들 명의의 글이고, 날짜는 2025년 8월 20일입니다. 요점은 이렇습니다.

• OPA 창시자들과 Styra 팀원 다수가 Apple에 합류한다.
• Apple은 이미 대규모 OPA 사용자다 — 글로벌 클라우드 서비스들의 인가 인프라 핵심 컴포넌트로 쓰고 있다고 공지에 명시돼 있습니다.
• OPA는 CNCF 졸업 프로젝트로 남고, 프로젝트 거버넌스와 라이선스에는 변화가 없다.
• 메인테이너 목록도 그대로 유지되며, 바뀌는 것은 해당 메인테이너들의 소속 표기(Styra에서 Apple로)뿐이다.
• Styra GitHub에 있던 도구들 — 상용 배포판 EOPA, OPA Control Plane, 각종 SDK(TypeScript, React, C#, Java 등), Rego 린터 Regal — 은 CNCF의 OPA GitHub 조직으로 옮기는 커뮤니티 프로세스를 시작한다.
• 웹사이트는 CNCF와 커뮤니티가, Rego Playground는 Styra가 계속 운영한다.
• 월간 릴리스 일정을 유지하고, 2025년 로드맵(언어 확장, 타입 체킹, 툴링, 부분 평가, 성능, 결정 로그)을 계속 진행한다.

주목할 점 하나. 이 공지 어디에도 "인수"라는 단어가 없습니다. 회사가 회사를 샀다는 이야기가 아니라, 사람들이 이직했다는 이야기입니다.

그래서 인수였나 — 확인 가능한 것과 불가능한 것

언론 보도를 원문으로 확인해 보면 표현이 더 분명합니다. Cloud Native Now의 기사는 Apple이 Styra 공동창업자 Tim Hinrichs와 Torin Sandall, 그리고 시니어 엔지니어들을 채용했지만 회사나 그 자산을 인수하지는 않았다고 썼고, 이를 "인수 없는 애퀴하이어"라고 불렀습니다. 이 건에 대한 Apple 명의의 별도 발표는 확인되지 않습니다.

그 후 Styra라는 회사에 어떤 일이 있었는지는 공식 문서로 남아 있지 않습니다. 다만 관측 가능한 사실은 있습니다. 이 글을 쓰는 2026년 7월 17일 기준으로:

• styra.com은 공용 리졸버(1.1.1.1, 8.8.8.8)에서 A 레코드와 NS 레코드 조회가 모두 SERVFAIL을 반환합니다. 도메인 웹사이트가 사실상 사라진 상태입니다.
• github.com/StyraInc 조직 페이지는 404입니다. 옛 StyraInc/regal 같은 주소는 open-policy-agent 조직의 저장소로 리다이렉트됩니다.
• 회사의 법적 상태(청산 여부 등)에 대한 공식 발표는 찾지 못했습니다. 모르는 것은 모른다고 적는 편이 정확합니다.

한편 사람들이 Apple에서 OPA 관련 작업을 계속한다는 것은 공개 커밋 이력으로 직접 확인됩니다. 예컨대 open-policy-agent/swift-opa 저장소에는 공지 이후에도 창업 멤버가 Apple 소속 이메일로 커밋한 기록이 이어집니다. 참고로 이 저장소 자체는 공지보다 앞선 2025년 4월에 만들어졌고, Swift OPA 공개 글은 2025년 5월 14일에 올라왔습니다 — Apple 쪽의 OPA 활용은 8월 공지 전부터 진행형이었다는 정황입니다.

그 후 11개월, 릴리스는 멈추지 않았다

프로젝트가 죽었는지 살았는지는 말이 아니라 릴리스 기록이 답합니다. OPA 릴리스 목록에서 공지 이후 마이너 릴리스만 추리면 이렇습니다.

사이사이 패치 릴리스가 있고, 이 글 기준 최신은 v1.18.2(2026-07-02)입니다. 공지가 약속한 월간 케이던스는 문자 그대로 지켜지고 있습니다. 참고로 OPA 1.0.0이 2024년 12월 20일에 나왔으니, 1.x 시대 전체가 이 격변과 겹쳐 있는 셈인데 릴리스 흐름에서는 이음새가 보이지 않습니다.

내용도 유지보수용 땜질만은 아닙니다. 공지에 적힌 로드맵 항목 중 실제로 배로 나온 것들이 있습니다.

• v1.15.0 — 로거 플러그인 인터페이스와 로테이션 지원 파일 로거. 로드맵의 "로깅을 디스크로" 항목에 해당합니다.
• v1.17.0 — future.keywords.not 임포트로 Rego의 오래된 부정(negation) 시맨틱 문제를 개선. 로드맵의 언어 확장 항목 중 하나입니다.
• v1.18.0 — 컨테이너 인지 리소스 제한(GOMAXPROCS 복원, GOMEMLIMIT 지원), 그리고 브레이킹 픽스 하나: 아웃바운드 User-Agent 헤더가 RFC 9110 위반이어서 Open Policy Agent/버전 꼴에서 Open-Policy-Agent/버전 꼴로 바뀌었습니다. 이 문자열을 정확히 매칭하는 WAF 규칙이나 로그 필터가 있다면 수정이 필요합니다.

릴리스 노트의 기여자 목록에는 Apple 소속 메인테이너 외의 이름들도 계속 보입니다. 다만 "릴리스가 나온다"와 "프로젝트가 건강하다"는 같은 문장이 아니라는 점은 뒤의 거버넌스 절에서 다시 봅니다.

Styra 도구들의 서로 다른 운명

공지가 약속한 이관은 실제로 일어났습니다. 그런데 이관된 도구들의 그 후 궤적은 제각각입니다 — 여기가 이 사건에서 가장 배울 게 많은 부분입니다.

Regal — 산 것. Rego 린터 Regal은 open-policy-agent 조직으로 옮겨진 뒤에도 꾸준히 릴리스 중입니다. 최신 v0.42.0이 2026년 7월 16일 — 이 글 바로 전날입니다.

OPA Control Plane — 새로 자라는 것. opa-control-plane은 Git 저장소들에서 정책 번들을 빌드해 S3, GCS, Azure Blob 같은 오브젝트 스토리지로 배포하는 관리 컴포넌트입니다. 이관 후 첫 태그 v0.1.0이 2025년 11월 18일, 최신 v0.7.0이 2026년 6월 9일입니다. 아직 0.x라는 점은 그대로 읽으면 됩니다 — 이제 만들어지는 중입니다.

EOPA — 기증됐지만 멈춘 것. 데이터 헤비 워크로드용 상용 배포판이던 EOPA는 오픈소스로 기증됐고, 2025년 8월 28일 v1.43.0부터 11월 6일 v1.45.1까지 릴리스가 이어졌습니다. 그리고 멈췄습니다. 이후 의존성 범프 커밋만 간간이 있다가, 2026년 6월 26일 "아카이브 안내" 커밋과 함께 저장소가 아카이브됐습니다. README에는 코드를 자유롭게 가져다 쓰라는 말과 함께, 유지보수에 관심 있으면 OPA Slack으로 연락 달라는 안내가 남아 있습니다. 기증에서 아카이브까지 약 10개월 — 인수자가 나타나지 않은 겁니다.

그 외. Rego Playground는 오늘도 HTTP 200으로 응답합니다(공지 시점 기준 운영 주체는 Styra였는데, 현재 누가 운영하는지는 공식 문서로 확인되지 않습니다). SDK들도 이관 목록에 있었지만 개별 저장소의 활동 수준까지는 이 글에서 검증하지 않았습니다. 그리고 눈에 띄는 공백 하나 — Styra의 SaaS 관리 플레인이었던 DAS는 공지의 FAQ 목록에 아예 등장하지 않습니다. 상용 고객들에게 어떤 안내가 나갔는지는 styra.com이 사라진 지금 공개 소스로 확인할 방법이 없습니다.

거버넌스 산수 — 메인테이너 전원이 한 회사 소속이 되면

이제 불편한 부분입니다. 오늘자 MAINTAINERS.md를 읽으면, opa 저장소 영역을 담당하는 메인테이너 6명(Anders Eknert, Ash Narkar, Charlie Egan, Stephan Renatus, Tim Hinrichs, Torin Sandall)의 소속이 전원 Apple입니다. Gatekeeper 계열(constraints, gatekeeper 등)은 사정이 달라서 Google 소속 1명과 Microsoft 소속 3명이 담당하고, Microsoft 쪽 3명은 2026년 1월 30일자로 갱신 표기가 돼 있습니다.

GOVERNANCE.md는 조직 단위 투표(organizational voting)를 규정합니다 — 한 조직에 메인테이너가 몇 명이든 조직당 1표이고, 문서가 밝힌 취지는 어느 한 조직도 특정 영역을 지배하지 못하게 하는 것입니다. 그런데 산수를 해 보면, 현재 opa 영역에서 투표권을 가진 조직은 Apple 하나입니다. 안전장치는 형식적으로 남아 있지만, 견제할 상대 조직이 그 영역에 없습니다.

공정하게 덧붙이면, 이 집중은 새로 생긴 문제가 아닙니다. 같은 사람들이 어제까지는 Styra 소속이었으니, opa 영역이 사실상 한 회사에 몰려 있던 것은 Styra 시절에도 마찬가지였습니다. 바뀐 것은 그 회사의 성격입니다 — 정책 엔진을 팔아서 먹고사는 회사에서, 정책 엔진을 내부 인프라로 쓰는 회사로. 벤더는 오픈소스를 상용 제품의 깔때기로 유지할 유인이 있고, 대규모 사용자는 자기 인프라의 안정성을 위해 유지할 유인이 있습니다. 어느 쪽이 커뮤니티에 더 나은 구조인지는 단정할 수 없고, 지금까지의 11개월 데이터는 적어도 방치 시나리오를 지지하지 않습니다.

마지막 안전망은 프로젝트가 개인이나 회사가 아니라 재단에 있다는 사실 자체입니다. OPA는 2021년 2월 CNCF 졸업 프로젝트가 됐고, 코드는 Apache-2.0입니다. 최악의 시나리오에서도 포크와 승계가 법적으로 열려 있는 구조입니다 — HashiCorp 라이선스 전환 때 Vault에서 갈라져 나온 OpenBao가 그 경로의 실례이고, 그 이야기는 OpenBao v2.6 정리 글에서 따로 다뤘습니다. 거버넌스가 재단에 있었기 때문에 OPA는 포크 없이 이 격변을 통과했다는 점이, 두 사례의 대비에서 가장 도드라지는 부분입니다.

open core 사용자가 이 사건에서 점검할 것

EOPA의 궤적이 핵심 교훈입니다. 벤더가 사라질 때 상용 제품을 오픈소스로 풀어 주는 것은 분명 품위 있는 퇴장이지만, 오픈소스화는 코드의 생존을 보장할 뿐 제품의 생존을 보장하지 않습니다. 코드가 공개돼 있어도 유지보수할 사람이 나타나지 않으면 10개월 뒤 아카이브됩니다. 비슷한 처지의 도구를 쓰고 있다면 점검 목록은 이렇습니다.

• 지금 쓰는 스택에서 상용 전용 기능에 의존하는 부분을 목록화하세요. EOPA 사용자라면 데이터 필터링이나 DB 통합 기능이 여기 해당합니다.
• 프로젝트의 소유 구조를 확인하세요. 재단 소유(CNCF 등)인지 벤더 단독 소유인지에 따라 벤더 소멸 시나리오의 결과가 완전히 다릅니다. OPA가 이번에 큰 탈 없이 통과한 일차 요인이 이것입니다.
• MAINTAINERS 파일을 실제로 읽으세요. 메인테이너들의 소속 다양성은 공개 문서로 확인 가능한 리스크 지표입니다.
• 출구 비용을 미리 계산하세요. 정책 엔진은 교체 비용이 큰 축에 속합니다 — 정책 언어(Rego, Cedar, 관계 튜플)마다 이식이 사실상 재작성입니다.

그래서 당신은 무엇을 해야 하나

오픈소스 OPA만 쓰는 팀 — 당장 할 일은 없습니다. 릴리스 케이던스, 거버넌스 문서, 라이선스 모두 공지 전과 동일하게 유지되고 있습니다. 다만 지켜볼 지표는 있습니다: 월간 케이던스가 유지되는지, 비Apple 소속 기여와 신규 메인테이너 영입이 생기는지.

EOPA 기능에 의존하던 팀 — 결정이 필요합니다. 저장소는 아카이브됐고 Apache-2.0이므로 포크해서 직접 유지하는 것은 자유지만, 그 비용을 감당할 수 없다면 대안 이전 계획이 필요합니다. 업스트림 OPA가 EOPA의 기능을 전부 흡수한 것은 아니라는 점에 유의하세요.

Styra DAS로 OPA 플릿을 관리하던 팀 — 공지는 DAS를 언급하지 않았고, 같은 문제 공간(번들 빌드와 배포)을 다루는 것은 이관된 OPA Control Plane입니다. 다만 공식적으로 후계라고 선언한 문서는 없고, 버전도 아직 0.x입니다. 검증 없이 갈아탈 물건은 아직 아닙니다.

신규 도입을 검토하는 팀 — 이 사건 자체는 OPA를 피할 이유가 되지 못합니다. 오히려 재단 거버넌스의 가치가 실증된 사례에 가깝습니다. 엔진 선택은 여전히 문제 유형이 결정합니다 — 범용 정책 평가(OPA)인지, 관계 기반 인가(Zanzibar 계열)인지, 그 비교는 인가 엔진 딥다이브에서 정리했습니다. Kubernetes 어드미션 정책이 목적이라면 Kyverno와 OPA Gatekeeper 비교도 참고하세요 — 위에서 봤듯 Gatekeeper 영역은 Google과 Microsoft 메인테이너가 지키고 있습니다.

마치며

사실만 남기면 이렇습니다. 인수는 발표된 적이 없고, 이직이 있었습니다. 프로젝트는 재단에 있었고, 그래서 사람들의 고용주가 바뀌어도 거버넌스와 릴리스는 이어졌습니다. 상용 제품들은 오픈소스로 기증됐지만, 그중 린터는 살아남았고 상용 배포판은 10개월 만에 아카이브됐습니다 — 오픈소스화가 곧 지속 가능성은 아니라는 것을 같은 사건 안에서 동시에 보여 준 셈입니다.

"벤더가 사라지면 오픈소스 프로젝트는 끝"도 틀렸고, "오픈소스니까 무조건 안전"도 틀렸습니다. 갈림길은 소유 구조와 유지보수 유인이 어디에 있느냐였습니다. 당신의 스택에서 한 회사에 매달려 있는 컴포넌트가 무엇인지, 이번 기회에 MAINTAINERS 파일부터 열어 보시기를 권합니다.

참고 자료

• Note from Teemu, Tim, and Torin to the Open Policy Agent community (OPA 블로그, 2025-08-20)
• OPA 릴리스 목록 (GitHub)
• OPA MAINTAINERS.md (원문) / GOVERNANCE.md (원문)
• open-policy-agent/eopa — 기증 후 아카이브된 저장소
• Regal 릴리스 / OPA Control Plane 릴리스
• OPA v1.17.0 릴리스 노트 — future.keywords.not / v1.18.0 릴리스 노트 — User-Agent 브레이킹 픽스
• CNCF, OPA 졸업 발표 (2021-02-04)
• Apple Buys Styra Brains, OPA Remains Open (Cloud Native Now)
• Introducing Swift OPA (OPA 블로그, 2025-05-14)
• 인가 엔진 딥다이브 — FGA/Zanzibar 계열 비교 (관련 글)
• OpenBao v2.6 — Vault에서 갈라진 뒤 (관련 글)