개발자인가 설계자인가

DB 란 무엇인가.

Database 의 약자인 DB는 

쉽게말해 정보의 집합체 이다.

그럼 정보는 무엇일까? 세상의 온갖것들이 다 정보이다.

그럼 그 모든것들을 다 Data 라고 봐야하나? 그건 아니다. 

설계자로써 가져야 하는 기본 마음 가짐은 "의미없는 컬럼은 없다" 이다. 

예를들어 내가 어떤 음식을 좋아하고 어떤 게임을 즐겨하며 직원들과 몇번의 술자리를 갖는지 

가족관계는 어떻게 되고 우리 가족은 휴일에 무엇을 하는지 

이런 것들은 일종의 정보일수는 있지만 Data라고 볼 수 없다. 

Data란 "구축된.. 또는 구축되어야 하는 System에서 필요로 하는 정보" 이다.

고객들과의 분석 과정에서 우린 수많은 요구사항을 듣는다. 

물론 고객들은 필요한 것들을 요구한다.

하지만 우린 제한된 Resource 안에서 수행할 수 밖에 없고 

고객의 모든 요구가 Programming 적으로 합당한지 검토할 수 밖에 없다. 

또한 그안에서 품질(Quality) 가 나와야 한다.

그렇다면 분석/설계자 (이하 설계자) 무엇에 초점을 맞추고 진행해야 할까? 

지극히 개인적인 생각이지만 역시 한줄로 표현하면 

"의미없는 컬럼은 없다" 이다.

"컬럼(Column)"은 Data의 최소 단위 이다. 이 컬럼들이 모여서 

데이터의 집합체-테이블(Table)이 된다. 또 그 테이블이 모여 고객이 원하는 시스템의 

데이터베이가 되는것이다.

설계자는 이 컬럼의 필요성과 연결고리를 고려해야만 한다. 

또한 사용처를 고민하지 않을 수 없다. 컬럼은 전체적인 공수나 프로그램 수정에 직접적인 영항을 주기 때문이다.

예를들어 고객사의 현업 A씨는 '도착예정일자'가 필요 하다고 한다. 

이유는 단순히 예정일자를 관리하고 싶어서 이다.

이건 현업의 언어이다. 설계자는 저 요구사항에서 일단 컬럼을 생각한다. 

표준에 맞는 DB타입, 개발 언어나 공통에서 제공하는 부분이 있는지.. 

현재 Table 에는 있는지 등등 ... 근데 더욱 중요한건 

업무적으로 어떻게-어디서 쓰이느냐 또 다른 화면에 영향이 있는가 이다.

생각나는데로 몇가지 얘기해 보면 

- 검수 등의 스케쥴을 관리해야 하는가?

- 예정일자로 인해 스케줄 관리가 추가될 가능성이 있는가? 

- 현황을 보는 레포트에서 추가가 필요한가? 

- 현황을 보는 레포트가 없다면 레포트가 추가될 가능성이 있는가? 

- 날짜에 대한 계산을 해야하는 것인가? 

- 현재 화면(업무)을 참조하는 다른 화면에서는 필요하지 않은가?

- 예정일자가 지난 경우 어떻게 처리가 될것인가?  Alert 기능이 필요한가?

- 예정일자가 도래하고 있는경우 어떻게 처리해야 하는 것인가? Alert 기능이 필요한가?

- 현재 화면에 예정일자에 대한 조회 조건을 추가해야 하는것인가? 

- 프레임웍에선 어떻게 조회조건을 받고 있는가?

 등등 ... 

고객은 단순히 "도착예정일자가 필요해요" 한마디 한건데 너무 오버 한다고 느껴지는가? 

본인은 그렇지 않다. 실제로 많은 현업들은 지금 생각나는것을 말한다. 

더 실력이 좋은 현업들은 다음,, 그 다음 요구하기 위해 현재의 것을 요청한다. 

최종적으로 요청할 화면 또는 프로세스가 너무 커지므로 조금씩 구현 시켜놓는 것이다. 

고객의 요구를 무시하자는 말이 아니다. 

거의 대부분의 요구에는 컬럼이 필요하고 설계자가 그것을 어떻게 받아 들이는지가

일정과 직접적인 연관이 있으니 이런 작은 쨉(?) 들을 단순하게 받아들이면 안된다는 것이다. 

설계자는 언제나 고객요구사항-일정-개발자-품질 의 한 가운데에 있다.

정해진 기일까지 최상의 품질로 모두를 만족 시켜야 하는 그런 어려운 일을 하고 있다.

그런 설계자 이기에 항상 모든 요구 하나하나에 무게를 두고 일을 해야한다.