Apache Hive 지원 종료: 버전, 일정 및 향후 조치

이 블로그 글의 AI 요약으로 바로 가기

주요 내용

Apache Hive 1.x, 2.x 및 3.x는 모두 지원 종료되었습니다. 현재 커뮤니티 릴리스는 4.x 계열에서만 제공되며, 현재 최신 버전은 4.2.0입니다.
EOL(지원 종료) 상태의 Hive 버전에서는, Hive 및 번들로 제공되는 종속 라이브러리에서 새로 공개된 CVE에 대해 해당 버전에 대한 커뮤니티 차원의 수정 사항이 제공되지 않습니다. 여기에는 가장 민감한 테이블의 위치를 파악하고 이에 대한 액세스를 관리하는 메타데이터를 보관하는 Hive 메타스토어도 포함됩니다.
지원되지 않는 데이터 웨어하우스 소프트웨어는 구체적인 감사 리스크를 초래합니다. PCI DSS 요구사항 12.3.4는 이를 문서화되고 고위 경영진의 승인을 받은 시정 조치 항목으로 규정하며, HIPAA, SOC 2 및 ISO/IEC 27001은 모두 입증 가능한 정상적으로 작동하는 취약점 관리 프로세스를 요구합니다.
앞으로 나아갈 수 있는 세 가지 현실적인 방안은 다음과 같습니다. Hive 4.2.0으로 현장에서 업그레이드하거나, Hive를 완전히 대체하거나, 타사 CVE 패치를 확보하여 통제된 마이그레이션 기간을 확보하는 것입니다.

운영 환경에서 Apache Hive 2.3 또는 3.1을 사용 중이라면, 해당 버전에 대한 커뮤니티 보안 패치 제공은 2024년에 중단되었습니다. 2.x 버전의 경우 5월 20일, 3.x 버전의 경우 10월 8일에 제공이 종료되었습니다. 커뮤니티는 1.x, 2.x, 3.x 버전이 지원 종료로 공식 선언했으므로, 이제 새로운 커뮤니티 릴리스와 수정 사항은 4.x 계열에서만 제공됩니다.

이는 대부분의 라이브러리보다 Hive에 있어 더 중요한 문제입니다. Hive는 데이터 웨어하우스 데이터(개인 식별 정보, 재무 기록, 의료 데이터 등 모든 데이터) 위에 구축된 SQL 및 메타데이터 계층이며, Hive 메타스토어는 해당 데이터의 위치와 접근 권한을 가진 사용자에 대한 정보를 담고 있습니다. 이 글에서는 지원되지 않는 버전이 무엇인지, 실제 보안 및 규정 준수 위험이 어떤 모습인지, 그리고 진지하게 고려해야 할 세 가지 해결 방안을 다룹니다.

아파치 하이브의 지원 종료 시점이 도래했나요? 버전 및 날짜

네. 아파치 하이버(Apache Hive) 커뮤니티는 는 1.x, 2.x, 3.x 계열에 대해 지원 종료(EOL)를 선언하기로 투표했습니다. 이는 해당 버전들에 대해 더 이상 커뮤니티 릴리스, 버그 수정 또는 보안 패치가 제공되지 않음을 의미합니다.

특정 라인이 EOL로 선언되면 해당 릴리스 스트림은 중단됩니다. ASF에서는 유료 연장 서비스를 제공하지 않으며, 보안 전용 유지보수 기간도 없습니다.

또한 4.x 계열의 동작 방식도 주목할 만합니다. 수정 사항은 백포트되지 않고 최신 마이너 릴리스에 바로 반영됩니다. CVE-2025-62728은 4.2.0에서 수정되었으며 4.1.x로 백포트된 적이 없으므로, “4.x에서”와 “패치됨”은 같은 의미가 아닙니다.

출시 라인	상태	최종 / 최신 버전	참고 사항
Hive 1.x	Lifecycle 종료	1.2.2 (2017년 4월 7일)	2024년 4월 11일에 단종(EOL)이 발표되었습니다.
Hive 2.x	Lifecycle 종료	2.3.10 (2024년 5월 9일)	2024년 5월 20일에 EOL이 선언되었습니다.
Hive 3.x	Lifecycle 종료	3.1.3 (2022년 4월 8일)	2024년 10월 8일에 EOL이 선언되었습니다.
Hive 4.0.x	대체됨; EOL 투표 결과 미공개	4.0.1 (2024년 10월 2일)	마지막 줄에 Java 8로 표시되어 있습니다. 유용한 중간 단계이지만, 더 이상 수정 사항이 제공되지 않습니다.
Hive 4.1.x	‘활성’ 상태, ‘현재’ 상태가 아님	4.1.0 (2025년 7월 31일)	Java 17; HMS도 독립형 구성 요소로 제공됨
Hive 4.2.x	최신 버전	4.2.0 (2025년 11월 23일)	최소 지원 버전으로 Java 21

참고: Hive 4.x 업그레이드는 오직 앞으로만 진행하는 작업으로 계획하십시오. Apache는 MySQL, PostgreSQL, Oracle, SQL Server 및 Derby용 스키마 업그레이드 스크립트를 제공하지만, 문서화된 다운그레이드 경로는 없으므로 롤백 계획은 이전 바이너리를 재설치하는 대신 메타스토어 데이터베이스 백업을 복원하는 것입니다. 실제로 필요해지기 전에 해당 복원 절차를 테스트해 두십시오.

프로덕션 환경에서 지원 종료(EOL)된 Apache Hive를 실행할 때의 보안 위험

Hive의 CVE는 일반적인 라이브러리 CVE와는 다릅니다. Hive 브로커는 개인 식별 정보(PII), 금융 거래 내역 및 의료 기록에 대한 접근 권한을 가지고 있으며, 메타스토어에는 이 모든 정보에 대한 매핑 정보가 저장되어 있습니다.

취약점이 EOL(지원 종료) 제품군에 영향을 미치는 경우, 해당 제품군에 대한 새로운 릴리스는 더 이상 제공되지 않으므로, 취약점을 완화하거나, 직접 수정 사항을 이전 버전으로 적용하거나, 타사 패치를 구매하는 것 외에는 선택지가 거의 없습니다.

메타스토어의 취약점이 왜 각별한 주의를 요하는가

메타스토어에 접근한 공격자는 전체 데이터 웨어하우스에 대한 액세스를 중개하는 구성 요소인 메타스토어 서비스의 권한으로 코드를 실행할 수 있습니다. HMS에는 역직렬화 및 인젝션 취약점이 발견된 사례가 문서화되어 있습니다.

파티션 가져오기(partition-fetch) 역직렬화 취약점 CVE-2022-41137(HIVE-26539)은 임의의 데이터 역직렬화를 허용하여 원격 코드 실행(RCE)으로 이어질 수 있었습니다. Apache는 이 취약점을 ‘중간(moderate)’ 수준으로 평가했으며, 영향을 받는 범위를 4.0.0 이전 버전의 4.0.0-alpha-1로 한정했기 때문에, 이 취약점은 일반 공개(GA) 릴리스에 포함된 적이 없으며 1.x, 2.x, 3.x 버전에도 영향을 미치지 않았습니다. 이 내용은 해당 구성 요소에 대한 정보로만 참고하시기 바라며, 귀하의 지원 종료(EOL) 버전과는 무관합니다.

최근 CVE-2025-62728을 통해 SQL 인젝션 취약점이 발견되었습니다. 이 문제는 4.1.0부터 4.2.0까지의 버전에 영향을 미쳤으며 4.2.0에서 수정되었습니다. 다시 말해, 이는 지원 종료(EOL) 버전의 결함은 아니지만, HMS에서 여전히 심각한 취약점이 지속적으로 발견되고 있으며 모든 수정 사항이 새로운 릴리스 형태로 제공된다는 사실을 보여주는 사례입니다.

아파치(Apache)는 또한 `metastore.try.direct.sql`이 false로 설정되어 있을 경우 해당 취약점 경로에 접근할 수 없다고 언급하고 있는데, 이는 지원 종료(EOL)된 버전에서도 여전히 적용할 수 있는 완화 조치 중 하나입니다. 심각도 라벨은 대충 훑어보기보다는 주의 깊게 읽어볼 가치가 있습니다. ASF의 “중간(moderate)” 등급과 CVSS 기본 점수는 동일한 발견 사항에 대해 서로 다른 방향을 가리킬 수 있기 때문입니다. 그 이유는 다음과 같습니다. CVE와 CVSS 점수 산정 방식 이 어떻게 작동하는지 설명해 드립니다.

주의: 여러 HMS CVE는 권한이 있는 사용자만 악용할 수 있는 것으로 기록되어 있으며, 아파치(Apache) 측의 자체 평가에 따르면 대부분의 배포 환경에서 HMS는 HiveServer2와 같은 소수의 애플리케이션에만 노출되어 있습니다. 이를 자동적으로 안전하다고 해석해서도 안 되며, 자동적으로 우려할 만한 상황이라고 해석해서도 안 됩니다. 실제로 영향을 받는 Thrift 메서드를 호출할 권한이 있는 사용자와 애플리케이션이 무엇인지, 해킹당한 HiveServer2가 해당 대상에 접근할 수 있는지, 그리고 `metastore.try.direct.sql`이 활성화되어 있는지 확인하십시오. 권고문의 문구가 아니라, 그 확인 결과를 통해 노출 여부를 판단해야 합니다.

모든 컴포넌트 뒤에는 고정된 종속성 트리가 있다

Hive는 하나의 JAR 파일이 아닙니다. Hive는 방대한 구성 요소와 의존성 구조에 기반을 두고 있습니다: Apache Hadoop, Calcite, Tez, Thrift, DataNucleus, ORC, Parquet, Avro, Kryo, Jackson, Guava, 그리고 Log4j 기반 로깅 스택 등이 포함됩니다. 이들 중 어느 하나라도 심각한 CVE를 유발할 수 있습니다.

Log4Shell (CVE-2021-44228) 이 가장 대표적인 사례입니다. 이는 Hive의 버그는 아니었지만, 2021년 12월 이전에 빌드된 모든 Hive 2.x 및 3.x 배포판에는 해당 취약점 범위에 속하는 Log4j 2 릴리스가 포함되어 있었으며, 이를 해결하기 위해서는 번들로 제공된 해당 라이브러리를 교체해야 했습니다.

특정 배포 환경이 실제로 악용 가능했는지는 구성에 따라 달렸는데, 구체적으로는 공격자가 제어하는 데이터가 로그 문장에 기록되었는지 여부에 달려 있었지만, 어쨌든 문제 해결 작업은 Hive 운영자에게 맡겨졌다.

지원이 제공되는 제품 라인에서는 취약점이 있는 라이브러리를 업데이트한 새 릴리스가 제공됩니다. 반면, 지원 종료(EOL)된 제품 라인에서는 그러한 릴리스가 절대 제공되지 않으며, 유지보수가 중단된 배포판 내의 JAR 파일을 수동으로 패치해야만 합니다. 아파치 스트러츠(Apache Struts)의 패치 주기를 겪어본 팀이라면 이 문제의 본질을 잘 알고 있을 것입니다. 수정 사항은 항상 새 릴리스 형태로 제공되지만, 더 이상 릴리스를 배포하지 않는 제품 라인에서는 이를 적용할 방법이 전혀 없습니다.

결코 해결되지 않는 인증 정보 유출 및 권한 격차

바로 여기서 EOL Hive는 더 이상 이론에 그치지 않게 됩니다. CVE-2024-29869 – 아파치(Apache)에서 ‘중요(Important)’ 등급으로 분류되었으며 1.1.0부터 4.0.1까지의 버전에 영향을 미쳤던 – 이 취약점으로 인해 Hive는 기본적으로 644 권한이 설정된 임시 디렉터리에 자격 증명 파일을 작성했는데, 해당 디렉터리에 접근 권한이 있는 모든 로컬 사용자가 이 파일을 읽을 수 있었습니다. 이 문제는 4.0.1 버전에서 수정되었습니다. EOL 버전을 사용하는 모든 라인이 이 문제의 영향을 받으며, 이들 중 어느 것도 수정된 버전을 적용할 수 없습니다.

‘중요’ 등급으로 분류된 CVE-2024-23953 역시 마찬가지입니다. LLAP 서명기에서 서명 비교에 고정 시간이 적용되지 않아, 권한이 있는 사용자가 유효한 서명을 바이트 단위로 위조할 수 있었습니다. 이 취약점은 2.2.0부터 4.0.0까지의 버전에 영향을 미쳤으므로, 2.3.x와 3.1.x 모두 해당 범위에 포함됩니다.

또한 3.1.3 이전 버전의 권한 검증 취약점이 있는데, 이 취약점으로 인해 CREATE 및 DROP 함수 작업 시 권한 검증 단계가 생략되어, 권한이 부족한 사용자라도 사용자 정의 함수(UDF)를 조작하여 악성 JAR 파일을 참조할 수 있었습니다(CVE-2021-34538). 3.1.3 버전 사용자는 해당 취약점에 대한 수정 사항을 적용받았으므로, 이 문제는 2.x 및 그 이전 버전에서 가장 심각한 영향을 미칩니다.

종합해 보면, 이는 단일한 확실한 익스플로잇 체인이 아니라, 구버전에서 발생하는 두 가지 별개의 상시적 위험, 즉 무단 UDF 조작과 읽기 가능한 인증 정보를 설명하는 것입니다. 지원 종료(EOL) 제품군의 경우, 이 두 가지 위험은 영구적으로 존재합니다. 또한, 유지 관리되는 기준선이 없는 상태에서 이를 선별하는 과정은 실제 엔지니어링 시간을 소모하게 되며, 이 과정에서 진정한 취약점과 스캐너의 오탐을 구분해야 합니다.

EOL(지원 종료) 상태인 Apache Hive 실행으로 인해 영향을 받는 규정 준수 프레임워크

EOL Hive를 실행하면 기술적인 보안 문제가 거버넌스 및 감사 문제로 확대됩니다. 이는 많은 데이터 웨어하우스가 규제, 계약 또는 고객 보안 요구사항의 적용을 받는 정보를 처리하기 때문입니다.

감사관은 확인된 취약점이 문서화되고 효과적인 통제 수단을 통해 시정되거나 완화되고 있는지 평가하며, 지원되지 않는 구성 요소가 있을 경우 이를 입증하기가 더 어려워집니다. 규모 측면에서 보면, ‘IBM 2025년 데이터 유출 비용 보고서’ 에 따르면 전 세계 평균 침해 비용은 444만 달러이며, 그중 의료 분야가 742만 달러로 가장 높았습니다. 전 세계 수치는 전년 대비 약 9% 감소했으므로, 이를 위협이 점차 커지고 있다는 식의 맥락보다는 배경 정보로 인용해야 합니다.

PCI DSS

카드 소지자 데이터가 귀사의 Hive 환경에 저장되거나 이를 통해 처리되는 경우, 관련 Hive 및 Metastore 시스템은 PCI DSS 적용 범위에 포함될 가능성이 높습니다. 여기에는 두 가지 요구 사항이 적용됩니다.

요구사항 6.3.3은 중요 및 고위험 패치를 출시 후 1개월 이내에 적용할 것을 요구하고 있으나, 패치가 존재하지 않을 경우 이를 입증하기 어렵습니다. 2025년 3월 31일부터 완전히 평가 가능한 요구사항 12.3.4는 최소 12개월마다 하드웨어 및 소프트웨어를 검토하고, 각 기술에 대해 공급업체로부터 여전히 신속한 보안 수정 패치를 받고 있는지 확인하며, 지원 종료 공지를 문서화하고, 고위 경영진의 승인을 받은 시정 계획을 수립할 것을 요구합니다.

EOL Hive는 평가에서 자동으로 불합격 처리되지는 않지만, 경영진이 승인한 문서화된 취약점으로 기록되며, QSA가 Metastore 및 HiveServer2 호스트에서 이에 대한 후속 조치를 취하게 됩니다. 보완 통제가 유효한 대안이 될 수 있으나, 이는 특정 위험을 해결해야 하며, 일반적으로 실제 마이그레이션이 진행되는 동안 임시 조치로 간주됩니다.

HIPAA

Hive에서의 의료 분석은 HIPAA 보안 규정의 적용 범위에 속하는 ePHI를 의미하며, 이는 특정 제품 버전을 지정하기보다는 위험 분석과 합리적이고 적절한 보안 조치를 요구합니다. 보안 업데이트를 받을 수 없는 소프트웨어는 위험 분석에 명칭을 명시하고, 문서화된 완화 조치 및 마이그레이션 일정을 첨부해야 합니다. 이 규칙은 EOL(제품 수명 종료) 소프트웨어를 전면적으로 금지하지는 않지만, ePHI를 처리하는 구성 요소가 문서화되지 않았거나, 완화 조치가 취해지지 않았거나, 패치 적용이 불가능한 경우, 이는 평가 시점뿐만 아니라 이후 해당 구성 요소가 정보 유출의 근본 원인이 될 경우에도 취약한 상태입니다.

SOC 2 및 ISO/IEC 27001

SaaS 및 엔터프라이즈 공급업체의 경우, 고객이 요청하는 보고서는 바로 이러한 것들입니다. 양측 모두 제대로 작동하는 취약점 관리 프로세스를 기대합니다. 즉, 취약점 탐지 및 시정에 관한 ‘신뢰 서비스 기준(Trust Services Criteria)’을 통해 SOC 2를 충족하고, 부록 A의 통제 항목 8.8인 ‘기술적 취약점 관리’를 통해 ISO/IEC 27001:2022를 충족해야 합니다. 지원되지 않는 데이터 웨어하우스는 신뢰할 수 있는 보안 수정 사항의 출처가 없고, 문서화된 완화 조치가 없으며, 기한이 정해진 마이그레이션 계획이 뒷받침되지 않을 경우 해당 통제 수단의 효과를 약화시킵니다.

현실 점검: “내부 전용”이라는 사실만으로는 Hive가 감사 범위에서 자동으로 제외되지 않습니다. 시스템이 규제 대상 데이터를 저장, 처리하거나 이에 대한 접근 권한을 제공하는 경우, 해당 프레임워크와 문서화된 시스템 경계를 기준으로 이를 평가해야 합니다. 네트워크 배치 위치는 범위와 보완 통제에 영향을 미칠 수 있지만, 이것이 문제를 완전히 해결해 주지는 않습니다.

지원 종료(EOL)된 Apache Hive의 마이그레이션 과제

대부분의 팀은 이미 “그냥 Hive 4로 업그레이드하세요”라는 지시를 받았습니다. 하지만 이러한 조언은 필요한 작업량을 크게 과소평가한 것입니다. 2.x나 3.x 계열에서 4.x로 넘어가는 것은 단순한 버전 업그레이드가 아닙니다. 이는 JVM, 메타스토어, 그리고 Hive에 의존하는 하위 엔진 및 애플리케이션 전반에 걸친 체계적인 변경을 의미합니다.

자바 버전 변경

기존 Hive 2 및 3 환경은 일반적으로 Java 8에서 실행됩니다. 아파치(Apache)의 요구 사항 표에 따르면 Hive 4.1.x에는 Java 17이, 4.2.x에는 Java 21이 명시되어 있으며, Java 8이 명시된 마지막 버전은 4.0.1입니다. 따라서 JVM을 아직 업그레이드할 수 없는 경우, 4.0.1은 더 이상 수정 사항이 제공되지 않음에도 불구하고 실질적인 과도기적 단계가 됩니다.

4.2.0으로 완전히 업그레이드하면 Hadoop 노드 전반에 걸쳐 JVM을 변경해야 하며, UDF 코드와 동일한 런타임 환경에서 실행되는 모든 다운스트림 서비스도 이에 맞춰 변경해야 합니다. Java 8 바이트코드는 최신 JDK에서도 대개 문제없이 실행되므로, 실제 작업은 호환성 테스트에 있습니다. UDF와 지원 라이브러리는 제거된 모듈, 내부 JDK API, 반사(reflection) 액세스, 또는 17이나 21을 지원하지 않았던 라이브러리에 의존할 경우 작동하지 않게 됩니다. 이 과정을 겪어본 사람이라면 누구나 Java 8 EOL 또는 Java 11 EOL 을 경험해 본 사람이라면, JVM 전환이 대개 마이그레이션 과정에서 가장 시간이 오래 걸리는 단계가 된다는 사실을 잘 알고 있을 것입니다. 먼저 모든 UDF와 JVM에 의존하는 서비스를 파악한 다음, Hive 업그레이드와 별도로 Java 업그레이드를 단계적으로 진행하십시오.

메타스토어 스키마 및 ACID 테이블 마이그레이션

Hive 4는 메타스토어 스키마를 변경하므로, 지원되는 백엔드 데이터베이스에서 업그레이드 스크립트를 순서대로 실행해야 합니다. HMS가 EOL(지원 종료) 데이터베이스에서 실행되는 경우 – 이는 PostgreSQL 13, 2025년 11월 13일에 지원 종료된 버전)을 사용하는 팀들이 직면한 것과 동일한 문제입니다. 이 경우 두 가지 마이그레이션을 한 번에 수행해야 합니다.

ACID 테이블은 특별한 주의가 필요하며, 이 요구 사항은 버전에 따라 다릅니다. Apache Hive 3.0.0 릴리스 노트에 따르면, 마지막 주요 압축 이후 UPDATE, DELETE 또는 MERGE가 실행된 ACID 테이블 파티션은 업그레이드 전에 반드시 주요 압축을 수행해야 하며, 해당 압축이 시작되면 더 이상 UPDATE/DELETE/MERGE를 실행할 수 없고, 이를 준수하지 않을 경우 데이터 손상이 발생할 수 있다고 명시되어 있습니다. INSERT 결과만 포함된 테이블은 이 규정의 영향을 받지 않습니다. 2.x에서 4.x로 버전을 크게 건너뛰는 경우 이 경계를 넘게 되므로, 이 규칙을 보편적인 것으로 간주하기보다는 Hive 3 이전에 생성된 트랜잭션 테이블이 어떤 것인지 확인하십시오. 먼저 메타스토어 DB의 스냅샷을 생성하고, 사전 점검 단계로 압축을 실행한 후, 실제 운영 환경에 적용하기 전에 복제본에서 스키마 업그레이드를 시뮬레이션해 보십시오. 현재 스키마 버전을 확인하고, 업그레이드를 모의 실행한 다음 적용하십시오:

schematool -dbType postgres -info

schematool -dbType postgres -upgradeSchema -dryRun

schematool -dbType postgres -upgradeSchema

자신의 dbType으로 대체하십시오. 연결 정보는 Hive 구성에서 가져옵니다. 메타스토어에 스키마 버전이 기록되어 있지 않은 경우, -upgradeSchemaFrom 옵션을 사용하여 소스를 명시적으로 지정하십시오.

엔진 및 통합 오류

Hive 4에서는 Tez를 기본 실행 엔진으로 채택했으며, MapReduce 엔진은 Hive 2 버전부터 더 이상 사용되지 않는 기능으로 지정되었고, 문서에는 별도 공지 없이 제거될 수 있다는 경고가 명시되어 있습니다. 여전히 mr 또는 Spark 실행 엔진에 고정된 워크로드가 있는 경우, 전환을 계획하기 전에 이를 검증해야 합니다.

더 큰 놀라움은 후속 단계에서 나타납니다. 호환성은 Spark, Trino, Impala, Iceberg 및 해당 메타스토어 클라이언트의 구체적인 버전과 구성에 따라 달라지므로, 버전 매트릭스가 유효하다고 가정하기보다는 테스트를 완료할 때까지 모든 통합을 검증되지 않은 것으로 간주해야 합니다. Spark, Trino, Impala가 하나의 메타스토어를 동시에 공유하는 경우, 업그레이드는 이들 모두에 동시에 파급됩니다. 작업 일정을 잡기 전에 모든 메타스토어 소비자를 파악하고, 각 엔진에 대한 호환성 테스트를 업그레이드 실행 매뉴얼에 포함시켜야 합니다.

전문가 팁: 복제된 메타스토어를 대상으로 하는 병렬 Hive 4.2.0 환경을 구축하고, 이에 대해 프로덕션 쿼리의 대표적인 샘플을 재실행해 보세요. 먼저 샘플을 비식별화 처리해야 합니다. 쿼리 로그에는 대개 민감한 식별자나 리터럴 값이 포함되어 있기 때문입니다. Spark 및 Trino 관련 오류는 프로덕션 전환 과정에서가 아니라 스테이징 단계에서 발견되어야 합니다. 그렇지 않으면 오류가 프로덕션 전환 중에 나타나는 경향이 있기 때문입니다.

Apache Hive 지원 종료 후의 대안

세 가지 경로는 거의 모든 팀에 적용되며, 이 경로들은 서로 배타적이지 않습니다. 대부분의 조직은 한 가지 경로를 통해 시간을 벌면서 동시에 다른 경로를 실행하게 됩니다.

Hive 4.2.0으로 현장 업그레이드

JVM 및 엔진 종속성을 변경할 수 있고 스테이징 환경이 마련되어 있다면, 4.2.0으로 업그레이드하는 것이 장기적으로 가장 깔끔한 해결책입니다. 현재 릴리스 라인으로 전환하고, 최소 지원 런타임으로 Java 21을 채택하며, 4.2.0 메타스토어 및 Apache Iceberg 관련 기능을 활용할 수 있습니다. 여기에는 Iceberg REST 카탈로그 클라이언트를 포함한 확장된 카탈로그 지원, 자동 압축, 삭제 벡터, 열 기본값 등이 포함됩니다. 앞서 설명한 Java 버전 변경, 스키마 마이그레이션, ACID 압축 사전 점검을 고려하십시오. 스택 규모가 작고 독립적인 경우, 여기서 시작하십시오. Spark, Trino, Impala를 동시에 지원하는 경우, 버전 번호에서 예상되는 것보다 훨씬 더 많은 시간을 할당해야 합니다.

Hive를 완전히 교체하기

일부 팀은 Hive를 업그레이드하기보다는 EOL을 계기로 Hive를 완전히 벗어나기도 합니다. Apache Iceberg를 기반으로 구축되고 Trino, Spark SQL 또는 관리형 플랫폼을 통해 쿼리가 실행되는 최신 레이크하우스 아키텍처는 기존 Hive 실행 계층에 대한 의존도를 줄이거나 없앨 수 있지만, 많은 팀이 전환 기간 동안 Hive와 호환되는 카탈로그나 메타스토어를 유지합니다. 이는 가장 많은 노력이 필요한 방식이며, 실제 보안 취약점 대응에 필요한 기한 내에 완료되는 경우가 드물기 때문에, 대개 연장된 지원 기간을 확보하면서 병행하여 진행됩니다. 어차피 플랫폼을 전환할 계획이라면, 이 방법을 통해 이미 폐기할 예정이었던 엔진에 마이그레이션 노력을 낭비하지 않을 수 있습니다.

TuxCare의 끝없는 라이프사이클 지원

감사 기관이나 위험 등록부에서 요구하는 일정에 맞춰 마이그레이션을 진행할 수 없는 경우, TuxCare의 무한 수명 주기 지원(ELS) 는 지원 종료된 Apache Hive 2.3.9에 대한 CVE 패치를 제공하며, 이는 기존 패키지 관리 워크플로우를 통해 전달됩니다. 지원 범위는 버전별로 다르므로, 계획을 세우기 전에 지원 버전 목록에서 정확한 릴리스 버전을 확인하시기 바랍니다. 2.3.10, 3.1.3 또는 다른 계열을 사용 중이라면 문의해 주십시오. TuxCare는 요청에 따라 버전을 추가해 드립니다. 이 서비스를 통해 데이터 웨어하우스 인프라가 의존하는 Hive 버전을 계속 사용하면서 서둘러 마이그레이션을 진행할 필요가 없습니다.

플랫폼 재구축을 진행 중인 팀의 경우, 이는 감사 압박 속에서 오류 발생 가능성이 높은 업그레이드를 진행하는 것과 자체 일정에 따라 계획된 마이그레이션을 진행하는 것의 차이를 의미합니다. 이를 통해 지속적으로 관리되는 보안 수정 사항 소스를 복원할 수 있는데, 이는 바로 PCI DSS 요구 사항 12.3.4가 적용되는 조건이며, Java 및 엔진 작업이 완전히 준비된 후 Hive 4.2.0으로 전환하는 과정에서 문서화되고 입증 가능한 시정 증거를 확보할 수 있게 해줍니다. 이 조치만으로는 감사 지적 사항을 해결하지는 못합니다. 이는 귀사의 감사 범위, 증거 자료, 평가자에 따라 달라지기 때문에 어떤 패치 서비스도 이를 해결할 수는 없습니다. 하지만 이 조치는 귀사가 제시할 수 있는 내용을 변화시킵니다.

TuxCare를 통해 EOL 이후에도 Apache Hive의 보안을 유지하세요

EOL Hive의 시계는 멈추지 않습니다. 사용 중인 버전에 영향을 미치는 새로 공개된 CVE에 대해서는 해당 라인에 대한 커뮤니티 수정 프로그램이 제공되지 않으며, 매 감사 주기마다 이에 대해 어떤 조치를 취했는지 질문을 받게 될 것입니다. 실질적인 절차는 다음과 같습니다. 먼저 패치 소스를 복원한 다음, 사고로 인해 어쩔 수 없이 대응해야 하는 상황이 아니라 스스로 정한 일정에 따라 Hive 4.2.0으로 마이그레이션하거나 Hive를 완전히 탈피하십시오.

지원 종료(EOL)된 Hive 버전을 사용 중이지만 이번 분기에 마이그레이션할 준비가 되지 않으신 경우, TuxCare의 Endless Lifecycle Support 를 통해 업그레이드나 교체를 준비하는 동안에도 CVE에 대한 패치를 지속적으로 적용받을 수 있습니다. 이 서비스는 강제적인 버전 업그레이드를 요구하지 않고, 기존 패키지 관리 워크플로우를 통해 Apache Hive 2.3.9용 CVE 패치를 제공합니다.

자주 묻는 질문

현재 어떤 버전의 Apache Hive가 여전히 지원되고 있나요?

커뮤니티 릴리스는 4.x 계열에서만 제공되며, 현재 버전은 4.2.0입니다. Apache는 4.1.x의 경우 Java 17을, 4.2.x의 경우 Java 21을 지원 대상으로 명시하고 있습니다. 수정 사항은 이전 버전으로 역포트되지 않고 최신 마이너 버전에 반영된다는 점에 유의하십시오. 예를 들어, CVE-2025-62728은 4.1.x가 아닌 4.2.0에서 수정되었으므로, 4.1.0을 실행하는 것은 패치된 릴리스를 실행하는 것과 동일하지 않습니다. 1.x, 2.x 및 3.x 계열은 모두 지원 종료되었습니다.

Apache Hive 3.x는 언제 지원 종료되었나요?

아파치 하이버(Apache Hive) 커뮤니티는 2024년 10월 8일 3.x 계열의 지원 종료(EOL)를 선언했습니다. 마지막 릴리스는 2022년 4월 8일에 공개된 3.1.3이었습니다.

EOL 이후에도 Hive 2.3.x를 운영 환경에서 계속 사용할 수 있나요?

기술적으로는 그렇지만, 커뮤니티에서 제공하는 수정 사항 없이 위험을 관리해야 합니다. 2.x 계열의 마지막 릴리스는 2024년 5월 9일에 출시된 2.3.10이며, 이 계열은 2024년 5월 20일에 지원 종료(EOL)가 선언되었습니다. Apache Hive 커뮤니티는 Hive 또는 번들된 종속성에 영향을 미치는 새로 공개된 CVE에 대해 새로운 2.3.x 릴리스를 제공하지 않을 것입니다. 귀하에게 남은 선택지는 자체적으로 백포트를 유지 관리하거나 TuxCare ELS와 같은 독립적인 상용 지원 서비스를 이용하는 것입니다.

Hive 4로 업그레이드하면 Spark 또는 Trino 연동 기능이 중단되나요?

각 엔진과 메타스토어 클라이언트의 정확한 버전 및 구성에 따라 가능합니다. 프로덕션 환경으로 전환하기 전에 스테이징 환경에서 대상 Hive 릴리스에 대해 모든 Spark, Trino, Impala 및 Iceberg 통합 기능을 테스트하십시오.

Hive Metastore(HMS)에는 별도의 지원 종료일이 정해져 있나요?

아니요. HMS 버전은 Apache Hive 릴리스를 따릅니다. Hive 4.1.0부터 메타스토어는 바이너리 및 Docker 이미지 형식의 독립형 구성 요소로도 배포되며, 4.2.0에서는 메타스토어 클라이언트 코드가 별도의 모듈로 분리되었습니다. 하지만 커뮤니티 보안 수정 사항은 여전히 지원되는 Hive 릴리스를 따릅니다. 따라서 Hive 버전의 지원 종료(EOL)는 메타스토어의 지원 종료(EOL)를 의미합니다.

요약