저녁 무렵, 조사가 일단락되었을 때 "내일 8시에 이 확인 작업을 한다고 캘린더에 넣어줘"라고 AI 에이전트에게 말했습니다.

몇 초 후, Google 캘린더의 7월 24일에 일정이 등록되어 있었습니다. 제목도 설명문도 제가 말한 내용 그대로였습니다.

그 순간에는 "편리하네"라고 생각하고 끝냈지만, 나중에 다시 생각해보았습니다. 이걸 매번 시킬 거라면 어떻게 구조화하는 것이 좋을까?

AI에게 캘린더를 다루게 한다고 하면 가장 먼저 떠오르는 것은 MCP (Model Context Protocol)일 것입니다. Google Calendar의 MCP 서버를 연결하면 일정 생성, 검색, 변경, 삭제가 모두 가능합니다.

연결하고 싶어졌습니다. 솔직히, 연결할 뻔했습니다.

멈춘 이유는, 하고 싶은 일을 세어보았을 때입니다.

• 일정 1건 등록하기
• 가끔 알림 분(minute)을 바꾸고 싶음

이것이 전부였습니다. 기존 일정을 검색하고 싶은 것도, 빈 시간을 찾게 하고 싶은 것도 아닙니다. 단 1건을 등록하기 위해 OAuth를 거치고, 클라이언트 ID를 발급하고, 토큰 보관 장소를 결정하고, 만료되었을 때의 재인증을 고민해야 합니다. 균형이 맞지 않는다는 느낌이 들었습니다.

게다가 MCP는 설정한 CLI에서만 사용할 수 있습니다. 제 손안에서는 Claude Code 외에도 codex나 cursor-agent를 실행하며 그날의 작업에 따라 나누어 사용하고 있습니다. 캘린더만 Claude에서만 다룰 수 있다는 것은 은근히 불편한 일입니다.

그래서 그날 AI가 실제로 수행한 절차를 다시 살펴보았습니다.

• Google 캘린더의 일정 생성 URL을 조립한다
• 그 URL을 열고 "저장"을 누른다

이것뿐이었습니다.

1단계가 핵심입니다. URL을 조립하는 데에는 인증도 라이브러리도 필요 없습니다. 단순히 문자열을 만들고 있을 뿐입니다.

?action=TEMPLATE
&text=작업 확인
...

이 URL을 열면 입력란이 모두 채워진 상태의 일정 생성 화면이 나타납니다. 나머지는 저장 버튼을 누르기만 하면 됩니다.

즉, 브라우저 자동화 (Browser Automation) 기능이 없는 AI라도, URL을 출력하는 것까지는 동일한 결과를 낼 수 있다는 뜻입니다. 누르는 주체가 사람으로 바뀔 뿐입니다.

이 점을 깨달은 시점에서 방침이 결정되었습니다.

그림으로 나타내면, 1단계와 2단계에서 담당이 바뀔 뿐인 구조입니다. 브라우저 자동화 기능을 가진 환경에서는 저장까지 진행하고, 기능이 없는 환경에서는 1단계에서 멈춰 사용자에게 바통을 넘깁니다. 사용할 수 없는 기능이 늘어나는 것이 아니라, 단계가 하나 낮아지는 형태가 됩니다.

세 가지 선택지를 앞에 두고, 어떤 것이 자신의 용도에 적합할지 저울질하는 상황입니다. 비교한 것은 다음 세 가지였습니다.

A안: URL 조립 방식을 skill로서 작성해 둔다. 실행 환경에 따라 2단계 구조로 만든다.

• 제1단계 (모든 AI 공통): URL을 조립하여 제시한다. 사용자는 클릭하여 저장을 누른다.
• 제2단계 (브라우저 자동화가 있는 경우): 열어서 저장까지 자동으로 누른다.

B안: API를 직접 호출한다. 읽기/쓰기 양방향.

C안: 캘린더 기능을 한 곳에 집약하고, 나머지는 의뢰하는 형태로 만든다.

나란히 놓고 보니 판단은 의외로 간단했습니다.

C안은 애초에 단독으로 성립할 수 없다는 것을 쓰면서 깨달았습니다. 위임 대상인 Claude 측에 A 또는 B의 구현이 필요하므로, 이는 "A 또는 B를 만든 후의 배포 방식"에 대한 이야기였습니다. 선택지인 척했던 후속 공정이었습니다.

A안을 선택한 이유는 기능의 다양성 때문이 아닙니다. 가져야 할 물건(관리 요소)이 늘어나지 않기 때문입니다.

MCP를 도입하면 토큰이라는 기밀 정보가 하나 늘어납니다. 보관 장소를 결정하고, 실수로 커밋하지 않도록 주의하며, 만료되면 알아차리고 수정해야 합니다. 한 번의 설정처럼 보이지만 실제로는 은근하게 길게 이어지는 비용입니다.

그에 반해 늘어나는 기능은 현재로서는 사용하지 않습니다. "이번 주 빈 시간에 넣어줘"라고 말하고 싶어지면 그때 생각하면 됩니다.

또 하나, 다른 에이전트에서도 동작한다는 점은 상상 이상으로 효과적입니다. skill의 위치는 Junction으로 설정하여 각 CLI가 동일한 선반을 보도록 해두었기 때문에, 배치하는 즉시 모두에게 배포됩니다. 그날 우연히 codex를 사용하고 있더라도 동일한 방식으로 캘린더에 등록됩니다. 이러한 일관성은 기능이 하나 더 많은 것보다 효용이 크다고 느낍니다.

구현하면서 막혔던 곳은 딱 하나였습니다. ctz입니다.

&ctz=Asia/Tokyo

이것을 생략하면 UTC로 해석되어 9시간의 차이가 발생합니다. "내일 8시"가 "내일 17시"가 되어버립니다.

그날은 마침 설정되어 있어서 눈치채지 못했지만, 나중에 사양을 확인하다가 "아, 이거 안 붙였으면 사고 칠 뻔했네"라며 등골이 서늘해졌습니다. 이런 것을 매번 기억할 자신이 없어서, skill에 "생략 금지"라고 적어 두었습니다.

일본어 URL 인코딩 (URL encoding)도 필요합니다. 원문 그대로 전달해도 통하는 경우가 많지만, 인코딩해 두는 편이 안전합니다.

"시작 10분 전 알림"을 하고 싶었지만, 일정 생성 URL에 알림을 지정하는 파라미터가 없습니다.

그래서 다음과 같이 구성했습니다.

이 부분은 B안이 명확하게 유리합니다. 솔직하게 패배를 인정하고, skill에는 "분(minutes)이 지정되면 알림란을 수정한다"는 절차를 적었습니다. 브라우저 자동화가 없는 환경에서는 캘린더 측의 기본 알림을 평소 사용하는 값으로 설정해 두면 실용상 문제는 없습니다.

내용은 3가지입니다.

URL 조립 규칙. 파라미터 표와 ctz (생략 금지 주의)

일시 결정 방식. 종료 시간은 항상 시작 시간 + 30분 고정. 모호하더라도 다시 묻지 않고 기본값으로 등록한 뒤 결과를 전달

실행 수단 분기. 브라우저 자동화가 있으면 저장까지, 없으면 URL 제시까지

두 번째는 제가 스스로 정한 규칙입니다. "30분이면 충분하다. 엄격한 시간이 필요할 때는 내가 직접 수정한다"라는 판단하에, AI에게 확인시키지 않는 것을 우선했습니다. 매번 "소요 시간은 어떻게 할까요?"라고 물어보는 편이 더 번거롭기 때문입니다. 틀렸다면 수정하면 되니까요.

그리고 실제로 실행하며 빠졌던 부분도 기록해 두었습니다. 저장 버튼을 좌표로 클릭했더니 첫 번째 시도가 빗나가고, 요소를 다시 잡은 뒤에 눌렀더니 성공했다는 이야기입니다. 다음의 저는 분명히 잊어버릴 것입니다.

A안과 B안은 배타적이지 않습니다. skill 절차의 맨 앞에 "MCP를 사용할 수 있다면 그것을 사용한다"를 끼워 넣으면, 2단계 구성이 3단계 구성이 될 뿐입니다.

그래서 언제 MCP를 도입할지에 대한 조건만 미리 적어 두었습니다.

• "이번 주 비어 있는 시간에 넣어줘"라고 말하고 싶어질 때
• "아까 일정을 30분 미뤄줘"가 필요해질 때
• "중복되면 넣지 마"가 필요해질 때

이 중 하나가 나타나면 그때 연결합니다. 나타나지 않으면 연결하지 않습니다.

미리 결정해 두면, 나중에 "역시 MCP가 더 좋지 않았을까"라며 흔들리지 않을 수 있습니다. 흔들리는 시간이 가장 아깝습니다.

처음에 MCP에 손을 뻗으려 했던 것은, 아마 "제대로 된 방법으로 하고 싶다"는 마음 때문이었을 것입니다. API를 올바르게 호출하는 것이 URL을 조립해서 브라우저로 여는 것보다 왠지 더 수준 높아 보이기 때문입니다.

하지만 제가 하고 싶은 것은 일정 한 건을 넣는 것이었습니다. 그 이상도 그 이하도 아닙니다.

거대한 시스템에 맞추기 전에, 실제로 수행한 절차를 분해해 봅니다. 이번에는 그 덕분에 인증(authentication) 문제를 하나 떠안지 않아도 되었습니다.

작게 시작하세요. 사용하는 도구는 필요해진 다음에 늘려가면 됩니다.

※ 헤더 이미지와 인포그래픽은 AI(이미지 생성)로 작성했습니다.

※ 본문의 삽화도 AI(이미지 생성)로 작성했습니다.

작성자: ishizakahiroshi

군마 북부에서 보호 고양이 2마리와 함께 사는 재택 엔지니어 (잡무 전문가)

X (업무 위탁·각종 상담은 이쪽으로):

백엔드·인프라·AI 연동 관련 업무 위탁 상담을 받고 있습니다. 풀 리모트(Full remote)입니다. 스팟(Spot)이나 주 2~3시간부터라도 환영하며, 다양한 프로젝트에 참여할 수 있다면 기쁘겠습니다. 다음과 같은 상담을 환영합니다.