🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Cloudflare는 모든 고객이 자체 OAuth 애플리케이션을 만들 수 있도록 self-managed OAuth를 공개하면서, 이를 뒷받침하기 위해 동의·철회·보안 모델과 Hydra 기반 OAuth 엔진을 대규모로 업그레이드했다.

📌 핵심 요약

• Cloudflare는 웹의 상당 부분을 지원하는 플랫폼이지만, 고객과 개발자가 여러 외부 도구·서비스를 함께 사용한다는 점에서 자동화, CI/CD, 통합을 위한 API와 위임 접근 방식이 중요하다고 설명한다.
• 기존에도 Wrangler나 일부 파트너 통합에서 OAuth가 쓰였지만, 제3자 OAuth는 수동으로 온보딩된 소수 통합에만 제공되어 일반 개발자는 관리가 어렵고 위임 애플리케이션 흐름에 덜 적합한 API 토큰에 의존해야 했다.
• Cloudflare는 모든 고객에게 self-managed OAuth를 열기 전에 동의 화면, 대시보드 철회 기능, 앱 소유권 표시, 피싱 방지 요소를 개선하고, OAuth 남용 가능성을 줄이기 위한 보안 모델을 보강했다.
• 내부적으로는 Hydra 기반 OAuth 엔진을 1.X와 2.X로 순차 업그레이드했으며, 데이터베이스 마이그레이션, 잠금 문제, 스키마 변경, 토큰 갱신 동작, 블루-그린 전환, 철회 이벤트 재생 같은 운영 과제를 해결했다.
• 업그레이드 후 Cloudflare는 API P95 지연 시간, 메모리 사용량, Go 힙 할당, 고루틴 수, CPU 사용량이 개선되었다고 제시하며, 이 기반 위에서 2026년 6월 3일 self-managed OAuth를 모든 고객에게 공개했다.

🧩 주요 포인트

1. Cloudflare는 웹의 상당 부분을 지원하는 플랫폼이지만, 고객과 개발자가 여러 외부 도구·서비스를 함께 사용한다는 점에서 자동화, CI/CD, 통합을 위한 API와 위임 접근 방식이 중요하다고 설명한다.
2. 기존에도 Wrangler나 일부 파트너 통합에서 OAuth가 쓰였지만, 제3자 OAuth는 수동으로 온보딩된 소수 통합에만 제공되어 일반 개발자는 관리가 어렵고 위임 애플리케이션 흐름에 덜 적합한 API 토큰에 의존해야 했다.
3. Cloudflare는 모든 고객에게 self-managed OAuth를 열기 전에 동의 화면, 대시보드 철회 기능, 앱 소유권 표시, 피싱 방지 요소를 개선하고, OAuth 남용 가능성을 줄이기 위한 보안 모델을 보강했다.
4. 내부적으로는 Hydra 기반 OAuth 엔진을 1.X와 2.X로 순차 업그레이드했으며, 데이터베이스 마이그레이션, 잠금 문제, 스키마 변경, 토큰 갱신 동작, 블루-그린 전환, 철회 이벤트 재생 같은 운영 과제를 해결했다.
5. 업그레이드 후 Cloudflare는 API P95 지연 시간, 메모리 사용량, Go 힙 할당, 고루틴 수, CPU 사용량이 개선되었다고 제시하며, 이 기반 위에서 2026년 6월 3일 self-managed OAuth를 모든 고객에게 공개했다.

🧠 상세 정리

1. Cloudflare 생태계에서 OAuth를 확대해야 했던 배경

Cloudflare는 자사 서비스가 웹의 약 20% 운영을 돕고 있지만, 개발자들이 Cloudflare만 사용하는 것은 아니라고 설명한다. 플랫폼 사용자는 여러 회사의 도구와 서비스를 함께 조합하며, Cloudflare API는 자동화, CI/CD, 인프라 통합을 연결하는 역할을 한다. 이 맥락에서 OAuth는 고객이 애플리케이션에 범위가 제한된 접근 권한을 부여할 수 있게 하는 핵심 흐름으로 제시된다. 그러나 기존에는 Wrangler나 PlanetScale 같은 일부 파트너 통합에서만 널리 경험할 수 있었고, 일반 개발자가 자유롭게 제3자 OAuth 통합을 만들기에는 접근성이 제한되어 있었다.

2. API 토큰 중심 방식의 한계와 self-managed OAuth의 필요성

기존 제3자 OAuth는 소수의 수동 온보딩 파트너에게만 제공되었기 때문에, 자체 통합을 만들려는 개발자들은 API 토큰에 의존해야 했다. 원문은 API 토큰이 관리하기 더 어렵고, 위임된 애플리케이션 흐름에는 잘 맞지 않는다고 지적한다. Cloudflare는 지난 1년 동안 초기 파트너를 늘리면서 동의, 철회, 보안 모델을 개선했고, 개발자 플랫폼이 성장하며 에이전틱 도구의 위임 접근 수요도 커졌다고 설명한다. 그 결과 모든 고객에게 OAuth를 개방하는 것이 플랫폼 성공에 중요하다는 판단에 이르렀다.

3. 동의·철회·소유권 표시를 강화한 보안 확장

Cloudflare는 기존 OAuth 솔루션이 제한된 파트너를 대상으로 할 때는 충분했지만, 모든 고객에게 열기에는 권한 모델, 동의 경험, 남용 완화 방식이 성숙하지 않았다고 평가했다. 이에 따라 접근을 요청하는 애플리케이션이 무엇인지, 어떤 권한을 받는지 더 명확하게 보여주도록 동의 경험을 개선했다. 또한 대시보드에서 애플리케이션 접근 권한을 쉽게 철회할 수 있게 했고, 앱 소유권을 더 잘 드러내 OAuth 피싱 공격을 방지하려 했다. self-managed OAuth 공개는 단순한 기능 출시가 아니라, 사용자 통제권과 보안 가시성을 강화하는 작업을 포함했다.

4. Hydra 1.X 업그레이드 계획과 데이터베이스 마이그레이션 문제

Cloudflare OAuth의 내부 엔진은 오픈소스 OAuth 엔진인 Hydra를 기반으로 하고 있었고, 초기 사용량이 제한적이던 시기에는 기존 배포가 충분히 역할을 했다. 하지만 개발자 플랫폼이 성장하고 에이전틱 워크플로가 늘어나면서 성능 개선과 새 기능을 위해 대규모 업그레이드가 필요해졌다. Cloudflare는 한 번에 큰 업그레이드를 하기보다 최신 1.X 릴리스로 먼저 올린 뒤, 동작과 성능 변화를 확인하고 2.X로 넘어가는 순차 전략을 택했다. 이 과정에서 인덱스 생성이 중요 테이블에 독점 잠금을 걸 수 있고, 컬럼 추가와 테이블 이동이 필요하며, 기존 Hydra SDK의 SELECT * 동작이 스키마 변경과 충돌할 수 있다는 문제가 드러났다.

5. 마이그레이션 충격을 줄이기 위한 SQL 재작성과 맞춤 Hydra

사용자 영향을 막기 위해 Cloudflare는 기본 마이그레이션을 그대로 실행하지 않고 SQL을 다시 작성했다. 예를 들어 중요 테이블 잠금을 줄이기 위해 CREATE INDEX CONCURRENTLY 같은 기능을 사용했으며, 기존 SDK의 SELECT * 동작 대신 명시적 컬럼을 선택하도록 커스텀 Hydra 버전을 만들었다. 이는 단순히 새 버전을 배포하는 문제가 아니라, 운영 중인 OAuth 시스템에서 인증과 토큰 흐름이 끊기지 않도록 데이터베이스 작업 방식을 조정하는 과정이었다. 원문은 1.X 업그레이드부터도 고객에게 영향을 줄 수 있었기 때문에, 사용자 중단을 최소화하면서 데이터 안정성과 보안을 유지하는 계획이 필요했다고 설명한다.

6. 2.X 업그레이드를 위한 블루-그린 전략과 철회 이벤트 보존

Hydra 2.X 업그레이드는 스키마 변경 규모가 커서 인플레이스 업그레이드가 적합하지 않다고 판단되었다. Cloudflare는 블루-그린 전략을 선택했지만, 마이그레이션이 여러 시간 걸리는 동안 시스템이 계속 올바르게 동작해야 했기 때문에 단순한 전환 이상의 준비가 필요했다. 쓰기를 완전히 막으면 새 인증이 불가능하고, 특히 사용자가 애플리케이션 접근 권한을 철회해야 할 때 이를 처리할 수 없는 문제가 생긴다. 이를 피하기 위해 토큰 만료 시간을 여러 시간으로 늘려 새 토큰 쓰기 수를 줄이고, Cloudflare Queues를 사용해 업그레이드 창 동안 발생한 철회 이벤트를 기록한 뒤 green 데이터베이스로 전환 후 재생하는 방식을 마련했다.

7. 1.X 업그레이드 실행과 refresh token 오류 대응

1.X 업그레이드는 운영 관점에서는 큰 문제 없이 진행되었고, 커스텀 데이터베이스 마이그레이션도 예상보다 빠르게 실행되었으며 사용자 영향은 없었다고 설명된다. 다만 이전 버전이 새 버전에서 생성한 토큰을 introspect할 수 없었기 때문에 하드 컷오버가 필요했다. 컷오버 이후에는 기존에 보지 못했던 refresh token 오류가 증가했는데, 새 버전의 더 엄격한 refresh invalidation 동작 때문에 재사용된 refresh token이 전체 access token과 refresh token 체인을 무효화했기 때문이었다. Cloudflare는 OAuth 트래픽을 라우팅하는 Worker에 refresh token coalescing 동작을 추가해 재시도를 짧게 캐시하고, 토큰 전체 무효화를 피하도록 완화했다.

8. 2.X 업그레이드 실행, 데이터 정리 문제, 성능 개선

2.X 업그레이드에서는 철회 재생 큐 활성화, 데이터베이스 복사와 복원, 새 제약 조건을 위반하는 기존 데이터의 정리, Hydra 서비스와 두 개의 내부 핵심 시스템 동시 전환, 전환 후 모니터링과 검증이 필요했다. Cloudflare는 요청량이 가장 낮은 시간대를 골라 업그레이드를 수행했고, 프로덕션 마이그레이션의 순수 실행 시간은 약 3시간이었다. 전환 직후 authorization service의 데이터 정리 작업이 OAuth 정책 데이터를 과도하게 삭제하는 문제가 관찰되었고, 조사 결과 일부 유효 OAuth 세션 상태가 Hydra 마이그레이션 문제로 손상되어 403 증가로 나타났다. Cloudflare는 데이터 복원을 수행하고 정적 정책 데이터 의존도를 줄이는 개선을 진행했으며, 최종적으로 API P95는 185ms에서 101ms로, CPU는 1.07코어에서 0.67코어로 낮아지는 등 성능과 안정성이 개선되었다고 제시한다.

🧾 핵심 주장 / 시사점

• 이 글의 핵심은 OAuth 공개 자체보다, 모든 고객에게 열 수 있을 만큼 동의·철회·소유권·마이그레이션 안정성을 먼저 갖추는 과정에 있다.
• 사용자 철회 이벤트를 업그레이드 중에도 잃지 않도록 큐에 기록하고 전환 후 재생한 점은, 위임 접근 시스템에서 보안 상태 보존이 가용성만큼 중요하다는 점을 보여준다.
• Cloudflare는 대규모 버전 업그레이드를 한 번의 전환으로 처리하지 않고 1.X와 2.X로 나누어 진행했으며, 각 단계에서 발견된 토큰 동작과 데이터 정합성 문제를 운영 계층에서 완화했다.

✅ 액션 아이템

• 동의 화면, 대시보드 철회, 앱 소유권 표시, 피싱 방지 기능을 self-managed OAuth 흐름 기준으로 정합성 점검한다.
• Hydra 1.X→2.X 업그레이드에서 확인된 DB 마이그레이션, 잠금, 스키마 변경, 토큰 갱신 동작 이슈를 운영 로그로 추적한다.
• API P95 지연, 메모리 사용량, Go 힙 할당, 고루틴, CPU 개선 수치가 self-managed OAuth 공개 후 실제 운영 지표에 반영되는지 점검한다.

❓ 열린 질문

• 기존 제3자 OAuth의 수동 온보딩 제한에서 벗어나 self-managed OAuth가 가장 먼저 효율을 높일 통합 분야는 어디인가?
• 동의·철회·보안 모델 강화가 OAuth 남용 가능성 축소에 실질적으로 어떤 지표를 통해 판단 가능한가?
• Hydra 블루-그린 전환과 철회 이벤트 재생 설계를 반복 적용할 때 운영 중단과 누락 리스크는 어떻게 통제할 수 있을까?