안녕하세요.

레거시 시스템을 유지보수하다 보면 "이게 왜 이렇게 되어 있지?"라는 생각이 들 때가 많습니다. 처음에는 동작하는 코드니 그냥 넘어가곤 했지만 시간이 지나면서 이런 작은 의문들이 쌓이기 시작했고, 어느 순간 "이건 정말 개선해야겠다"는 확신이 들 때가 있습니다.

오늘은 그중 하나인 제조사 공통 코드 관리 방식에 대한 고민을 공유하려 합니다. 단순히 "DB vs ENUM"이라는 기술적 선택의 문제가 아니라, 우리가 다루는 데이터의 본질이 무엇인지, 그리고 그것을 어떻게 관리해야 하는지에 대한 고민에 대해 공유합니다.

문제 인식: 4개 데이터를 위한 테이블이 필요할까?

담당 솔루션에는 제조사 정보를 관리하는 테이블이 있습니다. 구조는 아주 단순합니다.

-- manufacturer 테이블
id | name
---+----------
1  | APPLE
2  | SAMSUNG
3  | LG
4  | HEASU

처음 이 테이블을 봤을 때 "아, 제조사 네이밍을 저장하는 테이블이구나" 정도로만 이해했지만 이 시스템을 몇 달 운영하면서 이상한 점들이 눈에 들어오기 시작했습니다.

제조사 이름을 조회할 때마다 위 테이블을 FULL SCAN 합니다. 기업 내부망에 위치해 있다는 특성상 4건의 FULL SCAN은 큰 성능 문제가 아니였으나. 매번 화면을 렌더링 하기위해서 이 작은 테이블을 읽기 위해 SELECT * FROM manufacturer 를 태운다는게 계속 신경쓰이기 시작합니다.

그러다 문득 이런 생각이 들었습니다.

"4개의 고정된 값을 위해 테이블을 만들고, 매번 쿼리를 날리는 게 맞나?"

더 신경 쓰이는 건 변경 이력이었습니다. 히스토리를 통해 추적해보니 이 테이블은 개발 초기인 2021년에 생성된 이래 단 한 번도 수정된 적이 없었습니다.

이쯤되면 이건 '데이터' 라기보다는 '상수'에 가까운 게 아닌가? 라는 생각이 들었고 지금 구조가 단순 상수를 DB에 저장하여 렌더링 때마다 매번 불필요한 쿼리를 태우는 건 아닌가 고민되었습니다.

초기 생각: DB 관리가 더 편한데 굳이?

솔직히 처음에는 DB 방식을 유지하는 게 맞다고 생각했습니다. 인수인계 초기에 제조사가 추가로 계약된다면 해당 테이블을 참조하라는 답변을 들었고, 실제로 DB 수동관리의 장점은 명확했습니다.

고객사의 요청으로 제조사 명칭을 급하게 바꿔야하는 상황이 주어진다면 DML 쿼리 한 줄 날리는걸로 깔끔하게 1분이면 솔루션 내 모든 명칭이 바뀌기 때문에 빠르고 해당 구조또한 충분히 유연하다고 생각했습니다.

이러한 구조에 "굳이 잘 돌아가는 걸 바꿀 필요가 있나?" ENUM으로 전환 시 코드 수정하고, 빌드하고, 테스트하고, 배포해야 하는 프로세스만 되려 늘어난다고 생각했습니다. 그런데 며칠 동안 이 생각을 곱씹으면서 점점 이상한 느낌이 들기 시작했습니다.