어드민 세션 조회와 관리 권한 분리

어드민 운영 도구에는 세션 관리 기능도 있었습니다. 당시 문서를 다시 보면서 눈에 들어온 부분은 세션 목록보다 권한 구분이었습니다. 조회 권한과 전체 관리 권한을 별도로 정의하고 있었습니다.

운영자가 상태를 조회할 때와 변경할 때는 필요한 권한이 다릅니다. 세션 정보가 필요한 사람 모두에게 세션을 제어하는 권한까지 줄 필요는 없습니다.

조회와 관리의 구분

세션 조회는 현재 접속 상태를 파악하기 위한 기능입니다. 반면 세션을 만료시키는 등의 변경 기능은 사용 중인 사람의 작업에 영향을 줄 수 있습니다. 같은 화면에 있더라도 두 동작의 권한은 구분할 수 있어야 합니다.

예를 들어 문의 대응자는 접속 상태를 확인하고, 필요한 경우 권한이 있는 담당자에게 조치를 요청하는 방식으로 역할을 나눌 수 있습니다. 이는 권한 구분을 활용한 운영 예시이며, 당시 조직의 구체적인 역할 배치를 그대로 옮긴 것은 아닙니다.

중요한 것은 버튼을 숨기는 것으로 권한 처리를 끝내지 않는 것입니다. 실제 조회·변경 요청을 처리하는 서버에서도 해당 권한을 확인해야 합니다.

세션 상태와 조치 대상

계정 하나에 세션이 여러 개 있을 수 있습니다. 사용자의 세션 전체를 대상으로 하는지, 특정 접속 하나만 대상으로 하는지에 따라 영향이 달라집니다.

변경 기능을 설계할 때는 대상 계정과 세션, 현재 상태를 구분해 보여 주는 편이 좋습니다. 사용자가 작업 중인지 확인하지 않고 정리하면 작성 중인 내용이 사라지거나 다시 로그인해야 할 수 있습니다.

세션 만료와 계정 권한 변경도 같은 작업은 아닙니다. 현재 세션을 끝내는 것만으로 이후의 로그인까지 막히지는 않으므로, 조치 목적에 맞는 기능을 선택해야 합니다.

변경 결과와 이력

관리 도구에서는 요청이 성공했다는 응답뿐 아니라 대상 세션의 상태가 바뀌었는지도 확인할 수 있어야 합니다. 여러 인스턴스나 저장소를 사용하는 환경에서는 변경이 어느 범위에 반영되는지도 구현에 맞춰 확인해야 합니다.

누가 언제 어떤 대상을 변경했는지 남기는 기록도 필요합니다. 다만 세션을 조회하는 화면이나 변경 이력에 세션 쿠키·인증 토큰 원문까지 표시할 필요는 없습니다. 운영에 필요한 식별 정보와 인증에 사용하는 값은 구분해서 다뤄야 합니다.

세션 관리 문서에서 확인한 조회·관리 권한 구분은 이런 설계의 출발점이 됩니다. 상태를 알아야 하는 사람과 직접 변경할 수 있는 사람을 나누면, 운영에 필요한 정보를 제공하면서도 변경 범위를 제한할 수 있습니다.

다음 글에서는 재배포 없이 운영 로그 레벨을 조정하는 도구를 살펴보겠습니다.