TypeScript 풀스택 프로젝트에서 API 레이어를 어떻게 설계할지는 항상 팀 토론을 불러온다. REST는 오래됐지만 여전히 강력하고, GraphQL은 복잡한 데이터 요구사항을 우아하게 풀지만 보일러플레이트가 많다. 그리고 tRPC는 TypeScript 단일 코드베이스에서 타입 안정성을 극한으로 끌어올린다. 2026년 현재 실무에서 세 가지를 모두 사용해본 경험을 바탕으로 비교한다.
📋 목차
⚡ tRPC vs REST vs GraphQL 한눈에 비교
| 항목 | tRPC | REST | GraphQL |
|---|---|---|---|
| 타입 안정성 | 🏆 자동 (E2E) | 수동 (OpenAPI) | 스키마 기반 |
| 학습 곡선 | 🏆 낮음 | 🏆 낮음 | 높음 |
| 보일러플레이트 | 🏆 최소 | 중간 | 많음 |
| 클라이언트 유연성 | TypeScript만 가능 | 🏆 모든 클라이언트 | 🏆 모든 클라이언트 |
| Over-fetching 방지 | 보통 | ❌ 취약 | 🏆 완벽 |
| 캐싱 | React Query 통합 | 🏆 HTTP 캐싱 | 복잡 |
| 서드파티 연동 | 어려움 | 🏆 쉬움 | 중간 |
| 적합한 팀 규모 | 소규모 (풀스택 TS) | 모든 규모 | 중~대규모 |
🌐 REST — 여전히 왕좌에 있는 이유
REST는 2026년에도 가장 널리 쓰이는 API 패턴이다. 이유는 단순하다. 모든 클라이언트가 HTTP를 이해하고, 모든 개발자가 REST를 안다. curl로 테스트할 수 있고, Postman으로 문서화되며, 어떤 언어로도 호출 가능하다.
REST의 강점
- 표준화: HTTP 메서드(GET, POST, PUT, DELETE)와 상태 코드가 명확한 의미를 가진다.
- 캐싱: HTTP 레이어의 캐싱(CDN, 브라우저 캐시)을 그대로 활용할 수 있다. GET 요청은 CDN에서 캐싱되어 백엔드 부하를 크게 줄인다.
- 서드파티 연동: 외부 서비스(결제, 인증, SMS 등)는 대부분 REST API를 제공한다.
- 팀 온보딩: 신입 개발자도 REST는 이미 안다. 학습 비용이 없다.
REST의 한계
- Over-fetching과 Under-fetching이 고윈적인 문제다. 사용자 프로필 즌이핀 `/users/1`, `/users/1/posts`, `/users/1/followers` 세 문제을 생황이 생긴다. 리의 타입 안정성이 OpenAPI/Swagger 스키마 를 수동으로 관리해야 하므로 코드와 스키마가 분리되는 문제가 있다.
- N+1 문제: N <Ĭ 팀이하라면 N+1 읔움 API는 학습다. DataLoader 없음가 해결하기 리힉 하게 팀-1 비용해 기예 경우할 수 있다.
💡 실무 팁: REST를 선택하갨서천한다. zod-to-openapi 패키지로 Zod 스키마에서 OpenAPI 문서를 자동 생성할 수 있다.
📊 GraphQL — 복잡한 데이터 요구사항의 해답
GraphQL은 Facebook이 2015년 공개한 이후 복잡한 데이터 요구사항이 있는 대규모 앱의 표준으로 자리잡았다. 클라이언트가 필요한 데이터만 정확히 요청할 수 있어 Over-fetching/Under-fetching 문제를 근본적으로 해결한다.
GraphQL이 빛나는 상황
- 복잡한 데이터 관계: 소셜 미디어, 전자상거래처럼 여러 엔티티가 복잡하게 연결된 경우.
- 다중 클라이언트: 웹, iOS, Android가 각각 다른 데이터를 필요로 할 때 하나의 API로 대응 가능.
- 빠른 프론트엔드 개발: 백엔드 변경 없이 프론트엔드에서 필요한 데이터를 자유롭게 구성할 수 있다.
GraphQL의 현실적인 단점
보일러플레이트가 많다. 스키마 정의, 리졸버 구현, 클라이언트 쿼리 작성, 코드 생성까지 REST 대비 초기 설정 비용이 크다. N+1 문제는 DataLoader 없이는 해결하기 어렵고, HTTP 캐싱이 POST 요청 기반이라 CDN 활용이 제한적이다.
💡 실무 팁: 소규모 팀이 GraphQL을 선택하면 생산성이 오히려 떨어지는 경우가 많다. 팀 인원 5명 이하에서는 tRPC나 REST가 더 현실적이다.
⚡ tRPC — TypeScript 풀스택의 게임 체인저
tRPC는 TypeScript 풀스택 프로젝트에서 API 레이어를 아예 없애버리는 발상에서 출발했다. 서버에서 함수를 정의하면 클라이언트에서 타입 추론이 자동으로 따라온다. 코드 생성도, 스키마 동기화도 필요 없다.
tRPC의 핵심 강점
// 서버: 함수 정의
const appRouter = router({
getUserById: publicProcedure
.input(z.object({ id: z.string() }))
.query(async ({ input }) => {
return db.user.findUnique({ where: { id: input.id } });
}),
});
// 클라이언트: 자동 타입 추론 (코드 생성 없음)
const user = await trpc.getUserById.query({ id: '123' });
// user의 타입이 자동으로 추론됨 ✅위 코드에서 user의 타입은 서버 쿼리 반환값에서 자동으로 추론된다. 서버 코드를 변경하면 클라이언트에서 즉시 타입 오류가 발생해 런타임 버그를 빌드 타임에 잡을 수 있다.
tRPC의 한계 (솔직하게)
- TypeScript 전용: 모바일 앱(Swift, Kotlin), 외부 서비스와의 연동이 복잡하다.
- 모노레포 구조 필요: 서버와 클라이언트가 같은 저장소에 있어야 타입 공유가 쉽다.
- HTTP 캐싱: REST의 GET 캐싱만큼 자연스럽지 않다. React Query와 함께 쓰면 어느 정도 해결된다.
🔒 타입 안정성 비교
| 시나리오 | tRPC | REST | GraphQL |
|---|---|---|---|
| 서버 응답 타입 변경 시 | ✅ 즉시 오류 | ❌ 런타임 오류 | ⚠️ 코드젠 필요 |
| 입력 유효성 검사 | ✅ Zod 자동 통합 | ⚠️ 수동 구현 | 스키마 기반 |
| 자동완성 지원 | 🏆 완벽 | ⚠️ OpenAPI 필요 | GraphQL IDE 필요 |
| 리팩토링 안전성 | 🏆 매우 높음 | 낮음 | 중간 |
🗂️ 팀 규모 & 사용 사례별 선택 가이드
⚡ tRPC를 선택하세요
- TypeScript 풀스택 모노레포 (Next.js + tRPC + Prisma)
- 소규모 팀 (1~5명), 빠른 개발이 목표
- 외부 API 연동이 적은 내부 도구, SaaS MVP
- 타입 안정성을 최우선으로 할 때
🌐 REST를 선택하세요
- 다양한 클라이언트(웹, 앱, 서드파티)가 API를 소비할 때
- 공개 API, 외부 파트너와 공유하는 API
- 기존 REST 코드베이스를 유지보수할 때
- CDN 캐싱이 중요한 퍼블릭 서비스
- TypeScript를 쓰지 않는 팀
📊 GraphQL을 선택하세요
- 복잡한 데이터 관계 (소셜, 이커머스, 미디어 플랫폼)
- 웹/iOS/Android가 동일 API를 공유할 때
- 프론트엔드 팀이 백엔드와 독립적으로 빠르게 개발해야 할 때
- 팀 규모 10명 이상, GraphQL 경험자가 있을 때
🏆 최종 결론
TypeScript 풀스택 소규모 팀 = tRPC. Next.js + Prisma + tRPC 스택은 2026년 현재 TypeScript 풀스택에서 가장 높은 생산성을 보여준다. 보일러플레이트 없이 엔드-투-엔드 타입 안정성을 확보할 수 있다.
다중 클라이언트 또는 공개 API = REST. 모바일 앱, 외부 파트너, 퍼블릭 API가 필요하다면 REST가 여전히 최선이다. OpenAPI + Zod 조합으로 타입 안정성도 충분히 확보할 수 있다.
복잡한 데이터 요구사항 + 대규모 팀 = GraphQL. 단, 팀이 5명 이하라면 GraphQL의 초기 설정 비용이 생산성을 갉아먹는다. 규모가 커지기 전에는 REST나 tRPC로 시작하고 필요할 때 마이그레이션을 고려하자.
댓글
댓글 쓰기