[생각정리] Enum vs 공통코드, 나는 왜 Enum을 더 선호하는가

들어가면서

개발을 하다 보면 자주 마주치는 고민 중 하나가 코드 값 관리입니다.
회원 상태, 주문 상태, 결제 수단처럼 시스템 전반에서 쓰이는 값들을 어떻게 관리할지는
작은 서비스든 큰 서비스든 중요하며, 특히 서비스 유지보수 관점에서 더욱 중요한 주제입니다.

제가 처음 개발을 시작했을 때는 C++ 기반의 장비 개발이었습니다.
그 당시에는 DB를 거의 사용하지 않았고,
주로 모터와 같이 장비마다 다른 환경 세팅과 디바이스 정보를 저장하는 용도로만 활용했습니다.
그래서 코드 내부의 상태 값은 주로 enum이나 struct를 이용해 관리했고,
부득이하게 매직넘버나 매직스트링을 써야 할 때는 const 상수로 정의하여 사용했습니다.

이유는 간단합니다.
매직넘버나 매직스트링은 오타나 잘못된 사용으로 인해 쉽게 버그를 만들 수 있었기 때문입니다.
그래서 최대한 IDE의 도움을 받을 수 있도록 관리 방식을 정했고,
새로 투입된 개발자가 코드를 이해하는 데 불필요한 시간을 쓰지 않도록 매직넘버/매직스트링 사용을 지양했습니다.

이런 경험 때문에 지금도 DB 공통코드 테이블을 보면,
코드 작성 레벨에서는 결국 매직스트링으로 느껴졌습니다.

이번 글에서는 공통코드와 Enum 방식을 비교하려고 합니다.
그리고 아직까지는 개인적으로 공통코드보다는 Enum 방식을 더 선호하는 입장에서 진행하겠습니다.

---

Enum vs 공통코드 비교

구분	Enum	공통코드
장점	- 타입 안정성 보장 (IDE 자동완성, 컴파일 타임 체크 가능) - 가독성과 유지보수성 향상 - 매직넘버/매직스트링 제거 - 응집도가 높고 리팩토링 친화적	- DB 테이블 관리 → 운영자가 직접 값 추가/수정 가능 - 변경 이력 관리 용이 - 다국어 지원, 사용자 맞춤형 UI 유연 - 여러 서비스 간 코드 공유로 일관성 유지
단점	- 새로운 값 추가/변경 시 배포 필요 - 운영자가 직접 수정·추가 불가	- 코드 레벨에서는 매직스트링 비교 필요 ("01", "Y") - 타입 안정성·IDE 자동완성 불가 - 코드 ↔ DB 싱크 불일치 위험 - 남발 시 관리 복잡도 증가 - 코드를 이해하려면 반드시 DB를 함께 확인해야 하므로 학습 비용이 증가
적합한 경우	- 비즈니스 로직 핵심 값 (회원 상태, 주문 상태, 결제 상태 등) - 시스템 로직에 직접 영향을 주지만 자주 바뀌지 않는 값	- 운영 편의성이 중요한 값 (메뉴 이름, 다국어 라벨, 사용자별 메뉴명) - UI나 운영자 요청으로 자주 바뀌는 값 - 여러 서비스에서 동일한 코드 공유가 필요한 경우

---

비교와 혼합 전략

앞서 비교한 것처럼 어느 한쪽이 무조건 더 낫다고 보기는 어렵습니다.
중요한 것은 Enum과 공통코드의 차이를 이해하고, 상황에 따라 적절하게 선택하는 것입니다.

Enum vs 공통코드 차이는 결국 코드 안정성 vs 운영 편의성의 문제라고 생각합니다.

• 핵심 로직 값 → Enum으로 고정하여 안정성 확보
• 운영/UI 값 → 공통코드로 관리하여 유연성 확보

공통코드로 정의하고 Enum으로 매핑해서 사용하는 방식도 있습니다.
하지만 이 경우 관리 포인트가 Enum과 공통코드 두 곳으로 늘어나기 때문에,
유지보수 관점에서는 장점보다 단점이 더 커질 수 있다고 생각합니다.

---

마무리하며 (내 생각 정리)

Enum과 공통코드는 결국 코드 안정성 vs 운영 편의성의 선택 문제입니다.

저는 개인적으로 Enum을 더 선호합니다.
그 이유는 다음과 같습니다.

1. IDE 지원과 타입 안정성 덕분에 버그 가능성을 크게 줄일 수 있다.
2. 매직넘버/매직스트링을 제거하여 코드 가독성과 유지보수성이 좋아진다.
3. 새로 합류한 개발자가 코드를 이해하기 쉽다.
4. 코드 자체로 의미가 드러나고, DB를 보지 않아도 로직이 명확하다.

물론 공통코드는 UI 메뉴명이나 다국어처럼 운영 중에 변경이 필요한 경우 반드시 필요합니다.
이런 케이스마저 배포가 필요하다면 운영 측면에서 큰 부담이 될 것입니다.

그 외의 로직까지 공통코드로 관리한다면 코드 안정성과 유지보수성이 오히려 낮아질 수 있습니다.
사람은 실수할 수 있고, 이런 부분은 코드화해서 IDE의 도움을 받는 것이 더 효율적이라고 생각합니다.
또한 상태값이 추가·변경될 때 "01", "Y" 같은 문자열 비교가 남아 있다면 수정에 많은 비용이 듭니다.

제 경험상 메뉴명 변경이 자주 발생하지는 않고,
새로운 메뉴 추가나 커스터마이징도 대부분 배포와 함께 이뤄지는 경우가 많았습니다.

그래서 저는 핵심 로직은 반드시 Enum으로 관리하는 것이 현실적이고,
공통코드는 정말 불가피한 경우(메뉴명, 다국어 라벨, 여러 서비스의 공유 공통코드)에 최소한으로 쓰는 것이 맞다고 생각합니다.

혹시 다른 경험이나 의견이 있으시다면 댓글로 공유해주시면 감사하겠습니다.