권한이 계속 늘어나는 문제 해결

권한은 요청보다 회수가 느려서 쌓인다

권한은 대부분 “필요하니까 일단 열어주는 방식”으로 늘어난다. 문제는 부여보다 회수가 늦다는 점이다. 그래서 권한이 계속 늘어나는 조직은 보통 시스템이 복잡해서가 아니라, 접근권한 점검과 권한 검토 루틴이 없어서 정리가 밀린다.

프로젝트 시작, 긴급 대응, 외부 협업, 역할 변경 같은 이벤트가 생길 때마다 권한은 추가된다. 반대로 프로젝트 종료, 담당 변경, 퇴사, 예외 종료 시점에는 자동으로 줄어들지 않는다. 이 틈이 길어질수록 계정 권한 관리는 사람 기억에 기대게 되고, 접근 제어 거버넌스는 문서 없이 관성으로 유지된다.

이번 글은 제목 그대로 ‘리프레시’에 초점을 맞춘다. 새 체계를 크게 도입하는 이야기가 아니라, 이미 쌓인 권한을 털어내고 설명 가능한 상태로 되돌리는 글이다. 그래서 흐름도 단순하다. 권한 인벤토리를 만들고, 승인·만료 규칙을 고정하고, 월 1회 점검으로 묵은 권한을 비워낸다.

– 권한이 계속 늘어나는 팀은 어디서 무너지는가

권한이 누적되는 팀에는 공통 패턴이 있다. 첫째, 계정은 있는데 소유자가 불명확하다. 둘째, 읽기 권한과 수정 권한, 관리자 권한이 한 사람에게 섞여 있어 실제 위험도를 구분하지 못한다. 셋째, “이번 달만” 주었던 예외 권한이 다음 달에도 그대로 남는다.

이 문제는 협업 도구, 클라우드 콘솔, 파일 저장소, 데이터 조회 화면처럼 업무 빈도가 높은 곳에서 더 빨리 커진다. 신규 입사자 온보딩은 체크리스트가 있어도, 역할 변경 후 권한 축소나 프로젝트 종료 후 접근권한 점검은 약한 경우가 많다. 그 결과 요청은 표준화되고 회수는 예외 처리로 남는다.

실무에서 자주 보이는 장면도 비슷하다. 퇴사자 계정은 비활성화했지만 연결된 공유 드라이브 접근은 남아 있다. 긴급 장애 대응용 관리자 권한은 사건 종료 후에도 유지된다. 외부 협업자가 빠졌는데 대시보드 조회 권한은 남는다. 권한은 이런 식으로 한 번에 폭증하지 않고, 조용히 쌓인다.

– 왜 이런 문제가 생기는가

① 권한은 업무 요청 단위로 즉시 추가되지만, 회수는 별도 일정이 없어 뒤로 밀린다.
② 승인자가 “필요해서 열어줌”만 남기고 종료 시점과 검토 조건을 기록하지 않으면 예외 권한이 기본 권한처럼 굳어진다.
③ 시스템마다 관리자와 요청 채널이 달라 한 사람의 전체 접근 범위를 한 번에 보지 못하면 중복 권한이 숨어든다.
④ 역할 기반 권한이 약하면 사람 기준 직접 부여가 늘어나고, 담당 업무가 바뀐 뒤에도 예전 권한이 남는다.
⑤ 많은 팀이 신규 부여 속도는 관리하지만 회수 기준과 권한 검토 주기는 정하지 않아 추가만 빨라진다.
⑥ 접근권한 점검 일정이 없으면 “문제 생길 때까지 유지”가 사실상 기본 정책이 되어 권한이 관성으로 남는다.

결국 권한 증가는 기술보다 운영의 공백에서 시작된다. 인벤토리 없이 부여하고, 만료일 없이 승인하고, 점검 없이 유지하면 권한은 반드시 늘어난다.

– 권한 인벤토리가 있으면 무엇이 달라지는가

권한 정리는 많이 지우는 일이 아니다. 남아야 할 권한만 설명 가능하게 만드는 일이다. 그래서 핵심 지표는 삭제 건수보다 설명 가능성이다. 계정별로 시스템, 권한 수준, 업무 목적, 승인자, 만료일, 마지막 검토일을 말할 수 있으면 계정 권한 관리 난이도는 급격히 낮아진다.

항목	방치형 운영	권한 인벤토리 루틴 운영
권한 부여 기준	요청 메시지 중심	역할 + 업무 목적 중심
승인 기록	채팅/메일에 흩어짐	시트 또는 티켓으로 일원화
만료 규칙	없음	예외 권한 기본 30일, 연장 시 재승인
권한 검토	사고 후 확인	월 1회 정기 점검
회수 판단	담당자 기억 의존	만료일·역할 변경·미사용 기준
설명 가능성	낮음	높음

어떤 방식으로 시작할지도 나눠야 한다. 시스템 5개 이하, 승인자 2명 이하인 소규모 팀은 공유 시트 기반 권한 인벤토리로 시작해도 된다. 반대로 시스템 6개 이상이거나 승인자 3명 이상이 동시에 개입하면 티켓 기반 승인 흐름으로 가야 누락이 줄어든다. 규모보다 중요한 것은 한 계정의 전체 접근 범위를 한 번에 보여줄 수 있느냐다.

– 권한 인벤토리 만들기

첫 단계는 시스템별 목록이 아니라 계정별 목록으로 바꾸는 것이다. 한 사람 또는 한 서비스 계정을 기준으로 협업 도구, 파일 저장소, 클라우드, 데이터, 관리자 화면 권한을 모아야 한다. 최소 필드는 계정명, 소속, 시스템명, 권한 수준, 업무 목적, 승인자, 부여일, 만료일, 마지막 검토일 9개다.

둘째, 권한을 세 등급으로 나눈다. 기본 권한, 역할 확장 권한, 예외 권한으로 구분하면 어떤 권한부터 줄일지 순서가 생긴다. 기본 권한은 직무 기준으로 유지하고, 역할 확장 권한은 역할 변경 시 재검토하며, 예외 권한은 만료를 전제로 운영한다.

셋째, 승인 규칙을 짧게 고정한다. 읽기 권한은 팀장 승인 1회, 수정 권한은 시스템 소유자 승인 1회, 관리자 권한은 시스템 소유자와 팀장 2인 승인으로 끝내는 편이 강하다. 규칙은 길수록 예외가 늘어난다.

넷째, 만료 규칙을 기본값으로 둔다. 예외 권한은 30일, 프로젝트성 관리자 권한은 14일, 외부 협업 계정은 7일처럼 기간을 먼저 정하면 회수 요청이 자연스럽게 생긴다. 만료일이 없는 예외 권한은 예외가 아니라 누적 위험이다.

다섯째, 월간 권한 검토 대상을 자동으로 뽑는다. 만료일 경과 계정, 마지막 검토일 30일 초과 계정, 역할 변경 계정, 최근 30일 미사용 고권한 계정을 우선 목록으로 고정한다.

– 승인/만료 규칙 : 권한이 늘지 않게 막는 가장 짧은 운영선

실제 운영에서 가장 강한 규칙은 복잡한 정책이 아니라 짧고 반복 가능한 승인선이다. 권한 요청 템플릿에는 세 가지면 충분하다. 업무 목적 1문장, 필요한 기간, 종료 시점이다. 이 세 칸이 없으면 승인하지 않는 방식으로 바꾸면 요청 품질이 바로 올라간다.

만료 규칙도 선택값이 아니라 기본값이어야 한다. 읽기 권한은 기본 역할에 묶고, 일시적 수정 권한과 관리자 권한은 만료를 건다. 예외 권한은 연장할 수 있지만 자동 연장은 두지 않는다. 연장할 때마다 다시 승인받게 해야 “열기 쉬움, 닫기 어려움” 구조가 바뀐다.

이 단계에서 최소 권한 원칙이 실제로 작동한다. 필요한 범위만 열고, 필요한 기간만 유지하고, 끝나면 닫히는 구조가 만들어져야 한다. 접근 제어 거버넌스는 문장이 아니라 만료일 필드에서 시작된다.

– 월간 점검 흐름 : 30분 안에 끝나는 권한 검토 루틴

권한 점검은 길게 잡을수록 밀린다. 그래서 30분 안에 끝나는 월간 루틴이 필요하다. 예를 들어 매월 첫 번째 금요일 오전 10시에 지난 30일 변경분을 추출하고, 10분 동안 만료 계정을 확인하고, 10분 동안 연장 필요 여부를 검토하고, 마지막 10분 동안 회수 또는 연장 결과를 기록하면 된다.

검토 순서는 넓게 보지 말고 좁게 잘라야 한다. 1순위는 만료일이 지난 예외 권한, 2순위는 관리자 권한 계정, 3순위는 역할 변경자와 퇴사 예정자 계정, 4순위는 최근 30일 미사용 고권한 계정이다. 이 순서로 보면 짧은 시간에도 의미 있는 정리가 가능하다.

실무 예시도 분명하다. 프로젝트 종료 후 외부 협업자 2명이 빠졌는데, 파일 저장소와 대시보드 권한이 남아 있다고 하자. 시스템별로 찾으면 시간이 길어지지만, 계정별 권한 인벤토리가 있으면 5분 안에 접근권한 점검이 끝난다. 월간 점검은 전체를 다 보는 시간이 아니라, 남아 있으면 안 되는 권한을 먼저 털어내는 시간이다.

– 이 루틴이 실제로 작동하는지 보는 수치

운영 루틴은 문서가 아니라 수치로 검증해야 한다. 첫 번째 기준은 인벤토리 기입률 100%다. 이번 달 권한 변경 건 10건이 있었다면 10건 모두 기록돼 있어야 한다. 두 번째 기준은 만료일 보유율 95% 이상이다. 예외 권한 20건 중 19건 이상에 만료일이 있어야 한다. 세 번째 기준은 월간 점검 처리율 90% 이상이다. 점검 대상 30건이면 같은 달 안에 27건 이상 처리해야 한다.

여기에 한 가지를 더 보면 좋다. 역할 변경 후 잔여 권한 발견 건수다. 이 수치가 반복해서 나오면 인사 이벤트와 계정 권한 관리가 끊겨 있다는 뜻이다. 권한 루틴이 제대로 돌면 신규 요청 건수보다 잔여 권한 발견 건수가 먼저 줄어든다.

– 자주 하는 실수 / 주의할 점

가장 흔한 실수는 권한 인벤토리를 시스템 목록으로 시작하는 것이다. 그러면 사람 한 명의 전체 접근 범위를 보기 어려워 실제 회수 속도가 느려진다. 두 번째 실수는 승인 규칙을 복잡하게 쓰는 것이다. 예외가 많을수록 규칙은 더 짧아야 한다. 세 번째 실수는 만료일을 선택값으로 두는 것이다. 선택값은 결국 빈칸이 된다.

또 하나의 실수는 권한 회수 뒤 곧바로 전체 원복하는 것이다. 업무 차질이 생겨도 먼저 1회성 읽기 권한인지, 7일 재부여가 필요한 예외 권한인지 다시 분류해야 한다. 원복도 최소 권한 원칙으로 처리해야 한다. 같이 복구하는 것이 아니라 필요한 범위만 복구하는 방식이어야 한다.

긴급 장애 대응용 관리자 권한을 상시 권한으로 굳히는 것도 자주 나오는 오류다. 사고 대응은 끝났는데 고권한은 남는 순간, 그 권한은 더 이상 대응 권한이 아니라 방치 권한이 된다.

– 30초 체크리스트

– 마무리 : 리프레시는 한 번 지우는 일이 아니라, 계속 줄이는 루틴이다

권한 문제는 한 번의 정비로 끝나지 않는다. 쌓이는 속도를 줄이고, 남아 있는 권한을 설명 가능하게 만들고, 불필요한 권한을 매달 털어내는 루틴이 있어야 안정된다. 그래서 리프레시는 대규모 프로젝트가 아니라 운영 습관에 가깝다.

지금 당장 전체를 다 정리할 필요는 없다. 가장 먼저 볼 대상은 ‘권한 만료일’이 없는 계정이다. 그다음은 관리자 권한 계정이고, 그다음은 역할 변경 계정이다. 권한 정리는 많이 지우는 일이 아니라, 남아야 할 권한만 설명 가능하게 만드는 일이다.

다음 달부터 ‘권한 만료일’ 없는 계정만 먼저 정리한다.

– 요약

– FAQ

Q1. 권한 인벤토리는 꼭 별도 솔루션이 있어야 하나요?
A1. 아니다. 시스템 수가 적고 승인자 수가 많지 않다면 공유 시트로도 충분히 시작할 수 있다. 중요한 것은 도구보다 계정별 구조와 만료일 필드의 강제다.

Q2. 만료일은 모든 권한에 넣어야 하나요?
A2. 기본 권한 전체에 일괄 만료일을 넣기보다 예외 권한과 프로젝트성 고권한에 먼저 적용하는 편이 운영 부담이 낮다. 대신 마지막 검토일은 중요 권한에 반드시 남겨야 한다.

Q3. 월간 점검이 자꾸 밀리면 무엇부터 줄여야 하나요?
A3. 점검 범위를 전체 계정으로 잡지 말고 만료일 경과, 역할 변경, 미사용 고권한 계정으로 좁혀야 한다. 점검 시간도 30분으로 고정해야 루틴이 유지된다.