AI 권한 경계 설계법

AI 에이전트에게 일을 맡길 때 가장 위험한 문장은 ‘알아서 해줘’입니다. 사람에게는 맥락이 있지만 에이전트에게는 실행 범위, 금지 범위, 검증 기준, 멈춤 조건이 명시되어야 합니다. 헤르메스 운영에서 권한 경계는 자동화를 막는 장벽이 아니라 오래 달릴 수 있게 만드는 레일입니다.

권한 경계가 없으면 작은 콘텐츠 수정도 배포, DB 반영, 공개 페이지 스캔, 외부 알림, 다른 작업 파일까지 번질 수 있습니다. 반대로 경계가 너무 좁으면 매번 사람이 손으로 확인해야 하므로 24시간 운영의 장점이 사라집니다. 핵심은 작업 종류별로 ‘자동 진행’, ‘증거 보고 후 진행’, ‘사전 승인 필요’, ‘즉시 중단’의 네 단계를 미리 나누는 것입니다.

왜 권한 경계가 자동화의 출발점인가

헤르메스는 글 작성, 라이브 스모크, Q&A 점검, 크론 실행, DB-only 업로드처럼 반복 운영에 강합니다. 하지만 반복 운영일수록 작은 실수가 누적되기 쉽습니다. 권한 경계는 에이전트가 무엇을 해도 되는지보다 무엇을 하면 안 되는지를 먼저 정합니다. 이 순서가 안전합니다.

좋은 권한 경계는 세 가지 질문에 답합니다. 첫째, 이 작업의 소유 대상은 무엇인가. 둘째, 어떤 상태가 확인되면 계속 진행해도 되는가. 셋째, 어떤 신호가 나오면 성공 직전이라도 멈춰야 하는가. 이 세 질문이 없으면 자동화는 빠르지만 설명하기 어려운 상태가 됩니다.

예를 들어 DB-only Hermes 글을 올리는 작업의 소유 대상은 임시 JSON 한 건과 그 공개 URL입니다. git 커밋, 크론 생성, 다른 섹션 코드 수정은 소유 대상이 아닙니다. 따라서 업로드가 성공해도 git 작업을 하지 않는 것이 정상입니다. 반대로 배포 검증 작업의 소유 대상은 특정 커밋과 공개 경로이므로 DB-only 업로드는 범위 밖입니다.

권한 등급을 네 단계로 나누기

이 표의 목적은 에이전트를 겁주는 것이 아니라 판단 비용을 줄이는 것입니다. 반복 작업에서 매번 새로 고민하지 않고, 작업 카드에 등급을 붙인 뒤 해당 등급의 절차를 따릅니다.

실제 운영 순서

1. 작업 범위를 한 문장으로 고정한다

운영 시작 전에 ‘이번 작업은 무엇을 바꾸는가’를 한 문장으로 씁니다. 좋은 문장은 대상, 방식, 종료 조건을 포함합니다. 예를 들어 ‘Hermes 운영 팁 JSON 한 건을 DB-only로 업로드하고 live smoke 후 임시 파일을 보관 위치로 이동한다’는 범위가 명확합니다. 반대로 ‘Hermes 콘텐츠를 개선한다’는 너무 넓습니다.

범위 문장이 좁을수록 자동화는 강해집니다. 에이전트는 범위 밖의 문제를 발견해도 곧장 고치지 말고 후속 위험으로 보고해야 합니다. Q&A 페이지에서 별도 공개 문구 문제가 보이면 Hermes 글 업로드를 멈추지 않고 별도 후속 항목으로 남기는 식입니다.

2. 쓰기 권한과 읽기 권한을 분리한다

읽기 권한은 넓어도 됩니다. 공개 페이지, repo 상태, 테스트 결과, HTTP 응답, 브라우저 콘솔은 운영 판단에 필요합니다. 쓰기 권한은 좁아야 합니다. 파일 생성, DB 업로드, revalidate 호출, 설정 변경, 스케줄 변경은 각각 다른 위험을 가집니다.

DB-only 콘텐츠 운영에서는 임시 JSON 생성과 단일 포스트 업로드만 허용합니다. git 조작, 크론 변경, 환경 설정 출력, 대량 동기화는 별도 권한입니다. 이 분리가 있으면 한 작업의 실패가 다른 운영 축으로 번지지 않습니다.

3. 민감정보와 출력 경계를 먼저 정한다

민감정보는 보이지 않게 조심하는 것이 아니라 출력 경계를 설계해야 합니다. 결과 보고에는 값이 아니라 상태만 씁니다. 예를 들어 ‘업로드 명령이 성공했고 갱신 응답이 정상’이라고 말하면 충분합니다. 연결 문자열, 인증값 이름, 로컬 파일 경로, 개인 토큰 위치처럼 공격자가 힌트로 삼을 수 있는 정보는 공개 글과 운영 보고에서 제외합니다.

에이전트가 오류를 만났을 때도 원문 전체를 붙여 넣지 않습니다. 오류 종류, 실패 단계, 재시도 여부, 다음 조치만 요약합니다. 필요하면 원문은 로컬 증거 패킷에 보관하되 공개 보고에는 싣지 않습니다.

4. 검증 기준을 실행 전에 정한다

권한 경계는 검증 없이 완성되지 않습니다. ‘업로드했다’가 아니라 ‘검증을 통과했다’가 종료 조건입니다. Hermes 글이라면 스키마 검증, 품질 스캔, DB 업로드, 갱신 응답, /hermes 목록, /hermes/slug 상세, 공개 금지어 스캔, 브라우저 콘솔 확인이 한 묶음입니다.

검증 기준을 실행 후에 만들면 성공한 것처럼 보이는 증거만 고르게 됩니다. 실행 전 기준은 에이전트가 스스로를 속이지 못하게 하는 장치입니다.

상황별 예시

DB-only 콘텐츠 발행

단일 Hermes 팁을 올리는 경우 에이전트는 임시 JSON을 만들고 검증한 뒤 업로드합니다. 성공 후에는 원본을 보관 위치로 이동해 작업 트리를 깨끗하게 유지합니다. 이 작업에서 허용된 쓰기는 임시 콘텐츠 파일, DB 업로드, 보관 이동뿐입니다. git 커밋이나 스케줄 수정은 범위 밖입니다.

실패하면 업로드하지 않고 초안을 보관합니다. 품질 미달의 예시는 FAQ 부족, 상황별 예시 없음, 권한 경계 설명 누락, 검증 방법 부재, 공개 금지어 포함입니다. 이때는 ‘자동 보완 후 업로드’가 아니라 실패 이유를 남기고 멈추는 편이 안전합니다.

배포 검증

배포 검증 작업의 권한은 읽기 중심입니다. 공개 경로가 200인지, 새 마커가 보이는지, 콘솔 오류가 없는지, 단일 H1인지, 금지 문구가 없는지를 확인합니다. 배포 실패를 발견했다고 해서 자동으로 롤백하거나 다른 파일을 수정하면 권한 경계를 넘어섭니다. 롤백 기준이 사전에 승인되어 있을 때만 다음 단계로 갑니다.

Q&A 운영

Q&A에서는 공개 페이지 안전이 핵심입니다. 자동 답변 워커를 한 번 실행하거나 공개 목록에서 내부 문구를 찾는 것은 비교적 낮은 위험입니다. 그러나 질문 숨김, 재처리, 내부 노트 추가, 대량 정리는 사용자 콘텐츠 상태를 바꾸므로 더 높은 권한입니다. 반드시 작은 범위와 증거 보고가 필요합니다.

Q&A 운영의 좋은 기본값은 읽기 전용 확인입니다. 목록이 열리는지, 공개 카드가 중복되지 않는지, 답변 상태가 방문자 언어로 보이는지, 테스트성 질문이 노출되지 않는지 확인합니다. 상태 변경이 필요하면 한 질문 또는 한 패턴으로만 제한하고, 변경 전후 공개 화면을 비교합니다. 여기서 중요한 점은 에이전트가 ‘정리해도 될 것 같다’고 판단하는 순간이 아니라, 미리 정한 숨김 기준과 검증 기준이 맞을 때만 쓰기 작업을 수행한다는 점입니다.

모바일 원격 운영

휴대폰으로 운영 지시를 내릴 때는 문장이 짧아지기 때문에 권한 경계가 더 중요합니다. ‘확인해줘’는 읽기 전용인지 수정까지 포함하는지 모호합니다. 모바일 원격 운영에서는 기본값을 읽기 전용으로 두고, 쓰기 작업은 대상과 종료 조건이 명시될 때만 허용하는 방식이 안전합니다.

모바일에서는 화면이 작아 긴 로그와 diff를 제대로 검토하기 어렵습니다. 따라서 모바일 지시는 ‘상태 확인’, ‘단일 항목 업로드’, ‘공개 화면 확인’처럼 작게 쪼개야 합니다. 큰 변경이 필요하면 에이전트가 요약 증거를 만들고, 사람이 넓은 화면에서 확인한 뒤 다음 실행을 허용하는 편이 낫습니다. 이 방식은 속도를 조금 늦추지만 실수 비용을 크게 줄입니다.

비용과 토큰 관리

권한 경계에는 비용도 포함됩니다. 한 번의 작업이 반복 검색, 긴 빌드, 브라우저 확인, 대량 문서 읽기를 계속 수행하면 토큰 예산과 실행 시간이 빠르게 늘어납니다. 비용 권한을 정하지 않으면 에이전트는 ‘더 확인하면 더 안전하다’는 방향으로 끝없이 움직일 수 있습니다.

운영자는 작업 카드에 소모 상한을 적어야 합니다. 예를 들어 읽기 전용 점검은 대표 경로와 한 개 상세 페이지로 제한하고, 실패가 나오면 전체 크롤링으로 확장하기 전에 중간 보고를 남깁니다. 콘텐츠 작성도 한 주제, 한 slug, 한 업로드로 제한합니다. 여러 주제를 발견하면 다음 작업 큐로 넘깁니다.

증거 패킷과 재개 조건

권한 경계가 잘 지켜졌는지는 최종 결과만으로 판단하기 어렵습니다. 그래서 짧은 증거 패킷이 필요합니다. 증거 패킷에는 작업 범위, 실행한 검증, 마지막 성공 단계, 실패 또는 경고, 재개 조건이 들어갑니다. 긴 로그가 아니라 다음 운영자가 바로 판단할 수 있는 상태 카드입니다.

재개 조건은 특히 중요합니다. ‘나중에 확인’은 조건이 아닙니다. 좋은 재개 조건은 ‘목록 마커가 보이면 공개 완료로 전환’, ‘브라우저 콘솔 오류가 사라지면 다음 섹션 smoke 진행’, ‘작업 트리가 깨끗하면 다음 DB-only 발행 허용’처럼 관찰 가능한 문장입니다. 이 조건이 있으면 세션이 끊겨도 다음 에이전트가 임의로 범위를 넓히지 않습니다.

동시 작업과 충돌 방지

24시간 운영에서는 다른 에이전트나 크론 작업이 동시에 움직일 수 있습니다. 같은 저장소에서 한쪽은 콘텐츠를 만들고 다른 한쪽은 테스트를 고치면, 작업 트리 상태만 보고도 권한 경계가 흔들립니다. 그래서 선행 상태 확인이 필요합니다. 현재 작업이 만든 파일인지, 이미 있던 변경인지, 다른 작업이 만든 untracked 파일인지 구분해야 합니다.

DB-only 운영에서는 동시 작업이 있어도 git 조작을 하지 않으므로 충돌 위험이 낮습니다. 하지만 content 아래에 임시 파일을 남기면 다음 작업이 그것을 실제 소스 변경으로 오해할 수 있습니다. 업로드 성공 후 보관 위치로 이동하고, 품질 실패 시 초안 위치로 이동하는 이유가 여기에 있습니다. 깨끗한 종료 상태는 권한 경계의 일부입니다.

권한과 보안 경계

권한 경계는 계정 권한만의 문제가 아닙니다. 콘텐츠, 데이터, 배포, 알림, 비용, 시간도 모두 권한입니다. 에이전트가 토큰을 많이 쓰는 장기 작업을 계속 실행하는 것도 권한 사용이고, 공개 페이지에 내부 언어를 남기는 것도 권한 실패입니다.

보안 경계는 네 층으로 나눕니다. 첫째, 비밀값은 읽더라도 출력하지 않습니다. 둘째, 공개 콘텐츠에는 내부 절차명을 그대로 쓰지 않습니다. 셋째, 데이터 변경은 단일 대상과 되돌리기 방법이 있을 때만 수행합니다. 넷째, 외부 서비스 호출은 실패해도 재시도 횟수와 중단 기준을 넘지 않습니다.

이 원칙을 지키면 자동화가 느려 보일 수 있습니다. 그러나 실제로는 반대입니다. 경계가 명확하면 에이전트는 사람에게 묻지 않고도 많은 저위험 작업을 계속 처리할 수 있습니다.

실패 시 중단 기준

다음 신호가 나오면 작업을 계속하지 않습니다.

• 의도하지 않은 파일 변경이나 작업 트리 오염이 생겼다.
• 공개 페이지에서 내부 관리자 문구, 비밀정보 힌트, 테스트성 문구가 보인다.
• 업로드는 됐지만 목록이나 상세 live smoke 마커가 확인되지 않는다.
• 검증 명령이 실패했는데 원인이 현재 작업 범위 밖이다.
• 외부 서비스 호출이 반복 실패하고 재시도 기준을 넘었다.
• 에이전트가 필요한 권한과 금지된 권한을 구분하지 못하는 상태가 됐다.

중단은 실패가 아니라 안전한 운영 결과입니다. 중요한 것은 멈춘 뒤 어떤 증거를 남기는가입니다. slug, 단계, 마지막 성공 지점, 실패 신호, 재개 조건을 짧게 기록하면 다음 운영자가 이어받을 수 있습니다.

검증 체크리스트

• 이번 작업의 대상과 범위가 한 문장으로 고정됐는가?
• 읽기 권한과 쓰기 권한이 분리됐는가?
• 자동 진행, 증거 보고, 사전 승인, 즉시 중단 등급이 정해졌는가?
• 민감정보와 내부 언어가 공개 글이나 보고에 나오지 않는가?
• 품질 검증, 업로드 검증, 라이브 스모크, 브라우저 콘솔 확인이 연결됐는가?
• 실패 시 중단 기준과 재개 조건이 명확한가?
• 작업이 끝난 뒤 임시 파일이나 불필요한 변경이 남지 않는가?

다음 단계

팀이나 개인 운영자는 자주 반복하는 작업 세 가지부터 권한 경계표를 만들면 됩니다. 예를 들어 DB-only 콘텐츠 발행, 배포 검증, Q&A 워커 점검을 먼저 나눕니다. 각 작업마다 허용된 쓰기, 금지된 쓰기, 검증 명령, 라이브 확인 경로, 중단 기준을 적습니다.

그다음 헤르메스에게 맡길 작업 카드에 이 표를 붙입니다. 에이전트가 작업을 끝낸 뒤에는 결과뿐 아니라 경계 준수 여부를 보고하게 합니다. ‘무엇을 했다’보다 ‘무엇을 하지 않았고 왜 멈추지 않았는가’가 운영 신뢰를 만듭니다. 권한 경계가 습관이 되면 24시간 자동화는 더 과감해지면서도 더 안전해집니다.