이번주에 제시된 프레임워크를 보고, 어떤 기준으로 선택할지를 정리해보았다. 현재 요구사항으로는 어떤걸 선택해도 상관이 없고, 요구사항이 더 구체화되어야 선택지가 좁혀질 것 같다.
| 프레임워크 | 주요 특징 | 장점 | 단점 | 추천 상황 |
|---|---|---|---|---|
| Next.js | React 기반 풀스택(프론트 + 서버) 웹 프레임워크 | React 생태계 활용이 쉽고, 혼자서 빠르게 풀스택 개발 가능 | React 외(Vue, Angular)에서는 선택 메리트가 낮고, FE/BE 역할 분리가 애매해질 수 있음 | 개인 프로젝트, 소규모 팀, 빠른 프로토타입, React 중심 스택 |
| Nest.js | TypeScript 기반 백엔드 프레임워크, 구조(아키텍처) 강제 | 팀 개발에 유리하고, 역할 분담 및 유지보수에 강함 | 작은 프로젝트에는 무겁고, 구조 강제가 부담이 될 수 있음 | 팀 단위 백엔드, 중대형 서비스, TypeScript 기반 백엔드 표준화 |
| FastAPI | Python 기반 백엔드, 타입 힌트 기반 자동 문서화 | 간단히 서버 구축 가능, 문서 관리 부담 감소, AI/데이터 생태계 활용에 강함 | 구조를 강하게 잡아주지 않아 설계 책임이 개발자에게 있고, CPU bound 작업에는 비효율적일 수 있음 | AI/데이터 중심 서비스, 모델 학습 및 데이터 가공, 빠른 API 서버 |
| Spring Boot | Spring의 설정 복잡도를 줄인 Java 백엔드 프레임워크, POJO 지향 | 대규모 환경에 적합, 유지보수성과 안정성을 고려한 설계에 강함 | 작은 프로젝트에는 과한 큰 틀일 수 있음 | 대규모 서비스, 엔터프라이즈 환경, 장기 운영과 안정성이 중요한 시스템 |
데이터를 테이블 모양으로 관리하는 유형.
어떤 데이터를 담아야하는지에 따라 달라진다. 게시판에서 사용되는 데이터들은 권한과 관계가 분명하나다. 따라서 RDB가 적절하다 판단된다. 또한, 트랜잭션으로 데이터를 보호하며 정확한 조건에 해당되는 데이터를 찾는데 특화되어있다. 이번 주차 프로젝트에 소개된 데이터베이스는 PostgreSQL, MySQL, MariaDB. 어떤걸 골라도 구현에는 문제가 없다.
MySQL, MariaDB 는 비슷하고 선호나 회사에서 사용하고 있는걸 따라가면 된다. PostgreSQL의 경우에는 pgvector라는 기능을 이용해 벡터 검색까지 다룰 수 있다고 한다.
벡터 데이터베이스는 의미 기반 검색을 위해 필요해졌다. 나이, 성별, 점수와 같은 명확한 조건이 아니라, 어떤 것과 비슷한것을 찾으라는, 비슷한 의미를 찾을 수 있게 된다.
이전 주차에 LLM 모델을 직접 만들어보면서, 임베딩 벡터간 유사도를 이용해 연관성이 높은 단어를 추론해 보았다. 비슷하게, 문서나 동영상을 벡터로 임베딩하여 저장하는것이다. 검색어를 임베딩 벡터로 나타낼 수 있다면, 가장 유사한 벡터들을 조회하는것이다.
벡터를 위한 데이터베이스를 만드는 이유는 저장 뿐만 아니라 이것들을 효과적으로 다루기 위해서다. HNSW와 같은 ANN 알고리즘을 이용해, 가장 관련이 높은 벡터 몇개를 찾기위해 모든 데이터와 비교할 필요가 없어진다.
RAG의 등장으로 사용자 프롬프트로부터 관련있는 문서를 LLM에 넘길때, 벡터 DB가 자주 활용된다. 벡터 DB는 기존에도 있었지만, RAG의 등장으로 활용도가 높아졌다. 벡터 데이터가 많아질 가능성이 있다면, 벡터 DB를 사용하는것이 효과적인 전략일 수 있다.