[개인 프로젝트] - MongoDB 설계

이전 글에서 MongoDB를 사용하기로 결정하했고, 이제 본격적으로 설계를 해야 하는 단계에 들어섰다. 지금까지 NoSQL을 직접 사용해 본 경험이 없기에 MongoDB를 어떻게 설계하고 활용해야 할지 여러 자료를 찾아보며 정리해 보았다.

---

1. RDB처럼 테이블 설계가 필요한가?

가장 먼저 고민했던 점은 RDB와 같은 사전 설계까 필요한지 여부였다. 기존에 RDB를 사용할 때는 ERD Cloud 등을 활용해 테이블 구조를 먼저 설계하고, PK, FK, 테이블 간 관계, 속성들을 명확하게 정의한 뒤 구현을 진행했다.

 

하지만 MongoDB는 NoSQL 데이터베이스이며, 정해진 스키마가 없는 구조를 가진다. 이 때문에 RDB처럼 사전에 테이블 구조를 엄격하게 설계해야 하는지에 대한 의문이 생겼다.

 

 

여러 자료를 찾아본 결과, MongoDB에서는 RDB처럼 테이블 간 관계를 명확하게 정의할 필요는 없으며, 모든 필드와 속성을 처음부터 고정해 둘 필요도 없다. 대신, 애플리케이션에서 어떤 데이터를 저장할 것인지, 그리고 몇 개의 컬렉션이 필요한지 정도만 설계하면 된다는 점이 핵심이었다.

 

즉, MongoDB에서는 정규화된 테이블 구조보다는 데이터 사용패턴과 조회 방식에 맞춰 문서 단위로 데이터를 어떻게 묶을지 고민하는 것이 더 중요하다.

 

이러한 특성 덕분에 초기 설계 부담은 줄어들지만, 반대로 데이터 구조에 대한 고민을 전혀 하지 않아도 되는 것은 아니며, 서비스 성격에 맞는 컬렉션 단위 설계는 반드시 필요하다는 점도 함께 이해하게 되었다.

---

2. 컬렉션 설계

먼저, 저장해야 할 데이터는 비교적 명확하다. 기본적으로 다음과 같다.

 

1. LLM과 주고받은 질문/응답 로그를 저장하는 컬렉션
2. 키워드와 연관성이 높은 논문들의 메타데이터를 저장하는 컬렉션
3. 최종적으로 생성된 아이디어 관련 정보를 저장하는 컬렉션

위와 같이 현재 구조에서는 총 3개의 컬렉션이 필요하다. 그럼 각 컬렉션에 대해 기본적으로 어떤 정보들이 들어가는지 조금 더 정리하면 다음과 같다.

2.1. LLM과 주고받은 질문/응답 로그를 저장하는 컬렉션

LLM과 주고받은 질문과 응답 로그를 저장하는 방식은 크게 두 가지로 나눌 수 있다고 판단했다.

1. 질문을 하고 응답을 받을 때마다 즉시 컬렉션에 저장하는 방식이다.
2. 두 번째는 하나의 키워드에 대해 아이디어가 도출될 때까지 주고받은 모든 질문-응답을 하나의 실행 단위로 묶어 한 번에 저장하는 방식이다.

각 방식의 장단점을 기준으로 비교해보면 다음과 같다.

 

먼저, 응답을 받을 때마다 컬렉션에 바로 저장하는 방식의 경우, NoSQL 환경에서 WAL(Write Ahead Log) 기반의 안정적인 쓰기를 제공하더라도 쓰기 요청 횟수가 많아지면서 전체 요청 속도가 느려질 가능성이 있다. 즉, 로그 저장이 잦아질수록 쓰기 비용과 지연 시간이 커질 수 있다고 판단했다.

그렇지만, 이 방식은 응답이 생성되는 즉시 저장되기 때문에 로그 누락 가능성이 매우 낮다는 장점도 있다. 실행 도중 오류가 발생하더라도, 그 시점까지의 질문과 응답은 대부분 기록으로 남길 수 있어 디버깅이나 재현 측면에서는 유리하다.

 

두 번째 방식은 첫 번째 방식과 달리, 하나의 실행 단위가 종료된 후에 모든 질문-응답을 한 번에 저장한다. 이 경우 실행 중간에 쓰기 요청이 발생하지 않기 때문에, LLM 호출 흐름 자체는 상대적으로 깔끔하게 유지할 수 있다는 장점이 있다.

그러나 이 방식은 한 번의 쓰기 요청에 포함되는 데이터의 크기가 매우 커질 수 있으며, 실행이 길어질수록 단일 문서의 크기와 쓰기 부담이 증가한다. 또한 실행 도중 오류가 발생할 경우, 해당 실행에 대한 로그가 전형 저장되지 않을 수 있다는 단점도 존재한다.

 

현재 아이디어 생성 과정은 LLM에 의존하고 있으며, 생성된 아이디어의 타당성 판단은 사용자 또는 전문가에게 맡기고 있는 상태이다. 따라서 질문에 대한 응답이 누락되지 않고 최대한 모두 기록되는 것이 중요하다고 판단했고, 그 결과 응답을 받을 때마다 즉시 저장하는 첫 번째 방식을 선택하기로 했다.

 

2.2. 키워드와 연관성이 높은 논문들의 메타데이터를 저장하는 컬렉션

다음으로 고려해야 할 컬레션은 논문들의 메타데이터를 저장하는 컬렉션이다. 현재는 키워드에 대한 논문들의 연관성을 기준으로 논문의 유형, 제목, DOI, 출간 연도, 인용 횟수, 초록 등의 메타데이터를 저장하고 있다. 하나의 키워드에 대해 총 50개의 연관된 논문 정보를 수집하여 .txt 파일 형태로 저장하고 있다.

 

현재 코드 구조를 보면, 하나의 키워드에 대해 관련 논문 정보를 검색한 뒤, 해당 키워드 검색 결과를 기준으로 바로 .txt 파일을 생성해 저장하는 방식으로 구현되어 있다. 따라서 MongoDB에서도 이와 유사하게 하나의 키워드를 기준으로 관련 논문 메타데이터들을 묶어 하나의 문서로 저장하는 방식을 그대로 가져가도 무리가 없을 것이라 판단했다.

 

이 방식은 기존 코드 흐름을 크게 변경하지 않으면서도, 키워드 단위로 논문 정보를 조회하거나 재사용하기에 적합한 구조라는 점에서 설계 측면에서도 합리적이다.

 

2.3. 최종적으로 생성된 아이디어 관련 정보를 저장하는 컬렉션

마지막으로 고려할 컬렉션은 최종적으로 생성된 아이디어 관련 정보를 저장하는 컬렉션이다. 이 컬렉션은 사용자에게 직접 보여주는 데이터를 담기 때문에, 어떤 결과라도 누락되어서는 안되며, 저장 과정 또한 가장 신중하게 설계해야 하는 컬렉션이라고 판단했다.

 

현재 구조에서는 하나의 키워드에 대해 하나의 아이디어가 최종적으로 도출되며, 해당 아이디어에 대한 근거와 세부 정보 역시 하나의 파일에 함께 저장되고 있다. 따라서 이 컬렉션은 최종 결과물이 모두 생성된 이후, 한 번에 저장하는 방식이 적절하다고 판단했다.

 

이와 같은 방식은 아이디어 생성 과정 중간 결과가 아닌, 검증 및 활용이 가능한 완성된 결과만을 관리할 수 있다는 점에서 사용자에게 제공하는 데이터의 신뢰성을 높이는 데에도 도움이 된다.