한 줄 요약

Oracle이 20년 넘게 유지해 온 분기 Critical Patch Update(CPU) 체제 위에 매달 발행하는 Critical Security Patch Update(CSPU)를 얹었고, 그 첫 릴리스가 2026년 5월 28일에 나왔다.

분기 CPU는 그대로 1·4·7·10월에 누적본으로 나온다. CSPU는 그 사이 달에 셋째 화요일마다 끼어드는 소규모·고우선 전용 패치다. 첫 CSPU는 CVE 35건을 담았고, 그중 하나는 CVSS 10.0이었다. Oracle이 분기 리듬을 깨고 빠른 차선을 새로 낸 이유를 Oracle Security Blog의 공지와 운영자 관점에서 정리한다.

분기 CPU가 뭐였나

Oracle의 분기 CPU는 데이터베이스 운영자에게 익숙한 행사다. 매년 1·4·7·10월 셋째 화요일에, Oracle의 전 제품군에 걸친 보안 수정이 한 묶음으로 떨어진다. 한 번에 수백 건이 쏟아지는 게 특징이다 — 바로 직전인 2026년 4월 CPU만 해도 450건의 취약점을 한꺼번에 고쳤다.

이 모델의 핵심은 누적(cumulative)이라는 점이다. 가장 최신 CPU 하나에 그 이전의 모든 수정이 포함되므로, 운영자는 사실상 최신 CPU 한 개만 적용하면 된다. 관리가 단순하다는 장점은 분명하다.

문제는 주기다. 1월에 발표된 취약점을 표준 절차로 막으려면 4월 CPU까지 최대 석 달을 기다려야 한다. 그 석 달이 공격자에게는 그대로 열린 창이다.

월간 CSPU가 뭔가

CSPU는 그 창을 좁히는 장치다. 분기 CPU를 대체하지 않고 사이를 메운다.

  • 발행 주기: 분기 CPU가 없는 달의 셋째 화요일 — 2·3·5·6·8·9·11·12월
  • 성격: 전 제품군을 훑는 게 아니라, 즉시 대응이 필요하다고 Oracle이 판단한 소수 항목만 추린 묶음
  • 사전 예고: 각 CSPU 발행 직전 목요일(T-5)에 미리 공지

분기 CPU 4회와 CSPU 8회를 합치면, 운영자는 1년에 12번의 예측 가능한 패치 이벤트를 갖게 된다(Oracle). 사실상 월 1회 리듬이다.

flowchart TD
    JAN["1월 CPU
(누적·전 제품군)"]
    FEB["2월 CSPU"]
    MAR["3월 CSPU"]
    APR["4월 CPU
(누적·전 제품군)"]
    MAY["5월 CSPU
(첫 릴리스)"]
    JUN["6월 CSPU"]
    NEXT["7·10월 CPU
이후 동일 반복"]

    JAN --> FEB --> MAR --> APR --> MAY --> JUN --> NEXT

분기 CPU vs 월간 CSPU

둘은 목적이 다르다. 나란히 놓으면 역할이 분명해진다.

항목분기 CPU월간 CSPU
발행 시점1·4·7·10월 셋째 화요일2·3·5·6·8·9·11·12월 셋째 화요일
연간 횟수4회8회
범위전 제품군 전수고우선 항목만 선별
규모수백 건 (4월 450건)소규모 (5월 35건)
누적 여부누적 (최신본 하나면 됨)비누적 (개별 적용)
사전 예고발행 전 목요일발행 전 목요일

여기서 운영자가 놓치면 안 되는 한 가지가 있다. CSPU는 비누적이지만, 다음 분기 CPU가 그동안의 CSPU 수정을 모두 빨아들인다는 점이다. 즉 CSPU를 적용하지 않고 넘어갔더라도 다음 분기 CPU를 적용하면 그 사이 CSPU 수정이 따라온다 — 다만 그때까지 노출 창이 길어질 뿐이다.

5월 28일, 첫 CSPU의 내용

첫 CSPU는 새 CVE 35건을 담았다(Oracle Security Blog). 분기 CPU의 수백 건과 비교하면 의도적으로 작은 묶음이다. 제품군별 분포는 다음과 같다.

제품군패치 수
Oracle E-Business Suite12
Oracle REST Data Services (ORDS)11
Oracle Communications Unified Assurance8
Oracle Database Server3
Oracle Hospitality OPERA 51

심각도가 가볍지 않다. 가장 눈에 띄는 건 ORDS의 CVE-2026-46840으로, CVSS 10.0 만점이다 — 기밀성·무결성·가용성이 모두 완전히 무너지는 등급이다. E-Business Suite에도 CVSS 9.8~9.9급이 여러 건 있었고, Hospitality OPERA 5의 CVE-2026-34311은 9.8이었다.

작은 묶음이라고 가벼운 게 아니다. 오히려 분기까지 기다릴 수 없다고 Oracle이 판단한 항목만 골라 담았기 때문에, 평균 심각도는 분기 CPU보다 높다고 봐야 한다.

왜 분기에서 월간으로 갔나

여기가 이 블로그가 주목하는 지점이다. Oracle이 20년 넘게 지켜 온 분기 리듬을 굳이 깬 배경에는, 취약점이 발견되는 속도 자체가 달라졌다는 인식이 깔려 있다.

Oracle Database 업그레이드를 총괄하는 Mike Dietrich는 이 변화를 AI 기반 위협에 대한 대응으로 명시했다. 그는 AI 모델이 이전과 비교가 안 되는 속도로 취약점을 찾아내고 있으며, Oracle 자체도 Anthropic과 OpenAI의 모델을 취약점 탐지에 활용하고 있다고 밝혔다. 발견 속도가 빨라지면 노출 창을 그만큼 줄여야 한다는 게 그의 논리다.

이건 지난달 Copy Fail 글에서 다룬 흐름과 정확히 같은 줄기다. AI 코드 감사기가 10년 묵은 커널 버그를 한 시간 만에 찾아낸 사건은, 방어자에게 한 가지 사실을 분명히 했다. 오늘 멀쩡해 보이는 코드가 내일도 멀쩡할 거라고 가정할 수 없다는 것. 취약점이 더 빨리, 더 많이 드러나는 시대에는 패치 사이클도 그만큼 짧아져야 한다.

분기에서 월간으로의 전환은 그 압력에 대한 벤더 측 응답이다. 발견과 패치 사이의 간격을 구조적으로 좁히려는 시도다.

[과거] 분기 모델
  취약점 발견 ───────── 최대 3개월 ─────────▶ CPU 적용
                       (열린 창)

[현재] 월간 + 분기 모델
  취약점 발견 ─── 최대 1개월 ───▶ CSPU 적용
                  (좁힌 창)

운영자가 지금 해야 할 일

패치 주기가 4배로 잦아졌다는 건, 운영 부담도 그만큼 늘었다는 뜻이다. 12번을 모두 같은 속도로 따라가면 검증과 변경 관리가 무너진다. 차선을 나누는 게 핵심이다.

1) 패치 차선을 risk로 나눈다

모든 CSPU를 같은 속도로 처리할 필요는 없다. 인터넷에 노출된 ORDS·E-Business Suite처럼 공격 표면이 넓은 자산은 긴급 차선, 내부망 전용 DB는 표준 차선으로 분류한다. 5월 CSPU의 ORDS CVSS 10.0 같은 항목은 자산 분류와 무관하게 즉시 차선이다.

2) T-5 목요일 예고에 계획을 건다

Oracle이 발행 5일 전 목요일에 미리 알려 주므로, 화요일 발행을 기다리지 말고 목요일 예고로 영향 자산을 먼저 추린다. 발행 당일에 시작하면 이미 늦다.

3) 회귀 테스트를 가볍고 결정론적으로 만든다

월 1회 리듬에서는 매번 광범위한 수동 검증을 붙일 여유가 없다. 핵심 쿼리·배치·연동 지점만 자동으로 돌려 확인하는 최소 세트를 미리 갖춰 둬야 패치 주기를 따라갈 수 있다.

4) 우회책에 기대지 않는다

Dietrich의 표현을 빌리면, virtual patching처럼 임시방편에 의존하는 건 보안이 아니라 심리적 위안에 가깝다. 결국 정식 패치를 빠르게 적용할 수 있는 체계를 만드는 게 유일한 답이다.

왜 이게 중요한가

이번 변화의 의미는 단순히 “Oracle 패치가 잦아졌다"가 아니다. 보안 패치의 기본 단위가 분기에서 월로 바뀌는 흐름이 메이저 DB 벤더에서 시작됐다는 신호다.

Microsoft는 오래전부터 매달 둘째 화요일 Patch Tuesday를 돌려 왔다. 리눅스 배포판들은 CVE가 뜨면 며칠 안에 안정 커널을 내놓는다. 분기라는 긴 호흡을 고수하던 Oracle마저 월간 차선을 열었다는 건, AI가 취약점 발견 속도를 끌어올린 환경에서 분기 주기로는 더 이상 버틸 수 없다는 업계의 공통 인식에 합류했다는 뜻이다.

운영자에게 이 흐름의 결론은 명확하다. 패치를 분기에 한 번 몰아서 하는 행사가 아니라 상시로 도는 프로세스로 다시 설계해야 한다. CSPU는 그 전환을 강제하는 첫 신호다.

정리

  • Oracle이 분기 CPU에 더해 매달 셋째 화요일 CSPU를 발행하기 시작했다. 첫 릴리스는 2026년 5월 28일.
  • CSPU는 CPU를 대체하지 않고 사이 달을 메우는 소규모·고우선 패치다. 분기 CPU는 누적, CSPU는 비누적.
  • 첫 CSPU는 CVE 35건, ORDS의 CVSS 10.0(CVE-2026-46840)을 포함한 고심각도 항목 중심이었다.
  • 전환의 배경은 AI가 끌어올린 취약점 발견 속도 — 발견과 패치 사이 창을 구조적으로 좁히려는 응답이다.
  • 운영자는 패치를 분기 행사가 아니라 상시 프로세스로 재설계하고, risk 기준으로 차선을 나눠야 한다.

참고