상황별 API·통신 기술 선택 가이드

2026.10.01 · 4분

1. 선택 원칙

기술 이름부터 고르지 말고 요구사항을 먼저 문장으로 적습니다.

text

나쁜 출발: gRPC가 빠르다니 사용하자.
좋은 출발: 내부 서비스 호출량이 많고 JSON 직렬화와 계약 불일치가 문제다.

그다음 현재 방식으로 해결 가능한지, 새 기술을 도입할 만큼 문제가 큰지 확인합니다.

일반적인 요청과 응답인가?
- 단순 CRUD라면 REST부터 검토합니다.
- 화면별 데이터 조합이 복잡하다면 GraphQL을 검토합니다.
연결을 유지해야 하는가?
- 서버에서 클라이언트로만 보내면 SSE를 검토합니다.
- 양방향 이벤트가 빈번하면 WebSocket을 검토합니다.
내부 서비스 간 통신인가?
- 단순성과 범용성이 우선이면 REST도 충분합니다.
- 엄격한 타입·고빈도 호출·스트리밍이 중요하면 gRPC를 검토합니다.

회원, 게시글, 권한, 설정을 조회·수정하는 기능이라면 REST가 가장 단순합니다.

http

GET /users
PATCH /users/10
DELETE /posts/20

서비스 수가 적고 호출량이 보통이면 REST로 시작할 수 있습니다. 다음 문제가 반복될 때 gRPC의 가치가 커집니다.

기술을 조합한다면 기능별 기준을 문서로 명확히 둡니다.

text

REST: 영속 데이터 CRUD와 일반 명령
SSE: 서버 작업의 진행 상황
WebSocket: 사용자·기기 간 양방향 실시간 이벤트
gRPC: 백엔드 내부 서비스 호출

경계가 없으면 같은 기능이 여러 방식으로 중복 구현되어 인증, 오류 처리, 모니터링이 복잡해집니다.

통신 기술을 선택해도 이 문제들은 자동으로 해결되지 않습니다.

기술을 결정할 때 다음 문장을 완성해 봅니다.

현재 ___ 문제가 있으며, ___ 요구사항 때문에 ___ 기술을 선택한다. 기존 방식보다 ___가 좋아지고, 대신 ___의 운영 비용을 감수한다.

이 문장을 구체적으로 쓸 수 없다면 새 기술이 아직 필요하지 않을 가능성이 큽니다.

가장 좋은 기술은 기능 수와 관계없이 현재 문제를 필요한 만큼 단순하게 해결하고 팀이 안정적으로 운영할 수 있는 기술이다.