Lodash 지원 종료: 확장 지원으로 보안을 유지하세요

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

주요 내용

Lodash는 직접적인 종속성이 전혀 없지만, 195,000개 이상의 npm 패키지가 이를 의존하고 있어 수많은 종속성 트리에서 핵심적인 실패 지점이 되고 있습니다.
Lodash 버전 간에 적용된 오염 문제 해결 방안과 호환성 변경 사항은 운영 환경의 부하가 가해졌을 때만 드러나는 미묘한 버그를 유발할 수 있으며, 이는 예산 초과를 피할 수 없게 만듭니다.
TuxCare ELS와 같은 확장 지원 옵션은 고객이 전략적으로 업그레이드를 계획하는 동안 지원 종료된 버전에 대한 지속적인 보안 지원을 제공합니다.

자바스크립트 애플리케이션을 개발하고 있다면, 의존성 트리(dependency tree)에 Lodash가 포함되어 있을 가능성이 매우 높습니다. 자바스크립트 개발을 훨씬 수월하게 만들어주는 유틸리티 함수들을 직접 활용하고 계실 수도 있겠네요. 혹은 설치한 어떤 패키지가 Lodash에 의존하고 있어서, 3단계나 깊숙이 숨겨져 있을 수도 있습니다. 어느 쪽이든, 보안 검사에서 Lodash의 EOL(지원 종료) 경고가 뜰 때마다 "네, 알고는 있는데... 지금 당장 이 문제를 해결해야 할까요?"라고 생각해보신 적이 있을 겁니다.

망설이는 게 틀린 일은 아닙니다. 그리고 분명히 당신만 그런 게 아닙니다.

Lodash는 2012년부터 가장 널리 사용되는 자바스크립트 라이브러리 중 하나로, npm 생태계에서 꾸준히 가장 많이 의존되는 패키지로 꼽혀 왔습니다. 이 라이브러리는 간단한 프로토타입부터 수백만 명의 사용자를 처리하는 엔터프라이즈 애플리케이션에 이르기까지 모든 곳에 활용되고 있습니다. Lodash 버전의 지원이 종료될 때, 이는 단순히 하나의 패키지를 업데이트하는 문제가 아닙니다. 기존 기능을 쉽게 손상시킬 수 있는 복잡한 의존성 구조를 헤쳐 나가야 하는 과제이기도 합니다.

Lodash의 지원 종료(EOL) 버전이 공식적으로 지원 기간을 벗어났더라도, Lodash를 기반으로 한 애플리케이션을 안전하게 유지하고 규정 준수 요건을 충족시키는 방법에 대해 알아보겠습니다.

Lodash의 릴리스 주기는 어떻게 운영되는가

지원 종료 시 어떤 일이 발생하는지 자세히 살펴보기 전에, 먼저 Lodash의 라이프사이클이 실제로 어떻게 작동하는지 함께 확인해 봅시다. 솔직히 말해서, 이를 주의 깊게 주시하지 않는다면 어느 날 갑자기 깨달을 수 있습니다. 패치 없이 수년 동안 Lodash의 EOL 버전이 코드베이스에 그대로 남아 있었다는 사실을 말이죠.

Lodash는 일부 프레임워크처럼 엄격한 시간 기반 릴리스 일정을 따르지 않습니다. 대신 기능 완성도, 버그 수정, 보안 패치 등을 기준으로 새 버전을 출시합니다. 주요 버전(예: 3.x에서 4.x)은 수년 동안 유지될 수 있으며, 보안 문제나 버그가 발견될 때마다 이를 해결하는 증분 패치 릴리스가 제공됩니다.

실제로는 다음과 같습니다:

Lodash 3.x 2015년에 출시되어 문자열 메서드, 함수형 프로그래밍 유틸리티, ES6 호환성을 도입했습니다. v4가 출시되기 전까지 약 1년 동안 사용되었습니다.

Lodash 4.x dropped in 2016 with major changes; it removed old IE < 9 support, introduced a 4KB core build, and modernized the entire codebase. This version has been the primary release line for nearly a decade, with 4.17.23 being the latest stable release from January 2026, which includes a security fix for CVE-2025-13465.

그렇다면 수년 동안 같은 버전을 계속 사용하다 보면 어떻게 될까요? 바로 여기서 상황이 복잡해집니다. Lodash는 Node.js나 Bootstrap처럼 공식적이고 정해진 일정에 따라 지원 종료 공지를 발표하지는 않습니다. 하지만 지원 지원 정책 페이지 를 게시하여 어떤 버전이 적극적으로 지원되고 있는지, 어떤 버전이 지원 종료되었는지를 기록하고 있습니다. 오래된 버전은 단순히 패치 지원을 중단하게 되며, 커뮤니티는 새로운 릴리스로 넘어갑니다. 만약 지원이 종료된 버전에서 취약점이 발견되더라도 공식적인 수정 패치는 제공되지 않습니다.

Lodash의 EOL이 실제 운영 환경에 미치는 영향

좋아요, 공식 지원이 중단된다고 치죠. 뭐 대수롭지 않은 일이죠, 그렇죠? 코드는 여전히 잘 돌아가고 있고, 모든 게 정상적으로 작동하는데, 굳이 걱정할 필요가 있을까요?

자, 불편한 진실을 말씀드리자면, 패치 지원이 중단된다고 해서 취약점이 더 이상 나타나지 않는 것은 아닙니다. 사실 공격자들은 지원이 중단된 Lodash 버전을 여전히 사용 중인 조직을 노리곤 하는데, 바로 그 취약점들이 패치되지 않을 것임을 알고 있기 때문입니다.

실제 사례를 들어볼까요? Lodash는 특히 프로토타입 오염과 관련된 보안 문제의 기록이 잘 알려져 있습니다. 그 이력을 살펴보겠습니다:

CVE-2021-23337 (CVSS 7.2): template 함수의 명령어 주입 취약점. 이 취약점은 매우 심각하며, 원격 인증 공격자가 특수하게 조작된 요청을 전송하여 임의의 명령어를 실행할 수 있습니다. 4.17.21 이전의 모든 버전에 영향을 미칩니다.

CVE-2020-8203 (CVSS 7.5): merge, mergeWith및 defaultsDeep 함수입니다. 공격자는 Object에 속성을 주입하여 서비스 거부(DoS)를 유발하거나 심지어 임의 코드 실행까지 일으킬 수 있습니다. 4.17.19 이전 버전에 영향을 미칩니다.

CVE-2020-28500 (CVSS 5.3): toNumber, trim, trimEnd 함수입니다. 공격자는 지나치게 긴 문자열을 전송함으로써 애플리케이션이 무한정 멈춰버리게 할 수 있습니다.

CVE-2019-10744 (CVSS 9.1): 또 다른 프로토타입 오염 결함으로, 이번에는 생성자 페이로드를 사용하여 Object에 속성을 주입합니다. 4.17.12 이전 버전에 영향을 미칩니다.

CVE-2019-1010266 (CVSS 4.0): Date 핸들러의 제어되지 않은 리소스 소비로 인한 서비스 거부(DoS) 취약점. 4.17.11 이전 버전에 영향을 줍니다.

CVE-2018-16487 (CVSS 6.5): defaultsDeep, merge, mergeWith. 이 메서드는 모든 객체에 적용될 기존 속성을 수정할 수 있게 해줍니다.

CVE-2018-3721 (CVSS 5.3): __proto__ 수정 시 발생하는 프로토타입 오염으로, 공격자가 모든 객체의 속성을 추가하거나 수정할 수 있게 됩니다.

패턴이 보이시나요? Lodash에서는 프로토타입 오염(prototype pollution) 취약점이 계속해서 발견되고 있으며, 이는 바로 Lodash를 편리하게 만들어주는 유틸리티 함수들을 표적으로 삼고 있습니다. 이는 단순한 이론적 학문적 문제가 아닙니다. 이는 “아, 아마 업데이트해야겠네”라는 수준의 상황을 본격적인 규정 준수 악몽으로, 혹은 더 나아가 실제 보안 침해 사고로까지 번질 수 있는 실제적인 보안 문제입니다. Lodash의 지원 종료 버전을 사용 중이라면, 공식 패치가 제공되지 않는 상태에서 이러한 모든 취약점에 노출되어 있는 셈입니다.

이러한 Lodash 지원 종료 버전을 노린 공격이 위험한 이유는 단순히 빈번하게 발생하기 때문만이 아니라, 이러한 공격이 초래할 수 있는 결과 때문입니다. 프로토타입 오염은 서비스 거부(DoS) 공격, 애플리케이션 로직을 파괴하는 속성 주입, 그리고 경우에 따라 원격 코드 실행으로 이어질 수 있습니다. 민감한 데이터나 금융 거래를 처리하는 애플리케이션의 경우, 지원이 종료된 Lodash 버전을 계속 사용한다면 이는 단순한 이론상의 위험이 아닙니다. 이는 언제든 발생할 수 있는 규정 위반 사태입니다.

하지만 다른 라이브러리와 비교했을 때 Lodash의 보안 기능이 특히 흥미로운 점은 바로 이것입니다…

숨겨진 위험: 의존성 트리

대부분의 사람들은 Lodash의 보안 문제를 생각할 때, 자신의 코드에 Lodash를 직접 임포트하고 있는지 여부만 떠올립니다. 하지만 이는 빙산의 일각에 불과합니다. Lodash의 실제 지원 종료(EOL) 위험은 직접적인 의존성에만 있는 것이 아니라, 전체 의존성 트리 곳곳에 숨어 있습니다.

Lodash에 대해 한 가지 알아둘 점은, 이 라이브러리는 직접적인 종속성이 전혀 없습니다. 하나도 없습니다. 다른 어떤 것도 끌어오지 않는 독립적인 유틸리티 라이브러리입니다. 정말 멋지죠?

하지만 관점을 바꿔 보면 진짜 문제가 무엇인지 알 수 있습니다. 바로 Lodash가 npm 생태계 전체에서 가장 많이 의존되는 패키지라는 점입니다. 어느새, Lodash를 명시적으로 설치한 적이 없더라도, 여러분의 node_modules어딘가에 숨겨져 있게 됩니다.

이러한 전이적 종속성(직접 설치하지 않은 패키지들)은 Lodash가 서로 다른 버전으로 여러 번 나타날 수 있는 방대한 의존성 네트워크를 형성합니다. 팀이 package.json에 명시적으로 추가하지 않은 프로젝트도 본 적이 있습니다. 하지만 npm list lodash을 실행하면, Lodash에 의존하는 15개의 서로 다른 패키지가 표시되는데, 그중 일부는 버전 4.17.15, 일부는 4.17.19, 그리고 몇 개는 여전히 3.x 버전을 사용하고 있습니다.

Lodash의 모든 인스턴스는 잠재적인 보안 취약점이 될 수 있습니다. 게다가 직접 설치하지 않은 중첩된 종속성이기 때문에, 보안 감사 과정에서 이를 간과하기가 매우 쉽습니다.

여기서 중요한 점은, Lodash가 지원 종료(EOL)에 이르면 단순히 지원이 중단된 라이브러리 하나를 다루는 문제가 아니라는 것입니다. 해당 Lodash 지원 종료 버전에 의존하는 패키지들로 구성된 전체 생태계를 다루게 되는 것입니다. 다음과 같은 도구들 npm audit 같은 도구를 사용하면 알려진 취약점을 찾아내는 데 도움이 될 수는 있습니다. 하지만 이 도구들이 마법처럼 지원 종료된 버전을 대신 패치해 주지는 못합니다.

그리고 여기서부터 상황이 정말 복잡해집니다. 설령 내일 당장 Lodash를 업그레이드하고 싶더라도, 의존성 구조가 이를 허락하지 않을 수 있습니다. 패키지 A는 호환성을 위해 Lodash 3.x 버전을 필요로 합니다. 패키지 B는 4.17.15보다 새로운 버전에서는 작동하지 않습니다. 패키지 C는 패키지 D에 대한 전이적 의존성을 가지고 있는데, 패키지 D는 3년 동안 업데이트되지 않았으며 최신 버전의 Lodash에서는 오류가 발생합니다.

단순히 “패키지를 업데이트하기만 하면 되는” 일처럼 보였던 작업이, 어느새 “이 엉망진창인 종속성 문제를 모두 풀어야 하는” 대규모 프로젝트로 변해버렸다. 참 즐거운 시간이네.

Lodash 지원 종료 시 고려할 수 있는 대안

좋아요, 현재 사용 중인 Lodash 버전이 지원 종료(EOL) 시점을 앞두고 있거나, 어쩌면 이미 지났을 수도 있겠네요. 이 상황에서 실제로 어떤 선택지가 있을까요?

기본적으로 앞으로 나아갈 길은 세 가지가 있습니다. 각 경로를 현실적으로 살펴보겠습니다.

옵션 1: 다음 주요 버전으로 업그레이드

이건 누구나 하는 “공식적인” 답변입니다. 그냥 최신 버전의 Lodash로 업그레이드하세요! 문제 해결! 걱정 끝!

그리고 보세요, 많은 팀에게 있어 이건 정말로 올바른 선택입니다. 최신 버전의 Lodash는 확실히 더 우수합니다. 보안 문제가 해결되고 성능이 향상되었으며 유용한 기능들도 추가되었으니까요.

하지만 주요 버전으로의 마이그레이션을 진행할 때, “그냥 업그레이드하면 된다”는 말이 실제로 무슨 뜻인지 잠시 진지하게 생각해 볼까요?

먼저, 코드베이스 전체를 검토하여 호환성 문제를 일으킬 수 있는 변경 사항이 있는지 확인해야 합니다. Lodash는 버전 간에 API 명칭이 변경되거나, 동작이 미묘하게 달라지거나, 더 이상 사용되지 않는 함수가 추가되는 등 여러 차례의 API 변경이 있었습니다. 그런 다음 모든 종속성을 업데이트하고, 해당 종속성들이 실제로 최신 버전의 Lodash를 지원하는지 확인해야 합니다. 이어서 기존 동작에 의존하는 코드를 리팩토링해야 합니다. 수십 개에 달할 수도 있는 마이크로서비스 전반에 걸쳐 배포를 조율해야 하며, 프로덕션 환경에서 문제가 발생할 경우를 대비해 롤백 계획을 수립해야 합니다.

최신 의존성을 사용하고 테스트 커버리지가 탄탄한 소규모 앱이라면? 아마 몇 주면 끝낼 수 있을 겁니다. 하지만 Lodash에 전이적으로 의존하는 수백 개의 패키지가 얽혀 있는 방대한 엔터프라이즈 애플리케이션이라면? 수개월에 걸친 마이그레이션 작업이 필요할 것입니다. 광범위한 QA 사이클도 거쳐야 하고, 실제 운영 환경의 부하가 걸려야만 드러나는 미묘한 버그가 발생할 가능성도 매우 높습니다.

Lodash 3에서 4로 넘어가는 과정은 특히나 힘들었습니다. 메서드 이름이 바뀌었고, 체이닝 동작도 달라졌으며, 일부 메서드는 아예 제거되었습니다. 심지어 4.17.x 패치 릴리스에서도 극히 드문 경우에 적용되는 호환성 깨는 변경 사항이 도입되었습니다.

이 모든 것이 불가능한 일은 아닙니다. 단지 계획과 자원, 그리고 시간이 필요할 뿐입니다. 하지만 보안 팀이 최근 취약점 검사에서 발견된 Lodash EOL 경고에 대해 재촉해 올 때면, 이 세 가지는 대개 부족하기 마련이죠.

선택지 2: 대체 기술로의 전환

어떤 팀들은 Lodash의 지원 종료(EOL) 상황을 보고는 “있잖아, 어쩌면 이걸 계기로 전체적인 접근 방식을 다시 생각해 볼 기회일지도 몰라.”라고 생각합니다.

ES6+의 네이티브 메서드로 전환하고, 함수형 프로그래밍을 위해 Ramda를 활용하며, 더 특화된 라이브러리로 옮겨가는 등, 대안을 고려해 볼 만한 확실한 이유가 있습니다. 최신 자바스크립트에는 다음과 같은 내장 메서드가 있습니다. Array.map(), Object.assign(), Promise.all() 는 많은 Lodash 유틸리티를 대체할 수 있습니다.

하지만 이것이 무엇을 의미하는지 스스로를 속이지 말자. 이제 단순한 라이브러리 업그레이드 문제가 아니다. 전면적인 리팩토링을 앞두고 있는 셈이다. 그리고 리팩토링은 누구나 예상하는 것보다 훨씬 더 복잡해지는 특이한 성질을 가지고 있다.

“Lodash를 네이티브 메서드로 대체하기만 하면 되겠지”라고 시작했던 일이 금세 “잠깐만, 구형 브라우저를 위한 폴리필을 추가하고, 모든 유틸리티 함수를 다시 작성하고, 코딩 표준을 업데이트하고, 팀원들에게 함수형 프로그래밍 패턴을 다시 교육해야 하며, 아, 그리고 새 시스템을 구축하는 동안 기존 시스템도 유지 관리해야 한다”는 상황으로 번지게 됩니다.

그 유연성은 정말 매력적입니다. 일정이랑 비용은요? 막상 구체적으로 계획해 보면 대개 꽤나 현실을 직시하게 되죠.

옵션 3: TuxCare의 연장 지원

모든 것을 바꿔줄 해결책은 바로, 수명 종료된 소프트웨어의 보안을 전문으로 하는 기업들이 제공하는 연장 지원 서비스입니다.

TuxCare의 Lodash용 Endless Lifecycle Support(ELS)는 바로 이러한 상황을 위해 특별히 설계되었습니다. 준비가 되지 않은 상태에서 서둘러 업그레이드하거나 애플리케이션 전체를 리팩토링할 필요 없이, 현재 사용 중인 Lodash 버전을 계속 사용하면서도 정식 지원되는 버전과 동일한 수준의 보안 지원을 받을 수 있습니다.

작동 방식은 다음과 같습니다. TuxCare는 지원 종료된 Lodash 버전에 영향을 미치는 새로운 CVE를 모니터링하고, 해당 버전에 보안 수정 사항을 적용한 뒤 철저한 테스트를 거쳐 기존 환경과 완벽하게 통합되는 패치를 제공합니다. 이는 현대화를 회피하는 것이 아니라, 보안 위험에 노출되지 않은 상태에서 여러분의 일정에 맞춰 전략적으로 현대화를 추진하는 것입니다.

이는 단순히 시간을 벌기 위한 조치가 아닙니다. 엔터프라이즈급 보안과 규정 준수를 유지하면서 업그레이드 로드맵에 대한 주도권을 확보하는 것입니다.

Lodash EOL 업그레이드를 서두를 때 발생하는 진정한 비용

보안 대시보드에 표시되는 Lodash EOL 경고 때문에 당황한 팀들이 강제로 Lodash 업그레이드를 시도할 때 실제로 어떤 일이 벌어지는지 이야기해 봅시다.

팀이 규정 준수나 보안 문제로 인한 압박을 받아 주요 라이브러리 업그레이드를 비현실적인 일정에 강행할 때, 예상 가능한 문제들이 발생합니다:

지원 업무량 증가: 테스트 중에 발견되지 않았던 모든 버그들? 이제 운영 환경에서 하나둘씩 나타나기 시작합니다. 지원 팀은 이상한 동작에 대한 문의로 업무가 마비될 지경인데, 그중 절반은 Lodash 메서드의 동작 방식에 있는 미묘한 차이에서 비롯된 것입니다.

시스템 불안정성: 아마도 새로운 Lodash 버전에서 일부 전이적 의존성에 에지 케이스 버그가 있었을 수 있으며, 이는 프로덕션 부하가 걸렸을 때만 나타나는 현상일 수 있습니다. 아니면 프로토타입 오염 수정 사항이 merge 의 동작 방식을 변경하여 데이터 처리에 문제를 일으켰을 수도 있습니다. 업그레이드를 서두를 때, 바로 이런 문제들이 새벽 3시에 알림을 울리게 하고 엔지니어들을 매우 짜증 나게 만듭니다.

기술 부채의 누적: 규정 준수를 서두르다 보니 팀원들은 지름길을 택하기 시작합니다. 제대로 된 리팩토링은 생략되고, 임시방편이 쌓여만 갑니다. “나중에 제대로 고치자”는 말이 일상화되고, 6개월이 지나면 처음 시작했을 때보다 훨씬 더 엉망진창인 상황을 마주하게 됩니다.

예산 초과: 업그레이드 문제를 급하게 해결해야 할 때는 예산 초과가 거의 불가피합니다. 긴급 투입된 계약직 인력의 근무 시간, 지연된 기능 출시, 최고의 엔지니어들이 새로운 기능을 개발하는 대신 Lodash 호환성 문제를 디버깅하는 데 소요되는 기회 비용 등 모든 요소가 빠르게 누적됩니다.

업그레이드가 나쁘다는 말은 아닙니다. 서둘러 진행하는 업그레이드는 비용이 많이 들고 위험하다는 뜻입니다. 철저히 계획된 업그레이드와 당황해서 서둘러 진행하는 업그레이드의 차이는 미묘한 수준이 아닙니다. 그 차이는 엄청납니다.

간편한 해결책: Lodash 지원 종료(EOL)를 위한 TuxCare ELS

바로 이 점에서 TuxCare의 Lodash에 대한 ‘무기한 라이프사이클 지원’이 판도를 완전히 바꿔놓습니다.

TuxCare는 지난 10년 넘게 이 일을 해왔습니다. 이들은 지원이 종료된 운영 체제, 런타임, 라이브러리, 애플리케이션에 대한 보안 패치를 제공해 왔으며, 그 수는 12만 개가 넘습니다. 오픈소스 라이프사이클 관리에 대한 전문성을 갖추고 있다고 말할 때, 이는 단순한 마케팅 수사가 아닙니다. 이들은 실제로 대규모로 이를 수행해 왔습니다.

TuxCare의 접근 방식이 다른 점은 무엇인가요?

완벽한 종속성 트리 커버리지: 이는 매우 중요한 사항입니다. Lodash 자체에는 종속성이 없지만, TuxCare는 단순히 지원이 종료된 버전에만 패치를 적용하는 것이 아닙니다. TuxCare는 Lodash가 사용자의 전체 의존성 생태계 내에서 어떤 역할을 하는지 정확히 이해하고 있습니다. 그들은 Lodash에 의존하는 패키지 전반에 걸친 취약점을 모니터링하며, 전체 스택을 안전하게 보호하기 위한 포괄적인 지침을 제공합니다. 이는 단순히 하나의 라이브러리를 보호하는 것이 아니라, 수백 개의 다른 패키지가 의존하는 핵심 유틸리티 계층을 안전하게 지키는 것입니다.

정교하고 자동화된 패치 적용 프로세스: TuxCare의 프로세스는 강력한 자동화와 전문가의 검증을 결합합니다. 이들은 NVD, 벤더 보안 권고, GitHub 보안 피드 등 취약점이 공개되는 모든 채널을 모니터링합니다. CVE가 등록되면 알고리즘 도구와 AI 기반 자동화를 활용해 지원이 종료된 버전에도 수정 사항을 적용한 후, 실제 보안 전문가들이 모든 내용을 검증합니다. 모든 패치는 리포지토리에 배포되기 전에 무결성, 기능성 및 회귀 문제에 대한 철저한 테스트를 거칩니다.

이 과정이 내부적으로 정확히 어떻게 작동하는지 알고 싶다면 다음을 확인해 보세요 TuxCare의 오픈 소스 패치 프로세스에 관한 기술 백서를를 확인해 보세요. 기술 문서치고는 의외로 읽기 쉽습니다.

원활한 통합: TuxCare의 패치는 현재 사용 중인 어떤 워크플로우에도 바로 적용됩니다. npm, Yarn, pnpm 등 어떤 패키지 관리자를 사용하든 ELS 패키지는 문제없이 작동합니다. 프로세스나 도구를 전면적으로 개편할 필요가 없습니다. 이미 구축해 둔 환경을 그대로 계속 사용하면 됩니다.

SLA 기반 신속 대응: 새로운 취약점이 공개되면 TuxCare는 실제 서비스 수준 계약(SLA)에 기반한 패치를 제공합니다. 누군가가 언젠가 수정 패치를 역포트해 주기를 손꼽아 기다릴 필요가 없습니다. 예측 가능한 일정에 따라 즉시 적용 가능한 보안 업데이트를 제공받으며, 문제가 발생할 경우 보장된 지원을 받을 수 있습니다.

비용 효율성: 연장 지원(ELS)에 대해 사람들이 놀라워하는 점은 바로 대체 방안보다 비용이 훨씬 저렴하다는 사실입니다. 엔지니어링 시간(팀의 실제 시간당 요율 기준), 테스트 주기, 외부 업체 비용, 잠재적인 가동 중단 시간, 기능 출시 지연, 그리고 기회 비용을 모두 합산해 보면, ELS는 일반적으로 그 비용의 극히 일부만 소요됩니다. 게다가 고강도 마이그레이션 프로젝트로 인해 팀원들이 지치게 만들 필요도 없습니다.

규정 준수 및 투명성: TuxCare의 모든 릴리스에는 패치된 내용에 대한 완전한 가시성이 제공됩니다. 어떤 CVE가 해결되었는지, 어떤 구성 요소가 수정되었는지, 그리고 소프트웨어 부품 목록(SBOM) 내의 모든 내용을 어떻게 검증할 수 있는지에 대한 상세한 문서를 확인할 수 있습니다. 이는 규정 준수 감사 및 보안 보고에 있어 매우 중요합니다.

시작하는 방법

지원 종료된 버전을 사용 중이시라면, 현재 실제로 이용 가능한 버전을 확인하시려면 TuxCare에서 제공하는 실시간 CVE 추적기 를 운영하고 있어, 특정 버전을 조회하여 어떤 취약점이 패치되었는지 확인할 수 있습니다. 이는 어떤 보안 지원 범위를 받을 수 있는지 파악하는 꽤 간단한 방법입니다.

더 자세한 내용을 원하시나요? TuxCare의 ‘Lodash를 위한 무제한 라이프사이클 지원’ 페이지를 방문하시면 지원되는 버전, 가격, 그리고 실제 구현 방식에 대한 정보를 확인하실 수 있습니다.

Lodash EOL로 인해 시스템이 위험에 처하지 않도록 하세요

Lodash가 버전 3에서 4로 진화하면서 실질적인 개선 사항, 향상된 성능, 최신 자바스크립트 관행, 더 깔끔해진 코드, 그리고 중요한 보안 수정 사항이 도입되었습니다. 이는 분명한 장점들이며, 새로 시작하신다면 Lodash 4.17.21 이상 버전을 사용하는 것이 확실히 가치가 있습니다.

하지만 만약 Lodash의 불확실한 릴리스 일정에 맞춰 업그레이드할 경우 심각한 혼란을 초래할 수 있는 기존 애플리케이션을 유지 관리하고 있다면 어떻게 해야 할까요? Lodash의 지원 종료(EOL)가 반드시 ‘패닉 상태’나 ‘보안 악몽’을 의미하는 것은 아닙니다.

여러 가지 선택지가 있습니다. 실질적인 선택지 말이죠. 비즈니스에 정말로 필요한 시점에 신중하게 업그레이드를 계획할 수 있습니다. 기술적으로 타당한 이유가 있다면 다른 대안을 모색할 수도 있습니다. 또는 확장 지원 서비스를 활용하여 보안과 규정 준수를 유지하면서, 취약점 공개로 인해 어쩔 수 없이 조치를 취해야 하는 상황이 아니라 본인의 일정에 맞춰 결정을 내릴 수 있습니다.

Lodash의 지원 종료에 따른 보안 상황을 잘 대처하는 팀들이 반드시 예산이 가장 많거나 코드베이스가 가장 최신인 팀들만은 아닙니다. 오히려 위험을 인식하고, 실제 가능한 선택지를 파악하며, 앞으로 나아갈 방향에 대해 신중한 결정을 내리는 팀들이 바로 그들입니다.

현재 Lodash EOL(지원 종료)을 염두에 두고 계신다면, TuxCare가 제공하는 서비스를 확인해 보시는 것이 좋습니다. 준비가 되지 않은 상태에서 성급하게 업그레이드를 진행하는 것보다, 실제로 원하는 업그레이드 계획을 세우는 동안 현재 보유한 환경을 안전하게 유지하는 것이 더 현명한 다음 단계라는 것을 알게 되실 수도 있습니다.

방문하기 TuxCare의 오픈소스 소프트웨어를 위한 'Endless Lifecycle Support' 를 방문하여, 확장된 지원이 필요한 기간 동안 전체 오픈소스 스택을 어떻게 보호할 수 있는지 확인해 보세요.

요약