Dots가 늘 일하는 AI라면, 한 번의 허락은 언제까지 유효할까요

핵심 요약

• AI에게 계속 판단을 맡기려면 권한의 범위와 만료 조건도 정해야 합니다.
• 정보를 읽는 권한과 외부에 메시지를 보내는 권한은 구분해야 합니다.
• 실행을 멈추는 기능과 이미 끝난 작업을 복구하는 기능은 별개입니다.
• 책임을 따지려면 최초 지시부터 승인과 실행까지의 기록이 필요합니다.

OpenAI Dots가 사용자의 요청이 끝난 뒤에도 계속 일하는 AI 에이전트라고 가정해 보겠습니다. 특정 제품 기능을 전제로 하는 이야기는 아닙니다. 이런 상황에서는 개별 작업뿐 아니라 다음에 무엇을 할지 정하는 판단까지 AI에게 맡기게 됩니다. 메일을 읽고 일정을 조율해 주면 편리하겠지만, 처음 내준 허락이 언제까지 유효한지도 따져야 합니다.

일을 계속하려면 판단도 계속해야 합니다

“다음 주 출장 준비해 줘”라고 AI에게 부탁했다고 합시다. 항공편을 비교해서 보여주는 데서 끝난다면 어디까지 맡긴 일인지 비교적 분명합니다.

그런데 가격을 계속 살피다가 적당한 항공편이 나오면 예약까지 한다면 사정이 달라집니다. 사용자가 화면을 닫은 뒤에도 에이전트는 새로 들어오는 정보를 보고 판단해야 합니다. 이런 동작을 지속적 자율성이라고 부를 수 있습니다.

정보를 확인하는 동안 사용자의 사정도 달라질 수 있습니다. 출장이 취소됐는데 에이전트가 이전 지시대로 항공권을 예약할 수도 있는 겁니다. 지시를 충실히 따랐더라도 사용자에게는 원치 않는 결과입니다.

그래서 일을 계속 맡기려면 시작 조건과 함께 권한이 끝나는 조건도 정해야 합니다. “금요일 오후까지만 확인하기”, “일정이 바뀌면 예약을 보류하기” 같은 규칙입니다.

메일을 읽는 허락이 보내는 허락은 아닙니다

에이전트에게 메일 접근 권한을 줬다고 해보겠습니다. 사용자는 받은 편지함을 요약해 주길 바랐을 수 있습니다. 그 허락이 답장을 보내도 된다는 뜻인지는 따로 따져야 합니다.

권한은 서비스 이름으로 묶기보다 허용할 행동을 나눠 정하면 더 명확해집니다.

• 받은 메일을 읽고 요약할 수 있습니다.
• 답장 초안을 저장할 수 있습니다.
• 외부 수신자에게 발송하려면 승인을 받아야 합니다.

어떤 메일을 언제까지 다룰지도 정할 수 있습니다. 특정 프로젝트의 메일만 읽게 하거나, 출장 준비가 끝나면 관련 접근 권한이 만료되도록 하는 식입니다.

필요한 만큼만 권한을 주자는 것이 최소 권한의 원칙입니다. 상시 에이전트라면 처음 권한을 설정하는 데서 그치지 않고, 상황이 바뀔 때 권한을 줄일 수도 있어야 합니다.

사용자도 현재 어떤 일을 맡겨 뒀는지 한눈에 볼 수 있어야 합니다. 에이전트가 오늘 하는 일을 통제하려고 지난달 지시까지 기억해 내야 한다면, 일을 맡기고 관리하는 것부터 부담스럽습니다.

매번 승인받으면 편리함이 사라집니다

그렇다고 행동할 때마다 확인창을 띄울 수는 없습니다. 메일 한 통을 읽을 때마다 승인해야 한다면 사용자는 일에서 손을 떼기 어렵습니다.

언제 승인을 받을지는 행동이 미칠 영향을 보고 정할 수 있습니다. 가령 정보 수집과 초안 작성은 자동으로 처리하게 합니다. 결제나 외부 발송처럼 다른 사람에게 영향을 주는 행동은 실행 직전에 확인을 받는 식입니다.

반복하는 업무라면 범위를 정해 자동으로 실행하게 할 수도 있습니다. 예를 들어 “지정한 거래처에서 월 합계 10만 원 이내로 소모품 주문하기”라는 규칙을 둘 수 있습니다. 여기서 10만 원은 설명을 위한 예시이며, 실제 한도는 업무에 맞게 정해야 합니다.

금액만 제한해서는 충분하지 않습니다. 배송지나 구매 품목이 바뀌면 다시 확인하도록 조건을 붙일 수 있습니다. 에이전트가 어떤 행동을 해도 되는지 판단하기 어려울 때는 일단 보류하도록 정해 둬야 합니다.

승인 화면에는 사용자가 무엇을 허락하는지 구체적으로 드러나야 합니다. “계속할까요?”라고 묻기보다 “이 수신자에게 이 내용의 메일을 지금 발송할까요?”라고 물어야 사용자가 판단하기 쉽습니다.

멈춤 버튼과 책임을 따질 기록이 필요합니다

상시 에이전트에는 사용자가 쉽게 찾을 수 있는 중단 기능이 필요합니다. 지금 어떤 작업을 실행하고 있고, 어떤 작업이 대기 중인지도 보여줘야 합니다.

다만 중단 버튼으로 이미 일어난 일까지 되돌릴 수는 없습니다. 보낸 메일은 상대가 읽었을 수 있습니다. 완료된 예약을 되돌리려면 취소 절차를 거쳐야 할 수도 있습니다. 앞으로의 실행을 막는 기능과 이미 끝난 작업을 복구하는 기능은 따로 설계해야 합니다.

문제가 생겼을 때 확인할 기록도 있어야 합니다. 처음에 어떤 지시를 내렸고, 실행 당시 어떤 권한이 유효했는지 살펴볼 수 있어야 합니다. 사람이 승인했다면 당시 승인 화면에 어떤 내용을 보여줬는지도 남겨야 합니다.

가령 사용자가 초안 작성을 요청했는데 메일을 발송했다면, 에이전트가 지시를 잘못 해석했는지부터 살펴야 합니다. 발송 권한을 너무 넓게 줬는지, 승인 절차가 제대로 작동하지 않았는지도 각각 확인해야 합니다.

이런 기록이 있다고 법적 책임까지 저절로 정해지지는 않습니다. 다만 어디에서 문제가 생겼고 무엇을 고쳐야 하는지 판단할 근거는 됩니다. “AI가 알아서 했다”는 설명만으로는 같은 실수를 막기 어렵습니다.

상시 위임은 사용자가 매 순간 지켜보지 않아도 일을 계속해 준다는 점에서 편리합니다. 안심하고 맡기려면 허락한 범위와 그 허락이 끝나는 시점이 분명해야 합니다. 잠든 사이 AI가 처리해도 되는 일과, 반드시 사용자를 깨워서라도 물어봐야 하는 일을 미리 나눠 둬야 합니다.