728x90
반응형
최근 프로젝트에서 monorepo 구조를 채택하여 클라이언트와 서버 코드를 함께 관리하고 있습니다. 클라이언트는 모두 Next.js로 작성되었고, 서버는 NestJS를 사용하고 있습니다. 현재는 ts-rest와 zod를 활용하여 타입 안전성과 데이터 유효성 검사를 구현하고 있지만, tRPC를 알게되었고 도입하는 것이 좋을지 고민이 되었습니다. 이에 따라 각 도구의 장단점을 분석하고, 우리의 프로젝트 환경에 가장 적합한 선택을 찾아보았습니다.
ts-rest와 zod의 조합
장점
- 타입 안전성 강화: ts-rest를 통해 서버와 클라이언트 간의 타입을 공유할 수 있어 런타임 오류를 줄일 수 있습니다.
- 유효성 검사: zod를 사용하여 입력 데이터의 유효성을 검증함으로써 안정적인 API를 구축할 수 있습니다.
- RESTful 구조 유지: 기존의 RESTful 패턴을 따르므로 팀원들이 익숙한 방식으로 개발을 진행할 수 있습니다.
- NestJS와의 호환성: ts-rest는 NestJS와 자연스럽게 통합되어 추가적인 설정 없이도 사용할 수 있습니다.
단점
- 반복적인 코드 작성: 엔드포인트마다 유사한 코드를 작성해야 할 수 있어 생산성이 저하될 수 있습니다.
- 타입 동기화의 한계: 서버와 클라이언트 간의 타입을 완전히 일치시키는 데 어려움이 있을 수 있습니다.
- 타입 안전성의 한계: tRPC만큼의 완전한 타입 안전성을 제공하지 못할 수 있습니다.
tRPC의 도입 고려
장점
- 완전한 타입 안전성: 컴파일 타임에 타입 오류를 잡을 수 있어 안정성이 높습니다.
- 개발 생산성 향상: 별도의 API 스키마나 클라이언트 코드 생성 없이도 빠르게 개발할 수 있습니다.
- 간편한 데이터 페칭: React Query 등과 쉽게 통합되어 상태 관리가 용이합니다.
단점
- NestJS와의 호환성 부족: tRPC는 주로 Next.js와의 통합에 최적화되어 있어 NestJS와 함께 사용하기에는 제한적입니다.
- 추가적인 복잡성: NestJS와 tRPC의 철학이 다르기 때문에 두 프레임워크를 함께 사용하면 복잡성이 증가할 수 있습니다.
- 학습 곡선: 팀원들이 RPC 스타일에 익숙하지 않을 경우 학습 기간이 필요할 수 있습니다.
- 마이그레이션 비용: 기존의 ts-rest 기반 코드를 tRPC로 전환하려면 상당한 노력이 필요합니다.
우리의 선택: ts-rest와 zod의 지속적인 사용!
현재 프로젝트의 특성과 팀의 기술 스택을 고려했을 때, ts-rest와 zod를 계속 사용하는 것이 가장 현실적이고 효율적인 선택으로 보입니다.
이유
- NestJS와의 자연스러운 통합: ts-rest는 NestJS와 잘 맞물려 작동하므로 추가적인 복잡성이 없습니다.
- 팀의 익숙함: 팀원들이 이미 RESTful 패턴과 현재의 기술 스택에 익숙하므로 생산성을 유지할 수 있습니다.
- 유지보수 용이성: 새로운 도구를 도입함으로써 발생할 수 있는 유지보수 이슈를 최소화할 수 있습니다.
- 확장성: 여러 종류의 클라이언트(예: 모바일 앱, 다른 언어로 작성된 서비스)에서 API를 소비할 경우 RESTful API가 더 유연합니다.
프로젝트의 성공은 도구의 선택에 달려있지만, 그보다 더 중요한 것은 팀의 역량과 프로젝트의 특성에 맞는 최적의 선택을 하는 것이라 생각합니다. 현재, ts-rest와 zod를 계속 활용하여 개발을 진행하는 것이 가장 합리적이며, 이는 현재의 기술 스택과 팀의 전문성에 부합하고 생각했습니다.
새로운 기술인 tRPC는 분명 매력적이지만, NestJS와의 호환성 문제와 도입에 따른 복잡성 증가를 고려하면 지금 당장은 도입하지 않는 것이 좋을 것 같습니다. ts-rest, zod와 tRPC 중에서 고민하는 다른 분들께 도움이 되었으면 좋겠네요..!!
피드백은 언제나 환영합니다!
참고 자료
728x90
반응형
'개발일지 > Monorepo' 카테고리의 다른 글
[Monorepo] Monorepo 구축하기 (0) | 2024.09.12 |
---|