AI가 함께 비는 시간을 찾은 뒤, 초대를 보낼지는 사람이 정한다

Larry

미나는 친구 두 명과 저녁을 먹으려고 캘린더의 AI 도우미에게 부탁했다. “우리 셋 다 비는 평일 저녁 좀 찾아 줘.” 몇 초 뒤 AI는 목요일 7시를 찾았다. 바로 다음 순간, 두 친구의 휴대폰에 회의 초대가 동시에 떴다. 제목은 미나가 캘린더에 임시로 붙여 둔 이름 그대로였다. 그중 한 명은 나갈 수 있을지 가족에게 먼저 물어보려 했는데, 이제 정식 초대에 “수락"이나 “거절"로 답해야 하게 됐다.

AI가 시간을 잘못 찾은 것은 아니다. 문제는 “시간 좀 맞춰 줘"를 한 가지 일로 다뤘다는 데 있다. 실제로는 세 가지 일이다. 함께 비는 시간 찾기, 내 시간 잡아 두기, 다른 사람에게 초대 보내기. 앞의 둘은 아무도 놀라게 하지 않지만 셋째는 다르다. 업무 상황이라면 놀라는 쪽은 고객이나 상사일 수 있고, 초대 제목은 사내 작업용 코드명일 수 있다. 그래서 AI는 기본적으로 후보 시간을 내놓는 데서 멈추고, 초대를 보내기 전에는 이번 건의 세부 사항을 모두 담은 미리 보기를 사람이 확인해야 한다.

시간을 찾았다고 초대까지 보내도 되는 것은 아니다

쓰는 사람 입장에서는 시간을 찾는 것과 초대를 보내는 것이 한 걸음 차이라서, AI에게 한꺼번에 맡기는 것이 자연스러워 보인다. 하지만 시스템 입장에서 둘은 성격이 완전히 다른 동작이다.

빈 시간을 찾으려면 어느 시간대가 차 있는지만 읽으면 되고, 회의 이름조차 알 필요가 없다. 초대를 보내는 것은 누군가를 대신해 다른 사람의 캘린더와 받은편지함에 일정을 넣는 일이다. Microsoft의 캘린더 API 문서는 분명히 적고 있다. 참석자가 들어 있는 일정을 만들면 서버는 모든 참석자에게 초대를 보내고, 이 동작은 끌 수 없다. Google의 캘린더 API는 모든 손님에게 알릴지, 외부 손님에게만 알릴지, 아무에게도 알리지 않을지 프로그램이 고르게 하지만, 같은 문서에서 알리지 않도록 하면 일정이 상대 캘린더에 동기화되지 않을 수 있다고 경고한다.

다시 말해 AI가 손님이 포함된 일정을 만드는 순간, 바깥에 미치는 효과는 이미 일어났다. 입력란이 하나 늘어난 정도가 아니다. 남을 대신해 약속을 한 것이다.

세 가지 일, 세 가지 권한

세 가지 일이라면 AI에게 주는 권한도 나눠야 한다.

빈 시간 찾기: 읽기 전용. 차 있는 시간과 빈 시간만 보고 후보 두세 개를 돌려준다. 회의 내용은 읽지 않고 아무것도 만들지 않는다.

내 시간 잡아 두기: 내 캘린더에만 쓰기. 사용자 본인의 캘린더에 “확인 대기"라고 표시한 임시 일정을 만든다. 손님은 넣지 않고 알림도 보내지 않는다.

다른 사람 초대: 매번 승인. 다른 사람에게 영향을 주는 유일한 동작이므로, 매번 미리 보기를 만들고 사람이 확인한 뒤에 실행한다.

이 구분은 프롬프트에 적는 데 그치지 않고 AI가 쓸 수 있는 도구에 반영되어야 한다. 시간만 찾는 AI에게는 초대를 보내는 도구를 아예 주지 않는다. 애플리케이션 보안을 다루는 개방형 커뮤니티 OWASP가 정리한 AI 에이전트 보안 지침도 같은 것을 권한다. 도구 권한을 읽기 전용과 쓰기 가능으로 나누고, 실행 전에 동작 미리 보기를 보여 주고, 사람의 승인을 이번의 구체적인 동작에 묶어서 대상이나 매개변수가 바뀌면 다시 승인받으라는 것이다.

미리 보기에는 누가 영향을 받는지 보여야 한다

“이 회의를 만들까요?“라는 질문은 너무 막연해서, 승인하는 사람은 자신이 무엇에 동의했는지 알 수 없다. 승인할 만한 미리 보기라면 적어도 다음이 나와야 한다.

어느 계정, 어느 캘린더가 주최자가 되는지;
손님이 각각 누구인지;
시작과 끝 시간, 시간대, 반복 여부;
제목, 설명, 장소, 즉 상대가 보게 될 내용;
누가 알림을 받는지.

승인은 이 세부 사항 묶음에 걸리는 것이지, “회의 하나 잡기"라는 의도에 걸리는 것이 아니다. 승인한 뒤에 하나라도 바뀌면, 예를 들어 시간을 30분 미루거나 손님을 한 명 더하면 미리 보기로 돌아가 다시 확인한다.

놓치기 쉬운 점이 하나 더 있다. 네트워크 시간 초과가 첫 시도의 실패를 뜻하지는 않는다. 초대가 나갔는지 확실하지 않은 상태에서 AI가 그대로 다시 시도하면 상대는 초대를 두 번 받을 수 있다. Microsoft의 API는 일정을 만들 때 거래 식별자를 붙여 서버에서 불필요한 중복을 줄일 수 있게 한다. 첫 시도가 성공했는지 시스템이 확인할 수 없다면 멈추고 사람에게 넘겨야 한다.

매번 확인하기엔 너무 느릴 때

매번 미리 보기를 확인하면 일정 조율이 조금 느려진다. 하루에 회의를 열몇 건씩 잡는 비서 업무라면 초대마다 확인하는 것이 너무 번거로울 수 있다. 범위가 분명할 때는 완화해도 된다. 예를 들어 손님이 사내의 정해진 구성원뿐이고, 시간이 근무 시간 안이고, 회의가 1시간 이하일 때만 미리 보기 뒤에 한꺼번에 보내도록 허용한다. 그 범위를 벗어난 초대, 특히 외부 고객, 인사, 의료, 아직 공개되지 않은 일과 관련된 것은 계속 한 건씩 확인한다.

또 사용자가 AI에게 캘린더 쓰기 권한을 주고 싶어 하지 않는다면 억지로 권할 필요가 없다. AI는 회의 초안이나 “캘린더에 추가” 링크를 만들고, 마지막 한 걸음은 사람이 하게 두면 된다. 자동화가 조금 줄어도 조율은 끝난다.

다음 단계로, 팀의 AI 일정 조율에는 먼저 한 가지만 시켜 보자. 차 있는 시간을 읽고, 시간대를 붙인 후보 두 개를 내놓고, 거기서 멈추는 것이다. 시간대, 날짜를 넘기는 일정, 기존 임시 일정이 제대로 처리되는지 확인한 뒤에 캘린더 쓰기를 검토한다. 초대를 받는 쪽에도 같은 문제가 있다. AI 일일 요약에 올라온 초대가 이미 수락했다는 뜻은 아니다. AI가 1순위로 올린 일이 오늘 내가 한 약속이라는 보장은 없다를 참고하자. 같은 층위 구분을 메일, 파일, 결제 도구에 넓히려면 상시 AI 비서는 멈추는 법부터 배운 뒤에 주요 계정에 연결한다를 참고하면 된다.

AI 정리 카드

우리 팀의 AI 일정 조율 흐름이 빈 시간을 찾은 뒤 바로 사람을 대신해 초대를 보내고 있지 않은지 확인하고 싶다.
판단 방법은 이 글에서 가져왔다: https://boosterminiclass.com/ko/posts/ai-calendar-proposal-invitation-boundary/
글의 관점은 이렇다. "시간 좀 맞춰 줘"는 세 가지 일이다. 함께 비는 시간 찾기, 내 시간 잡아 두기, 다른 사람에게 초대 보내기. 앞의 둘은 아무도 놀라게 하지 않지만 셋째는 다르다. AI는 기본적으로 후보 시간을 내놓는 데서 멈춰야 한다. 초대를 보내기 전에는 주최 계정, 손님, 시간, 시간대, 제목, 알림 대상을 담은 미리 보기를 사람이 확인하고, 세부 사항이 바뀌면 다시 확인한다.

먼저 나에게 질문 3개를 해 달라:
1. 이 AI 일정 조율 도구는 지금 어떤 동작을 할 수 있는가(차 있는 시간 읽기, 회의 내용 읽기, 일정 만들기, 손님 추가, 알림 보내기);
2. 사용자가 "시간 좀 맞춰 줘"라고 하면 실제로 어디까지 진행하는가;
3. 초대를 보내기 전에 사용자는 어떤 확인 화면을 보는가.

내 답을 바탕으로 다음을 출력해 달라:
- 각 동작을 세 가지 일 중 어디에 속하는지 분류하고, 두 가지 일에 걸쳐 권한이 지나치게 넓은 도구를 짚어 줄 것;
- 시간대를 붙인 후보 두 개를 내놓고 멈추는 최소 버전;
- 초대 전 미리 보기에 들어가야 할 항목과, 지금 빠진 항목;
- 한꺼번에 확인해도 되는 범위의 조건과, 반드시 한 건씩 확인해야 하는 경우.
일정을 만들거나 바꾸지 말 것. 정보가 부족하면 먼저 나에게 물어볼 것. 마지막으로, 발송을 허용할지는 이 흐름을 책임지는 사람이 정한다는 점을 상기시켜 줄 것.