지도앱 그만 켜고 싶어서, AI로 ‘몇 시에 나가면 되는지’ 알려주는 일정 비서를 계속해서 만들어 가는 중...

지도앱 그만 켜고 싶어서, AI로 ‘몇 시에 나가면 되는지’ 알려주는 일정 비서를 계속해서 만들어 가는 중...

📝 한줄 요약

외부 미팅이 잡힐 때마다 캘린더와 지도앱을 번갈아 보며 “몇 시에 나가야 하지?”를 직접 계산하는 일이 번거로워서, AI와 함께 출발 시각을 자동으로 역산해주는 개인 일정·이동 비서를 만들었습니다.

Google 캘린더를 읽고, 이동 시간을 계산하고, 텔레그램으로 “몇 시부터 준비하고, 몇 시에 출발하면 되는지”를 알려주는 구조입니다. 10일 동안 Claude Code와 261번 대화했고, 작업 기록도 30개 정도로 쪼개가며 한 단계씩 쌓아 올렸습니다.

이번 작업을 하면서 느낀 건, 바이브 코딩이 생각처럼 “말하면 바로 뚝딱 완성되는 것”은 아니라는 점이었습니다. 오히려 내가 원하는 기능이 별것 아닌 것처럼 느껴져도, 실제로 안전하게 구현하려면 꽤 많은 설계와 검증, 반복이 필요했습니다.

바쁘시면 이것만 읽어도 됩니다.

• 만든 것: Google 캘린더를 읽어 텔레그램으로 “준비 시작 시각, 집에서 출발할 시각”을 알려주는 개인 일정·이동 비서

• 핵심 기능: 일정 시간에서 거꾸로 출발 시각을 역산하고, 알림이 울리는 순간 교통을 다시 확인해 최신 기준으로 안내

• AI 협업 방식: GPT에게는 요청을 구체화시키고, Claude Code에게는 그 요청을 바탕으로 실제 구현을 맡김

• 가장 크게 배운 점: 큰 기능은 한 번에 만들면 위험하고, 작게 쪼개서 설계 → 구현 → 테스트를 반복해야 안전함

• 솔직한 현재 상태: 아직 매일 실제로 돌리는 운영 단계는 아니고, 핵심 로직을 탄탄히 쌓아둔 구축 단계

• 느낀 점: 바이브 코딩도 거저먹기는 아니고, 제대로 만들려면 생각보다 오래 걸린다

🎯 이런 분들께 도움돼요

• 외부 미팅·외근이 잦아서 매번 이동 동선을 계산해야 하는 직장인, 대표, 영업 직군

• 코딩을 잘 몰라도 AI로 내 업무에 맞는 개인 도구를 만들어보고 싶은 분

• AI와 큰 프로젝트를 안전하게 진행하는 방법이 궁금한 분

• 캘린더, 메신저, 지도 API를 엮는 개인 비서/자동화 사례가 궁금한 분

• 바이브 코딩이 실제로 어느 정도까지 가능한지, 또 어디서 시간이 걸리는지 궁금한 분

😫 문제 상황

외부 미팅이 잡히면 늘 비슷한 일을 반복했습니다.

캘린더를 열어 일정 시간과 장소를 확인하고, 지도앱을 켜서 집에서 그 장소까지 이동 시간을 검색하고, “도착 여유 20분 잡고, 준비 시간 40분 잡으면 몇 시에 나가야 하지?”를 다시 계산해야 했습니다.

미팅이 하나면 그나마 괜찮은데, 외근이 두 개 이상이면 더 복잡해졌습니다. 집에서 첫 번째 미팅 장소까지, 첫 번째 미팅이 끝나고 두 번째 장소까지, 마지막 일정이 끝나고 다시 집이나 회사로 돌아오는 경로까지 따로 봐야 했습니다.

결국 하고 싶었던 건 단순했습니다.

“아침에 메시지 하나를 열면 오늘은 몇 시에 준비를 시작하고, 몇 시에 집에서 나가면 되는지 먼저 보이게 하자.”

다시 말해, 캘린더와 지도앱을 왔다 갔다 하며 머릿속으로 계산하는 일을 AI가 대신하게 만들고 싶었습니다.

🛠️ 사용한 도구

• Claude Code: 터미널에서 실제 코드를 만들고 수정하는 역할

• GPT: 내가 원하는 기능을 Claude Code가 잘 이해하도록 요청을 구체화하고, 작업 단계를 나누는 역할

• Google 캘린더: 개인 일정과 회사 일정 조회

• 텔레그램 봇: 브리핑과 출발 알림을 받는 채널

• 카카오 지도/길찾기: 장소 좌표 변환과 이동 시간 계산

• GitHub private repo: 작업 기록과 버전 관리

이번 프로젝트에서 저는 GPT와 Claude Code를 나눠서 사용했습니다. GPT에게는 “이걸 어떻게 요청해야 Claude Code가 삽질하지 않을까?”를 계속 물었고, Claude Code에게는 그 정리된 요청을 넣어 실제 구현을 맡겼습니다.

이 방식이 꽤 도움이 됐습니다. 내가 머릿속으로 대충 말한 요구사항을 GPT가 더 명확한 작업 지시로 바꿔주고, Claude Code는 그 지시를 바탕으로 파일을 수정하고 테스트를 돌렸습니다.

다만 이 방식 때문에 시간이 더 걸린 면도 있었습니다. GPT와 대화하면서 “아, 이것도 고려해야겠네”, “이 경우는 위험하겠네”, “이 기능은 지금 넣으면 안 되겠네” 같은 것들이 계속 보였고, 그만큼 기능을 더 잘게 쪼개고 안전하게 만들게 됐습니다.

🔧 작업 과정

1. 캘린더부터 연결하기

처음부터 거창한 비서를 만든 것은 아니었습니다. 먼저 Google 캘린더를 읽어오는 것부터 시작했습니다.

개인 캘린더와 회사 캘린더를 연결했는데, 회사 캘린더는 여러 사람의 일정이 섞여 있는 점이 문제였습니다. 그래서 회사 캘린더에서는 내가 봐야 하는 일정만 골라내는 필터를 만들었습니다.

중요했던 건 회사 계정은 읽기 전용으로만 접근하도록 한 점입니다. 실수로 회사 일정을 수정하거나 삭제하면 안 되기 때문에, 처음부터 안전장치를 두고 갔습니다.

이때부터 작업 원칙이 생겼습니다.

“기능을 만들기 전에, 먼저 어떤 파일을 어떻게 바꿀지 설명하게 하자.”

바로 구현시키는 대신, Claude Code에게 먼저 설계를 설명하게 했습니다. 어떤 파일을 수정할지, 이번 작업에서 무엇을 하고 무엇을 하지 않을지, 민감한 파일은 건드리지 않을지 확인한 뒤에 구현을 시작했습니다.

2. 텔레그램으로 받아보기

캘린더를 읽어온 다음에는 그 결과를 어디서 받을지가 필요했습니다. 저는 매일 쓰는 텔레그램을 선택했습니다.

개인 캘린더와 회사 캘린더를 합쳐서 텔레그램으로 “오늘 일정 브리핑”이 오는 것부터 만들었습니다. 아직 이동 계산은 없었지만, 이때 처음으로 “아, 이게 진짜 비서처럼 보이기 시작한다”는 느낌이 들었습니다.

막연히 코드 속에 있던 정보가 실제 메시지로 날아오니까 프로젝트가 손에 잡히기 시작했습니다.

3. 핵심 기능: 출발 시각을 거꾸로 계산하기

이 프로젝트의 핵심은 “일정 시간에서 거꾸로 계산하기”였습니다.

예를 들어 14:00에 미팅이 있다면, 단순히 14:00이라는 일정만 알려주는 게 아니라,

• 미팅 시작 20분 전에는 도착해야 하고

• 이동 시간이 1시간 20분 걸리면

• 집에서는 몇 시에 나가야 하고

• 준비 시간 40분까지 고려하면

• 몇 시부터 준비를 시작해야 하는지

를 계산해야 했습니다.

이 과정에서 장소를 좌표로 바꾸고, 그 좌표를 바탕으로 이동 시간을 계산하고, 일정 시작 시간에서 거꾸로 출발 시간을 역산하는 구조를 만들었습니다.

제가 원했던 건 단순히 “일정 요약”이 아니라 “늦지 않게 움직이기 위한 출발 의사결정”이었습니다.

4. 출발 시간대의 교통을 반영하기

처음 계산에서 한 가지 중요한 문제가 있었습니다.

브리핑을 밤에 만든다고 해서 밤 교통 기준으로 다음 날 아침 출발 시간을 계산하면 안 됩니다. 아침 출근 시간대와 밤 시간대는 이동 시간이 다르기 때문입니다.

그래서 “브리핑을 만드는 시점”이 아니라 “실제로 출발해야 하는 시간대”를 기준으로 이동 시간을 계산하도록 방향을 잡았습니다.

이 부분은 생각보다 중요했습니다. 단순히 지도 API를 붙이는 것과, 실제 사용자가 나가야 하는 시간에 맞춰 계산하는 것은 다른 문제였습니다.

5. 알림이 울리는 순간 다시 계산하기

브리핑은 전날 저녁이나 당일 아침에 미리 만들어질 수 있습니다. 그런데 실제 출발 시간이 되었을 때 교통 상황은 바뀔 수 있습니다.

그래서 출발 알림이 실제로 발송되는 순간, 그날의 이동 시간을 다시 계산하도록 만들었습니다.

예를 들어 원래는 08:20에 나가면 된다고 계산됐는데, 알림을 보낼 시점에 교통이 더 막히면 “기존 예상보다 길어졌습니다. 지금 바로 나가시는 편이 좋습니다”처럼 안내하게 했습니다.

이 기능을 만들고 나서야 단순한 일정 알림이 아니라 진짜 이동 비서에 가까워졌다는 생각이 들었습니다. 정해진 문구를 보내는 것이 아니라, 보내는 순간 한 번 더 확인해주는 구조이기 때문입니다.

6. 기차 일정은 집→역→목적지로 나누기

KTX나 SRT 일정은 일반 외근과 다릅니다.

그냥 집에서 목적지까지 자동차로 계산하면 안 되고,

• 집에서 출발역까지

• 출발역에서 기차 탑승

• 도착역에서 목적지까지

를 나눠서 봐야 합니다.

그래서 기차 일정은 별도의 “[기차 이동]” 섹션으로 분리했습니다. 집에서 몇 시에 나가야 출발역에 늦지 않는지, 기차 출발 시각을 기준으로 역산해서 안내하도록 만들었습니다.

이 부분도 처음엔 간단해 보였지만, 실제로는 꽤 많은 조건이 필요했습니다. 출발역, 도착역, 열차 출발 시간, 목적지 도착 가능 여부, 정보가 부족할 때 질문하는 방식까지 하나씩 나눠서 구현했습니다.

7. 자연어로 그때그때 조정하기

마지막에는 자연어 명령을 붙였습니다.

예를 들어 이런 식입니다.

“오늘 두 번째 이동은 택시로 봐줘.”

그러면 해당 날짜의 두 번째 이동 구간만 택시 기준으로 계산하게 했습니다.

더 나아가 한 문장에 두 가지 요청을 같이 말하는 것도 처리했습니다.

“내일 두 번째 이동은 택시로 보고, 알림은 20분 전에 줘.”

이 문장을 “두 번째 이동은 택시 기준으로 보기”와 “출발 알림은 20분 전으로 바꾸기”라는 두 가지 의도로 나눠서 처리하게 했습니다. 그리고 메시지도 두 번 보내지 않고 한 번에 묶어서 안내하도록 했습니다.

여기서 생각보다 섬세했던 부분이 있었습니다.

“오늘 마지막 일정 끝나고 회사로 복귀할게.”

이 문장에서 “끝나고”는 문장을 자르는 경계가 아니라 “일정이 끝난 뒤”라는 의미입니다. 그래서 자연어를 자를 때도 무작정 “고”나 “그리고”를 기준으로 자르면 안 됐습니다.

사람이 쉽게 쓰는 말을 코드가 자연스럽게 받아들이게 만드는 건 생각보다 많은 예외와 검증이 필요했습니다.

🧠 이번에 크게 느낀 점: 바이브 코딩도 거저먹기는 아니었다

사실 처음에는 바이브 코딩이라고 하면, 내가 생각한 걸 말하면 AI가 빠르게 구현해주고, 생각보다 쉽게 결과물이 나올 거라고 기대했습니다.

물론 예전보다 훨씬 쉬워진 건 맞습니다. 코드를 직접 하나하나 다 짜지 않아도 되고, 내가 모르는 구조도 AI가 제안해주고, 터미널에서 바로 수정하고 테스트까지 돌릴 수 있습니다.

그런데 이번에 해보니 “쉽다”와 “거저먹는다”는 완전히 다른 이야기였습니다.

제가 만들려던 기능은 겉으로 보기엔 단순했습니다.

“일정 보고, 이동 시간 계산해서, 몇 시에 나가면 되는지 알려줘.”

그런데 실제로 만들기 시작하니 생각할 게 계속 늘어났습니다.

• 회사 캘린더에서 어떤 일정만 가져올지

• 주소가 없으면 어떻게 할지

• 지도 API가 실패하면 어떻게 할지

• 전날 브리핑과 당일 교통이 다르면 어떻게 할지

• 외근이 여러 개면 동선을 어떻게 이어갈지

• 기차는 일반 이동과 어떻게 다르게 볼지

• 사용자가 자연어로 애매하게 말하면 자동 저장해도 되는지

• 충돌나는 요청은 어떻게 되물어야 하는지

• 민감한 파일이 커밋에 섞이지 않게 하려면 어떻게 할지

이런 것들을 하나씩 고려하다 보니, 생각보다 꽤 많은 시간이 들어갔습니다.

또 안전하게 만들기 위해 기능을 잘게 쪼개다 보니 더 오래 걸렸습니다. 하지만 반대로 그 덕분에 기존 기능이 망가질 걱정은 줄었습니다. 한 번에 크게 만들지 않고, 작은 단계로 나눠서 매번 테스트하고 커밋했기 때문입니다.

이번 경험을 통해 느낀 건 이겁니다.

바이브 코딩은 “생각 없이 빠르게 만드는 방식”이 아니라, 오히려 “내가 원하는 것을 더 잘게 정의하고, AI가 실수하지 않도록 계속 방향을 잡아주는 방식”에 가깝습니다.

AI가 코드를 대신 짜주더라도, 무엇을 만들지, 어디까지 할지, 어떤 경우를 막아야 할지, 언제 자동 저장하면 안 되는지는 결국 사람이 계속 판단해야 했습니다.

🔁 GPT와 Claude Code를 나눠 쓴 방식

이번 작업에서 저는 GPT와 Claude Code를 역할별로 나눠서 사용했습니다.

Claude Code는 실제 파일을 읽고, 코드를 수정하고, 테스트를 돌리는 역할을 했습니다. 반면 GPT는 제가 Claude Code에게 어떤 식으로 요청해야 할지 정리해주는 역할에 가까웠습니다.

예를 들면 이런 식입니다.

제가 GPT에게 말합니다.

“지금 Claude가 이런 보고를 했는데, 다음에 뭐라고 시키면 돼?”

그러면 GPT가 Claude Code에게 붙여넣을 수 있는 요청문을 정리해줍니다.

그 요청문에는 보통 이런 내용이 들어갔습니다.

• 이번에 할 범위

• 이번에 하지 않을 범위

• 수정해도 되는 파일

• 절대 건드리면 안 되는 파일

• 테스트해야 할 목록

• commit/push는 하지 말고 보고만 하라는 조건

• 사용자에게 보이는 문구에 개발자 용어를 노출하지 말라는 조건

이 방식이 좋았던 이유는 Claude Code가 길을 잃지 않았기 때문입니다. 막연히 “이 기능 만들어줘”라고 하기보다, “이 기능 중에서도 이번 단계는 여기까지만, 이건 하지 말고, 테스트는 이것까지”라고 구체적으로 시키니 훨씬 안정적으로 진행됐습니다.

물론 이 과정 때문에 시간이 더 걸리기도 했습니다. GPT와 이야기하다 보면 “아, 이것도 생각해야겠네” 하는 부분이 계속 나왔고, 그때마다 기능을 더 잘게 쪼개거나 예외 처리를 추가했습니다.

그래도 결과적으로는 그 시간이 낭비였다고 생각하지 않습니다. 오히려 그 과정 덕분에 프로젝트가 무너지지 않고 쌓였다고 느꼈습니다.

✅ 결과

Before vs After

솔직한 현재 상태

아직 매일 실제로 돌리는 운영 단계는 아닙니다.

현재는 핵심 로직을 탄탄히 쌓아둔 구축 단계입니다. 출발 역산, 실시간 재계산, 기차 구간, 자연어 조정, 복합 명령 처리 같은 주요 기능은 꽤 촘촘히 구현하고 테스트했습니다.

하지만 실제로 매일 쓰는 MVP가 되려면 아직 남은 작업이 있습니다.

• 상시 실행 환경 안정화

• 실제 일정으로 며칠 이상 테스트

• 예외 상황 정리

• 메시지 UX 다듬기

• 주변 사람에게 써보게 하기

• 앱 또는 서비스 형태로 빼내기

그리고 솔직히 말하면, 이 다음 단계도 제가 처음 생각했던 것보다 시간이 더 걸릴 것 같습니다. 개인용 MVP를 실제로 써보고, 주변 사람에게 테스트하고, 필요한 기능을 보완하고, 앱으로 분리하는 과정은 또 다른 프로젝트에 가깝겠다는 생각이 들었습니다.

즉, AI로 시작은 훨씬 쉬워졌지만, 실제로 쓸 만한 도구로 만드는 과정은 여전히 시간이 필요합니다.

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

1. “구현해”보다 “설계부터 설명해”가 훨씬 안전하다

이번 프로젝트에서 가장 많이 쓴 방식은 바로 이거였습니다.

“바로 구현하지 말고, 설계부터 설명해줘.”

어떤 파일을 바꿀지, 어떤 기능은 이번 범위에 넣고 어떤 기능은 제외할지, 테스트는 어떻게 할지 먼저 설명하게 했습니다. 이 과정에서 제 의도와 다른 방향으로 가는 걸 미리 막을 수 있었습니다.

2. 큰 기능은 반드시 작게 쪼개야 한다

자연어 명령 기능만 해도 한 번에 만든 게 아닙니다.

• 이동수단 하나 바꾸기

• 한 문장에 두 가지 의도 처리

• 일부만 처리 가능한 경우 안전하게 처리

• 세 가지 이상 의도 감지

• 확인 게이트는 다음 단계로 분리

이런 식으로 아주 잘게 나눴습니다.

처음에는 답답할 정도로 느리게 느껴졌지만, 지나고 보니 이게 가장 안전한 방식이었습니다. 한 번에 크게 만들면 어디서 문제가 생겼는지 찾기 어렵고, 되돌리기도 어렵습니다.

3. “이번에 하지 않을 것”을 적는 게 중요하다

AI에게 “무엇을 해줘”라고 말하는 것만큼 중요한 게 “무엇은 하지 마”라고 말하는 것이었습니다.

예를 들어 매번 이런 식으로 제한했습니다.

• 이 파일은 수정하지 마세요

• commit/push는 아직 하지 마세요

• .env나 인증 파일은 절대 포함하지 마세요

• DB 스키마는 바꾸지 마세요

• 사용자에게 개발자 용어를 보여주지 마세요

• 모호한 요청은 자동 저장하지 마세요

이런 제한을 계속 적어주니, 프로젝트가 커져도 사고가 날 가능성이 줄었습니다.

4. AI가 빠르게 만들수록, 사람은 더 많이 판단해야 한다

AI가 코드를 빠르게 만들 수 있으니, 오히려 사람이 판단해야 할 일이 더 많아졌습니다.

“이 기능을 지금 넣어도 되는지”
“자동 저장해도 안전한지”
“사용자에게 되묻는 게 맞는지”
“이번 단계에 넣지 말고 다음 단계로 미뤄야 하는지”

이런 판단은 AI가 대신해준다기보다, AI와 대화하면서 사람이 계속 결정해야 했습니다.

AI가 실행력을 올려주면, 사람의 기획과 판단의 중요성은 오히려 더 커지는 것 같습니다.

이렇게 하면 안 된다고 느낀 것

1. “다 만들어줘”라고 하면 위험하다

처음부터 “일정 비서 다 만들어줘”라고 했다면 아마 망가졌을 것 같습니다. 기능 범위가 너무 넓고, 예외도 많고, 실제 사용 상황도 복잡하기 때문입니다.

2. 확인 없이 자동 저장하게 만들면 위험하다

특히 자연어 명령은 조심해야 했습니다.

“알림은 20분 전에 주고, 10분 전에 줘”
“끝나고 집으로 가고, 회사로 복귀할게”

이런 문장은 사람이 봐도 충돌이 있습니다. 이걸 AI가 마음대로 판단해서 저장하면 안 됩니다. 그래서 모호하거나 충돌나는 요청은 자동으로 반영하지 않고 되묻게 만들었습니다.

3. 바이브 코딩을 너무 쉽게 보면 안 된다

AI가 코드를 대신 만들어준다고 해서 제품이 그냥 완성되는 건 아니었습니다.

오히려 제대로 만들려면 더 많이 쪼개고, 더 많이 확인하고, 더 자주 테스트해야 했습니다. 속도는 빨라졌지만, 책임이 사라진 건 아니었습니다.

🌍 다른 업무에 적용한다면

이 방식은 일정 비서뿐 아니라 다른 업무 자동화에도 그대로 적용할 수 있을 것 같습니다.

• 매주 반복하는 리포트 자동화

• 특정 조건이 되면 알려주는 텔레그램/슬랙 알림봇

• 영업 미팅 기록 정리 도구

• 고객 상담 내용을 자동으로 분류하는 도구

• 개인 데이터나 업무 로그를 모아 요약하는 도구

핵심은 똑같습니다.

큰 기능을 한 번에 만들지 말고, 설계를 먼저 받고, 작은 단계로 나눠서 각각 테스트하며 쌓는 것입니다.

🚀 앞으로의 계획

지금은 개인용 일정·이동 비서의 핵심 로직을 만든 단계입니다.

앞으로는 실제로 제 일정에 연결해서 며칠 이상 써보고, 메시지가 정말 도움이 되는지, 너무 길거나 헷갈리지는 않는지, 예외 상황에서 잘 버티는지 확인해보려고 합니다.

그 다음에는 주변에 외근이 많은 사람들에게도 써보게 하고 싶습니다. 대표, 영업 담당자, 강사, 컨설턴트처럼 외부 일정이 많은 사람들은 비슷한 불편함을 겪을 가능성이 높기 때문입니다.

장기적으로는 “외근자”를 위한 서비스 형태로 확장할 수도 있을 것 같습니다. 사용자가 자기 캘린더를 연결하면, “오늘 몇 시에 준비하고 몇 시에 나가야 하는지”를 자동으로 받아보는 방식입니다.

다만 이번 경험을 하고 나니, 서비스화도 생각보다 시간이 많이 걸릴 것 같습니다. 개인용으로 되는 것과 다른 사람이 안정적으로 쓰는 것은 또 다른 문제니까요. 그래서 당장 크게 벌리기보다는, 먼저 제 개인 MVP를 실제로 잘 쓰는 단계까지 가보려고 합니다.