규칙에 예외가 다섯 있었다

모든 테이블에 생성 시각과 수정 시각을 두기로 했는데 안 지켜진 것이 있어서 전수로 찾아봤다.

Table of contents

예외 다섯과 각각의 이유

시각 컬럼이 없는 테이블이 다섯 나왔고 각각을 열어 보니 넷은 이유가 있었다.

code_*           기준 자료. 언제 만들었는지 의미 없음
temp_import      임시 테이블. 매번 지우고 만든다
order_item_view  뷰. 컬럼을 못 넣는다
stat_daily       집계 결과. 집계 날짜가 이미 있다
legacy_backup    옛 자료. 옮길 때 그대로 가져왔다

마지막 하나만 그냥 안 넣은 것이었다. 위반 다섯이 아니라 정당한 예외 넷과 위반 하나였고 그 구분이 없으면 다섯을 전부 고치려 들게 된다.

예외의 기록과 검사 반영

예외를 규칙 문서에 적고 이름 규칙으로 표시했다. 특정 접두어가 붙으면 예외라는 것을 이름에서 알 수 있게 한 것이다.

검사 쿼리에서도 예외를 빼고 봤다. 빼지 않으면 매번 다섯 건이 나오고 그 상태가 이어지면 아무도 검사 결과를 안 본다. 상시로 붉은 검사는 꺼진 검사와 같다.

예외가 늘었을 때

몇 달 뒤 예외가 여덟이 됐다. 전체 테이블이 42개인데 여덟이면 19%다.

늘어난 셋을 보니 감사 로그와 세션과 캐시 항목이었고 전부 수명이 짧거나 시각이 이미 있는 것이었다. 예외의 성격이 우연히 겹치는 것이 아니라 한 방향을 가리키고 있었다.

목록 대신 조건

규칙을 다시 썼다. 목록을 나열하는 대신 조건으로 적었다.

자료가 오래 남고 언제 만들어졌는지가 필요한 테이블에
created_at, updated_at 을 둔다.

해당 없음
- 수명이 짧은 것 (temp_*, session, cache_*)
- 시각이 이미 있는 것 (stat_*, audit_log)
- 원본 유지 (legacy_*)
- 뷰

조건으로 쓰니 새 테이블이 생겨도 판단할 수 있다. 예외가 20%를 넘으면 규칙을 어기는 사람이 많은 것이 아니라 규칙의 조건이 잘못 잡힌 것이다.

새 테이블을 만들 때 판단하게도 했다. 전에는 만들고 나서 검사에 걸려 붙였는데 그때는 기존 자료의 시각을 알 수 없어 전부 같은 값이 됐다.

예외 표시의 남용

이름 규칙으로 예외를 표시하니 이름만 맞추면 예외가 되는 문제가 생겼다. 임시 접두어가 붙었지만 반년째 남아 있는 테이블이 있었다.

SELECT table_name, create_time FROM information_schema.tables
WHERE table_schema = 'app' AND table_name LIKE 'temp_%'
ORDER BY create_time;

만든 지 오래된 임시 테이블을 찾으니 셋이 있었다. 임시가 아닌 것은 이름을 바꾸고 규칙을 지키게 했다. 예외 표시가 회피 수단이 되지 않게 예외로 분류된 것들을 정기적으로 확인한다.

규칙이 없는 자리

예외를 정리하다 보니 규칙 자체가 없는 항목이 드러났다. 시각 컬럼과 기본 키 이름과 문자셋에는 규칙이 있는데 외래키를 걸지 여부와 소프트 삭제 방식과 인덱스 이름에는 없었다.

규칙이 없으니 테이블마다 달랐고 소프트 삭제만 세 가지 형태로 되어 있었다.

del_yn      18 테이블
deleted_at   6 테이블
is_deleted   2 테이블

가장 많은 형태로 통일하기로 하되 옛것을 다 바꾸지는 않고 새것부터 지키게 했다. 예외를 찾으러 들어갔다가 규칙이 없는 자리가 나온 셈이다.

정리

• 규칙을 만들면 예외를 찾는다
• 예외마다 이유가 있는지 보고 없으면 그것만 고친다
• 예외를 규칙에 적고 이름 규칙으로 표시한다
• 검사에서 예외를 빼고 본다. 상시로 붉은 검사는 꺼진 검사와 같다
• 예외가 늘면 규칙의 조건을 다시 본다
• 예외 목록 대신 조건으로 쓰면 새것도 판단된다
• 예외로 분류된 것들을 정기적으로 확인한다
• 예외를 찾다 보면 규칙이 없는 자리가 드러난다