Apache Spark 지원 종료: 데이터 파이프라인의 보안 유지 | TuxCare ELS

주요 내용

• 의존성 트리는 노출 범위를 확대합니다: 프로덕션용 Spark 배포 환경에는 직접 및 전이적 종속성, Hadoop 클라이언트 라이브러리, Netty, Jackson Databind, Apache Parquet, Apache Avro, Guava 등 수많은 구성 요소가 포함되어 있으며, 각 구성 요소는 고유한 CVE 스트림을 가지고 있습니다. 이러한 CVE 스트림은 상위 구성 요소인 Apache Spark의 지원 종료(End of Life) 전환이 발생하면 더 이상 통합된 보안 패치를 받지 못하게 됩니다.
• 서두른 업그레이드는 비용이 많이 들고 위험합니다: 당황한 나머지 서둘러 진행하는 마이그레이션은 운영 환경의 사고, 시스템 불안정, 기술적 부채의 누적, 그리고 연장 지원 비용을 훨씬 초과하는 예상치 못한 비용을 초래합니다.
• Apache Spark의 지원 종료(EOL)가 보안 지원의 종료를 의미하지는 않습니다: TuxCare ELS와 같은 확장 지원 옵션을 활용하면 전략적으로 업그레이드를 계획하는 동안 EOL 버전에 대한 지속적인 보안 지원을 받을 수 있습니다.

아파치 스파크(Apache Spark)는 지난 10년 이상 기업 데이터 엔지니어링, 대규모 분석, 머신러닝을 주도해 온 핵심 엔진입니다. 배치 작업, 스트리밍 파이프라인, 머신러닝 워크로드 전반에 걸쳐 방대한 데이터 세트를 메모리 내에서 동시에 처리할 수 있는 능력 덕분에, 금융 서비스, 의료, 전자상거래, 통신, 정부 기관 등 데이터 집약적 조직들에게 있어 스파크는 필수적인 선택지로 자리매김했습니다.

그러나 핵심 생산 인프라 전반에 Spark가 널리 보급되어 있다는 점은, Apache Spark의 지원 종료(EOL)와 관련된 보안 문제가 실제 운영 측면에서 상당한 비중을 차지함을 의미합니다. 지원이 종료된 버전의 Apache Spark를 운영하는 조직들은 스택 내에서 가장 데이터 집약적인 계층 중 하나, 즉 민감한 고객 기록, 금융 거래 및 규제 대상 데이터를 대규모로 일상적으로 처리하는 계층 내에서 보안 및 규정 준수 관련 책임을 지고 있는 셈입니다.

이 글에서는 Apache Spark의 지원 종료(End of Life)가 데이터 엔지니어링 팀에게 실제로 어떤 의미를 지니는지, 의존성 트리 내에서 보안 취약점이 실제로 어디에 축적되는지, 최신 버전으로의 마이그레이션이 겉보이는 것보다 훨씬 까다로운 이유, 그리고 TuxCare의 Endless Lifecycle Support(ELS)를 통해 팀이 준비되지 않은 상태에서 마이그레이션을 강행하지 않고도 완벽한 보안 및 규정 준수 범위를 유지할 수 있는 방법을 설명합니다.

Apache Spark의 제품 수명 주기는 무엇인가요?

Apache Spark는 다음과 같은 구조의 시맨틱 버저닝을 따릅니다. [MAJOR].[FEATURE].[MAINTENANCE]의 구조를 따릅니다. 마이너(기능) 릴리스는 일반적으로 6개월마다 출시되며, 출시 후 18개월 동안 버그 및 보안 수정 사항을 통해 유지 관리됩니다. 각 메이저 버전 내의 마지막 마이너 릴리스는 LTS(장기 지원) 릴리스로 지정되며, 일반적으로 약 31개월 동안 더 긴 기간 동안 유지 관리됩니다.

Spark 릴리스의 지원 현황:

3.x 시리즈의 마지막 LTS 릴리스이자, 아직 4.x 세대로 전환하지 않은 기업에서 가장 널리 배포되고 있는 Spark 3.5는 2026년 4월 12일에 Apache Spark 지원 종료(EOL) 시점에 도달할 예정입니다. Spark 3.4는 2024년 10월에, Spark 3.3는 2023년 12월에 각각 Apache Spark 지원 종료 시점에 도달했습니다. 아직 해당 브랜치 중 하나를 실행 중인 조직은 이미 패치가 적용되지 않은 프레임워크를 사용하고 있는 것이며, Spark 3.5를 사용하는 조직은 동일한 상황이 적용되기까지 남은 시간이 얼마 남지 않았습니다.

Apache Spark의 지원 종료 일정에 대한 당사의 종합 분석을 읽어보시고, 해당 일정이 귀사의 운영 환경에 어떤 영향을 미치는지 확인해 보십시오.

18개월 유지보수 기간 모델은 Apache Spark의 EOL 전환이 일정대로 이루어진다는 것을 의미하지만, 특정 버전이 프로덕션 환경에 처음 배포된 시점부터 데이터 엔지니어링 팀이 검증된 업그레이드를 완료할 준비가 될 때까지 걸리는 시간은 대개 훨씬 더 깁니다. Apache Spark의 지원 종료(EOL) 날짜가 도래하면, 파이프라인이 의존하던 보안 지원은 단순히 사라지게 되며, 운영 체제의 EOL 이벤트와 달리 업스트림 프로젝트 측에서 제공하는 유예 기간이나 확장 지원 단계는 없습니다.

아파치 스파크의 지원 종료(EOL)가 데이터 엔지니어링 플랫폼에 어떤 의미를 갖는가?

Spark를 활용해 하류 재무 시스템에 데이터를 공급하는 ETL 워크플로를 실행하는 프로덕션 데이터 파이프라인의 처리 엔진으로 사용하거나, 대규모로 개인 식별 정보를 처리하거나, 실시간 사기 탐지를 수행하거나, 머신러닝 특징 저장소의 기반을 제공하는 조직의 경우, Apache Spark의 지원 종료(End of Life) 조치는 단순한 배경 유지보수 사항이 아니라 보안 및 규정 준수 측면에서 직접적인 영향을 미치는 사건입니다.

Apache Spark 지원 종료일 이후에는 더 이상 보안 패치가 제공되지 않습니다

Spark 버전이 Apache Spark 지원 종료(End of Life) 시점에 도달하면, Apache 커뮤니티는 해당 버전에 대한 보안 패치 제공을 중단합니다. 그 이후에 공개되는 모든 취약점(Spark의 클러스터 통신 계층, 웹 UI, RPC 암호화 구현, Hadoop 클라이언트 라이브러리와의 통합, 또는 엔진의 기타 어떤 부분에서 발생하든)에 대해서는 해당 브랜치에 대한 공식 패치가 제공되지 않습니다. 커뮤니티에서 제공하는 유일한 해결책은 지원되는 릴리스로 업그레이드하는 것입니다.

특정 Spark API를 기반으로 파이프라인이 구축되어 있고, PySpark 작업이 특정 Spark 릴리스에 고정된 Python 생태계 버전에 의존하며, Spark 업그레이드를 위해 수십 개의 종속 작업과 인프라 구성에 걸쳐 조율된 변경이 필요한 복잡한 운영 환경에서 Spark를 실행하는 조직의 경우, “그냥 업그레이드”하는 것은 단기간 내에 실행 가능한 대안이 아닙니다. Apache Spark의 지원 종료(End of Life) 상태가 발효되는 시점과 마이그레이션을 현실적으로 완료하고 검증할 수 있는 시점 사이의 간격은, 바로 수정 패치가 없는 상태에서 새로운 취약점이 누적되는 기간과 정확히 일치합니다.

제품 수명 종료 후의 보안 및 규정 준수 위험

Apache Spark EOL 버전을 사용할 경우 규정 준수 측면에서 구체적인 문제가 발생합니다. PCI DSS 요구사항 6.3.3은 중요 및 고위험 패치를 출시 후 1개월 이내에 설치할 것을 요구하지만, Apache Spark EOL 버전에는 설치할 패치가 없어 일반적인 방법으로는 규정 준수가 불가능합니다. SOC 2 감사관은 운영 환경 내 EOL 소프트웨어를 통제 결함으로 지적합니다. Spark 클러스터가 HIPAA, GDPR 또는 금융 규제 범위에 속하는 데이터를 처리하는 조직의 경우, 처리 계층에 보안 패치가 적용되지 않은 것은 단순한 이론적 위험이 아닙니다. 이는 조만간 드러날 수 있는 실질적인 규정 준수 위반 사항입니다.

규제 대상 데이터 처리 영역 내에 Spark가 배포된 조직들은 보안 설문지에서 드러나는 것과 동일한 문서화 미비 사항에 직면하게 되며, 이는 공급업체 인증을 가로막을 뿐만 아니라 규제 산업 분야에서는 자체적으로 기한이 촉박한 시정 조치 요구 사항을 초래하기도 합니다.

CVE 기록: 취약점 기록이 보여주는 것

Spark의 CVE 이력은 기업 데이터 인프라 내에서 구동되는 프레임워크로서 Apache Spark의 EOL(지원 종료) 상태가 결코 수동적으로 받아들여서는 안 될 상황임을 다시금 확인시켜 줍니다.

CVE-2022-33891 (CVSS 8.8, 고위험)은 패치되지 않은 Spark의 취약점이 실제로 어떤 모습인지 가장 구체적으로 보여준 사례입니다. Spark ACL이 활성화된 상태에서, HttpSecurityFilter 구성 요소 내의 특정 코드 경로를 통해 공격자가 사칭을 통해 임의의 사용자 이름을 전달할 수 있게 했습니다. 그러면 필터는 해당 사용자 이름을 그룹 멤버십을 조회하는 데 사용되는 Unix 셸 명령에 직접 전달하여, 블라인드 OS 명령어 주입 취약점을 생성했습니다. Spark UI에 접근 권한이 있는 공격자는 Spark 프로세스를 실행 중인 사용자로 위장하여 임의의 셸 명령을 실행할 수 있었습니다. CISA는 이 취약점을 '알려진 악용 취약점(Known Exploited Vulnerability)'으로 지정하여, 오픈소스 생태계 전반에서 추적되는 가장 활발히 악용되는 취약점 중 하나로 분류했습니다. 공개 후 몇 달 동안 실제 환경에서의 악용 사례가 확인되었습니다. 이 취약점은 여러 Spark 3.0.x, 3.1.x 및 3.2.x 브랜치에 영향을 미쳤으며, 이들 모두는 현재 지원 종료(EOL) 상태입니다. 현재 지원이 종료된 브랜치에 대해 향후 유사한 심각도의 CVE가 발견되더라도 공식적인 수정 패치는 제공되지 않을 것입니다.

CVE-2023-22946 (CVSS 8.8, 고위험)은 심각한 취약점이 구형 Spark 브랜치에만 국한되지 않음을 보여주었습니다. 이 권한 상승 취약점은 3.4.0 이전의 모든 Spark 버전에 영향을 미쳤으며, 이는 공개 당시 Spark 3.3.x 및 그 이전 버전의 전체 설치 기반에 영향을 미쳤음을 의미합니다. 악의적인 사용자는 spark-submit에 사용자 정의 구성 클래스를 명령줄 인수로 전달함으로써, Spark의 프록시 사용자 권한 검사를 우회하고 작업을 제출하는 Spark 사용자의 권한 수준으로 권한을 상승시킬 수 있습니다. 기업 데이터 플랫폼에서 흔히 볼 수 있는 구성인 멀티테넌트 클러스터 환경에 Spark가 배포된 조직의 경우, 이러한 유형의 취약점은 데이터 접근 제어 모델의 무결성에 직접적인 영향을 미칩니다.

이러한 취약점은 스파크 엔진의 웹 계층과 권한 모델 전반에 걸쳐 존재하며, 이는 바로 데이터 인프라를 운영하는 조직이 반드시 보호해야 할 공격 표면입니다.

숨겨진 위험: Spark의 종속성 트리

프로덕션 환경의 Spark 배포 환경에서 취약점이 노출되는 범위는 Spark 엔진 바이너리 자체를 훨씬 넘어섭니다. Spark는 방대한 종속성 구조를 포함하고 있으며, 해당 소스 트리 내의 각 구성 요소는 각각 독립적인 CVE 목록을 가지고 있습니다.

Spark Core 모듈은 모든 RPC 및 네트워크 통신을 위해 Netty를 직접적인 런타임 종속성으로 포함하고 있으며, Netty는 HTTP 요청 파싱, 헤더 처리, SSL/TLS 구현에 영향을 미치는 취약점을 포함하여 상당한 수의 CVE 이력을 가지고 있습니다. JSON 직렬화를 위해 포함된 Jackson Databind는 지난 몇 년간 모든 Java 라이브러리 중에서도 가장 많은 CVE가 보고된 라이브러리 중 하나로, 주요 버전을 통틀어 수십 건의 역직렬화 취약점이 공개되었습니다. Apache Hadoop 클라이언트 라이브러리인 hadoop-common, hadoop-hdfs, hadoop-auth는 HDFS 및 YARN 통합을 위해 번들로 제공되며, 이들도 자체적인 보안 취약점을 가지고 있습니다. Apache Parquet는 기본 열 기반 저장 형식으로 포함되어 있습니다. Apache Avro는 스키마 기반 직렬화를 처리합니다. Apache ZooKeeper 클라이언트 라이브러리는 조정 서비스를 위해 Hadoop을 통해 포함됩니다. Google Guava, Apache Commons IO, Apache Commons Lang, Apache Commons Crypto, Curator(ZooKeeper 클라이언트 프레임워크), Protobuf 및 LZ4는 모두 런타임 종속성입니다. Spark가 ML 라이브러리(MLlib)와 함께 배포될 경우, JVM과 Python 프로세스 간의 열 기반 데이터 교환을 위해 Arrow가 사용됩니다.

일반적인 프로덕션 환경인 Spark와 Kafka의 Structured Streaming 통합 시, Kafka 클라이언트 라이브러리와 그 종속성들이 시스템 구성에 포함됩니다. 일반적인 통합 구성을 갖춘 프로덕션용 Spark 배포 환경의 전이적 종속성 그래프는 100개가 넘는 아티팩트로 구성됩니다.

특정 Spark 브랜치가 Apache Spark 지원 종료(EOL) 단계에 도달하면, 커뮤니티는 해당 Spark 릴리스와 관련된 모든 종속성에 대해 더 이상 통합된 보안 업데이트를 제공하지 않습니다. Apache Spark EOL 배포 환경을 대상으로 실행되는 취약점 스캐너는 수정 프로그램이 제공되지 않는 종속성 트리 전반에 걸쳐 점점 더 많은 문제점을 발견하게 되며, 이로 인해 보안 팀은 새로운 CVE 공개 주기가 도래할 때마다 해결 불가능한 스캔 결과가 누적되는 상황에 직면하게 됩니다.

보안 유지 및 규정 준수 방안

Apache Spark의 지원 종료 버전을 운영 중인 조직에는 여러 가지 해결 방안이 있습니다. 일부 방안은 상당한 엔지니어링 노력과 긴 시간이 소요됩니다. 반면, TuxCare의 ‘Endless Lifecycle Support’는 보안 취약점을 즉시 해소해 줍니다.

옵션 1: 최신 Spark 버전으로 업그레이드하기

장기적인 해결책은 현재 지원되는 Spark 버전으로 업그레이드하는 것입니다. 현재 활발히 유지보수되고 있는 릴리스는 Spark 3.5(LTS, 2026년 4월까지 지원), Spark 4.0, 그리고 4.x 계열의 최신 주요 기능 릴리스인 Spark 4.1입니다.

Spark 3.3.x 또는 3.4.x를 사용 중인 조직의 경우, Spark 4.0에서 도입된 주요 버전의 호환성 깨는 변경 사항을 피할 수 있으므로 Spark 3.5 LTS 릴리스로 업그레이드하는 것이 3.x 세대 내에서 가장 원활한 방법입니다. Spark 3.5는 3.x 애플리케이션과의 API 호환성을 유지하면서 보안 지원 기간을 2026년 4월까지 연장합니다. 이후 Spark 3.5 역시 Apache Spark의 지원 종료(EOL) 시점에 도달하게 되며, 이로 인해 Spark 4.x가 유일한 장기 지원 대상이 됩니다.

Spark 4.0 또는 4.1로 업그레이드하면 데이터 엔지니어링 코드베이스 전반에 걸쳐 신중한 계획이 필요한 일련의 호환성 깨는 변경 사항이 도입됩니다. Spark 4.0에서는 Scala 2.12에 대한 지원이 중단되어 많은 조직에 영향을 미쳤습니다. Scala로 작성된 Spark 애플리케이션은 전체 코드베이스를 Scala 2.13으로 업데이트하고, Scala로 컴파일된 모든 아티팩트를 재빌드해야 합니다. JDK 8 및 JDK 11에 대한 지원이 제거되었으며, 이제 Java 17이 최소 런타임 버전으로 지정되어 모든 클러스터 노드와 Spark 작업을 실행하는 모든 시스템에서 JVM 업그레이드가 필요합니다. Spark 4.0에서는 ANSI SQL 모드가 기본적으로 활성화됩니다. Hive 호환 null 처리 동작, 무음형 변환(silent type coercion) 또는 관대한 오버플로(permissive overflow) 의미론에 의존하던 파이프라인은 더 이상 null이나 래핑된 값을 무음으로 반환하지 않고 런타임 예외를 발생시키게 됩니다. 이로 인해 명확한 오류 메시지 없이 하류 결과 집합이나 파이프라인 로직이 손상될 수 있습니다. JDK 8을 필요로 하는 2.0 이전 버전의 Hive 메타스토어는 더 이상 지원되지 않습니다.

스파크에 상당한 투자를 한 조직의 경우—즉, 업그레이드 여부가 중요한 대부분의 조직—적절히 계획되고 테스트를 거친 스파크 4.x로의 마이그레이션에는 몇 주가 아닌 몇 달이 소요됩니다.

옵션 2: 다른 처리 프레임워크로 마이그레이션

일부 조직은 Apache Spark의 지원 종료(End of Life)를 계기로 대체 데이터 처리 기술을 검토하기도 합니다. 예를 들어, 상태 유지 스트림 처리를 위한 Apache Flink, SQL 분석을 위한 Trino 또는 Apache Hive, Python 네이티브 분산 계산을 위한 Dask 또는 Ray, 혹은 엔진을 완전히 추상화한 클라우드 네이티브 관리형 서비스 등이 있습니다.

Hive를 대상 프레임워크로 검토하고 계신다면, 당사의 심층 가이드에서 Apache Hive의 EOL에 대해 더 자세히 알아보실 수도 있습니다.

이러한 아키텍처적 주장은 특정 상황에서 타당성을 갖습니다. 특히 클라우드 네이티브 서버리스 실행 모델이 Spark 클러스터 관리에 따른 운영 부담을 없애주거나, 워크로드 패턴이 스트림 우선 아키텍처에 더 적합한 경우라면 더욱 그렇습니다. 하지만 프레임워크를 완전히 마이그레이션하는 것은 Spark 버전 업그레이드보다 비용이 훨씬 더 많이 듭니다. Spark SQL 쿼리, PySpark 변환, MLlib 파이프라인, Structured Streaming 토폴로지, 그리고 Spark를 기반으로 구축된 모든 툴링, 오케스트레이션 및 모니터링 인프라를 교체하거나 근본적으로 재구축해야 합니다. 이는 Apache Spark의 EOL(지원 종료) 일정에 의해 강요된 결정이 아니라, 신중하게 계획된 별도의 일정을 수립해야 할 전략적 인프라 결정입니다.

옵션 3: TuxCare 확장 라이프사이클 지원으로 지금 바로 시스템을 보호하세요

TuxCare의 ‘무기한 라이프사이클 지원’은 새로운 문제를 야기하지 않으면서 당면한 문제를 해결해 주는 솔루션입니다. 기존 Maven, Gradle 또는 pip 워크플로를 통해 프레임워크와 그 종속성 트리에 대한 지속적인 보안 패치 지원을 받으면서도, 강제 업그레이드나 인프라 운영 방식의 변경 없이 현재 사용 중인 Spark 버전을 계속 운영할 수 있습니다.

보안 취약점은 즉시 해소됩니다. 규정 준수 상태는 유지됩니다. 팀은 운영상 타당한 일정에 따라 적절한 업그레이드 계획을 자유롭게 수립할 수 있습니다. 여기에는 Scala 2.12 코드를 Scala 2.13으로 재작성하는 데 필요한 추가 기간, ANSI SQL 기본 설정 하에서 파이프라인 동작을 검증하는 과정, 클러스터 전반에 걸친 Java 런타임 업그레이드, 그리고 모든 프로덕션 작업에 대한 회귀 테스트 등이 포함됩니다. 마감 기한의 압박에 따른 강제 마이그레이션도, 규정 준수 관련 긴급 상황도, 하류 재무 또는 운영 시스템으로 데이터를 공급하는 프로덕션 파이프라인에서 발생하는 데이터 품질의 은밀한 저하도 없습니다.

스파크 업그레이드를 서두를 경우의 위험성

보안 대시보드에 Apache Spark의 EOL(지원 종료) 상태가 표시되고 규정 준수 팀에서 질문을 시작하면, 즉각적인 조치를 취해야 한다는 압박감이 실감 나게 다가옵니다. 서둘러 진행하는 Spark 업그레이드가 실제로 무엇을 수반하는지 파악하는 것은, 보안 취약점 자체를 이해하는 것만큼이나 중요합니다.

스파크 업그레이드의 실제 내용

Spark을 제대로 업그레이드하는 것, 특히 3.3.x나 3.4.x에서 4.x로 업그레이드하는 것은 단순한 종속성 파일의 버전 변경이 아니라, 여러 단계로 이루어지는 데이터 플랫폼 프로젝트입니다. 이를 위해서는 전체 코드베이스에서 더 이상 사용되지 않는 API와 제거된 기능을 점검하고, 현재 버전이 Spark 4.x의 최소 요구 사양보다 낮은 경우 모든 클러스터 노드에서 Java 런타임을 업그레이드하며, Scala 버전을 업데이트하고 Scala로 컴파일된 모든 아티팩트를 재빌드해야 하며, 새로운 릴리스에 맞춰 모든 클러스터 구성, 리소스 관리자 통합 및 배포 설명서를 검증해야 합니다.

코드 수정: Scala 기반 Spark 애플리케이션의 경우, Scala 2.12로 컴파일된 모든 아티팩트를 Scala 2.13 기준으로 재컴파일해야 합니다. ANSI SQL 모드 변경으로 인해 모든 Spark SQL 쿼리, DataFrame 변환 및 UDF를 체계적으로 검토하여, null을 반환하는 오버플로 동작, 허용적인 형 변환 또는 날짜 및 타임스탬프 처리 시 Hive 호환 에지 케이스에 의존하는 로직을 식별해야 합니다. 수백 개의 SQL 표현식이 포함된 대규모 파이프라인의 경우, 이러한 검토 작업은 상당한 규모의 엔지니어링 작업이 됩니다.

호환성 확인: PySpark 작업은 새로운 Python 데이터 소스 API에 대해 검증되어야 하며, 4.x 릴리스에서 발생한 PySpark 특유의 동작 변경 사항과의 호환성을 확인해야 합니다. Hive 메타스토어와 통합되는 모든 Spark 애플리케이션은 메타스토어 버전이 Spark 4.0의 최소 요구 사항인 Hive 2.0 이상인지 확인해야 합니다. Delta Lake, Apache Iceberg 또는 기타 테이블 형식 통합을 사용하는 작업의 경우, 해당 통합 기능이 Spark 4.x와 호환되는 릴리스를 제공하는지 확인해야 합니다.

툴체인 조정: Spark 전용 버전 문자열, 클래스패스 항목 또는 시작 플래그를 참조하는 빌드 시스템, CI/CD 파이프라인, 컨테이너 이미지, 클러스터 부트스트랩 스크립트 및 오케스트레이션 구성을 검토하고 업데이트해야 합니다. Spark의 구조화된 로깅 프레임워크가 4.0 버전에서 변경되어, 로그 파싱 인프라 및 가시성 도구들에 영향을 미칩니다.

테스트 오버헤드: 배치 ETL 파이프라인, 구조화된 스트리밍 작업, ML 훈련 워크플로 및 대화형 SQL 워크로드를 아우르는 전체 프로덕션 작업 인벤토리에 대한 종단 간 테스트는 생략할 수 없습니다. 특히 ANSI SQL의 동작 변경은 오류는 발생시키지 않더라도 미묘한 출력 차이를 유발하며, 이는 특정 데이터 분포나 극단적인 입력 사례에서만 드러나는 방식으로 결과를 조용히 변경할 수 있습니다. 처리된 데이터의 정확성에 의존하는 다운스트림 소비자가 있는 조직의 경우, 프로덕션으로 배포하기 전에 실제 데이터 볼륨을 사용하여 전체 작업 세트에 걸쳐 파이프라인 출력 정확성을 검증하는 것은 선택 사항이 아닙니다.

업그레이드를 서두르면 어떤 일이 벌어질까

팀들이 마감 기한의 압박 속에서 이 작업을 서둘러 처리할 때, 그 결과는 늘 비슷한 양상을 띤다.

지원 부담 증가: 검증되지 않은 ANSI SQL 변경 사항은 프로덕션 작업에서 예기치 않은 런타임 예외를 발생시킵니다. Scala 2.12/2.13 간의 비호환성은 클래스패스 충돌이나 메서드 미검출 오류로 나타나며, 영향을 받는 라이브러리에 대한 심층적인 지식이 없으면 진단하기 어렵습니다. 이로 인해 데이터 엔지니어링 및 플랫폼 운영 팀은 평소 업무량에 더해 이러한 사고의 물결을 감당해야 합니다.

시스템 불안정성: Spark 파이프라인은 종종 다운스트림 소비자의 대시보드, 리스크 시스템, 사기 탐지 모델, 그리고 고객 대상 데이터 제품을 구동하며, 이러한 환경에서 발생하는 행동 회귀 현상은 실시간 비즈니스 운영에 즉각적인 영향을 미칩니다. 테스트 과정에서 포착되지 않은 SQL 의미론, 형 변환 동작 또는 타임스탬프 처리 방식의 미세한 변화는 데이터 품질 문제를 야기하며, 이러한 문제는 탐지하기 어려울 뿐만 아니라 Spark 업그레이드와 연관 지어 추적하기는 더욱 어렵습니다.

기술 부채의 누적: 시간적 압박 속에서 적용된 임시 방편이 영구적인 해결책으로 굳어집니다. 근본적인 의미적 변화를 이해하지 못한 채 ANSI 예외를 피하기 위해 명시적인 형 변환을 적용해 수정한 SQL 쿼리는 그 자체로 데이터 품질 위험을 초래합니다. Apache Spark의 지원 종료(End of Life) 문제는 해결되지 않고 단지 미뤄질 뿐입니다.

예상치 못한 비용: 긴급 엔지니어링 업무 시간, 데이터 제품 출시 지연, 사고 대응에 드는 간접비, 그리고 신규 기능 개발 대신 프로덕션 파이프라인 장애를 해결하는 데 투입되는 시니어 데이터 엔지니어들의 기회 비용 등이 빠르게 누적됩니다. 서둘러 진행한 업그레이드로 인해 수주간의 프로덕션 사고가 발생하는 경우, 신중한 마이그레이션 계획을 가능하게 했을 연장 지원 비용보다 훨씬 더 큰 비용이 발생합니다.

간편한 해결책: Apache Spark 단종(EOL)을 위한 TuxCare ELS

TuxCare는 지원 종료된 Apache Spark 버전에 대해 ‘무기한 라이프사이클 지원’을 제공합니다. 준비가 되지 않은 상태에서 강제로 업그레이드를 진행할 필요 없이, 기존 인프라 운영 방식을 변경하지 않고도 기존 Maven, Gradle 또는 pip 워크플로를 통해 지속적으로 제공되는 보안 패치를 적용하여 현재 Spark 환경을 계속 운영할 수 있습니다.

TuxCare는 지난 10년 넘게 운영 체제, 런타임, 라이브러리, 애플리케이션 프레임워크 등 다양한 분야에서 이러한 활동을 펼쳐왔습니다. 이들은 오픈소스 생태계 전반에 걸쳐 22만 개 이상의 보안 패치를 배포했습니다. TuxCare가 “엔터프라이즈 규모에서 EOL(지원 종료) 소프트웨어의 보안을 유지하는 방법을 알고 있다”고 말할 때, 이는 단순한 마케팅 문구가 아니라 실제 운영 실적을 바탕으로 한 사실입니다.

지원 종료(EOL) 단계에 접어든 다른 구형 Java 웹 서비스 프레임워크를 관리하는 방법에 대한 자세한 내용은, Apache CXF EOL에 대한 당사의 분석 자료를 참고하여 해당 지원 연장이 귀사의 전체 스택에 어떻게 적용되는지 확인해 보실 수 있습니다.

전체 종속성 트리 커버리지: TuxCare의 Spark용 ELS는 프레임워크와 Netty, Jackson Databind, Hadoop 클라이언트 라이브러리, Apache Parquet, Apache Avro, Guava, ZooKeeper 클라이언트 라이브러리, Commons IO 등을 포함한 직접 및 전이적 종속성을 추가 비용 없이 포괄합니다. 취약점 스캐너는 패키지 경계를 구분하지 않으며, TuxCare의 커버리지 역시 마찬가지입니다. 단순히 최상위 Spark 아티팩트뿐만 아니라 전체 패치 대상 영역이 모두 처리됩니다.

정교하고 자동화된 패치 적용 프로세스: TuxCare는 NVD, 벤더 보안 권고, Apache 자체 CVE 목록, GitHub 보안 피드 등 Spark 및 종속성 취약점이 공개되는 모든 채널을 모니터링합니다. CVE가 식별되면 알고리즘 도구와 AI 기반 자동화 시스템이 지원되는 버전으로 보안 수정 사항을 백포트하며, 보안 전문가들이 패치가 배포되기 전에 모든 패치를 검증합니다. 모든 업데이트는 리포지토리에 적용되기 전에 무결성, 기능 및 회귀 테스트를 거칩니다. 자세한 기술 정보는 TuxCare의 오픈 소스 패치 프로세스에 관한 기술 백서를 참조하십시오.

원활한 통합: 현재 Maven, Gradle 또는 pip를 통해 Spark를 사용하고 계시더라도, 기존 워크플로우를 최소한으로 변경하는 것만으로 업데이트 소스를 TuxCare의 보안 저장소로 전환할 수 있습니다. 빌드 파이프라인이나 CI/CD 워크플로우, 데이터 엔지니어링 팀의 운영 방식에 어떠한 변경도 필요하지 않습니다. 보안 업데이트는 기존 툴체인을 통해 자동으로 적용됩니다.

SLA에 기반한 신속 대응: Apache Spark 지원 종료 버전에서 엔진 자체나 종속성 트리 내 어디에서든 새로운 취약점이 공개될 경우, TuxCare는 서비스 수준 계약(SLA)에 따라 보장된 일정 내에 패치를 제공합니다. 중요 및 고위험 취약점(CVSS 7+)은 공개 후 14일 이내에 해결됩니다. EOL(지원 종료)된 Spark 브랜치에 대해 결코 제공되지 않을 커뮤니티 백포트를 기다릴 필요가 없습니다. 고객은 계획에 맞춰 사용할 수 있는 일정에 따라 즉시 생산 환경에 적용 가능한 패치를 제공받으며, 취약점 분류 및 문제 해결을 위한 연중무휴 전문가 지원을 받을 수 있습니다.

비용 효율적인 보안 연속성: TuxCare ELS의 비용은 (임박한 규정 준수 기한으로 인해 서둘러 진행해야 하는) 긴급 업그레이드에 소요되는 엔지니어링 시간, 운영 위험, 사고 대응 및 로드맵 작업 지연에 드는 비용의 극히 일부에 불과합니다. 예측 가능한 보안 지원 범위, 통제된 업그레이드 일정, 그리고 규정 준수 관련 긴급 상황의 부재는 확장 지원이 올바른 기업 전략인 이유입니다.

Apache Spark 지원 종료(EOL) 버전에 대해 정확히 어떤 취약점이 해결되었는지 확인하려면, TuxCare에서 Apache Spark용 실시간 CVE 추적기를 운영하고 있습니다.

아파치 스파크의 지원 종료로 인해 데이터 파이프라인이 위험에 처하지 않도록 하세요

Apache Spark의 지원 종료가 파이프라인이 즉시 위험에 처한다는 뜻은 아니며, 팀이 준비되지 않은 상태에서 긴급 업그레이드를 수행해야 한다는 의미도 아닙니다. 하지만 아파치 스파크의 지원 종료(End of Life) 상태는 데이터 처리 인프라가 의존해 온 보안 지원이 더 이상 제공되지 않음을 의미하며, CVE-2022-33891이 CISA의 '알려진 악용 취약점(Known Exploited Vulnerabilities)' 목록에 포함된 사실은 스파크의 취약점이 단순한 이론적 관심사가 아니라 실제 악용의 대상이 되고 있음을 입증했습니다.

이 문제를 잘 처리하는 조직은 아파치 스파크(Apache Spark)의 지원 종료(End of Life) 상태를 압박감 속에서 대응해야 할 마감 기한이 아니라, 관리해야 할 보안 문제로 여기는 곳입니다. 팀의 역량에 진정으로 부합할 때, 즉 전체 작업 목록에 걸쳐 ANSI SQL 동작 변경 사항을 검증하고, 코드베이스 전반의 Scala 버전을 업데이트하며, 실제 데이터 양을 바탕으로 프로덕션 파이프라인에 대한 회귀 테스트를 수행하는 데 필요한 충분한 준비 기간을 포함하여, Spark 3.5, 4.0 또는 4.1로의 신중한 업그레이드를 계획할 수 있습니다. 더 광범위한 플랫폼 마이그레이션이 실제 아키텍처적 목적을 달성하는지 평가할 수도 있습니다. 또는 TuxCare ELS를 활용하여 규정 준수 감사관의 일정이 아닌, 귀사의 일정에 맞춰 이러한 결정을 내리는 동안에도 완벽한 보안과 규정 준수를 유지할 수 있습니다.

확장 지원은 단순한 임시 방편이 아닙니다. 이는 Spark 배포 환경을 안전하게 유지하고, 규정 준수 상태를 온전하게 지키며, 데이터 엔지니어링 팀이 긴급 대응에 매달리지 않고 개발에 집중할 수 있도록 해주는 선택지입니다. 현재 Apache Spark의 지원 종료(EOL)가 보안 관리의 주요 관심사라면, 다음을 방문해 주십시오. TuxCare의 오픈소스 소프트웨어 무제한 라이프사이클 지원 를 방문하여, 확장 지원이 필요한 기간 동안 데이터 인프라를 어떻게 보호할 수 있는지 확인해 보십시오.

요약

기사 이름

Apache Spark 지원 종료: 위험 요소, 보안 취약점 및 향후 대응 방안

설명

Apache Spark를 프로덕션 환경에서 운영 중이신가요? 강제 마이그레이션 없이도 보안과 규정 준수를 유지하세요. TuxCare ELS는 EOL 이후에도 보안 지원을 지속합니다.

작성자

아르템 카라세프

게시자 이름

TuxCare

게시자 로고