2026년 5월, TanStack의 npm 공급망 사고로 의존성 보안이 다시 한국 스타트업 슬랙 단톡방을 흔들었어요. 내가 짠 코드도 아닌데, 외주사가 두고 간 코드 안의 라이브러리 한 줄 때문에 우리 서비스가 위험해질 수 있다는 걸 새삼 실감한 사람이 많을 거예요. 외주 개발을 의뢰하거나 인계받는 단계에서 흔히 빠뜨리는 것이 바로 오픈소스 의존성·라이선스·공급망 점검이에요. 오늘은 외주 인수 시점에 반드시 점검해야 할 7가지를 정리해 봤어요.
외주사로부터 코드를 받은 후 평균 6~12개월 사이에 사고가 터지는 패턴이 가장 흔해요. 첫째 유형은 라이선스 충돌이에요. GPL 계열 라이브러리가 무심코 포함돼 있다가 우리가 SaaS로 출시할 때 소스 공개 의무가 발목을 잡아요. 둘째는 알려진 취약점 누적이에요. 외주사가 빌드한 시점의 라이브러리가 그대로 1년을 지나면, 평균 23개의 알려진 CVE가 쌓여요. 셋째는 유지보수 단절이에요. 외주사가 쓴 라이브러리가 deprecated되거나 깃허브 아카이브 처리되면, 한 달 안에 보안 패치 경로가 사라져요.
이 세 가지는 외주 계약서에 "보안 책임은 발주처에 귀속" 한 줄로 정리되는 경우가 많아서, 사고가 나도 외주사에 청구할 수 있는 비용이 거의 없어요. 그래서 인수 시점에 점검을 끝내는 게 가장 안전해요.
RFP·계약서에 "최종 산출물에 CycloneDX 또는 SPDX 표준 SBOM을 포함한다"는 항목을 넣으세요. SBOM은 우리 서비스가 어떤 라이브러리를 어떤 버전으로 쓰는지 한 파일에 정리한 거예요. 외주사가 자동 생성 도구(Syft, GitHub의 dependency-graph) 한 번 돌리면 되는 일이라, 추가 비용이 거의 들지 않아요. 인수 후 사고 발생 시 영향 범위를 30분 안에 파악할 수 있게 해 줘요.
license-checker, FOSSA, Snyk License Compliance 같은 도구로 라이선스를 추출하세요. 점검 우선순위는 GPL/AGPL/SSPL → LGPL → 카피레프트 변형 → 비표준 라이선스 순이에요. 우리 비즈니스 모델이 폐쇄형 SaaS라면 AGPL이 포함된 라이브러리는 즉시 제거 대상이에요. 한국 스타트업이 가장 자주 놓치는 라이브러리는 highlight.js, moment-timezone, node-canvas의 일부 버전이에요.
인수일의 package-lock.json, yarn.lock, pnpm-lock.yaml, Pipfile.lock, go.sum을 그대로 보존하세요. 이걸 기준으로 OSV-Scanner 또는 Trivy를 돌려 그날의 취약점 리포트를 PDF로 저장해 두세요. 이 기록이 있어야 6개월 후 "이 취약점은 인수 전에 이미 있었다"를 객관적으로 증명할 수 있어요.
외주사가 GitHub Actions, GitLab CI, CircleCI에 등록해 둔 비밀(secret)·환경변수의 목록을 받으세요. 특히 npm 토큰, AWS IAM 키, Supabase service key, Vercel API 토큰은 인수 즉시 회전(rotate)하는 게 표준이에요. 외주사가 어디 데스크탑 어딘가에 토큰을 평문으로 보관 중일 가능성이 늘 있어요. 비밀 회전 작업은 인수 24시간 이내 완료를 목표로 잡으세요.
.npmrc, .yarnrc, pip.conf에 외주사가 사적으로 설치한 사설 레지스트리 미러가 박혀 있는지 확인하세요. 사설 미러는 외주사가 종료된 후 갱신이 멈추면 그 자체가 공급망 사각지대가 돼요. 또한 --ignore-scripts 옵션이 CI에 적용돼 있는지, 설치 후 자동 실행되는 스크립트가 있는지 검사하세요. AI 코딩 에이전트가 추가한 라이브러리 중에는 설치 스크립트로 텔레메트리를 송신하는 경우가 종종 있어요.
Renovate·Dependabot의 머지 정책을 인수 시점에 다시 짜세요. 자동 머지는 patch 버전까지만 허용하고, minor 이상은 사람 리뷰 필수로 잠그는 게 안전해요. 또한 누가 매주 의존성 PR을 리뷰할지를 명문화해야 해요. 이 책임이 비어 있으면 6개월 안에 minor 업데이트 PR이 70개 이상 쌓이고, 어느 순간 한 번에 적용하면서 큰 사고가 나요.
외주사가 1년 유지보수 계약을 함께 진행한다면, "공급망 침해 발견 시 외주사가 24시간 내 영향 범위 분석을 제출한다"는 조항을 넣으세요. TanStack 사고처럼 외부에서 먼저 알려지는 공격은 인지 후 첫 24시간이 가장 중요해요. 이 SLA가 없으면 외주사는 "그 라이브러리는 우리가 직접 만든 게 아니다"는 답만 반복하게 돼요.
현실적으로 외주사가 자기 결과물을 객관적으로 감사하기는 어려워요. 가능하면 인수 단계에서 제3의 시각으로 의존성·라이선스·CI 환경을 함께 점검할 파트너를 두는 게 안전해요. 포텐랩은 IT 외주·바이브코딩 결과물을 인수하는 프로젝트를 다수 진행하면서 이 7가지 체크리스트를 표준 워크플로우로 운영하고 있어요. 평균 수행완수율 97%를 유지하는 비결도 인수 시점의 의존성·공급망을 단단히 잠그는 데서 시작해요.
외주로 받은 코드, 또는 AI로 만든 MVP를 정식 서비스로 옮기는 단계라면 의존성 점검을 가장 먼저 끝내세요. 30분짜리 점검이라도 6개월 후의 사고를 막아 줘요. 점검과 인수 운영을 함께 맡길 파트너가 필요하면 포텐랩 상담으로 문의해 주세요.