2.프로젝트 설계 - 요구사항 정의, DB

🦮 스스로를 위한 프로젝트 일지 가이드

1️⃣ 프로젝트를 진행하며 '왜' 그렇게 했는가

2️⃣ 어떤 문제가 생겼고, 어떻게 해결하였는가

3️⃣ 프로젝트를 되짚어보며 개선할 점이 있는가

 

이 포스팅에서는 당시 어떤 과정으로 요구사항과 DB를 설계했는지 되짚어 보고자 한다.

 

✅ 요구사항 정의

 

1️⃣ '왜' 그렇게 했는가

일단 학원에서 배운 부분(CRUD, 유효성 체크 등)은 기본이라고 생각하여 다 구현하고자 했었다.(클라이언트 입장에서도 다 기본적으로 당연히 있어야 하는 기능들이다.)

그렇게 회원가입, 로그인, 수강후기 게시판을 만들기로 했고,

또한 강좌 조회/신청 서비스가 프로젝트의 핵심이었으므로 강좌에 대한 안내/신청 페이지도 당연히 필요했다.

회원별 강좌를 관리하려면 마이페이지 기능도 당연히 필요했다.

쓰고 보니 기본만 한참 하다 끝난 것 같은...

 

2️⃣ 어떤 문제가 생겼고, 어떻게 해결하였는가

3️⃣ 개선할 점이 있는가

 

당시 00님과 요구사항을 정의할 때 정의서에 체계적으로 적기보다 종이에 러프하게 써내려가며 했다.

그래서 디테일한 기능은 대체적으로 서로 맡은 페이지를 만들어가면서 생각해 내어 구현했던 것 같다.

사실 프로젝트 기간이 한정되어 있고 경험이 부족하여 기능을 완성하는 데 소요될 시간을 짐작하기가 어려워 디테일하게 적기 어려운 부분이 있기도 했다.

하지만 만약 실무 프로젝트라면 고객이 원하는 기능이 분명하게 있을 것이다.

그런데 요구사항을 디테일하게 정의하지 않았다면 혹시나 고객이 요구하지 않았던 방향으로 기능을 구현할 수 있고, 시간과 노력이 낭비되면서 확실히 문제가 될 것이다.

나중에 누군가에게 이러이러한 기능이 있다고 프로젝트를 설명할 때도 요구사항 정의서가 있어야 명확하게 설명할 수 있을 것이다.

따라서 개선할 점은 설계 시 요구사항을 정의서에 체계적으로 디테일하게 명시하는 것이다.

 

✅ 결론부터

 

위 사진은 팀원 00님과 회의하며 설계한 DB 초안이다.

요구사항을 바탕으로 어떠한 테이블을 만들지 상의하여 6개의 테이블을 구성했다.

테이블명, 컬럼명, 자료형, 길이, 제약조건을 모두 상의하여 통일된 형식을 만들었다.

 

1️⃣ '왜' 그렇게 했는가

 

✅ 테이블 및 컬럼 구성

 

1)강좌

프로젝트 주제가 강좌 조회/신청 및 관리 서비스라 당연히 필요했다.

강좌고유번호 - 동적 CRUD 쿼리에 파라미터로 넣기 가장 간단한 형태는 문자보다 숫자고, 다른 테이블에서 외래키로 활용하기에도 좋을 거라고 판단했다. 튜플은 100개 이상 만들진 않을 거라고 판단하여 길이는 2로 설정했고, 유일성과 최소성을 만족하여 기본키로 설정했다.

강좌명, 기관명, 강좌일정, 강좌시간, 모집인원, 신청인원, 강사명, 강의대상 - 모두 사용자에게 필요한 정보다. 강좌 정보를 어떤 식으로 작성할지 예시를 적어보며 형식을 정했고, 그 형식을 바탕으로 자료형과 길이를 설정했다.

대기정원까지 컬럼에 추가할까 했지만, 대기정원을 반영하려면 신청인원이 다 찬 후에 반영해야 하는데, 테스트 시 튜플 넣고 하는데 시간이 너무 오래 소요될 것 같아 일단 보류하였고 결론적으로 넣지 않았다.

 

2)회원

프로젝트에서 제일 기본적인 로그인 기능을 구현하려면 당연히 필요한 테이블이었다. 나중에 스프링 시큐리티를 적용하며 며 컬럼이 추가됐다.

아이디 - 중복되지 않아야함 -> 유일성, 공백이면 안됨 -> not null, 최소성까지 만족하여 기본키로 설정했다.

이름, 휴대폰번호 - 회원정보 조회/수정 기능을 고려해 넣기로 하였다. 이름은 한글 기준으로 5자까지, 휴대폰번호는 -포함해서 13자까지...(이름 길이 정하면서 우리나라에 이름이 제일 긴 사람은 몇글자일까 궁금했다)

 

3)수강후기

게시판 기능을 구현하고 싶었기에 수강한 강좌에 대해 회원들끼리 후기를 올리는 게시판을 고안해서 탄생했다.

수강후기번호 - 강좌고유번호와 동일

작성자 아이디 - 수강후기 작성/수정/삭제 시 작성자를 구분하는 파라미터로 아이디가 적절하다고 판단하여 외래키로 설정했다. 나중에 회원 탈퇴 기능을 구현하면서 제약조건을 on delete set null로 수정하였다.

강좌고유번호 - 회원별 수강한 강좌를 조회할 때 사용하기 위해 외래키로 설정했다.

 

4)댓글

00님이 댓글 기능을 구현하고 싶어하여 만들었다.

작성자 아이디 - 회원 탈퇴 시 댓글도 없어지는 걸로 정하면서 on delete cascade로 정했다.

 

5)수강강좌

회원별 수강한 강좌를 조회/취소할 때 필요한 테이블이었다.

 

6)수강후기 사진파일

파일 업로드/다운로드 기능을 구현하고 싶어 만들었다. 파일명 컬럼을 수강후기 테이블에 쓸까 고민했는데, 하나의 게시물에 두 개 이상의 파일을 첨부한다고 가정할 때 데이터가 중복되므로 테이블 정규화를 해야 한다고 판단했다.

 

 

✅ 가독성, 편리성, 통일성

 

요구사항을 바탕으로 어떤 테이블을 만드느냐도 중요하지만, 혼자가 아닌 팀원과 함께하는 만큼 테이블을 설계하며 가장 중요하게 생각한 부분은 가독성, 편리성, 통일성이었다.

 

가독성 : 테이블/컬럼 이름은 의미를 바로 유추할 수 있도록 최대한 직관적으로 지었고, 컬럼 이름은 타 테이블의 컬럼과 헷갈리지 않도록 테이블 앞글자를 따서 지었다.

편리성 : 쿼리 작성 시 시간을 조금이라도 단축할 수 있도록 테이블/컬럼 이름은 되도록 짧게 지었다. (처음에 댓글 테이블 이름을 comment로 하려다가 조금 긴 것 같아서 00님과 고심 끝에 나온 결과물 reply..😂) 

통일성 : 테이블명, 컬럼명, 자료형, 길이, 제약조건을 의논하여 통일했다.

 

2️⃣ 어떤 문제가 생겼고, 어떻게 해결하였는가

 

테이블 설계 과정에서 의견 충돌이나 갈등은 없었다.

지금 생각해보니까 나는 프로젝트 때 원하거나 생각하는 바가 확실해서 의견을 내는 스타일이었고, 00님이 잘 수용해 준 것 같다. 고마워요..ㅠㅠ

나한테 일어났던 문제는 아니지만, 다른 조였던 xx님이 후에 말하기를 자기 조는 처음에 테이블 설계를 안 하고 일단 각자 시작해보고 나중에 맞추자, 라는 식으로 진행했단다.

그러다가 나중에 코드 취합할 때 테이블명 컬럼명 등등이 다~~ 달라서 취합하는 데 시간도 오래 걸리고 어려웠다고...

그래서 설계가 중요한 거구나, 느꼈다.

 

3️⃣ 개선할 점이 있는가

 

기능이 추가되면서 테이블 컬럼도 추가된 적이 있었는데, 돌이켜보니 내가 테이블을 수정하고 나서 바로바로 00님에게 공유를 안했던 것 같다.

기능을 다 구현하고 나서야 이거이거 구현하느라 테이블 이렇게 수정했다 공유했던 것 같은...

이 부분은 내 커뮤니케이션 능력이 부족했다. 팀원 간 업데이트는 바로바로!