[Project design] 기본 설계(화면 설계와 DB설계)

안녕하세요. 명월입니다.

이 글은 기본 설계(화면 설계와 DB설계)에 대한 글입니다.

이전에 프로젝트 공정에 대해서 설명했습니다.

링크 - [Project design] 프로그램 공정(워터폴 vs 애자일)

프로젝트 공정이란 전체적으로 프로젝트를 어떤 순서로 진행을 할 것인지 설정하는 것이라면 기본 설계는 프로그램을 어떻게 만들 것인지 설정하는 것입니다.

워터폴 공정에서의 기본 설계는 보통 UML(Unified Modeling Language: 통합 모델링 언어)의 유즈 케이스, 엑티브 다이어그램을 통해서 유저가 프로그램을 어떤 목적으로 사용할 것인지 어떻게 사용할 것인지 설정하는 것입니다. 꼭, 유스 케이스나 엑티브 다이어그램이 아닌 스토리 보드를 통해서 설정하는 방법도 나쁘지는 않습니다.

유즈 케이스 출처 - https://www.javatpoint.com/

엑티브 다이어그램 출처 - https://sourcemaking.com/

스토리 보드 출처 - http://nmasse.com/

이러한 방법의 장점은 프로그램의 목적을 정확하게 설정할 수 있고 고객과 프로그램을 같이 작성하는 멤버와 의사 소통의 편리함과 결과물에 확실한 목표 설정이 가능하다는 장점이 있습니다. 문제는 공정에 이런 수고까지 넣으면 시간이 엄청나게 길어진다는 단점이 있습니다. 그리고 다음 상세 설계나 코딩의 공정으로 넘어갔을 때, 고객과 유저의 추가 요청 사항이 생길 시에 변경의 유연성이 상당히 까다로워 집니다.

그도 그럴 것이 추가 사항이 변경이 되면 다시 기본 설계를 수정하고 거기에 순차적인 공정을 모두 수정해야 하는 수고가 발생하기 때문입니다.

그러기 때문에 저의 경우는 따로 UML과 스토리 보드를 통한 설계를 생략하는 편입니다.

그러나 아예 생략하기에는 프로그램의 목표를 설정하기 어렵기 때문에 저는 화면 설계로 대체하고 주석으로 스토리 보드의 흐름를 작성합니다.

화면 설계라는 것은 따로 엑셀이나 파워포인트로 작성하는 것이 아니고 Apache를 띄어 놓고 Visual code를 통해서 직접 html를 작성합니다.

이러한 장점은 웹 프로그램이라는 것은 WAS(Web Application Server)로부터 파싱된 html를 브라우저로 전송하는 것입니다. 즉, 기본 설계를 작성하더라도 코딩할 때 어차피 해야할 작업이라는 것입니다.

데이터 영역(.json)은 예제이기 때문에 실제와 약간은 달라질 수 있겠습니다만 html로 직접 작성하고 설계를 하는 개인적으로는 매우 보기 편하지 않을까 싶습니다.

그리고 유즈 케이스나 엑티브 다이어그램을 작성한다고 하더라도 정확한 프로그램 산출물이 아니기 때문에 발주자가 생각하는 프로그램과 개발자가 작성하는 프로그램의 차이가 발생할 수 있는데 이렇게 직접 화면을 html로 작성하면 그러한 갭을 상당히 줄일 수 있고 추가 요청이나 수정이 있어도 어차피 화면을 수정해야 하는 부분이기 때문에 유연성도 꽤 좋습니다.

이러한 방법의 단점 물론 존재합니다. html 태그와 css, javascript를 확실히 알아야 작성할 수 있는 영역이기 때문에 이러한 스킬이 부족하게 되면 역시나 작성이 힘들 수 밖에 없습니다. 사실 개인적으로 웹 프로그램 개발자가 html 태그와 css, javascript를 모르다는 것은.... 그런데 있긴 있더라구요..

그리고 html를 직접 작성하는 부분이기 때문에 시간 역시 꽤 걸리는 작업입니다. 그러나 제 생각은 개발자가 마우스 끄적끄적하는 것보다 키보드로 여러 코드를 팍팍 작성하면서 문서를 만드는 것이 무언가 간지(?)가 난다는 이런 구닥다리 개념이 있는 사람이라 이런 방법을 선호합니다.

그리고 이렇게 화면 설계를 하고 하서 DDL(Data Definition Language: 데이터 정의 언어)를 작성합니다.

DDL이라는 것은 정의 언어이기 때문에 간단하게 테이블을 만드는 것입니다. 그리고 그것을 스크립트 파일(.sql)로 관리를 합니다.

그러나 화면 설계와 다르게 DDL로 작성하게 되면 전체적인 관계도 테이블이 잘 확인이 되지 않습니다. 그러나 프로그램 개발에 도움이 되는 무료툴이 정말 많습니다.

제가 최근에 자주 사용하는 DB browser 툴로는 dbeaver가 있습니다.

링크 - Dbeaver (무료 데이터 베이스 접속 툴)

이게 개인적으로 dbeaver 툴이 굉장히 편한데 이 툴에서는 테이블을 작성하면 자동으로 ER를 작성해 주는 기능이 있습니다.

스크립트를 작성할 때는 큰 그림이 잘 보이지는 않지만 이렇게 툴을 이용하면 따로 ER를 만들거나 문서를 만들지 않아도 되는 장점이 있네요.

개인적으로 기본 설계는 이런 식으로 진행을 합니다.

이러한 방법의 큰 장점은 어차피 해야할 작업을 설계 쪽으로 당겨서 함으로 전체 공정의 시간을 많이 단축할 수 있고 추가 사항, 수정에 대한 유연성이 매우 좋습니다. 단점은 역시 개발자가 아니면 작성할 수 없는 기본 설계 방식입니다. 즉, 위 방식으로 운영하기에는 팀원의 개발 스킬이 필요하다는 것입니다.

여담으로 저는 일본에서의 개발 경력이 전체 경력에서 많은 비중을 차지하는데 일본의 프로젝트에서는 팀 맴버가 개발자가 아닌 맴버가 꽤 있습니다. (개발자라고는 하는데 태그나 디비를 전혀 다를 줄 모르는 사람이 존재한다는...-_-;;)

물론 테스트를 할 때는 개발자가 아니여도 별 상관이 없는 데, 문제는 이런 사람들이 설계도 한다는 것입니다. 그래서 그런지 개발 프로젝트에 완전한 워터폴 공정으로 프로젝트를 진행하는 경우가 많습니다. 자기는 기본 설계랑 상세 설계만 하고 실제 개발(코딩)은 다른 사람에게 미룬다는...

일본 이외의 한국이나 미국에서는 팀내에 개발자 비중이 꽤 높은 편이라 저는 위의 방식으로 채택하여 프로젝트를 진행하는 경우가 많습니다.

위 방법론이 반드시 정답은 아닙니다만, 적어도 저한테는 잘 맞는 공정인 듯 싶습니다.

여기까지 기본 설계(화면 설계와 DB설계)에 대한 글이었습니다.

궁금한 점이나 잘못된 점이 있으면 댓글 부탁드립니다.