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

기간: 2025.11.17 ~ 2025.11.21

 

* 본 회고는 최종 프로젝트 진행 중 기록이 누락된 기간을 뒤늦게 정리한 것이다.
22주차는 FastAPI–DB 연동 안정화, 인증 API 재정비, ERD 구조 개선,
그리고 프론트엔드와의 API 통합 준비 과정에서 발생한 여러 오류 대응이 핵심이었다.

 

또, 서비스 통합을 위한 API 및 데이터 구조 정비에 집중된 기간이었다.
FastAPI–PostgreSQL 연동 안정화, 인증 API 점검, 프론트–백엔드 연결 테스트,
그리고 프론트 측 요구사항 전달에 따른 API·ERD 구조 재수정이 제일 중요했다.
이 과정에서 다수의 클라이언트/서버 오류가 발생하였고,
요구사항 반영과 오류 해결을 반복하며 전체 구조의 일관성을 확보하는 데 주력하였다.

---

1. FastAPI–PostgreSQL 연동 안정화

기존 DB 연동은 구축되어 있었으나, 실제 서비스 수준의 안정성 확보를 위해
스키마와 ORM 모델 간 불일치 사항을 점검하였다.

• 테이블 스키마 변경 후 ORM 모델이 즉시 반영되지 않아 발생한 500 오류
• DBeaver에서는 조회되나 FastAPI 경로에서는 반환되지 않는 문제
• User 테이블 구조 변경(terms_agreed, email_verified 추가)에 따른 전체 모델 재정비
• ForeignKey 구조 변경에 따른 참조 오류 발생

여러 차례 마이그레이션을 수행하며 모델·스키마·API 구조를 일치시켰고,
이후 통합 테스트가 가능하도록 기본 안정성을 확보하였다.

---

2. 11월 17일 프론트 요구사항 수신 및 구조 정비

11월 17일, 프론트 작업자로부터 서비스 운영에 필요한 세부 요구사항이 전달되었다.
이 요구사항은 API 스펙과 ERD 구조에 직접적인 영향을 주었고,
22주차 수정 범위의 상당 부분을 결정하였다.

● 전달받은 요구사항 요약

프론트 측 요구사항(원문)

[User] 약관동의, 이메일인증(후순위)
[HealthProfile] 체중 → 몸무게
[Allergy] 알러지
[Drugs] 약이름, 약 종류[정제/캡슐/액상], 용량(용량+단위), 복용스케줄, 시작일~종료일 → 일정관리 연동
[Visit] 진단코드(진단명), 진료일, 병원, 담당의, 증상, 담당의 소견 → 진료기록에서 처방약 추가 가능
[Prescription] 약 종류/용량/스케줄 구조 재정비 + 일정관리 연동
[ChatLog] 채팅목록 리스트, 채팅 제목
[Segment] 화자분리 후순위
[Summary] 진료요약 결과를 담당의 의견으로 활용
[Feedback] 제목, 유형, 내용, 이메일(선택)
[Notification] 피드백 처리 단계별 알림
[Schedule] 제목, 유형(진료/검진), 날짜·시간·장소, 복약관리 연동
[Analysis] 이름, 만나이, 성별, 키, 몸무게, BMI, 분석 리포트 구조

● 요구사항 반영 작업

해당 요구사항들을 기반으로 다음과 같은 수정 작업이 이루어졌다.

• HealthProfile의 용어 정비(체중→몸무게)
• Allergy, Drug, Prescription의 필드 구조 세부화
• Visit 엔티티의 필드 확장 및 연동 구조 조정
• ChatLog 리스트 구조 반영
• Feedback 필드(title, category, email 등) 정비
• Schedule 엔티티의 타입/시간/장소 구조 구체화
• Analysis 테이블의 기본 정보 항목 보완
• Summary 데이터 사용 방향(진료 소견 연동) 반영

프론트 요구사항은 실제 사용자 화면 흐름을 기반으로 하므로,
데이터 구조와 API 설계에서 반드시 반영해야 하는 항목들이었으며
그 영향 범위가 넓어 DB·API 수정이 병행되었다.

---

3. 인증 API 점검 및 오류 대응

22주차 전체 시간 중 가장 많은 비중을 차지한 작업은
회원가입 및 로그인 API의 검증과 오류 수정이었다.
API 설계서 기준 최신 구조로 스키마를 재정비했으나
다양한 오류가 지속 발생했다.

3.1 회원가입 (/auth/signup)

• ValidationError로 인한 400 Bad Request 반복
• 응답 모델(access_token, refresh_token) 불일치
• 비밀번호 해싱 단계 오류로 500 Internal Server Error 발생
• 프론트 Axios 요청에서 Body 구조가 인식되지 않음 → JSON 스키마 통일 작업 수행

3.2 로그인 (/auth/login)

• JWT payload 누락으로 401 Unauthorized 지속
• 토큰 exp 계산 오류로 토큰 즉시 만료
• Swagger에서는 정상이나 프론트 Axios에서는 500 Internal Server Error 발생
• Authorization 헤더 처리 방식 불일치로 403 Forbidden 발생

22주차 내에는 인증 안정화를 완전히 달성하지 못했다.
이에 따라 서비스 개발이 중단되지 않도록
일시적으로 fake token / dummy user 정보를 사용해 통합 테스트를 진행하였다.

---

4. 프론트–백엔드 통합 중 발생한 오류 분석 및 대응

11월 17일 이후 프론트 팀이 실제 화면에서 API를 연결하는 과정에서
다양한 오류가 반복적으로 발생하였다.

● 발생 오류 유형

• 400 Bad Request: 요청 Body·필드 불일치
• 401 Unauthorized: JWT 미인증
• 403 Forbidden: role 검증 실패
• 500 Internal Server Error: 모델 불일치·예외 처리 누락 등 서버 오류

● 대응 방식

• 오류 발생 API를 구분하여 단계별 수정
• Swagger → Axios 요청 비교를 통한 구조 차이 검증
• 모델·스키마·엔드포인트 구조 정비
• 서버단 예외 처리 로직 보완
• 인증 오류 우회 상태에서 다른 CRUD 테스트 진행 가능하도록 환경 구성

여러 오류가 반복되었으나,
각 오류 유형에 대한 원인 분석 및 조치 과정은
향후 엔드포인트 구조 정교화에 도움이 되었다.

---

5. ERD 구조 수정 (11월 19일 작업)

21주차에 이미 생성된 만성질환·급성질환·알러지 테이블 외에
22주차에는 스케줄 및 피드백 관련 구조가 추가로 수정되었다.

 

기존 ERD

● 11/19 수정 내용

✔ Schedule 테이블 개선

• 제목(title), 유형(type), 날짜(date), 시간(time), 장소(place) 정비
• 복약 관리와의 연동을 고려한 필드 구조 재정의
• null 가능 필드 조정으로 데이터 무결성 강화

✔ Feedback 테이블 수정

• title 필드 반영
• category 구조 재정비
• requires_reply(Boolean) 확정
• 선택 이메일 필드 추가 검토

11/19일 수정된 ERD

 

해당 수정은 프론트 요구사항이 직접적으로 반영된 결과이며
수정 후 각 API 엔드포인트의 요청·응답 모델을 재구성하였다.

---

6. 23주차에서 이어질 작업

22주차 종료 시점에서 다음 주의 주요 작업은 아래와 같이 정리되었다.

• JWT 인증 오류 해결(22주차 미완료 과제)
• /health 전체 영역 API 구축(기본건강정보·알러지·만성질환·급성질환)
• 프론트 통합 테스트를 위한 스키마 및 API 구조 안정화

22주차 작업 결과를 기반으로 23주차에서는
건강 정보 전반의 CRUD 작업이 본격적으로 시작될 예정이었다.

---

7. 총평

22주차는 협업을 기반으로 한 API 및 데이터 구조 조정이 핵심이 된 기간이었다.
프론트의 요구사항 전달을 시작으로
DB 스키마, API 스펙, 엔드포인트 구조가 연속적으로 수정되었고,
인증 오류로 인한 반복적인 실패에도 불구하고
각 문제를 분석·정비하며 전체 시스템의 일관성을 확보하였다.

다수의 에러를 경험하는 과정에서
데이터 모델링·API 구조 정합성 확보·예외 처리 등
서비스 백엔드의 안정성을 높이기 위한 중요한 경험을 축적한 시기였다.