수명 주기가 끝난 소프트웨어: 신입 개발자들에게는 아무도 말해주지 않는 사실

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

주요 내용

지원 종료된 소프트웨어는 대개 정상적으로 계속 실행되지만, 상류 개발 측에서 보안 수정 사항 제공이 중단되면 새로 발견된 취약점에 대해서는 더 이상 상류 패치를 받을 수 없게 될 수 있습니다.
지원 종료(EOL)된 종속성을 업그레이드하는 작업은 단순히 버전을 올리는 것만으로는 거의 해결되지 않습니다. API 호환성 문제, 전이적 종속성, 회귀 테스트 등으로 인해 이 작업이 수 주간에 걸친 엔지니어링 프로젝트로 번질 수 있기 때문입니다.
락파일, 종속성 모니터링, 확장된 수명 주기 지원은 마이그레이션의 필요성을 없애주지는 않지만, 사고 발생 시가 아닌 본인의 일정에 맞춰 마이그레이션을 진행할 수 있게 해줍니다.

현대적인 개발 환경에서는 매번 npm install 명령은 신뢰의 행위입니다. 여러분은 직접 작성하지 않은 코드를, 한 번도 만난 적 없는 사람들이 유지 관리하는, 누구도 보장해 준 적 없는 지원 일정에 따라 가져오고 있는 것입니다. 이러한 신뢰는 핵심 라이브러리, 프레임워크, 런타임 또는 기타 의존성이 지원 종료(EOL)에 도달하면 벽에 부딪히게 됩니다.

신입 개발자에게는 지원 종료(EOL) 소프트웨어가 의존성 보고서에서 끊임없이 표시되는 성가신 경고에 불과해 보일 수 있습니다. 애플리케이션은 여전히 빌드되고, 운영 환경도 정상적으로 가동되고 있습니다. 겉보기에는 아무런 문제가 없어 보이기 때문에, 오히려 EOL을 과소평가하기 쉬운 것입니다.

업스트림 유지보수가 종료되면 해당 버전에 대한 보안 패치도 중단됩니다. 소프트웨어는 수년 동안 계속 작동할 수도 있습니다. 하지만 그 소프트웨어에 대한 다음 취약점이 발견되더라도 업스트림에서 수정 패치를 제공하지 않을 수 있으며, 이때 “그냥 업그레이드하세요”라는 조언은 위험할 정도로 자주 틀린 경우가 많습니다.

‘붉은 깃발’의 현실

소프트웨어의 수명 종료(EOL)에 대한 오해를 풀기 위해서는, 긴급 상황이 발생하기 전에 이를 제대로 이해해야 합니다. EOL이 반드시 기술적 결함을 의미하는 것은 아니며, 해당 패키지를 설치한 개발자의 잘못도 아닙니다. 소프트웨어에는 수명 주기가 있으며, 유지보수 담당자들은 결국 시간과 자원을 다른 곳에 투자해야 할 때가 오기 마련입니다.

중요한 구분은 바로 이것입니다: 작동하는 소프트웨어와 지원되는 소프트웨어는 같은 것이 아닙니다.

버전이 EOL(지원 종료) 단계에 도달하면, 일반적으로 업스트림 공급업체나 커뮤니티는 해당 버전에 대한 보안 패치 제공을 중단합니다. 그렇다고 해서 코드가 하룻밤 사이에 취약해지는 것은 아닙니다. 이는 나중에 해당 버전에 영향을 미치는 취약점이 발견되더라도, 더 이상 업스트림에서 제공하는 패치를 받을 수 없을 수도 있음을 의미합니다. 저는 이를 마치 열쇠를 가진 사람이 아무도 없는 자물쇠에 비유합니다. 오늘은 문이 여전히 잠겨 있지만, 내일 누군가가 그 자물쇠를 해제하는 방법을 알아낸다고 해도, 업스트림 측에서는 다시 와서 자물쇠를 교체해 줄 사람이 아무도 없을 것입니다.

또한, 공급업체 라이프사이클 정의가 귀사의 보안 상태에 어떤 영향을 미치는지 더 잘 이해하기 위해 ‘제품 수명 종료(End of Life)’와 ‘지원 종료(End of Support )’에 대한 당사의 전체 가이드를 읽어보실 수도 있습니다.

EOL이 당신을 찾아오기 전에 미리 파악하기

거의 어떤 것도 스스로 알리지 않습니다. 패키지를 설치할 때 “유지보수자가 2022년에 다른 곳에서 일자리를 얻어 이슈에 더 이상 응답하지 않는다”는 경고 메시지가 뜨지 않습니다. 직접 찾아봐야 하며, 의존성이 EOL(지원 종료)되었거나, 사용 중단되었거나, 사실상 유지보수가 중단되었을 수 있다는 징후들은 대개 눈에 띄는 곳에 있습니다:

레지스트리 목록에 표시된 사용 중단 공지. 때로는 후속 패키지를 가리키기도 하고, 때로는 아무 곳도 가리키지 않기도 한다.
프로젝트의 일반적인 출시 주기를 훨씬 넘긴 최종 게시일
단 한 명의 유지보수자, 또는 모든 계정이 활동을 멈춘 유지보수자 목록
답변이 없는 이슈 트래커의 보안 보고서를 열어보세요
두 번 전 버전에서 조용히 지원이 종료된, 공개된 지원 표
CI가 자체적으로 EOL 상태인 런타임 버전에 대해서만 테스트하도록 구성됨

공식적으로 발표된 지원 종료(EOL) 날짜는 주시할 가치가 있지만, 이는 약속이 아닙니다. 제가 계속해서 예로 드는 것이 바로 Node.js 16입니다. 이 버전의 지원 종료일은 원래 2024년 4월로 예정되어 있었으나, 내부에 번들된 OpenSSL 1.1.1 라이브러리의 지원 종료 시기와 맞추기 위해 7개월 앞당겨져 2023년 9월 11일로 변경되었습니다. Node 16을 고정 버전으로 지정하고 2024년 중반으로 마이그레이션을 계획했던 팀들은 업스트림에서 내린 결정으로 인해 1년 가까운 여유 기간을 잃게 되었습니다.

특정 패키지가 공식적으로 사용 중단되고 후속 버전이 지정된 경우, 당장 급한 문제가 발생하기 전에 지금부터 마이그레이션 범위를 파악하기 시작하세요. 단순히 오래되었지만 여전히 정상적으로 작동하는 패키지라면, 해당 버전을 고정하고 관찰 목록에 추가한 뒤, 담당자를 지정하여 대체 패키지를 백로그에 등록하세요.

오류가 발생한 API와 회귀 테스트

지난 몇 년간, “그냥 업그레이드하면 되지”라는 옛말은 셀 수 없이 많이 들어왔습니다. 우리 모두 그런 경험을 해봤을 겁니다. 처음에는 실제 개발 현장의 복잡함에 서서히 적응해 나가다가, 점차 선임 직책으로 올라갈수록 시야가 넓어지죠. 경험이 풍부한 개발자들은 EOL(지원 종료) 라이브러리를 대체하는 일이 단순히 버전 번호만 바꾸는 것만큼 간단하지 않다는 사실을 잘 알고 있습니다.

대규모 업그레이드에는 API의 호환성 파괴적 변경, 더 이상 사용되지 않는 함수, 호환되지 않는 플러그인, 변경된 런타임 요구 사항 등이 포함될 수 있습니다. 사소한 의존성 변경이라도 이에 의존하는 모든 구성 요소에 대한 회귀 테스트가 필요할 수 있으며, 실제 애플리케이션에서 이러한 테스트를 수행하는 데는 며칠에서 몇 주가 소요될 수 있습니다.

40명으로 구성된 SaaS 팀이 여전히 EOL(지원 종료)된 Node 16 베이스라인을 사용하고 있다고 상상해 보세요. 런타임 버전만 업데이트해도 네이티브 모듈 재빌드, 기존 구성 형식을 더 이상 지원하지 않는 테스트 실행기, 함수 시그니처가 아닌 기본 동작이 변경된 몇 가지 패키지 등이 연쇄적으로 발생할 수 있습니다. 이는 CI에서는 통과하지만 실제 운영 환경에서는 실패하는 유형의 호환성 문제입니다. 더 복잡한 환경에서는 통합 기능 재빌드, 다운스트림 종속성 검증, 팀 간 릴리스 조정 등의 작업까지 더해집니다.

또한 Knockout.js EOL 지원 가이드에서 레거시 프레임워크의 수명 종료(EOL) 관리에 대해 더 자세히 알아보실 수 있습니다.

그렇기 때문에 신입 개발자들이 이러한 복잡한 문제를 혼자서 해결하도록 내버려 두어서는 안 되며, “그냥 업그레이드하면 된다”는 지나치게 단순화된 조언에 현혹되어서도 안 됩니다. 업그레이드가 장기적으로 볼 때 확실히 올바른 해결책일 수도 있습니다. 하지만 안전하게 업그레이드하는 것은 단순히 버튼을 누르는 것이 아니라, 하나의 엔지니어링 프로젝트입니다.

스프린트 예상 작업량에 대해 누구도 확정하기 전에 스파이크 작업에 시간 제한을 설정하고, 해당 작업을 페어 프로그래밍으로 진행하세요. 범위가 정해지지 않은 업그레이드는 티켓이 아니라 추측에 불과합니다.

타동사 의존성 변화

현대 소프트웨어 프로젝트는 매우 복잡합니다. package.json, pom.xml, 또는 requirements.txt 는 결국 애플리케이션에 포함되는 요소의 일부에 불과합니다. 이러한 직접 의존성 아래에는 전이적 의존성이 층층이 쌓여 있습니다.

어떤 프로젝트가 패키지 A에 의존하고, 패키지 A가 패키지 B에 의존하며, 패키지 B가 패키지 C를 끌어오는 경우가 있을 수 있습니다. 여러분은 패키지 C를 직접 선택한 적이 없음에도 불구하고, 그 코드는 결국 여러분의 의존성 트리에 포함되게 됩니다. 또한, 수십 개의 직접적인 의존성이 수백 개 또는 수천 개의 설치된 패키지로 이어지는 경우가 흔합니다.

이로 인해 최상위 의존성 목록에서 예상되는 것보다 훨씬 더 광범위한 보안 노출 영역이 생성됩니다. 여러 단계 깊숙이 숨겨진 취약점은, 의도적으로 설치한 프레임워크가 모든 대시보드에서 완벽하게 정상적으로 보일지라도 여전히 심각한 문제를 일으킬 수 있습니다. 최신 도구들은 이러한 간접적 의존성 중 상당수를 식별할 수 있습니다. 예를 들어, GitHub의 의존성 그래프와 Dependabot은 매니페스트나 락파일에서 해결 가능한 취약한 전이적 의존성을 찾아내지만, 개발자들은 여전히 실제로 배포되는 내용이 무엇인지 명확히 파악할 수 있어야 합니다.

지원 종료(EOL)된 구성 요소가 해당 트리 구조에 포함되면 문제 해결이 더 어려워집니다. 취약점이 존재한다는 사실을 알고 있다가, 의존하고 있는 버전에 대해 보안 패치가 전혀 제공되지 않는다는 사실을 뒤늦게 알게 될 수도 있습니다.

실제 의존성 위험은 매니페스트에 나열된 직접적인 의존성 목록에만 국한되지 않습니다. 이는 완전히 해결된 의존성 트리 전체를 의미하며, 보안 도구는 바로 이 부분에 대한 가시성을 확보해야 합니다.

‘완료’ 뒤에 숨겨진 비용

“완료”의 정의는 다소 부담스러운 주제일 수 있지만, 이는 모든 프로젝트의 시작 단계에서 반드시 논의되어야 하며 팀 방침에 확고히 자리 잡아야 합니다. 유지 관리는 일회성 작업이 아닙니다. 이는 지속적으로 실천해야 하는 과정입니다.

기술적 부채는 언제나 존재할 것입니다. 저도 과거에 그로 인해 꽤 고생한 적이 있습니다. 하지만 수명 종료 단계에 접어든 종속성들은 그 기술적 부채 중 일부를 보안 부채로 바꿔버립니다.

이러한 기술적 부채는 결국 리팩토링이 필요한 수천 줄의 코드, 롤백해야 하는 실패한 업그레이드, 최신 릴리스로 인해 호환성이 깨져 고정된 종속성, 혹은 다른 시스템들이 너무 많이 의존하고 있어 아무도 손대려 하지 않는 레거시 애플리케이션 등의 형태로 나타납니다. 문제를 무시한다고 해서 종속성이 사라지는 것은 아닙니다.

결국 치명적인 취약점이 발견되거나, 스캐너가 문제점을 감지하기 시작하거나, 감사관이 지원이 중단된 소프트웨어가 왜 여전히 운영 환경에 남아 있는지 묻거나, 다른 프로젝트에서 갑자기 최신 버전을 요구하게 되는 상황이 발생합니다. 그러면 미리 계획할 수 있었던 마이그레이션 작업이 긴급 상황으로 변하고, 팀은 당황한 상태에 빠지게 됩니다.

더 나은 접근 방식은 EOL 소프트웨어를 조기에 파악하고, 어떤 시스템이 해당 소프트웨어에 의존하는지 파악한 뒤, 마이그레이션 계획을 수립하는 동안 해당 소프트웨어를 업그레이드할지, 교체할지, 격리할지, 아니면 계속 보안을 유지할지 신중하게 결정하는 것입니다. 담당자도 없고 목표 시한도 정해지지 않은 EOL 패키지는 기술적 부채가 아닙니다. 이는 시작 시점이 지연된 미해결 문제일 뿐입니다.

방어와 갑옷의 돔

EOL(제품 수명 주기 종료) 소프트웨어 문제를 완화하려면 개별 CVE에 대응하는 것만으로는 부족합니다. 현재 사용 중인 소프트웨어에 대한 가시성을 확보하고, 환경으로 유입되는 요소를 통제하며, 상류 공급업체의 지원이 중단될 경우를 대비한 계획을 수립해야 합니다.

이를 소프트웨어 라이프사이클을 둘러싼 “방어막”을 구축하는 것으로 생각해 보십시오. 패키지가 활발히 유지보수되는 동안 공급망 위험을 줄이고, 이미 운영 환경에 배포된 종속성을 모니터링하며, EOL 이후에도 계속 사용되는 구성 요소에 대한 보안 전략을 마련해야 합니다.

핀으로 고정하고 잠그세요

결정론적 빌드 환경은 첫 번째 방어선 중 하나입니다. npm 프로젝트의 경우, 잠금 파일( package-lock.json –을 버전 관리 시스템에 커밋하고 npm ci 를 적절히 활용하십시오. 이렇게 하면 빌드할 때마다 다른 의존성 트리를 자동으로 해결하는 대신, 락파일에 기록된 정확한 버전의 의존성을 설치하게 되며, 락파일과 package.json 파일 간의 버전이 일치하지 않을 경우 명확하게 오류를 반환합니다.

캐럿(^)나 틸드(~)와 같은 버전 범위는 여전히 타당한 용도가 있으므로, 이를 모든 곳에서 제거하는 것이 목표는 아닙니다. 목표는 버전 정책과 lockfile이 어떻게 상호작용하는지 이해하여, 의존성 업데이트가 우발적이기보다는 의도적으로 이루어지도록 하는 것입니다. 예를 들어,는 패키지와 그 의존성이 선언한 시맨틱 버전 제약 조건을 준수합니다. 즉, 버전 범위를 통해 개별적으로 승인하지 않은 호환 가능한 업데이트도 허용될 수 있습니다.

사람들이 자주 간과하는 한 가지 세부 사항: package.json 에 정확한 버전을 고정하는 것은 직접 의존성만 제어합니다. 새로운 의존성 해결이나 의존성 업데이트 시, 전이적 의존성은 여전히 상위 패키지가 선언한 범위대로 선택됩니다. 그런 다음 커밋된 락파일은 해결된 트리를 기록하며, npm ci 는 잠긴 트리를 재현 가능하게 설치합니다. 특정 전이적 버전을 강제로 적용해야 하는 경우, npm의 overrides 필드를 사용할 수 있습니다(Yarn의 ).

프로젝트가 라이브러리라면, 사용자가 중복을 제거할 수 있도록 버전 범위를 유지하세요. 배포된 애플리케이션이라면, 정확한 버전을 사용하고 신중한 업데이트 주기를 따르는 편이 좋습니다.

핵심은 재현성입니다. 개발, CI, 스테이징, 프로덕션 환경은 팀이 식별하고, 재현하며, 검토할 수 있는 의존성 상태를 기반으로 구축되어야 합니다. 이를 통해 개발 현장에서 가장 듣기 싫어하는 말 중 하나인 “음, 제 컴퓨터에서는 잘 되는데요.”라는 말을 없앨 수 있습니다.

SCA 툴링이 구세주로 등장하다

소프트웨어 구성 분석(SCA)과 종속성 보안 도구를 활용하면, 사람이 직접 검토하는 것만으로는 도달할 수 없는 수준까지 취약점을 면밀히 파악할 수 있습니다. 의도적으로 설치한 패키지가 무엇인지뿐만 아니라, 해당 패키지가 내부적으로 어떤 구성 요소를 불러왔는지도 파악해야 합니다.

GitHub의 종속성 그래프와 Dependabot은 지원되는 생태계 내에서 취약한 직접 및 전이적 종속성을 식별하고, 팀이 우선적으로 주의를 기울여야 할 부분을 파악할 수 있도록 도와줍니다. Snyk 역시 종속성 트리를 구축하며, 취약한 간접 종속성에 대한 업그레이드 경로를 제안할 수 있습니다.

또한, 알려진 CVE 탐지만으로는 공급망 문제를 완전히 해결할 수 없습니다. 악성 패키지나 보안이 침해된 패키지는 CVE가 할당되기 훨씬 전부터 위험할 수 있습니다. Socket과 같은 도구는 이 문제를 다른 관점에서 접근하여, 의존성 변경 사항을 모니터링하고 패키지의 동작을 분석함으로써 예기치 않은 네트워크, 파일 시스템 또는 셸 접근과 같은 위험 요소를 파악합니다.

꼭 한 가지만 하려면, 애플리케이션에 실제로 포함된 해결된 종속성을 점검하고, 어떤 발견 사항이 병합을 차단해야 하는지에 대한 정책을 설정하세요. 더 나아가고 싶다면, 새로 추가되거나 업데이트된 종속성에 대한 행동 분석을 추가하세요. CVE 기록이 깨끗하다고 해서 새로 침해된 패키지에 대해 아무것도 말해주지 않기 때문입니다.

한 가지 주의할 점은, 아무도 선별 검토하지 않는 결과를 생성하는 스캐너는 실제보다 더 많은 사항이 처리되고 있다는 잘못된 인상을 줄 수 있다는 것입니다. 조치가 필요한 결과는 담당자에게 전달하고, 이를 어떻게 처리해야 하는지 명확히 정의하십시오.

신입 개발자가 명심해야 할 교훈은 간단합니다. 애플리케이션에 어떤 데이터가 입력되는지 파악하고, 그 데이터가 왜 존재하는지 이해하며, 무언가 변경되었을 때 이를 어떻게 감지할지 알아두어야 합니다.

하네스 ELS

<br />

이상적인 세상이라면, 지원 종료(EOL)된 모든 종속성을 즉시 업그레이드할 수 있을 것입니다. 하지만 실제 운영 환경은 그렇게 돌아가지 않습니다. 프레임워크를 마이그레이션하려면 애플리케이션의 일부를 다시 작성해야 할 수도 있습니다. 런타임 업그레이드로 인해 비즈니스에 필수적인 종속성이 제대로 작동하지 않을 수도 있습니다. 오래된 라이브러리가 시스템의 기반에 자리 잡고 있어, 6개월 후 다른 프로젝트가 완료될 때까지는 아무도 손을 댈 수 없는 상황일 수도 있습니다.

그렇다고 해서 보안 문제를 무시하는 것이 용납될 수는 없습니다. 이는 팀들이 때때로 “즉시 업그레이드” 와 “보안 패치가 제공되지 않는 지원 종료된 소프트웨어를 계속 사용한다”라는 두 가지 선택지 사이에서 타협점을 찾아야 한다는 뜻입니다.

바로 그곳에서 Endless Lifecycle Support (ELS)가 중요한 역할을 합니다. TuxCare ELS는 지원이 종료된 운영 체제, 런타임, 라이브러리 및 애플리케이션에 대해 지속적인 보안 패치를 제공하므로, 팀은 향후 마이그레이션을 계획하는 동안 실제로 의존하고 있는 버전의 보안을 유지할 수 있습니다.

라이프사이클 초기 단계에 있는 오픈소스 패키지의 경우, SecureChain은 는 또 다른 보안 계층을 추가합니다. SecureChain은 npm, PyPI, Maven, Go 모듈, crates.io, PHP와 같은 공개 레지스트리를 대신하는 선별된 대안 역할을 수행하며, 검증된 소스 코드로부터 재빌드되고 지속적으로 모니터링 및 패치되는 패키지를 제공합니다. 또한 Artifactory, Nexus, GitHub Packages와 같은 리포지토리 관리 도구와 드롭인 호환성을 갖추고 있습니다. 업스트림 유지보수가 결국 종료되더라도, ELS는 지원 대상 패키지에 대한 수정 사항을 계속 제공할 수 있습니다. 이를 통해 사용자는 활발히 유지보수되는 오픈 소스 단계부터 EOL(지원 종료) 이후 사용 단계에 이르기까지 지속적인 서비스를 누릴 수 있습니다.

더 중요한 점은, 이를 통해 개발 팀에 여유를 줄 수 있다는 것입니다. 업스트림 지원이 종료된 후 취약점이 발견되었다는 이유로 서둘러 마이그레이션을 진행할 필요 없이, 애플리케이션에 적합한 일정에 따라 업그레이드를 계획하고, 테스트하며, 실행할 수 있습니다.

그렇다고 해서 현대화의 필요성이 사라지는 것은 아닙니다. 다만 현대화가 반드시 비상 상황에서 이루어져야 한다는 가정은 사라지는 것입니다.

최종 생각

소프트웨어 지원에 만료일이 있다고 해서 보안에도 만료일이 있는 것은 아닙니다. 팀들은 문제가 터지고 나서야 비로소 관심을 기울이고, 그제서야 모두가 허둥지둥 대처하곤 합니다. 우리는 이러한 사고방식을 바꿔야 합니다.

개발자로서 변화를 이끌어내기 위해 보안 전문가일 필요는 없습니다. 다만, 의존성에도 수명 주기가 있다는 점, 전이적 코드가 중요하다는 점, “아직 작동한다”는 것이 “아직 지원된다”는 뜻은 아니라는 점, 그리고 무턱대고 “업그레이드” 버튼을 누르는 것이 보안 전략이 될 수 없다는 점을 이해해야 합니다.

애플리케이션이 어떤 요소에 의존하고 있는지 파악하십시오. 잠금 파일을 커밋하십시오. 종속성 트리를 모니터링하십시오. 중요한 구성 요소가 지원 종료(EOL) 시점에 도달하는 시기를 파악하고, 절박하게 필요해지기 전에 미리 업그레이드 경로를 마련해 두십시오. 즉각적인 마이그레이션이 현실적으로 어려운 경우, 보안 패치를 받을 수 없는 지원 종료된 소프트웨어가 프로덕션 환경에 방치되지 않도록 주의하십시오.

이번 주에는 작은 것부터 시작해 보세요. lockfile을 열어 그 안에서 가장 오래된 패키지를 찾아, 마지막으로 게시된 시점을 확인해 보세요. 신입 개발자든 수석 아키텍트든 상관없이, 이러한 습관은 여러분의 스택을 보호하는 데 큰 도움이 될 뿐만 아니라, 잊혀진 의존성 때문에 모두가 큰 문제에 직면하게 되는 날을 피하는 데도 큰 역할을 할 것입니다.

요약