1-1. 왜 지금 "설계"를 배우는가

지금까지 데이터베이스 입문과 기본을 통해 다음과 같은 것들을 이미 익혔다고 가정한다.

• CREATE DATABASE, CREATE TABLE 로 데이터베이스와 테이블을 만든다.
• SELECT, INSERT, UPDATE, DELETE 로 데이터를 다룬다.
• JOIN, 서브쿼리, 인덱스, 트랜잭션으로 실무에 가까운 쿼리를 작성한다.

겉으로 보기에는 이 정도만 알아도 웬만한 서비스를 충분히 만들 수 있을 것처럼 느껴진다. 그래서 흔히 이런 생각을 하게 된다.

"그냥 필요한 데이터가 생길 때마다 CREATE TABLE로 테이블 만들고, 빠진 컬럼 있으면 ALTER TABLE로 추가하면 되지 않나?"

실제로 많은 초기 프로젝트가 이렇게 시작한다. 그런데 서비스가 커지고, 데이터가 쌓이고, 요구 사항이 복잡해질수록 설계 없이 쌓아 올린 구조의 한계가 그대로 드러난다.

이 문제를 이해하기 위해, 집을 짓는 과정을 떠올려본다.

• 튼튼한 집을 짓기 위해 가장 먼저 하는 일은 설계도를 그리는 일이다.
• 방은 몇 개가 필요한지, 어디에 배치할지, 기둥은 어디에 세울지, 전기와 수도 배선은 어떻게 연결할지 미리 계획한다.
• 설계도 없이 감으로만 집을 짓기 시작하면 초반에는 빠르게 올라가는 것처럼 보이지만,
  • 문이 제대로 안 닫힌다.
  • 벽에 금이 간다.
  • 하중을 잘못 계산해서 구조적으로 위험해진다.

데이터베이스도 똑같다. 설계는 집으로 치면 구조와 뼈대에 해당하는 작업이다.

• 초반에는 "테이블 하나 더 만들면 되지" 수준으로 보이지만,
• 잘못 설계된 테이블 구조는 시간이 지날수록 성능, 데이터 무결성, 유지보수성을 동시에 갉아먹는다.

이렇게 초기에 설계 없이 진행한 선택은 나중에 기술 부채(Technical Debt) 로 되돌아온다.

• 처음에는 빠르게 개발한 것처럼 보인다.
• 시간이 갈수록 작은 기능 하나 수정하는 데도 엄청난 시간이 든다.
• 결국 "처음부터 설계를 다시 했어야 했다"라는 말이 나오게 된다.

이 글의 목표는 바로 이 지점에서 출발한다.