Postman AI 플러그인 자동 설치 논란: 데이터 위험과 점검·제거법

Postman AI 플러그인 자동 설치 논란의 핵심은 API 데이터를 몰래 보냈다는 것이 아니라 다른 개발 도구의 설정을 사용자의 명시적 동의 없이 바꿨다는 점이에요. 2026년 11월 4일 기준으로 공개된 GitHub 이슈와 Postman 공식 문서를 읽어 보면, Postman 데스크톱 앱이 업데이트 과정에서 Claude Code·Codex 같은 코딩 에이전트에 Postman 플러그인과 시작 훅, 원격 MCP 연결, Postman CLI를 설치한 기록은 확인돼요. 반면 데이터가 실제로 업로드됐다는 증거는 아직 제시되지 않았어요. 이 글은 확인된 사실과 과장된 주장을 나누고, 내 PC와 팀에서 무엇을 어떤 순서로 점검·제거할지 정리해요.

Postman AI 플러그인 자동 설치 논란, 무엇이 확인됐나

2026년 10월 25일 Postman 공식 저장소에 이슈 #14370이 올라왔어요. 신고자는 macOS에서 Postman 데스크톱 12.33.4를 열자 Codex가 API 작업마다 Postman 스킬을 불러오고 MCP 인증 경고가 반복됐다고 적었어요. Postman 자체 로그(main.log)에는 2026년 10월 24일 시각으로 auto-existing-upgrade 출처의 설치가 실행돼 claude-code:installed, codex:installed 결과가 남았다고 인용했어요. 이 글감은 해커뉴스 1위에 오르며 '모든 API 데이터를 공유하려 한다'는 제목으로 퍼졌지만, 원문 신고자는 보고서가 데이터 유출을 입증하지 않는다고 분명히 적었어요.

11월 3일에는 다른 사용자가 같은 경로를 보고했어요. 기존에 로그인돼 있던 Postman이 12.31.3에서 12.35.1로 업데이트되면서 CLI와 Claude Code·Codex 플러그인이 설치됐고, Cursor는 이미 설치된 상태로 기록됐다고 해요. 이 사용자의 Codex 설정에는 훅 신뢰 기록이 없었다고 덧붙였어요. 즉 같은 '자동 설치'라도 기기와 버전마다 남은 흔적이 다를 수 있어요.

회사 측 입장은 이슈 댓글로 전해졌어요. 댓글에 인용된 Postman 명의 답변은 CLI와 에이전트 플러그인을 따로 설치하기 어려워하는 사용자가 많아 데스크톱 앱에 묶었고, 다운로드 페이지와 업데이트 흐름에서 안내하며 앱 안에서 제거할 수 있다고 설명했어요. 또 기존 사용자에게 옵트인을 더 분명히 하고 훅 승인·세션 시작 동작을 검토하겠다고 했어요. 실제로 Postman 다운로드 페이지에는 현재 'Postman 앱에 Postman CLI와 Postman 플러그인이 포함된다'는 문구가 있어요. 다만 한 댓글 작성자는 10월 26일 웹 아카이브 사본에는 이 문구가 없었다고 주장했으니, 사전 고지 여부는 아직 논쟁 중이에요.

무엇이 바뀌었나: 에이전트별 변경 위치

Postman 플러그인 README에 따르면 npx @postman/postman-plugin 한 번으로 Antigravity, Claude Code, Codex, GitHub Copilot CLI, Cursor, Factory Droid, Kimi Code, OpenCode, Pi까지 감지된 에이전트 모두에 설치할 수 있어요. 이슈에서 보고된 변경은 그중 일부지만, 같은 설치기가 쓰였다면 다른 에이전트도 확인 대상이에요.

가장 민감한 부분은 Codex 시작 훅이에요. 훅은 세션이 시작·초기화·압축될 때 실행되며, 이슈에 따르면 '사소하지 않은 API 엔지니어링 작업 전에는 postman:api-engineer 스킬을 불러와 따르라'는 지시를 에이전트 문맥에 넣어요. 사용자가 Postman을 쓰라고 하지 않아도 API 작업 전반이 Postman 쪽으로 흘러갈 수 있다는 뜻이에요. OpenAI Codex 훅 문서는 관리형이 아닌 훅은 사용자가 정확한 정의를 검토하고 신뢰해야 실행되며 신뢰를 훅 해시에 기록한다고 설명해요. Postman README는 npx 설치기가 이 시작 훅을 승인한다고 적고 있어, 사용자 승인 단계가 설치기 쪽에서 처리되는 구조예요.

데이터는 어디로 가나: API 키 유출 위험 경로

설치 자체와 데이터 전송은 구분해서 봐야 해요. Postman 플러그인 README는 데이터가 Postman으로 가는 경로를 비교적 솔직하게 적어 두었어요. 독자가 실제로 신경 쓸 경로는 세 가지예요.

• 워크스페이스 게시: postman init으로 폴더를 Postman 워크스페이스에 연결하면 컬렉션 실행 결과, 테스트 결과, 린트 결과, 요청 활동 등이 기본으로 게시돼요. 명령마다 --report-events=false로 끌 수 있어요.
• 원격 MCP: CLI를 쓸 수 없을 때를 위한 대체 경로로 Postman 호스팅 MCP 서버가 등록돼요. README는 MCP 도구 호출이 설계상 Postman에 도달하며 CLI 플래그로 통제되지 않는다고 밝혀요. 이 경로가 싫다면 MCP 서버를 설치하지 말라고 안내해요.
• 익명 사용 집계: CLI는 워크스페이스·사용자·페이로드 없이 명령 사용 횟수만 집계한다고 설명해요.

API 키 관점에서 보면 위험은 '에이전트가 다루는 데이터'에서 생겨요. 코딩 에이전트는 저장소의 .env, 테스트용 환경 변수, 요청 헤더를 읽을 수 있어요. 시작 훅이 API 작업을 Postman 스킬로 유도하고, 사용자가 MCP에 로그인해 둔 상태라면 그 과정에서 요청 본문이나 헤더가 Postman 클라우드로 전달될 수 있어요. 이슈 신고자의 경우 MCP는 인증이 없어 연결에 실패했으므로 이 경로가 작동하지 않았어요. 결국 점검 질문은 '설치됐나'보다 '로그인된 MCP나 워크스페이스 연결로 비밀값이 오갈 수 있었나'예요.

내 PC에서 점검·제거하는 순서

Postman을 계속 쓸지와 상관없이, 먼저 무엇이 설치됐는지 확인한 뒤 제거 여부를 정하는 편이 안전해요. 아래 순서는 macOS 기준이며 Windows·Linux는 경로가 달라요.

1. 1

   Postman 로그에서 자동 설치 기록 찾기

   main.log에서 auto-existing-upgrade, autoInstall.plugin, PostmanAgentPluginService 같은 문자열을 찾아 설치 시각과 대상 에이전트를 기록해요. 이 시각이 이후 설정 파일 변경 시각을 대조하는 기준이 돼요.

2. 2

   에이전트 설정 파일 확인

   ~/.codex/config.toml에서 postman 마켓플레이스·플러그인·hooks.state 항목을, ~/.claude/settings.json과 installed_plugins.json에서 postman 플러그인을 찾아요. Cursor·Copilot CLI 등 다른 에이전트를 쓴다면 각 플러그인 목록도 확인해요. 수정 전에 설정 파일을 백업해 두세요.

3. 3

   Codex 훅 검토

   Codex CLI에서 /hooks를 열면 훅 출처를 보고, 새로 바뀐 훅을 검토하고, 관리형이 아닌 훅을 개별로 끌 수 있어요. 데스크톱 앱은 Settings > Hooks에서 같은 작업을 해요. Postman 세션 시작 훅을 원치 않으면 여기서 비활성화해요.

4. 4

   플러그인과 CLI 제거

   README가 안내하는 공식 경로는 npx @postman/postman-plugin status로 현황을 보고 remove(필요하면 --agent <id>)로 제거하는 방식이에요. 다만 npx는 npm에서 패키지를 다시 받아 실행하므로, 스크립트 실행이 꺼려지면 각 에이전트의 플러그인 관리 명령으로 개별 제거해요. ~/.local/bin에는 다른 도구의 실행 파일도 있으니 폴더 전체를 지우지 말고 postman 파일만 정리해요.

5. 5

   제거 후 다시 확인

   설정 파일을 다시 검색해 postman 항목과 훅 신뢰 기록이 남지 않았는지 확인해요. 이후 Postman 앱이 업데이트될 때 다시 설치되지 않는지도 한동안 로그로 지켜봐요.

Postman을 계속 쓰면서 플러그인만 두고 싶다면, 최소한 원격 MCP 연결을 쓸지 정하고 워크스페이스 연결 시 --report-events=false 사용 여부를 결정해요. 프롬프트 안에서 어떤 지시가 우선하는지는 결국 모델 동작에 기대는 것이라, 설정 차원에서 훅을 끄는 조치를 대신하지는 못해요.

팀·조직에서 할 일: AI 기능 끄기와 정책

개인 PC 정리만으로는 다음 업데이트나 다른 도구에서 같은 일이 반복될 수 있어요. 조직이라면 '어떤 개발 도구가 다른 도구의 설정을 바꿀 수 있는가'를 정책으로 다루는 편이 좋아요.

• Codex 관리형 설정: Codex 문서에 따르면 관리자는 requirements.toml에서 allow_managed_hooks_only = true로 사용자·프로젝트·플러그인 훅을 건너뛰고 관리형 훅만 허용할 수 있어요. 훅 기능 전체를 끄려면 [features] hooks = false를 써요.
• Postman AI 접근: Postman 지원 문서에 따르면 엔터프라이즈는 팀 단위로 Postman AI를 켜고 끌 수 있고, 그 밖의 플랜은 개인 설정(Settings > AI)에서 바꿔요.
• 가드레일: Postman 관리 문서는 엔터프라이즈 조직 설정의 Guardrails에서 Secret Scanner(Postman v11.87 이상, Postman 클라우드나 LLM 제공자로 보내기 전 데이터 검사), PII 마스킹(기본 꺼짐), MCP 정책(기본값 모든 MCP 서버 허용)을 관리한다고 설명해요. 기본값을 그대로 두지 말고 조직 기준에 맞게 바꿨는지 확인하세요.
• 네트워크 통제: 원격 MCP를 업무에 쓰지 않는 조직이라면 프록시·방화벽에서 해당 MCP 엔드포인트를 차단하거나 허용 목록으로 관리할 수 있어요. 차단 전에 실제 사용 팀이 있는지 먼저 파악해요.
• 변경 감시: 에이전트 설정 디렉터리(~/.codex, ~/.claude 등)의 변경을 엔드포인트 관리 도구로 감시하면, 비슷한 자동 설치를 사후가 아니라 발생 시점에 알 수 있어요.

AI 개발 도구 관련 이슈는 해커뉴스·텔레그램 채널에서 먼저 퍼지는 경우가 많아요. 더따리 AI 텔레그램 트렌드와 블로그 트렌드에서 비슷한 보안·개인정보 이슈가 어떻게 언급되는지 살펴보면 점검 대상 도구를 빨리 파악하는 데 도움이 돼요. 다만 트렌드 도구는 화제성을 보여 줄 뿐 사실관계를 확인해 주지는 않으니, 이번처럼 원문 이슈와 공식 문서를 함께 읽어요.

페이지 참고

트렌드theddari.com›트렌드텔레그램 · AIAI 채널 실시간 포스팅 피드

페이지 참고

트렌드theddari.com›트렌드블로그 대시보드네이버 블로그 활동량 랭킹

개발 도구 AI 기능을 들일 때 확인할 기준

이번 사례는 Postman만의 문제가 아니라 코딩 에이전트 생태계 전체의 신뢰 경계 문제예요. 플러그인·훅·MCP는 에이전트를 강하게 만들지만, 동시에 다른 회사의 지시문과 네트워크 경로를 내 작업 흐름에 넣어요. 새 개발 도구나 업데이트를 받아들일 때는 다음을 확인해 보세요. 첫째, 설치 범위가 그 앱 안에 머무는지, 다른 도구의 사용자 전역 설정을 바꾸는지. 둘째, 사용자가 승인해야 하는 단계를 설치기가 대신 처리하지 않는지. 셋째, 데이터가 외부로 가는 경로(클라우드 게시, 원격 MCP, 사용 집계)를 문서로 밝히고 끄는 방법을 주는지. 넷째, 제거 경로가 모든 흔적을 지우고 다음 업데이트에서 재설치하지 않는지예요.

2026년 11월 4일 기준으로 Postman은 옵트인을 분명히 하고 훅 승인 동작을 검토하겠다고 했을 뿐, 자동 설치나 자기 승인 기능을 없앴다는 공식 발표는 확인되지 않았어요. 이후 릴리스 노트와 이슈 스레드의 업데이트를 확인하고, 그 전까지는 위 점검 순서로 설치 여부와 데이터 경로를 직접 확인하는 것이 현실적인 대응이에요.