프로젝트 초기, 총 3주 기간 중 2일을 온전히 데이터베이스 설계에 투자했습니다. 처음에는 제공된 예시 테이블을 기반으로 작업을 시작했으나, 실제 비즈니스 시나리오를 고려하며 다양한 케이스를 검토했습니다. "한 아이템에 여러 거래처가 존재한다면?", "제품의 가격은 어떻게 저장해야하는가, 단순 정가와 거래처별 가격 거래시점 가격 등이 있을 텐데" 등의 질문을 스스로 던지며 요구사항을 확장하다 보니 관계 테이블의 수가 증가했으며, 데이터를 담는 데 한계가 느껴졌습니다. 이러한 복잡성을 해결하기 위해 실무 중심의 데이터베이스 설계 원칙을 학습했습니다. 특히 공통코드 테이블을 통한 코드 관리와 Header-Detail 구조의 일대다 관계 설계 방식을 도입해 확장 가능하고 체계적인 데이터베이스 구조를 구축할 수 있었습니다.
설계 작업을 단독으로 진행했기 때문에, 기존 기획서보다 훨씬 확장된 구조에 대한 팀원들의 이해가 필수적이었습니다. 이를 위해 설계 의도와 각 테이블 간의 관계를 문서화했으며, 왜 이러한 설계 방향을 선택했는지에 대한 근거를 명확히 제시했습니다. 또한 프로젝트 진행 중 팀원들이 필요에 의해 테이블이나 컬럼을 수정할 경우, 모든 변경사항을 문서에 기록하도록 하여 버전 관리와 일관성을 유지했습니다. 문서화와 더불어 정기적인 팀 설명회를 통해 모든 팀원이 동일한 수준의 이해도를 갖도록 지속적으로 소통했습니다.
DB 설계를 하면서, 단순히 테이블을 만드는 게 아니라 프로젝트의 큰 흐름을 잡는 일이라는 생각이 들었습니다. 데이터 구조를 어떻게 짜느냐에 따라 앞으로 개발할 기능의 방향이 달라지는 것을 보며, 설계 단계의 중요성을 다시 한번 느낄 수 있었습니다.
설계 과정에서 Leadtime 개념을 도입하여 실제 제조업의 자재 관리 프로세스를 반영하고자 했으나, 실제 구현에서는 이 기능을 충분히 활용하지 못했습니다. 이는 3주라는 제한된 프로젝트 기간에서 1주차는 설계와 퍼블리싱, 마지막 주차는 문서 작업과 발표 준비로 인해 실제 개발에 집중할 수 있는 시간이 부족했기 때문입니다. 향후 프로젝트에서는 설계 단계에서 구상한 고도화된 기능들을 실제 구현까지 연결할 수 있는 충분한 개발 기간 확보가 필요하다고 느꼈습니다.
아래는 실제 초기에 설계한 ERD 및 DDL문을 나열했습니다. DDL문의 경우 초기 설계에 수정사항이 생기면 팀원들이 코멘트를 추가하도록 했습니다.