---
title: "공급망 보안, 이제 개발자 주의력 말고 ‘길목 자동 통제’로 간다"
published: 2026-07-05T07:05:02.941Z
canonical: https://jeff.news/article/4646
---
# 공급망 보안, 이제 개발자 주의력 말고 ‘길목 자동 통제’로 간다

OWASP 서울 챕터 세미나에서 당근과 토스 보안 실무자들이 오픈소스 패키지와 머신러닝 운영 환경의 공급망 위협 대응 사례를 공유했다. 핵심은 개발자 개인에게 조심하라고만 하지 말고, 사내망으로 들어오는 패키지와 모델 아티팩트의 길목에 프록시와 방화벽을 세워 자동으로 통제하자는 것이다.

- 공급망 보안의 결론이 점점 명확해지고 있음. “개발자가 조심하자”가 아니라 “들어오는 길목을 자동으로 막자”임
  - OWASP 서울 챕터 6월 세미나에서 당근과 토스 보안 실무자들이 실제 사내 방어 인프라 구축기를 공유함
  - 주제는 오픈소스 패키지와 머신러닝 운영(MLOps) 환경을 노리는 공급망 공격 대응이었음

- 파이썬 생태계만 봐도 수동 대응은 이미 무리임
  - 파이썬 공식 저장소(PyPI)에는 하루 900개가 넘는 신규 패키지가 계속 올라옴
  - 최근 1년 사이 새롭게 보고된 파이썬 생태계 멀웨어만 2800개를 넘음
  - 이 정도면 개발자 개개인이 패키지 이름, 버전, 배포 시점, 악성 여부를 일일이 판단하는 모델은 사실상 깨졌다고 봐야 함

> [!IMPORTANT]
> 핵심은 보안팀이 개발자를 더 귀찮게 만드는 게 아니라, 개발자가 평소처럼 일해도 위험한 유입이 자동으로 걸러지는 구조를 만드는 것임.

- 당근은 클라이언트 단속 대신 사내 ‘레지스트리 프록시’를 세움
  - 개발자가 외부 패키지 저장소를 직접 바라보는 게 아니라, 회사가 관리하는 공통 패키지 레지스트리를 거치게 한 구조임
  - 이 앞단에서 공통 보안 정책을 적용하면 팀마다 설정이 들쭉날쭉해지는 문제를 줄일 수 있음

- 당근의 핵심 정책 중 하나는 ‘쿨다운’임
  - 배포된 지 얼마 안 된 패키지는 일정 기간 접근을 제한함
  - 악성 패키지는 짧게 올라왔다가 빠르게 피해를 내고 사라지는 경우가 많아서, 초반 유입을 막는 것만으로도 감염 리스크를 낮출 수 있음
  - 당근 측은 기존 위협의 50~60%가 단순 버전 락킹 부재에서 비롯된다고 봄

- 토스가 주목한 다음 전장은 MLOps임
  - 표상영 토스 보안 연구원은 일반 소프트웨어 패키지 공급망 대응은 어느 정도 성숙했지만, 공격자들이 투자 대비 수익(ROI)이 좋은 다음 타깃으로 MLOps를 본다고 설명함
  - 모델 파일, 학습 아티팩트, 커스텀 스크립트가 섞이는 환경은 아직 방어 체계가 덜 정돈된 곳이 많음

- 특히 머신러닝 모델에서 직렬화 포맷은 생각보다 위험한 지점임
  - Pickle 같은 포맷은 역직렬화 과정만으로도 임의 코드가 실행될 수 있음
  - 안전한 데이터 전용 포맷을 쓰더라도, 커스텀 아키텍처 실행을 위해 동봉된 파이썬 스크립트 권한을 악용하는 변종 공격이 가능함
  - 그러니까 “모델 파일이니까 괜찮겠지”가 아니라, 모델도 코드처럼 취급해야 하는 상황임

- 토스는 쿠버네티스 환경에 자체 아티팩트 방화벽을 올림
  - 하루 6만건 이상의 패키지를 스캔하고 있음
  - 글로벌 플랫폼의 정적 애플리케이션 보안 테스트(SAST)는 우회 가능성이 있어서, 자체 검증을 통과한 청정 모델만 사내 저장소에 적재하는 체계를 강조함

> [!TIP]
> 공급망 보안 정책은 개발 속도를 막는 순간 우회되기 쉽다. 토스가 유해 버전만 숨기는 식으로 에러 없는 통제를 구현한 이유도 여기에 있음.

- 흥미로운 건 토스가 개발자 경험까지 같이 봤다는 점임
  - HTTP 캐시 스펙을 활용해 개발자에게 에러를 터뜨리지 않고, 문제가 있는 버전만 보이지 않게 처리하는 방식을 구현함
  - 보안 정책이 빌드와 배포를 자꾸 깨면 현업은 결국 다른 길을 찾기 때문에, 통제는 조용하고 일관되게 작동해야 함

- 당근과 토스 사례의 공통점은 ‘외부 반입 경로’를 잡았다는 것임
  - 오픈소스 패키지든 머신러닝 모델이든 공격자는 결국 회사 안으로 들어오는 길을 찾음
  - 그래서 사내망 진입 지점에 프록시와 방화벽을 세우고, 중앙에서 자동 정책을 적용하는 아키텍처가 현실적인 대안으로 떠오르는 중임

---

## 기술 맥락

- 당근이 레지스트리 프록시를 고른 이유는 패키지 보안을 개발자 PC 설정 문제로 두면 조직 전체 품질을 맞추기 어렵기 때문이에요. 모두가 같은 저장소 경로를 보게 만들면, 보안 정책을 한 군데에서 바꾸고 바로 적용할 수 있거든요.

- 쿨다운 정책은 새 패키지를 영원히 막자는 얘기가 아니에요. 악성 패키지는 올라온 직후 짧은 시간에 피해를 내는 경우가 많으니, 초반 몇 시간이나 며칠을 늦추는 것만으로도 공격 성공률을 낮출 수 있다는 판단이에요.

- 토스가 아티팩트 방화벽을 둔 건 MLOps에서는 모델 파일도 실행 경로가 될 수 있기 때문이에요. Pickle처럼 역직렬화가 곧 코드 실행으로 이어질 수 있는 포맷이 있고, 커스텀 모델 로딩 스크립트까지 붙으면 일반 패키지 스캐너만으로는 부족해요.

- HTTP 캐시 스펙을 활용해 유해 버전만 숨긴 접근도 실무적으로 중요해요. 보안 장치가 개발자에게 계속 에러를 보여주면 생산성 이슈가 되고, 결국 우회 경로가 생기거든요. 조용히 막되 필요한 정책은 강제하는 쪽이 대규모 조직에서는 더 오래 갑니다.

## 핵심 포인트

- 파이썬 공식 저장소에는 하루 900개 넘는 신규 패키지가 올라오고, 최근 1년 새 보고된 파이썬 생태계 멀웨어는 2800개를 넘음
- 당근은 사내 레지스트리 프록시와 쿨다운 정책으로 새 패키지 유입을 일정 기간 제한함
- 토스는 쿠버네티스 환경에서 아티팩트 방화벽을 운영하며 하루 6만건 이상의 패키지를 스캔함

## 인사이트

이 기사는 공급망 보안을 ‘교육’이나 ‘체크리스트’ 문제가 아니라 인프라 설계 문제로 다룬다는 점이 좋다. 개발자 경험을 망치지 않으면서 중앙에서 위험한 유입을 줄이는 방식이라, 규모가 커지는 조직일수록 바로 참고할 만하다.
