> 이 글은 GitHub 이슈 본문을 직접 읽지 못한 상태에서 이슈 제목과 공개된 과거 사례를 바탕으로 썼어요. 제목의 내용은 확인된 사실이 아니라 이슈 작성자의 주장으로 읽어주세요. 재현 방법과 Postman 측 답변은 원문(https://github.com/postmanlabs/postman-app-support/issues/14370)에서 꼭 확인해 주세요.
무슨 일이 있었나요
Postman의 공개 이슈 트래커에 #14370 이슈가 올라왔어요. 제목은 'Postman이 AI 플러그인을 조용히 자동 설치하고 모든 API 데이터를 공유하려 시도한다'는 내용이에요. 사용자 동의 없이 앱이 스스로 AI 기능을 붙이고, 그 기능이 API 데이터에 손을 뻗는다는 주장인 거죠.
이 주장이 어디까지 사실인지는 이 글에서 단정할 수 없어요. 다만 가볍게 넘기면 안 되는 이유는 분명해요. API 클라이언트는 개발자 PC에서 가장 민감한 것들이 모이는 장소거든요.
API 클라이언트가 왜 위험 지대일까요
Postman을 하루만 써도 그 안에 뭐가 쌓이는지 떠올려보세요. 운영 서버 주소, 인증 토큰, API 키, 사내 전용 엔드포인트 목록, 그리고 응답 본문에 찍혀 나온 실제 고객 데이터까지 들어 있어요. 집 열쇠와 금고 비밀번호와 건물 도면을 한 서랍에 넣어둔 셈이에요.
여기서 플러그인이라는 말이 중요해요. 플러그인은 앱에 덧붙는 기능인데요, 앱이 가진 권한을 그대로 빌려 쓰는 경우가 많거든요. 그러니 자동 설치가 정말 일어났다면 문제의 핵심은 기능 추가가 아니라 동의 없는 권한 확장이에요. 게다가 AI 기능은 구조상 입력을 외부 모델 서버로 보내 처리하는 경우가 많아요. 어떤 데이터가, 어디로, 언제 나가는지를 사용자가 고를 수 있느냐가 가장 먼저 따져볼 지점이에요.
이 논쟁은 AI 코딩 도구 쪽의 고민과도 닿아 있어요. 에이전트가 도구를 붙이고 컨텍스트를 모으는 일이 자연스러워질수록, 개발 도구가 기본값으로 무엇을 켜두는지가 곧 보안 문제가 되고 있거든요.
처음 나온 논쟁은 아니에요
Postman을 둘러싼 신뢰 문제에는 배경이 있어요. 2023년 Postman은 로컬 작업 공간인 Scratch Pad를 종료하면서 사용자를 계정과 클라우드 동기화 쪽으로 이끌었고, 이때 반발이 꽤 컸어요. 같은 해 경쟁 제품 Insomnia도 로그인 강제와 클라우드 전환 문제로 비슷한 홍역을 치렀고요.
2024년 말에는 보안 업체 CloudSEK가 공개 상태인 Postman 워크스페이스 약 3만 개에서 토큰과 키가 노출됐다고 보고했어요. Postman의 버그라기보다 사용자 설정 실수에 가까운 사례였지만, API 도구가 클라우드와 얽힐 때 어떤 사고가 나는지 잘 보여줬죠.
이런 흐름에서 떠오른 대안이 Bruno예요. 컬렉션을 일반 파일로 저장해서 Git으로 관리하는 오프라인 우선 도구거든요. Hoppscotch는 오픈소스라 직접 서버를 띄워 쓸 수 있고요. 터미널이 편하다면 HTTPie나 curl, 에디터 안에서 끝내고 싶다면 VS Code의 REST Client 확장도 있어요. 협업 기능은 여전히 Postman이 풍부한 편이라, 결국 편의성과 통제권 사이의 선택이에요.
한국 개발자가 오늘 해볼 일
Postman을 당장 지울 필요는 없어요. 대신 아래 순서로 점검해보세요.
1. 원문 스레드부터 읽기. 재현 조건과 영향받는 버전, Postman 측 답변을 확인하세요. 이 글보다 그쪽이 훨씬 정확해요.
2. 실제 트래픽 보기. macOS라면 Little Snitch나 LuLu로 앱의 외부 연결을 확인하고, mitmproxy 같은 프록시로 무엇이 나가는지 살펴볼 수 있어요. 남의 말보다 내 PC의 트래픽이 가장 확실한 증거예요.
3. 비밀 값 분리하기. Postman 변수에는 팀과 동기화되는 값과 내 PC에만 남는 로컬 값이 구분돼 있어요(버전에 따라 이름은 다를 수 있어요). 토큰은 로컬 값이나 Postman Vault 쪽에 두세요.
4. 운영 자격 증명 넣지 않기. 스테이징 전용으로 권한이 좁고 수명이 짧은 토큰을 쓰고, 의심되면 바로 교체하세요.
5. 회사 정책과 맞춰보기. 응답에 고객 개인정보가 들어 있다면 외부 전송이 개인정보보호법의 국외 이전 문제로 번질 수 있어요. 금융권처럼 망분리 규제가 있는 곳은 허용 도구 목록부터 다시 보는 게 좋아요.
팀 리더라면 이번 기회에 '개발 도구에 어떤 데이터까지 넣어도 되는가'를 문서로 남겨두길 추천해요. 사고가 나고 나서 정하면 늦거든요.
마무리
주장의 사실 여부와 별개로, API 클라이언트는 '편한 앱'이 아니라 '비밀이 모이는 곳'으로 다뤄야 해요. 여러분 팀은 API 테스트 도구에 운영 토큰을 넣어도 된다고 보시나요? Postman을 계속 쓰시나요, 아니면 Bruno 같은 로컬 도구로 옮기셨나요?
🔗 출처: Hacker News