위험한 업그레이드 없이 EOL 소프트웨어를 안전하게 유지하는 방법

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

전 세계 소프트웨어 팀 내부에서는 조용한 위기가 진행 중이지만, 대부분은 보안 감사 결과가 책상 위로 전달되기 전까지는 이를 깨닫지 못합니다. 수년 동안 의존해 온 핵심 라이브러리가 EOL에 도달했거나, 지원 종료(EOL)에 도달한 것입니다. 업스트림 유지보수 담당자들은 이미 손을 뗐습니다. 더 이상 패치도, 수정 사항도 없습니다. 하지만 그 라이브러리는 어떨까요? 여전히 운영 환경 깊숙이 자리 잡고 있으며, 안전하게 리팩토링하는 데만도 수개월이 걸릴 정도로 애플리케이션과 뗄 수 없이 얽혀 있습니다.

지원되는 버전으로 업그레이드하는 일은 주말에 해치울 수 있는 일이 아닙니다. 이는 API 오류, 회귀 테스트, 그리고 본래는 새로운 기능 개발에 투입되어야 할 개발자의 시간을 의미합니다. 그래서 팀은 압박을 받는 팀들이 흔히 그러하듯, 작업을 미루게 됩니다. 그리고 작업을 미루는 동안 취약점은 점점 쌓여만 갑니다.

EOL 위기

웹 개발 분야에서 어느 정도 경력을 쌓아오셨다면, 아마 ‘EOL’이라는 용어에 익숙하실 겁니다. 이는 공급업체나 커뮤니티가 보안 취약점에 대한 패치 제공을 중단하는 시점을 의미합니다. 이것이 여러분에게 어떤 의미일까요? 바로 시간이 카운트다운되기 시작한다는 뜻입니다. EOL은 악의적인 공격자들에게 쉬운 표적을 제공합니다. 바로 운영 환경에서 여전히 실행 중이지만 더 이상 수정 패치를 받지 못하는 소프트웨어입니다. 상류 유지보수자가 코드에서 손을 뗀다고 해서 해당 소프트웨어가 운영 환경에서 사라지는 것은 아닙니다. 여전히 그 자리에 남아 있으며, 잠재적으로 보안이 완전히 노출된 상태일 수 있습니다.

완료 기준

소프트웨어 팀들은 ‘완료 기준(DoD)’이 실제로 무엇을 의미하는지에 대해 끊임없이 고민합니다. 솔직한 대답은 ‘상황에 따라 다르다’는 것이지만, 그 핵심은 ‘안심하고 배포할 수 있는’ 상태가 어떤 모습인지에 대한 공동의 합의입니다. 버전을 업데이트하고, GitHub에 커밋하고, 배포하는 것만으로는 ‘완료’가 아닙니다.

버전 업그레이드를 완료했다고 판단하기 전에 확인해야 할 일련의 과정이 있습니다. 예를 들어, 어떤 프로젝트에서 다양한 API를 사용하고 있는데, 버전 변경 후 해당 API들이 모두 제대로 작동하지 않는다고 가정해 봅시다. 이것이 무엇을 의미할까요? 이는 모든 기능과 연동 부분을 일일이 점검하고 테스트하여 모든 것이 여전히 정상적으로 작동하는지 확인해야 한다는 뜻입니다.

모든 빌드는 성공해야 합니다. 맞습니다. 모든 빌드는 모든 환경에서 반드시 성공해야 합니다. 업그레이드된 버전이 기존 버전과 다르게 동작하여 빌드가 실패할 경우, 다시 성공할 때까지는 추가 테스트를 진행할 수 없으므로 프로세스를 중단해야 합니다.

기능 변경 시에는 철저한 회귀 테스트가 필요합니다. 업그레이드된 버전이 기존 기능을 손상시키지 않았는지 확인하기 위해 모든 기능적 및 비기능적 요소를 테스트해야 합니다. 또한 의존성 구조가 복잡해질수록 회귀 테스트에 소요되는 시간도 길어집니다.

마지막으로, 개발자들의 최종 승인이 필요합니다. 때로는 변경 사항을 검증하기 위해 개발자들을 현재 진행 중인 업무에서 잠시 빼내야 할 때도 있습니다. 이것이 바로 전체 프로세스의 숨겨진 비용입니다. 무언가를 성급하게 ‘완료’라고 단정 짓는 것은 프로젝트 전체의 진행 속도를 저해하기 때문입니다.

아무것도 하지 않기

가만히 앉아서 아무것도 하지 않는 것은 대개 큰 대가를 치르게 되는 실수입니다. 문제를 덮어두는 것은 언제나 가능하지만, 그렇게 함으로써 우리는 해당 제품뿐만 아니라 사용자, 그리고 그 소프트웨어를 기반으로 구축된 다른 모든 제품(지원 종료 여부와 상관없이)에게도 해를 끼치게 됩니다.

새로운 CVE(공통 취약점 및 노출)가 끊임없이 공개되고 있으며, 그중 일부는 필연적으로 여러분이 의존하고 있는 바로 그 패키지에 영향을 미치게 될 것입니다. 보안 스캐너가 이를 감지하기 시작하면 해당 목록은 점점 늘어납니다. 유지보수 담당자가 더 이상 관여하지 않더라도 소프트웨어는 계속 실행될 것입니다. 바로 이때, 소프트웨어의 시작부터 끝까지를 보호하는 방어막이 중요해집니다.

갑옷의 돔

오픈 소스 소프트웨어의 가장 큰 장점은 새로운 취약점이 발견되었을 때 커뮤니티가 패키지를 계속 유지하기 위해 보여주는 헌신과 열정입니다. 우리는 벤더뿐만 아니라 이러한 프로젝트를 뒷받침하는 커뮤니티에게도 큰 빚을 지고 있습니다. 패키지가 EOL에 도달하기 전에 공급망 전체를 먼저 보강하는 편이 더 낫지 않을까요?

단계별로 SecureChain가 등장합니다. Angular 20을 예로 들어 보겠습니다. Angular 22는 현재 적극적으로 지원되는 릴리스인 반면, Angular 20은 LTS 단계로 넘어갔으며 2026년 말에는 모든 공식 지원이 종료될 예정입니다. 이는 바로 미리 대비해 둘 가치가 있는 버전입니다. 여전히 많은 팀에서 생산 환경에 사용 중이고 현재도 지원받고 있지만, 머지않아 지원 종료일이 다가오고 있기 때문입니다.

이제 v20이 지원 종료(EOL)에 도달하기 전, 즉 상류 패치를 계속 받고 있는 동안에도 v20을 둘러싼 ‘방어막’을 구축할 수 있습니다. 지원 종료 전에 소프트웨어를 보호하는 것의 장점은 소스 코드로부터 패키지를 재빌드하고, 악성코드를 검사하며, 지속적으로 패치를 적용하고, 규정 준수 상태를 유지할 수 있다는 점입니다. 이를 통해 개발자와 보안 팀이 주도권을 되찾아 자신들의 방식에 따라 소프트웨어를 유지 관리할 수 있게 됩니다.

이러한 접근 방식은 기술 부채를 적절히 관리하면서 시간과 비용을 절약해 줍니다. 새로운 CVE가 그 어느 때보다 빠르게 등장하고 있는데, 이는 부분적으로 AI 코딩 도구가 취약점의 발견과 우발적인 도입을 모두 가속화하고 있기 때문이며, 이는 결과적으로 더 많은 공급망 공격으로 이어집니다. 전체 라이프사이클에 걸친 접근 방식, 즉 스택 전반에 걸쳐 모든 패키지에 대한 보안을 확보함으로써, ‘공급망 방어막’을 통해 이러한 모든 위협에 선제적으로 대응할 수 있습니다.

마무리

현대 소프트웨어 개발의 현실은, 오픈소스 의존성 라이브러리의 업스트림 유지보수자가 더 이상 관여하지 않는다고 해서 그 중요성이 비즈니스에 덜해진다는 뜻은 아니라는 점입니다. EOL(지원 종료) 패키지에 패치를 적용하지 않는 것은 중립적인 결정이 아닙니다. 이는 해결되지 않은 새로운 CVE가 발생할 때마다 커져만 가는 위험을 감수하겠다는 적극적인 선택입니다.

다행스러운 점은 강제 업그레이드나 업무에 지장을 주는 코드 재작성이 더 이상 유일한 대안이 아니라는 것입니다. 이미 사용 중인 버전에 보안 수정 사항을 역포트(backport)하면, 팀이 로드맵이나 ‘완료 기준(Definition of Done)’을 무너뜨리지 않고도 보안을 유지할 수 있습니다. 보안 범위에 유효 기간이 있어서는 안 되며, 올바른 패치 전략만 마련된다면 그럴 필요도 없습니다.

SecureChain의 전체 라이프사이클 지원 기능을 확인해 보세요 →

요약