아래는 7주차 위클리페이퍼 첫 번째 주제이다.

  • 웹 API의 발전 과정에서 SOAP에서 REST로의 전환이 일어난 이유와 그 장단점에 대해 설명하세요

먼저 웹 API란, 웹(네트워크)을 통해 서로 다른 애플리케이션이 데이터를 주고받을 수 있도록 정의된 약속이다. 우리가 흔히 접하는 예로는 프론트엔드(클라이언트)가 백엔드(서버)의 API를 호출하여 데이터를 주고받는 구조가 있다.

 

1. 과거의 웹 API: 엔터프라이즈 시스템 통합

그러나 과거에는 지금처럼 브라우저나 모바일 기기와 서버 간 통신이 주요 목적이 아니었다. 웹 API의 목적은 이기종 엔터프라이즈급 시스템을 연결하는 것이었다.

예를 들어

  • 은행사 A는 Java
  • 보험사 B는 .NET
  • 카드사 C는 C++

로 작성된 엔터프라이즈 애플리케이션을 사용한다고 가정하자.

이때 서로 다른 언어와 메모리 구조를 가진 시스템들이 데이터를 교환해야 하는 상황이 발생한다. 그러나 각 플랫폼의 차이와 기업 방화벽 정책으로 인해 직접적인 통신은 매우 어려웠다.

이러한 문제를 해결하기 위해 등장한 웹 API가 바로 SOAP이다.

 

2. SOAP의 등장과 특징

SOAP은 모든 방화벽에 기본적으로 열려 있는 HTTP(80번 포트)를 통신 수단으로 사용하고, 데이터를 XML이라는 텍스트 기반 구조로 통일하여 플랫폼 간 표준화를 이루었다.

SOAP은 단순한 웹 API를 넘어, 표준 메시지 “프로토콜”로 설계되었다.

  • XML 기반 메시지 작성
  • WSDL(Web Services Description Language)을 통한 인터페이스 정의
  • WS-*라는 기능 확장 표준 스펙 제공

특히 WS-*는 엔터프라이즈급 시스템에서 필요한 보안성과 신뢰성을 제공하기 위해 만들어진 규격이다.

대표적으로 다음과 같은 표준이 존재한다.

  • WS-Security (보안)
  • WS-ReliableMessaging (신뢰성)
  • WS-AtomicTransaction (분산 트랜잭션)

이를 통해 SOAP은 보안, 신뢰성, 트랜잭션을 프로토콜 수준에서 지원하였다. 그러나 이러한 기능들은 동시에 SOAP의 복잡성과 오버헤드의 원인이 되었다.

 

3. SOAP과 MSA의 구조적 충돌

시간이 지나면서 엔터프라이즈 중심 환경에서 벗어나 MSA(마이크로서비스 아키텍처)와 모바일·개인화 기기가 중심이 되는 시대가 도래했다.

SOAP은 이기종 플랫폼 통합을 목표로 설계되었기 때문에 MSA와 구조적으로 맞지 않는 부분이 존재한다.

WS-AtomicTransaction은 여러 시스템을 하나의 트랜잭션으로 묶어 강한 일관성을 유지해서 하나가 실패하면 전체가 롤백된다.

반면 MSA는 작은 서비스들이 독립적으로 동작하며, 부분 실패를 허용하고 재시도를 통해 **최종 일관성(Eventual Consistency)**을 달성하는 것이 더 유리하다. 이를 위해 Saga 패턴이 사용된다. WSDL 기반의 강한 계약 구조는 서비스 간 강한 결합을 유발하여 독립 배포와 확장성을 저해할 수 있다. 복잡한 XML 파싱과 WS-* 스펙 처리 과정은 대규모 엔터프라이즈 시스템에서는 문제가 되지 않았지만, 경량 클라이언트 환경에서는 부담이 될 수 있다. 이러한 배경 속에서 등장한 것이 REST이다.

 

4. REST의 등장과 핵심 특징

REST는 SOAP처럼 하나의 표준 메시지 프로토콜이 아니라, HTTP를 기반으로 하는 아키텍처 스타일이다.

REST의 핵심은 다음과 같다.

  • 자원(Resource)을 URI로 표현
  • HTTP 메서드(GET, POST, PUT, DELETE 등)의 의미를 적극 활용
  • Stateless 구조 유지

Stateless 구조는 서버가 클라이언트의 상태를 저장하지 않는 것을 의미하며, 수평 확장과 오토 스케일링 환경에서 매우 유리하다.

다음으로는 REST의 6가지 제약 조건이다.

 

5. REST의 6가지 제약 조건

  1. Client-Server
    클라이언트는 UI/UX를 담당하고, 서버는 데이터와 비즈니스 로직을 담당한다.
  2. Stateless
    서버는 클라이언트 상태를 저장하지 않으며, 모든 요청은 필요한 정보를 포함해야 한다.
  3. Cacheable
    HTTP의 캐시 메커니즘을 활용하여 응답을 캐시할 수 있다.
  4. Uniform Interface
    모든 자원은 URI로 식별되며, HTTP 메서드의 의미를 일관되게 사용한다.
  5. Layered System
    클라이언트는 자신이 최종 서버와 직접 통신하는지, 중간 계층(API Gateway, 프록시 등)을 거치는지 알 필요가 없다.
  6. Code-On-Demand (선택)
    필요 시 클라이언트에 실행 코드를 전달할 수 있다.

REST는 이러한 제약 조건을 통해 현대의 웹 환경에 적합하다.

그렇다면 REST의 장단점은 무엇이 있을까?

 

6. REST의 장점

REST는 다음과 같은 장점을 가진다.

  • 확장성에 유리하다.
    Stateless 구조 덕분에 로드 밸런싱과 오토 스케일링이 자연스럽게 이루어진다.
  • 웹 인프라와 자연스럽게 통합된다.
    HTTP 캐시, CDN, 프록시, API Gateway와 쉽게 연동된다.
  • 구현이 비교적 단순하고 가볍다.
    JSON을 사용하여 메시지 구조가 간결하고 파싱 비용이 낮다.

7. REST의 단점

  • 통합된 표준 스택이 존재하지 않는다.
    SOAP은 WS-*로 기능을 통합했지만, REST는 TLS, OAuth, 메시지 브로커, Saga 패턴 등으로 분리하여 해결한다.
  • 강한 분산 ACID 트랜잭션을 지원하지 않는다.
    대신 최종 일관성을 채택한다.
  • 설계 일관성이 깨질 위험이 있다.
    아키텍처 스타일이므로 원칙을 지키지 않으면 RPC 형태로 변질될 수 있다.

8. 결론

SOAP은 이기종 엔터프라이즈 시스템을 강한 계약과 표준화된 스펙으로 통합하기 위해 등장한 기술이다. 그러나 클라우드와 마이크로서비스 중심의 환경에서는 확장성과 독립 배포가 더욱 중요해졌고, 이에 따라 REST가 주류로 자리 잡게 되었다.

EJB가 사라지고 Spring이 등장한 것과 달리, SOAP은 기술적으로 도태된 것이 아니다. 강한 일관성과 신뢰성이 중요한 금융권이나 레거시 환경에서는 여전히 사용되고 있다.

결국 SOAP에서 REST로의 전환은 단순한 기술 교체가 아니라, 아키텍처 패러다임의 변화라고 볼 수 있다.

 

 

 

 

 

PSG-00
PSG-00
개발자의 작고 소중한 공간

티스토리툴바