권한과 승인 설계

에이전트에게 도구를 연결하는 순간 많은 팀은 이렇게 생각한다. "이제 이 일도 시킬 수 있겠네." 하지만 운영에 들어가면 더 중요한 질문은 따로 드러난다. 이 에이전트는 무엇을 하면 안 되는가. 실제 제품의 품질은 대개 여기서 갈린다.

똑똑한 모델은 일을 잘 시작할 수 있다. 그러나 권한이 넓고 승인 흐름이 허술하면, 잘 시작한 일이 곧 큰 사고로 이어질 수도 있다. 파일을 읽어야 할 에이전트가 수정까지 해버리고, 초안을 작성해야 할 에이전트가 실제 발송까지 해버리고, 조회만 하면 될 도구가 운영 데이터를 바꾸어버리는 식이다. 에이전트 하네스에서 권한 설계는 단순한 보안 옵션이 아니다. 행동의 경계선을 그리는 제품 설계다.

권한은 기능 설명이 아니라 행동의 한계다

도구 목록은 에이전트가 할 수 있는 일을 보여준다. 반면 권한 정책은 에이전트가 어디까지 할 수 있는지를 정한다. 둘은 비슷해 보이지만 완전히 다르다.

예를 들어 캘린더 도구가 있다고 해보자. 이 도구가 있다고 해서 에이전트가 언제나 일정을 생성해도 된다는 뜻은 아니다. 어떤 경우에는 빈 시간만 읽을 수 있어야 하고, 어떤 경우에는 초안만 만들 수 있어야 하며, 어떤 경우에는 사용자 승인 후에만 실제 생성이 가능해야 한다. 도구는 손에 쥔 공구이고, 권한은 그 공구를 어느 작업장에서 어떤 규칙 아래 쓸 수 있는지 정하는 장치다.

그래서 권한 설계는 "이 도구를 연결할까?"보다 한 단계 더 깊다. "이 도구를 어떤 상태에서, 어떤 범위까지, 누구 대신 쓰게 할까?"를 묻는다. 이 질문이 빠지면 에이전트는 기능은 많지만 통제는 어려운 존재가 된다.

읽기 권한과 쓰기 권한은 같은 권한이 아니다

실무에서 가장 먼저 분리해야 하는 것은 읽기와 쓰기다. 둘 다 단순한 접근처럼 보이지만, 실패의 성격이 완전히 다르다.

읽기 권한의 위험은 정보 노출이다. 에이전트가 문서를 읽고, 고객 데이터를 조회하고, 내부 위키를 검색하는 행위는 겉보기에는 얌전하다. 하지만 이 단계에서 민감한 정보를 과하게 끌어오거나, 필요 없는 자료를 섞어 읽거나, 읽은 정보를 다른 곳에 노출하면 문제가 생긴다. 읽기는 조용하지만 넓게 번진다.

쓰기 권한의 위험은 상태 변경이다. 파일 수정, 메일 발송, 일정 생성, 결제 승인, 티켓 종료, 데이터 삭제 같은 행동은 세상에 흔적을 남긴다. 한 번의 잘못된 쓰기는 나중에 정정할 수는 있어도, 이미 혼란과 비용을 만든 뒤일 수 있다. 쓰기는 시끄럽고 즉각적이다.

이 차이 때문에 좋은 하네스는 읽기와 쓰기를 절대로 한 덩어리로 다루지 않는다. 읽기 전용 도구와 상태 변경 도구를 나누고, 같은 시스템을 다루더라도 조회 단계와 실행 단계를 분리한다. 사용자가 "이번 주 가능한 회의 시간 알려줘"라고 했을 때는 읽기 권한만 필요하다. "그 시간으로 일정 잡아줘"가 되어야 비로소 쓰기 권한이 등장한다.

이 구분은 단순하지만 효과가 크다. 많은 사고가 고급 보안 기술 부족이 아니라, 조회와 실행을 섞어 놓은 설계에서 시작되기 때문이다.

권한은 대상, 행동, 범위, 시간으로 잘라야 한다

권한을 설계할 때 흔히 "캘린더 접근 허용", "이메일 사용 가능"처럼 시스템 단위로 생각한다. 하지만 이렇게 두루뭉술하게 열어두면 실제 운영에서 제어가 어렵다. 권한은 더 잘게 나누어야 한다.

같은 캘린더 권한이라도 이런 차이가 있다.

• 내 일정의 읽기만 가능한가

• 특정 캘린더에만 쓰기 가능한가

• 참석자 추가는 가능하지만 외부 초대는 금지인가

• 오늘 하루 동안만 가능한가

• 사용자 승인 후 한 번만 가능한가

즉, 권한은 보통 네 가지 질문으로 쪼개서 봐야 한다. 무엇에 대한 권한인가, 어떤 행동인가, 어느 범위까지인가, 언제까지 유효한가. 이 네 가지가 흐리면 에이전트는 너무 많은 자유를 얻게 된다.

예를 들어 문서 도구를 연결할 때도 "문서 편집 가능"으로 끝내면 위험하다. 초안 폴더만 편집 가능한지, 발행된 문서는 수정 금지인지, 공유 설정 변경은 막을 것인지, 삭제는 사람만 할 수 있는지까지 나누어야 한다. 권한은 넓은 깃발이 아니라 잘게 잘린 지도여야 한다.

위험도는 도구가 아니라 행동에서 결정된다

같은 도구라도 어떤 행동을 하느냐에 따라 위험도가 완전히 달라진다. 그래서 권한 설계는 "이 도구는 위험하다" 식으로 뭉뚱그리기보다, 어떤 행동 조합이 위험한가를 봐야 한다.

예를 들어 이메일 도구를 생각해보자. 받은 편지함을 읽는 것은 중간 정도의 민감도를 가질 수 있다. 답장 초안을 만드는 일은 그보다 한 단계 덜 위험할 수도 있다. 하지만 실제 발송은 상황이 달라진다. 외부 고객에게 잘못된 메시지를 보내면 되돌리기 어렵다. 대량 발송이나 첨부파일 전송이 붙으면 위험도는 더 올라간다.

파일 시스템도 비슷하다. 작업 폴더 안에서 임시 파일을 만드는 일은 비교적 안전할 수 있다. 그러나 설정 파일을 수정하거나, 운영 비밀값이 담긴 경로를 읽거나, 기존 결과물을 덮어쓰는 행동은 다른 등급으로 봐야 한다.

결국 위험도는 도구 이름이 아니라 행동의 결과에서 나온다. 읽기인지 쓰기인지, 가역적인지 비가역적인지, 내부 영향인지 외부 영향인지, 단일 객체인지 대량 작업인지가 훨씬 중요하다.

승인 흐름은 권한 부족의 보완책이 아니라 설계의 일부다

권한을 잘 나눠도 모든 상황을 정적으로 결정할 수는 없다. 어떤 행동은 평소에는 허용되지만, 특정 조건에서는 사람 확인이 필요하다. 바로 여기서 승인 흐름이 등장한다.

많은 팀이 승인을 귀찮은 안전장치로 본다. 하지만 실무에서는 승인도 하나의 인터페이스다. 잘 설계된 승인 흐름은 자동화를 망치지 않으면서도 사고를 크게 줄인다.

핵심은 단순하다. 항상 승인받게 하지 말고, 위험한 순간에만 선명하게 멈추게 하라. 모든 행동에 승인 버튼을 붙이면 사용자는 금방 무뎌진다. 반대로 정말 중요한 행동 앞에서만 멈추면, 사람의 주의력은 더 가치 있게 쓰인다.

좋은 승인 흐름은 보통 두 단계를 가진다. 먼저 에이전트가 하려는 일을 사람이 이해할 수 있는 형태로 요약한다. 그다음 실제 실행 여부를 묻는다. 이때 "계속할까요?" 같은 추상적 문구는 도움이 안 된다. 무엇을, 어디에, 어떤 영향으로 실행하는지 보여줘야 한다.

예를 들어 "고객 17명에게 일정 변경 메일을 발송합니다"와 "고객 커뮤니케이션 작업을 실행할까요?"는 전혀 다르다. 승인 설계는 기술 문제가 아니라 이해 가능성의 문제이기도 하다.

가장 좋은 승인 패턴은 초안과 실행의 분리다

사람과 에이전트가 함께 일할 때 가장 강력한 패턴 중 하나는 draft-first, 즉 초안 우선 구조다. 에이전트는 먼저 제안하고, 사람은 검토한 뒤, 필요할 때만 실제 실행을 허용한다.

이 구조가 좋은 이유는 단순하다. 에이전트는 준비 작업을 잘한다. 회신 문안을 만들고, 일정 후보를 고르고, 변경 계획을 정리하고, SQL 초안을 작성하는 일은 꽤 능숙하다. 문제는 마지막 버튼이다. 그 마지막 버튼은 종종 사업적 책임, 대외 커뮤니케이션, 법적 영향과 연결된다.

그래서 많은 쓰기 작업은 다음처럼 나누는 편이 좋다.

• 조회

• 초안 생성

• 승인

• 실제 실행

이렇게 나누면 사람은 처음부터 모든 일을 직접 하지 않아도 된다. 대신 중요한 순간에만 개입하면 된다. 자동화의 이익은 유지하고, 책임의 경계도 분명해진다.

특히 이메일, 일정, 결제, 고객 데이터 수정, 문서 발행 같은 작업은 이 패턴이 매우 잘 맞는다. 에이전트가 초안을 잘 만드는 것과, 실제로 그 행동을 세상에 반영해도 되는 것은 다른 문제이기 때문이다.

위험도에 따라 권한 단계를 나눠야 한다

모든 쓰기 작업을 같은 등급으로 취급하면 설계가 거칠어진다. 반대로 등급을 너무 많이 만들면 운영이 복잡해진다. 실전에서는 대개 몇 개의 선명한 단계로 나누는 편이 좋다.

가장 이해하기 쉬운 구조는 다음과 같다.

• 관찰 단계: 읽기만 가능하다. 조회, 검색, 요약, 비교, 초안 준비가 중심이다.

• 제안 단계: 변경안을 만들 수 있지만 실제 반영은 못 한다. 초안 메일, 수정 계획, 패치 제안이 여기에 속한다.

• 제한된 실행 단계: 영향 범위가 작고 되돌릴 수 있는 작업만 허용한다. 예를 들어 자신의 작업 폴더 수정, 임시 브랜치 생성, 개인 메모 업데이트처럼 비교적 좁은 쓰기다.

• 승인 기반 실행 단계: 외부 발송, 운영 데이터 변경, 공용 문서 반영, 일정 생성, 티켓 종료처럼 결과가 남는 작업은 승인 후에만 실행한다.

• 금지 단계: 삭제, 대량 수정, 권한 변경, 비밀값 접근, 결제 승인처럼 고위험 작업은 기본적으로 막고, 별도 프로세스로만 허용한다.

이런 단계 구조의 장점은 에이전트가 무엇을 못 하는지 명확해진다는 점이다. 사람도 제품을 신뢰하기 쉬워진다. "이 에이전트는 알아서 다 한다"보다 "여기까지는 자동, 여기서부터는 승인"이 훨씬 운영 가능한 문장이다.

사람이 개입해야 하는 지점은 적을수록 좋지만 정확해야 한다

사람 개입은 많을수록 안전해 보인다. 그러나 실제로는 과한 개입이 더 위험할 때가 있다. 승인 요청이 너무 자주 오면 사용자는 읽지 않고 누르게 된다. 그러면 승인 장치는 존재하지만 판단은 사라진다.

그래서 중요한 것은 개입 횟수가 아니라 개입 위치다. 다음과 같은 순간은 사람 개입 지점으로 잡기 좋다.

첫째, 외부 세계에 결과가 나갈 때다. 메일 발송, 고객 메시지 전송, 결제, 공용 문서 게시처럼 바깥으로 영향이 퍼지는 순간은 한 번 더 보는 편이 낫다.

둘째, 되돌리기 어려운 변경일 때다. 삭제, 권한 변경, 계약 정보 수정, 배포, 일정 확정처럼 나중에 복구 비용이 큰 행동은 자동 실행보다 승인 기반이 적합하다.

셋째, 에이전트가 예외 상황에 들어갔을 때다. 평소 패턴에서 벗어난 데이터, 충돌, 누락, 상충된 정보가 나타나면 사람에게 넘기는 편이 안전하다.

넷째, 대량 작업일 때다. 한 건 수정은 괜찮아도 천 건 수정은 다른 위험도를 가진다. 양이 늘어나면 리스크도 다른 등급으로 봐야 한다.

좋은 승인 설계는 사람을 에이전트의 상시 운전사로 만들지 않는다. 대신 중요한 교차로에서만 신호등 역할을 하게 만든다.

되돌릴 수 있는 작업과 없는 작업을 구분하라

권한과 승인 설계에서 매우 실용적인 기준이 하나 있다. 바로 가역성, 즉 되돌릴 수 있느냐는 점이다.

예를 들어 초안 문서를 만드는 일은 대개 되돌리기 쉽다. 임시 브랜치를 만드는 일도 비교적 복구가 가능하다. 잘못된 차트를 생성한 것도 다시 만들면 된다. 이런 작업은 제한된 자동 실행으로 맡기기 좋다.

반면 고객에게 보낸 메일, 삭제된 데이터, 외부 시스템에 등록된 일정, 확정된 결제, 배포된 코드 변경은 되돌리기 어렵거나 되돌리더라도 비용이 크다. 이런 작업은 같은 쓰기 권한이라도 다른 층으로 봐야 한다.

좋은 하네스는 가능한 한 세상을 바로 바꾸지 않고, 먼저 되돌릴 수 있는 중간 상태를 만든다. 예를 들어 바로 운영 DB를 갱신하기보다 변경 제안을 만들고, 바로 메일을 보내기보다 발송 대기함에 넣고, 바로 main 브랜치에 쓰기보다 PR을 생성하는 식이다. 이 한 단계 차이가 사고 규모를 크게 줄인다.

최소 권한 원칙은 에이전트에게 더 엄격해야 한다

보안에서 익숙한 최소 권한 원칙은 에이전트 하네스에서는 더 중요하다. 사람은 문맥을 알고, 이상한 상황을 눈치채고, 스스로 멈출 수 있다. 에이전트도 어느 정도 그렇게 보일 수는 있지만, 실제로는 규칙과 확률 위에서 움직인다. 따라서 사람보다 더 넓은 권한을 주면 안 된다.

최소 권한 원칙을 에이전트에 적용할 때는 이런 식으로 생각하면 좋다.

처음에는 읽기 중심으로 시작한다. 그다음 초안 생성 권한을 준다. 이후 좁은 범위의 쓰기를 허용한다. 마지막으로 승인 기반 실행을 붙인다. 처음부터 모든 쓰기와 네트워크와 외부 계정 연결을 열어두는 방식은 편해 보여도 오래 못 간다.

또한 권한은 가능하면 작업 단위로 발급하는 편이 좋다. 영구적이고 넓은 자격보다, 특정 작업 동안만 유효하고 특정 자원에만 닿는 권한이 훨씬 낫다. "이 에이전트는 언제나 모든 고객 정보를 수정할 수 있다"보다 "이 작업에서 이 고객 레코드 초안만 수정할 수 있다"가 훨씬 안전하다.

도구별로도 권한 차등이 필요하다. 같은 에이전트라도 검색 도구는 넓게 읽을 수 있고, 쓰기 도구는 매우 좁게 제한해야 한다. 최소 권한은 계정 수준의 설정만이 아니라, 도구 조합 수준의 설계여야 한다.

승인 없는 자동화보다 위험한 것은 모호한 승인이다

승인을 붙였다고 해서 설계가 끝나는 것은 아니다. 오히려 나쁜 승인 인터페이스는 사용자에게 거짓 안도감을 줄 수 있다. "허용" 버튼은 눌렀지만, 무엇을 허용했는지 모르는 상황이 생기기 때문이다.

좋은 승인 요청은 적어도 세 가지를 분명히 보여줘야 한다. 무엇을 하려는지, 어디에 영향을 주는지, 되돌릴 수 있는지다. 여기에 한 가지를 더 붙이면 더 좋다. 지금 승인하지 않으면 어떤 대안이 있는지다.

예를 들어 "CRM 고객 상태를 변경합니다"보다 "고객 12명의 상태를 lead에서 qualified로 변경합니다. 기존 상태로 되돌릴 수 있습니다. 먼저 미리보기 CSV를 검토할 수도 있습니다."가 훨씬 낫다. 이 문장은 사용자에게 판단 재료를 준다.

승인은 결국 사람의 책임 판단을 돕는 인터페이스다. 에이전트가 만든 결정을 사용자가 눈으로 이해할 수 있어야 한다.

역할에 따라 권한도 달라져야 한다

모든 사용자와 모든 에이전트가 같은 권한을 가질 이유는 없다. 조직에서 주니어 직원, 팀 리더, 재무 담당자가 같은 시스템 권한을 갖지 않듯, 에이전트도 역할에 따라 다른 경계를 가져야 한다.

예를 들어 리서치 에이전트는 검색과 요약은 넓게 할 수 있어도, 고객 데이터 수정 권한은 전혀 필요 없다. 코딩 에이전트는 저장소 안에서 브랜치를 만들고 테스트를 돌릴 수 있어도, 배포 버튼은 누르지 못해야 한다. 개인 비서형 에이전트는 일정 조회와 메일 초안 작성은 가능해도, 외부 발송은 승인 후에만 허용하는 편이 좋다.

이런 분리는 성능을 떨어뜨리기 위한 것이 아니다. 오히려 각 에이전트가 자기 일에 집중하게 만들어 품질을 높인다. 너무 많은 권한을 가진 에이전트는 강력해 보이지만, 실제로는 판단 공간이 넓어져 더 자주 흔들린다.

좋은 권한 설계는 실패했을 때도 사고를 작게 만든다

권한과 승인 설계를 잘하면 에이전트가 절대로 실수하지 않는 것은 아니다. 중요한 것은 실수했을 때 사고 반경이 작아진다는 점이다.

조회만 가능한 에이전트는 잘못 이해해도 세상을 크게 바꾸지 못한다. 초안만 만드는 에이전트는 엉뚱한 답을 내도 사람이 걸러낼 수 있다. 승인 기반 실행 구조에서는 마지막 순간에 브레이크를 걸 수 있다. 반대로 모든 권한이 한 번에 열려 있으면, 작은 오해 하나가 큰 변경으로 이어진다.

이 차이는 제품 운영에서 엄청나게 크다. 좋은 하네스는 영리함보다 먼저 실수의 비용을 낮추는 구조를 만든다. 권한 설계는 바로 그 비용 상한선을 정하는 일이다.

실무에서 바로 쓰는 권한 설계 질문

권한과 승인 구조를 검토할 때는 복잡한 표보다 몇 가지 질문이 더 도움이 될 때가 많다.

• 이 에이전트는 읽기만 해도 충분한가, 아니면 실제 변경이 필요한가

• 쓰기가 필요하다면 초안과 실행을 분리했는가

• 변경 대상은 개인 작업 공간인가, 공용 자산인가, 외부 시스템인가

• 되돌릴 수 있는가, 되돌리기 어렵다면 승인 지점이 있는가

• 한 건 작업인가, 대량 작업인가

• 이 행동은 지금 이 작업에 꼭 필요한가

• 권한은 영구적인가, 아니면 작업이 끝나면 사라지는가

• 사용자는 무엇을 승인하는지 한눈에 이해할 수 있는가

이 질문에 선명하게 답할 수 없다면, 대개 권한 설계가 아직 거칠다는 뜻이다.

권한은 에이전트를 믿지 않아서가 아니라 오래 믿기 위해 설계한다

권한 설계를 이야기하면 종종 분위기가 경직된다. 마치 에이전트를 못 믿어서 자꾸 묶어두는 것처럼 들리기 때문이다. 하지만 실제로는 반대다. 잘 설계된 권한 구조가 있어야 에이전트를 더 자주, 더 넓게, 더 오래 쓸 수 있다.

안전장치 없는 자동화는 한두 번 멋져 보일 수 있다. 그러나 운영에서는 금방 불안해진다. 팀은 결과를 의심하고, 승인 없이 실행되는 행동을 무서워하고, 결국 자동화를 꺼버린다. 반대로 읽기와 쓰기를 분리하고, 위험도에 따라 승인 흐름을 설계하고, 최소 권한 원칙을 지키면 사람은 에이전트에게 더 많은 일을 맡길 수 있다. 통제가 있기 때문이다.

좋은 작업장에는 공구만 있는 것이 아니다. 잠금장치도 있고, 위험 구역 표시도 있고, 마지막으로 멈출 수 있는 스위치도 있다. 에이전트 하네스에서 권한과 승인 설계는 바로 그 스위치와 잠금장치에 해당한다.

에이전트에게 무엇을 시킬 수 있는가보다, 무엇을 못 하게 만들 것인가가 더 중요하다. 그 선이 분명할수록 자동화는 오히려 더 강해진다.

다음 장에서는 이 권한 구조 위에서 에이전트가 무엇을 기억하고, 무엇을 상태로 남기며, 무엇을 버려야 하는지 살펴본다. 권한이 행동의 경계라면, 메모리와 상태는 행동의 흔적이기 때문이다.