본 글은 백엔드 팀원이 떠나고 혼자서 서버 개발을 해야 하는 상황에서, 어떻게 신규 기능을 도입할지에 대한 ADR을 다룬 글입니다.
신규 서버 추가하기
어쩌다보니 1인 기업이 되어 있었던 나…(실제 사업자 등록도 해놓음) 하지만 기존의 서비스는 이런저런 기능들을 추가했지만 아직까지 많은 기능들이 있지는 않아 더 추가가 필요하다고 생각했다.
하지만 문제는
- 스프링을 한번도 써보지 않았다
- 자바에 대한 지식이 많지 않다 는 점이 가장 큰 문제로 꼽혔다.
지금에서야 스프링을 배운다고 한들, 여기에 대한 비용 소모가 어마어마 할 것이고 이를 어떻게 효율적으로 해결하면 좋을까에 대한 고민을 하기 시작했다.
고민한 결과, 따로 nestjs 서버를 하나 더 운영해서 기존 DB와 세션을 위한 redis 등을 연결하고 사용할 수 있도록 하기로 결정했다. 그 이유는
- 인프라가 어느정도 구성이 되어 있었기 때문에 서버를 새롭게 추가하더라도 private ip를 통해 통신이 가능한 환경이다
- 자바스크립트가 익숙하다
- 이전에 프로젝트를 하면서 백엔드의 트러블 슈팅을 도왔던 적이 있었는데, 그 과정에서 nestjs의 구조를 조금이나마 경험했다
는 점을 기반으로 nestjs 서버를 추가 운영하기로 결정했다.
graphql
결론 먼저 얘기해보자면, nestjs 기반의 graphql을 이용한 서버를 따로 구축하기로 했다. 그 이유는
- 웹뷰도 따로 개발하는데, 리액트 기반의 애플리케이션인 웹뷰는 따로 서버가 없기 때문에 Next로 서버를 돌렸을 때 웹뷰의 요청 또한 next 서버 쪽으로 가게 된다. 결국 서버의 부하는 웹 클라이언트와 서버 뿐만 아니라 웹뷰 클라이언트 요청 또한 하나의 Nextjs 서버쪽으로 가게 되니 비효율적이라고 생각했다.
- 개인적인 생각이지만 nextjs서버는 bff를 위한 서버정도만으로 구성되는 것이 맞다고 생각한다. 이전까지는 하나의 프레임워크를 통해 풀스택으로 개발할 수도 있었지만 최근에는 컴포넌트 기반 아키텍처를 도입한 프론트엔드에서 파일의 수는 급격하게 증가하였고, 여기서 복잡한 서버의 로직까지 논리적으로 나누게 된다면 덩치가 커질 뿐만 아니라 서버는 서버사이드 렌더링 + db 접근, 서버 로직 처리 등의 모든 것들을 처리하기 때문에 부하가 커진다.
- 또한, 기존의 클라이언트 구조가 이미 클라이언트 중심의 구조로 이루어져있기 때문에 기존의 프로젝트 구조를 고치고 서버와 클라이언트를 내부에서 분리하는 것보다, 따로 서버를 구축하는 것이 이후의 유지보수성에서 관심사를 명확하게 하므로 더 좋다
- graphql을 이용하면 미리 스키마를 정의해놓고, 웹과 웹뷰에서 필요로 하는 데이터가 다를 수 있을 때 graphql로 원하는 데이터만 선택하여 유연하게 클라이언트단에서 작업할 수 있으므로 클라이언트를 위주로 작업하던 나에게는 유리하다 의 이유 때문이다.