Postman이 AI 플러그인 몰래 설치하고 API 데이터를 공유하는 게 사실인가?

동의 없이 AI 플러그인을 자동 설치하고 전체 API 데이터 공유를 시도한 사실이 GitHub 이슈로 확인됐다. Postman 공식 저장소에 올라온 이슈가 Hacker News에 공유되면서 알려진 것인데, 단순히 기능이 추가된 게 아니라 사용자가 모르는 사이에 플러그인이 설치되고 그 플러그인이 API 작업 데이터를 외부로 넘기려 했다는 게 문제의 핵심이다. 혼자 운영하는 작은 서비스에서 Postman을 쓴다면, 개발 환경에 올려둔 내부 엔드포인트, 인증 토큰, 요청·응답 본문이 그대로 외부에 노출될 수 있다는 뜻이기도 하다.

Postman이 자동으로 설치한 것은 어떤 종류의 플러그인인가

이슈 제목에 등장하는 "AI plugins"는 Postman이 최근 밀어붙이는 AI 보조 기능 계열로 보인다. Postman은 한동안 API 테스트·문서화 도구에 AI를 붙이는 방향으로 제품을 확장해왔고, 이 과정에서 플러그인 형태로 기능을 주입하는 구조를 택한 것으로 보인다. 중요한 건 플러그인의 종류보다 설치 방식이다. 사용자가 선택한 적 없고, 알림도 없었으며, 플러그인이 무슨 권한을 갖고 무슨 데이터를 다루는지 사전 고지도 없었다는 게 이슈의 핵심 불만이다. 어떤 플러그인인지 세부 명칭이나 버전은 직접 돌려봐야 안다.

어떤 범위의 API 데이터를 외부로 공유하려 했나

이슈 제목은 "all API data"라고 표현한다. 이걸 그대로 읽으면 Postman이 다루는 API 작업 전체, 즉 요청 URL, 헤더, 바디, 인증 토큰, 환경 변수, 응답 데이터까지 포함할 수 있다는 뜻이다. 혼자 굴리는 환경에서 Postman을 쓰는 방식을 떠올려보면 이게 왜 심각한지 바로 보인다. 개발 서버 엔드포인트, 스테이징 토큰, 써드파티 API 키, 내부 데이터베이스 응답 본문이 Postman 컬렉션과 환경 파일 안에 다 들어있기 마련이다. 이 데이터가 "전체" 범위로 AI 처리 목적으로 외부 서버에 올라간다면, 소규모 서비스라도 고객 정보나 내부 로직이 노출될 수 있다. 실제로 어떤 필드까지 전송 대상이었는지 세부 범위는 직접 돌려봐야 안다.

개발 도구 체인 한 곳이 뚫리면 연쇄적으로 어디까지 번지는지 감이 잘 안 올 수 있는데, 내 개발 도구 두 곳에 구멍이 생겼다를 보면 비슷한 흐름이 어떤 방식으로 실제 서비스에 영향을 주는지 참고가 된다.

이 문제를 어디서 공개적으로 확인할 수 있나

Postman 공식 GitHub 저장소 postmanlabs/postman-app-support의 이슈 트래커에 올라온 보고가 출발점이다. 이 이슈가 Hacker News에 공유되면서 더 많은 사람이 알게 됐다. 이슈 트래커는 공개 저장소라 누구나 읽을 수 있고, 거기서 재현 과정, 로그, 커뮤니티 반응을 직접 확인할 수 있다. 개발 도구 신뢰 문제는 이런 방식으로, 즉 공식 채널의 공개 이슈를 통해 드러날 때 가장 무게가 실린다. Postman이 직접 반박하거나 수정 버전을 내놓기 전까지는 이슈에 기록된 내용이 현재 확인 가능한 가장 구체적인 근거다.

사용자 알림이나 동의 없이 설치가 이루어진 것이 맞나

이슈가 "silently auto-installs"라는 표현을 쓰는 것 자체가 답이다. "silently"는 알림 없이, "auto-installs"는 자동 설치를 뜻한다. 사용자가 Postman을 쓰는 동안 플러그인이 먼저 설치되고, 그 플러그인이 데이터를 공유하려 했다는 순서다. 소프트웨어가 플러그인을 자동 설치하는 건 그 자체로 문제가 될 수 있는데, 거기에 데이터 외부 전송 시도까지 겹치면 개인정보 보호나 보안 계약 측면에서 훨씬 민감한 사안이 된다. SaaS 도구에서 무언가가 "조용히" 일어났다는 보고는 거의 항상 의도적인 UX 선택이거나 심각한 버그 중 하나다. 어느 쪽이든 사용자 입장에서는 받아들이기 어렵다. 특히 작은 서비스를 혼자 돌릴 때는 보안 사고 대응 여력 자체가 없기 때문에, 사전 동의 없는 행동은 도구 신뢰를 한 번에 무너뜨린다.

데이터를 실제로 전송한 것인가 아니면 시도에 그쳤나

이슈 제목은 "attempts to share"라고 표현한다. "attempts"이기 때문에 전송이 완료됐다는 단정은 현재 재료만으로는 할 수 없다. 시도에 그쳤을 수도 있고, 특정 조건에서만 실제 전송이 이뤄졌을 수도 있다. 이 차이는 실제로 중요하다. 시도조차 없었던 것처럼 보일 수 있는 환경도 있고, 특정 설정이나 버전에서만 발생하는 문제일 수 있기 때문이다. 어느 조건에서 실제 전송까지 갔는지, 어느 조건에서는 막혔는지는 직접 돌려봐야 안다. 현재 Postman을 쓰고 있다면 네트워크 트래픽을 직접 모니터링해서 의심스러운 외부 요청이 있는지 확인하는 게 가장 확실하다.

지금 당장 혼자 굴리는 서비스에서 이 상황을 어떻게 다룰지 생각해보면 선택지는 단순하다. 당장 대안 도구로 넘어가거나, 그 전까지는 Postman에 민감한 환경 변수와 프로덕션 토큰을 넣지 않는 것이다. 로컬 전용 환경에서는 네트워크 단에서 외부 전송을 차단하거나, 오픈소스 대안을 테스트해보는 쪽도 있다. 쓰던 컬렉션 파일에 뭐가 들어있는지 훑는 것부터 시작하면 된다. 개발 도구 하나를 바꾸는 건 번거롭지만, 이미 외부로 나간 API 키를 회수하는 것보다는 훨씬 낫다.

참고한 글

• Postman silently auto-installs AI plugins and attempts to share all API data - GitHub Issue