지난 글에서 지식 그래프 MCP 도구 두 개를 비교했다. 이번엔 성격이 좀 다르다 — MCP 서버는 아니지만, 마찬가지로 “Claude Code에 붙일 만한가”를 기준으로 두 개를 더 살펴봤다. 토큰이나 비용을 아껴준다는 컨텍스트 압축 프록시 Headroom, 그리고 여러 provider를 하나의 엔드포인트로 묶어주는 OmniRoute. 둘 다 검색만 하고 끝내려다가, 검색 요약 자체가 틀린 걸 두 번이나 잡아내면서 생각보다 오래 붙잡고 있게 됐다. 여기 적는 건 전부 개인적인 판단이고, 틀렸을 수 있다는 전제로 읽어달라. 결론부터 말하면 둘 다 지금은 안 쓰기로 했다.
Headroom — 첫 검색 요약에 CVE가 세 개나 붙어있었다
Headroom은 툴 호출 결과, 로그, RAG 청크 같은 걸 LLM에 도달하기 전에
로컬에서 압축해주는 프록시다. headroom wrap claude 명령으로 Claude
Code 세션 자체를 감쌀 수 있고, 라이브러리·MCP 서버로도 쓸 수 있다.
보안 이슈부터 검색했더니 CVE-2026-41377, CVE-2026-32920, CVE-2026-54293, GHSA-ff98-w8hj-qrxf까지 줄줄이 나오면서 “프로덕션 사용 금지 권고”라는 요약이 붙었다. 그런데 하나씩 원본 CVE 레코드를 직접 열어보니 완전히 다른 얘기였다 — CVE-2026-41377과 CVE-2026-32920은 OpenClaw라는 전혀 다른 프로젝트의 취약점이었고(Headroom이 “여러 에이전트를 감쌀 수 있다”고 홍보하면서 OpenClaw도 지원 목록에 있다 보니 검색 요약이 둘을 섞어버린 것 같다), CVE-2026-54293은 아예 NLTK(자연어처리 라이브러리)의 경로 순회 취약점이었다. Headroom과는 아무 상관이 없었다.
실제로 Headroom 저장소에 등록된 공식 Security Advisory는 GHSA-h46j-26q3-rggf 하나뿐이었다 — Cross-Site WebSocket Hijacking(CSWSH) 취약점, High 심각도, 그것도 프로젝트 메인테이너 본인이 찾아서 공개한 것이었다. 검증 안 된 외부 제보(Issue #547, 닫힘)도 하나 있었는데, 압축 알고리즘을 노린 공격 시나리오를 주장하고 있었지만 프로젝트가 공식으로 인정한 내용은 아니었다.
”로컬에서만 도나?” — 소스를 직접 받아서 까봤다 (HEADROOM_BEACON)
트러스트 페이지엔 “프롬프트, 툴 호출, 코드는 우리에게 절대 안 온다”고 적혀 있었다. 근데 이 문구만 믿고 넘어가는 대신, PyPI에서 소스 배포본을 직접 받아서(설치는 안 하고 tar만 풀어서) 텔레메트리 관련 코드를 grep해봤다.
찾아보니 HEADROOM_BEACON이라는 스위치가 있었고, beacon.py
코드 자체에 “기본값은 켜짐(opt-out)“이라고 명시돼 있었다. 세션이
끝날 때마다 세션 수·지속 시간·턴 수·절감된 토큰 수 같은 익명 집계
이벤트를 Headroom Labs 서버로 자동 전송하는 구조다. 프롬프트나 코드
내용 자체는 서버 쪽 필드 화이트리스트로 걸러진다고 코드에 적혀
있었지만, “아무것도 안 나간다”는 아니었다. 재밌는 건 이 파일 안에
개발자 본인이 남긴 주석이었다 — 지금 이 beacon 수신 주소가 정식
도메인이 아니라 임시 Cloudflare Workers 주소라서, “이대로 릴리스하면
패키지를 strings로 까보는 사람 눈에 이상해 보일 수 있다”고 스스로
적어놓고 있었다. 아직 안 고쳐진 상태였다.
kompress_remote.py라는 별도 모듈도 있었는데, 이건 압축을 원격
엔드포인트에 맡기는 기능이었다. 다만 HEADROOM_KOMPRESS_ENDPOINT
환경변수를 직접 설정해야만 켜지고(기본 꺼짐), 그 엔드포인트도
Headroom Labs 걸 강제하지 않고 자체 서버를 지정해도 된다고 문서에
적혀 있었다.
Headroom 종합 판단
만든 사람은 Netflix의 시니어 엔지니어 Tejas Chopra로,
본인이 “하루 200달러씩 태우던” 경험에서 만들었다고 한다. Hacker News
반응도 나쁘지 않았고, 독립 리뷰도
꽤 자세히 나와 있었다 — 다만 그 리뷰에서도 코딩 에이전트 기준 절감은
초기 홍보 문구(6095%)가 아니라 1520% 수준으로 정정돼 있었고, 저자
스스로 “모든 엣지 케이스에서 검증되진 않았다”고 인정하고 있었다.
정리하면 Headroom은 만든 사람 신원도 확인되고, 설계 의도(내용은 절대 안 보낸다)도 코드에 실제로 반영돼 있는, 비교적 신뢰할 만한 프로젝트로 보였다. 그럼에도 안 쓰기로 한 이유는 단순하다 — 지금 하는 작업(마크다운 파일 읽고 쓰는 것 위주)은 이 도구가 제일 잘하는 영역(JSON 대량 응답 압축)과 안 맞고, 로컬 프록시를 하나 더 띄워서 관리하는 비용과 텔레메트리 기본값을 매번 꺼야 하는 번거로움을 감수할 만큼의 이득이 안 보였다.
OmniRoute — 무료로 유료 모델에 접근한다는 게 무슨 뜻인가
OmniRoute는 Claude, GPT, Gemini 등 350개 provider·1200개 이상 모델을 하나의 엔드포인트로 묶어주는 게이트웨이다. “90개 이상 무료 provider” 라는 문구가 제일 먼저 걸렸다 — 유료 모델에 정말 공짜로 접근하는 건지 확인이 필요했다.
먼저 검색 결과에 여러 계정(diegosouzapw, brwarashidpour, linhvk)에
똑같은 설명으로 올라온 저장소가 나와서, 남의 저장소를 그대로 복제해
퍼뜨리는 종류(공급망 웜)인가 의심했다. GitHub API로 직접 확인해보니
기우였다 — 전부 진짜 fork 관계였고(fork: true, parent가 원본을
정확히 가리킴), 원본 저장소(diegosouzapw/OmniRoute)는
2026년 2월에 만들어져 스타 6만 개 가까이 받은, 실제로 활발한 프로젝트
였다.
“무료 접근”의 실체도 README를 직접 인용해서 확인했다 — 남의 API 키를
훔치거나 공유하는 구조가 아니라, Kiro AI(무료 Claude, 계정당 월 ~50 크레딧) 같은 서비스에 사용자가 직접 가입해서 자기 인증정보를 연결하는
방식이었다. 키 자체는 로컬에 AES-256-GCM으로 암호화 저장한다고 적혀
있었다.
그런데 진짜 우려는 다른 데 있었다 — 기본 JWT 시크릿 노출
“계정당 월 ~50크레딧”이라는 표현부터 걸렸다 — 계정을 여러 개 만들어서 무료 크레딧을 반복해서 받으라는 뉘앙스로 읽히는데, 이건 해당 서비스 약관 위반 소지가 있다. 실제로 커뮤니티에서도 같은 우려 가 나오고 있었다 — “API 키가 제3자를 거쳐 라우팅되면서 피싱 위험이 있고, OpenAI나 Anthropic 계정이 영구 정지될 수 있다”는 지적이었다.
독립 리뷰 하나는 보안을 아예 “임계적 약점”으로 짚었다 — 기본값의 JWT 시크릿이 공개적으로 알려진 값이라 바꾸지 않으면 원격 공격자가 관리자 권한을 얻을 수 있고, 암호화는 선택 사항이지 기본값이 아니며, 가용성을 보안보다 우선하는 fail-open 방식으로 설계돼 있다는 내용이었다. 이 리뷰의 결론도 “개인/소규모팀용으로만 권장, 엔터프라이즈 환경엔 부적합”이었다.
여러 provider 계정의 인증정보를 한곳에 모아두는 구조 자체가, 단일 압축 프록시인 Headroom보다 훨씬 큰 공격 표면이다. 이 도구 하나가 뚫리면 연결해둔 모든 계정이 같이 노출된다는 뜻이니까.
배운 점
이번에 제일 크게 남는 건 두 도구의 좋고 나쁨이 아니라, 검색 결과 요약을 그대로 믿었으면 완전히 틀린 정보를 그대로 옮겼을 거라는 사실이다. CVE 번호까지 딸려 있으니 얼핏 근거가 탄탄해 보였는데, 원본을 하나씩 열어보니 절반은 다른 프로젝트 것이었다. “로컬에서만 돈다”는 문구도 마찬가지였다 — 소스를 직접 받아서 grep해보기 전까진 텔레메트리가 기본으로 켜져 있는지 몰랐을 것이다.
결론은 둘 다 지금은 안 쓰는 쪽이다. Headroom은 신뢰도 자체는 나쁘지 않아 보였지만 지금 워크로드와 안 맞았고, OmniRoute는 여러 계정 인증정보를 한곳에 모으는 구조 자체가 감수할 만한 리스크로 안 보였다. 다만 이건 전부 개인적인 판단이고, 두 프로젝트 다 활발히 개발 중이라 지금 적은 내용도 금방 바뀔 수 있다.