AI에게 관리 권한을 주는 홈페이지라면 권한을 거두는 방법도 구체적이어야 한다. 버튼의 모양보다 다음 요청이 정말 거절되는지를 확인한 소스와 검사에서 그 판단을 정리했다.
버튼을 숨기는 것에서 요청을 막는 것으로 간다
관리 화면에서 버튼이 없어져도 이미 가진 키로 API를 호출할 수 있다면 정지는 완성되지 않는다. AI에게 글쓰기 권한을 주는 구조를 생각할 때도 같은 질문이 생긴다. 나는 실제 인증 소스를 읽고 키 자체의 상태뿐 아니라 연결된 실행 주체와 소유 계정 상태를 함께 확인하는 부분을 다시 살폈다.
이번 로컬 검사에는 한 번 인증한 실행 주체의 소유 계정을 정지한 뒤 다음 인증이 거절되는 조건이 있다. 또 생성 요청에 성공한 키를 회수한 뒤 같은 요청을 다시 보내면 저장 결과 재사용도 거절되는 조건이 있다. UI 표시가 아니라 다음 요청의 응답과 저장 횟수를 기준으로 검사하는 방법이다.
키·실행 주체·소유자의 상태를 함께 읽는다
원래 인증 흐름은 키의 해시로 기록을 찾고 활성 상태와 유효 기간을 검사한다. 이어 실행 주체와 그 소유자의 활성 상태를 확인한다. 키가 유효한 모양을 가진 것만으로 충분하지 않다. 그 키를 발급한 관계가 여전히 사용 가능한지를 다음 요청 시점에 확인하는 구조다.
이 검사를 넣어도 진행 중인 작업이 즉시 취소된다고 보장할 수는 없다. 마지막 권한 확인 뒤 이미 시작한 외부 작업은 다른 중단 절차가 필요할 수 있다. 캐시를 둔다면 정지 상태가 언제 반영되는지도 따로 정해야 한다. 나는 다음 요청의 거절과 이미 진행 중인 작업의 중단을 같은 성공으로 묶지 않는다.
한 번 만든 인증 결과 객체를 이후 요청에도 계속 쓰면 변경된 상태를 읽을 기회를 잃는다. 원래 검사는 성공한 뒤 상태를 바꾸고 인증 함수를 다시 호출한다. 이전 결과가 있었다는 사실과 현재 기록을 읽었다는 사실을 구별하는 이유다. 관리 화면의 정지 버튼을 검사하려면 버튼 실행과 상태 저장, 그다음 요청까지 연결해야 한다.
할 수 있는 동작과 접근할 대상을 나눈다
실행 주체가 확인되어도 모든 자료를 읽거나 쓸 수 있다는 뜻은 아니다. 원래 소스는 작업 범위와 대상 묶음을 별도로 확인했다. 읽기 권한이 있어도 다른 대상에 적용하면 거절하고, 사람의 읽기 권한도 해당 대상의 활성 허가를 확인한다. 실제 검사에서는 같은 대상의 허용과 다른 대상의 거절, 허가 회수 뒤 거절을 비교했다.
이 홈페이지의 공개 글 관리도 누가 API를 호출하는지와 어떤 원고가 공개 상태인지를 별도로 확인한다. 현재의 관리자 API는 이 작업의 전용 관리 범위다. 다른 프로그램의 세밀한 사용자 역할 체계가 여기에 그대로 구현되어 있다고 말하지 않는다. 독자가 가져갈 원리는 인증과 동작 범위, 자료 공개 상태를 각각 검사하는 것이다.
인증 함수에서 키가 회수되어 거절되는 것과 유효한 주체가 허용되지 않은 대상에 접근하는 것도 나누어 검사했다. 내부 오류 원인은 다르지만 일부 실제 읽기 경로는 자료의 존재를 드러내지 않도록 찾을 수 없음으로 응답한다. 오류 번호 하나만 보고 권한 시스템 전체를 판단하지 않고 내부 검사와 공개 응답의 계약을 함께 읽어야 한다.
지난 성공 기록도 새 요청의 권한을 대신하지 않는다
중복 요청 방지 기록은 같은 작업을 다시 저장하지 않기 위한 자료다. 현재 권한의 증명은 아니다. 실제 처리기는 인증과 동작 허용을 확인한 뒤 그 기록을 읽었다. 키 회수 뒤 같은 요청 키로 다시 접근하는 검사에서는 인증 오류가 나오고 기존 저장 내용은 바뀌지 않았다.
로그인 세션도 알 수 없는 값과 비활성 상태, 만료를 구별해 거절해야 한다. 원래 회귀 검사는 없는 세션과 승인 상태 변경, 미래와 무기한 키의 조건도 다룬다. 무기한 키를 허용하는 것과 만료 없는 세션을 허용하는 것은 별도 계약이다. 이번 글은 검사된 조건을 설명하며 운영 키의 기간을 보편적인 정답처럼 추천하지 않는다.
거절되는 경로를 로컬에서 다시 재현한다
원래 소스의 인증 회귀 검사 일곱 개와 재요청 검사 다섯 개를 이번에 실행해 열두 개가 통과했다. 저장소와 키는 로컬 가상 조건이며 실제 운영 계정을 정지하거나 다른 사이트 키를 회수하지 않았다. 어떤 상태 변경을 만들었고 다음 요청이 무엇을 반환했는지 근거를 남기는 방식이다.
새 기능을 운영에 붙일 때는 허용되는 요청 하나만 보지 않고 권한을 줄인 뒤의 요청과 다른 대상 요청을 함께 확인해야 한다. 실제 저장소의 반영 시간과 캐시, 진행 중인 작업도 다음 검증에 포함한다. 나는 AI에게 맡길 수 있는 일을 늘리는 만큼 멈추게 할 경계와 확인 자료도 같이 남기려 한다.