(WEB_PORTAL) 3단계 권한 체계 도입 — 제약 조건을 무중단으로 바꾸는 법

개요

기존에는 일반 직원과 관리자, 두 단계 권한만 있었지만, 조직 운영상 관리자보다 상위의 최종 관리자 역할이 필요해졌습니다. 역할 종류를 하나 늘리는 작업 자체는 간단해 보였지만, 실제로는 이미 운영 중인 DB의 제약 조건을 손대야 하는 문제가 있었습니다.

문제 상황

내장형 DB(SQLite)는 테이블을 만들 때 특정 컬럼에 허용값을 제한하는 제약 조건을 걸 수 있는데, 이 제약 조건은 나중에 값을 하나 추가하고 싶어도 ALTER TABLE로 간단히 수정할 수 없는 구조였습니다. 이미 서비스가 운영 중인 상태였기 때문에, 데이터를 보존하면서 제약 조건만 바꾸는 방법이 필요했습니다.

해결 방법

SQLite에서 흔히 쓰는 "새 구조의 테이블을 만들고 기존 데이터를 옮긴 뒤 이름을 바꾸는" 패턴을 사용했습니다.

트랜잭션 시작
  새 제약 조건을 가진 임시 테이블 생성
  기존 테이블의 모든 데이터를 임시 테이블로 복사
  기존 테이블 삭제
  임시 테이블 이름을 원래 이름으로 변경
트랜잭션 커밋

전체 과정을 하나의 트랜잭션으로 묶어서, 중간에 오류가 나더라도 원래 상태로 롤백되도록 안전장치를 뒀습니다.

권한별 화면 분기

역할이 세 단계로 늘어나면서, 사이드바 메뉴도 역할에 따라 다르게 보여주도록 구성했습니다. 최종 관리자에게는 전체 관리 메뉴와 권한 관리 메뉴가, 일반 관리자에게는 일상적인 운영 메뉴만 보이도록 나눴고, 상단 배지로도 현재 역할을 구분할 수 있게 표시했습니다.

회고

• 이미 운영 중인 DB의 제약 조건을 바꿔야 할 때는, 테이블을 아예 새로 만들어 옮기는 방식이 번거로워 보여도 가장 안전하다는 걸 확인했습니다. 데이터 손실 없이, 그리고 서비스 중단 없이 스키마를 진화시킬 수 있는 방법을 미리 익혀둔 게 이후에도 여러 번 도움이 됐습니다.
• 권한 체계를 설계할 때는 "역할을 몇 단계로 나눌지"보다 "각 역할이 서로의 권한을 침범하지 못하게 막는 방법"이 실제로 더 중요한 설계 지점이라는 걸 다시 느꼈습니다.