자주 묻는 질문 / 문제 해결
이 페이지는 PageTurner AI로 번역되었습니다(베타). 프로젝트 공식 승인을 받지 않았습니다. 오류를 발견하셨나요? 문제 신고 →
자주 묻는 질문과 이를 해결하기 위한 방법들을 모아놓은 문서입니다.
이 페이지를 개선하는 데 기여해 주시거나, 여기서 답변되지 않은 질문이 있다면 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.jsonjson{"typescript.tsdk": "node_modules/typescript/lib","typescript.enablePromptUseWorkspaceTsdk": true}
.vscode/settings.jsonjson{"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 패키지를 배포하고 프론트엔드 저장소에서 이를 사용하는 것입니다.
입력값에 따라 동적으로 다른 출력을 반환할 수 있나요?
현재는 불가능합니다. tRPC가 이를 자동으로 처리하려면 "Higher kinded types"라는 기능이 필요한데, 이는 아직 TypeScript에서 지원되지 않습니다.
전체 라우터에 미들웨어를 적용할 수 있나요?
아니요, 대신 기본 프로시저를 사용할 수 있습니다. 이는 라우터 단위로 처리하는 것보다 더 유연한 접근을 제공합니다.
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)를 제공할 계획입니다.
더 궁금한 점이 있으신가요?
기능 요청은 GitHub에, 질문은 GitHub Discussions에 작성해 주시거나 Discord를 이용해 주세요. 또한 페이지 하단의 '이 페이지 편집하기' 버튼을 사용해 이 페이지나 다른 페이지에 대한 개선 사항을 자유롭게 제안할 수 있습니다.