by
Apr 08. 2023
똑똑하게 데이터 3탄 : 열거형
이넘만 사용 가능하다, 가능한 모든 경우를 enum으로 약속해야
서비스를 만드는 과정에서 '헉' 하고 숨이 턱 막히는 것을 경험해 보셨나요? 몇 번이고 서로 돌아가며 검수를 했는데 오타가 있다거나, 데이터가 엉뚱한 위치에 나오고 있으면 당황스럽습니다. 하지만 진짜 문제는 이를 발견하고 개발자에게 수정을 요청할 때 발생합니다.
아 '삭제 중'이라는 상태가 있어요?
'삭제하기' 버튼 누르면 바로 '삭제' 상태 되어서 화면에서 안 보이는 줄 알았어요.
시스템 간 동기화가 중요한 서비스였고, 관련 시스템에서 다 '삭제'라고 확인되어야 '삭제완료' 상태가 되면서 비로소 고객이 보는 화면에서 더 이상 노출이 되지 않는 것이 기획 방향이었습니다. 이것을 수정하려고 하니, 해당 아이템이 추가되고 삭제되고 조회되는 모든 로직이 다시 검수에 들어가야 했습니다.
왜 이러한 상황이 발생하게 된 것일까요?
고정관념을 깨뜨리면
서로 불편해지는 상태값 정의
프로그램을 개발할 때 가장 기본적인 요소, 필수적인 기능이 무엇이 있을까요? 검색 기능? 회원가입과 로그인? 많은 경우 CRUD('씨알유디')입니다. 즉 콘텐츠(데이터)를 등록하고(create), 등록된 콘텐츠를 조회하고(read), 수정하고(update), 삭제하는(delete) 기능입니다. SNS 서비스에서는 콘텐츠 또는 게시물이 될 테고, 커머스 서비스에서는 상품 또는 리뷰가 될 테고 그 내용은 다르지만 CRUD가 되어야 기본적으로 갖출 것은 갖춘 서비스가 됩니다.
그런 상황에서 '삭제(delete)'라고 통용되는 개념이 아닌 '삭제 중(in deleting)', '삭제완료(deleted)'개념을 가지고 왔으니 혼란이 발생할 수밖에 없습니다. 해당 콘텐츠가 삭제되면서 더 이상 보이지 않는 '삭제완료(deleted)'가 '삭제'인 상황에서, '삭제 중'은 사용하지 않는 것이 나았을 것입니다.
대신, 한번 등록되어서 조회되는 콘텐츠에 별도의 플래그(flag)를 붙이는 것입니다. '정상', '삭제 요청', '삭제 승인 완료'. 그래서 '삭제' 버튼을 누르면 '삭제 요청'이 붙은 콘텐츠로서 조회는 되지만, 나중에 동기화가 진행되어 '삭제 승인 완료' 플래그로 바뀌면 정말 고정관념대로 '삭제(delete)'되는 것입니다.
이렇게 별도의 플래그를 붙이는 것도 고정관념을 활용했기에 이해하기 쉽게 되었습니다. 많은 사람들이 불편이나 민원을 접수할 때, 즉각 처리되지 않습니다. '요청완료' 상태였다가 최종적으로 담당자가 접수 및 '승인'을 해야 해당 문제가 해결되는 경우입니다. 등록의 경우도 마찬가지입니다. 커뮤니티에서 콘텐츠를 업로드하거나, 회원 등업을 요청할 때, '접수완료'가 되고 관리자나 서비스에서 확인 후 '승인'되는 경험이 있습니다.
미리 약속한 이넘들만
사용할 수 있다고 선언해 보자
이넘은 '이놈'이 아니라 enum(열거형)을 소리대로 표기한 것입니다. 다음은 위키피디아에서 제공하는 뜻입니다. 요약하자면 변수가 아닌 상수, 즉 함부로 이름을 변경할 수 없는 카테고리명(category, 범주)을 미리 집합으로 정의해 놓은 것입니다.
열거형
컴퓨터 프로그래밍에서 열거형 (enumerated type, enumeration), 이넘 (enum), 팩터 (factor, R 프로그래밍 언어 및 통계학의 범주형 변수에서 부르는 명칭)는 요소, 멤버라 불리는 명명된 값의 집합을 이루는 자료형이다. 열거자 이름들은 일반적으로 해당 언어의 상수 역할을 하는 식별자이다.
Season이라는 enum을 정의할 때는 Spring(봄), Summer(여름), Fall(가을), Winter(겨울)이라는 사계절의 집합이라고 정의하거나, SimpleOperator이라는 enum을 정의할 때는, plus(x+y), minus(x-y), multiply(x*y), divide(x/y) 이렇게 더하기 빼기 곱하기 나누기 사칙연산의 집합을 정의하는 것입니다. 미리 명칭을 정의했기에 'Fall'이 아닌 'Fal'이라는 오타가 나면 프로그램을 서비스에 올리기 전에 런타임 오류가 납니다. 그래서 오타가 발생할 수 없습니다.
위와 같이 '삭제 중', '삭제완료'의 문제 경우에도 이미 문제는 발생했을 때, enum으로 상태값들이 정의되었었으면 빠르고 정확하게 수정 및 해결을 할 수 있었을 것입니다. 실제로 사칙연산을 활용하는 프로그래밍 중에, 계좌에 입금된 금액을 더하려고 했다가 만약 대출금액이라서 - 로 수정해야 하는 경우가 있을 수 있습니다. 이때 일일이 +를 - 로 바꿀 필요 없이, 어떤 조건 (예, 해당 금액을 입금한 user가 은행이다)에서는 명명된 plus를 minus로 바꾸라는 코드 한 줄로 바꿀 수 있기 때문입니다.
벚꽃 개화시기가 빨라지고, 춘삼월에도 25도 넘는 무더위가 반복되는 것을 보면, 대한민국 계절의 enum에서 Spring이 사라지거나, Semi-Summer로 변경될지도 모른다는 생각이 듭니다.
사진: Unsplash의Joel Nevius