AI 어시스턴트가 일을 대신하려면 얼마나 많은 권한이 필요할까?

AI로 생성한 편집 일러스트: 정보 읽기와 메시지 발송 권한은 각각 설정합니다.

AI에게 이메일 정리, 회의 준비, 업무 팔로업을 맡기는 일은 이제 자연스럽게 느껴집니다. 망설여지는 순간은 권한 허용 버튼을 누를 때입니다. 어디까지 볼 수 있을까? 나를 대신해 무엇을 할 수 있을까? 이 권한을 나중에 다시 회수할 수 있을까?

최근의 한 논의가 이런 질문을 수면 위로 끌어올렸습니다. Business Insider가 10월 9일에 게재한 인터뷰에서 XMTP Labs CEO Shane Mac은 자신의 개인 금융 에이전트가 회사 Slack에 보고서를 올렸다고 밝혔습니다. 이 기사는 편집된 당사자 구술 기록이며, 독립적인 기술 감사가 아닙니다.

이 인터뷰는 이후 Reddit의 r/technology에 공유되었습니다. 논의에서 일부는 AI에게 민감한 정보를 맡기는 것에 반대했고, 또 일부는 개인 계정과 업무 계정이 왜 섞여 있는지 물었습니다. 이런 반응은 구체적인 우려를 보여줍니다. 어시스턴트가 정보를 읽는 동시에 메시지를 보낼 수 있을 때, 사용자는 정보의 행선지를 어떻게 파악할 수 있을까?

10월 12일에는 CNA가 게시한 TikTok 영상도 사용자가 AI 에이전트에게 권한을 너무 많이 주는지 논의했습니다. 영상 설명에 따르면 관련 발언은 사용자가 자신이 부여한 접근 권한을 이해할 수 있는지에 초점을 맞춥니다.

이런 내용이 모든 에이전트가 문제를 일으킨다는 것을 증명하지는 않지만, 권한이 개인 어시스턴트에 대한 대중의 논의로 들어왔다는 점은 보여줍니다. AI를 제대로 활용하려는 사람에게는 권한이 작업을 따라가야 합니다.

같은 이메일이라도 정리와 발송에는 다른 권한이 필요합니다

어시스턴트에게 이런 작업을 맡긴다고 가정해 봅시다. 매일 아침 답장이 필요한 이메일을 찾아 핵심을 정리하고, 몇 가지 답장 초안을 준비하는 것입니다.

이 일을 하려면 이메일을 검색하고 읽어야 합니다. 답장 초안은 대화에 먼저 표시하고 사용자가 확인하면 됩니다. 이메일 자동 발송, 삭제, 전달 설정 변경은 모두 별도의 권한 결정이어야 합니다.

처음부터 모든 작업을 열어두면 어시스턴트는 이 작업에 필요한 것보다 더 많은 능력을 갖게 됩니다. 나중에 프롬프트를 바꾸더라도 계정의 실제 접근 범위가 함께 바뀌지는 않을 수 있습니다.

먼저 작업을 세 가지 질문으로 나눌 수 있습니다.

• 무엇을 읽을 수 있는가? 어느 계정, 어느 기간, 어떤 자료인가?
• 무엇을 실행할 수 있는가? 검색과 읽기만인가, 아니면 발송·수정·삭제도 허용하는가?
• 결과는 누구에게 가는가? 현재 대화에 표시하는가, 아니면 명확한 개인 수신 주소로 보내는가?

이 세 가지는 각각 다루어야 합니다. 원본 앱의 권한은 접근 가능한 데이터를 결정하고, 연결 계층은 호출 가능한 작업을 제한할 수 있으며, 어시스턴트의 워크플로는 매개변수와 결과 수신자를 정해야 합니다.

세 계층은 각각 따로 설정해야 합니다. 그림은 작업 설계 권장 사항이며, 스위치 하나로 모든 제한이 완료된다는 뜻이 아닙니다.

‘읽기 전용’에도 명확한 정보 행선지가 필요합니다

읽기 전용 권한은 첫 단계 어시스턴트에 잘 맞습니다. 먼저 정보를 정리하고, 사람이 결과를 확인한 뒤, 실행 능력을 점차 늘리는 방식입니다.

하지만 읽기 자체도 정보를 어시스턴트의 처리 과정으로 가져옵니다. 어시스턴트가 원본 데이터를 수정할 수 없더라도, 다른 도구가 메시지 발송을 허용한다면 읽은 정보가 다른 곳으로 옮겨질 수 있습니다.

따라서 개인 아침 브리핑은 우선 개인 대화에 바로 표시하면 됩니다. 팀 브리핑은 팀이 승인한 데이터 출처와 수신 위치를 사용해야 합니다. 개인 재무, 가족 일정, 회사 메시지는 각각 연결과 출력 채널을 따로 마련할 가치가 있습니다.

메시지를 보내는 흐름에서는 계정과 수신 대상을 명확히 하고, 가능하면 안정적인 대상 식별자를 사용하며, 필요할 때 최종 내용을 사용자에게 확인시켜야 합니다. 비슷한 그룹 이름, 연락처 이름, 계정 라벨은 유일한 판단 근거로 적합하지 않습니다.

이것은 워크플로에서 구현해야 할 설계입니다. ‘메시지 보내기’ 호출을 허용한다고 해서 시스템이 모든 내용이 모든 수신자에게 적합한지 자동으로 판단하는 것은 아닙니다.

어시스턴트에게 설명 가능한 능력 세트를 부여하기

OOMOL에서는 이런 결정을 계정 연결과 인터페이스 호출 범위에 적용할 수 있습니다. 권한 제어 문서는 Provider 권한 범위, 연결 접근 권한, 허용되는 작업 호출을 각각 설명합니다.

예를 들어 이메일 정리 어시스턴트는 이메일 검색과 읽기만 허용하는 연결을 사용할 수 있습니다. 사용자를 대신해 메일을 보내야 할 때는 발송 작업에 맞는 능력을 따로 설정합니다. 같은 계정으로도 작업 범위와 구성원 접근 범위가 다른 여러 연결을 만들 수 있습니다.

구체적으로 어떤 권한 범위를 선택할 수 있는지는 원본 서비스의 지원에 달려 있습니다. 어떤 작업을 제한할 수 있는지도 현재 연결이 제공하는 인터페이스를 확인해야 합니다. 레코드 수준의 가시 범위는 여전히 원본 앱 권한과 요청 매개변수의 영향을 받습니다.

OOMOL의 사용자 정의 인터페이스 제한에는 놓치기 쉬운 세부 사항이 하나 있습니다. Proxy와 동적 call_tool 진입점을 비활성화한다는 점입니다. 이렇게 하면 호출이 명시적으로 허용된 작업에만 머물러, 또 다른 범용 진입점이 이미 선택한 범위를 넘어서는 일을 막습니다. 이 동작은 위 권한 문서에서 나온 것이며, 설정할 때 함께 확인할 수 있습니다.

팀이 연결 서비스를 직접 관리해야 한다면 OpenConnector가 오픈 소스, 자체 호스팅 경로를 제공합니다. 팀이 자신의 환경에서 연결 자격 증명, 작업 정책, 실행 기록을 관리하고, MCP나 HTTP 같은 진입점을 통해 어시스턴트에 앱 작업을 제공할 수 있습니다. 자체 호스팅 가이드는 런타임 인증, 허용 및 차단 작업, 그리고 민감 정보를 제거한 실행 기록 설정을 설명합니다.

이런 능력은 팀이 접근 경계를 설정하고 점검하는 데 도움이 됩니다. 어시스턴트에 반환되는 비즈니스 데이터는 여전히 민감 정보로 취급해야 합니다. 메시지 수신자, 내용 확인, 실행 확인도 어시스턴트나 앱의 워크플로에서 구현해야 합니다.

작지만 유용한 작업부터 권한을 부여하기

첫 버전의 어시스턴트는 한 가지 일만 하면 됩니다. 오늘의 회의와 관련 이메일을 읽고, 주의가 필요한 항목을 개인 대화에 올리는 것입니다.

올바른 계정을 선택하고, 맞는 자료를 찾고, 출처를 표시할 수 있는지 확인한 다음에 할 일 생성이나 메시지 발송 능력을 추가하는 것을 고려하세요. 작업을 하나 추가할 때마다 이렇게 답할 수 있어야 합니다. 그것이 어떤 작업을 위해, 어느 계정에 작용하며, 결과가 어디로 가는가?

멈춰야 할 때는 무엇을 회수해야 하는지도 알아야 합니다. 계정 연결 해제, 호출 자격 증명 취소, 예약 작업 취소는 각각 다른 통제 지점에 해당합니다. 이미 발송된 정보는 그것으로 자동으로 사라지지 않습니다.

시작하려면 OOMOL Connections에서 작업에 필요한 연결을 설정하고, 권한 제어 가이드에 따라 허용 작업을 좁힌 뒤, 어시스턴트에게 명확한 요청을 전달하세요.

오늘 주의해야 할 이메일을 정리해 줘. 검색과 읽기만 하고, 보내거나 삭제하지 마. 결과는 현재 대화에 표시하고 원본 메일 링크도 남겨 줘.

어시스턴트의 능력이 작업에 대응하면 권한을 이해하기 쉬워지고, 나중에 능력을 추가할 때도 근거가 더 분명해집니다.