티스토리 뷰

 

안녕하세요, 미시깽입니다.  요즘 화두가 되고 있는 주제 중의 하나가 바로 빅데이터(Big Data) 입니다.  어쩌면 빅데이터라는 키워드가 이슈로 떠오른 이유를 추론해보면, IT가 발전되며 시간이 오래 지나면서 "회원데이터=돈"이라는 단순한 인식을 뛰어넘어, 점차 통계학적으로나 마케팅 방법론으로 데이터베이스를 해석하게 됨에 따라 회사에서 "물건을 팔아 수익을 남긴다."의 개념이 아닌, "필요로 하는 사람에게 물건을 팔아 수익을 남긴다"는 개념변화를 통해, 공식적인 매출을 내기위한 도구로 활용되기 시작한게 바로 이 DB가 아닌가 생각됩니다.(사실 빅데이터 이전에도 DW나 CRM등으로 DB를 활용한 내용들은 꾸준히 연구, 분석되어 오긴 했습니다.) 

 

DB설계와 개발의 상관관계?!

 

생각보다 많은 기획자들이 오해하고 있는 것 중 하나가 기획부터 개발까지의 프로세스인데, 기획안을 만들면 디자이너에게 전달되고, 디자이너가 디자인을 하고 나면 코더 또는 퍼블리셔에게 전달되고(이 과정이 생략되고 디자이너가 코딩을 하는 경우도 많죠.) 그 뒤 코딩된 파일이 개발자에게 전달되고 바로 개발이 시작된다고 생각하는 것인데, 이 과정에서 중요한 프로세스인 DB 설계과정을 고려하지 않는 겨우가 많습니다. 

 

기획부터 개발까지의 과정은 이렇습니다..

 

일반적으로 많은 웹사이트를 운영하는 회사들이 DB 설계과정을 간과하고 넘어가다보니 이렇게 생각할 법도 합니다만, 실제로는 디자이너가 디자인을 하고, 코더가 코딩을 하는 사이, DBA가 기획안을 보며 DB를 설계하고, 개발하거나 혹은 디자인이 들어가는 동시에 DBA가 기획안 내 정의된 각종 DB요소들을 기반으로 DB를 설계하는 것이 보다 정확한 웹개발 프로세스라고 볼 수 있습니다.

 

DBA가 무엇에 쓰는 물건인고?

DBA는 "DataBase Administration"의 약자로 쉽게 이야기하면 데이터베이스를 관리하는 관리자로 데이터베이스 시스템을 원활하게 수행하도록 데이터베이스의 전체적인 운영관리를 담당하는 포지션.

 

보통 DB 설계이슈가 중요한 비중을 차지하는 게임회사나 서비스 규모가 큰 회사들은 프로젝트에 DBA가 포함되어 진행되기도 하는데요.  DB 설계를 어떻게 해서 개발하느냐에 따라 웹사이트의 속도에도 지대한 영향을 미치기 때문에 비록 눈에는 잘 보이지 않지만, 매우 중요한 부분이라 할 수 있습니다.

 

 

DB를 구성하는 일은 쉽지 않아요.

 

DBA가 DB설계를 하기 위해서는 기획안을 보고 전체적인 프로세스를 이해하고 데이터의 흐름을 정리해서 설계를 하고 DB를 구성해야하는데요.  저 같은 경우에 거의 십여년 전 오라클 DBA 교육과정을 들은 정도고, 실제로 전문 DBA로서 실무를 해본적이 없기 때문에, 제가 설명하는 내용이 완전하다고 할 수느 없습니다. 개발자로서 DB를 만드는 역할은 했었어도, DBA로서 DB를 만드는 역할을 해본 적이 없다는 건 분명히 차이가 있는거죠.

 

보통 전문 DBA가 DB를 만들때는 DB 운영의 효율성을 중심으로 만들게 되지만, 개발자 입장에서 DB를 만들때는 개발의 편의성을 좀 더 중시하게되다 보니 DB 운영의 효율성이 우선순위에서 밀리게 되는건.. 어쩔 수 없는 부분인거죠.  그렇기 때문에라도 DB설계나 개발 및 운영은 전문 DBA가 해야한다고 잠시 생각해봤는데, 여하튼 DBA가 하는 업무에 대한 정의는 굉장히 많지만, 지금 말씀드릴 주제는 아니니 일단 지나갑니다. 


앞서 DB 설계를 하기 위해서는 기획안을 통해 전체적인 데이터의 흐름을 정의하고, 각각의 데이터 흐름에 대한 구체적인 정의를 시작하게 되는데, 먼저 테이블 명세서라는 것을 작성하게 됩니다.  테이블명세서는 특별한 양식이 있거나 하진 않지만, 대략 비슷한 내용들이 명시되게 됩니다. 테이블에 대한 설명, 테이블의 속성값들, 그 값들에 대한 설명이 들어가게 됩니다.

 

 

기획안을 보면서 최대한 뽑아낼 수 있는 각각의 속성들을 뽑아내서 테이블을 만들고, 그 안에 속성들을 컬럼으로 소화시키게 됩니다.  즉, 기획안 안에 있던 모든 데이터들이 DB로 만들어질 수 있도록 모두 끄집어 내게 되는 거죠. 여기까지 정리되면 이 내용들을 바탕으로 본격적인 ERD를 제작하게 됩니다.

 

ERD는 "ERWin" 이라는 프로그램을 많이 사용하는데요, 이 프로그램을 통해 명세서에 있는 내용들을 작성하며 옮기게 되는데요.  여기서 ERD는 "Entity Relationship Diagram"의 약자로 그 의미와 작성의 이유는 아래와 같습니다.

 

1. 개략적으로 데이터 및 데이터들의 관계를 표현한 도식화된 그림.

2. 분석가들은 조직의 데이터를 이해하고 이를 응용프로그램에 반영하고자 ERD를 작성.

3. 엔티티(Entity)란 데이터베이스에 저장할 정보의 주체 또는 대상을 의미.

4. ERD에서 엔티티는 네모로 표기.

 

데이터와 데이터들의 관계를 표현하기 위해 그리는 ERD는 크게 "Logical"과 "Physical" 두 가지로 작성해야 하는데요.  Logical은 하드코딩이라고 생각하셔도 됩니다. 직관적인 테이블에 대한 설계그림인데요. 테이블 이름, 그리고 컬럼마다의 이름이 들어가게 됩니다. 적어도 어떤 내용을 담는 상자이고, 그 상자에 가지런히 분류되어 나누어 들어가는 명칭이 뭔지 한눈에 알아볼 수 있게되는거죠.  화살표로 연결된 선들을 통해 테이블간의 관계도 일단 확인이 가능하구요.  어떤 선이던간에 연결되어 있다면 서로 연관이 되어 있다고 생각하시면 됩니다.

 

ERD의 Logical 설계화면. (네모박스안의 요소가 Entity)

Physical은 DB서버 안에 정의될 내용 그 자체라고 생각하시면 되는데요.  실질적으로 DB서버 안에서 사용될 이름, 사이즈까지 정의되게 됩니다. 테이블간의 관계까지 정의가 되면, ERWin을 이용해서 이 내용 그대로 데이터베이스에 넣어 정의된 내용으로 테이블 생성 및 관계까지 생성이 가능합니다.

 

ERD의 Physical 설계화면.

위와 같은 순서는 프로젝트의 성격이나 회사내 업무흐름 순서에 따라 얼마든지 변경 가능한 것이고, 어디나 제가 위에 설명한대로 운영되지 않는다는건 꼭 유념해주시구요. 테이블 명세서의 경우에는 공공기관 프로젝트가 아닌 이상 작성하지 않는 경우도 많습니다. 

 

 

참고로 저 같은 경우엔 팀 막내나 신입들 스터디 차원에서 명세서를 그리게 하는데요. 테이블명세서의 작성이 끝나고 시간이 허락한다면 해당 테이블을 ERD로 그려보라고는 하지만, 사실 개발자에게 그렇게까지 시키기에는 무리가 있어서 테이블명세서 정리 정도로 지시하는 편이며, 이 정도의 과정을 진행하는 것으로도 기존에 구축된 DB를 이해하는데 큰 도움이 되곤 합니다.


이렇게 설계된 DB 설계도(Schema)를 바탕으로 실제 사용자 화면에 뿌려질 데이터의 정보를 불러오기 위해 사용해야하는 테이블들에게서 필요한 정보를 추출하기 위한 DB 프로그래밍 하고, DB에 대한 정보는 개발자에게 전달되어, 그 결과물을 가지고 화면개발에 들어가게 되는거죠.

 


기획안은 사이트 전체의 초석을 다지는 길!!

 

DBA가 ERD를 그리기 위해 근간이 되는 자료는 기획안일 수 밖에 없습니다.  기획안에 DB에 대한 내용이 어떻게 들어가냐는 의문을 가지실 분들도 계실텐데, 스토리보드를 작성하는 과정에서 구현설명 즉, 디스크립션을 넣게 된다는 것은 다 아실 겁니다.  여기서 "회원가입 영역"에서 입력하는 정보의 정의를 예로 들어본다면...

 

1. 아이디는 대소문자 구분 없이 영문만 허용하며 최소 4자에서 최대 10자까지 허용.

2. 비밀번호는 알파벳과 숫자, 특수문자의 조합으로 8자에서 15자까지 허용.

3. 비밀번호는 대소문자를 구분.

4. 이름은 15자까지 허용.

5. 일반전화번호는 입력받지 않음.

6. 휴대전화는 통신사(SK, KT, LGT) 3사와 식별번호(010, 011, 016, 019, 017) 및 전화번호를 입력 받음.

 

위와 같은 형태로 입력받는 정보의 정의를 내리게 되는데, 이러한 정보들이 개발과 DB설계 및 개발에 반영이 되는 것이죠.  여기서 아이디에 부여된 DB 관련된 정보는 "대소문자를 구분하지 않는다."와 "영문만 허용한다", "최소 4자에서 최대 10자"인데, 이러한 정보정의가 되었을 때, 개발자는 '4자 미만을 넣었을 경우, 4자 이상 넣어야 한다고 메세지를 띄워야겠구나..' 같이 10자 이상으로 넘어갈 수 없도록 제한을 걸게 되는 것이고, DBA는 회원정보테이블에 회원아이디에 대한 컬럼의 사이즈를 영문10자에 해당하는 사이즈로 설계할 수 있겠죠.


웹사이트에 대한 기획안은 사이트 완성도를 높일 수 있는 유일한 수단입니다.  기획안 작성만으로도 벅찬데 언제 이런 내용까지 다 생각하며 넣어야 하느냐고 생각하실 수도 있구요.  혹은 개발자가 꼼꼼이 보지도 않는데 그런거까지 언제 다 일일이 정리해넣느냐, 그냥 물어보면 대답하면 되고, 테스트할 때 이상있으면 수정해달라고 하면 되는거지. 라고 생각하실 수도 있을텐데요.

 

사람의 습관이란건 무섭습니다. 기획자가 기획안에 해당 내용 꼼꼼이 정의해주시고 개발자가 문의했을때 기획안에 있다고 확인해보시라고 하셔야 개발자도 자꾸 기획안을 한번 더 보고 하는거죠. 기획안 대충 보고 개발할 때 기획자한테 물어보지 뭐. 이렇게 되게 하지 마시고, 최대한 개발자가 묻는 질문들이 기획안에 들어가 있어야, 개발자가 기획안을 자꾸, 자주 볼 수 있게 하실 수 있답니다.


지금까지 DB 설계를 위한 문서인 ERD에 대해서 간략하게 정리해봤는데, 다음 편에서는 기획자가 ERD 설계도를 보고 이해할 수 있도록 ERD에 사용되는 각각의 용어와 부호의 의미에 대해서 정리하겠습니다.

 

 

 

 

미시깽. 토끼같은 귀여운 딸래미 둘과 사과같은 남편과 살고 있는 웹개발 13년차.  아이러브스쿨과 SK커뮤니케이션즈 등을 거쳐, 국회입법조사처와 한국지역정보개발원에서 IT관련 빡센 행정업무를 경험하고, 세훈항운(주)에서 다시 웹개발을 시작, 자회사인 (주)온필에서 기술개발팀장으로 있으면서, 여행업이라는 새로운 분야에 대해 배우는 마음으로 시스템 개발에 매진 중.

 

 

댓글
댓글쓰기 폼