Perplexity가 개발자 엔드포인트(개인 PC 및 작업 환경)의 공급망 보안을 점검하는 읽기 전용 스캐너 'Bumblebee'를 깃허브(GitHub)에 공개했다. 이 도구는 macOS와 리눅스 환경에서 작동하는 인벤토리 수집기로, Perplexity가 자사의 검색 제품과 코멧(Comet) 브라우저, 컴퓨터 에이전트를 보호하기 위해 내부적으로 사용하던 기술이다.

최근의 사이버 공격은 실제 서비스가 돌아가는 운영 서버뿐만 아니라, 개발자의 PC에 설치된 패키지, 에디터 확장 프로그램, AI 도구 설정 파일을 직접 겨냥하는 추세다. 소프트웨어 엔지니어나 데이터 사이언티스트의 PC에는 수십 개의 라이브러리와 브라우저 애드온, 그리고 MCP(Model Context Protocol, AI 모델이 외부 데이터에 접근하게 돕는 규격) 설정이 복잡하게 얽혀 있다. 새로운 보안 취약점이 발견되었을 때, 보안 팀이 가장 먼저 맞닥뜨리는 문제는 '지금 당장 어떤 개발자의 PC가 위험에 노출되어 있는가'를 파악하는 일이다.

기존의 보안 도구들은 이 질문에 명확한 답을 주지 못했다. SBOM(Software Bill of Materials, 소프트웨어 구성 요소 명세서)은 빌드된 결과물이나 저장소 중심으로 작동하고, EDR(Endpoint Detection and Response, 엔드포인트 탐지 및 대응) 제품은 실행 중인 프로세스나 네트워크 트래픽을 추적한다. 정작 개발자 노트북의 파일 시스템 곳곳에 흩어져 있는 락파일(lockfile)이나 패키지 메타데이터, AI 도구 설정값 같은 '로컬 상태'를 훑어보는 도구는 부족했다. Bumblebee는 바로 이 지점, 즉 로컬 디스크의 메타데이터를 직접 읽어 취약한 버전의 패키지가 설치되어 있는지 즉각적으로 찾아내는 역할을 수행한다.

Bumblebee v0.1.1, Go 1.25 기반의 제로 의존성 스캐너

Bumblebee는 개발자 PC에 설치된 각종 패키지와 설정 파일의 목록을 읽어오는 읽기 전용 인벤토리 수집 도구다. 현재 공개된 버전은 v0.1.1이며 이 도구를 실행하기 위해서는 Go(구글이 개발한 프로그래밍 언어) 1.25 버전 이상의 환경이 필요하다. 여기서 주목할 점은 제로 의존성(Zero Dependency) 설계다. 쉽게 말하면 외부에서 가져다 쓰는 추가 라이브러리가 전혀 없다는 뜻이다. 비유하자면 조립식 가구를 살 때 별도의 드라이버나 망치가 필요 없이 모든 도구가 세트에 포함되어 있어 바로 조립할 수 있는 상태와 같다. 보안 스캐너가 외부 라이브러리에 의존하면 그 라이브러리 자체가 보안 취약점이 될 수 있는데 Bumblebee는 이를 원천적으로 차단해 도구 자체의 안전성을 높였다.

설치 과정은 매우 단순하며 터미널에서 명령어 한 줄로 끝난다.

go install github.com/perplexity/bumblebee@latest

설치를 마친 후에는 도구가 정상적으로 작동하는지 확인하는 과정이 필요하다. 이때 사용하는 명령어가 바로 셀프 테스트다.

bumblebee selftest

이 명령어를 실행하면 내장된 테스트 데이터를 통해 바이너리가 올바르게 작동하는지 검증한다. 라이선스는 아파치 라이선스 2.0(Apache License 2.0)을 따른다. 이는 기업이나 개인이 자유롭게 사용하고 수정하며 배포할 수 있도록 허용하는 매우 관대한 오픈소스 라이선스다.

Bumblebee가 수집한 데이터는 NDJSON(Newline-Delimited JSON, 줄바꿈으로 구분된 JSON) 형식으로 출력된다. 보통의 JSON 파일은 전체 내용을 하나의 커다란 괄호로 묶어 관리하므로 파일 전체를 읽어야만 내용을 파악할 수 있다. 하지만 NDJSON은 쉽게 말해 한 줄에 하나의 데이터 덩어리를 배치하는 방식이다. 비유하자면 모든 내용이 한 권의 책으로 묶인 백과사전이 아니라 한 장씩 낱개로 뜯어서 읽을 수 있는 카드 뉴스 뭉치와 같다. 덕분에 데이터 양이 방대해져도 컴퓨터가 한 줄씩 빠르게 읽어 처리할 수 있어 효율적이다. 이러한 출력 방식은 대규모 개발자 환경에서 수집된 수만 개의 패키지 정보를 실시간으로 분석해야 하는 보안 팀의 작업 흐름에 최적화된 선택이다.

락파일과 메타데이터만 읽는 '읽기 전용' 스캔 방식

기존의 보안 스캐너들은 패키지 버전을 확인하기 위해 패키지 관리 도구를 직접 호출하는 방식을 주로 사용했다. 하지만 이는 보안 도구가 오히려 공격의 통로가 될 수 있는 위험한 행동이다. 비유하자면 수상한 택배 상자 안에 무엇이 들었는지 확인하려고 상자를 직접 열어보는 것과 같다. 만약 그 상자에 설치 즉시 작동하는 악성 스크립트가 숨겨져 있다면, 보안 점검을 하려던 행위 자체가 공격을 실행시키는 트리거가 되어 시스템을 감염시킨다. 범블비(Bumblebee, Perplexity가 공개한 공급망 스캐너)는 이 지점에서 완전히 다른 접근 방식을 취한다. 패키지를 실제로 설치하거나 실행하는 과정을 완전히 배제하고, 디스크에 이미 기록된 텍스트 형태의 메타데이터만 읽어내는 읽기 전용 방식을 선택했다.

쉽게 말하면 설치 과정에서 생성되는 일종의 영수증이나 명세서만 훑어보는 식이다. 범블비가 분석 대상으로 삼는 파일은 `package-lock.json`, `pnpm-lock.yaml`, `go.sum` 같은 락파일(Lockfile, 설치된 패키지의 정확한 버전과 의존 관계를 고정해 기록한 파일)과 `*.dist-info/METADATA` 같은 메타데이터 파일들이다. 이 파일들은 이미 설치가 완료된 상태의 기록물일 뿐, 그 자체로 어떤 코드를 실행하는 능력이 없다. 따라서 범블비는 `npm`이나 `pnpm`, `bun`, `pip` 같은 패키지 관리 도구를 직접 호출하지 않는다. 특히 설치 과정에서 자동으로 실행되어 시스템 설정을 바꾸거나 외부 서버와 통신하는 라이프사이클 훅(Lifecycle Hook, 특정 단계에서 자동으로 작동하는 스크립트)을 아예 건드리지 않는다는 점이 핵심이다. 덕분에 분석 과정에서 의도치 않게 악성 코드가 활성화될 가능성을 원천적으로 차단하며 안전하게 인벤토리를 수집한다.

스캔 범위는 시스템 상황과 목적에 따라 세 가지 프로필로 나누어 정교하게 운영한다. 가장 기본이 되는 베이스라인(baseline) 프로필은 시스템의 공통적인 루트 경로와 언어별 툴체인, 그리고 에디터 및 브라우저 확장 프로그램 같은 범용적인 영역을 훑는다. 프로젝트(project) 프로필은 `~/code`나 `~/src`처럼 개발자가 실제로 코드를 작성하고 관리하는 특정 작업 디렉토리를 집중적으로 분석하여 프로젝트 단위의 위험을 찾아낸다. 마지막으로 딥(deep) 프로필은 심각한 보안 사고가 발생했을 때 운영자가 지정한 루트 디렉토리 전체를 샅샅이 뒤져 숨겨진 위협을 찾는 용도로 사용한다. 다만 초기 버전인 v0.1 기준으로는 일부 제약 사항이 존재한다. Bun의 바이너리 형식 락파일인 `bun.lockb`는 아직 파싱을 지원하지 않으며, 텍스트 형식으로 저장된 `bun.lock` 파일만 읽어낼 수 있다.

SBOM과 EDR이 놓치는 '로컬 상태'의 빈틈 메우기

보안 팀이 가장 답답해하는 지점은 개발자 개개인의 노트북 속에 정확히 무엇이 설치되어 있는지 실시간으로 알 수 없다는 사실이다. 기존의 SBOM(Software Bill of Materials, 소프트웨어 자재 명세서)은 제품을 만들기 위한 설계도나 출고 명세서와 같다. 빌드 결과물이나 저장소 중심의 목록을 관리하므로 최종 제품에 무엇이 들어갔는지는 알 수 있지만, 개발자가 로컬 환경에서 테스트용으로 설치한 패키지나 파편화된 설정 파일까지는 잡아내지 못한다. 저장소에 기록되지 않은 로컬 전용 설정들이 보안의 사각지대가 되는 경우가 많기 때문이다. 쉽게 말해 완성된 요리의 레시피는 알고 있지만, 정작 요리사의 조리대 위에 어떤 유통기한 지난 재료가 널브러져 있는지는 확인하지 못하는 셈이다. 범블비(Bumblebee)는 빌드 아티팩트가 아니라 로컬 파일 시스템 전체를 훑어 실제 설치된 상태를 확인하는 방식으로 이 간극을 메운다.

EDR(Endpoint Detection and Response, 엔드포인트 탐지 및 대응) 도구 역시 다른 관점에서 빈틈을 보인다. EDR은 일종의 CCTV처럼 어떤 프로세스가 실행되었는지, 네트워크로 어디와 통신하는지를 실시간으로 감시하는 데 특화되어 있다. 하지만 파일 내부에 적힌 정적인 메타데이터, 즉 설정 파일의 텍스트 자체를 분석해 잠재적 취약점을 찾는 작업에는 최적화되어 있지 않다. 비유하자면 건물에 누가 들어오고 나가는지는 감시하지만, 책상 서랍 속에 어떤 위험한 문서가 들어있는지는 확인하지 않는 것과 같다. 범블비는 프로세스를 실행하거나 네트워크를 감시하는 대신, 디스크에 저장된 메타데이터를 정적으로 분석한다. 특히 npm 같은 패키지 매니저의 설치 스크립트가 자동으로 실행되어 공격이 시작되는 상황을 방지하기 위해, 패키지 매니저를 직접 호출하지 않고 락파일(lockfile, 의존성 버전 고정 파일)만 읽어내는 안전한 방식을 택했다.

점검 범위는 현대 개발 환경의 파편화된 특성을 반영해 매우 구체적으로 설계되었다. 단순한 언어별 라이브러리를 넘어 VS Code, Cursor, Windsurf, VSCodium 같은 코드 에디터의 확장 프로그램 매니페스트까지 모두 읽어낸다. 브라우저 역시 Chrome, Comet, Edge, Brave, Arc, Firefox를 지원해 플러그인을 통한 공급망 공격 경로를 촘촘하게 살핀다. 특히 최근 급증하는 AI 도구의 설정 파일 점검 능력이 핵심이다. `mcp.json`, `claude_desktop_config.json`, `~/.gemini/settings.json` 같은 MCP(Model Context Protocol, 모델 컨텍스트 프로토콜) 설정 파일을 분석해 AI 에이전트가 어떤 환경에서 작동하는지 파악한다. 이는 기존 보안 도구들이 애플리케이션이라는 큰 덩어리로만 접근하던 시각을, 개발자 PC 내의 세부 설정 파일이라는 아주 작은 단위까지 확장해 분석하는 접근법이다. 디스크에 남겨진 정적인 흔적만으로 현재의 노출 상태를 즉각적으로 판별해낸다.

위협 신호부터 탐지까지, 5단계 자동화 워크플로우의 실현

기존의 보안 대응 방식은 보안 팀이 취약점 공지를 올리면 개발자가 일일이 자신의 PC를 확인해 보고하는 수동적인 구조였다. Perplexity(퍼플렉시티, AI 기반 검색 엔진 기업)는 이 과정을 5단계의 자동화 워크플로우로 전환해 대응 시간을 획기적으로 줄였다. 먼저 외부에서 위협 신호가 수신되면 Perplexity Computer(퍼플렉시티 컴퓨터, AI 에이전트)가 해당 위협의 생태계와 패키지 이름, 버전 정보를 담은 카탈로그 초안을 자동으로 작성한다. 이후 인간 개발자가 이 내용을 검토해 깃허브(GitHub)의 풀 리퀘스트(PR, 코드 변경 요청)를 머지(Merge, 병합)하면, 업데이트된 카탈로그를 기반으로 각 엔드포인트(Endpoint, 사용자 단말기)에서 스캔이 수행되고 그 결과가 보안 팀에 공유된다. 쉽게 말하면 AI가 먼저 범인 몽타주를 그리고 사람이 이를 최종 승인하면, 전사적인 수색을 자동으로 돌리는 시스템이다. 특히 사람이 개입하는 리뷰 단계는 AI가 잘못 짚은 오탐을 걸러내어 불필요한 전사 스캔으로 인한 리소스 낭비를 막는 안전장치 역할을 한다.

이 과정에서 Bumblebee(범블비, 개발자 PC 공급망 스캐너)는 탐지 결과의 신뢰도를 세 단계로 나누어 제공한다. 정확한 메타데이터를 통해 신원과 버전이 완벽히 일치하면 High(높음) 등급을 부여하고, 신원은 확실하지만 버전 정보가 일부만 확인되면 Medium(중간) 등급을 매긴다. 단순히 관련 경로가 발견되었거나 참조 기록만 있는 경우에는 Low(낮음) 등급으로 분류한다. 비유하자면 신분증을 대조해 완벽히 일치하면 High, 인상착의만 비슷하면 Medium, 그 근처에서 목격된 정황만 있으면 Low로 분류해 보안 팀이 우선순위를 정해 대응하게 돕는 식이다. 보안 팀은 이를 통해 수백 대의 개발자 PC에서 쏟아지는 결과물 중 어떤 기기를 가장 먼저 격리하거나 패치해야 할지 명확한 판단 근거를 얻는다.

운영 효율을 극대화하기 위해 사용자 정의 노출 카탈로그(Exposure Catalog) 기능을 JSON(제이슨, 데이터 교환 형식) 파일 형태로 지원한다. 보안 팀은 조직의 특성에 맞는 위협 목록을 직접 정의해 스캐너에 입력할 수 있으며, 이는 도구의 핵심 로직을 수정하지 않고도 탐지 대상을 즉시 바꿀 수 있음을 의미한다. 또한 저장소 내의 `threat_intel/` 디렉토리를 통해 실제 공개된 공급망 공격 사례를 기반으로 유지 관리되는 카탈로그를 즉시 활용할 수 있다. 이는 새로운 공격 기법이 등장했을 때 보안 팀이 제로 베이스에서 분석을 시작하는 것이 아니라, 이미 검증된 인텔리전스를 가져와 바로 적용하는 효과를 준다. 이러한 구조는 개발자가 자신의 로컬 환경을 일일이 감사해야 하는 부담을 없애는 동시에, 보안 팀에게는 실시간에 가까운 가시성을 제공한다. 상세한 구현 방식과 카탈로그 구조는 공식 저장소인 https://github.com/perplexity/bumblebee 에서 확인할 수 있다.

AI 에이전트 도입 가속화되는 한국 기업의 '엔드포인트' 보안 과제

개발자가 자신의 노트북에 설치하는 수십 개의 패키지와 확장 프로그램이 이제는 공격자의 주 타겟이 되고 있다. 기존에는 실제 서비스가 돌아가는 운영 서버를 직접 뚫으려 했다면 이제는 개발자의 PC라는 입구를 노려 내부망으로 침투하는 식이다. 최근 npm(노드 패키지 매니저), PyPI(파이썬 패키지 인덱스), RubyGems(루비젬 패키지 관리자) 등을 겨냥한 Mini Shai-Hulud 캠페인이 대표적인 사례다. 비유하자면 성벽을 직접 공격하는 대신 성문을 열고 들어오는 보급품 상자에 몰래 독을 타는 방식과 같다. 이런 공급망 공격은 npm, pnpm, Yarn, Bun뿐만 아니라 Go modules, Composer까지 다양한 생태계를 가리지 않고 광범위하게 이루어지며 개발자가 무심코 설치한 라이브러리 하나가 기업 전체의 보안 사고로 이어진다.

특히 최근 도입이 가속화되는 MCP(Model Context Protocol, 모델 컨텍스트 프로토콜) 설정 파일은 새로운 보안 취약점이 될 수 있다. MCP는 AI 모델이 외부 데이터나 도구에 유연하게 접근할 수 있게 돕는 규격인데 이 설정이 담긴 JSON(제이슨, 데이터 교환 형식) 파일들이 개발자 PC 곳곳에 흩어져 저장된다. 쉽게 말하면 AI 에이전트가 어떤 서버에 접속하고 어떤 도구를 쓰는지 상세히 적어놓은 내부 지도와 같다. `mcp.json`이나 `claude_desktop_config.json` 같은 파일 내의 서버 인벤토리가 노출되면 공격자는 개발자가 어떤 내부 자원을 사용하는지 한눈에 파악할 수 있다. 단순한 설정 파일이라고 생각하기 쉽지만 그 안에는 서버 주소와 같은 민감한 정보가 포함되어 있어 AI 도구의 연결성을 높여주는 편의 기능이 역설적으로 기업 내부망의 구조를 외부에 드러내는 결정적인 단서가 되는 셈이다.

한국의 AI 실무 환경에서는 이러한 엔드포인트 보안을 위해 정기적인 스캔 체계를 구축하는 것이 시급하다. 많은 기업이 AI 에이전트 도입 속도에 치중한 나머지 개발자 개개인의 PC 상태를 점검하는 프로세스를 놓치고 있다. 수백 명의 개발자가 사용하는 PC를 일일이 수동으로 점검하는 것은 사실상 불가능하다. 이를 해결하려면 cron(크론, 리눅스 예약 작업 도구), launchd(런치디, 맥OS 서비스 관리자), systemd(시스템디, 리눅스 시스템 관리자) 같은 도구를 활용해 주기적으로 상태를 점검하는 자동화 루틴을 만들어야 한다. 기업 규모가 크다면 MDM(Mobile Device Management, 모바일 기기 관리) 툴을 통해 전사 개발자 PC의 스캔 주기를 중앙에서 제어하고 관리하는 방식이 현실적이다. 비유하자면 매일 아침 보안 요원이 출입문을 점검하듯 자동화된 스캔 프로세스가 백그라운드에서 상시 작동하며 취약한 패키지나 설정 파일의 노출 여부를 감시하는 체계가 갖춰져야 한다.