어느덧 Spring 숙련 과정 2주차가 흘러가고 있습니다. 이번 주는 TODO 서비스 만들기에 돌입하면서, 쉴 새 없이 코드를 붙잡고 씨름하는 시간을 보냈습니다. 처음 TODO 서비스를 접했을 때는 '간단한 CRUD 기능만 구현하면 되겠지?'라는 안일한 생각도 잠시 들었지만, 막상 프로젝트를 시작하고 보니 생각보다 고려해야 할 사항들이 많았습니다. 특히 데이터베이스 설계를 위한 ERD(Entity-Relationship Diagram) 작업에서부터 예상치 못한 난관에 부딪히며, 설계의 중요성을 다시 한번 깨닫게 되었습니다.
데이터 모델링, 고민의 흔적들
TODO 서비스의 핵심은 사용자가 할 일을 등록하고 관리하는 것이기에, 데이터 모델링에 심혈을 기울였습니다. 가장 먼저 사용자 정보를 담는 USER 엔티티를 설계했습니다. 사용자를 식별하는 USER_ID를 기본 키로 설정하고, 비밀번호, 이름, 이메일, 계정 생성일 등의 속성을 정의했습니다.
다음으로, 할 일 카드를 담는 CARDLIST 엔티티를 설계했습니다. CARDLIST_ID를 기본 키로 설정하고, 리스트 생성일, 리스트 내부 카드 개수, 그리고 해당 리스트를 생성한 사용자의 USER_ID를 외래 키로 연결하여 사용자-리스트 간의 관계를 명확하게 표현하고자 했습니다.
마지막으로, 실제 할 일 내용을 담는 CARD 엔티티를 설계했습니다. CARD_ID를 기본 키로 설정하고, 할 일 완료 여부를 나타내는 STATUS 속성을 추가했습니다. 처음에는 CARD 엔티티와 CARDLIST 엔티티 간의 관계를 어떻게 설정해야 할지 고민이 많았습니다. CARD 엔티티에 CARDLIST_ID를 외래 키로 설정하여 CARD가 특정 CARDLIST에 속하도록 하는 것이 일반적인 방법이지만, 확장성을 고려하여 다대다 관계를 설정하고 중간 테이블을 두는 방식도 고민했습니다. 결국, 현재는 CARD 엔티티에 CARDLIST_ID를 외래 키로 설정하는 방식으로 결정했지만, 앞으로 서비스가 확장됨에 따라 관계 설정 방식을 변경해야 할 수도 있다는 생각을 하고 있습니다.
ERD 설계를 진행하면서, 각 엔티티 간의 관계를 명확하게 정의하고 데이터의 정합성을 유지하는 것이 얼마나 중요한지 깨달았습니다. 예를 들어, 사용자가 삭제될 경우 해당 사용자가 생성한 CARDLIST와 CARD는 어떻게 처리해야 할지, CARDLIST가 삭제될 경우 해당 CARDLIST에 속한 CARD는 어떻게 처리해야 할지 등을 꼼꼼하게 고려해야 했습니다. 이러한 고민들을 통해 데이터 모델링은 단순한 테이블 설계가 아니라, 서비스의 전체적인 구조와 흐름을 결정하는 중요한 과정임을 알게 되었습니다.
앞으로 나아가야 할 방향
ERD 설계를 마무리하고 나니, 이제 본격적인 개발에 착수해야 할 때입니다. 앞으로는 ERD를 기반으로 데이터베이스를 구축하고, API를 개발하여 사용자 인터페이스와 연결하는 작업을 진행할 예정입니다. 2주차 과제를 통해 데이터 모델링의 중요성을 깨달았듯이, 앞으로도 끊임없이 배우고 성장하는 개발자가 되기 위해 노력할 것입니다. 예상치 못한 문제에 직면하더라도, 포기하지 않고 끈기 있게 해결해 나가면서 TODO 서비스를 완성해나가겠습니다.