플러스프로젝트 배경
1) 문제점 - 계정 발급과 권한 판정이 분리되면, 계정 생성 경로마다 권한 로직이 따로 구현되고 어느 경로에서는 권한이 아예 붙지 않는 상태가 생긴다. - 역할의 최소권한을 전역 기본값으로 걸어두어도, 개별 화면이 자기 권한을 선언하면 그 기본값이 대체되어 조용히 무력화된다. 이 저장소는 관례상 거의 모든 화면이 자기 권한을 선언하고 있었다(업무 모듈 하나에서만 391곳). - 직원 계정을 만들 때 소
프로젝트 성과
실제 계정 테스트로 발견한 권한 우회를 단일 지점으로 봉합
역할의 최소권한을 전역 기본값으로 걸어두었지만, 화면이 자기 권한을 선언하는 순간 기본값이 대체된다는 성질 때문에 대부분 무력화돼 있었다.
권한이 기본값에 기대어 열리는 계정 생성 경로를 차단
직원 계정을 만들 때 소속을 지정하지 않아도 권한 레코드를 항상 명시적으로 생성하도록 바꿔, 레코드가 없을 때의 관대한 기본 판정이 새 계정에 적용되는 사고를 원천에서 막았다.
일괄 등록의 실패를 격리하고 관리자가 볼 수 있게 만듦
엑셀 일괄 등록을 행 단위로 독립 처리해 한 행의 실패가 다른 행을 막지 않게 했다.
개인정보 기능의 '꺼짐'을 검증 가능한 상태로 설계
방문자 위치 조회처럼 개인정보 국외 이전 소지가 있는 기능은 설정 하나로 끌 수 있게 하되, 그 검사를 캐시 조회보다 앞에 두었다.
핵심 기능
엑셀 기반 직원 계정 일괄 발급
관리자가 엑셀을 올리면 컬럼 매핑과 미리보기를 거쳐 실제 로그인 가능한 계정이 한 번에 발급된다.
진행 단계
도메인 경계 확정과 화면 설계
2026.08.
계정 발급과 권한 판정을 하나의 도메인으로 묶기로 결정하고, 회원가입부터 조직도·권한 관리까지 13개 화면의 흐름을 먼저 정리했다. 이 결정이 이후 모든 설계의 전제가 되었다.
프로젝트 상세
계정을 만드는 일과 그 계정이 무엇을 볼 수 있는지 정하는 일을 굳이 하나의 도메인으로 묶은 데에는 이유가 있었다. 둘을 떼어놓으면 계정은 생겼는데 권한이 붙지 않거나, 계정이 만들어지는 경로마다 권한 로직이 조금씩 다르게 복제되는 일이 생긴다. 그래서 회원가입과 소셜 로그인, 회사 단위의 직원 계정 발급, 조직도, 역할 기반 접근제어(RBAC)를 처음부터 한 덩어리로 설계했다. 가장 오래 붙들었던 문제
