성급한 설계가 불러온 구조 변경의 결과
개인 프로젝트를 시작하면서, 외부 API 데이터를 수집해 데이터베이스에 저장하기 위해 간단한 구조의 ERD를 먼저 설계하고, WebClient를 이용한 데이터 수집 및 저장 작업을 시작했습니다.
초기에는 단순한 여행지 정보만 처리할 계획이었기 때문에, ERD도 최소한의 구조로 간단하게 설계하여 개발을 시작했습니다. 하지만 프로젝트를 진행하면서 기능을 추가하거나 수정하는 과정에서 전체적인 방향을 충분히 정리하지 않은 채 작업을 이어가다 보니, DB 구조가 계속 변경되었고,
여기에 DB 설계 역량이 부족했던 점까지 더해져 테이블을 반복적으로 수정하는 데 많은 시간을 소모하게 되었습니다.
그 결과, 기존 테이블 구조의 변경은 물론 테이블 간 관계 설정도 반복적으로 손봐야 하는 상황이 발생하게 되었습니다.
특히, 외부 API의 데이터 구조를 충분히 분석하지 않고 개발을 서둘렀던 점이 이후 구조 변경의 가장 큰 원인이 되었다.
ERD 재설계
DB 구조를 어차피 전반적으로 수정해야 하는 상황이었기 때문에, 기존 ERD의 문제점부터 파악해보았습니다.
처음에는 외부 API에서 제공하는 식별값(content_id 등)을 PK로 사용하면 안 된다는 개념에 익숙하지 않아, 중간에 대체 키(id)를 도입하긴 했지만, 설계에 일관성이 없어서 오히려 불필요하거나 애매한 구조가 되었습니다.
이에 따라 ERD를 전면적으로 수정하며 다음과 같은 원칙을 적용했습니다:
- 모든 테이블에 내부 식별용 id를 AUTO INCREMENT로 생성하여 기본키(PK)로 사용
- 외부 API가 제공하는 식별값(content_id 등)은 비즈니스 키로 보고 UNIQUE 제약조건만 부여
이러한 구조로 변경함으로써, 외래 키(FK)가 비즈니스 키의 변경에 영향을 받는 문제를 예방할 수 있었고, 데이터의 정합성과 유지보수성도 함께 개선할 수 있었습니다.
개선된 ERD
