관리 페이지

기존 admin 권한은 전체관리자 권한이다. 앱관리자는 전체관리자 권한을 부여하거나 다른 앱을 관리할 수 없다. 전체관리자가 해당 앱에서 사용자의 역할을 앱관리자로 지정한다. 일반 사용자의 앱 이용 권한과 관리자 역할은 별도 값이다.

로그인 후 서버가 확인한 권한에 따라 계정 화면(상단 사용자 이름을 누르면 가는 /login)의 왼쪽 사이드바 관리자 섹션에 전체관리자·앱관리자·위키 링크를 표시한다. 상단 헤더에는 관리자 링크를 두지 않는다. 링크 숨김 외에도 모든 관리 API가 검증된 Firebase Bearer 토큰과 앱별 권한을 다시 검사한다. 쿠키만 있는 요청은 관리 권한을 부여하지 않는다. 통합계정의 서비스 제한은 앱별 이용 허용보다 우선한다.

전체관리자 판정은 Firebase admin 클레임이 정본이며 기존 최초 관리자 경로는 검증된 이메일에만 적용한다. CONTEXTBIO_BOOTSTRAP_ADMIN_EMAILS를 비우면 해당 경로를 끌 수 있다. 전체관리자 승격 자체는 신뢰된 계정 운영 절차로 처리하며 앱관리 API로 임의 전체관리자를 생성할 수 없다.

사용자 현황과 집계

계정 하나는 한 이름으로 부른다. Gmail 주소는 로컬파트의 점과 +꼬리표를 뗀 형태를 정본으로 삼는다 — hyun.goo.woo@gmail.com과 hyungoowoo@gmail.com은 구글이 같은 사서함으로 배달하므로, 주소를 글자 그대로 열쇠로 쓰면 한 사람이 두 폴더와 두 벌의 권한을 갖고 한쪽에서 막아도 다른 쪽으로 들어온다. 점이 의미를 갖는 다른 도메인(hong.gildong@ajou.ac.kr)에는 적용하지 않는다. 이 규칙 이전에 만들어진 점 든 이름은 그대로 두고 조회만 맞춰 주므로 기존 자료 폴더를 잃지 않으며, 이름을 실제로 정리하려면 tools/gmail_keys.py로 레지스트리와 자료 폴더를 함께 옮긴다(서비스를 멈추고 실행한 뒤 백엔드를 재기동한다).

기존 공용 사용자 레지스트리의 해당 앱 사용자와 새로 접속한 사용자를 UID 기준으로 관리한다. 아직 방문하지 않은 사용자는 Firebase UID로 등록할 수 있다. UID가 없는 과거 산출물도 파일 목록에는 남으며 이름만으로 계정에 자동 귀속하지 않는다.

• 최종 접속: 해당 앱의 인증된 API 이용 또는 활성 화면 신호를 서버가 받은 시각이다. 관리자 페이지의 권한 확인만으로 다른 앱의 최종 접속 시각을 갱신하지 않는다.
• 사용시간: 앱 화면이 보이고 최근 입력 활동이 있을 때 전송되는 신호를 서버 시각으로 합산한다. 여러 탭은 중복 합산하지 않고 장시간 신호 공백은 제외한다. 분석 계산시간이나 GPU 사용시간과는 다르다.
• 집계 시작: 새 관리 기능 적용 이후 기록만 집계한다. 과거 사용시간을 소급 추정하지 않는다. 과거 공용 레지스트리의 접속 시각은 앱별 최종 접속으로 표시하지 않는다.
• 접속 기록: 화면 아래 "최근 관리 이력 · 접속 기록"에 사용자 변경·한도 변경·파일 삭제와 함께 로그인 접속이 한 줄씩 남는다. 최종 접속이 마지막 한 번만 보여주는 것과 달리 언제부터 언제까지 썼는지를 남기므로, 권한을 준 계정이 실제로 쓰는지, 막은 뒤에도 들어오는지를 확인할 수 있다. 같은 사람의 연속 사용은 한 줄로 묶고(30분 이상 끊긴 뒤 다시 오면 새 줄), 앱 이용 권한이 없는 요청은 애초에 통과하지 못하므로 접속으로도 남지 않는다. 관리 화면을 여는 것은 접속으로 세지 않는다.

월별 LLM 토큰 한도

월 경계는 UTC 달력 월이다. 한도 0은 LLM 요청 중지, 빈 값은 무제한이다. 분석 산출물 조회 권한은 토큰 한도와 별개다. 신규 사용자 기본 한도 변경은 이후 처음 등록되는 계정에 적용하며 기존 사용자는 개별 한도로 관리한다.

요청 전에 AURORA는 32,768, PepDesigner는 65,536 토큰의 예산을 예약한다. 남은 한도가 예약량보다 작으면 모델 호출 전에 429로 거부한다. API 워커들의 예약은 공유 잠금으로 직렬화하므로 동시 요청이 같은 잔여량을 중복 사용하지 않는다. 제공자가 반환한 실제 사용량이 있으면 예약을 해제하고 그 사용량으로 정산한다. 실제 사용량이 예약보다 큰 경우에도 수치를 자르지 않고 기록하며 이후 요청을 제한한다. 이는 제공자 측의 강제 생성 토큰 제한이나 결제 금액 상한을 대신하지 않는다.

실패·사용량 누락 시에는 예약량을 추정 사용량으로 반영하고 실제 집계와 구분한다. 프로세스가 종료되어 정산하지 못한 예약은 자동으로 풀지 않는다. 제공자 기록을 확인하기 전 재사용하면 한도를 우회할 수 있기 때문이다. 월말에 시작한 요청은 시작한 월에 정산한다. 이전 형식의 원격 LLM worker는 사용량을 반환하지 않을 수 있으므로 worker와 API를 함께 갱신한다.

LLM은 파이프라인 설정 제안만 담당한다. 관리 API, 사용자 권한, 사용량 장부, 파일 삭제, 시스템 환경·설정에 접근하지 않는다.

산출물 관리

사용자와 분석별 보관 폴더를 조회하고 이름으로 검색한다. 폴더를 열면 파일명·용량·수정 시각과 삭제 가능 여부를 보여주며 200개씩 전체 목록을 탐색할 수 있다.

파일 삭제는 관리자가 확인한 일반 산출물 파일만 대상으로 한다. 원본 입력, 실행 설정·기록, 심볼릭 링크와 디렉터리는 삭제하지 않는다. 실행 중이거나 상태가 불명확한 작업은 삭제를 거부한다. AURORA는 작업에 기록된 출력·리포트 디렉터리만, PepDesigner는 실행 폴더의 생성 파일만 관리한다. 경로를 URL에 임의로 지정해 다른 위치를 열거나 지울 수 없다.

PepDesigner 삭제는 분석 제출·재개와 같은 잠금을 사용하고 스케줄러 상태를 재확인한다. AURORA는 API 작업 생성과 삭제를 공유 잠금으로 구분한다. 관리 작업의 요청자·시각·대상·완료 여부를 감사 기록에 남긴다. 삭제한 파일은 복원되지 않으므로 중요한 결과는 별도로 보관한다.

운영자 배포 및 보관

공통 구현의 정본은 사이트 저장소 app_management.py이며 tools/sync_management.py로 두 앱의 사본을 동기화한다. 운영 장부 위치는 AURORA_MANAGEMENT_DIR, PEPD_MANAGEMENT_DIR로 지정한다. 기본값은 각 앱의 작업/사용자 데이터 옆 관리 디렉터리이며 소스 체크아웃과 정적 사이트에 넣지 않는다. 개발 환경은 별도 디렉터리를 사용한다.

장부는 파일 잠금과 원자적 교체를 사용한다. 같은 앱의 모든 API 워커가 같은 장부와 잠금을 보도록 구성하고 서비스 계정만 쓰게 한다. 장부를 삭제하면 권한·한도·사용 이력이 초기화되므로 백업 대상으로 관리한다. AURORA execution.lock이 비정상 종료 후 남았다면 해당 생성·삭제 요청이 종료됐는지 확인한 뒤 운영자가 복구한다.

배포 순서는 장부 경로·권한 준비, 두 앱 백엔드 및 원격 LLM worker 갱신, 인증/인가 및 한도 차단 검증, 회사 사이트 빌드·배포, 관리자 계정으로 두 역할과 링크 확인이다. 인증 없이 노출되는 정적 HTML에는 사용자 자료가 없고 실제 자료는 API 권한 검사 후 로드된다.