Knockout.js는 지원 종료(EOL)되었나요? 현황, 위험 요소 및 보안 유지 방법

주요 내용

• Knockout.js는 공식적으로 지원 종료가 선언된 적이 없습니다. 이 프로젝트는 6년 넘게 새로운 버전을 출시하지 않다가, 2026년 3월에 v3.5.2와 v3.5.3이라는 두 가지 유지보수 릴리스를 내놓았습니다.
• “종료되지 않음”은 “지원됨”과 같은 의미가 아닙니다. LTS도, 보안 SLA도, 공개된 EOL 일정도, 공개된 취약점 공개 정책도 없습니다. 패치 주기를 확약한 적이 없는 프로젝트를 기준으로 패치 주기를 계획할 수는 없습니다.
• Knockout에 대해 등록된 유일한 CVE인 CVE-2019-14862는 3.5.0 버전에서 수정된 중등도 심각도의 XSS 취약점입니다. 이 취약점이 발생하는 코드 경로는 Internet Explorer 7 및 그 이전 버전에서만 실행되므로, 최신 브라우저를 사용하는 환경에서는 실제 악용 위험이라기보다는 주로 스캐너, SBOM 및 감사상의 문제로 간주됩니다.
• 현재 유지보수가 이루어지는 후속 버전이 존재합니다. TKO, 즉 Knockout 4.x 계열은 2026년 4월에 첫 안정화 버전을 출시했으며 Knockout과 호환되는 빌드를 제공하지만, Knockout 3.x에 비하면 그 채택률은 여전히 미미한 수준입니다.
• 현실적인 대안: 공급업체 지원, 자체 패치 관리, 기존 시스템 강화, 또는 단계적 마이그레이션. 일괄적인 재작성은 거의 올바른 첫 번째 조치가 되지 않습니다.

Knockout.js는 많은 개발팀을 당황하게 만드는 애매한 위치에 놓여 있습니다. 이 라이브러리가 더 이상 개발되지 않는다는 공식 발표는 한 번도 없었지만, 2019년 말부터 2026년 초까지 릴리스 활동은 거의 완전히 중단된 상태였습니다. 그러던 중 2026년 3월, 로드맵이나 사전 공지 없이 , 로드맵이나 사전 공지 없이 이루어졌습니다. DNN(구 DotNetNuke) 사이트나 이를 기반으로 구축된 내부 .NET 애플리케이션을 운영 중이라면, 이러한 오랜 침묵과 갑작스러운 활동의 반복이 바로 문제입니다. 예측할 수 없는 요소에 의존하고 있는 셈이기 때문입니다.

이 글에서는 Knockout의 현황, 버전 업데이트 이력, 실제 운영 시스템에 있어 중요한 위험 요소, 그리고 향후 실용적인 방향에 대해 솔직하게 다룹니다. 먼저 솔직한 입장을 밝히자면, 여기서 문제가 되는 것은 패치가 적용되지 않은 라이브러리 자체가 아닙니다. 문제는 “여전히 설치 가능” 와 “예측 가능한 유지보수”사이의 간극이며,사이의 간극이며, 바로 그 간극에서 감사 결과들이 쌓이고, 팀들은 문제를 해결할 신뢰할 만한 경로가 없다는 사실을 깨닫게 됩니다.

Knockout.js는 공식적으로 지원이 종료되었나요?

아니요, 공식적으로는 아닙니다. Knockout.js는 공식적으로 지원 종료로 선언된 적이 없으며, 3.5.2와 3.5.3 버전은 모두 2026년 3월에 출시되었습니다. Trusted Types 지원은 3.5.2 버전에서 도입되었으며, 현재 출시된 버전인 3.5.3까지 이어지고 있습니다. Knockout이 완전히 버려졌다는 주장은 더 이상 그 릴리스 이력과 일치하지 않습니다.

많은 커뮤니티 주도형 자바스크립트 프로젝트는 정식 EOL(지원 종료) 공지를 전혀 발표하지 않습니다. 상류에 상업적 공급업체가 없으며, 만료일이 정해진 지원 계약도 없습니다. 대신 서서히 활기가 사라지는 모습을 보게 됩니다. Git 커밋 횟수는 줄어들고, 미해결 이슈는 쌓여만 가며, 릴리스 간격은 점점 길어집니다. Knockout은 ‘사망’했다기보다는 ‘간헐적으로 유지 관리되고 있다’고 표현하는 것이 가장 적절합니다.

이러한 구분은 이를 어떻게 다루느냐에 있어 중요합니다. 엄밀히 말해 EOL 소프트웨어는 는 계획을 세울 수 있는 명확한 종료일이 정해져 있습니다. 반면, 간헐적으로만 유지 관리되는 라이브러리에는 그러한 종료일이 없기 때문에 관리가 더 어려워질 뿐, 쉬워지지는 않습니다.

현실 점검: Knockout은 약 158,000건의 npm 다운로드 를 기록했습니다. 문서화된 보안 대응 약속이 없는 널리 사용되는 소프트웨어는 감당하기 어려운 위험 요소입니다. 팀들은 이 소프트웨어에 의존하고 있지만, 취약점이 언제, 혹은 과연 해결될지에 대해서는 아무도 약속하지 않았기 때문입니다.

Knockout.js의 주요 이정표 및 버전 출시일

만약 지원 종료(EOL) 날짜가 명시된 깔끔한 LTS 표를 찾으러 이곳에 오셨다면, 안타깝게도 다음과 같은 답변을 드려야겠습니다. Knockout은 LTS 모델을 운영한 적이 없으며, 지원 종료 날짜를 공개한 적도 없습니다. 아래에 나열된 모든 릴리스 날짜는 Knockout 공식 다운로드 페이지를 통해 확인한 것입니다.

그 타임라인의 흐름 자체가 바로 핵심입니다. 2019년 11월의 3.5.1 버전과 2026년 3월의 3.5.2 버전 사이에는 6년 이상의 공백이 있었으며, 이 기간 동안 어떤 버전도 출시되지 않았습니다. 그러다 같은 달에 두 개의 릴리스가 연달아 나왔고, 불과 2주도 채 지나지 않아 npm에서 3.5.2 버전이 더 이상 지원되지 않게 되었으며, 3.5.3에서 수정된 호환성 문제를 유발하는 변경 사항이 포함되어 있다는 공지가 게시되었습니다. 이러한 회귀 현상에는 Knockout이 엄격 모드(strict mode)에서 실행될 때 바인딩이 완전히 실패하는 문제가 포함되어 있었습니다.

6년 만에 두 번의 릴리스만으로는 예측 가능한 보안 업데이트 주기를 확립할 수 없습니다. 이는 수많은 실제 버그를 수정한 유지보수 담당자들을 비판하는 것이 아닙니다. 이는 운영 팀이 무엇을 신뢰할 수 있는지에 대한 지적입니다. 즉, 응답 시간에 대한 공식적인 약속이 공개되어 있지 않으므로, 이를 바탕으로 계획을 세울 수 있는 근거가 없다는 뜻입니다.

주의: 6년이라는 시간 차이로 인해 다음 패치가 곧 나올 것이라고, 혹은 아예 나올 것이라고 가정해서는 안 됩니다. Knockout 보안 문제는 스스로 해결해야 할 수도 있는 사안으로 간주하십시오.

지원되지 않는 Knockout.js 버전을 사용할 경우의 위험

간헐적 유지보수는 계속 미룰 수 있는 마감일이 아닙니다. 이는 이미 처해 있는 상태이며, 최근에 코드를 수정했는지 여부와 관계없이 해당 구성 요소를 실행하는 모든 시스템의 위험 프로필을 형성합니다. 아래에 나열된 위험 요소들은 실제 사고와 실제 감사에서 드러나는 것들입니다.

현재 알려진 CVE 하나와, 이것이 실제로 어떤 영향을 미치는지

Knockout에 대해 하나의 CVE가 등록되었습니다: CVE-2019-14862는 CWE-79로 분류된 중등도 크로스사이트 스크립팅(XSS) 취약점으로, CVSS 3.1 기준 점수는 6.1입니다. 이 취약점은 3.4.2까지의 안정화 버전에 영향을 미치며, 3.5.0 이후 버전에서는 발견되지 않습니다.

이 메커니즘을 이해하는 것은 중요합니다. 왜냐하면 이를 어떻게 대처해야 할지에 영향을 미치기 때문입니다. Knockout은 attr 바인딩에서 name 속성을 특별히 처리하여, 문자열 연결을 통해 요소 이름을 DOM으로 전달했습니다. 이 코드 경로는 Internet Explorer 6 및 7에 대한 임시 해결책으로만 존재하며, Knockout이 IE 7 이하 버전을 감지할 때만 실행됩니다. Knockout 유지보수 담당자들은 최신 브라우저에서는 이 문제를 재현할 수 없었으며, 해당 취약점의 악용 예측 점수는 1% 미만으로 유지되고 있습니다.

따라서 현재 사용 중인 브라우저 환경에서는 실질적인 노출 위험이 거의 제로에 가깝습니다. 문제는 비용의 성격이 다르다는 점입니다. 소프트웨어 구성 분석, SBOM, 고객 보안 설문조사를 수행할 때마다 해당 버전에 대한 미해결 권고 사항이 표시될 것이며, “당사 사용자는 Internet Explorer 7을 사용하지 않습니다”라는 말은 구체적인 수정 조치를 제시하는 것이 아니라, 반드시 제시하고 문서화해야 하는 보완 통제 논거에 불과합니다. 이 권고 사항은 2020년 7월, 2021년 1월, 2022년 4월의 오라클 중요 패치 업데이트(Critical Patch Updates)에서도 언급되었으며, 레드햇(Red Hat)에 의해 추적되었기 때문에 많은 하위 시스템의 인벤토리에 포함되어 있습니다.

널리 퍼지고 있는 내용이라 꼭 바로잡아야 할 점이 하나 있습니다. CVE-2019-14863이 때때로 Knockout의 문제로 오인되곤 합니다. 이는 검증되지 않은 xlink:href 속성과 관련된 AngularJS 보안 권고 사항이며, Knockout과는 아무런 관련이 없습니다. Knockout과 관련된 CVE는 두 개가 아니라 단 하나입니다.

가능한 경우 업그레이드를 진행하는 것이 여전히 올바른 선택입니다. 기술적인 장애물은 거의 없습니다. Knockout은 대개 DNN 설치 환경이나 고객이 쉽게 수정할 수 없는 공급업체가 관리하는 단일 페이지 애플리케이션에 내장되어 있으며, 상류 측에서 이 문제를 해결하도록 압박한 적도 한 번도 없었습니다.

감사 결과 및 지연된 보안 검토

규정 준수 평가는 프론트엔드가 제대로 작동하는지 여부보다는, 타사 코드 내의 취약점을 찾아내고 수정하기 위한 명확한 프로세스를 제시할 수 있는지 여부에 더 중점을 둡니다. 구체적인 사항은 프레임워크마다 다르므로, 이를 정확히 파악해 두는 것이 좋습니다. PCI DSS v4.0.1이 가장 구체적입니다. 이 표준은 타사 구성 요소 목록, 알려진 취약점에 대한 패치 일정을 요구하며, 요구사항 12.3.4에 따라 더 이상 보안 수정 프로그램을 제공받지 않는 소프트웨어에 대해서는 경영진의 승인을 받은 문서화된 검토를 요구합니다. Knockout이 결제 페이지의 일부를 렌더링하는 경우, 스크립트 목록 및 무결성 요구 사항이 추가로 적용됩니다. SOC 2 는 고정된 통제 목록을 규정하지 않으며, 감사인은 귀사가 운영한다고 주장하는 취약점 관리 프로세스를 테스트합니다. HIPAA 보안 규정은 규정 중심이 아닌 위험 분석에 기반을 두고 있으며, FedRAMP 는 정의된 시정 기간을 둔 지속적인 모니터링을 요구합니다.

지원되지 않는 소프트웨어가 있다고 해서 이러한 항목 중 어느 하나라도 자동으로 불합격 처리되는 것은 아닙니다. 다만 이에 대한 검토 사항이 생성되어 이에 답변해야 하며, 문서화된 보안 대응 절차가 없는 종속성의 경우 현재 해당 종속성에 대한 취약점이 공개되어 있지 않더라도 이를 방어하기 어렵습니다. 조달 과정에서 고객들로부터도 비슷한 질문이 제기되는 경향이 있는데, 답변할 수 없는 설문 항목이 계약 체결을 은연중에 지연시킬 수 있습니다.

오픈소스 구성 요소에 대한 벤더 지원 패치 서비스는 바로 이러한 격차를 해소하기 위해 마련된 것입니다. TuxCare의 Knockout.js에 대한 ‘Endless Lifecycle Support’ 는 업그레이드가 고려 대상이 아닐 때 팀들이 선택하는 옵션 중 하나입니다.

주변 스택은 대개 더 큰 위험을 수반합니다

공개된 Knockout 패키지는 런타임 종속성을 선언하지 않습니다. 이 패키지는 독립형 라이브러리이므로, 방대한 Node 또는 PHP 애플리케이션과 달리 취약점을 숨길 수 있는 복잡한 전이적 구조가 없습니다.

위험 요소는 Knockout이 어떤 구성 요소들과 결합되어 있는지에 있습니다. 구형 애플리케이션에서는 Knockout이 jQuery 1.x, Bootstrap 3, RequireJS, 그리고 노후화된 DNN이나 SharePoint 셸과 함께 사용되는 경우가 흔합니다. 사용 중인 버전에 따라, 이러한 구성 요소들에는 이미 알려진 취약점이나 고유한 유지보수 제약 사항이 있을 수 있습니다. 이 경우 Knockout은 전체 구조를 지탱하는 핵심 축 역할을 하게 되는데, Knockout을 업그레이드하려면 주변의 모든 요소를 수정해야 하는 경우가 많기 때문입니다.

이처럼 간헐적으로 관리되던 하나의 라이브러리가 결국 스택 전체에 걸친 제약 조건으로 변모하게 됩니다.

Knockout.js의 지원 전망이 불확실할 때 고려할 수 있는 대안

실질적으로 취할 수 있는 조치는 네 가지입니다. 그중 세 가지는 ‘노크아웃’ 상태를 유지하는 방법이며, 이에 대해서는 이 글에서 다루고 있습니다. 네 번째 방법인 ‘단계적 이전’에 대해서는 다음 섹션에서 설명하겠습니다. 올바른 선택은 애플리케이션을 얼마나 변경할 수 있는지, 그리고 애플리케이션을 얼마나 오랫동안 가동 상태로 유지해야 하는지에 따라 달라집니다. 이 중 어느 것도 ‘아무 조치도 취하지 않는 것’은 아닙니다. 아무 조치도 취하지 않으면 그 대가가 다음 감사나 다음 사고로 미뤄질 뿐이기 때문입니다.

공급업체 지원 서비스 구매하기

여기서 핵심은 애플리케이션 코드를 수정하지 않고도 Knockout을 안전하게 계속 실행할 수 있는지 여부입니다. 벤더의 CMS에 얽매여 있는 대부분의 팀의 경우, 이는 가능하며, 벤더가 제공하는 지원이 가장 번거로움이 적은 방법입니다.

‘확장된 수명 주기 지원’이란, 업스트림 프로젝트에서 보장하지 않는 보안 유지 관리 업무(새로운 취약점 모니터링, 수정 사항의 백포트 적용, 계약에 따른 대응 기한 제공 등)를 제3자가 대신 수행한다는 것을 의미합니다. 이를 통해 지원 약속이 없는 구성 요소를 감사 시에도 문제없이 처리할 수 있는 구성 요소로 전환할 수 있습니다.

Knockout은 런타임 종속성을 전혀 선언하지 않기 때문에, 커버리지 문제는 대부분의 라이브러리보다 더 간단합니다. TuxCare의 ‘Endless Lifecycle Support’ 현재 Knockout.js 버전 2.3.0, 3.2.0 및 3.4.2를 지원하며, TuxCare가 호스팅하는 저장소를 통해 npm으로 CVE 수정 사항을 제공합니다. 애플리케이션을 업그레이드할 수 없고 문서화된 보안 수정 사항이 필요한 경우, 이 서비스를 통해 즉시 마이그레이션하지 않고도 위험 관리 및 규정 준수 업무를 지원할 수 있습니다.

자체 관리형 패치 적용

이 작업을 주도할 수 있는 사내 자바스크립트 보안 전문 인력이 있습니까? 있다면, 문제가 없는 것으로 확인된 버전을 고정하고, 새로운 문제가 발생하는지 모니터링하며, 수정 사항을 자체 포크에 적용할 수 있습니다.

대신 여러분이 유지보수 담당자가 되어야 한다는 점이 단점입니다. 즉, Knockout이나 관련 컴포넌트와 관련된 모든 사항을 파악하기 위해 NVD, GitHub Advisory Database, 업스트림 저장소, 다운스트림 벤더의 보안 권고 사항을 모니터링하고, 패치를 작성 및 테스트한 뒤, 이러한 작업을 무기한으로 지속해야 합니다. 이는 프론트엔드 보안 역량이 뛰어나고, 시스템의 영향 범위가 작으며 그 구조를 명확히 파악하고 있는 팀에게는 효과적인 방법입니다.

지식이 한 명의 엔지니어 머릿속에만 갇혀 있으면 제대로 작동하지 않습니다. 그 엔지니어가 회사를 떠나는 날, 유지보수되던 포크는 어느새 또 다른 유지보수되지 않는 종속성이 되어버립니다.

제자리에 고정하고 봉쇄하기

실제 탈출 계획을 세우는 동안 시간을 벌 수 있을 만큼 폭발 반경을 줄일 수 있을까요? 대개는 가능합니다. 그리고 이것이 가장 잘 활용되지 않는 방법입니다.

실무상: 호환성이 허용되는 경우, CVE-2019-14862의 영향을 받지 않으며 프로젝트의 최신 수정 사항이 반영된 최신 버전인 3.5.3으로 업그레이드하십시오. 그런 다음 제한적인 콘텐츠 보안 정책(CSP)을 적용하고, 추가적인 탐지 및 필터링 계층으로서 웹 애플리케이션 방화벽(WAF) 도입을 고려하십시오. 이 두 가지 조치 모두 취약한 라이브러리에 대한 패치 적용을 대체할 수는 없지만, 향후 대응 방안을 결정하는 동안 공격 표면을 상당히 축소하는 데 도움이 됩니다.

전문가 팁: Knockout 3.5.2부터 도입되어 3.5.3까지 이어지는 Trusted Types 지원 기능은 내부 운영을 위해 ‘knockout’이라는 이름의 정책을 생성합니다. CSP에서 require-trusted-types-for ‘script’를 설정하면 Knockout이 이를 자동으로 처리하지만, trusted-types 지시어를 허용 목록으로 사용하는 경우 Knockout을 해당 목록에 포함시켜야 합니다. 그렇지 않으면 정책 등록이 오류 없이 실패하며, 정책이 적용될 때 Knockout의 HTML 처리 기능이 정상적으로 작동하지 않게 됩니다. Trusted Types는 2026년 2월부터 모든 브라우저에서 지원되므로, 구형 클라이언트에서도 테스트를 진행해야 합니다. 이 기능은 DOM 기반 XSS 취약점에 대한 노출을 줄여주지만, 모든 형태의 XSS를 완전히 제거하는 것은 아닙니다.

Knockout.js의 장기적인 철수 전략 수립

이 글은 마이그레이션 튜토리얼이 아닌 계획 수립을 위한 연습입니다. 목표는 마이그레이션 코드를 작성하는 것이 아니라 의사결정 순서를 정하는 것이며, 이는 모든 접근 방식에서 공통적으로 적용되는 원칙입니다. 즉, 불필요하게 대규모의 ‘빅뱅’ 방식 재작성을 피해야 합니다. 이러한 방식은 배포 위험을 한곳에 집중시키고, 모든 점진적인 보안 개선 작업을 하나의 거대한 마일스톤 뒤로 미루게 되기 때문입니다.

대상 및 상호운용성 모델을 선택하십시오

어떤 프레임워크로 전환할 것이며, 전환 기간 동안 기존 코드와 새 코드는 어떻게 공존하게 될까요? 이에 대한 답변은 크게 두 가지가 있는데, 코드를 전면 재작성하기로 결정하기 전에 비교적 새로운 방식을 먼저 살펴볼 필요가 있습니다.

첫 번째는 Knockout 4.x의 공식 라인인 TKO입니다. 이 프로젝트는 2026년 4월에 첫 안정 버전을 출시했으며, 모듈식이고 TSX 중심의 빌드와 더불어 의도적으로 마이그레이션이 용이하도록 설계된 Knockout 호환 빌드를 제공하고, 3.x에서 4.x로 업그레이드하는 경로에 대한 문서도 마련해 두었습니다. Knockout 프로그래밍 모델을 계속 사용하고자 하는 팀에게 이는 활발히 유지보수되는 코드를 확보할 수 있는 가장 빠른 경로입니다. 단, 채택 현황을 유의해야 합니다. TKO의 호환 빌드는 주당 약 100건의 npm 다운로드에 그치는 반면, Knockout은 10만 건 이상의 다운로드를 기록하고 있습니다. 따라서 자체 테스트 스위트를 통해 검증하고, 이를 확립된 플랫폼이라기보다는 소규모 프로젝트로 취급하는 것이 좋습니다.

두 번째는 주류 프레임워크입니다. Knockout은 특정 DOM 노드에 바인딩되는데, 이 점이 도움이 됩니다. 각 프레임워크가 DOM의 명확하게 구분된 부분을 담당한다면, 기존 Knockout 페이지 내에 React, Vue 또는 Svelte 컴포넌트를 마운트하여 기존 코드와 새 코드를 병행하여 실행할 수 있는 경우가 많습니다. 벤치마크 결과가 아닌, 팀의 기존 기술 역량과 채용 시장을 고려하여 대상 프레임워크를 선택하십시오. Knockout이 DOM의 일부를 새로운 프레임워크에 넘겨주는 상호운용성 경계는 신중하게 설계해야 할 부분입니다. 이 경계가 제대로 정리되지 않으면 마이그레이션 작업이 수개월 동안 지체될 수 있습니다.

스트랭글러 피그 무늬가 있는 시퀀스

스트랭글러-피그(strangler-fig) 패턴은 시스템의 특정 부분을 경로별 또는 기능별로 점진적으로 교체하는 반면, 나머지 레거시 애플리케이션은 계속 실행됩니다. 변경 빈도가 가장 높거나 위험이 가장 큰 부분, 즉 자주 수정하거나 민감한 입력을 처리하는 부분부터 시작하세요. 이렇게 하면 가장 자주 변경되는 코드의 위험 요소를 제거하게 되므로, 초기 단계부터 가치를 극대화할 수 있습니다.

트래픽이 적고 안정적인 화면은 Knockout에서 가장 오랫동안 유지될 수 있으며, 일부는 이전할 가치가 전혀 없을 수도 있습니다.

출구를 측정하고 계측한다

시작하기 전에 “완료”의 기준을 수치로 명확히 정의하세요: 마이그레이션된 바인딩의 비율, 남아 있는 Knockout 의존 경로의 수, 번들 크기, 프론트엔드 스택 전반의 CVE 노출 현황 등입니다. 피처 플래그를 사용하여 마이그레이션된 슬라이스를 토글을 통해 배포하고, 매 빌드 시 의존성 스캐너를 실행하여 위험 건수가 줄어드는 것을 확인하세요.

전문가 팁: 의존성 스캐너 보고서에 Knockout 항목을 추가하고 월별 추이를 그래프로 표시해 보세요. 보고상으로는 순조롭게 진행되고 있는 것처럼 보이지만 Knockout 사용량이 전혀 줄어들지 않는 마이그레이션은 실제로는 순조롭지 않은 것이며, 그래프를 통해 이를 간과할 수 없게 됩니다.

TuxCare로 Knockout.js 애플리케이션의 보안을 유지하세요

Knockout이 완전히 사라진 것은 아니지만, 공개된 일정도 없고 보안 SLA도 없는 프로젝트를 중심으로 계획을 세우면 규모를 가늠할 수 없는 위험을 떠안게 됩니다. 시스템을 계속 가동하든 단계적으로 중단하든 간에, 그 과정에서 보안 대응 책임이 누구에게 있는지 여부는 여전히 미해결 문제로 남아 있습니다.

지금 당장 코드를 재작성할 수 없는 경우, 공급업체가 지원하는 서비스를 이용하면 즉각적인 마이그레이션을 강요받지 않으면서도 Knockout.js에 대한 지속적인 보안 패치와 평가자가 요청할 문서를 제공받을 수 있습니다. TuxCare의 ‘Endless Lifecycle Support’ 은 Knockout.js 버전 2.3.0, 3.2.0 및 3.4.2를 지원하며, npm을 통해 CVE 수정 사항을 제공하므로, 사고 발생 중에 급하게 대응해야 하는 상황 대신 본인의 일정에 맞춰 전환할 수 있는 여유를 확보할 수 있습니다.

자주 묻는 질문

2026년에도 Knockout.js를 실제 운영 환경에서 계속 사용해도 안전한가요?

애플리케이션에 대한 평가가 완료되고 적절한 보안 조치가 취해진 후에는 사용이 가능합니다. 현재 최신 버전인 3.5.3은 CVE-2019-14862의 영향을 받지 않지만, Knockout은 보안 SLA를 공개하지 않으며 예측 가능한 릴리스 주기도 없습니다. 따라서 새로운 개발 시 기본 선택지로 삼기보다는 명시적으로 관리되는 종속성으로 취급해야 합니다.

내 애플리케이션이 어떤 버전의 Knockout.js를 실행 중인지 어떻게 알 수 있나요?

브라우저 콘솔에서 ko.version을 확인하거나, npm 의존성인 경우 npm ls knockout 명령어를 실행해 보세요. DNN과 같은 번들링된 플랫폼의 경우, 해당 라이브러리가 별도로 설치되는 것이 아니라 플랫폼에 포함되어 제공되는 경우가 많으므로, Knockout 파일 헤더나 패키지 매니페스트를 직접 확인해 보세요.

현대 브라우저들이 Knockout.js 지원을 중단하게 될까요?

공식적으로 발표된 브라우저 지원 종료 시한은 없으며, Knockout은 순수 자바스크립트이므로 현재 사용 중인 브라우저에서 문제없이 실행됩니다. 장기적으로 볼 때, 브라우저 API의 변경이나 더 엄격해진 기본 보안 정책으로 인해 구형 애플리케이션에 호환성 문제가 발생할 수 있습니다. 단기적인 위험 요소는 브라우저의 지원 중단이 아니라, 패치 없이 라이브러리와 관련 스택이 노후화되는 것입니다.

마이그레이션 과정에서 Knockout.js가 최신 프레임워크와 공존할 수 있을까요?

대개 그렇습니다. Knockout은 특정 DOM 노드에 바인딩되므로, 각 프레임워크가 DOM의 명확하게 구분된 부분을 담당하는 한, React, Vue 또는 Svelte 컴포넌트를 Knockout과 함께 마운트하고 한 번에 하나의 경로나 기능씩 마이그레이션할 수 있습니다.

Knockout.js에 알려진 CVE가 있나요?

첫 번째: CVE-2019-14862는 3.4.2 버전까지의 안정화 릴리스에 영향을 미치는 중등도 크로스 사이트 스크립팅(XSS) 취약점입니다. 3.5.0 버전 이후에는 영향을 받지 않습니다. CVE-2019-14863은 때때로 Knockout과 관련이 있는 것으로 오인되기도 하지만, 이는 AngularJS에 대한 보안 권고 사항입니다.

요약

기사 이름

Knockout.js는 지원 종료(EOL)되었나요? 현황, 위험 요소 및 보안 유지 방법

설명

Knockout.js는 단 한 번도 지원 종료가 선언된 적이 없으며, 2026년 3월에도 두 차례의 릴리스가 출시되었습니다. 다음은 실제 위험 요소와 보안을 유지하는 네 가지 방법입니다.

작성자

로한 티말시나

게시자 이름

TuxCare

게시자 로고