증상 가이드는 자유 본문이 아니라 정형 폼
가이드가 Quill 자유 본문이었다면, 증상 가이드는 정반대로 정형 폼입니다. 대표질환/원인, 집에서 체크할 것, 팁, 참고자료(정상/비정상 사진 묶음) 같은 구조화된 항목을 리스트로 관리해야 했습니다. 그래서 자식 테이블을 5개 두는 구조(symptom_suspected_diseases, symptom_home_checks, symptom_tips, symptom_references, symptom_reference_images)로 V4에서 새로 만들었습니다.
연관 관계, 처음엔 단방향이었다
처음 만든 "함께 보면 좋아요" 연관은 증상 가이드가 다른 증상 가이드만 가리키는 단방향 구조였습니다. 그런데 실제로 필요한 건 증상 가이드에서 일반 가이드로도, 가이드에서 증상 가이드로도 넘나드는 양방향 혼합 연관이었습니다.
그래서 V6에서 symptom_guide_relations를 drop & recreate해서 다형적 참조로 바꿨습니다.
복합 PK (symptom_guide_id, target_type, target_id)
target_type: GUIDE | SYMPTOM
target_id는 FK 없음 — 무결성은 애플리케이션 레벨에서 보장
target_id가 guides 테이블을 가리킬 수도, symptom_guides 테이블을 가리킬 수도 있어서 DB 레벨 FK를 걸 수 없습니다. 대신 역참조 인덱스 (target_type, target_id)를 추가해서 조회 성능을 확보하고, 삭제 시 애플리케이션에서 양쪽 참조를 직접 정리하도록 했습니다. 같은 문제가 일반 가이드 쪽에도 있어서 V7에서 guide_relations도 동일하게 다형적으로 바꿨습니다.
수정 API에서 자식 처리 방식을 나눈 이유
증상 가이드 수정은 PUT 전체 교체입니다. 그런데 자식 테이블을 전부 "삭제 후 재생성"으로 처리하면 복합 PK를 쓰는 연관 테이블에서 delete→insert 순서에 의존하는 문제가 생깁니다. 그래서 규칙을 나눴습니다.
- 단순 PK 자식(대표질환/체크/팁/참고자료+사진): 전체 교체
- 복합 PK인 연관가이드: 변경분만 반영하는 diff 처리
같은 "수정" 작업이라도 데이터 구조에 따라 다른 전략을 쓴 겁니다.
이번 편 요약
- 증상 가이드는 정형 폼 + 자식 테이블 5개 구조
- 연관 관계를 단방향에서 GUIDE|SYMPTOM 다형적 양방향 참조로 리팩토링 (V6, V7)
- 전체 교체와 diff 처리를 자식 테이블 구조에 따라 나눠서 적용
다음 편에서는
기능 얘기는 잠시 접어두고, 배포 이야기로 넘어갑니다. SSH로 배포하다가 계속 타임아웃이 나서 결국 러너를 자체 구축한 사연입니다.
