Apidog에서 SOAP 및 WSDL 웹 서비스 테스트 방법

SOAP 엔드포인트를 테스트해야 할 때가 있습니다. 예를 들어 청구 시스템의 레거시 환율 변환기나 .NET 기반 파트너 주문 관리 서비스가 그렇습니다. 이 경우 호출이 계약대로 동작하는지 확인하고, 주변 코드가 변경된 뒤에도 동일한 결과를 반환하는지 반복 검증해야 합니다. SOAP는 전체 XML 엔벨로프, 특정 Content-Type, WSDL 기반 계약을 사용하므로 일반적인 REST 요청 도구만으로는 다루기 불편할 수 있습니다.

지금 Apidog을 사용해 보세요

Apidog은 REST, GraphQL, gRPC와 함께 SOAP 및 웹 서비스 요청을 처리합니다. 따라서 레거시 SOAP 서비스만을 위해 별도 도구를 운영할 필요가 없습니다.

이 글에서는 다음 두 가지 방법을 다룹니다.

1. SOAP 요청을 직접 구성해 수동으로 전송하기
2. WSDL 파일을 가져와 엔드포인트와 환경을 생성하기

프로토콜 차이를 먼저 확인하려면 REST, GraphQL, gRPC, SOAP 비교를 참고하세요. SOAP 엔벨로프의 공식 정의는 W3C SOAP 사양에서 확인할 수 있습니다.

SOAP란 무엇이며 왜 별도 설정이 필요한가

SOAP(Simple Object Access Protocol)는 서로 다른 플랫폼과 언어가 XML 메시지를 통해 통신할 수 있도록 설계된 프로토콜입니다. 예를 들어 Java 클라이언트와 .NET 서비스는 내부 구현이 달라도 동일한 WSDL 계약을 기준으로 통신할 수 있습니다.

SOAP 테스트에서 확인해야 할 핵심은 세 가지입니다.

• 메시지 형식: 요청과 응답은 JSON이 아닌 구조화된 XML 문서입니다.
• 전송 방식: 일반적으로 HTTP 또는 HTTPS를 사용합니다.
• 계약 검증: WSDL과 XML 스키마를 기반으로 메시지 구조가 엄격하게 검증됩니다.

XML 문법이 익숙하지 않다면 MDN XML 문서를 먼저 확인하세요.

SOAP는 플랫폼 간 통합, 레거시 시스템 연결, WS-Security 기반 보안 메시징에서 여전히 사용됩니다. 따라서 REST 방식처럼 URL과 JSON 본문만 보내는 것으로는 충분하지 않습니다. 올바른 헤더, SOAP 엔벨로프, XML 응답 검증이 필요합니다.

SOAP 엔벨로프와 XML 구조는 SOAP API와 XML 가이드에서 더 자세히 볼 수 있습니다.

시작하기 전 체크리스트

SOAP 또는 웹 서비스 요청을 보내려면 Apidog 2.1.31 이상이 필요합니다. 이전 버전에서는 해당 기능을 지원하지 않습니다.

시작 전에 다음을 준비하세요.

• Apidog 2.1.31 이상
• SOAP 엔드포인트 URL
• 호출할 작업(operation) 이름
• 작업에 필요한 매개변수
• 가능하다면 .wsdl 또는 .xml 형식의 WSDL 파일

WSDL 파일은 모든 작업, 입력 구조, 서비스 주소를 정의합니다. WSDL 형식 자체는 W3C WSDL 2.0 문서에서 확인할 수 있습니다.

경로 A: SOAP 요청을 수동으로 보내기

엔드포인트 URL과 호출할 작업 이름을 이미 알고 있다면 요청을 직접 구성할 수 있습니다.

1단계: Content-Type 헤더 설정

SOAP 요청에서는 Content-Type을 명시적으로 설정해야 합니다.

Content-Type: text/xml; charset=utf-8

또는:

Content-Type: application/soap+xml

일반적으로 다음 기준을 사용합니다.

SOAP 버전	일반적인 Content-Type
SOAP 1.1	text/xml; charset=utf-8
SOAP 1.2	application/soap+xml

정확한 값은 WSDL 또는 서비스 문서를 기준으로 결정하세요. Content-Type 관련 오류가 발생하면 SOAP 버전과 헤더 값을 다시 확인합니다.

2단계: 본문 형식을 XML로 설정하고 SOAP 엔벨로프 입력

Apidog에서 요청 본문 형식을 xml로 선택한 뒤 SOAP 엔벨로프를 입력합니다.

다음 예시는 공개 숫자-단어 변환 서비스의 NumberToWords 작업을 호출합니다. ubiNum 값으로 1234를 전달합니다.

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:web="http://www.dataaccess.com/webservicesserver/">
  <soap:Body>
    <web:NumberToWords>
      <web:ubiNum>1234</web:ubiNum>
    </web:NumberToWords>
  </soap:Body>
</soap:Envelope>

구조를 분해하면 다음과 같습니다.

• soap:Envelope: 전체 SOAP 메시지 컨테이너
• soap:Body: 실제 요청 데이터 영역
• web:NumberToWords: 호출할 작업 이름
• web:ubiNum: 작업에 전달할 입력값

중요한 점은 네임스페이스입니다. xmlns:web 값과 작업 요소 이름은 서비스가 기대하는 정의와 정확히 일치해야 합니다. 임의로 추측하지 말고 WSDL의 targetNamespace, operation 정의, 메시지 구조를 확인하세요.

3단계: 요청 전송 및 XML 응답 검증

요청을 전송하면 서버는 일반적으로 SOAP 엔벨로프 형식의 XML 응답을 반환합니다.

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <m:NumberToWordsResponse xmlns:m="http://www.dataaccess.com/webservicesserver/">
      <m:NumberToWordsResult>one thousand two hundred and thirty four</m:NumberToWordsResult>
    </m:NumberToWordsResponse>
  </soap:Body>
</soap:Envelope>

최소한 다음을 검증하세요.

1. SOAP 엔벨로프가 반환되었는지
2. 예상한 응답 노드가 존재하는지
3. 결과 값이 계약 및 테스트 기대값과 일치하는지

이 예시에서는 다음 요소를 확인합니다.

NumberToWordsResponse

NumberToWordsResult

더 많은 SOAP 엔벨로프 예시와 구성은 webservice.apidog.io에서 확인할 수 있습니다.

실무 적용 예시

환율 서비스라면 작업만 바꾸면 됩니다.

<web:ConvertCurrency>
  <web:fromCurrency>USD</web:fromCurrency>
  <web:toCurrency>KRW</web:toCurrency>
  <web:amount>100</web:amount>
</web:ConvertCurrency>

주문 상태 서비스라면 다음과 같은 구조가 될 수 있습니다.

<web:GetOrderStatus>
  <web:orderId>ORD-10001</web:orderId>
</web:GetOrderStatus>

패턴은 동일합니다.

1. 올바른 Content-Type 설정
2. XML SOAP 엔벨로프 작성
3. 요청 전송
4. 응답 Body의 결과 노드 검증

경로 B: WSDL 가져오기로 엔드포인트 생성하기

서비스가 여러 작업을 제공한다면 엔벨로프를 하나씩 작성하지 않는 편이 좋습니다. WSDL을 가져오면 Apidog이 작업, 입력 구조, 서비스 주소를 읽어 엔드포인트를 생성합니다.

WSDL 가져오기 절차

1. 설정으로 이동합니다.
2. 데이터 가져오기를 선택합니다.
3. WSDL을 선택합니다.
4. .wsdl 또는 .xml 파일을 업로드합니다.
5. 파싱된 API 엔드포인트 미리보기를 검토합니다.
6. 환경 탭에서 서비스 주소를 확인합니다.
7. 확인을 클릭해 가져오기를 완료합니다.
8. 오른쪽 상단에서 생성된 환경을 선택합니다.
9. 요청을 전송합니다.

반드시 확인할 두 가지

1. 가져오기 전 서비스 주소 확인

WSDL 내부 서비스 주소가 오래된 스테이징 서버나 플레이스홀더 URL일 수 있습니다. 이 경우 생성된 모든 요청이 잘못된 서버로 전송됩니다.

확인을 누르기 전에 환경 탭에서 다음을 확인하세요.

• 프로토콜이 올바른지 (http 또는 https)
• 호스트가 올바른지
• 포트가 올바른지
• 운영/스테이징 환경이 의도한 대상인지

2. 요청 전 환경 선택

가져오기 과정에서 기본 URL을 포함한 환경이 생성됩니다. 오른쪽 상단에서 이 환경을 선택하지 않으면 요청에 기본 주소가 적용되지 않아 실패할 수 있습니다.

WSDL 가져오기가 끝나면 각 SOAP 작업을 개별 엔드포인트처럼 호출할 수 있습니다. 응답 검증 방식은 수동 요청과 동일합니다.

다른 도구에서 프로젝트를 이전하는 경우 SOAP 프로젝트 가져오기 가이드를 참고하세요.

WSDL 가져오기는 문서상 .wsdl 및 .xml 파일 업로드를 지원합니다. URL에서 WSDL을 직접 가져오거나 내용을 붙여넣는 방식은 문서화되어 있지 않으므로, 파일 업로드 방식을 사용하세요.

SoapUI에서 전환하기

기존 SOAP 테스트가 SoapUI에 있다면 처음부터 다시 만들 필요는 없습니다.

1. 기존 WSDL 파일을 내보내거나 확보합니다.
2. Apidog에서 WSDL을 가져옵니다.
3. 생성된 환경의 서비스 주소를 확인합니다.
4. 필요한 요청별 검증과 테스트 시나리오를 추가합니다.

이 방식으로 SOAP 서비스, REST 엔드포인트, 테스트 시나리오를 하나의 프로젝트에서 관리할 수 있습니다. 차이점과 마이그레이션 관점은 Apidog 대 SoapUI 비교에서 확인할 수 있습니다.

어설션과 테스트 시나리오 구성

성공 응답 한 번은 서비스가 살아 있음을 보여줄 뿐입니다. 계약을 계속 준수하는지 확인하려면 응답 값에 대한 어설션이 필요합니다.

SOAP 응답에서 다음을 검증하세요.

• 예상한 응답 작업 노드가 존재하는지
• 결과 요소를 올바르게 추출했는지
• 결과 값이 기대값과 일치하는지
• 오류 응답이라면 SOAP Fault가 포함되었는지

예를 들어 환율 서비스에서는 변환된 금액이 유효한 숫자 범위인지 검증할 수 있습니다. 주문 상태 서비스에서는 반환된 상태가 허용 목록에 있는지 검증할 수 있습니다.

PENDING
PROCESSING
SHIPPED
DELIVERED
CANCELLED

또한 여러 호출을 하나의 시나리오로 연결할 수 있습니다.

주문 생성 → 주문 ID 추출 → 주문 상태 조회 → 상태 검증

이 과정에서 이전 응답에서 추출한 값을 다음 요청의 입력값으로 전달합니다. 구현 방식은 Apidog으로 테스트 시나리오 작성하기 가이드를 참고하세요.

SOAP와 REST 요청을 같은 시나리오에 섞을 수도 있습니다. 예를 들어 REST API로 테스트 데이터를 만들고, SOAP 작업으로 주문 상태를 검증하는 흐름을 구성할 수 있습니다.

WS-Security 헤더가 필요한 경우

보안 SOAP 서비스는 종종 WS-Security를 사용합니다. 이 경우 보안 정보는 SOAP 엔벨로프의 Header에 포함됩니다.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
  <soap:Header>
    <wsse:Security>
      <!-- 서비스 요구사항에 맞는 보안 블록 -->
    </wsse:Security>
  </soap:Header>
  <soap:Body>
    <!-- 작업 요청 -->
  </soap:Body>
</soap:Envelope>

전송 방식은 동일합니다.

1. Content-Type 설정
2. 보안 헤더를 포함한 전체 XML 엔벨로프 작성
3. 요청 전송
4. 응답 또는 SOAP Fault 검증

Apidog CLI로 워크플로 자동화하기

SOAP 또는 WSDL 기반 요청을 테스트 시나리오로 저장한 경우, Apidog CLI를 통해 명령줄에서 시나리오를 실행할 수 있습니다.

Node.js v16 이상 환경에서 설치하고 인증합니다.

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

저장된 테스트 시나리오는 시나리오 ID와 환경 ID로 실행합니다.

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

주요 옵션은 다음과 같습니다.

옵션	설명
-t	테스트 시나리오 ID
-e	환경 ID
-r	리포터 형식

여러 리포터가 필요하면 쉼표로 구분합니다.

apidog run \
  --access-token $APIDOG_ACCESS_TOKEN \
  -t <scenario_id> \
  -e <env_id> \
  -r cli,html,junit

문서에서는 저장된 테스트 시나리오와 스위트 실행을 설명하지만, SOAP 단계로 구성된 모든 시나리오가 헤드리스 환경에서 실행되는지는 명시되어 있지 않습니다. 따라서 CI 적용 전에는 실제 프로젝트 시나리오로 실행 여부를 검증하세요.

파이프라인 연동 방법은 Apidog CLI CI/CD 가이드에서 확인할 수 있습니다.

자주 묻는 질문

SOAP 요청에는 어떤 Content-Type을 사용해야 하나요?

다음 중 하나를 사용합니다.

text/xml; charset=utf-8

application/soap+xml

일반적으로 SOAP 1.1은 text/xml; charset=utf-8, SOAP 1.2는 application/soap+xml을 사용합니다. WSDL이나 서비스 문서를 우선 확인하세요.

SOAP 테스트에 유료 플랜이 필요한가요?

문서상 SOAP 또는 WSDL 요청을 사용하기 위한 필수 조건은 Apidog 버전 2.1.31 이상입니다. SOAP/WSDL 지원에 대한 별도 플랜 또는 자체 호스팅 제한은 명시되어 있지 않습니다.

URL에서 WSDL을 직접 가져올 수 있나요?

문서화된 방식은 .wsdl 또는 .xml 파일 업로드입니다. URL 가져오기나 WSDL 텍스트 붙여넣기는 문서화되어 있지 않으므로 파일을 업로드하세요.

SOAP와 REST API를 같은 프로젝트에서 테스트할 수 있나요?

가능합니다. Apidog 프로젝트에서 SOAP 작업과 REST 엔드포인트를 함께 관리하고, 하나의 테스트 시나리오에서 순차적으로 실행할 수 있습니다. GraphQL도 함께 테스트해야 한다면 Apidog에서 GraphQL API 테스트하기를 참고하세요.

WSDL로 가져온 요청이 잘못된 서버로 전송됩니다. 왜 그런가요?

주로 다음 중 하나입니다.

1. WSDL에 포함된 서비스 주소가 오래되었거나 잘못되었습니다.
2. 가져오기 전에 환경 탭의 주소를 확인하지 않았습니다.
3. 요청 전 오른쪽 상단에서 생성된 환경을 선택하지 않았습니다.

서비스 주소를 다시 확인하고, 요청을 보내기 전에 올바른 환경을 활성화하세요.

마무리

SOAP 테스트는 반드시 별도 레거시 도구를 사용해야 하는 작업이 아닙니다. Apidog에서는 다음 두 가지 방식으로 SOAP 서비스를 검증할 수 있습니다.

• Content-Type, XML 본문, SOAP 엔벨로프를 직접 구성해 수동 호출하기
• WSDL을 가져와 엔드포인트와 환경을 자동 생성하기

어떤 방식을 선택하든 핵심은 같습니다. SOAP 서비스가 WSDL 계약과 기대 응답을 계속 준수하는지 반복적으로 확인하는 것입니다.

Apidog 다운로드 후 WSDL을 가져와 레거시 SOAP 서비스도 REST API와 동일한 테스트 워크플로에서 관리해 보세요.