# gRPC, OpenAPI 및 REST 이해와 API 설계에서의 활용 시기 (2020)

> Clean Markdown view of GeekNews topic #18879. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=18879](https://news.hada.io/topic?id=18879)
- GeekNews Markdown: [https://news.hada.io/topic/18879.md](https://news.hada.io/topic/18879.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-01-24T09:57:04+09:00
- Updated: 2025-01-24T09:57:04+09:00
- Original source: [cloud.google.com](https://cloud.google.com/blog/products/api-management/understanding-grpc-openapi-and-rest-and-when-to-use-them)
- Points: 1
- Comments: 1

## Topic Body

### API 관리

#### gRPC와 REST: API 설계에서 gRPC, OpenAPI, REST의 이해와 사용 시점

- **API 설계 모델**: API 설계에는 주로 RPC와 REST 두 가지 모델이 사용됨. 대부분의 현대 API는 HTTP 프로토콜을 기반으로 구현됨.
- **gRPC**: HTTP 2.0을 전송 프로토콜로 사용하는 RPC API 구현 기술. Google 등에서 RPC와 HTTP의 아이디어를 결합한 API를 많이 사용함.
- **HTTP의 세 가지 주요 사용 방식**:
  1. **REST**: 클라이언트가 서버에서 제공하는 URL을 그대로 사용하며, URL 형식을 이해할 필요가 없음.
  2. **gRPC**: HTTP/2를 사용하지만, HTTP는 API 설계자에게 노출되지 않음.
  3. **OpenAPI**: 클라이언트가 URL 경로 템플릿을 사용하여 API를 호출함.

#### REST

- **특징**: 클라이언트가 URL 형식을 이해할 필요가 없으며, URL은 API 사양의 일부가 아님.
- **장점**: 안정성, 일관성, 보편성 등 웹의 장점을 가짐. 엔티티 지향 모델이 더 간단하고 이해하기 쉬움.

#### gRPC

- **특징**: HTTP/2를 사용하지만, HTTP의 세부 사항은 숨겨짐. 클라이언트는 절차를 호출하고 매개변수를 전달하여 API를 사용함.
- **장점**: 클라이언트 측 프로그래밍 라이브러리를 쉽게 생성할 수 있으며, 성능이 좋음.

#### OpenAPI

- **특징**: URL 경로 템플릿을 사용하여 API를 호출하며, 클라이언트가 URL 형식을 이해해야 함.
- **장점**: 표준 HTTP 기술만으로 API에 접근 가능. 클라이언트 측 프로그래밍 라이브러리를 생성할 수 있음.

#### gRPC와 OpenAPI의 비교

- **유사점**: 둘 다 RPC 인터페이스 정의 언어(IDL)로 사용 가능.
- **차이점**: gRPC는 HTTP 세부 사항을 숨기고, OpenAPI는 HTTP 세부 사항을 노출함.

#### REST의 장점

- **엔티티 지향 모델**: 더 간단하고 이해하기 쉬우며, 시간이 지나도 안정적임.

#### OpenAPI 사용 방법

- **경로 정의**: 경로와 HTTP 메서드를 사용하여 API를 정의함.

#### OpenAPI의 장단점

- **장점**: RPC 모델과 유사하여 프로그래머에게 친숙함. HTTP 요청으로 매핑할 수 있음.
- **단점**: HTTP 세부 사항을 설계하는 데 많은 노력이 필요함.

#### gRPC의 장점

- **간단한 구현**: 서버 측 구현이 간단하며, 클라이언트 측 라이브러리를 쉽게 생성할 수 있음.
- **성능**: 이진 페이로드를 사용하여 효율적임.

#### gRPC의 단점

- **특수 소프트웨어 필요**: 클라이언트와 서버 모두 특수 소프트웨어가 필요함.
- **프록시 기능 제한**: HTTP API와 달리 프록시에서 기능을 확장하거나 수정하기 어려움.

#### 결론

- **API 설계 선택**: REST, OpenAPI, gRPC 각각의 장단점을 고려하여 선택해야 함.
- **gRPC 사용 시 고려 사항**: 클라이언트가 gRPC 기술을 채택하지 않아도 되는 경우, 내부 API인 경우 유리함.

## Comments



### Comment 33802

- Author: neo
- Created: 2025-01-24T09:57:05+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=42799245) 
- gRPC를 배우지 말았어야 했다는 후회가 있음. 디버깅과 설정 조정에 많은 시간이 소요되었음
  - gRPC는 내부를 숨긴다고 하지만, 실제로는 많은 디버깅과 설정 조정이 필요함
  - Maven 플러그인, HTTP2와의 호환성 문제, 방화벽 문제 등으로 많은 시간을 낭비했음
  - 문서가 부실하고, 오류 메시지를 관찰 가능하게 만드는 데 어려움이 있었음

- 오랫동안 API를 구축해왔으며, gRPC와 HTTP/REST를 사용해왔음
  - OpenAPI와 REST의 차이를 구분하는 것이 이상하다고 생각함
  - OpenAPI는 HTTP API의 동작을 문서화하는 방법이며, RESTful API를 표현할 수 있음
  - gRPC는 프로토콜 버퍼를 주고받는 RPC 메커니즘임
  - gRPC는 효율적이지만, HTTP 라이브러리만큼 강력하지 않음

- FAANG에서 일한 경험이 있으며, 내부 서비스 라우팅에 gRPC가 유용하다고 생각함
  - RPC 프로토콜은 대규모 및 고속으로 작업을 가능하게 함
  - 그러나 고객이나 웹을 대상으로 하는 경우에는 gRPC를 사용하지 않을 것임

- 양방향 스트리밍을 하지 않는 한, gRPC는 시간 낭비라고 생각함
  - 다양한 언어로 구현된 서비스 간의 RPC 호출을 할 때 많은 미들웨어가 필요함

- gRPC를 사용한 프로젝트에서 성능을 이유로 도입했으나, JSON API로 전환했음
  - gRPC에 대한 경험이 부족했고, 프로젝트는 여러 문제로 인해 실패했음

- connectrpc를 사용하면서 gRPC의 문제점을 해결하고 있음
  - buf.build를 통해 3rd party proto 파일을 쉽게 가져올 수 있음
  - SDK 자동 생성 기능이 매우 유용함

- gRPC는 REST보다 개발 경험이 나쁘다고 생각함
  - 추가적인 도구가 필요하고, 생성된 클라이언트 코드가 복잡함

- REST API는 초기 URI와 표준화된 미디어 타입만 알면 된다고 Roy Fielding이 언급함

- 데이터 센터 내에서 gRPC 사용을 좋아하지 않음
  - 성능이 높지 않고, 오픈 소스 클라이언트의 품질이 낮음
  - 웹 기반 API에서는 JSON의 가독성을 선호하지만, 타입 불일치 문제가 있음

- gRPC는 Google 외부에서는 접근하기 어렵다고 느꼈음
  - gRPC JS 클라이언트가 무겁고 불투명함
  - REST의 단순함에 비해 실행이 잘못되었다고 생각함