RESTful 좀 쓰지 마라¶

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com) 
초안: 2024년 12월 / 개정: 2026년 01월

[Author’s Intent] 이 글은 RESTful 아키텍처가 모든 비즈니스 시스템에 만능 해법이 아님을 논리적으로 증거하고, 각 시스템의 본질과 요구에 따라 아키텍처를 신중하게 선택해야 함을 경고하고자 합니다.

Executive Summary¶

현재 RESTful API는 국내 웹 개발에서 사실상의 표준(de facto standard)로 여겨진다.
사실상의 표준이 되면서, RESTful API는 그 한계점과 비용에 대한 고민이 없이 무분별하게 사용되고 있다.
RESTful은 웹의 확장성과 상호운용성을 극대화하기 위해 제안된 것으로, 자원(=Data)을 주로 정적으로 배포하기 위한 아키텍처 스타일이다.
인터페이스 일관성(Uniform Interface), 상태 비저장성(Stateless), 캐시 가능성(Cacheability)에 대한 요구가 그러한 목적을 암시한다.
동작을 GET/POST/PUT/PATCH로만 제공하겠다는 것은 모든 자원의 취급을 동등 개념(사실상 JSON 문서)으로 간주하겠다는 것이다.
웹에서 JSON 문서에 RESTful의 원칙인 상태 비저장성(Stateless), 캐시 가능성(Cacheability)을 강제하면, 사실상 정적(영속/준영속) 문서 공유로 수렴된다.
때문에 다중 리소스에 대한 동시 편집 - 즉, 트랜잭션이 중심이 되는 업무 시스템에 사용하기에 부적절하다.
CRUD 자원에 URI를 하나씩 대응시키는 설계는 복잡한 시나리오를 수십 개의 HTTP 호출로 잘게 쪼개진다.
그러나 라운드 트립의 폭증은 사소한 문제로 더 큰 문제는 트랜잭션에 대한 원자성 보장을 클라이언트가 떠맡게 된다는 점이다.
이는 소프트웨어 기능의 신뢰성 측면, 그리고 보안상 아주 심각한 취약점이다.
그리고 대부분의 비즈니스는 상태 비저장성(Stateless)과 호환성이 없다.
웹의 근원적 출발은 연구소(CERN = 유럽 입자 물리 연구소) 내부의 문서 공유 - 즉 무료 개념이나, 비즈니스는 상태·규칙·트랜잭션이 핵심이기 때문이다.
판매자, 구매자, 상품, 가격의 존재는 '상태 (State)'의 존재를 필수로 만든다.
아키텍처적 이점/비용 구조 분석의 결과는 RESTful은 위키, 커뮤니티, 회계 장부와 같은 평면적 정보구조에 대한 수정이 매우 드문 시스템을 상정한 구조적 해결책이다.
이를 상태가 연속적으로 변하는 전자상거래, 물류, 교육/학습관리, 기계, 영업, 고객관리 등의 분야에 적용하는 것은 비용 폭증만 가져온다.

Preface¶

현재 대한민국 웹 개발 생태계에서 RESTful API는 선택의 영역을 넘어선, 일종의 '기본값(Default)'이자 '사실상의 표준(de facto standard)'으로 확고히 자리 잡았다. 신규 프로젝트의 아키텍처 회의에서 통신 방식을 논의할 때, REST 이외의 대안은 진지하게 고려조차 되지 않는 경우가 허다하다. 마치 웹 개발을 한다면 당연히 RESTful하게, JSON을 주고받는 HTTP API를 설계해야 한다는 것이 불문율처럼 여겨지고 있다.

과거 엔터프라이즈 시장을 지배했던 SOAP과 XML의 과도한 복잡성에 지친 개발자들에게, REST의 직관성과 단순함은 분명 매력적인 대안이었다. 그러나 시간이 흐르며 이 '단순함'은 도리어 아키텍처적 사고를 가로막는 장벽이 되었다. 수많은 개발팀이 로이 필딩(Roy Fielding)이 제안한 REST의 본질적인 제약 조건—상태 비저장성(Stateless), 캐시 가능성(Cacheability), HATEOAS 등—이 왜 필요한지, 그리고 그것이 어떤 비용을 수반하는지에 대한 깊은 고민 없이, 그저 URL에 자원(Resource)을 명시하고 HTTP 메서드로 CRUD를 매핑하는 행위를 'RESTful'이라 부르며 기계적으로 답습하고 있다.

문제는 이러한 관습적 선택이 우리가 해결해야 할 비즈니스의 본질과 충돌할 때 발생한다. REST는 태생적으로 웹이라는 거대한 분산 하이퍼미디어 시스템, 즉 정적인 문서나 자원의 상태를 전달하고 공유하는 데 최적화된 아키텍처 스타일이다. 그러나 현대의 많은 비즈니스 애플리케이션은 단순한 정보의 나열과 조회를 넘어, 복잡한 트랜잭션 제어, 상태(State)의 전이, 그리고 순차적이고 원자적인 비즈니스 로직 처리를 핵심으로 한다.

이러한 동적인 비즈니스 요구사항을 정적인 자원 중심의 REST 아키텍처에 억지로 끼워 맞추려다 보니, 시스템은 필연적으로 비효율을 낳게 된다. 하나의 논리적 작업을 처리하기 위해 수십 번의 네트워크 왕복(Round Trip)이 발생하고, 서버가 져야 할 트랜잭션의 책임을 클라이언트가 떠안게 되며, 데이터의 일관성을 보장하기 위해 불필요한 복잡성이 코드 곳곳에 스며든다. 그럼에도 불구하고 "왜 이 프로젝트에 REST를 사용하는가?"라는 질문에 대해, 기술적 근거 대신 "업계 표준이니까", "라이브러리가 많으니까"라는 안일한 답변만이 돌아오는 것이 작금의 현실이다.

이 글은 RESTful API가 무가치하다거나 무조건 배격해야 한다는 주장을 하려는 것이 아니다. 다만, 아무 생각 없이, 모든 문제에 REST를 사용하는 현재의 풍조와, 도구의 특성 및 비용 구조를 고려하지 않은 무분별한 채택이 가져오는 구조적 리스크를 지적하고자 한다. 우리가 만드는 시스템이 단순한 블로그나 위키가 아니라면, REST는 최선의 답이 아닐 수 있다. 이제는 관성적인 선택에서 벗어나, 우리가 마주한 문제의 복잡성을 가장 효과적으로 제어할 수 있는 아키텍처가 무엇인지, 그 비용과 효용을 냉정하게 따져보아야 할 시점이다.

REST는 문서 배포를 위한 스타일이다¶

REST는 2000년, 로이 필딩(Roy Fielding)의 박사 논문에서 처음으로 제안되었다. REST는 분산 시스템 설계를 위해 다음과 같은 6가지 제약 조건을 기반으로 한다. 이 제약 조건들은 REST 아키텍처 스타일을 정의하며, 이를 준수해야 진정한 RESTful 시스템이라 할 수 있다.

클라이언트-서버 구조: 클라이언트와 서버를 명확히 분리하여 각자의 역할에 집중할 수 있도록 한다.
상태 비저장성 (Stateless): 서버는 클라이언트의 상태 정보를 저장하지 않는다. 각 요청은 독립적으로 처리되어야 하며, 필요한 모든 정보는 요청에 포함되어야 한다.
캐시 가능성 (Cacheability): 서버 응답이 캐시될 수 있어야 하며, 클라이언트는 이를 활용하여 네트워크 트래픽과 서버 부하를 줄일 수 있다.
계층화 시스템 (Layered System): 클라이언트와 서버 간에 여러 계층을 둘 수 있으며, 각 계층은 독립적으로 동작한다.
인터페이스 일관성 (Uniform Interface): REST 시스템은 일관된 인터페이스를 제공해야 하며, 이를 통해 리소스와 상호작용할 수 있어야 한다.
주문형 코드 (Code on Demand): 필요에 따라 서버가 클라이언트에 코드를 전송하여 실행할 수 있다. 예: JavaScript, 플러그인 등.

REST의 제약 조건들, 특히 인터페이스 일관성(Uniform Interface), 상태 비저장성(Stateless), 캐시 가능성(Cacheability)을 깊이 들여다보면, 이 아키텍처가 지향하는 바가 명확해진다. 그것은 바로 '정보의 효율적인 배포와 공유'이다.

우선, 인터페이스 일관성을 보자. REST는 리소스에 대한 조작을 HTTP Method(GET, POST, PUT, DELETE 등)라는 극히 제한된 동사로 한정한다. 이는 시스템이 다루는 모든 대상을 '문서'나 '자원'이라는 동등한 개념으로 추상화하겠다는 선언과 같다. 복잡한 비즈니스 행위(예: '주문 승인', '재고 예약', '배송 시작')를 고유한 메서드로 정의하는 대신, 단순히 문서를 생성(Create)하거나 수정(Update)하는 행위로 환원시킨다. 이는 마치 리눅스 시스템의 설계가 근본적으로 모든 것을 파일 입출력으로 환원하려는 것과 유사하며, 일반적으로 데이터가 JSON 형식을 띤다 해도 본질적으로는 정적인 문서 관리의 메타포를 따르고 있음을 의미한다.

다음으로 상태 비저장성과 캐시 가능성은 이 아키텍처가 '변하지 않는' 혹은 '드물게 변하는' 정보에 최적화되어 있음을 강력하게 시사한다. 서버가 클라이언트의 이전 상태를 기억하지 않아도 된다는 것은, 각 요청이 독립적인 문서 조회와 같다는 뜻이다. 또한 응답을 캐시할 수 있다는 것은, 데이터가 시간에 따라 급격하게 변하지 않으며, 여러 사용자가 동일한 시점에 동일한 데이터를 보아도 무방하다는 전제를 깔고 있다.

웹(Web)이라는 거대한 시스템이 바로 이러한 특성을 가진다. 뉴스 기사, 블로그 포스트, 위키 백과 항목 등은 한 번 작성되면 잘 변하지 않고, 수많은 사람이 동시에 읽어도 문제가 없다. REST는 이러한 웹의 확장성과 상호운용성을 극대화하기 위해 고안된 아키텍처다.

그러나 우리가 개발하는 현대의 비즈니스 애플리케이션은 어떤가? 재고는 실시간으로 변하고, 주문 상태는 복잡한 규칙에 따라 전이되며, 사용자의 행동 문맥(Context)에 따라 서버의 응답이 달라져야 한다. 이런 동적인 환경에서 JSON 데이터에 REST의 원칙을 강제하는 것은, 살아 움직이는 비즈니스 프로세스를 박제된 정적 문서처럼 취급하려는 것과 다름없다.

결과적으로, RESTful은 자원(Resource)이라는 이름의 데이터를 정적으로 배포하고 공유하기 위한 아키텍처 스타일이다. 이를 복잡한 트랜잭션과 상태 관리가 필수적인 업무 시스템에 무비판적으로 적용하는 것은, 마치 엑셀로 복잡한 ERP를 구축하려는 시도처럼 도구의 본질적 목적을 오해한 것이다.

RESTful은 트랜잭션(Transaction)을 수용하지 않는다¶

RESTful은 다중 리소스에 대한 동시 편집, 즉 트랜잭션이 중심이 되는 업무 시스템에 사용하기에 부적절하다. 정확히 말하면 RESTful Architecture의 중심에 트랜잭션(Transaction)을 위한 자리가 없어서 수용되지 않는다. 결과적으로 아키텍처 밖에서 이를 처리해야 하고, 그 책임이 신뢰성이 높은 서버가 아니라 클라이언트로 넘어간다.

REST가 전제하는 것은 "리소스 단위의 독립적 조작"이다. 주문이라는 사건이 발생하면 실제로는 결제 승인, 재고 차감, 포인트 적립, 쿠폰 소진, 배송지 확정 등이 묶여 하나의 원자적 상태 전이를 이룬다. 하지만 REST 방식으로 설계하면 각각을 다른 리소스의 생성/수정으로 분해하게 되고, 각 단계는 다른 엔드포인트로 흩어진다. 이때 원자성은 HTTP 호출의 집합으로 해체된다. 한 번의 비즈니스 명령이 수십 개의 요청으로 쪼개지고, 실패 조합은 기하급수적으로 증가한다. "어디까지 성공했는지"를 판단하고 되돌리는 로직은 결국 클라이언트나 오케스트레이터가 짊어진다. 그러나 대부분 오케스트레이터 또는 트랜잭션 매니저는 만들지 않는다.

자원에 대한 CRUD를 URI를 하나씩 대응시키는 설계는 사용 시나리오 친화적이지 않다. 데이터 관리에 방점이 찍힌 설계이다. 결과적으로 단일 기능은 수십 개의 HTTP 호출로 잘게 쪼개진다. 그러나 라운드 트립의 폭증은 사소한 문제로, 더 큰 문제는 트랜잭션에 대한 원자성 보장을 신뢰성이 떨어지는 외부(ex> 웹브라우저)가 떠맡게 된다는 점이다. 예를 들어 결제 승인 후 재고 차감이 실패하면 결제 취소를 호출해야 하고, 그 취소마저 실패하면 "보상 트랜잭션의 보상"을 만들어야 한다. 이 구조는 서버를 신뢰 가능한 시스템이 아니라, 단순 엔터티 저장소로 전락시킨다. 결국 비즈니스 로직의 핵심은 클라이언트에 전가된다.

이 문제는 단순한 복잡성의 문제가 아니라, 신뢰성과 보안의 문제다. 트랜잭션의 핵심은 "중간 상태가 외부에 노출되지 않는다"는 보장인데, REST 방식으로 쪼개면 중간 상태가 API 호출 사이에서 노출된다. 그 순간 동시성 충돌이 발생하고, 사용자에게는 "결제는 됐는데 주문은 안 됐다" 같은 실패 경험이 남는다. 더 치명적인 것은 공격 표면이다. 호출 순서를 바꾸거나 일부 단계만 재실행하면, 할인 중복 적용, 재고 우회, 포인트 중복 적립 같은 허점이 생긴다. 보안은 결국 API 호출의 순서와 횟수를 검증하는 규칙을 또 만들어야 한다는 뜻이고, 이는 REST의 단순함을 무너뜨린다.

현실적으로 많은 팀이 "사가 패턴"이나 "보상 트랜잭션"으로 이를 우회한다. 그러나 이는 트랜잭션을 없애는 것이 아니라, 훨씬 복잡한 형태로 재구현하는 것이다. 분산 락, 메시지 큐, 상태 저장소, 재시도 전략이 추가되고, 운영자는 실패 조합을 모니터링해야 한다. 결국 아키텍처는 더 비싸지고, 장애 대응은 더 어려워진다. 요약하면 RESTful은 트랜잭션을 없애지 못한다. 단지 트랜잭션을 "어디서 처리할 것인가"를 서버에서 클라이언트와 운영으로 밀어낼 뿐이다. 이 점이 복잡한 업무 시스템에서 REST가 비효율적으로 느껴지는 가장 큰 이유다.

대부분의 업무는 장부 기록이 아니다¶

대부분의 비즈니스 시스템은 RESTful이 전제하는 상태 비저장성(Stateless)과 본질적으로 호환되지 않는다. 웹의 근원적 출발은 연구소(CERN) 내부의 문서 공유, 즉 무료로 정보를 배포하고 열람하는 환경이었다. 이때의 웹은 정적 문서의 배포와 공유가 목적이었고, 각 문서는 독립적으로 존재하며, 사용자의 행위가 시스템의 상태를 변화시키지 않았다. 그러나 비즈니스 시스템은 이와 정반대의 특성을 가진다. 판매자, 구매자, 상품, 가격 등은 단순한 정보가 아니라, 서로 얽혀 있는 상태(State)와 규칙(Rule), 그리고 트랜잭션(Transaction)의 집합이다.

예를 들어, 전자상거래 시스템을 생각해보자. 사용자가 상품을 장바구니에 담고, 결제 과정을 거쳐 주문을 확정하는 일련의 과정은 단순한 CRUD의 조합이 아니다. 각 단계마다 재고의 변동, 결제 승인, 배송지 검증, 할인 정책 적용 등 복잡한 비즈니스 로직이 개입된다. 이 과정에서 발생하는 모든 데이터는 서로 긴밀하게 연결되어 있으며, 하나의 작업이 실패하면 전체를 되돌려야 하는 원자성(Atomicity)이 요구된다. 즉, 거래란 단순히 문서를 저장하고 조회하는 행위가 아니라, 여러 상태가 유기적으로 변화하고, 그 변화가 일관되게 유지되어야 하는 복합적인 흐름이다.

RESTful의 상태 비저장성은 각 요청이 독립적으로 처리되어야 한다는 제약을 강제한다. 서버는 클라이언트의 이전 상태를 기억하지 않으며, 모든 정보는 요청에 포함되어야 한다. 이로 인해, 실제 비즈니스에서는 상태를 클라이언트 토큰, 임시 저장소, 분산 캐시 등 다양한 방식으로 우회 저장하게 된다. 예를 들어, 장바구니 ID, 결제 세션, 인증 토큰 등 모든 상태 정보를 매 요청마다 전달해야 하며, 이 과정에서 보안 검증, 유효성 검사, 동시성 제어 등 추가적인 복잡성이 발생한다. 결국, 상태를 없애는 것이 아니라, 더 많은 레이어에 복제하고, 관리 포인트를 늘리는 셈이다.

더 나아가, 거래의 본질은 트랜잭션의 신뢰성과 일관성에 있다. 은행 송금, 재고 관리, 주문 처리 등은 모두 "한 번의 명령에 여러 규칙을 평가하고, 실패 시 전체를 되돌리는" 흐름을 필요로 한다. 그러나 RESTful을 교과서적으로 적용하면, '주문 생성 → 결제 정보 등록 → 재고 차감 → 배송지 확정'처럼 비즈니스의 한 단계를 여러 개의 HTTP 호출로 쪼개게 된다. 각 호출이 독립적으로 성공했는지 확인하고, 실패하면 되돌릴 API를 또 만들어 호출해야 한다. 결국 API는 상태 머신이 아니라 엔터티 저장소에 불과해지고, 실제 흐름은 클라이언트 코드에 흩어진다. 원자성 보장을 클라이언트가 떠맡게 되면서, 실패 조합과 복구 시나리오가 급격히 늘어난다. 클라이언트가 많아질수록 제어 불가능한 조합이 생기고, 서버는 트랜잭션을 보장하지 못한다.

이러한 구조적 한계는 보안과 신뢰성에도 직접적인 영향을 미친다. 예를 들어, 결제 시스템에서 트랜잭션의 원자성이 깨지면, 중복 결제, 재고 오류, 데이터 불일치 등 치명적인 문제가 발생할 수 있다. RESTful의 상태 비저장성은 이러한 문제를 예방하기 위한 서버 측 제어를 어렵게 만들고, 클라이언트에 과도한 책임을 떠넘긴다. 또한, 네트워크 장애나 지연이 발생할 경우, 여러 요청 중 일부만 성공하거나 실패하는 상황이 빈번하게 발생하며, 이를 복구하기 위한 로직이 클라이언트와 서버 모두에 중복 구현된다.

결국, 거래란 단순한 문서 관리가 아니다. 비즈니스의 본질은 상태의 변화와 그 변화의 일관성, 그리고 트랜잭션의 신뢰성에 있다. RESTful의 제약을 무비판적으로 적용하는 것은, 복잡한 업무를 단순 장부 기록으로 오해하는 것과 같다. 우리는 시스템의 목적과 요구사항을 먼저 파악하고, 그에 맞는 아키텍처를 선택해야 한다.

RESTful은 매우 평면적이다.¶

RESTful 아키텍처의 또 다른 본질적 한계 중 하나는 '평면성(flatness)'에 있다. RESTful은 위키, 커뮤니티, 회계 장부처럼 엔터티 간의 종속성이 적고, 각 리소스가 독립적으로 존재하는 환경에서 가장 큰 효과를 발휘한다. 이러한 시스템에서는 각 리소스가 단일 URI로 명확히 식별되고, CRUD 작업이 단순하게 매핑된다. 하지만 현실의 비즈니스 도메인은 대개 복잡한 엔터티 관계와 계층적 구조, 그리고 다양한 의존성을 내포한다.

이를 설명하기에 차용하기 좋은 개념이 Fan-in과 Fan-out이다. 본래 Fan-in과 Fan-out은 모듈의 의존성에 대해 사용되는 개념이다. 그러나 데이터나 정보 또한 상호간에 연관성, 참조, 의존성, 확장성 등 다양한 이유로 연결된다.

RESTful에서는 각 리소스를 독립적으로 다루기 때문에, Fan-in/out이 커질수록 단일 자원이 어디까지의 데이터를 반환해야 하는지 결정하는 문제가 연쇄적으로 발생한다. 예를 들어, 고객 정보를 조회할 때 단순히 고객의 Id만 반환하면, 이후 주문, 결제, 배송 등 하위 리소스에 대해 1+N+M+L... 형태의 추가 호출이 필요해진다. 반대로, 한 번에 모든 하위 리소스까지 반환하면 불필요한 트래픽이 발생하고, 리소스의 정체성(즉, 무엇이 핵심 데이터인가)이 모호해진다.

이러한 평면성의 한계는 실제 시스템에서 다양한 문제로 이어진다. 첫째, 데이터가 복잡하게 얽혀 있는 도메인에서는 RESTful의 단순한 리소스-URI 매핑이 오히려 비효율을 초래한다. 예를 들어, 전자상거래 시스템에서 주문 내역을 조회할 때, 주문 자체뿐 아니라 상품, 결제, 배송, 할인, 쿠폰 등 수많은 연관 엔터티가 함께 필요하다. 이때 각 엔터티를 별도의 URI로 분리하면, 클라이언트는 수십 번의 네트워크 호출을 반복해야 하며, 이는 성능 저하와 동기화 문제, 장애 포인트 증가로 이어진다. 둘째, 하위 리소스를 한 번에 모두 반환하는 방식은 데이터 과다 전송, 불필요한 정보 노출, API의 일관성 저하 등 또 다른 문제를 낳는다. 실제로는 클라이언트마다 필요한 데이터의 범위가 다르기 때문에, 일률적으로 모든 정보를 반환하는 것은 RESTful의 단순함을 해치는 결과가 된다.

또한, Fan-in/out이 큰 자료구조를 가진 도메인에서는 API 설계의 난이도가 급격히 높아진다. 어떤 URI에서 어디까지의 연관 데이터를 포함할지, 중첩 깊이와 반환 정책을 어떻게 정할지, 부분 갱신이나 부분 조회를 어떻게 지원할지 등 수많은 설계적 고민이 필요하다.

결국, RESTful이 진정한 가치를 발휘하는 곳은 데이터 구조가 단순하고, 엔터티 간의 종속성이 약하며, 각 리소스가 독립적으로 관리될 수 있는 환경이다. 반대로, 복잡한 비즈니스 로직과 계층적 데이터, 다양한 관계와 의존성이 얽힌 시스템에서는 RESTful의 평면성이 한계로 작용한다.

아키텍처로서 RESTful의 장단점과 청구서¶

아키텍처로서 RESTful은 데이터의 변경 빈도가 낮고, 트랜잭션이나 복잡한 상태 전이가 거의 없는 시스템을 염두에 두고 설계된 구조적 해결책이다. 이러한 환경에서는 RESTful의 단순함과 일관성, 그리고 확장성이라는 장점이 극대화된다. 예를 들어, 위키 문서나 게시판 글, 회계 장부의 기록처럼 대부분의 작업이 조회와 단순한 추가/수정에 그치고, 여러 사용자가 동시에 복잡한 상태 변화를 일으키지 않는 경우에는 RESTful이 제공하는 표준화된 인터페이스와 캐시 전략이 큰 효과를 발휘한다. 또한, 문서 기반의 시스템에서는 각 리소스가 독립적으로 존재하므로, 상태 비저장성의 제약이 오히려 시스템의 단순화와 확장에 기여할 수 있다.

그러나 현실의 비즈니스 시스템, 특히 전자상거래, 물류, 교육/학습관리, 기계 제어, 영업, 고객관리 등과 같이 상태가 연속적으로 변하고, 복잡한 트랜잭션과 규칙, 동시성 제어가 필수적인 분야에 RESTful을 그대로 적용하는 것은 심각한 비효율과 비용 증가로 이어진다. 이러한 시스템에서는 한 번의 비즈니스 명령이 여러 상태를 동시에 변화시키고, 실패 시 전체를 되돌려야 하는 원자성(Atomicity)과 일관성(Consistency)이 요구된다. 하지만 RESTful은 각 요청이 독립적으로 처리되어야 한다는 제약 때문에, 복잡한 업무 플로우를 여러 개의 HTTP 호출로 쪼개게 만들고, 그 결과 트랜잭션의 책임이 신뢰성이 낮은 클라이언트로 전가된다. 이 과정에서 발생하는 네트워크 비용, 상태 동기화 문제, 보상 트랜잭션의 복잡성, 데이터 불일치와 보안 취약점 등은 시스템 전체의 신뢰성과 유지보수성을 심각하게 저해한다.

특히, RESTful의 가장 큰 한계는 "변화가 드문 정보 구조"에 최적화되어 있다는 점이다. 달리 말하면, 시계열에 따라 변화가 발생하는 기능을 제공하지 않거나, 매우 드물게 제공한다는 것이다. 즉, 능동적인 동작(Action)이 거의 없는 매우 수동적 시스템에 최적화되어 있다는 의미이다.

결론¶

RESTful은 단순 정보 배포와 조회, 변경이 드문 평면적 데이터 구조에는 여전히 강력한 도구이지만, 상태와 트랜잭션, 복잡한 비즈니스 로직이 핵심인 시스템에는 적합하지 않다.

모든 아키텍처는 그 선택에 수반되는 이점과 비용을 검토한 뒤, 지금 이 문제에 최적인 것을 선택해야 한다. 그렇지 않을 경우 리스크를 개발 과정에서 야근과 인건비 증가, 운영 시 시스템의 불안정성이라는 청구서로 부담하게 된다. 때문에 웹 개발 생태계에서 RESTful API는 '사실상의 표준(de facto standard)'으로 인식되는 현상태는 거의 대부분의 개발자와 회사가 영문도 모른 채 불필요한 세금을 내는 상태와 같다.

아키텍처의 선택은 우선 그 아키텍처의 뛰어난 점과 취약한 점, 그리고 그것을 위해 기꺼이 지불하는 비용을 인식하는 것에서 출발해야 한다. 그 뒤, 우리의 문제의 본질과 요구사항에 명확히 따라 적절한 선택을 해야 한다. 같은 맥락에서 RESTful은 만능 해법이 아니라 특정 문제에 최적화된 도구임을 인식하고, 가능하면 '기본값(Default)'으로 인식하지 말기 바란다.

Author¶

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com)
https://js-seth-h.github.io/website/Biography/

Over 20 years in software development, focusing on design reasoning and system structure - as foundations for long-term productivity and structural clarity.

Researched semantic web and meta-browser architecture in graduate studies,
with an emphasis on structural separation between data and presentation.

Ph.D. in Software, Korea University
M.S. in Computer Science Education, Korea University
B.S. in Computer Science Education, Korea University