AI와 함께하는 2026년 1분기, tRPC를 선택한 이유

시작하며

코딩 에이전트의 성능이 날로 좋아지고 있습니다. 사실상 학습을 위한 사이드 프로젝트가 아니라, 실제로 사용하기 위한 사이드 프로젝트는 점점 더 LLM Agent에 의존하여 개발하게 되는데요.

이런 개발 형태를 취하다 보면 여러 고민에 봉착하게 됩니다. 저의 경우 특히 다음 포인트에서 막힐 때가 있었습니다.

• FE와 BE 간 API를 어떻게 정의할 것인가?
• FE 혹은 BE 작업 간 API가 변경되었을 경우 서로 정합성을 어떻게 보장할 것인가?
• FE에서 올바른 API를 호출한다고 어떻게 보장할 수 있는가?

OpenAPI Spec을 활용하는 방법도 있을 것이고, TypeSpec 등을 활용하는 방법도 있을 것이고, Sub Agent를 활용하는 방법도 있을 것이고 다양하게 해결해볼 수 있을 것입니다.

몇 가지 방법을 시도해본 뒤 나름 저에게 가장 나았던 방법을 찾았습니다. 결론부터 이야기하자면, FE와 BE를 TypeScript로 통일하고 tRPC로 연결하는 것입니다. 이번 글에서는 이 결론에 도달하기까지의 시행착오를 풀어보려고 합니다.

Agent Coding을 위한 기술 스택 선정을 고민하시는 분들께 도움이 되길 바랍니다.

Agent Coding, 사람의 개발과는 다르다

본격적으로 기술 스택 이야기를 하기 전에, AI 중심의 개발이 사람의 개발과 어떻게 다른지를 먼저 짚어볼 필요가 있습니다.

사람은 기본적으로 사유를 통해 돌아가는 코드를 작성합니다. 반면 AI는 LLM 모델의 특성상 논리적으로 말이 되는 코드를 작성하는 것에 집중합니다. 논리적으로 말이 된다는 것은 높은 확률로 돌아가는 코드일 가능성이 높지만, 해당 논리에 빈틈이 있거나 잘못된 논리가 들어갔을 경우 예기치 못한 동작을 불러올 수 있게 됩니다.

즉, 사람이 개발할 때보다 “고장나는 지점”이 더 많아지게 됩니다. 이 차이가 기술 스택 선정에 있어서도 중요한 변수가 됩니다.

첫 번째 선택: FE와 BE를 합칠 것인가, 나눌 것인가

가장 먼저 마주하게 되는 질문은 FE와 BE를 분리해서 개발할 것인가입니다.

통합 스택의 시도

처음에는 많은 분들이 그러하듯, Next.js의 Server Actions나 API Routes를 활용해 FE와 BE를 하나의 프레임워크 안에서 모두 처리하는 풀스택 구성을 시도했습니다. Supabase와 결합하면 별도의 BE 서버 없이 빠르게 개발할 수 있다는 점이 매력적이었죠. Ruby on Rails에서 View까지 모두 처리하는 방법 역시 비슷한 맥락에서 고려해봤습니다.

통합 스택에서 드러난 문제점

하지만 Agent 기반으로 개발을 진행하다 보니 통합 스택 특유의 문제가 도드라지기 시작했습니다.

아무리 디렉터리를 잘 나누고 아키텍처를 잘 설계한다고 해도, 어느 순간 문제가 발생했을 때 전체 애플리케이션에 영향을 주는 경우가 종종 있었습니다. 예를 들어 특정 부분만 렌더링이 안되면 될 것 같은데 페이지 전체가 렌더링이 안된다거나 하는 일이 있었죠.

물론 이런 부분을 Agent에게 올바르게 Instruction을 줘서 해결할 수도 있겠습니다. 서버 컴포넌트와 클라이언트 컴포넌트가 적절하게 사용되게 한다든가, 에러 바운더리 설정을 잘 한다든가 등등의 방법이 있을 것입니다. 하지만 그걸 달성하기 위해선 엔지니어로서 깊은 이해도를 가지고 있어야 했고, 이는 기술 스택의 범주보다는 특정 기술에 대한 디테일한 엔지니어링으로 느껴졌습니다.

특히 컨텍스트가 길어지면서 그러한 지침을 어기게 되면 다시 그걸 테스트하거나 하는 식으로 에이전트 전체 워크플로우가 길어지기 때문에 효율적인가에 대한 의문도 함께 있었습니다.

분리의 결론

결국 저는 FE와 BE를 나누는 것이 더 낫다는 결론을 내렸습니다.

큰 틀에서 FE와 BE를 나눠 개발하는 것이 AI가 집중할 수 있는 컨텍스트를 분리할 수 있음과 동시에, 일종의 내장애성을 갖추게 하는 큰 기틀이 된다고 판단했습니다. FE는 사용자와 맞닿는 부분의 엔지니어링과 구현에 집중하고, BE에서 비즈니스 도메인에 맞닿는 부분의 엔지니어링과 구현에 집중하도록 하는 것이죠.

두 번째 선택: 어떤 언어를 쓸 것인가

FE와 BE를 나눠놓고 생각하다 보면, 각 모듈에 어떤 언어를 쓸지 바로 따라서 고민하게 됩니다.

다른 언어의 시도

초기에는 FE를 TypeScript로, BE를 Java 혹은 다른 언어로 개발하는 조합도 시도해봤습니다. 각 언어가 가진 생태계의 강점을 활용할 수 있을 거라 생각했죠.

다른 언어에서 드러난 문제점

하지만 언어가 다르면 Agent의 컨텍스트에 대한 인지력이 확 떨어진다는 것을 체감했습니다.

특히 각 언어의 타이핑 철학 혹은 변수, 타입 선언에 대한 문법이 다를 경우 모델의 상호 코드 이해력이 확 떨어졌습니다. 가령 덕 타이핑과 타입 연산이 적극적으로 활용되는 TypeScript FE 소스 코드와, 정적 타이핑과 제너릭 기반의 타입이 적극적으로 활용되는 Java BE 소스 코드를 병용해서 개발하다 보면 Agent가 한순간에 갈피를 못 잡는 상황도 자주 맞닥뜨렸습니다.

새로운 세션을 열 때마다 아무리 기존 문서를 먼저 불러오게 하더라도 매번 다른 결과와 결론을 내는 경우가 많았습니다. A 언어로 작성된 코드를 보고 내용을 이해한 다음, B 언어로 작성된 코드를 보고 이해한 내용과 부합하는지 확인하는 식으로 진행하다 보니 컨텍스트와 판단에 많은 부하가 걸리는 것이었죠.

하나의 언어로의 수렴

결국 저는 하나의 언어를 사용하는 것이 훨씬 낫다는 결론을 내리게 되었습니다. FE는 높은 확률로 TypeScript로 개발하게 될 것이니, BE도 Node 혹은 Bun을 활용해 TypeScript로 개발하고, 만약 모바일 앱까지 필요하다면 최근 괄목상대한 Expo 기반의 React Native 앱을 TypeScript로 개발하는 것이 낫다는 것입니다.

적어도 2026년 현재, TypeScript는 풀스택을 개발하기에 가장 적합한 언어라는 생각, 그리고 풍부한 학습 데이터를 가지고 있는 언어라는 생각이 들었기 때문입니다.

세 번째 선택: FE와 BE 사이의 API를 어떻게 정의할 것인가

FE와 BE를 나눠 개발한다고 정하고 나면, 그다음에 만나게 되는 것은 결국 API입니다. 필요한 데이터를 어떻게 서로 소통할 것인지에 대해 명시하는 것, 결론적으로 어떤 파라미터로 어떤 원격 프로시저를 호출했을 때 어떤 반환값이 넘어오는가에 대한 것을 명시하는 것과 동일합니다.

OpenAPI Specification의 시도

가장 먼저 시도한 것은 OpenAPI Specification(OAS)이었습니다. 업계 표준이기도 하고, Agent에게 스펙 문서를 넘겨주면 그에 맞춰 개발할 수 있을 거라 기대했습니다.

OpenAPI Specification에서 드러난 문제점

하지만 이 부분에 있어 열심히 노력하더라도 FE와 BE 사이에 괜찮은 방법을 찾기가 참 어려웠습니다. OAS를 사용한다고 해도 JSON이 과하게 커지면서 컨텍스트에 부담이 되는 경우가 꽤 많았습니다. Agent가 처리해야 할 컨텍스트 윈도우에 비대한 JSON 스펙이 자리를 차지하면서, 정작 중요한 비즈니스 로직에 대한 이해도가 떨어지는 것이었죠. 스펙을 먼저 정의하고 그에 맞춰 개발하면 정합성이 보장될 거라 생각했지만, 실제로는 보호해야 할 대상보다 보호 장치가 더 무거워진 셈이었습니다.

그렇다고 gRPC를 활용하기엔 이걸 FE와 BE 사이에 사용하는 유즈케이스가 잘 없었습니다.

결국 tRPC

그래서 고민하던 차에 만나게 된 것이 tRPC입니다.

tRPC는 Zod 기반으로 API Specification을 정의할 수 있고, 이걸 모노레포나 별도 패키지로 뽑아두면 FE와 BE에서 언제든지 가져다 쓸 수 있게 됩니다. 즉, 공통의 스펙을 바라보고 개발할 수 있게 됩니다.

OAS처럼 별도의 거대한 JSON 스펙 문서가 필요 없습니다. TypeScript 코드 자체가 곧 스펙이 되기 때문에 Agent가 코드를 읽는 것만으로도 API의 입출력을 정확히 이해할 수 있습니다.

// shared/schema.ts
import { z } from "zod";

export const CreateUserInput = z.object({
  name: z.string(),
  email: z.string().email(),
});

export const UserOutput = z.object({
  id: z.string().uuid(),
  name: z.string(),
  email: z.string().email(),
  createdAt: z.string().datetime(),
});

언어가 동일하니 FE에서 BE의 프로시저를 호출할 때 타입 안전성이 자연스럽게 보장되고, Agent가 잘못된 API를 호출하거나 잘못된 파라미터를 넘기는 실수가 구조적으로 차단됩니다.

이걸 벤치마크로 뽑아볼 방법을 아직 고민해보지는 못했지만, 저의 대부분의 유즈케이스에서 좋은 성과를 보여주고 있습니다.

Agent Coding에 적합한 기술 스택의 조건

이러한 시행착오를 거치며 느낀, Agent Coding에 적합한 기술 스택의 특징은 다음과 같습니다.

• 컨텍스트를 분리할 수 있는 구조: Agent가 한 번에 집중해야 하는 범위를 줄여주는 것이 중요합니다. FE와 BE를 분리하여 각각의 관심사에 집중할 수 있도록 하는 것이 그 시작입니다.
• 단일 언어 기반의 풀스택: 언어가 다르면 Agent의 컨텍스트 전환 비용이 급격히 증가합니다. 하나의 언어로 FE와 BE를 관통하는 것이 Agent의 이해도와 일관성을 높이는 데에 큰 도움이 됩니다.
• 코드 자체가 스펙이 되는 API 계약: 별도의 스펙 문서가 컨텍스트를 압도하지 않으면서도, 타입 수준에서 FE와 BE 간의 정합성을 보장할 수 있는 방식이 이상적입니다. tRPC가 이 조건에 가장 부합했습니다.

마치며

최근 기술 스택으로 React 기반 FE에 tRPC를 활용하고, BE는 Fastify 기반 tRPC 서버를 작성하고 있습니다. FE 프레임워크는 Vite를 주로 사용하고, SSR이 필요한 경우 Next.js를 렌더링 레이어로만 활용합니다.

AI 기술이 더 발전하면서 로컬의 파일을 더 효율적으로 Retrieval 할 수 있는 방법론이 개발되거나, 지금과 같은 속도로 모델이 계속 발전하게 된다면 방법론이 또 바뀔지도 모르겠습니다. 하지만 적어도 Opus 4.5, Opus 4.6 시대에는 이 조합이 유효한 것 같다는 생각이 듭니다.

Agent Coding을 위한 기술 스택 선정을 고민하고 계신다면, 기술의 유행만을 보기보다는 AI 에이전트의 특성과 한계를 함께 고려하는 것이 필수적으로 선행되어야 한다고 생각합니다. 제 사례가 그 길을 고민하는 분들께 한번쯤 재고하는 데에 도움이 되었으면 좋겠습니다.