「전부 맡겨버리면 된다」는 유혹

어떤 운영 팀이든 비슷한 잡무가 쌓여간다. 인증 정보의 로테이션(Rotation), 계정 발행, 검증 환경 구축, 사용되지 않는 리소스의 소거. 모두 어렵지는 않지만, 은근히 손이 많이 간다. 생성 AI (Generative AI)가 자율적으로 스크립트를 작성하고, 티켓을 읽고, API를 호출할 수 있는 수준에 도달한 지금, 당연히 이런 생각이 들고 싶어진다. 그렇다면 처음부터 끝까지 AI에게 시켜버리면 되지 않을까.

하지만 솔직히 말해서, 그 「처음부터 끝까지」야말로 가장 위험한 부분이다. 티켓을 읽고, 무엇을 해야 할지 판단하며, 실행까지 해내는 에이전트 (Agent)에게는 광범위하고 상시 유효한 권한이 필요하게 된다. 하지만 그 「광범위하고 상시 유효한 권한」은 보안의 세계가 수십 년에 걸쳐 인간의 계정으로부터 배제하려고 노력해 온 바로 그것이다. 게다가 AI는 교묘한 지시나 불완전한 입력에 빠질 수도 있다. 인간보다 더 쉽게 잘못된 판단을 내릴 수 있다.

문제는 생성 AI의 능력이 낮은 것이 아니다. 많은 팀이 자동화를 시작하기 전에 「어느 정도의 권한을, 어느 정도의 기간 동안, 누구의 감독하에 넘길 것인가」를 결정하지 않고 있다는 점이다. 이것은 AI의 성능 문제가 아니라 권한 아키텍처 (Architecture)의 문제이며, 답의 상당수는 이미 보안 공학 (Security Engineering) 안에 있다. 나머지는 그것을 새로운 종류의 주체——생성 AI——에 다시 적용하기만 하면 된다.

최소 권한을 말 그대로 실천하기.

태스크를 자동화할 때의 첫 번째 반응은 에러가 나지 않을 때까지 역할을 과하게 부여하는 것이다. 본래 해야 할 일은 해당 태스크에 필요한 API 호출을 하나씩 나열하고, 그 외의 권한은 일절 주지 않는 것이다. 수고는 들지만, 이 수고는 금방 회수할 수 있다. 에이전트가 지시를 오해했을 때, 권한이 좁다면 피해도 그만큼 작게 끝난다.

직무 분리를 인간 이외의 주체에도 적용하기.

「지불을 신청하는 사람과 승인하는 사람은 달라야 한다」는 회계의 고전적인 원칙은 AI 운영에도 그대로 적용된다. AI는 「제안」——이 계정을 무효화해야 한다, 이 명령을 실행해야 한다, 예상되는 영향 범위는 이렇다——을 만드는 데 매우 능숙하다. 하지만 동일한 주체가 그 제안의 실행 권한까지 가져서는 안 된다. 「제안하는」 역할과 「실행하는」 역할을 AI와 인간, 혹은 AI와 독립된 자동 체크 (Automatic Check)로 나누어 둠으로써, 판단의 오류와 그 실행이 동시에 일어나 버리는 사고를 애초에 일어날 수 없는 구조로 만들 수 있다.

Human-in-the-loop를 이름뿐인 것으로 만들지 않기.

「인간이 승인하고 있습니다」라고 말하면서, 실제로는 메시지를 제대로 읽을 시간도 없이 「승인」 버튼을 누르고 있을 뿐인 팀은 적지 않다. 루프 (Loop)가 기능하는 것은 인간이 그 판단을 평가할 수 있을 만큼의 문맥과 시간을 실제로 가지고 있을 때뿐이다. 그러기 위해서는 AI의 역할을 「블랙박스적인 실행」이 아니라 「짧고, 구체적이며, 리뷰하기 쉬운 제안을 만드는 것」으로 좁히고, 인간의 역할을 「정말로 평가하는 것」으로 좁힐 필요가 있다.

Capability 방식의 유효 기간이 있는 권한.

자동화 시스템에 일종의 조작을 영구적으로 수행할 수 있는 상설 열쇠를 주는 것이 아니라, 해당 태스크 1회분에 한정된 유효 기간이 있는 열쇠를 승인이 내려졌을 때만 발행한다. 이 열쇠가 유출되거나 에이전트가 오작동하더라도, 피해가 미치는 시간은 서비스 계정의 수명이 아니라 몇 분 단위로 수렴한다. 구축하는 수고는 늘어나지만, 「어디까지 피해가 확산될 수 있는가」라는 질문을 끝없는 것이 아니라 작게 구획된 것으로 바꿀 수 있다.

태스크마다 해당 AI가 얼마나 많은 신뢰를 「획득」하고 있는지를 단계적으로 파악하는 공통 언어를 가지고 있으면 도움이 된다. 기준으로 다음과 같은 구분을 생각할 수 있다.

많은 팀이 해야 할 일은 어느 날 갑자기 「이제 AI에게 운영을 맡기자」라고 결정하는 것이 아니라, 태스크마다 이 단계를 한 단계씩 올라가는 것이다. 스테이트리스 (Stateless) 서비스를 재시작하기만 하는 스크립트와, 운영 데이터를 삭제할 수 있는 스크립트는 리스크의 질이 완전히 다르다. 양쪽을 「자동화」라는 같은 단어로 묶어버리는 것은 위험하다.

이 사고방식을 움직이는 데 특별한 인프라 (Infrastructure)는 필요 없다. 현실적으로 돌아가는 패턴의 한 예시는 다음과 같다.

• 위험한 조작(삭제·권한 박탈·배포 등)의 실체가 되는 스크립트는 미리 인간의 손으로 리뷰하여 준비해 둔다. AI가 그 자리에서 즉흥적으로 명령어를 구성하도록 하지 않는다.
• AI의 역할은 전달된 요청(티켓, 알림, Slack 메시지 등)을 읽고, 미리 준비된 여러 스크립트 중 "어느 것을" "어떤 파라미터(Parameter)로" 사용할지를 판단하는 것으로 한정한다. 제로 베이스에서 새로운 명령어를 발명하게 하지 않는다.
• 그 제안을 인간이 짧은 시간 내에 확인할 수 있는 형태—실행될 명령어, 대상, 예상되는 영향—로 제시한다.
• 승인이 내려진 후에야 비로소 실행에 옮긴다. 이상적으로는, 그 한 번의 조작에만 국한된 유효 기간이 있는 권한으로 실행한다.
• 모든 것을 기록으로 남긴다. 요금제 문제로 감사 로그(Audit Log)를 취득할 수 없는 SaaS와 같은 제약이 있다면, 그것은 "나중에 어떻게든 할 세부 사항"이 아니라, 해당 태스크에 부여할 수 있는 자율성의 상한선을 결정하는 현실적인 제약으로 취급한다.

이렇게 함으로써 AI는 "읽기", "트리아지 (Triage)", "판단의 초안 작성"이라는 특기 분야에서 충분히 역량을 발휘하면서도, 운영 환경을 실제로 변경하는 권한은 확인 가능한 범위 내에 머물게 할 수 있다.

실제로 발생하는 실패는 대개 화려하지 않다. "파일을 이동해 달라"는 한정적인 요청에 대해, 에이전트(Agent)가 인접한 파괴적인 행동—복사가 완료되었다고 판단한 순간 원래 파일을 삭제하는 등의 행동—을 멋대로 "논리적인 뒷정리"로서 실행해 버리는 케이스다. 실제로는 복사가 올바르게 끝나지 않았더라도 상관없이 삭제되어 버린다. 원래 요청의 어디에도 삭제 허가는 없었음에도 불구하고, AI가 자신의 판단으로 그 단계까지 넘어가 버리는 것이다.

그렇기에 가드레일(Guardrail)은 AI 자신의 "지시" 안에 두는 것이 아니라, 그 바깥쪽—권한의 경계, 정책 체크(Policy Check), 애초에 삭제라는 조작을 호출할 수 없는 스크립트—에 둘 필요가 있다. 지시는 잘못 읽힐 수 있다. 존재하지 않는 권한은 결코 사용되지 않는다.

이것은 AI 자체에 대한 이야기가 아니다. 최소 권한(Least Privilege), 직무 분리(Separation of Duties), 기간 한정 권한, 그리고 실제로 주의를 기울이는 인간—이 모든 것은 실수할 수 있는 인간이나 탈취된 서비스 계정(Service Account)을 전제로 설계되어 온 액세스 제어(Access Control) 이론의 오래된 지견이다. 생성형 AI는 그 동일한 사고방식을 적용해야 할, 매우 유능하면서도 때때로 자신감이 과한 새로운 주체를 팀에 부여했을 뿐이다. AI 운영에서 가장 큰 성과를 끌어내는 것은 가장 빠르게 가장 많은 권한을 넘겨준 팀이 아니라, 태스크마다 "이 AI가 실제로 어디까지의 권한을 획득했는가"를 세심하게 파악해 온 팀일 것이다.