Written by Paul
서버 - 기술 스택.
필자는 Node.js + Prisma ORM로 이루어진 서버 개발을 선호한다. 따라서 Spring Boot 기반의 mapper.xml로 raw query를 돌리는 등의 코드베이스는 나에게 맞는 코드베이스는 아닌 것 같다.
몇 가지 리서치를 해보니, Java 기반은 잘 모르겠지만 Kotlin 기반은 ORM을 쓰는게 일반적이었던 것 같다. ORM에 너무 익숙해진 나로써는 raw query는 코드베이스의 일관성을 갖기 위해 최대한 지양하고 싶긴 하다.
복잡한 raw query를 효과적으로 관리하는 법은 아직 잘 모르겠다. 프로젝트의 코드베이스에 따라서 많이 달라질 것 같긴 하다.
서버 - Vercel functions.
vercel 배포를 쓰게 되면, 무료버전은 좀 느리긴 한데 (max 1G memory를 지원한다) 무중단 배포 등 인프라 작업을 잘 해줘서 코드단에서만 집중할 수 있다. 결론적으로, 실제 유저가 쓸 환경에서는 유료버전을 추천하고 커스터마이징 측면에서는 AWS로 넘어가는 것을 추천한다. vercel은 IaaS로서 너무 좋지만, 아직까지 서비스 측면에서는 커스터마이징의 한계가 있다.
서버 - NestJS
기존 나는 fastify / express 등의 라이브러리 기반으로 zero to one 을 쌓아가는 노드 서버를 작성하는데에 익숙했다. 프레임워크라는 것이 만들어 놓은 룰에 따라가야 할 만큼 사이드프로젝트가 규모가 크지도 않았다.
하지만 회사 프로젝트처럼 체계적인 프로젝트를 다루기 위해서는, 서버 프레임워크는 불가피 한 것으로 보이기도 했다. 코드베이스를 유지해야 하기 때문이었다. 따라서 요즘은 NestJS를 많이 활용하는 것 같다. 마치 Next.js를 쓰듯이 말이다.
아직 NestJS 까지 경험은 못 한 상태인데, 조만간 한번 경험 해 볼 생각이다!
DB - DBeaver
디비를 직접적으로 다룰 때에 좋다. 다른 툴도 있는 것으로 알고 있는데, 필자는 DBeaver를 썼다. Supabase + postgresql을 쓰는 것도 자체 콘솔이 있어 좋은 방법이다. 기존 TablePlus를 썼었는데, DBeaver가 훨씬 나은 것 같다. 디비 조회 및 CRUD용으로 DBeaver 를 추천한다!
DB - Prisma ORM
introspect 등 기존 설립된 DB 구조를 바탕으로 prisma.schema를 형성할 수 있는 등 형상관리 측면에서 이점이 아주 많다. 이것과 관련된 글은 조금 더 심화적으로 하나의 글로 다시 다룰 예정이다. 그렇더라도 디비 테이블 자체에서 정규화가 제대로 진행 되지 않으면, ORM을 쓰더라도 관리가 복잡한 것은 사실이니 먼저 근간이 되는 Schema 부터 잘 잡는게 좋다.
참고로 MySQL 의 Point 데이터 타입은 아직 prisma orm에서 지원하지 않는다.
서버 - fastify
서버 작업에는 다음과 같은 요소들이 꽤나 중요해 보였다.
- 레이어 분리
- 서비스
- 컨트롤러
- 모듈
- DTO
- schema 관리를 위한 DTO 분리
따라서 필자는 fastify를 사용하여 서버를 띄우는데, 추후 NestJS를 점진 적용 할 수 있을 것 같다.
- Domain
- domain.module.ts
- router
- domain.service.ts
- 비즈니스 로직
- domain.controller.ts
- 각각의 라우터에서 서비스 레이어를 불러와 로직을 계산하고, response를 내려주는 컨트롤러
꽤나 지금은 이 구조에 익숙해져서 생산성이 많이 올라갔다.
마치며
서비스 개발은 쉽지 않다. 기획이라는 전체적인 그림 안에서 잘 돌아가는 서비스를 만들려면, 정책의 얼개가 잘 맞아야 한다. 마치 톱니바퀴 여러개가 잘 맞물려서 돌아가는 시계태엽처럼 말이다. 결국 정책의 얼개는 데이터 단으로 들어오고, 그 데이터를 잘 다루는 것이 개발자가 하는 일의 일환이다.
서비스 개발은 어렵다. 혹은 쉽지 않다! 다만, 유저의 피드백과 반응을 보며 성장하는 서비스를 보는일은 행복한 일이다. 앞으로 그런 서비스를 만들기 위해 또 부단히 노력할 계획이다.