국내 프로젝트에서 디비 컬럼 및 변수에 enum을 쓰는 것에 대한 고찰

오랜만에 남의 회사 프로젝트에서 개발자1 롤로 일하는 중.

세월이 흐르니 짬찌들도 이런저런 지식을 얻기 쉬워져 개발 표준을 나름대로 세워서 진행하고 있더라.

그 중 신박한 경험을 함.

1. 세월이 많이 흘러 mysql에도 디비컬럼 타입을 enum으로 지정을 지정할 수 있게 됨.

- 이에 따라 엔티티 및 dto에도 이넘타입을 선언할 수 있음.

- 데이터 구조로는 아마 매핑되는 영역이 있을거고 실 데이터는 아주 효율적으로 저장될거임. 테이블 크기가 10억 row이러면 데이터 약간 아끼긴 할듯

- 미쿡인 경우 enum 글자 자체가 프론트로 드러나도 되는 경우가 많을 거임. canceled 이런거.

2. 근데 어떤 짬찌가 국내 프로젝트. 그것도 SPA + API 구조의 프로젝트에 enum을 강제함

- 그래 진짜 네이버나 배민급 개바쁜 서버에서는 이정도 비용도 아낄만함.

- 십덕도 나중에 어른될거 대비해서 이렇게 해놓긴 함.

근데 시발 공공이나 업무사이트에서 이짓거리하면 상태값 하나 추가하는데 디비컬럼부터 백엔드 프론트까지 10군데는 건드려야함 ㅋㅋ

쇼핑몰이라 치자.

[주문완료, 배송준비중, 배송중, 배송완료, 수취확인]

5개의 상태가 있다고 치는데 이게 모든 주문/결제/반품 이런 루틴에 들어감.

이런건 enum으로 처리하면 보기도 좋고 변할일도 잘 없어서 하면 괜찮음. 오히려 코드값으로 하면 중간번호에 낑궈넣기 애매하니까 이게 더 좋은 처리임.

근데 이 병신은 수취여부, 공개여부, 노출여부 이런걸 다 enum으로 해놓고 값은 Y,N 근데 화면에는 노출, 미노출 이렇게 표현하게 함.

그리고 나서 지금 QA 진행하고 있는데...

- 노출여부를 공개여부로 바꿔주세요. 이런 QA 올라오면 지옥 시작되는거임. 그냥 어드민 코드관리화면에서 바꾸면 될걸 개발자 10명이 달라붙어서 처리 중.

- 엑셀 다운로드 구현하려면 이넘값 다 서버에서 스위치문 처리해야함 ㅋㅋㅋㅋㅋㅋㅋ

- 필연적으로 휴먼에러로 인하여 단어 통일이 틀어지면서 지옥으로 흘러감

요약:

AI가 코딩해주는 시대가 도래했음에도 불구하고 여전히 병신들은 병신짓을 함.