개념
왜 Postman 하나로 끝나지 않는가
레슨 2에서 Postman으로 API 테스트를 시작했다. Postman은 오늘날 가장 널리 쓰이는 API 형식인 REST(모듈 9에서 배운 GET/POST 등 HTTP 메서드와 JSON)에 최적화되어 있다. 하지만 은행, 보험, 공공기관처럼 오래전에 시스템을 구축한 조직은 여전히 SOAP라는 다른 방식의 API를 쓰는 경우가 많다. SoapUI는 이 SOAP API를 다루기 위해 만들어진 도구다.
REST와 SOAP — 무엇이 다른가
| REST (Postman이 주로 다루는 것) | SOAP (SoapUI가 주로 다루는 것) | |
|---|---|---|
| 데이터 형식 | 주로 JSON | 항상 XML |
| 요청 구조 | 자유로운 형식, URL에 자원을 표현 | 정해진 봉투(Envelope) 구조 필수 |
| 명세 방식 | OpenAPI(레슨 4) | WSDL(Web Services Description Language) |
| 주로 쓰이는 곳 | 최신 웹·모바일 서비스 | 금융·공공기관의 오래된 기간계 시스템 |
<!-- SOAP 요청의 전형적인 구조 -->
<soap:Envelope>
<soap:Header>...</soap:Header>
<soap:Body>
<GetAccountBalance>
<accountId>12345</accountId>
</GetAccountBalance>
</soap:Body>
</soap:Envelope>레슨 4에서 배운 OpenAPI가 REST API의 명세 방식이었다면, WSDL은 SOAP API의 명세 방식이다. SoapUI는 WSDL 파일을 가져오면 그 안에 정의된 모든 요청을 자동으로 화면에 만들어준다 — Postman이 사람이 직접 요청을 하나씩 만드는 것과 다른 지점이다.
SoapUI의 핵심 기능
- WSDL 임포트 — WSDL 주소만 입력하면 그 API가 제공하는 모든 기능(오퍼레이션)이 자동으로 트리 구조로 나타난다
- 어서션(Assertion) — 레슨 2의
pm.test와 같은 역할을 하지만, SoapUI는 GUI에서 어서션 종류를 선택하는 방식이다("응답 시간이 N초 이내", "XPath로 이 값이 저 값과 같은지" 등) - 속성 전이(Property Transfer) — 한 요청의 응답값을 다음 요청의 입력으로 자동 연결한다. 레슨 2의 컬렉션에서 변수를 넘기던 것과 같은 개념을 SOAP 환경에서 지원한다
- REST도 함께 지원 — SoapUI는 이름과 달리 최신 버전에서 REST API도 다룰 수 있다. 다만 REST 전용 도구(Postman)만큼 가볍고 빠르지는 않다
왜 아직도 SOAP인가
"이미 낡은 기술 아닌가?"라고 생각하기 쉽지만, 은행 코어뱅킹 시스템이나 정부 행정 시스템처럼 한 번 구축하면 수십 년을 바꾸지 않는 시스템에서는 SOAP가 여전히 현역이다. 이런 시스템은 엄격한 계약(WSDL)과 표준화된 보안 규격(WS-Security)이 요구되는 경우가 많아, 오히려 REST보다 SOAP가 적합하다고 판단되는 경우도 있다. QA로서 "왜 이 회사는 아직도 SOAP를 쓸까"를 이상하게 여기기 보다, 그 산업의 안정성·규제 요구가 그런 선택을 하게 만들었다는 맥락을 이해하는 게 실무에 더 도움이 된다.
실무에서 왜 필요한가
REST/JSON 기반의 최신 스타트업에서만 경력을 쌓은 QA가 금융권이나 공공기관 프로젝트에 투입되면, 처음 보는 XML 구조와 WSDL 앞에서 당황하는 경우가 실제로 흔하다. SOAP와 SoapUI의 기본 개념을 미리 알아두면, 그런 환경으로 옮겨도 "REST와 근본적으로 뭐가 다른가"를 빠르게 파악하고 적응할 수 있다. 채용공고에 "SOAP/XML 기반 API 테스트 경험"이 명시된 경우, 대개 이런 안정성이 중요한 레거시 산업의 프로젝트임을 짐작할 수 있다.