생고기 업체 데이터베이스 디자인

온라인으로 생고기를 판매하던 한 회사에서 "우리 재고, 주문, 배송 관리를 위한 엑셀 시트가 곧 터질 것 같아요"라는 요청을 받은 지 어느덧 2주가 흘렀다.

엑셀로 충분히 관리 가능하면서도 운영이 복잡하지 않은 데이터베이스를 설계하는 작업을 맡았다. 그 과정을 되짚으며, 겪은 일들을 이야기해보려 한다. 하하.


[첫 번째 허들: ‘뉴비’와 ‘수기’로 감당하는 구조]


보통 IT 회사의 DB 구조(데이터베이스 스키마)를 보면, 프로그래밍적 유지보수, 서비스의 복잡도, 객체 간의 관계 등을 고려하여 만들어졌음이 티가 난다. 하지만 이를 오프라인 기반 소규모 생산업체에 그대로 적용하려 하면 여러 문제가 발생한다.

우선, 대부분의 소규모 회사에서 ‘관계형 데이터베이스’라는 개념 자체가 매우 생소하다.물론 어찌저찌 기록을 쌓다 보면 데이터베이스 비슷한 것이 만들어지고, 이를 관리하기 위한 관계형 구조 비스무리한 것이 생성되기는 한다.

문제는, 그렇게 만들어진 데이터를 IT 인프라에 기록하고 관리할 수 있는 사람,더 나아가 원칙에 근거해 처음부터 설계 및 유지보수를 할 수 있는 사람이 없다는 것이다.그렇기에 대부분의 데이터는 이런저런 엑셀 시트나 심지어 종이에 기록되고 운영되는 상태이다.
 
이런 환경에서 중요한 기준은 아래 두 가지다:
1. 누구나 이해 가능한 DB 구조인가?
2. 해당 구조의 테이블 수가 개인이 관리 가능한 정도인가?

누군가는 이렇게 말할 수도 있다:
 "그럼 BigQuery 같은 관리형 도구 쓰면 되는 거 아냐?"

 하지만 ‘클라우드’라는 말 자체가 IT 뉴비들에게 생소한 경우가 많다.거기에 ‘관리형 DB’라는 추가적인 개념까지 더하면, 이는 누군가에게는 그야말로 개 똥때리는 소리처럼 들릴 수 있다.


[두 번째 허들: 누구도 전체 프로세스를 모른다]

문제는, 누구도 회사의 전체 프로세스를 정확히 이해하지 못한다는 것이다. 예를 들어, 발주 → 생산 → 입고 → 재고 → 출고 → 배송이라는 과정에서, 어떤 데이터가 누구에 의해 기록되고 활용되는지 명확히 아는 사람이 없다. 더 나아가, 결국 어떤 데이터를 보고 싶고, 어떻게 사용하고 싶은지조차 모르는 경우도 많다.

물론 이는 모든 회사에 해당할 수 있는 문제다. 
하지만 IT 회사에서는 서비스 개발과 동시에 DB 설계가 진행되기 때문에,이런 문제가 크게 드러나는 경우는 적다(물론 IPO를 앞둔 상황이라면 다를 수 있지만).

초기 단계의 다양한 사업체에서는 이러한 문제를 해결하기 위해 DB 설계자가 [사장 → 매니저 → 실무자] 순으로 인터뷰를 진행하며 아래와 같은 질문에 답을 찾아야 한다:
1. 회사의 미션과 이를 뒷받침하는 핵심 객체는 무엇인가?
2. 회사의 데이터 흐름 내에 존재하는 테이블(객체)은 무엇인가?
- 혹은, 존재해야 할 테이블은 무엇인가?
3. 각 테이블의 존재 이유는 무엇인가?
4. 각 테이블에 포함될 컬럼(객체의 정보)은 무엇이며, 앞으로 추가될 가능성은 있는가?
5. 기타 등등…


[세 번째 허들: 설득하기]

데이터베이스 설계처럼 매출을 직접 창출하지 않는 활동은 그 중요성을 설득하기 쉽지 않다.

 IT 서비스라면, DB 설계 자체가 서비스 개발의 필수 과정으로 여겨진다.그러나 실물을 생산하는 업체에서는 "운영이 좀 더 나아질 것 같긴 한…" 정도로 인식되는 경우가 많다.

즉, 처음에 받았던 "엑셀을 개선해달라"는 요청과는 별개로, 설계를 맡은 사람은 중간중간 꾸준히 데이터베이스 설계의 중요성과 가치를 설명하고 설득해야 한다.


[네 번째 허들: …다음 글에서]

이 글에서는 데이터베이스 설계를 시작하며 마주했던 주요 허들을 다뤘다. 다음 글에서는 과연 어떤 방식으로 이 문제들을 해결했는지 그리고 그 과정에서 있었던 재미있는 에피소드를 나누려 한다. (다음 글도 기대해달라!)