[좌충우돌] (2) 시작부터 난관

제가 도와줄 스타트업의 서비스는 소비자와 기업을 잇는 B2C 플랫폼이며,

 

소비자가 원하는 상품과 기업을 찾고 정보를 얻어가거나,

다른 업체에 컨텍이 될 수 있게 도와주는 웹 플랫폼 입니다.

 

앞서 (1)장 에서 말씀 드렸듯, 

학부생의 스타트업이고, 빠른 개발과 베타 서비스가 초기 목적이었어서

기존에 상세한 명세나 설계 없이 바로 바로 기능을 구현하는 개발을 수행했었기에,

당장 필요한 작업은 요구사항을 파악하고 설계를 하는것부터였습니다.

 

하지만 문제는

요구사항에 맞춰 서비스의 처음부터 우리의 입맛에 맞게 설계를 해야하는 것이 아니라,

기존의 DB, API 에 맞게 설계를 맞춰가야 한다는 것이었습니다.

 

물론 이전에도

초기 설계가 결국 나중에 서비스 개선과 오류수정에 투입되는 비용보다 훨씬 적다는 사실을 알고있었을것입니다.

그럼에도 대학생의 스타트업 입장에서

투자를 받고, 대회에 참가하는 성과를 거두기 위해 어쩔 수 없는 판단을 했었었고,

 

그러기에 현재 다시 서비스를 돌아보며 재설계와 구현이 필요하다고 이야기 했습니다.

 

 

그럼 이제부터 설계부터 이야기를 시작해보겠습니다.

 

설계없이 구현된 서비스, 어떻게 헤쳐나갈까?

대부분의 프로젝트, 토이 프로젝트라도 기획과 더불어 가장 중요한 것은 설계라고 생각됩니다.

그렇기에 여태껏 시간을 많이 투자하더라고 구현 전에 설계를 집중적으로 신경을쓰면서 프로젝트를 진행해왔습니다.

 

하지만 이번에는 정반대의 상황에 봉착했습니다.

구현은 되었지만, 설계가 없습니다.

(마치 있었는데 없었습니다.. 같은 느낌)

 

그래서 저와 함께 새롭게 투입된 백엔드 개발자 둘이서 한 주 정도 서비스를 직접 이용해보면서

어떤 기능들이 있을지, 각 페이지에 필요한 데이터들은 무엇이 있을지,

인증 방식은 어떠한지, 서비스 사용 시나리오 등

기능 요구사항은 어떠하고 어떤 데이터가 주고 받아지는지를 분석했습니다.

 

(1) 인증 기능

   - 카카오 인증

 

(2) 탐색 기능

   - 상품 탐색

   - 업체 탐색

 

(3) 검색 기능

   - 상품 검색

   - 업체 검색

   - 기타 검색

 

(4) 커뮤니티 기능

   - 게시글

   - 댓글

 

(5) 상품 상세

   - 후기

   - 좋아요

 

(6) 기사 기능

   - 꿀팁 공유

   - 꿀팁 스크랩

 

(7) 백오피스 기능

   - 업체 생성

   - 업체 수정

   - 상품 등록

   - 상품 수정 및 삭제

 

(8) 회원 기능

   - 정보 조회

   - 정보 수정

   - 탈퇴

 

위 내용들을 바탕으로 기존 담당자에게 기능 명세 정리를 요청했고

기능별 어떤 요구사항들이 있는지 정리받았습니다.

 

정리된 기능 요구사항

이렇게 초반 기능 요구사항에 대해서 정리를 한 후에,

기존에 사용중이 ERD를 바탕으로 디비와 클래스 설계에 들어갔습니다.

 

이 시점에서 우리의 고민점은 아래와 같았습니다.

 

기존 디비의 스키마를 그대로 유지해야할까?

사실 전체적인 작업에서 가장 많이 고민하고 신중했던 부분이 바로 데이터베이스와 관련된 문제들이었습니다.

 

이유는 

현재 실제로 운영되는 데이터베이스였고, 실제 사용자들의 데이터가 담긴 상태이며

함부로 삭제하거나 수정하면 개인정보에 대한 법적인 문제가 발생할 수 있다는 부담감이 존재했습니다.

또한 상품과 업체의 데이터 역시 실제 등록된 업체들, 또한 우리 스타트업은 

이 데이터들로 금전적 이득을 바라는 바이기에,

모든 데이터의 변경 혹은 삭제는 곧 돈과 직결된 문제였습니다.

 

하지만 진짜 문제는 따로 존재했습니다.

위에서 말한 문제는 그냥 데이터베이스를 그대로 옮기고, 서버만 갈아끼우면 해결되는 문제긴했지만

정작 진짜 데이터베이스의 스키마들이 마음에 들지 않았습니다.

 

데이터베이스와 관련된 부분은 사람의 취향에 따라 다른 문제이고, 소속된 조직, 기업의 정책에 맞춰 개발해야하는 부분이지만,

현재 저희 스타트업은 DBA가 있는것도, 정해진 정책이 있는것도 아니였기에 싹 갈아 엎겠다고 생각했습니다.

테이블의 네이밍이 복수형식으로 되어있다. 또한 카멜케이스로 구성이 되어있다.

쓰지않는 테이블이 존재

무엇을 의미하는지 모르는 필드명

FK 인데, 외래키 관계가 아닌 직접 주입을 사용하는 id Key 값

일정하게 증가하지 못하는 PK값 

또한 사용하지 않는 필드도 존재하고, 사용자에게 권한이 부여되는 필드가 존재하지 않으며,

특정 타입이나 상태 등을 나타내는 필드는 enum 보다는 int 를 사용하여 명시적으로 뜻을 전달하지 못하는 등

여러가지로 고칠 점이 많았습니다.

 

따라서 우리는 기존 데이터는 최대한 유지하되, 테이블명, 필드명을 정리하고 정규화를 시킬 필요가 있다고 판단했습니다.

그래서 데이터가 담기지 않고, 활용을 하지 않는 필드들은 과감히 지워냈고,

테이블과 필드들의 네이밍 규칙을 새롭게 정의하여 ERD를 구성하였습니다.

 

하지만 위 문제중 pk 와 관련된 문제는 어쩔수없이 안고가되, 앞으로 새롭게 추가되는 pk 에 대해서만

순서를 지키도록하였습니다.

이유는 저 pk 가 단독적인 것이 아니라, 다른 테이블의 레이블과도 여러 매핑을 맺고있으므로,

한 pk 를 수정하면 다른 관련된 fk 도 수정해야하는 문제점이 있었기 때문입니다.

(수작업으로 해주어도 수 백개의 데이터를 실수 없이 한다는 보장이 없어, 데이터의 무결성을 보장하지 못할 수 있다고 판단했습니다.)

 

또한 honeyTip과 관련된 문제도,

이때 운영중인 서비스는 honeyTip이라는 게시글을 서버에서 관리하는 것이 아니라,

프런트에서 정적으로 띄어주는 방식으로 운영되어 조회수와 SEO 와 같은 문제로 해당 honeTip에 

수작업으로 id 를 부여하는 방식으로 관리되고 있었습니다.

 

따라서 honeytip을 서버에서도 관리하도록 새로운 테이블을 생성해주었고,

추후에 이에 맞춰 API 를 통해 생성과 수정, 조회가 되도록 개발을 진행했습니다.

 

이에 맞춰 새로운 클래스를 설계했습니다.

 

다음 게시글에서 새로운 클래스 다이어그램과 API 설계를 진행하는 과정에 대해 이야기 드리겠습니다.

 

긴 글 읽어주셔서 감사합니다.

 

 

 

 

 

"daehwan2yo"   contact

software, soongsil univ  <  now

udsward@gmail.com  < email

https://github.com/daehwan2yo<    git

daehwan2yo - Overview