API 아키텍처 — REST · GraphQL · gRPC · WebSocket · SSE · Webhook
같은 과제(주문 3건+고객 이름)를 여섯 방식으로 풀어, 왕복 수·데이터 모양·연결 형태가 어떻게 갈리는지 시퀀스로 비교한다.
1 / 9같은 과제를 여섯 방식으로 풉니다 — "주문 3건과 각 주문의 고객 이름을 보여줘라." 방식마다 왕복 수와 데이터 모양이 다릅니다.
RESTGraphQLgRPCWebSocketSSEWebhook
단계 목록 · 키보드 ←/→ 이동, Space 재생
API 스타일은 우열이 아니라 대화의 모양이다 — 요청/응답(REST·GraphQL·gRPC), 지속 연결(WebSocket·SSE), 서버 간 통지(Webhook) 중 어떤 왕복이 필요한지가 선택을 정한다.
왜 헷갈리는가
"GraphQL이 REST보다 신형이니 낫다", "gRPC가 빠르니 다 gRPC로" 같은 세대론이 혼란의 뿌리다. 여섯은 같은 축의 진화가 아니라 서로 다른 질문에 대한 답이고, 실제 서비스는 보통 서너 개를 함께 쓴다.
애니메이션이 보여주는 것
REST 장면의 왕복 4번(주문 1 + 고객 3)이 언더페칭이다. 필드를 다 담아 한 번에 주면 이번엔 안 쓰는 데이터가 실리는 오버페칭이 된다. GraphQL은 '필요한 모양'을 질의로 선언해 왕복 1번·잉여 0으로 만든다 — 대신 서버 구현·캐싱·보안(쿼리 깊이 제한)이 복잡해진다.
gRPC는 사람이 읽는 텍스트를 포기하고 Protobuf 바이너리 + HTTP/2 + 코드 생성을 얻는다. WebSocket과 SSE는 아예 연결을 열어 두는 쪽이고(양방향 vs 서버→클라 단방향), Webhook은 상대가 브라우저가 아니라 서버일 때의 답이다.
현업 선택 기준
실제 조합의 전형은 이렇다.
- 공개 API·일반 CRUD: REST. HTTP 캐시·CDN·도구 생태계가 그대로 먹힌다.
- 다양한 화면(웹+iOS+Android)이 한 백엔드를 공유: GraphQL(BFF 자리). 화면마다 다른 모양을 서버 배포 없이 만든다.
- 마이크로서비스 내부 호출: gRPC. 계약(proto)에서 코드가 나오고, 지연·크기가 작다.
- 채팅·협업·게임(양쪽이 수시로 말함): WebSocket. 알림·시세·LLM 토큰 스트림(서버만 말함): SSE — 재연결이 공짜고 프록시 친화적.
- 결제 완료·PR 머지 같은 서버 간 이벤트: Webhook + 서명 검증 + 재시도 큐. 받는 쪽 장애를 견디는 설계가 본체다.
면접·설계 리뷰에서 가르는 질문
"누가 대화를 시작하는가, 얼마나 자주인가, 상대는 브라우저인가 서버인가" — 이 세 질문에 답하면 스타일이 거의 정해진다. 스타일을 먼저 고르고 요구를 끼워 맞추는 순간 설계가 뒤집힌다.
기억할 것
- REST=자원+동사, GraphQL=모양 선언, gRPC=계약+바이너리 — 셋 다 요청/응답이다.
- WebSocket=양방향 상시, SSE=서버→클라 단방향 상시 — 연결을 열어 두는 쪽.
- Webhook만 방향이 다르다 — 내 서버가 남의 서버를 부른다.
- 언더페칭/오버페칭이 보이면 GraphQL, 내부 서비스 간이면 gRPC부터 검토.
- 한 서비스가 서너 스타일을 같이 쓰는 것이 정상이다.