Q1에 노드 백엔드 기술을 왜 이렇게 골랐는가

Apr 23, 2026 updated Apr 23, 2026 backend nestjs node prisma

이 문서는 노드 백엔드 개발 쪽으로 가기 위한 이정표를 만들려고 적어둔 글입니다..
나중에 제가 다시 봐도 이때 왜 이런 선택을 했는지 기억이 살아나면 좋겠고, 비슷한 로드맵을 지나가는 다른 사람한테도 그나마 도움이 되면 좋겠다는 생각으로 썼습니다.

이 글을 잘 보려면 자바스크립트, 타입스크립트, 그리고 약간의 백엔드 지식은 있는 편이 좋습니다.
문법 설명까지 하진 않습니다.

결과적으로는 Q4쯤에 노드로 만든 백엔드와 KMP 앱을 연동해서 배포까지 보는 걸 목표로 잡고 있습니다.

Node.js 백엔드 프레임워크 비교

노드로 구현하는 백엔드 프레임워크 삼대장을 꼽으라면 보통 이쪽입니다.

둘 다 직접 오래 써본 건 아니기 때문에, 대중의 평가를 아예 무시할 수는 없었습니다.
그리고 저는 기가막히게 규칙이 잡혀 있는 걸 꽤 좋아합니다.

그 기준에서 보면 NestJS 쪽이 마음이 더 갑니다.

특히 자바와 비슷하게 생겼다는 점이 생각보다 큽니다.
완전 다른 문법을 다시 받아들이는 것보다, 어느 정도 익숙한 틀 위에서 적응하는 편이 훨씬 낫습니다.

다음은 ORM입니다.
항상 그렇지만, ORM을 처음 볼 때는 이게 그래서 뭔데..? 싶습니다.

대충 보면 OOP와 RDBMS를 연결해주는 다리라고 보면 됩니다.
노드 진영에서 유명한 선택지를 비교해봐도, 결국 가장 많이 손이 가는 건 Prisma였습니다.

이유는 단순합니다.

Gemini 같은 모델에게 물어봐도 여러 조건을 종합했을 때 Prisma를 많이 꼽았고, 사람들 평가도 비슷했습니다.
그래서 그나마 덜 헤매는 선택은 Prisma라고 봤습니다.

이 문서에서는 데이터베이스와 배포 전략까지 완전히 결론내진 않았습니다.
다만 Prisma 쪽을 본 이상 PostgreSQL로 가는 흐름이 가장 자연스럽다고 봤고, 이후 서비스 배포까지 이어질 걸 생각하면 이쪽이 가장 무난합니다.

아직 이 단계에서는 무조건 이게 정답이다라기보다, 후속 분기에서 다시 봐도 흔들리지 않을 정도의 기준을 만드는 쪽에 가깝습니다.

Q1 기준에서 저는 이렇게 정리했습니다.

이유도 별거 없습니다.
타입스크립트 기준으로 가치가 있고, 자료가 많고, 규칙이 잘 잡혀 있고, 나중에 다시 봐도 설명하기 쉬운 조합이기 때문입니다.

초반 기술 선정은 결국 완벽한 정답 찾기보다, 나중에 후회할 확률이 낮은 조합을 고르는 게 더 중요하다고 생각합니다.