시설에 거주하는 청소년들의 교통비 지원 사업을 운영 중인 T재단. 우편📮을 통해 사업 지원서를 받고 [엑셀 파일.xls]로 사업 현황을 관리하던 T재단은 재단 사이트 리뉴얼을 의뢰하며 사이트에 [지원 사업을 관리할 수 있는 시스템 구축]을 함께 요청함
🚇앞서 T재단의 사이트 리뉴얼 프로젝트를 기획, 운영한 기획자 A는 과거 타 재단의 고교생 장학 지원 시스템을 기획한 경험을 살려 T재단의 지원 사업 시스템을 기획하기로 함
기획자 A가 경험한 타 재단 장학 지원 시스템은
- 관리자 페이지에서 2020년 장학 사업을 발행(?)하면
- 사용자 페이지에 신청 페이지가 열리고
- 해당 사업에 신청한 학생들의 신청 데이터(신상, 학적, 계좌 정보 등)가 쌓이는 구조로
- 2020년 사업엔 2020년 학생 데이터만 하위로 맞물려있는 구조였다.
🚇<타 재단 장학 지원 시스템의 주체가 재단 학생>이었다면 <T재단의 지원 사업 주체는 재단 시설담당자 학생> 으로 달랐다.
기획자 A는 이전과 마찬가지로 2020년 사업이 열리면 2020년의 시설담당자가 2020년의 시설과 학생 정보를 입력하는 구조로 T재단 시스템을 기획 하였다.
- 이는 매년 세 덩어리의 데이터가 연관되지 않고 새로 쌓이는 구조로 만들어 졌다.
- 한마디로 종이 장부 같은 시스템
시스템 개발 막바지에 T재단 현업 책임자가 시스템 구조 자체에 대한 문제제기를 하였다. T재단 책임자가 예상했던 시스템은 매년 사업은 새로 등록되더라도 한 번 등록한 시설과 학생 정보는 새로 등록할 필요 없이 유지되는 구조였던 것
<aside> 💁🏻♂️ "매번 이용할 때마다 회원가입해야 하는 서비스도 있던가요?"
</aside>
이미 시스템 개발 막바지였던 상황. 일개 사원에 불과했던 기획자A는 상사 몰래 개발팀에 빌어가며 조금씩 시스템을 고치려다 개발팀의 난색과 고객사의 압박을 못 견딜 때가 돼서야 상사에게 보고하는 잘못된 대처를 함. → 초기 DB 설계가 잘못되면 엎고 새로 만들어야 할 수 있다!
이 에피소드에서 기획자 A가 관계형 DB 설계에서는 "정규화(Normalization)"가 필요하다는 것을 알고 있었으면, 보다 나은 결말을 맞을 수 있었을 것이다.