LoopBack 3의 지원 종료와 점점 더 규모가 커지고 있는 API 마이그레이션

주요 내용

• LoopBack 3는 2020년 12월에 커뮤니티 지원 종료 시점을 맞이했으며, 더 이상 업스트림에서 수정 사항이 제공되지 않습니다.
• LoopBack이 IBM API Connect에 포함되어 있다면, 먼저 해당 제품의 수명 주기를 확인하십시오.
• LoopBack 4는 완전히 새로 작성된 버전이기 때문에, 일반적인 ‘버전 올리기 및 오류 수정’ 방식의 업그레이드 계획은 적용되지 않습니다.
• 위험의 상당 부분은 제한된 전이적 종속 관계에 기인하는데, 이는 npm audit fix 도달할 수 없습니다.

LoopBack 3는 모델, 커넥터, 접근 제어 및 생성된 엔드포인트를 결합함으로써 정교한 API 개발을 신속하게 수행할 수 있게 했습니다. 바로 이러한 추상화 요소들 때문에 LoopBack 4로의 마이그레이션은 단순한 의존성 업데이트가 아닌 아키텍처 차원의 프로젝트가 되는 것입니다.

커뮤니티 지원은 2020년 12월에 종료되었습니다. 유일하게 기록된 예외는 IBM API Connect를 통해 제공된 중대한 버그 및 보안 수정 사항이었으나, 해당 경로는 적용 대상이었던 제품 버전과 함께 이후 폐쇄되었습니다. 한편, LoopBack 3 프로젝트에 대해 스캐너가 보고하는 내용의 상당 부분은 프레임워크 패키지 자체보다는 종속성 트리에 속하는 경향이 있습니다.

이 글은 LoopBack 3의 지원 종료 시점이 지났고, 마이그레이션 과정이 사실상 재작성과 다름없으며, 해당 API가 시스템의 핵심 부하를 담당하고 있는 상황에서 어떻게 해야 할지에 대해 다룹니다.

비즈니스를 구현한 API 프레임워크

LoopBack 3은 결국 매우 중요하게 드러난 한 가지 면에서 뛰어났습니다. 사용자가 모델을 정의하고, 커넥터를 연결하며, 액세스 제어를 설정하면 LoopBack은 이를 바탕으로 작동하는 REST 엔드포인트를 생성해 주었습니다. 그것도 매우 빠르게 말이죠. 몇 년이 지나면, 이러한 모델 정의들은 아무도 문서화하지 않았음에도 조직의 통합 계층으로 자연스럽게 자리 잡게 됩니다. LoopBack 3을 떠나는 데 있어 어려운 부분은 프레임워크 코드 자체가 아니라, 모델 정의, 후크, ACL 내에 축적된 비즈니스 로직입니다.

LoopBack 3 모델에서 생성된 60개의 REST 엔드포인트를 보유한 물류 회사를 상상해 보세요. 두 개의 내부 앱이 이 엔드포인트들에 의존하고 있습니다. 파트너사 통합 시스템은 파트너사가 제어하는 일정에 따라 이 엔드포인트들을 호출합니다. 이 모든 시스템은 Node.js 12가 설치된 가상 머신(VM)에서 실행되는데, 부팅 순서를 이해하던 마지막 직원이 수년 전에 퇴사한 탓에 아무도 이 VM을 재구축하려 하지 않습니다.

그런 시스템의 경우, 버전 업그레이드는 마이그레이션 전략이 아니며, 이는 이후의 모든 의사결정에 영향을 미칩니다. 이를 무시하고 다른 방식으로 접근한다면, 패치되지 않은 API가 여전히 운영 환경에 남아 있는 상태에서 마이그레이션이 지연되는 결과가 초래될 가능성이 높습니다.

LoopBack 3의 지원 종료가 실제로 의미하는 바는 무엇인가

커뮤니티의 지원이 끊기면서 LoopBack 3에는 새로운 기능이 추가되지 않을 뿐만 아니라, 커뮤니티 주도의 버그 수정 활동도 더 이상 이루어지지 않습니다. 프로젝트의 README 파일은 나머지 사항에 대해 단호하게 밝히고 있습니다. 더 이상 풀 리퀘스트를 접수하지 않으며, 커뮤니티 사용자에 대한 지원도 제공하지 않는다는 것입니다. 장기 지원 정책은 다소 유연한 편으로, 유지보수 담당자가 커뮤니티에서 제출한 중대한 버그 수정안을 검토할 여지를 남겨두고 있습니다. 두 문서 모두 IBM API Connect를 통한 중대한 버그 수정에 대한 동일한 제한적인 예외 사항을 언급하고 있으며, 이 두 문서는 해당 제품이 아직 지원 기간 중이던 시기에 작성되었습니다.

이 모든 것 뒤에는 간과하기 쉬운 지원 정책도 있습니다. LoopBack의 장기 지원 (LTS) 정책은 ‘유지보수 LTS ’를 릴리스가 해당 단계에 진입했을 당시 지원되던 Node.js LTS 버전과 연계시켰습니다. 해당 Node.js 버전의 유지보수가 종료되면, 이에 대응하는 LoopBack 라인도 유지보수 기간이 종료되었습니다. Maintenance LTS에서는 새로운 주요 Node.js 버전에 대한 지원 추가가 명시적으로 허용되지 않았는데, 이는 지원되는 Node.js 세대가 수년 전에 이미 확정되었다는 것을 우회적으로 표현한 것입니다.

유용한 팁: LoopBack이 IBM API Connect v5 또는 v2018을 통해 번들로 제공된 경우, IBM 대체 솔루션이 있다고 단정하기 전에 제품 수명 주기를 확인하십시오. v5에 대한 기본 지원은 2022년 4월 30일에, v2018에 대한 기본 지원은 2023년 4월 30일에 종료되었으며, 두 버전 모두에 대한 연장 지원은 2023년 12월 31일에 종료되었습니다. 현재 IBM은 두 버전 모두 코드 수정이나 보안 패치를 제공하지 않는다고 밝히고 있습니다. 이 경로는 이미 막혀 있으며, 이는 오픈 소스의 EOL(제품 수명 주기 종료) 날짜만이 여러분에게 이미 기한이 만료된 유일한 시한이 아니라는 것을 의미합니다.

공개 패키지 이력에서 바로 확인할 수 있는 한 가지 신호가 있습니다. 최신 LoopBack 3 릴리스는, [email protected], 여전히 npm을 통해 제공되고 있으며, 새로운 상류 개발 작업은 LoopBack 4 패키지에 집중되어 있습니다. 프로젝트의 주된 관심사는 바로 그곳에 있습니다.

루프백 4가 단순히 번호를 바꾼 루프백 3이 아닌 이유

LoopBack 4는 현재 활발히 개발 중인 버전입니다. 또한 처음부터 완전히 새로 작성된 버전이기도 합니다. 핵심은 TypeScript를 우선으로 하며, 의존성 주입과 IoC 컨테이너를 기반으로 구축되었고, LoopBack 3를 특징지었던 ‘모델과 부트 스크립트’ 방식 대신 컨트롤러와 리포지토리가 사용됩니다. 확장 모델도 달라졌습니다. 이는 패키지 관리자를 통해 달성하는 최종 목표가 아닌, 새로운 프로그래밍 모델입니다.

따라서 대부분의 작업은 LoopBack 3 고유의 규칙을 기반으로 구축된 애플리케이션 부분에서 이루어집니다. 이는 대개 부트 스크립트와 이에 의존하는 순서, 원격 메서드와 이에 연결된 작업 훅, 권한 모델을 정의하는 ACL, 믹스인 및 커넥터 구성, 모델 JSON 규칙에 기반한 모든 요소, 그리고 하위 소비자들이 이미 배포하고 있는 생성된 클라이언트 SDK 등을 의미합니다.

작업 규모를 솔직하게 평가하세요. 일반적인 프레임워크 업그레이드는 스프린트 단위로 측정될 수 있습니다. 반면 LoopBack 3로의 마이그레이션은 쉽게 분기 단위로 소요될 수 있으며, 예상 소요 시간은 깔끔하게 이식할 수 있는 애플리케이션 코드보다는 모델 정의에 포함된 로직의 양에 따라 달라집니다.

현실 점검: “그저 업그레이드일 뿐”이라는 가정이 바로 이러한 프로젝트를 좌초시키는 원인입니다. 간단한 로직만 적용된 12개의 엔드포인트는 소규모 팀이 처리할 수 있는 범위의 프로젝트입니다. 반면, 권한 모델을 반영한 ACL이 적용된 200개의 생성된 엔드포인트는 별도의 예산 항목이 필요한 아키텍처 프로그램이며, 이는 당연히 그럴 만한 가치가 있습니다.

API가 귀하가 통제할 수 없는 통합 시스템에 데이터를 제공하는 경우, 다른 사항을 결정하기 전에 보안 마감 기한과 재작성 마감 기한을 분리하십시오. 이 두 가지는 서로 다른 시간표이며, 이를 혼동하면 서둘러 재작성해야 하는 상황이 발생하고, 그 결과 파트너사에 대한 약속을 지키지 못해 대가를 치르게 될 것입니다.

연구 결과는 실제로 어디에서 나온 것일까

LoopBack 3 프로젝트의 종속성 트리를 열어보면 대개 금세 일정한 패턴이 드러납니다. 프레임워크 자체의 코드는 위험 요소의 일부에 불과합니다. 계속해서 나타나는 이름들은 여러 단계 아래에 위치해 있으며, 사용 중인 커넥터와 락파일에 따라 다음과 같은 것들이 포함되는 경향이 있습니다. qs, lodash, body-parser, nodemailer, strong-remoting, strong-globalize, 더 이상 사용되지 않는 shortid, glob, inflight, 그리고 underscore.string. 일부는 LoopBack 패키지의 직접적인 종속성입니다. 상당수는 위쪽 종속성들에 의해 간접적으로 끌려 들어온 전이적 종속성입니다.

이 프레임워크에는 그 자체의 자문 이력이 있으며, 그 시작과 끝 모두에서 교훈을 얻을 수 있다. 이 2020년 11월 30일자 LoopBack 보안 권고 에서 발생한 초기 단계의 오염 문제를 다뤘습니다. @loopback/rest, 여기에는 다음을 포함하는 JSON 페이로드가 constructor 수용되었습니다. CVE-2020-4988로 등록된 이 취약점은 버전 8.0.0 및 그 이전 버전에 영향을 미쳤으며, 9.0.0에서 수정 사항이 적용되었습니다. 이는 LoopBack 4 코드인데, 프레임워크 수준의 수정 사항이 이제 해당 버전에 반영되기 때문에 오히려 중요한 점입니다. 이 2022년 8월 6일자 공고 PostgreSQL을 사용 중이라면 꼭 읽어봐야 할 글입니다. 이 글은 확장 기능을 통한 심각한 SQL 인젝션 취약점을 다루고 있기 때문입니다. contains 필터 적용 loopback-connector-postgresql 5.5.0 이하 버전. 해당 필터가 커넥터에 접근할 수 있을 때 문제가 발생하는데, 여기에는 다음과 같이 구성된 데이터 소스도 포함됩니다. allowExtendedProperties: true 그리고 커넥터 메서드를 직접 호출하는 코드. 버전 5.5.1에서는 입력 값 정화 기능이 추가되었으며, 해당 권고문에는 아직 업그레이드를 할 수 없는 팀을 위한 해결 방안이 제시되어 있습니다.

화면에 정확히 어떤 내용이 표시되는지는 락파일, Node.js 버전, 그리고 프로젝트의 직접 의존성에 따라 달라집니다. 프로젝트 간에 공통적으로 적용되는 것은 그 구조입니다. 이러한 버전 중 일부는 LoopBack의 패키지 범위나 그 상위 패키지에 의해 제한을 받는데, 이것이 바로 자동 수정 기능이 호환되는 수정된 버전을 선택하지 못하게 하는 원인입니다.

주의하세요: 대우 npm audit fix --force LoopBack 3 프로젝트에서 고위험 변경 사항으로 간주됩니다. 일반 npm audit fix 사용자가 지정한 범위 내에 있는 업데이트만 설치합니다. 메타취약점 체인이 루트 프로젝트에 도달하면, 이를 해결하려면 해당 범위 외부의 변경이 필요할 수 있습니다. 이 시점에서 npm은 --force, 이는 해당 문서에 따르면 지정한 종속성 범위를 벗어난 모듈을 설치하며, 여기에는 SemVer의 메이저 버전 변경 사항도 포함됩니다. 이렇게 오래된 소스 트리에서는, 이런 이유로 한가로운 오후가 앱이 부팅되지 않는 상황으로 바뀌게 됩니다. 다음 명령을 실행하세요. npm audit fix --dry-run --json 먼저 그 내용을 읽어보세요.

실무에서 유념해야 할 점은 두 가지 목록을 따로 관리해야 한다는 것입니다. 하나는 리프 종속성을 제거함으로써 해결할 수 있는 문제점이고, 다른 하나는 트리 상위의 제약 조건으로 인해 해결이 차단된 문제점입니다. 이 두 목록에는 완전히 다른 해결 방안이 필요하며, 이를 혼동하면 스프린트를 낭비하게 됩니다. 또한 이것이 바로 여기에서 타전적 커버리지가 다른 어떤 패치 작업보다 더 중요한 이유이기도 합니다. 적용 가능한 취약한 종속성을 그대로 둔 채로 해결책을 마련한다면, 해당 문제점은 실제로 해결된 것이 아니기 때문입니다.

올바른 길 선택하기

단 한 가지 정답은 없지만, 현실적으로 선택할 수 있는 방안은 많지 않습니다. 로직이 충분히 단순해서 작업을 실제로 완료할 수 있는 수준이라면, LoopBack 4를 기반으로 작고 검증된 서비스를 재구축하세요. 아키텍처가 더 이상 비즈니스 요구를 충족하지 못하는 API는 플랫폼을 전환하세요. 잘못된 설계를 새로운 프레임워크로 그대로 가져가면, TypeScript에서도 똑같은 문제가 반복될 뿐이기 때문입니다.

서둘러 마이그레이션을 진행할 경우, 현재 배포 환경에 실제로 적용되는 취약점보다 더 즉각적인 운영 위험이 발생할 수 있는 상황에서는 Secure LoopBack 3을 그대로 유지하십시오. 이렇게 하면 재작성 가능성을 완전히 배제하는 척하지 않으면서도 시간을 벌 수 있습니다.

부하를 처리하는 API의 경우, 스트랭글러 패턴이 바로 이를 구체적으로 구현한 방식입니다. 외부 계약이 안정적으로 유지되도록 LoopBack 3 API 앞에 호환성 파사드를 배치한 다음, 그 뒤의 기능을 하나씩 옮겨 나갑니다. 이렇게 하면 뒤편을 재구축하는 동안에도 파트너들은 계속해서 동일한 URL을 호출할 수 있습니다.

그 창은 여전히 수정이 필요하며, 제공되는 내용은 현재 사용 중인 릴리스 버전에 따라 달라집니다. TuxCare의 엔드투엔드 수명 주기 지원(ELS) 현재 TuxCare가 관리하는 npm 레지스트리를 통해 드롭인 대체품으로 제공되는 LoopBack 1.10.0 및 2.42.0에 대한 문서를 다루고 있습니다. 함께 제공되는 오버라이드 목록은 스캔 보고서를 읽는 모든 사람에게 흥미로운 부분인데, 이는 qs, body-parser, underscore.string 최상위 패키지에서 멈추지 않고 트리 전체를 처리합니다. 파사드가 LoopBack 2 서비스를 앞세우고 있는 경우, 재빌드 실행 중에 보안 시계가 처리됩니다. 3.x 버전의 경우, 계획에 포함시키기 전에 해당 릴리스에 대한 적용 범위를 확인하시기 바랍니다.

간단히 말하자면 이렇습니다. 논리가 단순하고 엔드포인트 수가 적다면 LoopBack 4로 재구축하고 일정을 잡으면 됩니다. 모델 기반 권한 관리와 파트너 통합이 필요한 경우, 파사드 뒤에서 단계적으로 재작성해야 하며, 기존 인터페이스는 해당 릴리스에 대한 지원이 지속되는 동안 안전하게 유지해야 합니다. 또한 LoopBack이 IBM API Connect를 통해 도입된 경우, 무엇보다 먼저 제품 지원 문제를 해결해야 합니다.

TuxCare의 루프백 처리 방식

TuxCare는 프레임워크와 그 종속성 트리를 추적한 다음, 패치를 적용하기 전에 각 보안 권고 사항이 해당 릴리스에 실제로 적용되는지 여부를 판단합니다. 적용 가능성을 최우선으로 하고, 불필요한 정보는 차후에 처리하는 방식인데, 눈앞에 보이는 내용의 상당 부분이 전이적인 성격을 띠고 있을 때 이는 특히 중요합니다.

수정 사항은 프레임워크 업그레이드로 제공되는 대신 지원되는 버전으로 역포트되며, 해당 패키지는 지원이 종료된 기존 버전을 그대로 대체할 수 있는 형태로 공개됩니다. 이러한 구분은 매우 중요합니다. 생성된 엔드포인트는 다른 팀들이 의존하는 계약과 같기 때문에, 응답 형식을 변경하는 ‘수정’은 하류에 있는 모든 팀에게 회귀 현상을 초래하기 때문입니다.

지원 모델은 즉흥적으로 운영되는 것이 아니라 문서화되어 있습니다. 공개된 목표 기간은 CVSS 7.0 이상의 ‘높음’ 및 ‘매우 높음’ 등급 발견 사항의 경우 공개 후 14일, ‘중간’ 등급은 60일, ‘낮음’ 등급은 90일이며, 보고된 문제에 대한 초기 대응은 3일 이내에 이루어집니다. 이 모든 사항은 계약상 보장이 아닌 상업적으로 합리적인 노력의 범위로 규정됩니다. TuxCare가 빌드하는 모든 패키지에는 SBOM이 포함되어 제공되며, CycloneDX VEX 문서는 각 패키지 버전과 함께 배포되고 매 릴리스마다 업데이트되므로, 감사 추적을 통해 특정 아티팩트 버전에 어떤 알려진 CVE가 영향을 미치고 어떤 CVE는 영향을 미치지 않는지 기록됩니다. 이러한 추적성은 문서화된 기록이 필요한 규제 환경에서 그 가치를 입증하며, 티켓 기반의 서면 에스컬레이션 절차가 이를 보장합니다. TuxCare는 업스트림 프로젝트가 아니며, 그렇게 행세하지도 않습니다. 이 작업은 업스트림의 관심이 LoopBack 4로 옮겨간 후, 프로덕션 시스템을 위해 체계적으로 수행되는 백포팅 작업입니다.

대상 패키지의 실시간 CVE 현황을 확인하려면 TuxCare CVE 트래커를 참고하시기 바랍니다.

OpenJS 생태계에서 LoopBack의 위치

LoopBack은 OpenJS 재단의 At-Large 프로젝트입니다. IBM 계열사인 StrongLoop가 2021년 6월 이 프로젝트를 재단에 기증했으며, 이듬해 인큐베이션 단계를 거쳐 At-Large로 승격되었습니다. 재단의 ‘생태계 지속 가능성 프로그램( ESP)’은 지원 종료된 버전이나 구버전에 대한 상업적 지원을 제공하기 위해 마련되었으며, 파트너사의 수익 일부는 참여 유지보수자와 재단의 활동을 지원하는 데 사용됩니다. TuxCare는 골드 회원 및 ESP 파트너로 참여했으며, 이 프로그램은 비독점적이므로 상업적 지원이 유지보수자가 파트너사가 지원하는 버전을 포함하여 어떤 버전이든 공개적으로 지원하지 못하게 막지는 않습니다.

LoopBack 4가 적절한 선택일 수도 있습니다. 하지만 이 경로를 패키지 업데이트로 취급하는 것은 훌륭한 팀이 엉터리 계획을 세우게 되는 방식입니다.

요약

기사 이름

LoopBack 3 지원 종료 및 이것이 귀하의 API에 미치는 영향

설명

LoopBack 3는 2020년에 지원 종료되었으며, LoopBack 4는 단순한 업그레이드가 아닌 완전히 새로 작성된 버전입니다. 실제 마이그레이션 비용과 TuxCare가 어떻게 도움을 주는지 확인해 보세요.

작성자

로한 티말시나

게시자 이름

TuxCare

게시자 로고