본문으로 건너뛰기
버전: 11.x

FAQ / 문제 해결

자주 묻는 질문과 이를 해결하는 방법에 대한 아이디어 모음입니다.

이 페이지에 개선 사항을 기여하거나, 여기에서 답변되지 않은 질문이 있다면 GitHub에서 새로운 토론을 시작해 주세요. 또한, 질문이 여기에서 답변되지 않았다면 GitHub Discussions와 Discord를 확인해 보세요.

작동하지 않습니다! 모든 곳에서 any가 발생합니다​

  • 코드에 타입 오류가 없는지 확인하세요
  • tsconfig.json에 "strict": true가 있는지 확인하세요
  • package.json에서 @trpc/* 버전이 일치하는지 확인하세요
  • tRPC가 요구하는 TypeScript 버전(>=5.7.2)을 사용하고 있는지 확인하세요
  • 에디터가 package.json과 동일한 TypeScript 버전을 사용하도록 설정되어 있는지 확인하세요

VSCode 설정​

에디터가 package.json과 동일한 TypeScript 버전을 사용하도록 하려면 프로젝트 루트에 있는 .vscode/settings.json에 다음 설정을 추가하세요:

.vscode/settings.json
json
{
  "typescript.tsdk": "node_modules/typescript/lib",
  "typescript.enablePromptUseWorkspaceTsdk": true
}
.vscode/settings.json
json
{
  "typescript.tsdk": "node_modules/typescript/lib",
  "typescript.enablePromptUseWorkspaceTsdk": true
}

동료들도 동일한 경험을 할 수 있도록이 파일을 저장소에 커밋하는 것을 강력히 권장합니다.

미들웨어로 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가 이를 자동으로 수행하려면 TypeScript에서 아직 지원되지 않는 "Higher kinded types"가 필요합니다.

관련 토론: https://github.com/trpc/trpc/discussions/2150

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

아니요, 대신 기본 프로시저를 사용할 수 있습니다. 이는 라우터 수준별로 적용하는 것보다 더 유연합니다.

tRPC는 Next.js App Router 및 RSC와 함께 작동하나요?​

네, tRPC는 Next.js App Router 및 React Server Components와 함께 작동합니다. 권장되는 접근 방식은 Next.js App Router 설정 가이드를 참고하세요.

unstable_로 표시된 기능을 사용하는 것이 안전한가요?​

요약: 네!

tRPC에서 unstable_로 표시된 기능을 발견했다면, 해당 API가 불안정하며 마이너 버전 업데이트 시 변경될 수 있음을 의미합니다. 그러나:

  • 구현 세부 사항은 마이너 변경 사항에서 변경될 수 있으며, 이름과 옵션이 변경될 수 있습니다
  • tRPC에 존재하는 기능은 이미 프로덕션 환경에서 사용되고 있습니다
  • 해당 기능 사용을 적극 권장합니다
  • unstable_ 기능에 변경 사항이 적용되면 릴리스 노트에 포함됩니다(타입 오류가 표시됩니다)
  • API 설계에 대한 제안이나 이슈는 github.com/trpc/trpc/issues 또는 #🧪-unstable-experimental-features 채널의 Discord에 보고해 주세요

experimental_로 표시된 기능을 사용하는 것이 안전한가요?​

tRPC에서 experimental_로 표시된 기능을 발견했다면, 해당 API가 불안정하며 tRPC의 어떤 버전 업데이트 중에도 변경될 가능성이 매우 높음을 의미합니다.

  • 기능의 범위와 사용법이 크게 변경될 수 있습니다
  • 기능이 충분히 테스트되지 않았을 수 있습니다
  • 기능이 완전히 제거될 수 있습니다
  • 가이드된 마이그레이션 경로 없이 최신 문서를 읽고 업그레이드하는 것은 사용자의 몫입니다
  • 변경 사항이 릴리스 노트에 충분히 문서화되지 않을 수 있습니다
  • 버그 수정이 보장되지 않습니다

그러나 우리는 피드백을 환영합니다! API 설계에 대한 제안이나 이슈는 #🧪-unstable-experimental-features 채널의 Discord에 보고해 주세요.

tRPC는 semver을 엄격하게 따르나요?​

네. tRPC는 유의적 버전 관리(Semantic Versioning)를 엄격하게 따르며, 마이너 버전 업데이트에는 비호환 변경을 도입하지 않습니다.

이와 함께, JSDoc에 @internal로 표시된 경우를 제외하고, export된 TypeScript type에 대한 변경 사항도 주요 변경 사항(major changes)으로 간주합니다.

tRPC의 버전이 이미 왜 이렇게 높은가요?​

tRPC가 시작되어 사용자가 매우 적었을 때, 우리는 semver을 엄격하게 지키면서 API 설계를 자주 반복 개선했습니다.

  • tRPC의 첫 9개 버전은 프로젝트의 첫 8개월 동안 출시되었습니다.
  • v9 출시 14개월 후 출시한 버전 10는 API 결정에 근본적인 변경 사항을 가한 tRPC의 진정한 "버전 2"로 볼 수 있습니다. (2는 이진법으로 10이죠, 맞죠?)

현재 API는 안정적으로 유지될 것으로 예상합니다. 향후 비호환 변경이 필요하다면 v9에서 v10으로 업그레이드할 때와 마찬가지로 코드 변환 도구(codemod)를 제공할 계획입니다.

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

GitHub에 기능 요청을 작성하거나, GitHub Discussions에 글을 남기거나, Discord에 참여해 주세요. 또한 페이지 하단의 "이 페이지 편집" 버튼을 사용하여 이 페이지나 다른 페이지의 개선 사항을 제안할 수도 있습니다.