필요한 정보와 기능에만 접근할 수 있으려면

로그인은 사용자가 누구인지 확인하는 과정입니다. 권한은 그 사용자가 어떤 정보를 보고 어떤 일을 할 수 있는지 정합니다. 로그인한 회원이라는 사실만으로 다른 회원의 자료나 관리 기능까지 이용할 수 있는 것은 아닙니다.

이 제안은 ‘누가, 누구의 자료를, 어느 항목까지 보고 바꿀 수 있는가’를 설명하고, 정한 제한이 실제 요청과 정보 전달에도 적용되는지 확인할 수 있도록 돕는 자료와 절차를 다룹니다.

역할과 맡은 일을 기준으로 범위를 정해야 합니다

로그인하지 않은 방문자도 권한 관리 대상입니다. 공개된 정보와 기능을 정하고, 회원이나 담당자에게만 허용할 범위를 구분할 수 있어야 합니다. 관리자로 등록되었다는 이유만으로 업무와 무관한 모든 자료를 볼 필요는 없습니다.

권한은 역할뿐 아니라 개별 허용, 자료와의 관계, 접속 조건을 함께 고려할 수 있습니다. 가상의 협업 서비스라면 편집자는 글을 검토하고, 프로젝트 참여자는 자신이 참여한 프로젝트의 자료를 읽도록 정할 수 있습니다. 내부에서 접속했다는 이유만으로 모든 자료를 허용하기보다, 그 자료를 이용할 업무와 권한도 확인할 필요가 있습니다.

읽기, 수정, 삭제, 승인, 파일 내려받기와 다른 사람에게 권한을 주는 일도 구분해야 합니다. 운영자가 업무별로 필요한 범위를 설명하고, 변경을 승인할 담당자에게 확인받을 수 있는 자료가 필요합니다.

화면의 표시와 실제 요청의 제한이 일치해야 합니다

버튼과 메뉴를 숨기면 화면에서 사용할 기능을 정리할 수 있습니다. 그러나 화면을 거치지 않고 같은 작업을 요청할 수 있으므로, 표시 여부만으로 권한을 제한할 수는 없습니다. 서버(서비스의 요청을 처리하는 컴퓨터나 실행 환경)가 요청마다 해당 자료에 그 작업을 할 권한이 있는지 확인해야 합니다.

API는 브라우저나 앱이 서버에 정보나 작업을 요청하는 통로입니다. 사람이나 자동화 도구가 API로 직접 요청하더라도 같은 제한이 적용되어야 합니다. 가상의 게시판에서 삭제 버튼을 숨겼어도 작성자나 관리 권한을 확인하지 않고 삭제 요청을 처리한다면, 화면과 실제 동작의 기준이 다른 것입니다.

안내 자료에는 화면이 보이는지와 요청이 허용되는지를 따로 확인하는 방법이 필요합니다. 허용할 근거가 없거나 권한을 확인하지 못한 경우에는 정보를 보내거나 작업을 실행하지 않도록 기준을 정하고, 오류나 누락을 확인할 경로도 마련해야 합니다.

자료 안의 항목과 전달 경로까지 구분해야 합니다

자료 하나를 읽을 수 있어도 그 안의 모든 항목을 볼 수 있는 것은 아닙니다. 가상의 주문 처리 업무에서 주문번호와 처리 상태만 필요하다면, 연락처와 내부 메모까지 함께 제공할 이유는 별도로 확인해야 합니다. 수정 권한도 마찬가지입니다. 자기 소개를 고칠 수 있다고 회원 등급까지 바꿀 수 있는 것은 아닙니다.

화면에 표시되지 않아도 서버가 보낸 결과에 정보가 들어 있다면 이미 이용자의 기기에 전달된 것입니다. 서버에서 허용된 항목만 골라 보내고, 이름이나 연락처를 일부 가리는 마스킹이 필요한 경우에는 가린 값만 전달되는지 확인할 수 있어야 합니다. 전체 원문을 보낸 뒤 화면에서 숨기는 방식과 구분해 설명할 필요가 있습니다.

상세 화면, 검색, 내려받는 파일과 API처럼 같은 자료가 여러 경로로 제공될 때는 각 경로의 제한을 함께 살펴야 합니다. 한 화면을 고쳤다는 이유로 다른 경로도 보호되었다고 판단하지 않도록 점검 대상과 결과를 남길 필요가 있습니다.

저장소에서 가져오는 정보도 필요한 범위로 줄여야 합니다

데이터베이스(DB)는 정보를 모아 보관하는 저장소입니다. DB에서 업무에 필요한 항목만 가져오면 불필요한 원문을 처리하는 범위를 줄일 수 있습니다. 관련된 여러 자료를 함께 조회하거나 조회를 돕는 도구가 자료를 자동으로 불러오는 경우에도, 실제로 어떤 항목이 포함되는지 확인해야 합니다.

암호화한 정보를 원래 값으로 되돌리는 것을 복호화라고 합니다. 저장할 때 암호화했더라도 프로그램이 복호화한 원문을 이용자에게 보내면 조회 제한이 적용된 것은 아닙니다. 서버 내부 계산에 필요한 정보와 이용자에게 전달할 수 있는 정보를 나누어 살펴야 합니다.

이 제안에서는 특정 조회 문법이나 개발 도구의 사용법보다, 필요한 자료와 항목을 정하고 실제 조회·전달 범위와 비교할 수 있는 설명을 다룹니다. 개발 방식이 달라도 같은 기준으로 검토할 수 있도록, 확인할 자료와 결과를 맡을 담당자를 정하는 지원이 필요합니다.

AI가 대신하는 일에도 사용자의 권한이 이어져야 합니다

AI 에이전트는 요청받은 일을 처리하기 위해 도구로 정보를 조회하거나 작업하는 프로그램입니다. 누구를 대신해 무슨 일을 하는지, 사용할 수 있는 자료와 기능이 무엇인지 구분할 수 있어야 합니다. 사용자에게 허용된 권한과 실제로 맡긴 업무의 범위를 함께 적용해야 합니다.

가상의 주문 서비스에서 회원이 자신의 주문 상태를 확인해 달라고 했다면, 다른 회원의 주문은 조회 대상이 아닙니다. 해당 회원에게 주문을 취소할 권한이 있더라도 상태 확인만 맡긴 상황에서 임의로 취소할 수 있는 것은 아닙니다. 운영용 에이전트도 서버 상태를 살피는 일에 고객 개인정보 전체가 필요한지 따로 검토해야 합니다.

이 제한을 AI에게 전달하는 지시문에만 맡기기보다 서버와 실행 도구가 확인하도록 해야 합니다. AI가 주장하는 사용자 이름이나 승인 여부 대신 서비스가 확인한 사용자와 업무를 기준으로 판단하고, 사용자 업무를 처리하면서 별도의 운영 권한으로 제한을 넘지 않는지도 확인할 필요가 있습니다.

권한이 바뀐 뒤의 요청과 남아 있는 자료도 확인해야 합니다

담당 업무나 프로젝트 참여가 끝나면 필요 없어진 권한을 거두고, 임시 권한은 종료 시점을 정할 수 있어야 합니다. 이미 로그인한 상태나 연결된 도구를 통한 다음 요청에도 변경이 반영되는지 확인해야 합니다. 이미 전달하거나 내려받은 정보까지 자동으로 되돌릴 수 있는 것은 아니므로, 복사본을 관리할 범위도 함께 살펴야 합니다.

누가 언제 어떤 이유로 권한을 주거나 바꾸었는지 기록하고, 권한 변경 자체를 승인할 수 있는 사람도 제한할 필요가 있습니다. AI의 작업은 누가 맡긴 어떤 업무였는지와 이용한 자료·작업·결과를 확인할 수 있도록 남기되, 개인정보 원문을 기록에 다시 복사하지 않도록 해야 합니다.

인수인계에는 현재 권한 목록뿐 아니라 예외적으로 허용한 이유, 끝낼 시점과 미확인 항목도 포함할 수 있습니다. 담당자가 바뀌어도 불필요한 접근이 계속 남지 않도록 검토 시간을 확보하는 지원이 필요합니다.

허용과 거부를 모두 확인할 수 있어야 합니다

관리자 계정으로 기능이 작동하는지 확인하는 것만으로는 권한 점검을 마치기 어렵습니다. 방문자, 일반 회원, 업무별 담당자와 에이전트로 나누어, 허용된 일은 수행되고 허용되지 않은 일은 거부되는지 확인할 필요가 있습니다. 실제 개인정보 대신 점검용 사용자와 자료를 준비할 수 있도록 지원해야 합니다.

점검표에는 다른 회원이나 조직의 자료에 대한 요청, 화면을 거치지 않은 요청, 제한된 항목의 조회·수정, 검색과 파일 내려받기, 로그아웃이나 권한 회수 뒤의 요청 등을 포함할 수 있습니다. 모든 서비스에 같은 항목을 적용하기보다 사용하는 기능에 맞춰 선택하도록 구성하는 편이 도움이 됩니다.

AI가 점검을 돕는다면 허용된 코드와 설정, 실행 결과에서 먼저 확인한 내용을 남기고, 운영자가 결정할 사항이나 확인 자료가 부족한 부분을 질문하도록 할 수 있습니다. 결과에는 확인한 역할·자료·항목·작업을 적고, 화면만 확인했는지 실제 전달된 정보와 처리 결과까지 확인했는지도 구분해야 합니다. 이 기록이 있어야 다음 검토에서 빠진 범위를 이어서 확인할 수 있습니다.