[기술 공부] API 역사와 진화

ParkJunHa·2025년 5월 30일

API Gateway POSIX REST Soap graphql grpc open api economy win32

기술공부-API

목록 보기

2/3

Win32 / Posix (1980-90s)

Win32와 POSIX API는 로컬 OS 자원 제어에 집중한 추상화였음.
당시 개발자의 주요 관심은 파일을 열고, 쓰레드를 만들고, GUI를 띄우는 일이었고, API 역시 내 컴퓨터 안에서 무엇을 어떻게 다룰것인가가 중심이었음.

프로그램이 CPU / 메모리 / 파일을 만지는 유일한 통신 창구인 OS API
앱이 머신마다 달라지는 세부 레지스터를 몰라도 되게끔 하기 위한 하드웨어 추상화가 목적이었음.
흐름상 실행 파일 ➡️ DLL/시스템 콜 ➡️ 커널로 동기 / 단일 프로세스 호출
네트워크 없이 동작하던 로컬 애플리케이션 시대.
- PC와 OS가 제공하는 자원만 사용함.
- OS 내부 자원에만 의존하는 프로그래밍 패러다임.

엔터프라이즈 통합 & SOAP / WSDL (2000s)

배경
- 2000년대 초중반, 대기업의 이기종 시스템들을 연결하기 위한 표준적인 통신 방법으로 각광받았음.
- 기업 내부에는 이질적인 시스템(ERP, CRM, 회계, 물류) 들이 운영 중. ➡️ 각각은 서로 다른 언어, 플랫폼, 데이터 포맷을 사용.

이들을 하나의 흐름으로 통합하는 것이 필요함 (주문이 들어오면 물류·회계 시스템이 자동으로 감지하고 반응하는 등.)

SOAP(Simple Object Access Protocol)

XML 기반 메시징 프로토콜

<Envelope>
<Header>…</Header>       <!-- 인증, 트랜잭션 등 메타정보 -->
<Body>…</Body>           <!-- 실제 호출 내용 -->
</Envelope>

WSDL(Web Service Description Language)

SOAP API의 인터페이스 명세서(XML)

<portType name="OrderService">
<operation name="PlaceOrder">
  <input message="tns:PlaceOrderRequest"/>
  <output message="tns:PlaceOrderResponse"/>
</operation>
</portType>

어떤 메서드가 있으며 어떤 파라미터/리턴을 갖는지 정의함.

UDDL(Universal Description, Discovery and Integration)
- 지금은 거의 사용하지 않지만, 웹 서비스의 디렉토리임

데이터는 모두 XML 문서로 전달되며, HTTP뿐만 아니라 SMTP등 다른 프로토콜도 사용 가능했음
호출은 RPC 스타일(함수처럼 호출) 또는 Document 스타일 (XML 문서 교환)

장점	한계
언어/플랫폼 독립성 (XML 기반)	XML 문서가 크고 복잡함 → 성능 저하
계약 기반(Contract-first 개발 가능)	툴 의존도 ↑, 학습 비용 ↑
확장 가능한 헤더 구조 (WS-Security 등)	“WS-*" 스펙들이 너무 방대하고 복잡
트랜잭션, 신뢰성, 보안 모두 대응 가능	HTTP만 사용하지 않아서 방화벽 제약 발생
IDE 지원 강력 (Java, .NET 등에서 자동 생성)	브라우저/모바일 환경 부적합

REST 시대 - 웹 네이티브 API (2005 - 2015)

2000년대 후반부터 본격적으로 시작되어, 오늘날까지 가장 널리 사용되는 API 설계 방식

배경
- SOAP은 무겁고 복잡하며, XML만 지원하고 브라우저나 모바일에 비효율적
- Ajax, JavaScript, iPhone 등으로 웹이 상호작용 중심으로 진화
- 기업뿐 아니라 개발자 커뮤니티·오픈 플랫폼 생태계가 성장함 ➡️ 단순하고 유연한 API 필요

REST(Representational State Transfer)
2000s, Roy Fielding의 논문에서 제시된 웹 아키텍쳐 스타일

REST는 웹의 기본 원칙을 기반으로 자원을 표현하고 상태를 전이하는 방식.

Rest 아키텍쳐 제약조건

제약조건	설명	핵심 효과
1. 클라이언트-서버 구조	프론트엔드와 백엔드 명확히 분리	UI와 처리 로직 분리
2. 무상태(Stateless)	요청마다 모든 정보 포함	수평 확장 용이
3. 캐시 처리 가능(Cacheable)	응답에 캐시 여부 명시	성능 최적화
4. 계층화된 시스템	중간 서버 (게이트웨이, CDN 등) 가능	보안, 확장성 향상
5. 일관된 인터페이스	통합된 방식으로 리소스 접근	REST의 핵심
6. 코드 온 디맨드 (선택적)	JS 등 실행 코드 전송 가능	유연성 (거의 사용 안함)

Rest 설계의 기본 구조

요소	예시	설명
URI	`/users/123`	리소스 식별 (명사형)
HTTP Method	GET / POST / PUT / DELETE	CRUD 동작 정의
Status Code	200, 201, 204, 400, 404, 500 등	처리 결과 명시
Representation	JSON / XML 등	리소스의 형태
Header	`Content-Type`, `Authorization` 등	메타 정보 전달
Query Parameter	`?sort=desc&page=2`	리소스 필터링, 페이지네이션

Rest 장점

장점	설명
단순함	HTTP만 이해하면 누구나 설계·사용 가능
URL 직관성	자원 중심 구조로 이해 쉬움
캐시 및 CDN 활용 용이	HTTP 인프라 자원 그대로 활용
프론트엔드 친화적	JSON 사용 → JS 연동 쉬움
툴링 생태계 풍부	Swagger/OpenAPI, Postman 등 도구 발달

한계와 대응

한계	설명	대응
과다 / 과소 페이로드	필요한 데이터만 받기 어려움	GraphQL 등장
버전 관리 혼란	URI or Header 등 다양한 방식 → 일관성 없음	명확한 정책 필요
상태 관리 어려움	Stateless 구조로 복잡한 워크플로우 불리함	Token · 상태 저장 서버 도입
표현력 한계	복잡한 쿼리 구조 어려움	OData, GraphQL, 필터 DSL 등으로 보완

REST 🆚 RESTful
RESTful : REST아키텍처 스타일의 제약조건을 잘 지켜서 설계된 API를 의미함.

비교 항목	REST	RESTful
정체성	아키텍처 스타일 (이론적)	이를 따른 구체적인 API 구현 (실천적)
출처	2000년 Roy Fielding의 박사논문	REST 개념을 적용한 웹 API 설계 방식
적용 범위	HTTP에 국한되지 않음 (HTTP는 구현 방식 중 하나)	대부분 HTTP 기반 API로 구현
사용 맥락	“REST 기반이다”는 이론적 설명	“RESTful하게 만들었다”는 설계의 적합성 평가

GraphQL (2015~, 클라이언트 주도 쿼리)

배경
- REST API는 고정된 응답 구조를 갖고 있음
- 모바일 앱이나 다양한 프론트엔드 화면은 "필요한 데이터만" 원함
- Over-fetching / Under-fetching 문제 발생
- Facebook이 GraphQL 제안: "필요한 데이터만 선언적으로 요청하게 하자"

특징	설명
단일 엔드포인트	`/graphql` 하나로 모든 데이터 접근
쿼리 기반 요청	클라이언트가 필요한 필드만 선택
타입 시스템 내장	`schema`로 API의 타입과 구조 정의 (SDL)
계층적 요청	한 번의 쿼리로 관계형 데이터를 계층적으로 요청 가능
실시간 처리	`Subscription`으로 웹소켓 기반 실시간 처리 가능

장단점
- 장점
  - 필요한 데이터만 응답
  - 타입이 명확하여 문서화 용이
  - 단일 엔트리 포인트
  - 계층형 구조
- 단점
  - N+1 Query 문제 : 하위 필드를 루프마다 DB 요청하면 성능이 망가짐.
  - REST처러 URL기반 캐싱이 불가함.
  - 쿼리마다 깊이 / 복잡도 제한 안하면 과부하 되고, 보안 문제도 있음
  - Batch/Throttle필요함. 모든 데이터 요청이 Resolver 함수로 가기 때문.
보완
- DataLoader (N+1 문제 해결)
- Persisted Query, Query Whitelisting
- 쿼리 분석 툴: GraphiQL, Apollo Studio
- CDN + Edge 컴퓨팅으로 캐싱 구조 우회
gRPC + Protobuf (2016~, 마이크로 서비스 최적화)
배경
- 마이크로서비스 환경에서 서비스 간 API 호출 빈도 폭증
- REST/JSON은 느리고 텍스트 기반 → 네트워크 낭비
- Google이 내부 RPC 시스템을 오픈소스화 → gRPC + Protobuf

특징	설명
IDL 기반 개발	`.proto` 파일로 서비스 및 메시지 정의
바이너리 직렬화	JSON보다 5~10배 작고 빠른 `Protobuf` 사용
HTTP/2 기반	멀티플렉싱, 스트리밍, 헤더 압축 가능
양방향 스트리밍 지원	실시간 처리에 유리 (서버↔클라이언트 쌍방)
자동 코드 생성	언어별 Stub/Client 자동 생성

장점
- 매우 빠르고 경량화된 통신
- 타입 안정성 → 컴파일 타임 검증 가능
- 스트리밍 처리 → 실시간 데이터 흐름에 적합
- 언어·플랫폼 간 호환성 우수
- 서비스 간 내부 통신에 매우 적합
단점
- 브라우저 사용 불가
- 디버깅 어려움 : JSON이 아니고 바이너리 메시지임
- 표준화 부족
- 캐시 없음
- 보안/게이트웨이 구성 복잡.
활용
- 내부 마이크로서비스 간 통신 (Service Mesh)
- 실시간 데이터 스트림 (IoT, 위치 추적 등)
- 대용량 요청 처리 (ML 모델 호출 등)
- 클라이언트가 Web이 아닌 경우 (모바일 앱, 데스크탑, 서버)

ParkJunHa

PS린이

이전 포스트

[기술 공부] API Fundamentals

다음 포스트