결석 에세이_박효원

파이썬 공급망 공격에 맞서는 당근의 기술적 돌파구

: 사내 PyPI 프록시 서버 구축과 쿨다운 필터링 시스템 구현의 엔지니어링 기록

 

1. 들어가며: 오픈소스의 신뢰성과 기업 인프라의 타협점
현대 소프트웨어 엔지니어링 생태계에서 오픈소스 라이브러리는 가히 필수불가결한 존재다. 개발 과정에서 이미 완성되고 검증된 모듈을 가져다 쓰는 것은 비즈니스 속도를 가속하는 가장 강력한 무기다. 특히 파이썬은 머신러닝, 데이터 분석, 거대언어모델(LLM) 파이프라인부터 백엔드 서비스에 이르기까지 방대한 공용 패키지 저장소인 PyPI를 기반으로 견고한 생태계를 다져왔다.
그러나 오픈소스의 자유로움과 무조건적인 신뢰 이면에는 치명적인 보안 위협이 도사리고 있다. 그중에서도 소프트웨어 공급망 공격은 기업 내부의 보안 장벽과 코드 리뷰 시스템을 완전히 무력화할 수 있는 가장 정교하고 위협적인 형태다. 패키지 배포 주기의 허점이나 배포 자격 증명을 노려 악성 코드를 주입하는 기법은 이미 사내의 통제망 안으로 침투하기 때문에 사후 대응이 매우 어렵다.
당근에는 이러한 전사 기술 생태계의 안정성을 고민하기 위해 다양한 프로그래밍 언어에 관심 있는 구성원들이 자발적으로 모여 전사 정책과 생태계 이슈를 논의하는 챕터 그룹이 존재한다. 그중 파이썬 챕터는 최근 파이썬 진영을 강타한 공급망 공격 사태를 기점으로, 사내 파이썬 인프라의 보안을 획기적으로 개선하기 위해 움직이기 시작했다. 본 에세이는 당근 파이썬 챕터가 겪은 실제 인프라의 페인 포인트와 이를 극복하기 위해 사내 PyPI 프록시 서버를 구축하고, 독창적인 의존성 쿨다운 메커니즘을 결합하여 전사적인 보안 거버넌스를 어떻게 직접 엔지니어링으로 풀어냈는지에 대한 실전적 기록이다.

2. 사건의 발단과 위협 분석: LiteLLM 공급망 공격의 메커니즘
당근 파이썬 챕터가 해결해야 할 핵심 과제는 2026년 3월 24일 발생한 LiteLLM 패키지 공급망 공격 사태를 통해 극적으로 가시화되었다. LiteLLM은 다양한 LLM API를 단일 규격으로 호출할 수 있어 사내 인공지능 엔지니어링 및 서비스 구현에 널리 도입되어 있던 핵심 오픈소스 라이브러리였다. 당시 공격자가 취한 침투 메커니즘은 매우 정교했으며 일련의 공격 파이프라인을 따랐다.
첫째, 보안 인프라의 취약점 노출 단계다. LiteLLM 개발팀은 패키지 안정성 진단을 위해 배포 파이프라인 내부에서 취약점 보안 스캐너인 Trivy를 주기적으로 가동하고 있었다. 공격자는 이 Trivy 보안 스캐너의 설정이나 로그 관리 부실을 파고들어 스캐너가 소유하고 있던 내부 인증 크리덴셜을 수집 및 탈취하는 데 성공했다.
둘째, 코드 리뷰 시스템 무력화 단계다. 일반적인 소스코드 저장소인 GitHub의 메인 브랜치 병합 프로세스는 다른 메인테이너의 승인을 받아야만 코드를 반영할 수 있는 강력한 방어 메커니즘이 존재한다. 하지만 공격자는 소스코드를 직접 수정하는 대신, 탈취한 크리덴셜을 통해 공식 배포 파이프라인의 권한을 통째로 도용했다. 즉, GitHub 메인 브랜치의 정상적인 검증 절차를 거치지 않고 악성 코드가 삽입된 패키지 파일을 배포 시스템으로 바로 전송했다.
셋째, 공식 PyPI 저장소 배포 단계다. PyPI 인프라 입장에서는 공식 CI/CD 시스템이 올바른 자격 증명을 제출했으므로, 아무런 의심 없이 악성 코드가 포함된 변조 버전인 1.82.7 및 1.82.8 버전을 공식 레지스트리에 등록 및 배포 처리하였다.
넷째, 악성 페이로드 작동 단계다. 등록된 악성 버전에는 시스템 내부 자산을 도용하기 위한 페이로드가 은밀히 이식되어 있었다. 해당 패키지가 개발자의 PC나 클라우드 운영 서버에 다운로드되어 실행되는 순간, 패키지는 백그라운드에서 시스템 환경 변수, 로컬에 암호화 없이 적재되어 있던 SSH 키, 그리고 AWS나 GCP 등 인프라 전체를 관리할 수 있는 접근 크리덴셜을 갈취하여 공격자가 제어하는 외부 C2 서버로 전송하였다.
이 사태는 개발자 개개인이 신뢰할 수 있는 공식 배포 도구를 사용했음에도 시스템 전체의 클라우드 제어권이 통째로 넘어갈 수 있는 아찔한 시나리오였다. PyPI 운영진에 의해 악성 버전이 비교적 빠르게 탐지 및 격리 조치되었음에도 불구하고 그 짧은 시간 동안 이미 막대한 수의 다운로드가 발생했다. 심지어 유사한 시기에 telnyx 패키지 역시 완전히 동일한 방식으로 공격자에게 무력화되는 도미노 침해 사고가 연속되었다.

3. 해결의 단초: '언제 설치할 것인가'에 대한 보안 패러다임 전환
이러한 공급망 공격에 대응하기 위해 기존 보안 업계가 주로 취했던 방식은 정적 혹은 동적 소스코드 감사 방식이었다. 설치 전 코드 파일을 스캔하여 위험 요소를 가려내는 식이다. 하지만 하루에도 수백 개씩 신규 릴리스되는 패키지 목록을 사내 인프라 단에서 매번 디컴파일하고 스캔하여 위협을 차단하는 것은 물리적으로 불가능에 가깝다.
당근 파이썬 챕터는 이 지점에서 공격 메커니즘에 내재된 시간적 요인에 주목했다. 기존 보안 분석 자료에 따르면, 최근 발생한 대표적인 대형 공급망 공격 10건 중 8건은 악성 코드가 레지스트리에 올라온 직후부터 탐지·격리되기까지의 소요 시간이 일주일 미만이었다. 만약 우리가 일정 기간의 대기 시간, 즉 쿨다운 정책을 인프라에 적용할 수만 있다면 그동안 유포된 주요 공격의 90% 이상을 사전에 완벽하게 우회하고 사내 망을 보호할 수 있다는 확신을 얻었다.
일부 모던 패키지 관리 도구들은 이미 이 아이디어를 탑재하기 시작했다. Rust 기반의 고성능 패키지 관리 도구인 uv는 특정 설정을 통해 최근 3일 이내에 업로드된 패키지를 의존성 탐색 리스트에서 원천 배제하는 기능을 지원하며, 표준 pip 역시 최근 릴리스된 패키지 다운로드를 일시적으로 제어할 수 있는 플래그를 도입하기 시작했다.
하지만 이 해결책을 실제 현업 환경에 적용하려다 보니 클라이언트 중심 통제의 명확한 한계에 부딪혔다. 사내에는 수십 개의 개발 부서가 존재하고 수백 명의 엔지니어가 근무하고 있다. 이들 개개인의 로컬 개발 환경과 각 프로젝트마다 분산되어 있는 수백 개의 Dockerfile, 그리고 다양하게 정의된 배포 설정 파일을 돌아다니며 일일이 개별 설정을 일관되게 규정하고 강제하는 것은 운영상 현실성이 없었다. 단 한 명의 개발자나 단 하나의 배포 파이프라인에서 설정을 누락하는 순간, 전체 보안 전선에 치명적인 구멍이 뚫리게 되기 때문이다.
이에 따라 당근 파이썬 챕터는 클라이언트의 환경 변화에 의존하지 않고, 사내로 진입하는 모든 파이썬 의존성 패키지 요청 트래픽이 강제적으로 거쳐 갈 수밖에 없는 공통 인프라적 통로, 즉 단일 진입점 프록시 서버를 직접 개발하여 배치하기로 경로를 수립했다.

4. 첫 번째 해결 단계: 사내 PyPI 프록시 서버(Karrot PyPI Proxy)의 기획과 엔지니어링
당근 파이썬 챕터가 인프라 레이어에서 풀고자 한 문제는 단순히 쿨다운 보안 정책의 적용에만 머무르지 않았다. 이들은 이미 사내 개발자들이 사설 라이브러리를 설치 및 관리하기 위해 사용하던 AWS CodeArtifact 시스템 내부의 고질적인 페인 포인트를 함께 목격하고 있었다.
당근은 사내에서 자체적으로 제작하고 표준화한 공통 분석 모델이나 라이브러리를 사내 환경에서 배포 및 로드할 수 있도록 AWS의 사설 패키지 저장소 매니지드 서비스인 AWS CodeArtifact를 가동하고 있었다. 하지만 보안을 위해 이 엔드포인트를 외부에 개방할 수 없었고, 이에 따라 개발자가 사내 패키지를 설치하고 싶을 때마다 매번 로컬 PC에서 임시 AWS 토큰을 명령어로 재발급받아 그것을 리포지토리 URL 사이에 조각조각 조립해야만 통신할 수 있는 무겁고 비효율적인 수동 방식이 강제되고 있었다.
파이썬 코드를 작성하고 싶었을 뿐인데 로컬 PC에 무겁고 거추장스러운 관련 소프트웨어를 선행해서 무조건 깔아야 했고, 이조차도 시간이 흐르면 토큰이 자동으로 만료되어 개발 중에 의존성 다운로드 실패 메시지를 수시로 마주하게 만들었다. 이보다 심각한 지점은 도커 컨테이너화 과정에서 터져 나왔다. 도커 이미지 빌드 단계에서 사내 프라이빗 패키지를 내려받으려면 AWS 자격 증명을 빌드 파라미터 형태로 주입하는 비표준적인 방식을 강행해야 했다. 이 구조는 컨테이너 레이어 내부 파일 시스템 어딘가에 실제 클라우드 인프라 자격 증명 데이터가 영구히 적재되거나 남아돌 수 있는 심각한 보안 리스크를 유발했으며, 가용성 보장을 위해 무거운 모듈을 빌드 이미지 안에 강제로 탑재하는 자원 낭비를 유발했다. CI/CD 환경 역시 토큰의 파이프라인 매핑으로 설정이 극도로 복잡했다.
당근 파이썬 챕터는 이 장벽을 허물기 위해 개발자와 CodeArtifact 사이에 위치하는 경량형 중재 프록시 레이어를 독자적으로 구현하여 내부 네트워크 전면 망에 배포했다.
해결 메커니즘은 단순하되 명확했다. 개발자가 패키지를 요청하면 프록시 서버가 직접 중간에서 그 요청을 넘겨받아 자신들이 내부적으로 AWS 자격 증명으로 포장하고 가공해 CodeArtifact 엔드포인트로 흐름을 이어가게 만드는 구조다. 이 프록시 구조의 도입으로 사내 개발 환경에 산재해 있던 지저분한 환경 변수와 시크릿 주입 로직들은 완전히 은닉 및 대체되었다.
로컬 빌드, 복잡한 CI/CD 컨텍스트, 컨테이너 Dockerfile 등 그 어떠한 가상 인프라 영역에서도 개발자들은 평소 인터넷에서 패키지를 다운로드하듯이 프록시가 가리키는 한 줄의 고정된 인덱스 주소만 입력하면 복잡한 수동 인증 절차를 한 번에 패스할 수 있게 되었다. 프록시 내부가 파이썬 패키징 표준 스펙인 PEP 503 Simple Repository API의 핵심 경로 명세들을 고스란히 재구현하여 호환하고 있었기에 가능한 구조였다.

5. 두 번째 해결 단계: 프록시 서버 내부의 자원 한계 극복 및 고가용성 인프라 엔지니어링
사내의 모든 패키지 조회 및 바이너리 다운로드 트래픽이 새롭게 얹혀진 프록시 단일 지점으로 빨려 들어옴에 따라, 파이썬 챕터 엔지니어들은 이 프록시가 지탱해야 하는 물리적 리소스 한계와 장애 극복 기법들을 면밀하게 제어해 나가야만 했다.
 첫째, 대용량 머신러닝 및 딥러닝 바이너리의 버퍼링 한계 극복이다. 데이터 사이언스와 인공지능 연구가 활발한 사내 환경 특성상, 빌드 요청 내역에는 기가바이트 단위를 상회하는 초대형 라이브러리 파일인 PyTorch나 TensorFlow 등이 수시로 호출된다. 만약 프록시 서버 내부 메모리 영역에서 이 거대한 바이너리 스트림을 한 번에 가져와서 메모리에 버퍼링한 후에 클라이언트에게 한꺼번에 밀어내는 구식 방식을 취한다면, 빌드 배포 트래픽이 단 한 순간 몰리는 즉시 가상 머신에 OOM 프로세스 크래시가 유발되어 전사 패키지 다운로드 시스템이 마비된다. 이를 방지하기 위해 프록시 내부 구조는 바이너리 데이터를 메모리에 절대 적재하지 않고, 업스트림 응답 스트림 채널을 열어두고 고정된 물리적 영역인 8KB 크기의 청크 단위로 가볍게 쪼개어 수신 즉시 다운스트림 클라이언트에 고속 릴레이 처리하는 청크 스트리밍 파이프라인을 정밀 구축하였다. 이를 통해 서버는 거의 제로에 가까운 가벼운 가상 메모리 점유율을 고정적으로 안전하게 유지하며 수십 대의 동시 대용량 패키지 다운로드 요청을 막힘없이 견뎌냈다.
 둘째, 백그라운드 토큰 갱신 데몬 스레드 설계다. 수동 인증을 프록시 내부로 격리하기 위해, AWS가 발급하는 CodeArtifact 임시 세션 토큰의 전체 라이프사이클 관리 루틴 역시 프록시가 완전히 자율적으로 관리해야 했다. 이를 위해 프록시 애플리케이션 기동 시점에 메인 리퀘스트를 수용하는 메인 스레드와 철저하게 비동기적으로 작동하는 백그라운드 자가 치유형 데몬 스레드를 하나 더 띄우는 형태로 설계했다. 이 독립적인 데몬 스레드는 백그라운드에서 주기적으로 수면 상태를 반복하며, 현재 보관 중인 토큰의 물리적 만료 잔여 시간을 실시간 파악하고 만료가 다가올 때마다 자동으로 선제 재발급 루틴을 호출하는 임무를 담당했다.
 셋째, 15분 만료 최소화와 소프트 스왑 설계다. 보안의 기본 룰인 자격 증명의 최소 노출 원칙을 철저하게 준수하기 위해 사내 프록시는 AWS가 허용하는 가장 짧은 유효 수명 기간인 900초(15분) 설정만을 허용하여 토큰을 갱신 발급받도록 시스템 값을 고정했다. 혹여 토큰이 메모리 누수나 탈취 등의 사고로 노출되더라도 공격자가 활용할 수 있는 시간의 제약을 15분 내외로 원천 차단해 버린 것이다. 이와 동시에, 토큰이 실제로 만료되는 순간 빌드 요청이 실패하여 장애가 발생하는 가용성 균열을 막기 위해 만료 예정 시각으로부터 300초(5분) 전에 백그라운드에서 신규 임시 토큰을 미리 갱신받아 조용히 바꿔치기하는 소프트 스왑 기법을 적용해 가용성을 보장했다.
 넷째, 동시성 경합 상태의 스레드 동기화 락 및 지터 도입이다. 메모리에 보관하고 있는 이 전역 토큰 변수는 동시다발적으로 들어오는 무수히 많은 파이썬 패키지 설치 스레드들에 공유되어 사용되는 임계 구역 자원이다. 따라서 백그라운드 데몬이 신규 토큰으로 메모리를 덮어씌우는 타이밍에 다중 유저가 접속하여 해당 포인터를 동시에 참조하려는 경합 현상이 상시 발생했다. 파이썬 챕터는 이 문제를 원자적으로 해결하기 위해 내부 메모리 상태 교체 구문 구간에 수동 스레드 동기화 객체를 도입하여 토큰의 점유 안정성을 완벽히 조절했다. 또한, 분산 컨테이너 인프라 환경에서 기동 중인 여러 프록시 웹 컨테이너 노드들이 정확하게 동일한 시간에 AWS 엔드포인트를 노크해 갱신을 하려고 몰려드는 트래픽 충돌 사태를 미연에 필터링하고자, 토큰 갱신 예약 주기에 무작위 60초 변동 오차폭인 지터를 수학적으로 혼합하여 갱신 타임스탬프 스케줄을 랜덤하게 분산 정규화했다.
 다섯째, 똑똑한 헬스 체크 엔드포인트의 구성이다. 단순히 프로세스가 구동 중인지만 체크하는 일반적인 방식은 토큰 갱신 데몬이 비정상 종료되어 실제 작동 불능 상태에 빠진 인스턴스를 걸러내지 못한다. 당근 프록시는 토큰 갱신 데몬이 만약 알 수 없는 API 에러나 네트워크 격리로 인해 갱신 기능을 마비당한 채 구동되는 중이라면, 가차 없이 사내 오케스트레이터 단에서 그 인스턴스를 즉각 제거하고 재생성시킬 수 있도록 설계했다. 이를 위해 프록시 내부의 헬스 체크 핸들러는 단순히 서버 생존 여부만을 반환하는 것이 아니라, 현재 보관 중인 임시 토큰이 실제로 유효한지 검증하는 자가 진단을 수행하여 문제 발생 시 즉각 서비스 제외 처리를 하도록 구조를 완성했다.

6. 세 번째 해결 단계: 파이썬 공식 명세 규격(PEP 503 & PEP 691)의 융합과 실시간 쿨다운 필터링 구현
사내 파이썬 패키지 통신이 프록시라는 이 단일 진입점 구조에 안정적으로 고착되자, 드디어 파이썬 챕터가 기획했던 공급망 위협 방어인 의존성 쿨다운 필터링 정책을 중앙 제어 방식으로 전사에 즉시 보급할 수 있는 무대가 비로소 마련되었다. 하지만 기쁨도 잠시, 쿨다운 로직을 프록시 내부에 코드로 구축하려던 시점에 공식 파이썬 인터페이스 규격의 심각한 구조적 한계와 충돌하게 되었다.
pip나 uv 등의 기본 배포 에이전트 도구들은 기본적으로 파이썬 표준 협회가 제정한 PEP 503 Simple Repository API 가이드라인을 따라 저장소 패키지 버전을 인식한다. 이 명세는 특정 패키지가 수용하는 가용 리스트 버전 목록을 지극히 정적이고 평평한 원시 HTML 구조로 파싱하여 되돌려줄 것을 규정하고 있다. 여기서 발생한 치명적인 문제는 이 구식 규격의 HTML 내부에는 패키지가 공식 사이트에 올라온 물리적 기재 타임스탬프 정보가 누락되어 존재하지 않는다는 점이었다. 프록시 서버가 업스트림인 AWS CodeArtifact로부터 이 뼈대만 남은 HTML 문자열을 내려받은들, 어떤 링크가 방금 등록된 위험 등급의 패키지인지 시간적으로 판별해 낼 수 있는 근거가 전무했다.
이 한계를 타파하기 위해 당근 파이썬 챕터가 결합한 규격이 바로 최신 파이썬 패키징 명세인 PEP 691 표준이었다. PEP 691 스펙은 기존 HTML 기반의 인터페이스를 구조화된 JSON 데이터 포맷으로 확장하여 제공하는 규격이다. 클라이언트 요청 헤더 내부에 특정 포맷을 명시하여 조회하면, PyPI 원격 저장소는 각 바이너리 버전별로 정확한 시간 세부 정보가 내장되어 제공되는 JSON 데이터를 내어준다. 이 JSON 명세에는 우리가 그토록 필요로 했던 각 파일의 업로드 시간 필드가 명확하게 명시되어 제공된다. 비로소 프록시 단에서 정확한 시간 기반의 연산과 비교 처리를 수행할 수 있는 데이터 구조적 기반이 마련된 것이다.
두 스펙의 장점을 결합하기 위해 당근 파이썬 챕터는 독창적인 하이브리드 필터링 파이프라인을 구현하였다. 사내 개발자의 패키지 설치 도구가 프록시 서버로 특정 패키지 조회를 요청하면, 프록시 서버는 내부적으로 두 개의 네트워크 요청을 병렬 실행한다. 하나는 사내 CodeArtifact에서 기존 방식의 PEP 503 HTML 원본 응답을 가져와 대기시키는 작업이며, 다른 하나는 공용 저장소인 PyPI 공식 웹사이트에 동일 패키지에 대해 PEP 691 JSON 메타데이터를 질의하는 작업이다. JSON 응답이 수신되면 프록시는 업로드 시간 필드를 파싱하여 현재 시각과 비교 연산을 수행한 뒤, 사내 보안 정책으로 설정된 쿨다운 윈도우 기간 이내에 업로드된 위험 버전의 파일명 리스트를 추출한다. 그 후, 미리 대기시켜 둔 HTML 내부 텍스트 스트림을 스캔하여 해당 위험 버전에 대응하는 HTML 요소를 정규식 치환 엔진을 통해 완전히 소거한다. 최종적으로 클라이언트에게는 위험한 최신 버전 링크가 완벽히 증발한 안전한 HTML만이 서빙되는 정밀한 우회 방어 로직이 완성되었다.

7. 네 번째 해결 단계: Central Dogma 통합을 통한 무중단 정책 스왑 데브섹옵스 아키텍처 구축
정교한 실시간 쿨다운 필터링 파이프라인을 성공적으로 빌드했음에도, 이를 무작정 사내 인프라 전체에 곧장 적용하는 것은 운영 관점에서 대단히 위험한 일이었다.
보안 규정이란 항상 현실의 비즈니스 출시 가속도와 긴밀하게 밀고 당기는 트레이드오프를 겪기 마련이다. 만약 전 세계가 검증하여 안전도가 완벽한 핵심 패키지의 급작스러운 오류 핫픽스 릴리스나, 당근 파이썬 엔지니어들이 사내 사설망에서 자체 빌드하여 배포한 사내 모듈들마저 며칠 동안 대기해야 한다며 쿨다운 정책이 가로막는다면, 전사적인 긴급 장애 복구와 비즈니스 기민성은 크게 흔들릴 수밖에 없다. 그렇다고 해서 예외 처리 목록을 수정할 때마다 프록시 서버 코드를 고치고 가상화 인프라 전체를 수동 빌드하여 무중단 배포 단계를 밟는 행위는 시시각각 변화하는 보안 위협에 대처하기에 대단히 비효율적이었다.
당근 파이썬 챕터는 이러한 운영 경직성을 부수고 유연하며 기민한 보안 거버넌스 파이프라인을 확보하기 위해, Git 기반의 고성능 분산 구성 관리 플랫폼인 Central Dogma 시스템을 프록시 아키텍처에 유기적으로 연결하였다. Central Dogma의 실시간 파일 변경 API 인터페이스를 프록시 내부에 내장함으로써, 프록시는 프로세스 리부팅이나 가상 서버 장애 중단 없이도 실시간으로 수정되는 보안 설정 값들을 거의 제로 레이턴시 수준으로 동적 스왑할 수 있게 되었다.
이 고도화된 중앙 제어 구성 관리를 통해, 파이썬 챕터 운영진은 침해 사고 발생 상황에 따라 쿨다운 통제 레이어 자체의 작동 정지는 물론, 보안 강도 조정을 위한 격리 일수를 즉시 유동적으로 변경 제어할 수 있게 되었다. 특히 쿨다운 필터링에서 예외 취급을 지정하는 목록에 당근의 사내 패키지명이나 필수 고신뢰도 모듈의 명칭을 추가하는 즉시, 전 사내에 설치된 실시간 프록시 서버 노드들의 메모리 화이트리스트 변수 상태가 단 1초 만에 무중단 교체되어 안전한 최신 빌드 패치가 지연 없이 전사에 보급되는 데브섹옵스 거버넌스를 실현해 냈다.

8. 실증적 성과 및 한계성 고찰: PyTorch Lightning 글로벌 공급망 공격 완벽 방어 성공 기록
인프라의 모든 연결 부위를 엔지니어링으로 매끄럽게 가꾸어 사내 가동을 안정화한 지 얼마 지나지 않은 시점, 당근 파이썬 챕터가 설계한 보안 장벽의 진정한 진가를 시험해 볼 기회가 글로벌 테크 씬에서 연쇄적으로 폭발하며 그 가치를 빛내기 시작했다.
2026년 4월 30일, 전 세계 인공지능 학계 및 현업 데이터 사이언티스트들의 필수 프레임워크인 PyTorch Lightning 공식 레지스트리 유포판이 감염되는 글로벌 위기 상황이 터졌다. 국내외를 막론하고 수많은 인공지능 서비스 기업들과 기술 연구소의 연구원들이 이 소식을 접하지 못한 채, 혹은 늘 하던 대로 패키지 설치 명령을 가동하여 인프라 자격 증명 탈취의 직접적인 제로데이 위협에 노출되고 있었다.
하지만 당근의 엔지니어들과 머신러닝 분석가들은 아무런 걱정 없이 평소와 같은 빌드 및 분석 작업을 평화롭게 이어나갔다. 당근 내부 망에 상시 가동 중이던 사내 PyPI 프록시의 쿨다운 필터링 엔진 덕분에, 해당 감염 버전 정보의 링크 주소들이 표준 조회 영역에서 완벽하게 은닉 및 소거된 상태로 개발 도구들에 하달되었기 때문이다. 개발자들은 단 한 줄의 보안 설정 변경 작업도 거치지 않은 채, 프록시가 자동으로 정제해 준 안전하고 검증된 직전 버전을 우회하여 안전하게 내려받음으로써 단 한 건의 시스템 자격 증명 유출 침해 사건 없이 인프라의 완벽한 무결성을 지탱해 냈다.
비록 이 쿨다운 기술 기반 방어 체계가 글로벌 위기에서 당근의 자산을 지켜낸 강력한 구원투수로 활약하였으나, 운영 과정에서 파이썬 챕터가 감내하고 해결해야 할 기술적 트레이드오프 요건들 역시 한 차례 정립되었다.
 첫째, 긴급 보안 취약점 업데이트의 전달 지연 리스크다. 특정 모듈 내부에서 극도로 심각한 제로데이 취약점이 대외적으로 폭로되어 공식 오픈소스 개발팀이 이를 상쇄하는 긴급 보안 패치 버전을 배포했을 경우, 쿨다운 시스템은 해당 패치 버전 역시 갓 배포된 대기 격리 대상 패키지로 오인하여 사내 유입을 막아 세우는 보안적 모순을 야기한다. 이를 위해 당근은 보안 관제 채널을 연동하여, 공식 보강 취약점 패치 확인 즉시 Central Dogma의 예외 관리 화이트리스트 테이블에 즉각 등록해 패스트 트랙으로 우회 수송하는 휴먼 운영 인프라 프로세스를 밀접하게 결합해 보강 중이다.
 둘째, 시간적 잠복형 변종 공격 탐지의 한계다. 만약 공격자가 쿨다운 차단 시간 한계선을 상회하도록 설계하여, 코드가 설치된 이후 한참 뒤인 시점에 비로소 악성 스크립트가 수면 위로 구동되게끔 트리거 지연 장치를 내장하는 등의 시간 지연형 변종 공격을 감행할 경우, 단순 유입 시간 차단기인 쿨다운 메커니즘은 그 능력을 완전히 상실하게 된다.
결국 시간 기반 쿨다운 정책은 공급망 위협을 완전히 종식할 수 있는 단 하나의 만능 열쇠가 아니며, 프록시 단의 선제적 쿨다운 타임 필터 배리어와 더불어, 개발 빌드 배포 단계에서 의존성 패키지들의 시그니처 정밀 검증을 상시 가동하는 보안 탐지 엔진, 그리고 서버가 구동되는 커널 수준 가상 런타임 환경에서 허가되지 않은 아웃바운드 네트워크 요청을 사전 차단하는 다층 방어 시스템이 사내 인프라에 함께 병렬적으로 엮어 기능해야 비로소 완벽한 보안을 달성할 수 있음을 입증하고 있다.

9. 마치며: '언제 설치할 것인가'를 스스로 제어하는 주체성의 가치
당근 파이썬 챕터가 LiteLLM 공급망 위협으로부터 시작해 사내 PyPI 프록시 서버를 기획, 구현하고, 나아가 쿨다운 및 Central Dogma 통합 제어 아키텍처로 도달한 일련의 여정은 현대 오픈소스 위협 환경에 맞서는 모범적인 데브섹옵스 엔지니어링의 정수를 여실히 투영하고 있다.
이들이 이룩해 낸 해결 과정의 가장 뛰어난 지점은, 기업 인프라의 핵심 자산을 안전하게 통제한다는 무거운 보안의 숙제를 풀기 위해 개발자들의 일상적인 생산성과 개발 경험을 단 한 순간도 희생시키지 않았다는 점이다. 사내 개발자들은 그저 원래 하던 대로 아무런 도구 설치나 자격 증명 설정 없이 패키지 인덱스 한 줄만 선언해 빌드 도구를 실행했을 뿐이지만, 인프라 스스로가 그 길목에 숨어 복잡한 AWS 토큰 발급을 대행해 주며, 악성 링크를 스스로 잘라내어 무해한 환경만을 하달해 주는 영리한 중재 레이어를 완성해 냈다.
개발에 쓰이는 외부 재료를 맹목적으로 신뢰하는 방관의 시대를 지나, 무엇을 설치할 것인가와 함께 우리가 그것을 우리 인프라에 언제 서빙하고 수용해 줄 것인가의 시간적 주도권을 기업 인프라가 스스로 제어하도록 아키텍처를 교정한 것. 그것이야말로 수많은 외부 위협 속에서 파이썬과 데이터 분석 생태계를 가장 안전하게 향유해 나가는 가장 모범적이고 선구적인 엔지니어링의 패러다임이라고 단언할 수 있다.

 

 

*출처 및 참고문헌: 당근 테크블로그 / https://medium.com/daangn/당근이-파이썬-공급망-공격에-대응하는-방법-e0b4f483b574