개요
통신을 활용하여 개발하는 개발자라면 API를 활용한 기능 개발을 합니다. 현재 많이 사용되고 있는 통신 방식을 살펴보기 전에 먼저 API가 무엇인지를 알아보겠습니다. 그리고 API에 포함된 처리 방식들을 살펴보고 어떻게 활용하는지 알아보도록 하겠습니다.
API는 Application Programming Interface의 줄임말입니다. 이 인터페이스는 두 소프트웨어가 서로 통신할 방법을 설명하기 위해 고안된 방식입니다. 그렇기 때문에 두 개 이상의 소프트웨어의 통신이 필요할 때 API 개발을 하게 됩니다.
API를 개발하면 회사의 데이터와 기능을 내외부 개발자들이 사용할 수 있습니다. 물론, 인증 절차가 들어가겠지만요.
우리가 흔히 구축하는 방식은 RestAPI는 Web을 기반으로 한 External API입니다. HTTP 프로토콜을 사용하죠.
Internal API는 대표적으로 RPC를 사용합니다.
gRPC는 구글에서 개발한 대표적인 RPC Framework입니다. gRPC는 원래 구글 내에서 마이크로 서비스 간의 통신을 많이 해야 하기 때문에 활용했던 프레임워크로 구글이 오픈 소스로 공개함으로써 다른 기업이나 개인들이 사용하기 좋은 프레임워크로 발전했습니다.
gRPC
앞서 말한 대로 gRPC는 구글에서 만든 오픈 소스 RPC입니다. 전송을 위해서 HTTP/2 를 사용하고 있으며, 쉽고 빠르게 시작 및 확장이 가능한 특징을 가지고 있습니다. 여러 언어 및 플랫폼에서 작동하도록 확장하고 있으며, 양방향 스트리밍 및 통합 인증을 제공하고 있습니다.
간단하게 특징을 정리하겠습니다.
| 기능 | gRPC |
|---|---|
| 계약 | 필수 (.proto) |
| 프로토콜 | HTTP/2 |
| 페이로드(데이터 교환 형식) | Protobuf (small, binary) |
| 규범 | 엄격한 사양 |
| 스트리밍 | 클라이언트, 서버, 양방향 |
| 브라우저 지원 | 아니요 (gRPC-웹 필요) |
마이크로 서비스 아키텍처를 구성할 때 내부의 어플리케이션끼리 통신하기 용이하도록 만든 것이기 때문에 그와 비슷한 기능을 만들 때 활용할 수 있습니다. 대표적으로 서로 다른 내부 애플리케이션 통신을 빠르고 안전하게 할 때 활용합니다. gRPC가 제공하는 가장 대표적인 기능이 streaming이기 때문이죠. 그리고 대량의 데이터 같은 경우 Rest 보다 7배 빠른 프로토콜 버퍼를 쓴다고 구글에서 이야기합니다.
클라이언트가 서로 다른 언어로 되어 있더라도, 새롭게 라이브러리를 작성하지 않아도 됩니다. 이미 서버에 구현된 프로토콜 버퍼를 해당 언어에 맞게 배포하면 되기 때문이죠.
그렇다면 gRPC를 활용하는 경우는 언제일까요?
- 마이크로 서비스 스타일 아키텍처에서 다양한 언어로 구성된 서비스를 연결할 때
- 모바일과 백엔드 서버를 연결할 때
- 스트리밍 요청 또는 응답을 처리해야 하는 실시간 서비스를 연결할 때
위와 같은 상황에서 사용하면 좋습니다. 제가 다녔던 이전 게임 회사에서도 게임 서버와 클라이언트 모바일과 연결할 때 gRPC를 활용했었습니다. 그래서 제가 만든 운영툴과 연결할 때도 gRPC를 통한 연결을 하기도 했었습니다. 물론 REST로 해도 되지만 서버 개발자의 추가 리소스가 필요했기에 제가 gRPC를 학습하고 연결하는 과정을 거쳤었죠.
이와 항상 비교되는 표준은 WebSocket입니다. 가장 많이 사용되는 곳은 채팅으로 실시간 업데이트, 라이브 스코어 업데이트, 뉴스피드와 같은 기능에서 활용됩니다. 이 내용은 gRPC vs WebSocket을 다룰 때 이야기 하겠습니다. 각각의 장단점이 명확하고 언제 사용해야 하는지가 중요합니다.
gRPC는 간단하게 정리하도록 하고 Rest에 대해 이야기해 보죠.
REST
Rest는 여러분들이 잘 알고 있는 웹 서버 개발자가 가장 많이 개발하는 API입니다.
Web API의 한 종류로 REST 디자인 프린시플을 따르는 API를 REST API라고 합니다.
REST는 Representational State Transfer Architectural Style의 줄임말이죠.
2000년도에 최초로 등장하였고, 개발자에게 높은 자유도를 보장해 줍니다. 덕분에 많은 Component 들을 연결하거나 마이크로 서비스 아키텍처에서 많이 사용되었습니다.
클라이언트, 서버, 리소스, 표현(Representation)으로 구성되어 있죠.
가장 많이 사용되는 데이터 형식은 JSON입니다.
그래서 서버와 클라이언트가 REST API로 통신할 때 가장 먼저 정의하는 것이 JSON 스펙 정의 입니다. 정의된 JSON 스펙에 따라 각각의 개발자들은 개발을 시작할 수 있으며, 서로 커뮤니케이션하면서 개발을 진행하고 기능을 만들게 됩니다.
앞서 REST API에 대한 설명을 적어놨습니다. 한번 참고하시면 좋겠습니다.
GraphQL
GraphQL은 애플리케이션 프로그래밍 인터페이스를 위한 쿼리 언어이자 서버 측 런타임으로 클라이언트에게 요청한 만큼의 데이터를 제공하는 데 우선순위를 둡니다. 기존에 있던 REST보다 더욱 빠르고 유연하며, 개발자 친화적으로 만들기 위해 설계되었습니다.
Rest를 대체할 수 있는 GraphQL은 개발자가 단일 API 호출로 다양한 데이터 소스에서 데이터를 끌어오는 요청을 구성할 수 있도록 지원합니다. 그러면 Rest보다 좋다고 하는 이유는 무엇이고, 왜 이런 기술을 만들었는지 알아야 합니다.
Rest의 한계
Rest API의 장점은 서버와 클라이언트을 독립적으로 개발이 가능했습니다. 시간이 지나다 보니 점점 클라이언트 코드가 복잡해지고, End-Point가 늘어나면서 복잡성이 높아지기 시작했습니다. 개발만 한다고 되는 것이 아닌 의존성 핸들링을 위해 코드가 추가되고, 유틸 함수들이 늘어나게 됩니다.
이것은 문서화 이슈도 발생합니다. Swagger 같은 툴이 있지만 이 툴을 이용해서 문서화를 하는 것조차도 리소스가 많이 필요합니다. 그러다 보니 커뮤니케이션 비용이 계속해서 증가하고, 문서화에 소홀히 하는 경우가 생깁니다. 그러면 정보가 불충분하여 문제가 생기는 경우도 있습니다.
이런 한계를 가진 REST를 개선하기 위해서 GraphQL 이란 애플리케이션 레이어 쿼리 언어가 생성되었습니다.
GraphQL 장점
FE에서 필요한 최소한의 정보만 별도 요청이 가능합니다. 그래서 효율이 오르고 각 장비에서의 퍼포먼스를 향상 가능합니다. HTTP 요청 횟수를 줄일 수 있죠. 그리고 REST는 JSON을 통해 데이터를 전송합니다. 그 안에 타입 정의는 딱히 없습니다. 하지만 GraphQL은 데이터 유형 정의가 엄격하여 클라와 서버 간 통신 오류를 줄여줍니다. 대표적인 예시로 숫자를 String으로 받을지 Number로 받을지 소통하지 않으면 모릅니다. 그러면 당연히 Number로 올 것이라 예상한 팀에서는 String을 받는 순간 에러가 발생하고 하죠. 이런 단점을 상쇄한 것이 GraphQL입니다.
다른 장점으로는 REST는 Resource 종류별로 요청을 해야 하며, 그렇기에 요청 횟수가 필요한 Resource 종류에 비례해서 증가하게 됩니다. GraphQL은 원하는 정보를 하나의 Query에 모두 담아 요청이 가능하죠. 즉, HTTP 응답 size를 줄일 수 있습니다.
GraphQL은 애플리케이션 API가 기존 쿼리를 중단하지 않고도 배포가 가능합니다. 마지막으로 Over-Fetching과 Under-Fetching을 개선합니다.
여기서 나오는 Over-Fetching과 Under-Fetching은 알아둘 필요가 있습니다. REST의 한계이기 때문이죠.
Fetch는 웹 페이지를 구성에 필요한 다양한 요청을 의미합니다. 데이터를 받아오기 위한 작업을 뜻합니다. 그렇다면 Over-Fetching은 무엇일까요? 바로 필요한 데이터 이상을 서버에서 데이터를 받아오는 것을 의미합니다.
특정 API 요청에서 내가 필요한 정보는 3개인데 받는 정보는 10개가 넘어간다면 이걸 Over-Fetching이라고 합니다. 그래서 네트워크 리소스를 의미 없이 잡아먹는 경우가 생기죠. 이것이 한, 두개이면 괜찮지만 요청 개수가 초당 몇백 개만 넘어가도 요청 속도에 부하가 생기곤 합니다.
Under-Fetching은 한 번의 요청에 필요한 데이터를 모두 받아오지 못해 여러 번 요청을 수행하는 것을 의미합니다. 여러 번의 요청을 더욱 좋지 않은데, 하나의 화면을 만들기 위해 서버에 요청하는 Request 개수가 많아지면 네트워크 지연이 눈에 보일 정도로 늘어납니다. 그렇기 때문에 한번 요청에 클라이언트가 만족할 만큼의 데이터를 전달해야 하는데 그렇지 못한 상황을 Under-Fetching이라고 하죠.
이런 상황을 최대한 줄이는 것이 GraphQL이라고 보시면 됩니다.
GraphQL 단점
장점만 있는 게 아니겠죠? 가장 먼저 나오는 단점은 File 전송과 같은 Text 기반의 전송이 아닌 요청은 작업 처리가 복잡합니다. 그리고 Caching 기능이 REST보단 복잡하죠. 그리고 고정된 요청과 응답만 필요한 경우가 있습니다. 그리고 데이터 쿼리의 상당 작업들이 서버 측에서 처리하기 때문에 서버 개발자 작업의 복잡성이 증가합니다. 결국, 서버 개발자가 해야 할 일이 많아집니다. REST API는 서버 개발자들이라면 쉽고 빠르게 작성할 수 있는 반면 GraphQL은 학습 시간이 필요하면서 지속적인 관리 비용이 REST 보다 많습니다.
마무리
이 글에서 다양한 API에 대한 내용을 다뤘습니다. 가장 많이 사용하는 것은 REST지만 상황에 따라 GraphQL, gRPC 등 다른 선택지도 있다는 것을 알아야 합니다. 개발자는 문제를 해결할 때, 선택을 해야 합니다. 가장 효율적인 처리 방식이 무엇인지 말이죠.
저는 아직 GraphQL과 gRPC를 현업에서는 사용하진 않았습니다. 그렇기에 한번 경험이 필요해 보이네요. 어떤 문제든