데이터베이스에 대한 기본적인 개념을 다졌으니 본격적으로 ‘모델링’에 대해 알아보자. 데이터베이스 모델링이란, 데이터의 생성부터 운영, 관리까지 이르는 전체 프로세스를 명확하고 구체적으로 표현(문서화)하는 것을 의미한다. 이번 글에서는 데이터베이스 모델링의 첫 번째 단계인 요구 사항 분석하기에 대해 설명하고자 한다.
■ 데이터베이스 모델링, 왜 필요한가?
보통의 데이터베이스는 용량, 관리 인력 등 리소스에 한계가 있기 마련이다. ‘난 모르겠고, 일단 다 저장해보자’, 하고 때려넣다가는 금방 자료가 꼬이거나 비효율적으로 운영하게 될 것이다. 확장성에 문제가 생길 수도 있다.
따라서 ‘어떤 데이터’를 ‘어떤 관계’로 그려서 데이터베이스에 저장할지를 사전에 잘 설계할 필요가 있다. 기획자 입장에서 데이터베이스를 공부해두면 좋은 이유도 마찬가지다. 말도 안되는 요구 사항을 할 가능성이 줄어들고, 초반에 어디까지 고민해야하는지 좀 더 명확해진다랄까.
■ 데이터베이스 모델링 단계
데이터베이스 모델링 단계는 크게 4가지로 나눌 수 있다. 요구 사항 분석 > 개념적 데이터 모델링 > 논리적 데이터 모델링 > 물리적 데이터 모델링이고 각각의 단계에서 요구사항 분석서, ERD, 관계형 데이터 모델, SQL이라는 산출물이 생기게 된다. 그리고 나서는 애플리케이션을 개발하고, 보안 및 관리를 하는 단계로 넘어간다.
각각의 단계에 대한 상세 설명은 차후 글에서 다루도록 하고, 오늘은 먼저 요구 사항 분석 과정에 대해 알아보겠다.
■ 1단계: 제안 요청서(RFP, Request for Proposal) 작성하기
제안요청서는 말그대로 개발자 또는 외주 업체에게 “이러이러한 기능을 가진 서비스가 필요한데 할 수 있니?”라고 개괄적으로 보내는 문서를 말한다. 보통 공공기관에서 제안요청서를 작성해서 공고를 내기 때문에 샘플을 확인해보면 좋을 것 같다. 대략적인 구성 항목은 다음과 같다. 내부 프로젝트를 한다면 이 단계는 사전 회의를 통해 회의록으로 대체해도 좋다.
1. 개요 –> 이 프로젝트는 말이야…
어떤 업무를 요청하는지 알려주는 항목이다. 사업에 대한 개요, 즉 프로젝트명, 기간, 예산, 계약을 한다면 어떤 조건인지 등에 대해 설명한다. 또한, 이 사업의 필요성과 목적, 현황에 대한 정리, 추진 일정 등이 필요하다.
2. 요청 사항 –> 내가 원하는 건 이거, 이거야.
프로젝트의 산출물을 미리 그려보고, 어떤 것이 필수적으로 구현되어야 하는지, 어떤 것들이 구현되었으면 좋을지 구분하여 작성해두면 추후에 업무 일정과 범위 협의하여 마일스톤을 세팅하는 데 도움이 된다. 기능/성능/인터페이스/DB 외에도 보안, 유지보수 등 포괄적으로 작성해야 한다.
3. 제안서 작성 가이드 –> 그래도 제안서니까 이런 형식에 맞춰줄래?
내부 프로젝트라면 상관없겠지만 , 외주 업체에 발주는 내는 거라면 제안서 작성에 대한 가이드를 주면 좋다. 기본적으로 공고 프로세스, 선정 기준, 예상 일정 등이 필요하다. 만약 요청하는 양식이나 형식(ppt, word, pdf) 있다면 제시해준다. 제안서에 들어갈 목차와 제출처에 대한 안내도 넣는다.
■ 2단계: 요구 사항 명세서(SRS, Software Requirements Specification) 작성하기
RFP로 요구 사항이 도출되었으면 이제 요구사항 명세서를 작성할 차례이다. 이 SRS에는 국제 표준(IEEE-Std-830)이라는 녀석이 있다. 표준에 대한 상세 내용은 구매를 해야… 하지만 대략적인 요구 사항에 대해서 이미 널려 있으므로 있다. 상세 내용은 다음의 블로그를 참조해보자.
내용을 살펴보면, 제안 요청서에 산발되어 있는 데이터를 정리하여 하나의 문서로 만든 것이다. 아직은 상세 내용에 대한 설명(이해를 돕기 위해 서술형 문장이나 자료 첨부)이 있으며, 역할별로 각자 본인의 업무를 어떻게 수행할지, 요구 사항을 제대로 이해한 것이 맞는지 확인하는 작업을 진행하는 단계이다.
■ 3단계: 요구 사항 정의서 작성하기
요구사항 정의서는 요구사항이 명확한지, 완전한지를 검증하는 문서이다. SRS를 보고 요구 사항을 통합하거나 분리하고, 부족한 부분이 있다면 다시 요구사항 도출단계로 돌아가서 채워야한다.
또한, 요구 사항을 목록으로 정리한다. 어떤 요구 사항을 수행할지 안할지, 제약 조건이 있는지 등을 일목요연하게 정리해둔다. 물론 지속적으로 수정, 업데이트, 관리해야하는 문서다.
■ 요구 사항 파악은 1회성 태스크가 아니다!
지금까지 요구 사항 분석 프로세스에 대해 간략히 알아보았다. 물론 현실 세계에서도 이렇게 챡-챡-챡 진행 되면 좋지만 현실은…. 촉박한 시간, 비협조적인 구성원, 귀차니즘… 등등에 의해 진척되기 어려울 것이다. 무엇보다도 서비스를 만들고자 하는 사람도 내가 어떤 것을 원하는지, 고객은 어떤 것을 원하는지 한 마디로 정의하기 어렵다.
그렇기에 이번 글에서 다룬 내용은 1-2번으로 끝내는 태스크가 아니다. 기획을 엉성하게 해서 개발에 착수하면 노가다만 더 늘뿐이다. 가능하면 이해관계자들을 모두 모아서 대화를 하고, 서로 의견을 주고 받으며 정교화해나가는 것이 중요하고, 이 단계에서 “네가 기획잔데 왜 몰라?!” “네가 개발잔데 왜 몰라?!” 싸우지 않고 협업해나가는 것이 매우 중요하겠다.