출근!
설계 훈련 정리 - enum vs class로 Role 표현하기
🔍 오늘의 질문
“‘사용자(User)’와 ‘권한(Role)’ 관계를 설계할 때, 단순히 enum으로 관리하는 것과 객체로 분리하는 것 사이에는 어떤 차이가 있을까?”
🧠 나의 생각 정리
-
enum은 단순한 권한 구분에는 적합하지만,
사용자마다 다른 메뉴 접근 권한 같은 커스터마이징이 필요한 상황에서는 한계가 있다. -
enum은 고정적이고 변경 가능성이 낮은 구조에 유리하지만,
나에게는 너무 딱딱하고 유연하지 못한 느낌으로 다가온다. -
Role과 같은 개념은 행동(behavior) 을 포함할 수 있기 때문에,
상황에 따라 클래스로 분리해서 책임을 위임하는 쪽이 더 적절할 수 있다.
🧑🏫 티쳐 피드백 요약
✅ 네가 잘 짚은 포인트
- enum의 한계: 상수값 이상을 넘기기 시작하면 유지보수/확장성에서 무너짐
- 커스터마이징이 필요한 권한 구조에는 부적합
- 단순한 구조라면 enum도 효율적인 선택이 될 수 있음
🔁 한 단계 더 생각해볼 포인트
- 실무에선 권한(Role)과 권한 리스트(Permission)가 DB에 저장되고 관계 매핑되는 경우가 많음
- 정책 기반 접근:
PermissionEvaluator,AccessPolicy,RoleStrategy같은 이름의 행동 중심 설계 패턴이 자주 쓰임
💡 추가적으로 알아두면 좋은 개념들
1. SRP (단일 책임 원칙)
- 권한의 구분과 권한의 행동을 한 객체에 모두 담는 건 SRP 위배 가능성
- Role과 Permission을 분리하는 기준이 여기에 해당됨
2. 전략 패턴 (Strategy Pattern)
- 역할별로 행동이 다를 때, 각 행동을 별도의 전략 객체로 분리해서 관리
- 예:
AdminRoleStrategy,UserRoleStrategy
3. 의존성 역전 원칙 (DIP)
- 코드가 구체적인 enum에 의존하면 유연성이 떨어짐
- 대신 인터페이스(
Role,PermissionPolicy)에 의존하고, 구현체만 바꾸는 구조가 좋음
4. 도메인 주도 설계 (DDD)의 관점
- 권한(Role)은 단순한 값이 아니라 행동의 책임을 지는 주체로 간주할 수 있음
- Value Object와 Entity 사이 어딘가로 취급되기도 함
🧩 실무 경험에서 얻은 교훈
-
간단한 상수로 이루어진 구조라 판단하고 enum으로 구현했지만,
실제로는 변동 사항이 잦았고, 속성 값이 점점 많아졌으며 계산 로직이 추가되면서
enum 수정 비용이 class보다 오히려 더 크다는 점을 체감했다. -
앞으로는 enum을 도입하기 전,
- 변동 가능성은 얼마나 되는지
- 값의 추가/수정이 발생할 여지가 있는지
- 로직이 개입될 가능성이 있는지
를 더 면밀히 검토해야겠다는 자기 반성을 하게 되었다.
🎯 오늘 설계 훈련 소결
enum과 class는 단순히 코드 구조가 아닌,
도메인을 어떻게 바라보고 얼마나 유연하게 설계할지를 결정하는 선택지다.
이번 설계 질문을 통해, 내가 어떤 기준과 경험을 가지고 판단할 수 있을지 한 걸음 정리해볼 수 있었다.
퇴근!
enum, 도메인, 그리고 현실적인 설계 - 아티클 읽기
Q. 오늘 어떤 고민에서 시작했을까?
퇴근길엔 코딩 없이 “설계 고민”을 하기로 했고,
오늘 아침에 했던 [enum vs 도메인 클래스] 주제와 연결해
실무에서 enum을 어떤 기준으로 써야 할지 고민해봤다.
Q. 아침엔 왜 enum을 피해야겠다고 느꼈을까?
- 유연성이 없고, 정책 변경 시 배포가 필요해서
- 비즈니스 변화에 대응하기 어려워 보여서
- 테스트도 어려워질 것 같았기 때문에
Q. 그럼 왜 다시 enum을 재평가하게 됐을까?
아래 아티클을 읽고 시선이 바뀌었다:
깨달은 점:
- enum 자체가 나쁜 게 아니라, 적재적소에 쓰지 못했던 내 문제였다.
- enum은 오히려 맥락을 담고, 표현력을 높여줄 수 있다.
Q. enum이 주는 장점은 뭘까?
- 표현력↑: 숫자/문자열보다 의미가 명확해짐
(예:"01"vsSubscriptionType.STANDARD) - IDE 지원: 자동완성, 타입 안정성, 오타 방지
- 맥락 표현: 어떤 도메인의 어떤 값인지 코드 레벨에서 보여줌
Q. 그럼 언제 enum을 쓰면 안 될까?
- 변경 가능성이 있는 값
(예: 상품 가격, 할인율, API 주소 등) - 배포 없이 바꾸고 싶은 설정들
- 테스트/환경 분기 등 유연성이 필요한 구조
Q. 이런 경우 enum을 써도 괜찮을까?
“타사 API 정보는 enum으로 관리해도 될까?”
- ❌ URL, 인증키 등은 변경 가능성이 높고 환경 의존적 → enum 부적합
- ✅ 식별자, 타입, 상태 같은 고정 값 → enum OK
Q. 마지막으로 현실적인 기준을 잡아보자면?
- “자주 바뀌면 enum 쓰지 마라”
- “고정된 분기, 식별자면 enum이 깔끔하다”
- “설정 가능한 영역은 YAML/DB/ENV로 분리하자”
느낀 점
오랜만에 설계 고민을 깊게 해봤다.
그동안은 동료가 없어서 이런 대화를 나눌 기회가 거의 없었는데,
누군가랑 이렇게 맥락까지 나눠가며 고민하니까 배움의 깊이가 완전히 달라졌다.
단순히 “enum 쓰지 마라”가 아니라, 왜 쓰면 안 되는지, 어디에 써야 하는지까지 이해하게 됐다.
내일 아침 과제엔 이 기준을 가지고
SubscriptionProduct 설계를 다시 돌아보며
도메인 책임 분리를 고민해볼 예정.
