캡스톤 디자인 PART.1주차(프로젝트 기획, 설계 단계)

서론

캡스톤 디자인을 시작합니다. 캡스톤이란 집을 지을 때 지붕이나 담 위에 마지막 얹는 갓돌(capstone) 이란 뜻으로 집을 짓는 행위입니다. 그 동안 공부한 내용을 기반으로 완벽한 서비스를 하나 만들어 보는 것입니다. 이제 제 마지막 학교 생활이 시작되었습니다.!

 

본론

- 팀 빌딩

캡스톤은 반드시 5명이 팀을 이뤄 진행해야 하며 안 될 경우 랜덤으로 5명이 배정됩니다. 저희 팀은 동기 3명과 후배 1명으로 구성되며 동기 두 명이 풀스택, 저와 동기 한 명이 DB 관리자와 서버, 후배 한명이 풀스택을 담당하여 팀을 이뤘습니다.

 

- 프로젝트 기획 단계

1. 프로젝트 주제

=> 아이디어 thinking

1) AI 활용 : 처음에는 AI 모델을 활용하는 프로젝트를 하고자 하였습니다. 동아리에서 만든 GAN 모델, QA 모델이 있었고 이를 활용하여 웹 서비스로 제공하는 것입니다.

2) 학과 홈페이지 개선 : 동기 중 한 명이 학과 홈페이지 관리자입니다. 현재 운영하는 학과 홈페이지의 졸업 관련 페이지를 분리한다고 하여 그 부분을 처음부터 끝까지 설계부터 구현 및 배포까지 해보는 것입니다.

=> 아이디어 선정

원래는 1번을 하려고 하였으나 실제 서비스를 운영해보는 경험이 매우 값지다고 생각하여 2번으로 결정하였습니다. 저는 졸업 페이지와 챗봇 도우미를 만들고 관리하는 개발자로 투입될 것입니다. 이때 챗봇은 규칙 기반 챗봇으로 ai를 사용하지 않을 것입니다.

 

=> 협업 방식

올해 초에 진행한 네트워크형 캠퍼스 아카데미에서 적용한 방식대로 진행합니다.

 

1) 데일리 미팅 : 매일 정오, 오후 7시
2) PR : 오후 7시 백엔, 프엔 각자 진행한 부분 발표하고 PR 진행

3) 주간 목표 정하기 : 매주 금요일 캡스톤 대면 수업시
4) 보고서 작성 방식 : 쓰기로 한 날 모두 모여서 부여된 파트 작성 등

※ 필요한 보고서ⓛ 프로젝트 계획서, ② 요구사항 명세서, ③ 프로젝트 설계도(구성도), ④ 다이어그램(시퀀스, 클래스, ERD)

5) 역할 : 팀장, 데일리 회의록 작성(개개인의 오늘 한 일, 추후에 할일을 적고 팀의 목표, 일정 변동 사항 등을 적음) 등

6) 협업 툴 : 형상관리 = 깃/ 스케쥴 = 노션 등
7) 타임라인 작성

2. 깃허브 규칙

1) 브랜치 규칙

 

2) 커밋 규칙

3) 깃 브랜치 전략

실제 운영을 대비하여 운영 브랜치와 기능 개발 브랜치를 분리하는 전략으로 진행합니다. dev 브랜치에서 프로젝트 개발을 진행하고 stg 브랜치에서 운영환경으로 이관하기 전 최종 테스트를 거칠 것입니다.

 

3. 주제 구제화

모든 팀원이 동일한 주제를 생각하도록 구체적으로 동기화 해보겠습니다.

학과측의 요청으로 홈페이지가 곧 SI 업체에 의해 개편되고 관리된다고 합니다. 그 중 졸업 논문 서비스는 코드 설계상 오류로 현재 정상 작동하지 않아 업체 관리 대상에서 제외되었고 학과측에서 학교 자체 서버에서 졸업 논문 서비스를 유지 보수 및 관리 해줄 것을 CS-HOME(제 동기가 속한 학과 홈페이지 관리자 팀)에 요청하게 되어 이 주제로 캡스톤을 진행하기로 했습니다.

여기서 저는 전체적인 백엔드 설계와 졸업 페이지를 구현하고 챗봇을 서비스에 적재하고 운영, 관리하는 역할입니다. 실제 서비스에 사용할 기능을 기획해보고 만들어 보는 최고의 경험이 될 것 같습니다!

 

=> 요구사항 분석

1) 프레임워크 변경 : servlet/jsp로 구성된 레거시 코드를 spring/jsp로 변경
2) DB 리모델링 : 졸업논문 서비스가 정상 동작하지 않는 이유를 DB 문제로 보고, 테이블 재설계
3) 관리자(조교) 기능 : 

4) 유저(학생) 기능 : 
5) 졸업 도우미 챗봇 기능

 

요구사항 명세서를 작성하면서 비로소 팀원 모두 프로젝트를 확실히 이해할 수 있습니다. 작성 및 요구사항 리서치 관련 내용은 1, 2주차 요구분석에서 자세히 다룹니다.

 

=> 서비스 기능, 설계 정리

1) 설계 : 전체적인 서비스 상세 구현, DB 다이어그램, UI 디자인 설계
2) 기능 : 로그인, 조교 챗봇 등(참고 1)

 

=> 기획서 작성 및 발표

1) 기획서

 

2) 발표 자료

 

- 프로토타입 작성

졸업 도우미 홈페이지부터 챗봇 연결까지의 프로토타입을 다룹니다. 이 내용은 1, 2주차 프로토타입 작성에서 자세히 설명하겠습니다. (참고 5)

 

- 프로젝트 설계 단계(= 설명 및 피드백 필수)

1. DB 설계(참고 1)

DB 설계는 요구사항에 맞게 카테고리를 보고 설계합니다. 논리적 모델링, 물리적 모델링, 인덱싱 순서로 설계합니다.

 

최종 논리적 모델링

논리적 모델링 결과물입니다. 프로젝트를 진행하면서 개발 상황에 따라 변동될 가능성이 있는 부분입니다. (참고 4) 본격적으로 자세히 제 생각을 설명해보겠습니다.

 

1) 학생 테이블

(잠시 데이터 타입을 표시합니다.) 기본키인 id, 유저가 로그인할 때 필요한 로그인 id와 비밀번호가 있습니다.

 

졸업 방식과 졸업 단계를 학생 테이블의 컬럼으로 넣었었는데 졸업이라는 카테고리가 학생과 1 : n 관계로 생각되어 분리하였습니다. 학생 테이블에서 졸업 신청을 역추척할 수 있게 졸업 id를 외래키로 두었습니다.

 

2) 관리자 테이블

기본키인 관리자 번호가 존재하고 로그인, 회원가입을 위한 아이디, 비밀번호가 존재합니다.

 

3) 공지사항 테이블

 

기본키 공지사항 번호가 존재하고 공지사항 게시글을 게시판에 고정할 때 필요한 고정 컬럼이 있고 Boolean을 위해 BIT로 타입을 설정했습니다.

 

한명의 학생은 여러 공지사항에 댓글을 달 수 있고 하나의 공지사항에는 여러 학생이 댓글을 달 수 있어서 학생과 공지사항을 댓글을 다는 관계로 만들어 주었습니다.

 

하나의 공지사항에 여러개의 첨부파일을 달 수 있어서 1 : n 관계로 만들었습니다.

 

4) 진행일정, 게시판, 안내 및 내규, 엑셀 관리

이 테이블들은 관계를 가지고 있지 않고 텍스트 형식으로 본문 데이터 컬럼만 가지고 있습니다.

 

논리적 모델링을 참고하여 물리적 모델링을 합니다. 이후 실행 계획을 통해 인덱스를 넣을 것입니다. 이렇게 뿌리가 될 ERD 설계를 마쳤습니다. 간단한 10개의 테이블이지만 엄청나게 고민한 것 같습니다.

 

2. 프론트엔드 UI 설계(기능 명세서 필요)

 

+ 페이지별 기능 명세서

프론트의 페이지의 흐름과 기능을 명세합니다.

 

3. 백엔드 도메인 엔터티 설계

StudentNoticeBoard가 위에 DB 설계에서 만든 학생과 공지사항이 댓글을 작성하는 관계 매핑 테이블에 해당합니다.

 

원래 M : N 관계에서 테이블을 만들 때는 매핑 테이블을 만들고 엔터티 설계에서는 양쪽 테이블에 List를 두지 매핑 테이블을 만들지 않습니다.

 

하지만 이 경우는 StudentNoticeBoard가 M:N의 매핑 테이블로 보일 수도 있지만 그렇게 되면 엔터티를 설계하는데 List 대신 매핑 테이블을 만든 것이라서 의문입니다. ✅

 

이렇게 설계한 이유는  StudentNoticeBoard는 여기서 매핑 테이블이 아니고 댓글이라는 별도의 테이블이라서 데이터를 양쪽에 List를 두는 것보다 별도의 엔터티를 만드는 것이 맞다고 생각했습니다.

 

5. 백엔드 도메인 별 협력 관계 설계

1) 관리자 도메인

이 어플리케이션에는 관리자와 회원 도메인이 있습니다. 관리자 도메인을 요구사항에 맞게 다이어그램을 설계합니다. 관리자는 로그인하여 관리자 기능을 수행합니다. 관리자는 회원가입을 할 필요없이 DB에 미리 넣어 놓을 것입니다.

 

관리자는 공지사항을 조회, 수정, 삭제, 등록할 수 있고 고정해서 맨 위로 올릴 수 있습니다.

 

관리자는 진행일정을 수정할 수 있고 진행 일정 게시판을 관리할 수 있습니다.

 

관리자는 안내 및 내규를 관리할 수 있습니다.

 

관리자는 학생 상세 조회를 통해 유저 졸업 신청서를 조회 및 다운로드 할 수 있고 대상자 전체 조회와 엑셀 관리 등 학생 전체 목록을 볼 수 있으며 유저별 졸업 논문 진행 상황을 조회할 수 있습니다.

 

2) 회원 도메인

관리자 도메인을 요구사항에 맞게 다이어그램을 설계합니다. 유저는 회원가입과 로그인으로 유저 기능을 사용합니다.

 

학생은 졸업 신청을 할 때 졸업 방식을 선택하고 각종 신청서를 제출하게 됩니다.

 

학생은 게시판에서 관리자가 작성한 글들을 확인하고 댓글을 달 수 있습니다.

 

6. 백엔드 도메인별 클래스 다이어그램 설계

1) 관리자 도메인

관리자 도메인 협력 관계를 보고 클래스 다이어그램을 만듭니다.

 

2) 회원 도메인

회원 도메인 협력 관계를 보고 클래스 다이어그램을 만듭니다.

 

7. 서비스 제공 흐름

1) 로그인

 

2) 공지사항 관리

 

3) 진행일정 관리

 

4) 안내 및 내규 관리

 

5) 졸업 대상자 졸업 관리

 

6) 공학인증 관리

 

 

8. 챗봇 설계

챗봇 설계는 챗봇을 만드는 설계가 아니고 전체 기능 중 챗봇 기능을 구현하기 위해 백엔드 개발자가 해야할 것을 차근차근 새로운 블로그 페이지에 작성할 것입니다. > 이 부분이 제게 할당되어 제가 지금까지 배운 프로젝트 방법 그대로 진행해 보겠습니다.

 

※ 원래 챗봇이 분리되는게 아니고 위 프로젝트 설계에 함께 있어야 하는 것입니다! (캡디 5, 6에 같이 정리해 두었습니다. 참고 6)

 

 

결론

- 느낀점

캡스톤이라고 하면 앱, 웹을 만들거나 새로운 서비스를 만드는 것만 생각해서 처음에 주제를 들었을 때는 걱정이 되었습니다. 하지만 캡스톤의 진정한 의미를 생각해보면 모레와 흙으로 집을 짓는 것입니다. 졸업 도우미를 기획하고 설계하고 최종적으로 서비스하는 것은 지금까지 배운 내용을 모아 그럴 듯한 결과물을 만드는 것이라고 생각할 수 있습니다. 무엇보다 실제 사용할 서비스에 제가 만든 기능을 넣어 운영까지 해보는 것은 엄청난 경험이 될 것입니다.

이제 진짜 마지막 4학년이 시작됩니다. 공부한 내용을 차근차근 활용하여 직접 만들어보는 캡스톤의 정의를 실현하고 졸업하겠습니다.

 

 

참고

DB 모델링

교양 과목 추천

요구사항 명세서

DB 설명

프로토타입

캡디 5, 6