설계도와 실제 사이

프로젝트에 exERD 로 만든 설계 파일이 있었다. 표와 관계가 그림으로 보였다. SHOW CREATE TABLE 로 실제 스키마와 맞는지 확인해 보기로 했다.

Open Table of contents

양쪽 방향으로 어긋났다

비교해 보니 설계도에는 있는데 실제에는 없는 컬럼이 있었다. 반대로 실제에는 있는데 설계도에 없는 것도 있었다. 어긋남이 한 방향이 아니라 양쪽으로 나 있었다.

설계도를 만든 뒤에 실제를 고친 것도 있고 설계도만 고치고 적용하지 않은 것도 있었다. 어느 쪽이 나중인지 파일만 봐서는 알 수 없었다. 그래서 어느 쪽이 정본인지부터 정해야 했다.

코드는 MySQL 을 쓰고 exERD 파일은 보지 않는다. 설계도가 무엇이라고 적혀 있든 도는 것은 실제 쪽이다. 그러니 정본은 실제 스키마였다.

틀린 설계도는 없느니만 못했는데 있으면 그것을 믿고 실제를 안 보기 때문이다. 실제로 설계도를 보고 컬럼이 있는 줄 알고 코드를 쓴 사람이 있었다. 없는 것보다 나쁜 문서가 있다는 것을 그때 알았다.

데이터가 이미 들어 있어서 MySQL 을 설계도에 맞출 수는 없었다. 그러면 반대로 실제에서 읽어 와 다시 만드는 방향이 된다. exERD 에 그 기능이 있어서 돌려 봤다.

구조는 정확하게 따라왔는데 사람이 적어 둔 설명이 전부 사라졌다. 이 컬럼이 무엇을 뜻하는지 적어 둔 것들이었다. 구조는 실제에서 읽어 오면 되지만 설명은 실제에 없었다.

설계도의 진짜 값이 구조가 아니라 설명이라는 것이 그때 드러났다. 구조는 언제든 실제에서 읽어 올 수 있다. 사라지면 곤란한 것은 사람이 쓴 설명 쪽이었다.

그래서 설명을 테이블과 컬럼의 COMMENT 로 옮겨 MySQL 안에 담았다. SHOW CREATE TABLE 에 같이 나오니 다시 읽어 와도 따라온다. 담아 두지 않고 그때그때 읽어 오는 구조가 되니 낡을 것이 없어졌다.