웹 API: SOAP에서 REST로의 전환, SOAP과 REST의 차이

소영·2025년 3월 2일

위클리 페이퍼 코드잇 스프린트

🎯 주제

웹 API의 발전 과정에서 SOAP에서 REST로의 전환이 일어난 이유와 그 장단점에 대해 알아보자.

웹 API

먼저 간단하게 API와 웹 API의 개념을 짚고 넘어가자.

API?

API(Application Programming Interface)

요청과 응답을 사용하여 두 애플리케이션(소프트웨어)이 서로 통신하는 방법이다.
인터페이스이므로 내부 구현을 전부 알 필요 없이, 정해진 방법(메서드, 엔드포인트 등)만 따르면 기능을 사용할 수 있다.

식당에서 음식을 주문할 때를 떠올려보자.

메뉴판(API 문서): 손님(사용자)은 메뉴판을 보고 주문할 수 있는 음식 목록을 확인한다.(가능한 기능)
주문 요청(요청 Request): 손님은 웨이터(API)를 통해 "스테이크 하나 주세요!"라고 주문한다.
주방 처리(내부 구현): 웨이터는 주문을 받아 주방(서버)으로 할 일을 전달하지만, 손님은 주방에서 요리를 어떻게 만드는지 알 필요가 없다.
음식 제공(응답 Response): 요리가 완성되면 웨이터(API)가 손님에게 가져다준다.

이처럼 클라이언트(손님)가 요청(주문)한 대로 내부 동작(요리 과정)은 드러나지 않고, 응답(서빙)이 이루어지는 방식이 API이다.

웹 API?

웹 API는

웹 상에서 HTTP/HTTPS 프로토콜을 통해 네트워크 상에서 기능을 제공하고 소비하는 방식이다.
클라이언트(웹 브라우저, 모바일 앱 등)와 서버 간의 데이터 교환을 가능하게 하는 인터페이스이다.
⚙️ 클라이언트에서 특정 URI(엔드포인트)로 HTTP 요청을 보내고, 서버에서 정해진 로직을 수행한 후 JSON, XML 등의 응답 데이터를 보낸다.

🫧 SOAP(Simple Object Access Protocol)

웹 API가 확산됨에 따라, 정보 교환을 표준화하기 위해 SOAP(Simple Object Access Protocol)라는 프로토콜 사양이 개발되었다.

엄격한 포맷: 정해진 형식이나 표준을 철저하게 따라야 하므로 보안과 신뢰성이 높다.
XML 기반: SOAP은 요청과 응답 데이터의 포맷이 XML 형식으로 고정되어 있다.
- ✅ XML은 플랫폼 독립적이라, 운영 체제나 언어가 달라도 수정 없이 사용할 수 있다.
- SOAP 메시지는 반드시 Envelope(Header + Body) 구조를 따라야 한다.
✅ WSDL (Web Services Description Language) 사용:
- SOAP API가 어떤 요청을 받을 수 있고, 어떤 응답을 반환하는지 XML 기반으로 명확히 정의한다.
- SOAP 클라이언트는 WSDL을 읽고 자동으로 API 호출을 구성할 수 있다.
✅ 다양한 프로토콜 지원:
- SOAP은 HTTP, TCP, SMTP 등 다양한 전송 프로토콜과 함께 작동할 수 있다.
- SOAP은 네트워크 환경에 맞춰 유연하게 프로토콜을 선택 가능하다.
✅ 보안 기능:
- WS-Security(웹 서비스 보안) 지원 → 인증, 암호화, 메시지 무결성 등을 보장한다.
✅ 상태 유지(Stateful 가능):
- 이전 요청과 연결된 데이터를 계속 사용할 수 있다.
- 클라이언트에서 매번 같은 정보(ex 로그인 세션 정보)를 보낼 필요 없으므로 서버 부하를 줄일 수 있다.

SOAP에서 REST로의 전환

그러나 SOAP의 장점에는 단점도 함께 따라온다.

⛔ 유연하지 못함: XML 형식만 따르므로 유연하지 못하고, 구현 및 설정이 복잡하고 무거워질 수 있다.
- JSON 데이터로는 { "name": "Alice" }지만, XML 형식으로는 아래처럼 길게 보내야 한다.
```
<Envelope>
  <Body>
    <User>
      <Name>Alice</Name>
    </User>
  </Body>
</Envelope>
```
⛔ 상태 유지의 단점: 애플리케이션 서버가 각 클라이언트의 상태를 유지해야 하므로 이전 요청을 모두 기억하고 있어 오버헤드가 생긴다.
⛔ 처리 속도: REST 사용 시 보다 더 크고 복잡한 메시지로 전송 및 처리 속도가 느리다.
⛔ 확장의 어려움: 애플리케이션이 요청 간에 상태를 저장해야 하므로 대역폭과 메모리 요구 사항이 증가한다. 결과적으로 애플리케이션 비용이 많이 들고 확장하기가 어려워진다.

XML만 고집하여 오버헤드가 생기고 복잡도가 높아져
무거운 기업 시스템 같은 레거시가 아닌 가벼운 웹 서비스에서는 더 가볍고 빠른 API 방식이 요구된다.

이에 따라 과거에는 SOAP이 많이 사용되었지만, 점차 REST API를 쓰는 게 표준이 되었다.

SOAP vs REST

SOAP과 REST는 둘 다 애플리케이션 간의 데이터 요청, 응답 방식에 대한 규약이라는 점에서 유사하다.

그러나 데이터 지원 형식과 유연, 확장성의 부분에서 차이가 있다.

✅ 유연하고 다양한 데이터 형식 지원
- SOAP은 반드시 XML을 사용하여 데이터가 크고, 처리 속도가 느리다.
- REST는 JSON, XML, Plain Text 등 유연한 데이터 포맷 사용이 가능하다. 기본 형태인 JSON은 매우 간결하고 가벼워 처리 속도가 빠르고 성능이 좋다.
✅ 유지보수성
- SOAP은 서비스 설명서 WSDL을 필수로 작성해야 하고, WSDL를 기반으로 API 요청을 구성해야 해서 개발 과정이 복잡하다.
- REST는 URI로 자원을 식별하고, HTTP 메소드로 요청의 의미를 단순하고 직관적으로 나타내어 설정과 사용이 쉽다.
✅ 확장성
- SOAP에서는 상태 유지가 가능하기 위해 각 서버가 세션 정보를 공유해야 하므로 확장성이 떨어진다.
- REST에서는 상태를 저장하지 않으므로, 이전 상태를 기억할 필요가 없어 부하 분산이 쉽다.
✅ 웹 개발에 좋음
- SOAP은 다양한 프로토콜을 지원하지만 대부분의 웹 서비스가 HTTP 기반이므로 불필요한 기능까지 포함하게 되었다.
- REST는 HTTP 기본 원칙을 따르고, 캐싱이 가능하여 웹 개발 친화적이다.

현재는 대부분의 웹 서비스에서 REST를 표준 방식으로 채택하지만,
기업 시스템 같은 레거시 애플리케이션이나 보안이 중요한 곳에서는 SOAP이 적절할 수 있으므로 필요에 따라 사용하면 된다.

참고자료

https://aws.amazon.com/ko/compare/the-difference-between-soap-rest/
https://aws.amazon.com/ko/what-is/api/
https://www.redhat.com/ko/topics/integration/whats-the-difference-between-soap-rest#%EC%9A%94%EC%95%BD
https://www.redhat.com/ko/topics/api/what-are-application-programming-interfaces#web-api-%EB%B0%8F-%EC%9B%90%EA%B2%A9-api
https://drg2524.tistory.com/138

소영

블로그 이전: https://syleeblog.tistory.com/

이전 포스트

[Spring] WP 5-2. SpringBoot에서의 Bean 개념 & 등록 방법 정리

다음 포스트