DynamoDB 설계

DynamoDB는 NoSQL로, Partition Key와 Sort Key만 결정해두면 나머지는 자유롭게 데이터를 넣고 뺄 수 있는 DB입니다. 굳이 데이터들이 똑같은 요소를 가지고 있을 필요는 없죠. 그래서 미리 SQL문을 잘 짜놓을 필요도 없고요.

 

그래도 DB에 어떤 내용이 들어가야 하는지에 대해서는 깊게 고민해야했습니다.

DB에서 데이터를 불러와야하는데, NoSQL이랍시고 막 집어넣다가는 그 복잡성이 엄청나게 올라갈게 뻔했기 때문이죠.

 

그래서 필요한 서비스들과 필요 데이터들을 정리했습니다.

 

우선 저는 DB를 총 세 개 구성했습니다. 

- user DB

• Partition Key: email (string) → 유저 이메일
• grade (string) → 유저의 구독 등급
• usedToken (number) → 유저가 사용한 토큰 수
• enrolledAt (string) → 유저가 처음 가입한 날
• subStartedAt (string) → 유저가 구독을 시작한 날
• subExpireAt (string) → 유저의 구독이 끝나는 날

- meta DB

• Partition Key: email (string) → 유저 이메일
• Sort Key: conversationId (string) → 각 대화의 id
• firstMsg (string) → 각 대화에서 유저가 입력한 첫 번째 메시지의 첫 20글자
• lastUpdate (string) → 각 대화에서 유저가 마지막으로 입력한 시각

- msg DB

• Partition Key: conversationId (string) → 각 대화의 id
• timestamp (string) → 각 대화가 이루어진 시각 + 중복 방지를 위한 8자리 랜덤 아이디
• message (string) → 각 대화의 내용
• who (string) → 대화의 주체 (user, gpt, claude, grok, gemini)
• combined (boolean) → 해당 메시지가 종합 보고서인지 여부

 

1. 유저의 첫 로그인

  - user DB에 유저가 존재하는지 확인

  - 없을 경우 자동 회원가입 진행 (구글로그인을 구현했기 때문에 따로 회원가입 절차 필요없음)

  - 있을 경우 user DB에서 회원정보 가져와서 프로필 구성하고, meta DB에서 Sidebar의 대화 탭 구성

 

2. 유저의 대화 시작

  - meta DB에 데이터 삽입, msg DB에 데이터 삽입

 

3. 기존 유저의 기존 대화 불러오기

  - 유저가 Sidebar에 이미 존재하는 항목을 선택할 경우

  - 클릭한 meta data를 바탕으로 동일한 conversationId를 가진 모든 msg 들고오기

  - timestamp 순으로 ui에 뿌려주기

 

4. 구독 갱신 / 신규 가입 

  - user DB 업데이트 (PUT)

 

이정도 로직을 생각하고 있었습니다. 간단한 채팅 앱 같지만 외부 api, 구독 모델까지 도입하고자 하니 정말 생각할게 많더군요.

 

여기서 더 발전하자면 msgDB에 email도 포함하는겁니다.

conversationId를 uuidv4를 사용해서 겹칠 일이 거의 없다 한들, 지금 DB데이터 구성이 결국 모든 유저들의 msg data를 하나의 DB에 때려넣는거기때문에

데이터 구분을 조금 더 확실하게 하고싶으시다면 email + conversationId 조합으로 구분하는게 혹시모를 충돌을 방지할 수 있지 않을까 싶습니다.