외근 비서 에이전트 만들기

[Claude Code] 자기 전 텔레그램 하나로 “내일 아침 몇 시에 일어날지” 정해진다 — 외근 비서 에이전트 만들기

📝 한줄 요약

외근이 많아서 매일 캘린더와 지도 앱을 번갈아 켜며 “몇 시에 출발해야 하지?”를 계산하던 일을, Claude Code로 만든 개인 비서 에이전트에게 넘겼습니다.

이제 자기 전 텔레그램 메시지 한 통이면 “아, 내일은 이쯤 일어나면 되겠네” 하고 알람만 맞추고 자면 됩니다.

바쁘시면 이것만 읽어도 돼요

• 무엇을: 개인/회사 Google Calendar를 읽어, Telegram으로 전날 저녁·당일 아침에 “일정 + 이동 동선 + 출발 시각”을 브리핑하는 비서를 만들었어요.

• 핵심 가치: 미팅 시각에서 거꾸로 역산해 “출발할 시각 기준 이동시간”을 계산하므로 지도 앱을 다시 열지 않아도 됩니다.

• 정확도 한 끗: 현재 교통이 아니라 실제 출발할 시각의 교통량으로 계산하는 미래 교통 예측을 붙였어요.

• 인상 깊었던 점: “설계 확인 → 범위 확정 → 구현 → 검증” 사이클로 차곡차곡 쌓이는 안정감, 그리고 실제로 텔레그램에 알림이 딱 도착한 순간.

• 외근 많은 사람에겐: 자기 전·아침마다 일정 확인하던 일이 통째로 하나 줄어듭니다.

• 제일 큰 교훈: 한 번에 다 만들려 하지 말고 잘게 쪼개서 시키기.

• 새롭게 느낀 점: 바이브 코딩을 잘한다는 것은 단순히 AI에게 코드를 시키는 것이 아니라, 개발 구조를 이해하고 AI가 지금 어떤 일을 하고 있는지 판단하는 능력에 더 가깝다는 것.

🎯 이런 분들께 도움돼요

• 미팅·외근 일정이 잦아서 매일 동선을 직접 계산하는 직장인이나 대표

• “오늘 몇 시에 나가야 안 늦지?”를 캘린더와 지도 앱을 오가며 매번 확인하는 분

• 코딩은 잘 몰라도 Claude Code 같은 AI 도구로 내 업무를 자동화해보고 싶은 분

• AI에게 코드를 시키고 있지만, 어떻게 해야 더 안정적으로 결과물을 만들 수 있을지 고민하는 분

😫 문제 상황 (Before)

외근이 많은 일을 하다 보면, 하루 루틴에 은근히 반복되는 “잡일”이 하나 있습니다.

자기 전에 캘린더를 열어 내일 일정을 확인하고, 외부 미팅이 있으면 네이버지도나 카카오맵을 다시 열어 거기까지 얼마나 걸리는지 검색합니다.

그다음 미팅 시각에서 거꾸로 빼서 생각합니다.

“그럼 몇 시에 출발해야 하지?”

“준비까지 하면 몇 시에 일어나야 하지?”

미팅이 하루에 두 개 이상이면 더 골치 아픕니다.

첫 미팅이 끝난 뒤 다음 외근지까지 이동시간이 빠듯하지는 않은지, 그 사이에 충분히 도착할 수 있는지, 모든 일정을 마치고 집에는 몇 시쯤 돌아올 수 있을지를 또 따져야 합니다.

매번 앱 두세 개를 오가며 계산하는 게 별것 아닌 것 같아도, 매일 반복되면 꽤 피곤한 일입니다.

그래서 “이걸 누가 대신 계산해서 텔레그램으로 딱 알려주면 좋겠다”는 생각에서 시작했습니다.

🛠️ 사용한 도구

• Claude Code: 실제 프로젝트 파일을 읽고, 코드를 작성하고, 테스트를 실행하는 구현 담당

• GPT: 제가 원하는 기능을 구조화하고, Claude Code에게 전달할 구체적인 작업 지시문을 만드는 설계·검토 담당

• 모델: Claude Opus 4.x

• 연동: Google Calendar 읽기 전용, 카카오 지도/길찾기 API, Telegram 봇

• 특이사항: 약 5일에 걸쳐 기능을 작은 단계로 나누어 하나씩 쌓아 올림. 매 단계마다 진행 현황을 CLAUDE.md에 기록하며 다음 작업의 기준점으로 사용

처음에는 Claude Code 하나만으로도 충분히 만들 수 있을 거라고 생각했습니다.

그런데 실제로 진행해보니, GPT와 Claude Code를 번갈아 사용하는 방식이 훨씬 안정적이었습니다.

제가 원하는 기능을 GPT에게 설명하면, GPT가 그 내용을 구현 가능한 단위로 쪼개고 Claude Code에게 전달할 명령을 구체적으로 정리해줬습니다.

Claude Code는 그 지시를 바탕으로 실제 파일을 읽고, 코드를 수정하고, 테스트를 실행했습니다.

결과적으로 GPT는 설계자와 검토자에 가깝고, Claude Code는 구현자에 가까운 역할을 했습니다.

저는 그 둘이 지금 어떤 일을 벌이고 있는지 중간에서 확인하고, 범위가 너무 커지거나 방향이 틀어질 때 다시 조정하는 역할을 맡았습니다.

🔧 작업 과정

실제 작업 순서대로, 비서가 어떻게 점점 똑똑해졌는지 이야기처럼 풀어볼게요.

1. “일단 내 일정부터 읽게 하자” — 캘린더 연결

가장 먼저 한 일은 개인 캘린더를 읽어오게 하는 것이었습니다.

개인 Google Calendar에서 오늘과 내일 일정을 read-only로 읽어오는 최소 테스트 파일을 만들어주세요.

그런데 회사 캘린더에서 막혔습니다.

분명 일정이 있는데 조회하면 0건이 나오더군요.

알고 보니 제가 챙겨야 하는 “(레오)” 표시가 붙은 일정들이 회사 계정의 기본 캘린더가 아니라 별도 공유 캘린더에 들어 있었습니다.

Claude Code가 조회 대상 캘린더를 그 공유 캘린더로 바꿔주면서 해결됐어요.

또 한 가지 문제가 있었습니다.

회사 캘린더에는 다른 사람들의 미팅도 섞여 있었기 때문에, 제목에 “(레오)”가 들어간 일정만 제 일정으로 골라내도록 했습니다.

회사 계정은 절대 수정하지 않고 읽기 전용으로만 접근하도록 못박았고요.

2. “두 계정을 한 화면에” — 다중 캘린더 통합

개인 메일 계정이 두 개라 둘 다 연결하고, 회사 공유 캘린더까지 합쳐 총 3개 소스를 하나로 통합 조회하게 했습니다.

그리고 그 결과를 텔레그램으로 보내봤습니다.

실제로 폰에 일정 브리핑이 도착했습니다.

비서의 입과 눈이 처음 연결된 순간이었어요.

3. “이건 이동 계산이 필요한 일정인가?” — 똑똑한 분류

여기서부터 일반 캘린더 앱과 달라집니다.

모든 일정에 이동 계산이 필요한 건 아니니까요.

온라인 미팅이나 종일 일정은 빼고, 실제로 어딘가로 가야 하는 외부 일정만 골라내야 했습니다.

회사 일정 제목이 사람 이름이나 “지사장님”처럼 보이고 “(레오)”가 붙는 경우가 많았습니다.

이런 제목을 장소로 오인하면 안 됩니다.

“김미경 지사님(레오)” 같은 제목을 장소로 착각하지 않고 “장소 확인 필요”로 분류하게 다듬어주세요.

이런 식으로 일정의 성격을 하나씩 분류하게 만들었습니다.

4. “지도 앱 좀 그만 열고 싶다” — 핵심 가치

이번 프로젝트에서 제가 가장 원했던 부분입니다.

카카오 지도 API를 붙여서, 일정 장소를 좌표로 바꾸고 자차 기준 이동시간을 자동으로 계산하게 했어요.

이동시간 계산 API 연동을 시작하되, 범위를 아주 작게 잡아서 진행해주세요.

여기서도 작은 트러블이 있었습니다.

카카오 지도가 403 오류를 뱉길래 확인해보니, 개발자 콘솔에서 지도/길찾기 사용 설정을 켜지 않았던 것이 원인이었습니다.

설정만 켜니 바로 해결됐습니다.

그리고 한 가지 욕심을 더 냈습니다.

단순히 “지금 기준 이동시간”이 아니라, 실제로 출발할 시각의 교통량으로 계산해야 정확하잖아요.

오전 8시 출발과 오후 2시 출발은 막히는 정도가 완전히 다르니까요.

그래서 미래 시각의 교통을 예측하는 길찾기까지 붙여서, 미팅 시각에서 거꾸로 역산해 “그 시각에 출발하면 얼마나 걸리는지”의 정확도를 끌어올렸습니다.

설계할 때 한 가지 더 신경 쓴 건, 지도 서비스를 카카오 하나에 묶지 않은 것입니다.

나중에 네이버지도나 구글지도를 선택해서 쓸 수 있게 구조를 열어뒀어요.

사람마다 더 정확하다고 느끼는 지도가 다를 수 있고, 비용이나 API 신청 조건도 다를 수 있으니까요.

지금은 카카오로 동작하고, 네이버와 구글 연동은 다음 숙제로 남겨뒀습니다.

5. “그래서 몇 시에 나가면 돼?” — 출발 시각 역산 + 두괄식 브리핑

이제 본론입니다.

비서가 알아서 이렇게 계산하게 했어요.

미팅 10:00 시작
→ 20분 여유 두고 도착하려면 09:40 도착
→ 이동 48분이면 집에서 08:52 출발
→ 준비 40분 고려하면 08:12부터 준비 시작

그리고 외근이 여러 개인 날을 위해, 집 → 첫 외근지 → 다음 외근지 → 귀가까지 동선 전체를 이어서 계산하게 했습니다.

여기에 제가 정말 원했던 기능을 더했어요.

일정 충돌 경고입니다.

외근지 간 이동시간상 다음 미팅을 맞출 수 없으면, 부족한 시간과 함께 경고해줘.

첫 미팅이 12:30에 끝나는데 다음 외근지까지 2시간이 걸려서 14:00 미팅에 늦을 것 같으면,

“⚠️ 약 50분 부족 — 일정 조정이 필요합니다”

라고 미리 알려줍니다.

브리핑은 두괄식으로 만들었습니다.

메시지를 열자마자 맨 위에 “몇 시에 준비 시작, 몇 시에 출발”이 먼저 보이고, 세부 일정표는 그 아래에 둡니다.

바쁠 때 윗줄만 봐도 되니까요.

6. “자동으로, 그리고 미리 알려줘” — 스케줄러 + 출발 알림

마지막으로 이걸 자동화했습니다.

전날 저녁에는 내일 일정을, 당일 아침에는 오늘 일정을 알아서 텔레그램으로 보내게 했습니다.

제가 텔레그램에서 “오늘”, “내일”, “이번주”라고 직접 물어도 즉시 답하게 했고요.

여기에 출발 알림 예약까지 붙였습니다.

각 이동마다 다음처럼 알림이 가도록 했습니다.

1. 출발 10분 전

2. 출발 권장 시각

3. “지금 나가도 늦을 수 있어요”라는 마지노선 알림

프로그램이 잠깐 꺼졌다 켜져도 알림을 다시 챙기고, 일정이 바뀌면 옛 알림은 정리하고, 전송이 실패하면 재시도하는 안전장치까지 갖췄습니다.

테스트 알림이 예약한 시각에 실제로 폰에 딱 도착했을 때,

“아, 이거 진짜 되는구나”

싶었던 게 이번 작업에서 제일 짜릿한 순간이었어요.

✅ 결과 (After)

Before vs After

결과물

자기 전 텔레그램을 보고,

“아, 내일은 이쯤 일어나면 되겠네”

하고 알람만 맞추고 잡니다.

아침에는 일어나면 알아서 브리핑이 와 있어서,

“이때까지는 집에서 나가야 하는구나”

가 정해져 있고요.

외근이 많은 사람 입장에서는 매일 반복되던 일이 통째로 하나 줄어드는 셈입니다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 한 번에 다 만들지 말고 잘게 쪼개기

이번 작업에서 가장 큰 교훈입니다.

“일정 비서 만들어줘”라고 한 번에 요청한 것이 아니라,

• 개인 캘린더 읽기만

• 회사 캘린더 필터링만

• 이동이 필요한 일정 분류만

• 장소를 좌표로 바꾸는 기능만

• 자차 이동시간 계산만

• 출발 시각 역산만

• Telegram 전송만

이런 식으로 작은 단계로 끊어서 진행했습니다.

단계마다 정상 작동하는지 확인할 수 있었고, 문제가 생겨도 어느 단계에서 잘못됐는지 찾기 쉬웠습니다.

잘못된 경우에도 전체 코드를 되돌리는 것이 아니라 해당 단계만 수정하면 됐습니다.

2. 구현 전에 “설계부터 보고해줘”라고 요청하기

Claude Code에게 바로 코드를 작성하게 하기보다, 먼저 어떤 파일을 수정할지, 어떤 함수가 추가될지, 이번 단계에서 어디까지 구현할지를 보고하게 했습니다.

이 과정을 거치면 제가 원하지 않은 방향으로 코드가 커지는 것을 막을 수 있었습니다.

특히 Claude Code는 일을 잘 처리하지만, 때로는 여러 기능을 한 번에 묶어서 구현하려는 경향이 있었습니다.

빠르게 결과를 만들 수는 있지만, 범위가 커질수록 코드가 꼬이거나 나중에 검증하기 어려워질 수 있습니다.

그래서 다음과 같은 식으로 범위를 명확히 제한하는 것이 중요했습니다.

• 이번에는 이 파일만 수정해줘.

• 아직 Telegram에는 연결하지 마.

• 독립 테스트까지만 해줘.

• 다른 파일은 수정하지 마.

• 먼저 설계만 제안해줘.

3. GPT와 Claude Code를 번갈아 사용하기

제가 직접 Claude Code에게 명령을 내릴 때보다, GPT에게 현재 상황을 설명하고 Claude Code에 전달할 작업 지시문을 만들어달라고 했을 때 훨씬 명확하게 작동하는 경우가 많았습니다.

GPT는 제가 말한 요구사항을 다음처럼 구체화해줬습니다.

• 이번 단계의 목표

• 수정해도 되는 파일

• 수정하면 안 되는 파일

• 구현해야 할 함수

• 구현하지 말아야 할 기능

• 테스트 기준

• 실행해야 할 명령어

• 성공 여부를 판단할 기준

이렇게 정리된 명령을 Claude Code에 전달하면, Claude Code도 범위를 더 정확히 이해하고 작업했습니다.

다만 GPT와 Claude Code 모두 항상 완벽한 것은 아니었습니다.

GPT는 직접 더 알아보고 구체적인 답을 줄 수 있는 상황에서도 “Claude Code에게 확인해보세요”라고 다소 뭉뚱그려 넘기는 경우가 있었습니다.

반대로 Claude Code는 작업을 더 작게 나누는 것이 안전한 상황에서도 한 번에 여러 파일을 수정하고 기능을 연결하려는 경우가 있었습니다.

결국 중요한 것은 두 AI 중 하나를 맹목적으로 믿는 것이 아니라, 사용자가 지금 어떤 작업이 진행되고 있는지 이해하고 중간중간 범위를 조정하는 것이었습니다.

4. 진행 현황을 문서로 계속 남기기

작업이 길어질수록 AI도 이전 결정을 놓칠 수 있습니다.

그래서 완료한 기능, 아직 연결되지 않은 기능, 다음 구현 순서, 수정하면 안 되는 파일, 테스트 결과를 CLAUDE.md에 계속 기록했습니다.

이 문서 덕분에 Claude Code 세션이 바뀌거나 대화가 길어져도, 프로젝트의 기준점을 다시 읽고 이어갈 수 있었습니다.

이렇게 하면 안 돼요

욕심내서 “다 만들어줘”라고 던지기

한 번에 큰 기능을 요청하면 결과가 빠르게 나오는 것처럼 보이지만, 실제로는 검증하기 어렵고 문제가 생겼을 때 원인을 찾기도 어렵습니다.

집 주소·알림 시각 같은 값을 코드에 직접 박기

나중에 바꾸기 어려워집니다.

사용자마다 달라질 수 있는 값은 설정이나 프로필로 분리해야 합니다.

AI가 만든 결과를 이해하지 않고 계속 다음 단계로 넘어가기

코드가 실행된다고 해서 구조가 좋은 것은 아닙니다.

지금 어떤 파일이 어떤 역할을 하는지, 어떤 함수가 다른 함수에 연결되어 있는지, 아직 구현되지 않은 기능이 무엇인지 모른 채 다음 작업으로 넘어가면 나중에 오류가 생겼을 때 유지보수를 시키기도 어려워집니다.

바이브 코딩을 잘한다는 것은 무엇일까

이번 프로젝트를 진행하면서 “바이브 코딩을 잘한다”는 것이 단순히 AI에게 일을 많이 시키는 능력은 아니라는 생각이 들었습니다.

처음에는 개발을 잘 몰라도 원하는 기능을 말로 설명하면 AI가 알아서 만들어주는 것이 바이브 코딩이라고 생각했습니다.

물론 실제로 어느 정도는 가능합니다.

하지만 프로젝트가 조금만 복잡해지면, 사용자가 지금 어떤 일이 벌어지고 있는지 이해하지 못한 상태에서는 원하는 결과를 정확히 얻기 어렵습니다.

기능이 처음에는 작동하더라도, 중간에 오류가 생기거나 새로운 기능을 추가할 때 구조를 모르면 무엇을 어떻게 수정해야 할지 구체적으로 요청하기 어렵습니다.

AI가 한 번에 너무 많은 것을 수정하려고 하는지, 기존 구조와 충돌하는지, 지금 이 기능을 먼저 만드는 것이 맞는지 판단하기도 어렵습니다.

결국 바이브 코딩을 잘한다는 것은 코드를 직접 모두 작성하는 능력보다는, 개발의 기본적인 아키텍처와 구조를 이해하고 현재 프로젝트에서 어떤 일이 벌어지고 있는지 파악하는 능력에 더 가까운 것 같습니다.

아이러니하게도 AI 덕분에 개발을 공부할 필요가 없어진 것이 아니라, AI가 코드를 만들어줄 수 있게 되었기 때문에 비개발자도 개발 구조를 공부했을 때 훨씬 큰 레버리지를 얻을 수 있게 됐다고 느꼈습니다.

코드를 직접 처음부터 끝까지 작성하지 않더라도,

• 기능을 어떤 단위로 나눠야 하는지

• 데이터가 어디에서 들어와 어디로 나가는지

• 어떤 값은 코드가 아니라 설정으로 빼야 하는지

• 어떤 기능은 독립적으로 테스트해야 하는지

• 지금 구현이 전체 구조에서 어떤 위치에 있는지

이 정도를 이해할 수 있다면, AI에게 훨씬 정확한 지시를 내리고 더 안정적인 결과물을 만들 수 있습니다.

그래서 앞으로 바이브 코딩 실력을 높이기 위해서는 프롬프트 문장만 잘 쓰는 법보다, 개발 구조를 읽고 설계할 수 있는 기본기를 함께 키우는 것이 더 중요하겠다는 생각이 들었습니다.

🌍 다른 업무에 적용한다면?

“흩어진 정보를 모아서, 계산해서, 알아서 알려준다”는 구조는 외근 일정 외에도 쓸 수 있습니다.

예를 들면 다음과 같습니다.

• 여러 채널의 주문을 모아 아침마다 요약해주기

• 정기 보고서 초안을 미리 만들어 메신저로 보내주기

• 영업 일정과 고객 정보를 모아 다음 행동을 알려주기

• 여러 시스템에 흩어진 데이터를 모아 이상 징후를 알려주기

• 반복적으로 확인하고 계산해야 하는 업무를 자동 브리핑으로 바꾸기

매일 반복되는 확인·계산 작업이라면 비슷한 방식으로 비서를 만들 수 있습니다.

🚀 앞으로의 계획

• 지도 선택권 넓히기: 지금은 카카오로 동작하지만, 네이버지도·구글지도 중에서도 선택할 수 있도록 연동 추가

• KTX/SRT 같은 장거리 이동 역산: 집 → 출발역 → 탑승 → 도착역 → 목적지까지 구간을 나눠 계산

• 맥미니로 24시간 상시 운영: 컴퓨터를 켜두지 않아도 매일 자동으로 돌도록 안정화

• 대화로 즉석 변경: “이 미팅 장소 바뀌었어”, “이번엔 택시로 갈게” 같은 말을 알아듣고 다시 계산해주기

• SaaS 확장 검토: 외근이 많은 사람들을 위한 “외근자” 같은 앱·서비스로 발전 가능성 검토

📋 재사용 가능한 프롬프트

프롬프트 1: 큰 기능을 잘게 쪼개 진행하기

[내가 만들고 싶은 것]을 만들고 싶어.

다만 한 번에 다 만들지 말고, 가장 작은 단계부터 하나씩 진행해줘.

이번 단계에서는 [아주 작은 범위]만 구현하고, 나머지는 다음 단계로 미뤄줘.

구현 전에 먼저 어떻게 만들 건지 설계와 범위를 보고하고, 내 확인을 받은 뒤에 시작해줘.

프롬프트 2: 진행 현황을 문서로 유지하기

방금 완료한 작업을 [진행현황 문서]에 정리해줘.

완료한 항목과, 다음에 구현할 항목을 의존성 순서대로 정리해줘.

다음 작업으로 가장 안전한 1순위가 무엇인지도 알려줘.

프롬프트 3: 일정에서 출발 시각 거꾸로 계산하기

미팅 시작 시각에서 [도착 여유시간]과 이동시간을 빼서 집에서 출발할 시각을 계산해줘.

거기에 [준비 시간]을 더 빼서 몇 시부터 준비를 시작하면 되는지도 알려줘.

이동시간은 지금 기준이 아니라 [실제 출발할 시각]의 교통량 기준으로 계산해줘.

[도착 여유시간], [준비 시간]은 본인 상황에 맞게 바꿔 쓰세요.

프롬프트 4: AI가 수정할 범위를 제한하기

이번 단계에서는 [수정할 파일]만 수정해주세요.

[수정하면 안 되는 파일]은 건드리지 마세요.

아직 [다음 단계 기능]은 연결하지 말고, 독립 테스트까지만 진행해주세요.

수정 후에는 실행한 테스트와 성공 기준을 보고해주세요.