본문 바로가기
버전: 10.x

자주 묻는 질문 / 문제 해결

비공식 베타 번역

이 페이지는 PageTurner AI로 번역되었습니다(베타). 프로젝트 공식 승인을 받지 않았습니다. 오류를 발견하셨나요? 문제 신고 →

자주 묻는 질문과 이를 해결하기 위한 방법들을 모아놓은 문서입니다.

이 페이지를 개선하는 데 기여해 주시거나, 여기서 답변되지 않은 질문이 있다면 GitHub에 새 논의를 생성해 주세요. 또한 질문에 대한 답을 찾지 못하셨다면 GitHub Discussions와 Discord를 살펴보시길 권장합니다.

작동하지 않아요! 모든 곳에서 any 타입이 나타납니다​

  • 코드에 타입 오류가 없는지 확인하세요

  • tsconfig.json에 "strict": true가 설정되어 있는지 확인하세요

  • package.json에서 모든 @trpc/* 패키지 버전이 일치하는지 확인하세요

미들웨어가 Context 타입을 변경하게 하려면 어떻게 해야 하나요?​

컨텍스트 확장 문서를 참조하세요.

tRPC는 프로덕션 환경에서 사용할 수 있나요?​

네. tRPC는 매우 안정적이며 수천 개의 기업에서 사용하고 있습니다. Netflix 및 Pleo와 같은 대규모 기업들도 프로덕션 환경에서 tRPC를 사용 중입니다.

모노레포에서 tRPC가 작동하지 않는 이유는 무엇인가요?​

정확한 답변은 어렵지만, tRPC에는 빌드 단계가 없기 때문에 문제가 tRPC 측에 있을 가능성은 낮습니다.

확인해 볼 사항들:

  • 모든 프로젝트에서 @trpc/* 패키지 버전이 동일한지 확인하세요

  • 모든 tsconfig.json 파일에 "strict": true가 설정되어 있는지 확인하세요

  • 애플리케이션에 타입 오류가 없는지 확인하세요

  • 별도의 서버와 클라이언트 tsconfig.json 파일을 사용하면서 모노레포 패키지가 번들링되지 않은 경우, 클라이언트의 tsconfig.json에 서버 tsconfig.json과 동일한 "paths": [...] 설정이 있는지 확인하여 클라이언트가 동일한 파일을 찾을 수 있도록 하세요

모노레포에서 tRPC를 사용하는 여러 오픈소스 프로젝트를 찾아보려면 Awesome tRPC 컬렉션을 참고하세요.

모노레포는 필수인가요?​

아니요, 모노레포는 필수가 아닙니다. 하지만 모노레포를 사용하지 않으면 클라이언트와 서버가 함께 작동한다는 보장을 잃게 되어 tRPC 사용의 이점 일부를 누리지 못하게 됩니다.

tRPC를 활용하는 한 가지 방법은 백엔드 저장소의 타입을 포함한 프라이빗 npm 패키지를 배포하고 프론트엔드 저장소에서 이를 사용하는 것입니다.

관련 논의: https://github.com/trpc/trpc/discussions/1860

입력값에 따라 동적으로 다른 출력을 반환할 수 있나요?​

현재는 불가능합니다. tRPC가 이를 자동으로 처리하려면 "Higher kinded types"라는 기능이 필요한데, 이는 아직 TypeScript에서 지원되지 않습니다.

관련 논의: https://github.com/trpc/trpc/discussions/2150

전체 라우터에 미들웨어를 적용할 수 있나요?​

아니요, 대신 기본 프로시저를 사용할 수 있습니다. 이는 라우터 단위로 처리하는 것보다 더 유연한 접근을 제공합니다.

tRPC가 Next.js 13 App Layouts & RSC와 호환되나요?​

예, tRPC는 Next.js 13 App Layouts 및 React Server Components와 호환됩니다. 다만 아직 공식 예제는 제공되지 않습니다.

자세한 정보는 이 이슈에서 확인할 수 있으며, 여기서 몇 가지 구현 예시를 참조했습니다.

unstable_로 표시된 기능을 안전하게 사용할 수 있나요?​

요약: 네!

tRPC에서 unstable_로 표시된 기능은 API가 불안정하여 마이너 버전 업데이트 시 변경될 수 있음을 의미하지만:

  • 구현 세부사항이 마이너 변경 시 변동될 수 있음(이름 및 옵션 변경 가능)

  • tRPC에 존재하는 기능은 이미 프로덕션 환경에서 사용 중임

  • 해당 기능 사용을 적극 권장함

  • unstable_ 기능 변경 사항은 릴리스 노트에 반영되며 타입 오류로 확인 가능

  • API 설계 관련 제안이나 이슈는 github.com/trpc/trpc/issues 또는 Discord의 #🧪-unstable-experimental-features 채널로 제출해 주세요

experimental_로 표시된 기능을 안전하게 사용할 수 있나요?​

tRPC에서 experimental_로 표시된 기능은 API가 불안정하여 tRPC 버전 업데이트 시 크게 변경될 가능성이 높음을 의미합니다.

  • 기능의 광범위한 측면과 사용 방식이 변경될 수 있음

  • 기능 테스트가 충분히 이루어지지 않았을 수 있음

  • 기능이 완전히 제거될 수 있음

  • 최신 문서를 참조하고 가이드 없이 업그레이드하는 것은 사용자 책임임

  • 변경 사항이 릴리스 노트에 충분히 기록되지 않을 수 있음

  • 버그 수정이 보장되지 않음

그러나 여러분의 의견을 소중히 여깁니다! API 설계 관련 제안이나 이슈는 Discord의 #🧪-unstable-experimental-features 채널로 제출해 주세요.

tRPC는 시맨틱 버저닝(semver)을 엄격히 준수하나요?​

예, tRPC는 시맨틱 버저닝을 매우 엄격히 준수하며 마이너 버전 업데이트 시 호환성 깨짐(breaking change)을 절대 도입하지 않습니다.

이와 함께 JSDoc에서 @internal로 표시된 타입을 제외하고, export된 TypeScript type 변경도 메이저 변경으로 간주합니다.

tRPC 버전이 이미 높은 이유는 무엇인가요?​

tRPC 초기에는 사용자가 적었고 시맨틱 버저닝을 엄격히 준수하면서 API 설계를 지속적으로 개선했습니다.

  • tRPC의 첫 9개 버전은 프로젝트 시작 후 8개월 내에 출시되었습니다.

  • v9 출시 14개월 후 공개한 버전 10은 API 설계의 근본적 변경이 이루어진 실제 "버전 2"로 간주해야 합니다. (2 is 10 in binary, amirite?)

이제 API가 안정화되었으며, 향후 호환성 깨짐 변경 시 v9→v10 업그레이드처럼 코드모드(codemod)를 제공할 계획입니다.

slug: typescript-performance-lessons title: v10 리팩토링 과정에서 얻은 TypeScript 성능 교훈 authors: [sachinraja]​

더 궁금한 점이 있으신가요?​

기능 요청은 GitHub에, 질문은 GitHub Discussions에 작성해 주시거나 Discord를 이용해 주세요. 또한 페이지 하단의 '이 페이지 편집하기' 버튼을 사용해 이 페이지나 다른 페이지에 대한 개선 사항을 자유롭게 제안할 수 있습니다.