[벡엔드] 카테고리 Java Enum 활용

카테고리를 테이블로 관리했을 때의 문제점

 

카테고리의 클래스를 구현하는 도중 문득 카테고리 각각을 테이블로 만드는 것이 상당히 비효율적이라고 느껴졌습니다. 그러한 이유는 다음과 같습니다.

 

 

• 카테고리 변경이 거의 일어나지 않음
  • 본 프로젝트 특성상, 한 번 정의된 카테고리 추가/삭제가 거의 발생하지 않는다. 따라서 카테고리 CURD는 프로젝트 초기 이후 거의 사용되지 않는다.
• 관계 관리의 복잡성 증가
  • Developer : DevLanguage의 관계는 다대다 관계이다. 연관관계 메서드 등을 구현하기 위해 코드가 길어지며, 운영 단계에서 중간엔티티가 증가한다
    
• 성능 이슈
  • 테이블을 Join & Group by 하며 성능 부하가 발생한다.

 

Java Enum 도입

이러한 비효율을 해결하기 위해 다음 기술 블로그를 레퍼런스하여 Java의 Enum을 활용하기로 정하였습니다.

https://techblog.woowahan.com/2527/

Java Enum 활용기 | 우아한형제들 기술블로그

 

Java Enum을 활용할 수 있었던 이유는 다음과 같습니다.

• 수평적인 카테고리 사용
• 카테고리를 거의 변경하지 않음
• 테이블 방식에 비해 성능적 강점 존재
• 불필요한 코드 제거

 

 

문제상황

도메인 설계 이후 Enum을 잘 사용하고 있었지만 간과하고 있던 점이 있었고, 프로젝트 마감 일주일 전에 문제가 발생하게 되었습니다.

간과한 점은 다음과 같습니다.

Java Enum 활용기 ❘ 우아한형제들 기술블로그 중

 

프로젝트 제출 전, 카테고리 종류를 전체적으로 축소하기로 결정했고 다음 배포에서 Enum 코드 일부를 제거했습니다. 이후 카테고리 조회를 포함하는 API에서 에러가 발생하는 문제가 생겼습니다.

 

 

Project의 languageList가 Enum 클래스 DevLanguage의 JAVA를 가지고 있는 상황입니다. 이때 코드상으로 Enum에서 Java를 삭제하고 배포해도 문제가 생기지는 않으나 데이터베이스는 아직 JAVA에 대한 값을 저장하고 있어서 조회를 할 때 저장된 값이 현재 Enum 중 매칭되지 않아서 문제가 발생하게 됩니다.

 

해결

매칭되지 않는 값이 languageList에 남아있어 해당 project 자체를 조회 할 수 없었습니다. project update와 delete API도 마찬가지로 사용할 수 없었습니다.

 

조금 더 직접적인 수정 방법을 찾아야 했고 데이터베이스의 값들을 직접 수정하여 이 문제를 해결할 수 있었습니다. 구체적으로는 인텔리제이에 데이터베이스를 연결하여 터플들 중 languageList의 값이 ‘C’처럼 매칭된 문자열로 나타나지 않고 0xAFD12F14FC와 같이 알 수 없는 값으로만 남아있는 데이터들을 직접 삭제함으로써 문제를 해결했습니다.

 

이후에는 다음과 같은 방식으로 문제를 사전에 방지하는 방법을 고민했습니다.

• 배포 전에 삭제된 Enum 값을 가지는 인스턴스의 필드 정리
  • Enum 클래스 업데이트 시 삭제된 필드 정리

 

• 기존 코드에 예외 처리를 추가하고 삭제된 필드를 정리하는 로직 추가