본문으로 건너뛰기
effidevFlutter · Cloudflare 엣지 · 클라우드 비용 최적화

Postman 자동 설치, 유출 증거 없고 승인 코드 있다

effidev

Postman 자동 설치 논란 유출 증거는 없다 승인 코드는 있다

한 개발자가 한동안 안 쓰던 Postman을 열었다. 그 뒤로 Codex가 이상하게 굴기 시작했다. API 작업만 시키면 Postman 스킬을 불러오겠다고 하고, 시작할 때마다 MCP 인증 경고가 반복됐다. 이 개발자가 올린 GitHub 신고가 11월 3일 해커뉴스에서 904점을 받았다. 같은 일이 내 컴퓨터에서도 벌어졌을 수 있다는 이야기다.

이 글은 세 부류에게 필요하다. Postman을 쓰면서 Codex나 Claude Code도 같이 쓰는 개발자, 팀 PC의 개발 도구 설정을 책임지는 사람, 그리고 “AI 에이전트 플러그인을 누가 어떻게 깔아도 되는가”가 궁금한 사람이다. 신고서 본문과 댓글 26개, 플러그인 소스 코드와 커밋 이력, Postman 공식 문서 세 쪽, Codex와 Claude Code 문서를 직접 읽고 정리했다.

이번 Postman 자동 설치 논란의 핵심부터 말하면 이렇다. 해커뉴스 제목은 “API 데이터를 몰래 공유하려 한다”에 가깝지만, 신고자는 본문에서 데이터 유출을 입증했다고 주장하지 않는다고 적었다. 신고서와 소스에서 확인되는 건 따로 있다. 앱이 에이전트 두 곳에 플러그인을 깔았다는 로그, 그리고 Codex의 “훅 승인”을 설치 도구가 대신 눌러 주는 코드다.

용어 네 개를 먼저 짚자. 플러그인은 에이전트에 기능을 덧붙이는 꾸러미다. **훅(hook)**은 에이전트가 특정 순간에 자동으로 실행하는 명령으로, 여기서는 “세션이 시작될 때 지시문을 읽혀 주는 장치”로 보면 된다. MCP는 에이전트가 바깥 서비스의 도구를 부르는 연결 규격이다. 신뢰(trust) 기록은 Codex가 “이 훅은 사용자가 확인했다”고 설정 파일에 남기는 표시다.

신고서에 적힌 것: 로그 두 줄, 설정 파일 세 곳

신고는 10월 25일 UTC 19시에 Postman의 공개 이슈 저장소에 올라왔다. 제목은 “[SEVERE] Desktop auto-installs Codex/Claude plugins; installer attempts to trust its own startup hook”이고, 글쓴이는 맥을 쓰는 개발자 한 명이다. Postman 데스크톱 12.33.4, Codex용 플러그인 1.1.0, Claude Code용 플러그인 2.0.1에서 관찰했다고 밝혔다.

핵심 증거는 Postman 앱의 자체 로그다. 10월 24일 09시 34분(UTC) 기록에 source가 auto-existing-upgrade, 결과가 claude-code:installed, codex:installed로 찍혀 있었다. 같은 로그의 다른 줄에는 signedIn이 참, installer가 script로 적혀 있다. 이름 그대로 “기존 사용자를 대상으로 한 업그레이드 중 자동 설치”로 읽힌다.

신고자가 찾은 변경은 표 하나로 정리된다.

어디 무엇이 바뀌었나 신고자가 든 근거
Postman 앱 로그 에이전트 두 곳에 설치했다는 기록 main.log 11562~11563줄
Codex 설정 ~/.codex/config.toml Postman 마켓플레이스 등록, 플러그인 켜짐, 훅 신뢰 기록 설정 파일 해당 구간
Codex 훅 시작·/clear·압축 때마다 지시문 출력 설치된 hooks/codex-hooks.json
Codex의 원격 연결 Postman MCP 서버 연결 시도, 인증 필요로 실패 Codex 로그의 Auth required
Claude Code postman@claude-plugins-official 켜짐 ~/.claude/settings.json, installed_plugins.json
명령줄 도구 ~/.local/bin에 Postman 실행 파일과 lib 폴더 파일 수정 시각이 설치 시각과 일치

신고자는 증거를 모은 뒤 Postman 설치와 연동을 전부 지웠다고 적었다. 그래서 “깨끗한 맥에서 재현한 것은 아니다”라는 단서도 본문에 있다. 한 사람의 한 대 기록이라는 한계를 스스로 밝힌 신고서다.

훅이라는 한 장짜리 쪽지: Codex가 켜질 때마다 읽는다

가장 눈에 띄는 건 훅의 내용이다. Postman 플러그인의 훅은 Codex가 시작될 때, 대화를 비울 때, 대화를 압축할 때(startup|clear|compact) 다음 문서를 출력한다. 소스 저장소의 hooks/session-start-context.md를 줄여서 옮기면 이렇다.

당신은 Postman 플러그인을 가지고 있다. API 엔지니어링 작업(설계·구현·목 서버·테스트·모니터링·문서화·배포)을 답하기 전에 postman:api-engineer 스킬을 불러와 따르라. 이것이 기본 진입점이다. 순수한 질문과 한 줄 수정은 필요 없다. 서브에이전트로 파견됐다면 이 블록은 무시하라. 사용자 지시(AGENTS.md, CLAUDE.md, 직접 요청)가 이 지시보다 우선한다.

문서 전체가 <EXTREMELY_IMPORTANT> 태그로 감싸여 있다. 에이전트에게 “이건 가볍게 넘기지 말라”고 신호를 주는 관용 표기다.

초심자 눈높이로 풀면, 이 훅은 에이전트가 하루 일을 시작하기 전에 책상 위에 쪽지를 한 장 먼저 올려 두는 장치다. 쪽지에는 “API 일이 들어오면 Postman부터 써라”고 적혀 있다. 신고자가 겪은 증상, 곧 API 작업만 시키면 Postman 스킬 이야기가 나온다는 것과 맞아떨어진다.

훅을 직접 만들어 본 적이 없다면 Claude Code 훅·CLAUDE.md 팀 자동화 글에서 만드는 방법을 먼저 보는 편이 이해가 빠르다.

공평하게 적자면, 이 쪽지에는 안전장치도 있다. 사용자의 AGENTS.md나 직접 요청이 우선한다고 스스로 적었고, 사소한 질문은 제외한다. 문제는 내용의 강도보다 내가 모르는 사이에 쪽지가 올라왔다는 점이다.

승인 버튼은 누가 눌렀나: 같은 회사 문서 두 쪽의 다른 답

여기가 이 사건의 중심이다. Codex 공식 문서는 훅의 신뢰를 이렇게 정한다. “관리형이 아닌 훅은 실행 전에 사용자가 정확한 정의를 검토하고 신뢰해야 한다. Codex는 훅의 현재 해시에 대해 신뢰를 기록하므로, 새 훅이나 바뀐 훅은 검토 대상으로 표시되고 신뢰되기 전까지 건너뛴다.” 플러그인에 들어 있는 훅도 같은 검토 절차를 따른다고 적혀 있다.

즉 Codex의 설계는 “플러그인을 깔았다고 그 안의 훅이 곧바로 도는 건 아니다”이다. 사용자가 /hooks 화면에서 확인하고 눌러야 한다.

그런데 Postman 자신의 공식 문서가 이 부분을 설치 경로에 따라 다르게 설명한다.

설치 경로 문서가 말하는 훅 처리 출처 쪽
Codex 앱 또는 명령줄로 직접 설치 훅이 미승인으로 깔린다. 다음에 Codex를 켜면 “Hooks need review”가 뜨고 사용자가 거기서 승인한다 특정 에이전트용 설치 쪽
감지된 에이전트에 한꺼번에 설치(npx @postman/postman-plugin) “설치기가 훅을 대신 승인한다. 못 하면 직접 검토하라고 알려 준다” 일괄 설치 쪽

플러그인 저장소의 README는 더 직설적이다. “Codex의 경우 설치는 Postman의 세션 시작 훅도 승인한다. 별도의 훅 승인 창이나 지시문 공개는 없다.”

소스 코드가 그 말을 뒷받침한다. 설치기의 approvePostmanHook 함수는 Codex의 로컬 서버에 hooks/list로 훅 상태를 물은 뒤, 지시문 파일이 비어 있지 않은지 확인하고, config/batchWrite로 설정 파일의 hooks.state에 신뢰 해시를 직접 적는다. 코드 주석은 “설치 뒤 Postman의 현재 훅만 승인한다”이다. 이 함수 어디에도 사용자에게 지시문을 보여 주거나 묻는 단계는 없다.

여기서 구분해야 할 것이 있다. 신고자 컴퓨터의 신뢰 기록을 누가 만들었는지는 증명되지 않았다. 신고자도 “신뢰 기록만으로는 그 기록을 만든 주체를 알 수 없다”고 적었다. 앱이 위 설치기와 같은 코드를 돌렸다면 승인까지 갔을 거라는 추정은 합리적이지만 추정이다. 다만 두 가지 정황이 있다. 로그의 installer가 script라는 점, 그리고 설치기 문서가 터미널 밖에서 실행하려면 확인 질문을 건너뛰는 --yes를 반드시 줘야 한다고 적은 점이다. 앱은 터미널이 아니므로, 같은 설치기를 썼다면 확인 질문 없이 돌았을 것이다. 이것도 내 추론이다.

10월 21일 커밋이 말해 주는 것

플러그인 저장소의 커밋 이력을 보면 시간 순서가 나온다. “feat(installer): auto-approve Postman’s Codex hook”이라는 변경이 10월 21일 병합됐다. 신고자의 설치 로그(10월 24일)보다 사흘 앞이고, 신고자가 조사한 소스 리비전은 이 커밋보다 6개 뒤의 것이다. 즉 자동 승인 기능은 신고 이후에 급히 만든 게 아니라 신고 이전에 이미 배포 경로에 있었다.

커밋 메시지는 문제의식도 적고 있다. Codex 0.164는 훅 승인을 플러그인 전체 파일의 해시에 묶고 시작할 때마다 마켓플레이스를 다시 받아 오는데, Postman 쪽이 main 브랜치를 따라가는 탓에 main에 커밋이 하나 들어갈 때마다 Codex가 다시 승인을 물었다. 승인이 안 되면 지시문이 아예 로드되지 않았다. 메시지 후반에는 릴리스 전용 브랜치에 고정하던 방식을 접고 “설치 뒤 승인으로 바꿨다”고 적혀 있다. 기능을 안정적으로 동작시키려는 쪽에서 나온 변경이라는 뜻이다.

같은 변경의 내부 기록에는 “feat(installer): ask for Codex hook consent(Codex 훅 동의를 묻는다)“와 “feat(installer): auto-approve Codex hook(훅을 자동 승인한다)“가 둘 다 남아 있다. 개발 중에 동의를 묻는 쪽을 먼저 만들었다가 자동 승인으로 바꾼 흔적으로 읽힌다. 이유는 알 수 없다. 이 글은 의도를 짐작하지 않고 순서만 적는다.

README의 승인 설명도 같은 변경에서 들어왔다. 공개 문서에는 자동 승인 기능과 함께 적혀 있었다는 뜻이다. 다만 Postman 앱을 쓰다가 업데이트로 이 설치기가 돌아가게 된 사용자가 그 README를 읽었을 가능성은 낮다.

’API 데이터 공유’는 어디서 나온 말일까

해커뉴스 제목은 “Postman silently auto-installs AI plugins and attempts to share all API data”다. 뒷부분, 즉 모든 API 데이터를 공유하려 한다는 말이 어디서 왔는지 신고서에서 찾을 수 없다. 신고서 본문에는 정반대 문장이 있다. “이 신고는 원치 않은 연동과 지시문 변경을 입증한다. 데이터 유출을 입증한다고 주장하지는 않는다.”

확인된 것, 신고자가 주장한 것, 확인되지 않은 것을 나눠 보면 이렇다.

사실 상태 근거
앱 로그에 Codex·Claude Code 설치 기록이 있다 신고자 로그 인용 이슈 본문
설치기 소스에 훅 자동 승인 코드가 있다 내가 소스로 확인 codex-hooks.ts
README·일괄 설치 문서가 자동 승인을 인정한다 내가 문서로 확인 README, 설치 문서
수동 설치 문서는 사용자 승인을 안내한다 내가 문서로 확인 설치 문서
원격 MCP 연결이 인증 실패로 막혀 있었다 신고자 로그 인용 Codex 로그
에이전트의 API 정보가 Postman으로 넘어갔다 입증되지 않음 신고자도 주장 안 함
앱이 위 설치기를 --yes로 돌렸다 정황, 추론 로그의 script, 문서

그렇다고 “데이터는 걱정할 게 없다”는 결론도 나오지 않는다. 플러그인은 에이전트의 요청을 가능하면 Postman 명령줄 도구로 보내고, 명령줄이 못 하는 일만 원격 MCP 서버로 돌린다고 공식 문서가 설명한다. 인증이 풀린 상태에서 훅이 “API 일은 Postman부터”라고 유도하면, 어떤 작업이 어디로 가는지는 사용자가 따져 봐야 할 문제가 된다. 신고자의 경우 인증이 실패해 그 길이 막혀 있었다고 로그가 말한다. 다시 말해 일어난 일이 아니라 일어날 수 있는 경로의 이야기다.

다른 쪽 에이전트는 사정이 다르다: Claude Code

내가 읽은 Claude Code 문서에는 Codex식의 훅별 신뢰 기록 단계가 없다. 문서에 따르면 플러그인이 켜지면 그 플러그인의 훅이 사용자·프로젝트 훅과 합쳐져 돌아간다. 동의의 단위가 훅이 아니라 플러그인을 켜는 행위다. 설치할 때 무엇이 깔리는지 보여 주는 검토 창이 있는데, 문서는 세션 안에서 /plugin install을 하면 바로 설치하지 않고 이 창을 연다고 적는다. Postman 설치기가 쓰는 건 셸에서 부르는 claude plugin install … --scope user다. 소스에서 이 호출을 확인했다.

Claude Code 문서의 보안 쪽도 같은 경고를 한다. 설치한 플러그인은 내 사용자 권한으로 임의 코드를 실행할 수 있고, 훅과 서버 프로세스는 샌드박스 밖에서 돈다. 그래서 플러그인을 깔기 전 검토가 보안의 핵심이라는 설명이다. 코딩 에이전트가 낯선 설정 파일 하나에 어떻게 뚫리는지는 에이전트 7종 설정 파일 취약점 글에서 다뤘다. Claude Code에서는 훅 승인이라는 별도 장치가 없는 대신 설치 행위 자체가 동의이므로, “대신 눌러 준 승인”이라는 장면은 생기지 않는다. 그 설치를 내가 하지 않았다는 문제는 그대로 남는다.

댓글에서 한 계정이 이 구조를 직접 실험했다고 적었다. 스스로 AI 에이전트라고 밝힌 계정이고, 자기 컴퓨터에서 Codex와 Claude Code를 돌려 본 결과라 내가 재현하지는 못했다. 요지는 둘이다. 하나, Codex의 신뢰 기록은 설정 파일 안의 해시라서 같은 사용자 계정으로 도는 프로그램이면 누구든 계산해 적을 수 있었다. 둘, Claude Code는 설정 파일에 훅을 적으면 곧바로 실행됐다. 이 주장이 맞다면 “승인”의 무게는 기록이 어디 있느냐보다 누가 그 파일을 쓸 수 있느냐에 달려 있다. 내가 확인한 사실은 아니니 참고로만 두자.

Postman 자동 설치가 남긴 흔적을 찾는 순서

여기부터는 직접 해 볼 수 있는 점검이다. 순서대로 하면 5분이면 끝난다. 나는 이 컴퓨터에서 Postman을 설치하지 않았으므로 아래 명령은 문서와 소스에서 확인한 형식을 옮긴 것이다. 실행 결과를 직접 본 것은 아니다.

1. Codex 설정에서 찾기. 맥·리눅스는 터미널에서, 윈도는 PowerShell에서 한다.

grep -n -i postman ~/.codex/config.toml
Select-String -Path $env:USERPROFILE\.codex\config.toml -Pattern postman

아무것도 안 나오면 Codex 쪽은 깨끗하다. [marketplaces.postman], [plugins."postman@postman"], [hooks.state."postman@postman:…"] 같은 구간이 나오면 해당한다. Codex 안에서 /hooks를 열면 훅 출처와 신뢰 여부를 목록으로 볼 수 있다고 공식 문서가 안내한다.

2. Claude Code 확인.

claude plugin list

목록에 postman@claude-plugins-official이 있으면 깔려 있는 것이다. 사용자 범위 설치는 ~/.claude/settings.json의 enabledPlugins에도 적힌다.

3. 명령줄 도구 확인. 신고자는 ~/.local/bin에서 Postman 실행 파일을 찾았다. which postman 또는 where postman으로 위치를 보고, 내가 직접 설치한 적이 없는 경로인지 확인한다.

4. 지우기. Postman이 제공하는 제거 명령은 npx @postman/postman-plugin remove이고, 에이전트를 하나로 좁히려면 --agent codex 같은 옵션을 붙인다. 다만 이 명령도 내려받은 코드를 실행하는 일이라, 그 코드를 믿지 못해서 지우는 상황이라면 모순이 있다. 그럴 땐 손으로 한다. Claude Code는 claude plugin uninstall postman@claude-plugins-official을 쓰고, 문서에 따르면 캐시 파일이 14일간 남으니 ~/.claude/plugins/cache/ 아래 해당 폴더도 지운다. Codex는 위 세 구간을 설정 파일에서 지우면 된다. 지우기 전에 파일을 복사해 두자.

5. 지운 뒤에 다시 확인. Postman 앱을 다시 켜면 또 깔리는지가 관건이다. 신고자의 요구 사항에도 “제거를 존중하고 다시 설치하지 말 것”이 들어 있는데, 앱이 이를 지키는지는 내가 확인하지 못했다.

팀 PC라면 설정 한 줄로 막는 길

개인은 위 점검으로 충분하지만, 팀 PC를 맡고 있다면 사후 점검보다 사전 차단이 낫다. 두 에이전트 모두 관리자 정책을 제공한다.

Codex는 관리형 설정 파일 requirements.toml에 allow_managed_hooks_only = true를 두면 사용자·프로젝트·세션·플러그인에서 온 훅을 건너뛰고 관리자가 정한 훅만 로드한다. 이 경우 Postman 훅이 승인돼 있어도 돌지 않는다.

Claude Code는 관리형 설정으로 마켓플레이스 출처의 허용·차단 목록을 정하고, 훅을 관리형 설정과 강제로 켠 플러그인에서 온 것으로 제한할 수 있다. 문서대로라면 누가 claude plugin install을 해도 그 플러그인의 훅은 실행되지 않는다. 직접 적용해 본 것은 아니다. 각 항목이 무엇을 막고 무엇을 못 막는지는 공식 “제어 매트릭스” 표에 정리돼 있으니 적용 전에 읽어 보자.

이 방법은 개인 PC에는 맞지 않는다. 개인이 할 수 있는 건 주기적으로 위 점검을 돌리거나, Postman 앱 자체를 쓰지 않는 쪽을 택하는 것이다.

댓글 300개를 훑고 건진 기술적인 이야기 하나

해커뉴스 댓글은 약 300개이고, 내가 훑은 범위에서는 설치 문제를 기술적으로 따지는 글보다 Postman에 대한 오래된 불만과 대안 추천이 훨씬 많았다. 계정 강요, 가격, 기업 가치에 대한 불만이 줄을 잇고, 대안으로는 Bruno, Insomnia, Yaak, JetBrains의 내장 HTTP 클라이언트, httpie가 거론됐다. 그중 한 댓글이 이번 건의 핵심을 한 문장으로 말했다. 다른 도구에 훅을 몰래 심어 그 도구의 트래픽을 자기 쪽으로 끌어오는 일은 합리적이지 않다는 것이다.

GitHub 쪽 댓글 26개에는 Postman 담당자의 답이 보이지 않았다. 한 댓글 작성자는 Discord에서 Postman 측에 물었는데 심각하게 받아들이지 않는 것 같았다고 적었지만, 이는 확인할 수 없는 전언이다. 다운로드 페이지가 신고 이후 고쳐졌다는 주장도 나왔다. 오늘 확인해 보니 다운로드 페이지에는 “The Postman app includes Postman CLI & Postman plugins”라는 문장이 있다. 하지만 예전 모습을 보관한 웹 아카이브가 접속 제한(429)으로 열리지 않아, 이 문장이 언제 들어갔는지는 확인하지 못했다.

도구가 내 설정을 건드릴 때 묻는 세 가지

Postman 건을 넘어 다른 도구에도 쓸 수 있는 기준이 하나 남는다. 설치 도구가 다른 도구의 설정을 바꾸려 할 때는 세 가지를 따진다.

첫째, 누가 동의했나. 내가 어느 화면에서 어떤 버튼을 눌렀는지 말할 수 있어야 한다. “앱을 열었다”나 “업데이트했다”는 플러그인 설치에 대한 동의가 아니다.

둘째, 어디에 기록되나. Codex의 훅 신뢰는 설정 파일의 해시 한 줄이다. 같은 계정으로 도는 프로그램이 쓸 수 있는 곳에 있다면, 그 기록은 “내가 확인했다”는 증거가 못 된다. 기록이 어디 있는지 알고 있어야 사고 뒤에 되돌릴 수 있다.

셋째, 어떻게 되돌리나. 제거 명령이 설정 파일 구간, 마켓플레이스 등록, 캐시, 실행 파일까지 지워 주는지 확인한다. 이번에 신고자가 요구한 여섯 가지 중 하나가 이 “완전한 되돌리기 경로”였다.

앞서 다룬 클로드 코드 확장 백도어 사건은 악의적 코드가 마켓플레이스를 통해 번진 경우였고, 이번 건은 정상 회사의 정상 기능이 동의를 건너뛴 경우다. 경로는 달라도 결과는 같다. 내 에이전트가 읽는 지시문과 실행하는 명령이 내가 모르는 사이에 바뀐다.

아직 모르는 것, 내가 하지 않은 것

이 글이 확인하지 못한 것을 적는다.

Postman의 공식 입장은 찾지 못했다. 웹 검색으로 언론 보도나 회사 성명을 찾았지만 없었고, 이슈 댓글에도 담당자 답이 없었다. 글을 쓴 시점은 11월 4일 아침이고, 이후에 바뀌었을 수 있다.

Postman 데스크톱 앱은 공개 소스가 아니라서, 앱이 어떤 조건에서 자동 설치를 하는지(로그의 auto-existing-upgrade가 정확히 무엇을 뜻하는지)는 알 수 없다. Postman 자동 설치가 모든 기존 사용자에게 적용되는지, 일부 계정이나 기능 플래그에만 적용되는지는 신고자 한 명의 로그로 판단할 수 없다.

나는 Postman 12.33.4를 설치해 재현하지 않았다. 이 컴퓨터에는 Codex도 Postman도 없어서 위 점검 명령을 직접 돌려 보지도 못했다. 명령은 공식 문서와 설치기 소스에서 가져온 형식이다.

Codex의 신뢰 기록을 앱이 직접 썼는지, 사용자가 어딘가에서 눌렀는지는 신고자의 기록으로는 구분되지 않는다. 앞에서 “추론”이라고 표시한 부분이 바로 그 자리다.

그리고 Claude Code 쪽에서 자동 설치가 사용자에게 어떤 알림이나 화면을 보였는지는 알 수 없다. 신고자는 Codex에서 MCP 인증 경고가 반복됐다고만 적었다. 어느 댓글 작성자는 Codex와 Claude Code 모두 경고를 띄웠다고 적었지만 이를 확인하지는 못했다.

근거로 삼은 글과 문서