[플레이데이터 SK네트웍스 Family AI캠프 16기] 20주차 회고

기간: 2025.11.03 ~ 2025.11.07

 

20주차는 파이널 프로젝트 Medinote의 데이터베이스 및 시스템 설계를 실제 구현 단계로 옮긴 시기였다.
이전 주까지 문서로만 존재하던 ERD와 API 정의서를 기반으로, 실제 PostgreSQL 환경에서 테이블을 구축하고 구조를 검증하는 작업이 중심이 되었다. 또한 멘토링을 통해 프로젝트의 AI·DB 아키텍처 설계 방향을 재정비할 수 있었다.

---

1. 데이터베이스 설계 문서 완성 (11월 3~4일)

초반에는 ERD를 기반으로 전체 데이터베이스 설계 문서를 완성하였다.
총 13개 테이블(User, HealthProfile, Drug, Visit, Prescription, File, OCRJob, ChatLog, Consent, Transcript, Segment, Metric, Summary)에 대해 다음 항목을 상세히 정의하였다.

• PK·FK·데이터 타입·제약조건
• 3차 정규화(3NF) 수준의 중복 제거
• ON DELETE CASCADE 등 개별 엔티티의 생명주기(Lifecycle) 설계
• email UNIQUE 등 안정적인 데이터 무결성 확보

특히 User.email UNIQUE 제약을 데이터베이스 차원에서 처리함으로써
중복 가입 방지 및 인증 구조의 안정성을 높이는 방향으로 설계를 확정하였다.

---

2. 멘토링 3회차 (11월 3일)

이번 멘토링은 단순한 데이터베이스 리뷰를 넘어,
AI 아키텍처 전체를 다시 평가하고 설계의 중요성을 재정립하는 시간이었다.

주요 피드백은 다음과 같다.

• STT에 화자 분리(Diarization) 기능 추가 제안
• LLM + Vector DB(Chroma) 기반 구조 검토
• RAG Chain 구성 시 가드레일 설계의 필요성 강조
• 설계는 개발자의 책임이며, AI는 보조 도구라는 점 재확인

멘토링 이후 설계 문서를 다시 점검하며
구조적 선택에 대한 명확한 근거를 확보하는 방향으로 설계를 재정비하였다.

---

3. PostgreSQL 및 DBeaver를 활용한 DB 구축 (11월 5~7일)

설계 문서 확정 후, 실제 Docker 기반 PostgreSQL 환경에서 테이블 구축을 시작하였다.
이 과정에서 예상보다 다양한 오류가 발생했고, 테이블을 반복적으로 생성·삭제하며 구조를 검증하였다.

주요 오류 사례는 다음과 같다.

• FK 충돌 및 참조 순서 오류
• 타입 불일치로 인한 제약 조건 위반
• Auto Increment 관련 충돌
• 예약어(Reserved Word) 사용으로 인한 생성 실패
• Visit–Prescription 1:1 관계 설정 실패
• Consent 테이블 내 user_id·grantee_id 동시 참조로 인한 순환 FK 문제
• Transcript–Segment 식별 관계 오류

이러한 오류를 해결하면서, 문서 기반 ERD가 실제 DB에서 어떻게 동작하는지 구조적으로 이해할 수 있었다.

---

4. 프로젝트 구조 변경에 따른 ERD 전면 수정 (11월 6일)

11월 6일에는 UI 구조 변경에 따라
DB 설계문서, ERD, API 정의서를 동시에 수정해야 했다.

• STT와 챗봇 기능의 흐름이 변화함에 따라
  Transcript–Summary–ChatLog 관계 재정의
• 일부 엔티티의 역할·필드 구성 변경
• 연동 흐름에 따른 API 구조 재배치

수정 전 ERD 설계

수정 후 ERD 설계

 

 

하루 전체를 ERD 재설계에 투입했으며,
프로젝트 설계가 고정형이 아니라 반복적인 검증과 수정을 통해 완성된다는 점을 다시 확인한 시점이었다.

---

5. 정보처리기사 실기 시험 (11월 8일)

주말에는 정보처리기사 실기 시험에 응시하였다.
프로젝트 일정으로 인해 충분한 준비는 어려웠으나, 시험을 직접 경험함으로써 문제 유형을 파악할 수 있었다.
비록 높은 점수는 어려울 것으로 예상되나, 향후 충분한 학습으로 합격 가능성을 확인할 수 있었다.

---

6. 주간 회고

이번 주는 “설계의 실체를 이해하는 시기”였다.

• DB는 시스템의 중심이며, ERD의 오류는 전체 API 구조에 영향을 준다.
• 설계는 단순히 문서를 작성하는 단계가 아니라, 실제 동작을 고려한 구조적 사고가 필요하다.
• AI 도구를 활용하더라도, 최종적인 설계 책임은 개발자에게 있다는 점을 재확인하였다.
• 반복적 수정이 지속되더라도, 수정이 가능한 구조가 올바른 설계라는 사실을 체감하였다.

---

7. 다음 주 계획

다음 주에는 본격적으로 DB와 FastAPI를 연결하여
데이터베이스가 실제 서비스에서 동작하는지 검증할 예정이다.

주요 예정 작업은 다음과 같다.

• CRUD API 테스트
• 초기 샘플 데이터 삽입
• SQLAlchemy 모델 작성
• ERD 기반 마이그레이션 스크립트 구성
• STT–Summary–ChatLog 연동 실험

시스템 내 데이터 흐름을 생성하고 검증하는 단계로 진입하게 된다.

---

8. 마무리

DBeaver에서 설계한 구조가 실제로 구축되는 과정을 거치며
“설계한 시스템이 현실화되고 있다”는 확신을 얻을 수 있었다.
수많은 오류와 반복적인 재설계를 거쳤지만,
각 작업이 DB 구조의 완성도를 높이는 데 기여했다.

이제 다음 단계는, 구축된 DB가 FastAPI를 통해 실질적인 서비스 흐름 속에서
정상적으로 동작하는지 확인하는 일이다.