gRPC vs REST API: 백엔드 아키텍처 선택 가이드

현대 소프트웨어 개발에서 백엔드 서버는 다양한 클라이언트와 시스템 간의 데이터 통신을 담당하는 핵심 요소입니다. 이러한 통신을 위한 API(Application Programming Interface) 설계는 시스템의 성능, 확장성, 그리고 유지보수성에 지대한 영향을 미칩니다. 특히 REST API와 gRPC는 백엔드 아키텍처를 구축할 때 가장 널리 고려되는 두 가지 강력한 기술입니다. 이 글에서는 두 기술의 근본적인 차이점과 특징을 비교하고, Node.js 환경에서의 예시를 통해 어떤 상황에서 어떤 API가 더 적합한지 심도 있게 분석해 보겠습니다.

REST API의 이해와 특징

REST(Representational State Transfer)는 웹 서비스를 위한 아키텍처 스타일로, HTTP 프로토콜을 기반으로 합니다. 2000년대 초반부터 웹 서비스의 표준처럼 자리 잡았으며, 현재까지도 가장 널리 사용되는 API 스타일 중 하나입니다.

REST API는 다음과 같은 주요 원칙을 따릅니다.

• 클라이언트-서버(Client-Server): 클라이언트와 서버의 역할이 명확히 분리되어 독립적으로 발전할 수 있습니다.
• 무상태(Stateless): 서버는 클라이언트의 요청 간 상태를 저장하지 않습니다. 각 요청은 필요한 모든 정보를 포함해야 합니다.
• 캐시 가능(Cacheable): 클라이언트는 응답을 캐싱하여 네트워크 부하를 줄일 수 있습니다.
• 계층화된 시스템(Layered System): 클라이언트는 직접 서버와 통신하는지, 중간 서버와 통신하는지 알 수 없습니다.
• 균일한 인터페이스(Uniform Interface): 리소스에 대한 접근 방식이 통일되어 있습니다. (예: GET, POST, PUT, DELETE와 같은 HTTP 메서드 사용)

장점:

• 단순성 및 범용성: HTTP 표준을 따르므로 이해하고 구현하기 쉽습니다. 웹 브라우저와의 호환성이 뛰어납니다.
• 사람이 읽기 쉬운 형식: JSON 또는 XML과 같은 텍스트 기반 형식으로 데이터를 주고받아 디버깅이 용이합니다.
• 낮은 학습 곡선: 웹 개발자라면 대부분 익숙한 기술 스택을 활용할 수 있습니다.

단점:

• 오버 페칭(Over-fetching) 및 언더 페칭(Under-fetching): 필요한 데이터보다 더 많은 데이터를 받거나(오버 페칭), 여러 번의 요청을 통해 데이터를 가져와야 하는 경우(언더 페칭)가 발생할 수 있습니다.
• 성능 오버헤드: 텍스트 기반의 데이터 포맷과 HTTP/1.1의 헤더 중복 등으로 인해 효율성이 떨어질 수 있습니다.
• API 버전 관리의 복잡성: API 변경 시 클라이언트 호환성 유지를 위한 버전 관리가 필요합니다.

Node.js에서 Express.js를 이용한 간단한 REST API 서버 예시는 다음과 같습니다.

// app.js
const express = require('express');
const app = express();
const PORT = 3000;

app.use(express.json()); // JSON 요청 본문 파싱

let products = [
    { id: 1, name: 'Laptop', price: 1200 },
    { id: 2, name: 'Mouse', price: 25 }
];

// 모든 제품 조회
app.get('/products', (req, res) => {
    res.json(products);
});

// 특정 제품 조회
app.get('/products/:id', (req, res) => {
    const product = products.find(p => p.id === parseInt(req.params.id));
    if (product) {
        res.json(product);
    } else {
        res.status(404).send('Product not found');
    }
});

// 새 제품 추가
app.post('/products', (req, res) => {
    const newProduct = {
        id: products.length + 1,
        name: req.body.name,
        price: req.body.price
    };
    products.push(newProduct);
    res.status(201).json(newProduct); // 201 Created
});

app.listen(PORT, () => {
    console.log(`REST API Server running on http://localhost:${PORT}`);
});

gRPC의 이해와 특징

gRPC(Google Remote Procedure Call)는 Google에서 개발한 오픈소스 고성능 RPC(Remote Procedure Call) 프레임워크입니다. REST API가 HTTP 프로토콜 위에 데이터를 전송하는 반면, gRPC는 Protocol Buffers(Protobuf)를 사용하여 데이터를 직렬화하고 HTTP/2를 통신 프로토콜로 사용합니다.

주요 특징:

• Protocol Buffers: 언어 중립적, 플랫폼 중립적인 직렬화 메커니즘으로, JSON보다 훨씬 작고 빠르게 데이터를 직렬화/역직렬화합니다. .proto 파일에 서비스 인터페이스와 메시지 구조를 정의합니다.
• HTTP/2: 단일 TCP 연결을 통해 여러 요청을 동시에 처리하는 멀티플렉싱, 헤더 압축, 서버 푸시 등을 지원하여 REST API의 HTTP/1.1보다 훨씬 효율적인 통신을 제공합니다.
• 코드 생성(Code Generation): .proto 파일을 기반으로 다양한 프로그래밍 언어(Node.js, Java, Python, Go 등)의 클라이언트 및 서버 스텁 코드를 자동으로 생성합니다. 이는 개발 생산성을 높이고, 런타임 오류를 줄여줍니다.
• 스트리밍(Streaming): 단방향(서버 스트리밍, 클라이언트 스트리밍) 및 양방향 스트리밍을 기본으로 지원하여 실시간 통신 및 대용량 데이터 처리에 유리합니다.

장점:

• 높은 성능 및 효율성: Protocol Buffers와 HTTP/2 덕분에 데이터 전송량과 지연 시간이 크게 줄어듭니다.
• 강력한 타입 체크: Protobuf를 통해 서비스 계약이 명확해지며, 컴파일 시점에 타입 오류를 감지할 수 있습니다.
• 다국어 지원: 다양한 언어로 자동 생성되는 코드는 마이크로서비스 아키텍처에서 여러 언어로 개발된 서비스 간의 통합을 용이하게 합니다.
• 스트리밍 지원: 실시간 통신, IoT 기기, 장시간 연결이 필요한 애플리케이션에 적합합니다.

단점:

• 높은 학습 곡선: Protobuf 정의, 코드 생성 등 REST에 비해 새로운 개념과 도구에 대한 이해가 필요합니다.
• 브라우저 지원 부족: 웹 브라우저에서 gRPC를 직접 호출하기 어렵습니다 (gRPC-Web과 같은 추가 계층 필요).
• 가독성 부족: 바이너리 데이터 형식이라 사람이 직접 읽기 어렵습니다.

Node.js에서 gRPC 서버를 구현하기 위한 .proto 파일 정의와 서버 코드의 예시는 다음과 같습니다.

// product.proto
syntax = "proto3";

package product;

service ProductService {
    rpc GetProduct (GetProductRequest) returns (ProductResponse);
    rpc CreateProduct (CreateProductRequest) returns (ProductResponse);
    rpc ListProducts (Empty) returns (ListProductsResponse); // 모든 제품 조회
}

message GetProductRequest {
    int32 id = 1;
}

message CreateProductRequest {
    string name = 1;
    double price = 2;
}

message ProductResponse {
    int32 id = 1;
    string name = 2;
    double price = 3;
}

message ListProductsResponse {
    repeated ProductResponse products = 1; // repeated 키워드로 배열 정의
}

message Empty {} // 빈 메시지 (인자 없는 요청에 사용)

// grpc_server.js
const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');
const PROTO_PATH = './product.proto';

// Protobuf 파일 로드
const packageDefinition = protoLoader.loadSync(PROTO_PATH, {
    keepCase: true,
    longs: String,
    enums: String,
    defaults: true,
    oneofs: true
});
const productProto = grpc.loadPackageDefinition(packageDefinition).product;

let products = [
    { id: 1, name: 'Laptop', price: 1200.0 },
    { id: 2, name: 'Mouse', price: 25.0 }
];

// gRPC 서비스 구현
const productServiceImpl = {
    GetProduct: (call, callback) => {
        const product = products.find(p => p.id === call.request.id);
        if (product) {
            callback(null, product);
        } else {
            callback({
                code: grpc.status.NOT_FOUND,
                details: "Product not found"
            });
        }
    },
    CreateProduct: (call, callback) => {
        const newProduct = {
            id: products.length + 1,
            name: call.request.name,
            price: call.request.price
        };
        products.push(newProduct);
        callback(null, newProduct);
    },
    ListProducts: (call, callback) => {
        callback(null, { products: products });
    }
};

function main() {
    const server = new grpc.Server();
    server.addService(productProto.ProductService.service, productServiceImpl);
    server.bindAsync('0.0.0.0:50051', grpc.ServerCredentials.createInsecure(), (err, port) => {
        if (err) {
            console.error(err);
            return;
        }
        server.start();
        console.log(`gRPC server running on port ${port}`);
    });
}

main();

핵심 기술 비교: REST vs gRPC

REST API와 gRPC는 백엔드 API 설계에 있어 근본적으로 다른 접근 방식을 취합니다. 다음 표는 두 기술의 주요 차이점을 요약한 것입니다.

특징	REST API (HTTP/1.1 기반)	gRPC (HTTP/2 기반)
통신 프로토콜	HTTP/1.1 (기본)	HTTP/2
데이터 직렬화	JSON, XML, 텍스트 (사람이 읽기 쉬움)	Protocol Buffers (바이너리, 고성능)
API 정의 언어	OpenAPI/Swagger (선택 사항)	Protocol Buffers IDL (.proto 파일)
데이터 전송 방식	Request-Response (단방향)	Unary, Server Streaming, Client Streaming, Bidirectional Streaming (다양한 스트리밍 지원)
코드 생성	수동 또는 부분적인 도구 지원	.proto 파일 기반 자동 생성 (다국어 지원)
성능 및 효율성	비교적 낮음 (텍스트 기반, 헤더 오버헤드)	매우 높음 (바이너리, HTTP/2 멀티플렉싱, 헤더 압축)
타입 안전성	런타임 시점에 검증 (스키마 유효성 검사 필요)	컴파일 시점에 강한 타입 체크
브라우저 호환성	우수 (직접 호출 가능)	부족 (gRPC-Web 게이트웨이 필요)
학습 곡선	낮음	높음

아키텍처 다이어그램으로 보는 활용 시나리오

두 API 스타일은 시스템 아키텍처 내에서 각기 다른 역할을 수행할 때 최적의 성능을 발휘합니다.

REST API 아키텍처 (공개 API 및 웹 서비스)

REST API는 주로 웹 브라우저나 모바일 앱과 같은 외부 클라이언트와의 통신, 그리고 공개적으로 제공되는 API 게이트웨이에 적합합니다.

[웹/모바일 클라이언트]
       |
       |  HTTP/1.1 (JSON)
       v
[API 게이트웨이]
       |
       |  HTTP/1.1 (JSON)
       v
[백엔드 서비스 A] <---> [데이터베이스]
       |
       |  HTTP/1.1 (JSON)
       v
[백엔드 서비스 B]

• 설명: 클라이언트는 API 게이트웨이를 통해 백엔드 서비스에 접근합니다. 게이트웨이는 요청을 적절한 백엔드 서비스로 라우팅하며, 모든 통신은 HTTP/1.1과 JSON을 기반으로 이루어집니다. 이 구조는 범용적인 웹 서비스, 서드파티 연동, 그리고 개발 편의성이 중요한 프로젝트에 적합합니다.

gRPC 아키텍처 (마이크로서비스 및 고성능 내부 통신)

gRPC는 주로 마이크로서비스 간의 내부 통신, 고성능이 요구되는 백엔드 시스템, 그리고 IoT 기기와의 통신에 강점을 가집니다.

[클라이언트 (웹/모바일)]  <--- HTTP/1.1 (JSON) ---> [gRPC-Web 게이트웨이]
                                                        |
                                                        |  HTTP/2 (ProtoBuf)
                                                        v
                                                   [마이크로서비스 A] <--- HTTP/2 (ProtoBuf) ---> [마이크로서비스 B]
                                                        |                                                |
                                                        |  HTTP/2 (ProtoBuf)                             v
                                                        v                                          [데이터베이스 B]
                                                   [마이크로서비스 C] <---> [데이터베이스 A]

• 설명: 외부 클라이언트는 REST API 또는 gRPC-Web 게이트웨이를 통해 시스템에 접근하고, 게이트웨이 내부에서는 고성능 gRPC를 사용하여 마이크로서비스 간에 통신합니다. 이는 서비스 간의 효율적인 데이터 교환을 가능하게 하며, 시스템 전체의 응답 시간을 단축시킵니다.

Node.js 백엔드에서의 구현 예시

실제 Node.js 백엔드 개발 시 REST와 gRPC를 어떻게 활용할 수 있는지 간단한 코드 예시를 통해 살펴보겠습니다.

REST API 예시 (Express.js)

Express.js는 Node.js에서 REST API를 구축하는 데 가장 널리 사용되는 프레임워크입니다.

// rest_server.js
const express = require('express');
const app = express();
const PORT = 3001;

app.use(express.json());

let items = [
    { id: 1, name: 'Item A', description: 'Description for A' },
    { id: 2, name: 'Item B', description: 'Description for B' }
];

// GET /items - 모든 아이템 조회
app.get('/items', (req, res) => {
    res.json(items);
});

// GET /items/:id - 특정 아이템 조회
app.get('/items/:id', (req, res) => {
    const item = items.find(i => i.id === parseInt(req.params.id));
    if (item) {
        res.json(item);
    } else {
        res.status(404).send('Item not found');
    }
});

// POST /items - 새 아이템 생성
app.post('/items', (req, res) => {
    const newItem = {
        id: items.length + 1,
        name: req.body.name,
        description: req.body.description
    };
    items.push(newItem);
    res.status(201).json(newItem);
});

app.listen(PORT, () => {
    console.log(`REST API Server running on http://localhost:${PORT}`);
});

gRPC 예시 (grpc-js)

Node.js에서 gRPC를 사용하려면 @grpc/grpc-js와 @grpc/proto-loader 라이브러리가 필요합니다.

먼저 .proto 파일을 정의합니다 (item.proto).

// item.proto
syntax = "proto3";

package item;

service ItemService {
    rpc GetItem (GetItemRequest) returns (ItemResponse);
    rpc CreateItem (CreateItemRequest) returns (ItemResponse);
    rpc ListItems (Empty) returns (ListItemsResponse);
}

message GetItemRequest {
    int32 id = 1;
}

message CreateItemRequest {
    string name = 1;
    string description = 2;
}

message ItemResponse {
    int32 id = 1;
    string name = 2;
    string description = 3;
}

message ListItemsResponse {
    repeated ItemResponse items = 1;
}

message Empty {}

다음은 gRPC 서버 코드입니다.

// grpc_server.js
const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');
const PROTO_PATH = './item.proto';

const packageDefinition = protoLoader.loadSync(PROTO_PATH, {
    keepCase: true,
    longs: String,
    enums: String,
    defaults: true,
    oneofs: true
});
const itemProto = grpc.loadPackageDefinition(packageDefinition).item;

let items = [
    { id: 1, name: 'Item A', description: 'Description for A' },
    { id: 2, name: 'Item B', description: 'Description for B' }
];

const itemServiceImpl = {
    GetItem: (call, callback) => {
        const item = items.find(i => i.id === call.request.id);
        if (item) {
            callback(null, item);
        } else {
            callback({
                code: grpc.status.NOT_FOUND,
                details: "Item not found"
            });
        }
    },
    CreateItem: (call, callback) => {
        const newItem = {
            id: items.length + 1,
            name: call.request.name,
            description: call.request.description
        };
        items.push(newItem);
        callback(null, newItem);
    },
    ListItems: (call, callback) => {
        callback(null, { items: items });
    }
};

function main() {
    const server = new grpc.Server();
    server.addService(itemProto.ItemService.service, itemServiceImpl);
    server.bindAsync('0.0.0.0:50052', grpc.ServerCredentials.createInsecure(), (err, port) => {
        if (err) {
            console.error(err);
            return;
        }
        server.start();
        console.log(`gRPC server running on port ${port}`);
    });
}

main();

REST와 gRPC, 언제 무엇을 선택할까?

두 기술 모두 강력한 장점을 가지고 있으므로, 프로젝트의 특정 요구사항과 제약 조건에 따라 적절한 선택을 해야 합니다.

REST API가 더 유리한 경우:

• 공개 API 또는 외부 클라이언트 연동: 웹 브라우저나 모바일 앱 등 다양한 외부 클라이언트에서 쉽게 접근해야 하는 공개 API를 구축할 때 적합합니다.
• 개발 용이성 및 빠른 프로토타이핑: HTTP와 JSON에 익숙한 개발자들이 많아 빠르게 개발하고 테스트할 수 있습니다.
• 간단한 CRUD(Create, Read, Update, Delete) 작업: 리소스 기반의 간단한 데이터 조작에 최적화되어 있습니다.
• 브라우저 호환성: 웹 브라우저에서 직접 호출할 수 있어 프론트엔드 통합이 용이합니다.

gRPC가 더 유리한 경우:

• 마이크로서비스 간 통신: 서비스 간의 내부 통신에서 높은 성능과 효율성이 필요할 때 이상적입니다.
• 고성능 및 저지연 통신: 실시간 데이터 처리, 대용량 데이터 스트리밍, IoT 기기 통신 등 성능이 critical한 애플리케이션에 적합합니다.
• 다국어 환경의 개발: 여러 프로그래밍 언어로 개발된 서비스 간의 통합이 필요할 때 코드 자동 생성 기능이 큰 이점을 제공합니다.
• 엄격한 API 계약 및 타입 안전성: Protobuf를 통한 명확한 인터페이스 정의는 시스템의 안정성과 유지보수성을 높입니다.
• 양방향 스트리밍 필요: 채팅 애플리케이션, 실시간 알림 시스템 등 양방향 통신이 필요한 경우에 강력합니다.

마무리

REST API와 gRPC는 각각의 장단점을 가진 강력한 백엔드 API 기술입니다. REST API는 범용적인 웹 서비스와 공개 API 구축에 여전히 탁월한 선택이며, gRPC는 마이크로서비스 아키텍처 내의 고성능 내부 통신 및 실시간 데이터 처리에 혁신적인 솔루션을 제공합니다. 프로젝트의 특성, 성능 요구사항, 개발 팀의 숙련도 등을 종합적으로 고려하여 가장 적합한 API 스타일을 선택하는 것이 성공적인 백엔드 시스템 구축의 핵심입니다.