요약
기업 보안 검토, 규정 준수 의무, 데이터 상주 요구사항으로 인해 Postman 도입이 저해되고 있으며, 이로 인해 Postman에서 다른 솔루션으로의 마이그레이션이 촉발되고 있습니다. 반복되는 패턴은 동일합니다. 클라우드 우선 아키텍처는 데이터를 사내에 유지해야 하는 정책과 상충되며, Postman은 자체 호스팅(self-hosted) 옵션을 제공하지 않습니다. Apidog의 자체 호스팅 엔터프라이즈 배포는 이러한 조직들이 선택하는 대안이 되고 있습니다.
서론
Postman은 10년 이상 API 툴링 시장에서 지배적인 위치를 구축했습니다. 그 네트워크 효과는 상당합니다. 3천만 사용자, 광범위한 공개 API 컬렉션, 모든 주요 CI/CD 플랫폼과의 통합, 그리고 단순한 요청 테스트를 넘어 API 설계, 문서화, 모니터링까지 확장된 기능 세트를 갖추고 있습니다.
하지만 지난 몇 년 동안 기업 계정에서 역추세가 나타났습니다. 보안 및 규정 준수 팀은 개발자 툴링을 새로운 시각으로 면밀히 검토하고 있으며, Postman의 클라우드 우선 아키텍처는 점점 더 많은 조직에서 이러한 검토를 통과하지 못하고 있습니다.
문제는 구조적입니다. Postman의 제품은 클라우드 협업을 중심으로 구축되었습니다. 작업 공간, 팀, 환경, 컬렉션 동기화는 모두 Postman 서버에 데이터가 상주해야 합니다. 이는 제품이 개별 개발자와 소규모 팀을 대상으로 했을 때는 타당했습니다. 민감한 데이터를 처리하는 기업 계정으로 시장을 확장하면서, 협업을 가능하게 했던 동일한 아키텍처가 규제되고 보안에 민감한 환경에서는 약점이 되었습니다.
원인 1: 보안팀 검토로 인한 도입 저해
Postman 마이그레이션을 유발하는 가장 일반적인 시나리오는 보안 검토입니다. 조직이 소프트웨어 보안 프로그램을 성숙시키면서, 개발자 툴링도 프로덕션 인프라와 동일한 면밀한 검토를 받게 됩니다.
검토 프로세스는 일반적으로 다음과 같습니다. 엔지니어링 팀이 Postman 사용을 확대하거나, 개별 계정에서 공유 엔터프라이즈 계정으로 전환하거나, 개발 툴체인에 공식화하려고 합니다. 보안 팀은 공급업체 평가의 일환으로 도구를 검토합니다. 검토 결과, Postman의 클라우드 동기화는 요청 본문, 환경 변수(자격 증명 포함), 응답 데이터를 Postman의 미국 기반 서버로 전송한다는 사실이 밝혀집니다.
보안 팀은 질문을 던집니다. "우리의 데이터 처리 정책이 내부 엔드포인트 및 자격 증명을 포함하는 API 요청 데이터를 타사 클라우드에 저장하는 것을 허용하는가?" API 자격 증명 및 내부 시스템 정보를 기밀 또는 민감한 정보로 분류하는 데이터 분류 정책을 가진 조직의 경우, 대답은 종종 "아니오"입니다.
이 우려에 대한 Postman의 답변은 SOC 2 Type II 인증 및 엔터프라이즈 보안 문서입니다. 일부 조직에게는 이것으로 충분합니다. 다른 조직의 경우, 이 인증은 근본적인 아키텍처 문제를 해결하지 못합니다. SOC 2 인증을 받은 공급업체조차도 클라우드에서 실행될 때 귀하의 데이터에 접근할 수 있기 때문입니다.
보안 팀의 결론은 자체 호스팅 옵션이 없는 클라우드 우선 SaaS 제품인 Postman은 민감한 내부 시스템과 관련된 작업에 사용될 수 없다는 것입니다. 엔지니어링 팀은 검토를 통과할 대안을 찾아야 합니다.
원인 2: 데이터 상주에 대한 규정 준수 요구사항
규정 준수 요구사항은 특히 엄격한 데이터 상주 규칙이 있는 산업에서 도구 마이그레이션의 중요한 원동력이 되었습니다.
GDPR이 적용되는 유럽 조직. GDPR은 미국 기반 클라우드 서비스에 마찰을 일으킵니다. 표준 계약 조항(SCC)이 EU-미국 데이터 전송을 위한 법적 메커니즘을 제공하지만, 특히 민감한 데이터를 다루는 조직은 데이터를 유럽에 보관하는 도구를 사용하여 그 복잡성을 피하는 것을 선호할 수 있습니다. Postman은 EU 지역 데이터 상주 옵션이나 자체 호스팅 옵션을 제공하지 않으므로, 데이터를 EU 내에 보관할 방법이 없습니다.
FFIEC 및 OCC 지침이 적용되는 금융 서비스. 미국 은행 규제 당국은 데이터 상주 및 타사 위험 관리를 점점 더 강조하고 있습니다. OCC 또는 FDIC 감독을 받는 은행 및 금융 기관은 민감한 시스템 정보(금융 시스템용 API 자격 증명 포함 가능)를 타사 클라우드에 저장해야 하는지 여부를 면밀히 검토하고 있습니다.
CMMC가 적용되는 정부 계약업체. 미국 국방 계약업체를 위한 사이버보안 성숙도 모델 인증(CMMC) 프로그램은 통제되지 않은 미분류 정보(CUI) 처리에 대한 요구사항을 명시합니다. FedRAMP 승인 서비스가 아닌 상용 클라우드 도구에 CUI를 저장하는 것은 CMMC 요구사항을 위반할 수 있습니다. Postman은 FedRAMP 승인을 보유하고 있지 않습니다.
HIPAA가 적용되는 헬스케어. 규정 준수 검토 기사에서 논의된 바와 같이, Postman은 HIPAA에 대한 BAA를 제공하지만, 클라우드 동기화 모델은 여전히 테스트 요청에 포함된 PHI(보호 건강 정보)가 Postman 서버로 전송됨을 의미합니다. 엄격한 HIPAA 프로그램을 가진 조직은 해당 데이터 흐름을 완전히 제거하는 도구를 선호할 수 있습니다.
이러한 규정 준수 맥락 전반의 공통점은 조직이 데이터 흐름을 제어해야 하지만, Postman의 아키텍처는 이를 불가능하게 만든다는 것입니다.
원인 3: 규모에 따른 비용
보안 및 규정 준수만이 유일한 원동력은 아닙니다. 엔지니어링 조직이 확장됨에 따라 순수 비용도 요인으로 작용합니다.
Postman의 엔터프라이즈 가격은 사용자당 월별 요금입니다. 소규모 팀의 경우 비용은 무시할 수 있습니다. 수백 또는 수천 명의 개발자가 있는 엔지니어링 조직의 경우 비용이 상당해집니다. 대규모 비용 분석을 수행하는 조직은 자체 호스팅 대안의 일회성 배포가 다년간에 걸쳐 상당한 비용 절감을 가져올 수 있음을 발견하기도 합니다.
이러한 비용 고려사항은 이미 내부 플랫폼 인프라에 투자하고 있는 조직에게 특히 중요합니다. 기존 Kubernetes 클러스터 또는 내부 서버 팜에 API 도구 배포를 추가하는 것은 반복되는 사용자당 SaaS 비용에 비해 한계 비용이 적습니다.
비용은 거의 단독으로 작용하지 않습니다. 비용 문제로 마이그레이션하는 조직은 일반적으로 보안 또는 규정 준수 문제도 언급합니다. 비용은 공식 검토를 촉발하는 촉매제이며, 이는 이후 보안 및 규정 준수 문제를 표면화시킵니다.
원인 4: CloudSEK의 발견과 그 여파
2023년 CloudSEK이 30,000개 이상의 공개 Postman 작업 공간에서 API 키가 유출되었음을 발견한 것은 기업 보안 팀에 특정 영향을 미쳤습니다. 이는 Postman의 잘못된 설정이 광범위한 자격 증명 노출로 이어지는 구체적인 사례를 제공했습니다.
보안 팀이 이 보고서를 보았을 때, 그들은 자신들의 조직에 명백한 질문을 던졌습니다. "자격 증명이 포함된 공개 작업 공간이 있는가?" 많은 이들이 그렇다는 것을 발견했습니다. 그에 따른 감사 프로세스는 개선으로 이어졌지만, Postman의 기본 아키텍처가 조직의 위험 허용치와 호환되는지에 대한 재평가로도 이어졌습니다.
이 발견은 또한 보안 팀에게 개발자 툴링 위험에 대해 엔지니어링 리더십과 대화할 때 제시할 구체적인 증거를 제공했습니다. "클라우드 동기화된 자격 증명"에 대한 추상적인 우려는 실행하기 어렵습니다. API 키가 노출된 특정 기업을 언급하고 자신의 노출 여부를 확인할 수 있는 메커니즘을 제공하는 보고서는 실행 가능한 정보입니다.
일부 조직에서는 감사 결과 자격 증명이 포함된 공개 작업 공간이 발견되지 않았습니다. 그들은 정책을 강화하고 Postman을 계속 사용했습니다. 다른 조직의 경우, 감사 결과 노출이 발견되었고, 프로덕션 자격 증명이 Postman API 네트워크를 검색하는 누구에게나 접근 가능했다는 사실을 발견한 경험은 마이그레이션하기에 충분한 동기가 되었습니다.
마이그레이션 패턴: 조직이 실제로 하는 일
Postman 클라우드에서 마이그레이션하는 조직은 식별 가능한 패턴을 따릅니다.
1단계: 보안 또는 규정 준수 트리거. 보안 검토, 감사 결과, 규정 준수 요구사항 또는 사고(예: 노출된 작업 공간 발견)는 개발자 툴링에 대한 공식적인 평가를 촉발합니다.
2단계: 요구사항 수집. 보안 팀은 요구사항을 수립합니다. 일반적으로 데이터 상주, 자격 증명의 클라우드 동기화 없음, 자체 호스팅 배포 옵션, 팀 협업 기능, Postman 컬렉션 호환성(마이그레이션용), 그리고 엔터프라이즈 지원이 요구됩니다.
3단계: 평가. 후보 도구들은 요구사항에 따라 평가됩니다. Bruno는 중앙 집중식 협업 기능이 부족하여 대규모 팀의 평가에서 일반적으로 탈락합니다. Hoppscotch 자체 호스팅도 평가되지만, 팀에 DevOps 역량이 부족하거나 Hoppscotch가 다루지 않는 기능이 필요한 경우 우선순위에서 밀릴 수 있습니다. Apidog 자체 호스팅은 자체 호스팅과 함께 전체 기능 세트(설계, 테스트, 문서화, 목킹)가 필요한 팀에게 가장 일반적인 선택입니다.
4단계: 파일럿. 엔지니어링 팀의 일부가 Postman과 병행하여 후보 도구를 30-90일 동안 운영합니다. Postman 컬렉션은 내보내지고 가져와집니다. 워크플로우가 검증됩니다.
5단계: 마이그레이션. 컬렉션이 마이그레이션되고, 깨끗한 자격 증명으로 환경이 재설정되며(마이그레이션은 키를 교체하기에 좋은 시기), Postman 계정은 프로비저닝 해제됩니다.
이러한 조직들이 대신 선택하는 것
대안 환경은 엔터프라이즈 팀이 실행 가능한 옵션을 가질 정도로 성숙했습니다.
Apidog 자체 호스팅. 요청 테스트뿐만 아니라 API 설계, 문서화, 목킹 등 Postman의 모든 플랫폼 기능을 유지하면서 데이터를 자체 인프라 내에 보관해야 하는 조직에게 가장 일반적인 선택입니다.
자체 호스팅 배포는 Docker에서 실행되며, 온프레미스, 프라이빗 클라우드 또는 특정 클라우드 지역에 배포할 수 있습니다. 팀 협업 기능은 클라우드 버전과 동일하게 작동하지만, 동기화는 내부 서버로 이루어집니다. 데이터 상주 위치는 전적으로 귀하의 통제하에 있습니다.
엔터프라이즈 조달을 위해 Apidog은 전담 지원이 포함된 자체 호스팅 라이선스 모델을 제공합니다. 이는 대규모 조직의 공급업체 관리 요구사항에 부합합니다.
엔지니어링 중심 팀을 위한 Bruno. 강력한 DevOps 문화와 Git 중심 워크플로우를 가진 조직은 Bruno의 '파일로서의 컬렉션' 접근 방식이 인프라-as-코드(IaC) 원칙과 일치하기 때문에 Bruno를 선택하기도 합니다. 컬렉션은 동일한 저장소에서 애플리케이션 코드와 함께 존재합니다. 버전 관리는 Git입니다. 유지보수할 서버가 없습니다.
Bruno는 조직의 주요 요구사항이 요청 테스트이고 팀이 더 최소한의 도구 경험에 익숙할 때 가장 잘 작동합니다.
Hoppscotch 자체 호스팅. 오픈 소스이며 자체 배포 가능하고 브라우저 기반입니다. 데스크톱 앱 설치 없이 팀 구성원에게 웹 UI를 제공하려는 조직에 적합합니다. Apidog의 자체 호스팅 옵션보다 더 많은 운영 투자가 필요합니다.
성공적인 마이그레이션의 공통점
Postman 클라우드에서 성공적으로 마이그레이션하는 조직은 몇 가지 공통된 관행을 공유합니다.
마이그레이션을 부차적인 일이 아닌 프로젝트로 수행합니다. 컬렉션은 스스로 마이그레이션되지 않습니다. 환경 변수는 깨끗한 자격 증명으로 다시 입력해야 합니다. 스크립팅 API의 차이로 인해 테스트 스크립트 조정이 필요할 수 있습니다. 적절한 프로젝트 시간을 할당하면 더 깔끔한 마이그레이션이 가능합니다.
마이그레이션을 자격 증명을 정리할 기회로 삼습니다. 마이그레이션 프로세스는 환경 변수를 다시 입력해야 합니다. 이는 API 키를 교체하고 개발자 자격 증명의 범위가 올바르게 지정되었는지 확인하기에 자연스러운 시점입니다. 이렇게 하는 조직은 마이그레이션 후에 이전보다 더 깔끔한 자격 증명 상태를 갖게 됩니다.
새로운 도구의 보안 모델에 대해 팀을 교육합니다. 왜 이 도구를 선택했는지, 그리고 데이터 모델이 Postman과 어떻게 다른지 이해하는 것은 엔지니어링 팀이 좋은 결정을 내리는 데 도움이 됩니다. "우리 데이터는 우리 서버와 동기화되므로 사내에 머무른다"는 것을 이해하는 팀은 "우리는 도구를 바꿨다"는 것만 아는 팀보다 보안 허점을 만들 가능성이 적습니다.
새로운 플랫폼에 대한 명확한 정책을 수립합니다. Postman에 필요했던 것과 동일한 거버넌스가 새 도구에도 필요합니다. 누가 무엇에 접근할 수 있는지, 어떤 자격 증명이 어디에 저장되는지, 그리고 작업 공간 접근이 어떻게 관리되는지 등입니다. 정책 개선 없는 마이그레이션은 동일한 위험을 다른 플랫폼으로 옮기는 것에 불과합니다.
Postman이 해결하지 못한 제품 격차
엔터프라이즈 마이그레이션 추세는 궁극적으로 제품 격차에서 비롯됩니다. Postman은 자체 호스팅 옵션을 구축하지 않았습니다.
고객 인프라에서 실행되고 내부적으로 데이터를 동기화하는 자체 호스팅 Postman은 Postman을 지배적으로 만든 모든 기능을 유지하면서 데이터 상주 문제를 해결할 수 있을 것입니다. 수년 동안 여러 기업 고객이 Postman의 피드백 포럼에서 공개적으로 이를 요청했습니다. 제품은 그 방향으로 나아가지 않았습니다.
Postman의 비즈니스 모델은 클라우드 구독에 의존합니다. 자체 호스팅 옵션은 해당 수익의 일부를 일회성 또는 연간 라이선스 비용으로 전환하고, Postman이 우선순위를 두지 않은 배포 인프라를 구축하고 유지보수해야 할 것입니다.
이러한 격차는 Apidog 및 다른 대안들에게 큰 기회를 만들었습니다. "Postman 기능, 자체 호스팅 배포"에 대한 수요는 실제 존재하지만, Postman 자체적으로는 충족되지 않고 있습니다.
자주 묻는 질문
Postman이 이로 인해 실제로 기업 고객을 잃고 있습니까? 보안 검토에 의해 주도되는 마이그레이션 패턴은 실제하며 개발자 포럼 및 커뮤니티 토론에서 문서화되어 있습니다. 성숙한 보안 프로그램을 가진 대규모 조직은 Postman의 아키텍처 한계에 부딪힐 가능성이 가장 높습니다. Postman이 이로 인해 순 고객을 잃고 있는지는 이 분석의 범위를 벗어나는 비즈니스 문제입니다.
Postman 동기화를 비활성화하고 로컬로 사용할 수 없습니까? Postman은 2023년경 Scratch Pad를 제거했으며, 이는 완전한 로컬 작동을 위한 유일한 경로였습니다. 현재 버전은 로그인된 계정을 요구하며 기본적으로 데이터를 동기화합니다. 전체 데이터 제어가 필요한 기업에게 Postman 내의 부분적인 완화 조치는 충분하지 않습니다.
Apidog 자체 호스팅 배포는 운영상 어떤 모습입니까? Docker Compose 또는 Kubernetes에서 실행됩니다. PostgreSQL 데이터베이스와 TLS 종료를 위한 리버스 프록시가 필요합니다. 운영 부하는 중간 복잡성 웹 애플리케이션을 실행하는 것과 유사합니다. 내부 플랫폼 엔지니어가 있는 팀은 이를 처리할 수 있습니다.
마이그레이션 중 기존 Postman 컬렉션은 어떻게 됩니까? Postman 컬렉션은 JSON 형식으로 내보내집니다. Apidog, Bruno, Hoppscotch, Insomnia는 모두 Postman 컬렉션 형식을 가져올 수 있습니다. 컬렉션 가져오기는 일반적으로 깔끔합니다. 환경 변수는 수동으로 다시 입력해야 합니다(이는 자격 증명 위생을 위한 좋은 관행입니다).
Apidog 자체 호스팅은 SSO 및 엔터프라이즈 인증을 지원합니까? Apidog의 엔터프라이즈 자체 호스팅 제품은 SAML 및 OIDC를 통한 SSO 통합을 지원합니다. 이는 대부분의 엔터프라이즈 배포에 필수적인 요구사항이며, 엔터프라이즈 요금제에서 사용할 수 있습니다.
일반적인 Postman 마이그레이션은 얼마나 걸립니까? 100-200개의 Postman 컬렉션을 가진 50명 규모의 엔지니어링 팀의 경우, 마이그레이션은 파일럿 기간 및 교육을 포함하여 결정부터 완전 전환까지 일반적으로 4-8주가 소요됩니다. 컬렉션이 더 많은 대규모 팀은 더 오래 걸립니다.
Postman 클라우드에서 벗어나는 기업들은 Postman이 나쁜 제품이라서 그렇게 하는 것이 아닙니다. 그들의 요구사항이 성숙함에 따라 제품의 아키텍처가 더 이상 그들의 요구사항에 맞지 않기 때문에 그렇게 하는 것입니다. Postman 대안으로 성공하는 조직은 단순히 도구를 교체하는 것이 아니라 명확한 요구사항을 가진 프로젝트로 마이그레이션을 다루는 조직입니다.