기술 선택 이유
- 저희 프로젝트의 특성상 백엔드에서 처리한 맵 데이터를 프론트엔드에서 3D 오브젝트들로 매핑해야 합니다. 맵 데이터는 트리 구조로 이루어져 있으며, 같은 유형의 중복되는 요소들이 많습니다. 이에 따라 맵 데이터를 절차적으로 3D 오브젝트로 변환하기보다는 재사용 가능한 컴포넌트화하여 개발하는 것이 이점이 많기 때문에, 컴포넌트 기반 개발에 적합한 React Three Fiber를 선택하였습니다.
- 팀원이 바닐라 Three.js에 대한 경험이 없는 대신, React 경험이 많은 것을 고려하여, 익숙한 문법에서 개발을 할 수 있으며 React스럽게 개발할 수 있는 React Three Fiber를 채택했습니다.
- threejs용 react 렌더러이며, 재사용 가능한 컴포넌트 단위로 오브젝트를 분리하거나 자체 포함된 요소들을 활용하여 선언적으로 코드를 작성할 수 있습니다.
- 공식문서에 따르면 threejs와의 호환성이 정말 높으며, 추가 오버헤드가 없고, React의 스케줄링 기능을 통해 오히려 성능이 더 뛰어납니다.
- 기본적으로 여러 이벤트(onClick 등)를 지원하여 레이캐스터를 선언하지 않고도 3D 마우스 피킹을 손쉽게 구현할 수 있습니다. (보일러 플레이트 코드가 줄어듬)
- 타입을 명시하는 과정에서 컴파일 단계에 미리 오류를 잡아낼 수 있어, 추후 디버깅 과정과 테스트 과정에 드는 비용을 줄일 수 있어 사용하였습니다.
- 별다른 추가 설치 없이, 기본적으로 typescript 컴파일링, 스타일 임포트, 파일 임포트 등을 기본적으로 지원하기 때문에, 초기 프론트엔드 설정에 들어가는 비용을 줄일 수 있습니다.
- Vite의 빠른 번들링 속도로 인한 시간 감축이(이 글에 따르면 Webpack대비 약 278% 향상) Vite를 배워야 하는 추가적인 학습 시간보다 더 빠르다고 판단되었기에 채택하였습니다.
- 팀원 중 컴퓨터 성능이 좋지 않은 팀원이 있어, Webpack을 번들링하면서 들어가는 시간으로 개발을 하지 못하면서 비생산적으로 소요되는 시간을 절감할 수 있을 것이라고 판단되었습니다.
- Zustand는 threejs 렌더러로 사용한 React Three Fiber의 개발자가 제작했으며, 무엇보다 React Three Fiber가 내부적으로 Zustand를 사용하고 있으므로, 다른 상태관리 라이브러리를 고려할 이유가 없었으며 호환성이 뛰어나 zustand를 채택하였습니다.
- 러닝커브가 낮고, 보일러 플레이트 코드량이 적다는 장점이 있습니다.
- 프로젝트 내 데이터의 특성
- 저희 프로젝트는 유저 한명 당 매 번 독립적인 히스토리 데이터가 추가되는 서비스로, 데이터 간 관계가 필요하지 않으며 데이터의 변경보다는 삽입/삭제가 주로 발생하는 서비스입니다.
- 이 때, 각 DB의 삽입과 삭제는 거의 상위 구조에서만 이루어지므로, 관계형 DB보다는 비관계형 DB가 프로젝트에 적합하다고 생각했습니다.
- NoSQL을 사용할 때의 이점
- 저희 프로젝트에서는 Notion에서 수집한 데이터들을 가공한 후 저장하는데, 한 개의 갤러리마다 여러 페이지가 있고, 페이지마다 각 데이터의 종류를 분류해서 배열에 삽입한 후 트리 형태로 저장합니다.
- 이를 관계형 데이터베이스로 저장한다고 가정하면, 한 개의 갤러리를 저장하는 데 약 **10개의 서브 테이블(갤러리 페이지 테이블, 서브 타이틀 테이블 등)**이 필요하고 평균 200개의 쿼리가 수행되어야 합니다.
- 반면에, NOSQL로 저장한다면 한 개의 갤러리를 저장하는데 1번의 쿼리만 수행하면 되기 때문에 더 효율적이라고 생각했습니다.
- 따라서, 트리 구조로 이루어진 맵 데이터를 별다른 조인 과정 없이 한 번에 저장하고 읽어올 수 있는 NoSQL이 프로젝트에 적합하다고 생각했습니다.
- Notion Acess Token의 특성
- 사용자의 Notion 데이터를 가져오는데 필요한 Notion API에 접근하기 위한 토큰입니다.
- 토큰의 만료 기한이 없기 때문에, 탈취당할 경우 심각한 문제가 발생합니다.
- 따라서 사용자 식별 및 인증에 필요한 해당 토큰을 일시적으로 특정 기한동안만 저장해야합니다.
- 또한 해당 정보는 저장하고 있는 동안 변화할 일이 없고, 프로젝트 특성 상 빈번히 호출되기 때문에 on-disk DB에 저장하는 것이 다소 비효율적입니다.
- 위와 같은 특성을 고려했을 때 in-memory DB에 저장하는 것이 가장 효과적이라고 생각했습니다.
- in-memory DB로 Redis를 사용
- 향후 분산 서버 환경을 고려하여 서비스 서버 여러 대가 하나의 Redis 서버를 공유하여 사용하도록 하였습니다.
- 프로젝트 특성 상 수집한 글과 이미지를 그대로 사용하지 않고, 자연어 처리를 통한 키워드 추출과 이미지 픽셀 처리가 데이터 시각화에 큰 도움이 될 것이라 생각했습니다.
-
자연어 처리, 이미지 처리에 파이썬을 사용한 이유
- 해당 경험이 있는 팀원의 존재로 러닝커브의 최소화
- js에 비해서 한국어 자연어 처리 라이브러리가 잘 갖춰져 있다고 판단
-
FastAPI를 사용한 이유
- MSA로서 사용할 것이기 때문에 Django 같이 무거운 프레임워크를 사용할 필요가 없다고 판단
- ASGI기반 프레임워크라서 비동기 작업에 유리
- 같은 ASGI기반 프레임워크인 SANIC등과 비교해 사용량의 증가 추이가 가장 높음 출처
- 경험이 있는 팀원이 존재하였고, 문법이 간단하기 때문에 러닝커브가 매우 낮음
- branch의 PUSH/PR를 감지해서 자동으로 코드가 실행되어 번거로운 수작업을 최소화할 수 있습니다.
- Jenkins는 별도 서버를 운용해야하는 반면, Github Actions는 서버 인스턴스를 구축할 필요가 없기 때문에 비용을 절약할 수 있고, 관리하기 더욱 편리합니다.
- 컨테이너 가상화를 통해 배포 환경에서 코드의 올바른 동작을 보장받을 수 있습니다.
- VM과 비교해서 Container는 hypervisor를 사용하지 않고 OS를 공유하기에 비교적 가볍습니다.
- 위와 같은 이유로 추후 분산 환경을 적용하는 것을 고려했을 때, Docker를 사용하는 것은 필수 불가결하다고 판단했습니다.
