자동 알림 하나도 생각보다 많은 것이 필요했다
Santiago Brain을 만들면서 꼭 해보고 싶었던 기능이 있었다.
아침이 되면 내가 먼저 앱을 열지 않아도, 오늘과 내일 일정을 문자로 받아보는 것.
그리고 오후에는 한 번 더 일정을 점검해서, 놓친 일이 없는지 알려주는 기능도 만들고 싶었다.
처음에는 아주 간단하게 생각했다.
Google Calendar와 Google Tasks에서 일정을 읽고,
그 내용을 문자로 보내면 끝이라고 생각했다.
그런데 실제로 만들어보니,
자동 문자 하나가 제대로 오게 만드는 데 생각보다 많은 요소가 필요했다.
처음에는 ChatGPT 예약 알림부터 시작했다
나는 먼저 ChatGPT의 예약 기능으로 아침 일정 알림을 받아봤다.
아침 특정 시간이 되면 일정 브리핑이 오도록 설정했다.
이 기능은 비교적 잘 작동했다.
문제는 내가 원한 것이 단순한 ChatGPT 알림이 아니라는 점이었다.
나는 Santiago Brain이 직접
오늘 일정,
내일 일정,
중요한 할 일,
마감이 지난 일
을 정리해서 휴대폰 문자로 보내주길 원했다.
그래서 Santiago Brain 안에 별도의 문자 발송 기능을 만들기 시작했다.
문자 서비스는 별도의 외부 서비스를 사용해야 했다
Santiago Brain 자체가 휴대폰 문자를 직접 보내는 것은 아니다.
문자를 보내려면 문자 발송 서비스를 연결해야 한다.
나는 SOLAPI 같은 문자 발송 API 서비스를 연결하는 방식으로 진행했다.
여기서 처음 알게 된 것이 있다.
문자 발송은 단순히 전화번호만 넣으면 되는 것이 아니었다.
발신번호 등록이 필요했고,
API 키와 인증정보도 필요했고,
서비스 쪽에서 발신번호 승인을 받아야 했다.
즉,
앱 → 문자 서비스 → 이동통신망 → 내 휴대폰
이라는 여러 단계를 거쳐야 했다.
테스트 문자가 왔을 때는 거의 다 된 줄 알았다
처음 테스트 문자가 휴대폰에 도착했을 때는 상당히 기뻤다.
“이제 아침마다 일정 문자만 보내면 되겠구나.”
그런데 테스트 문자가 한 번 오는 것과,
매일 정해진 시간에 정확한 내용을 보내는 것은 전혀 다른 문제였다.
테스트 발송은 사람이 버튼을 눌러 보내면 된다.
자동 발송은 그렇지 않다.
정해진 시간이 되면 서버가 자동으로 실행돼야 하고,
Google 일정을 읽어야 하고,
내용을 정리해야 하고,
문자 API를 호출해야 한다.
중간에 하나라도 실패하면 문자는 오지 않는다.
오전 일정 브리핑과 오후 재점검을 만들었다
내가 원한 기본 구조는 단순했다.
아침에는 오늘과 내일 일정을 알려준다.
오후에는 남아 있는 일정과 할 일을 다시 한번 점검한다.
그래서 이런 흐름을 생각했다.
오전 브리핑
Google Calendar 확인
→ Google Tasks 확인
→ 오늘과 내일 일정 정리
→ 문자 작성
→ 휴대폰 발송
오후 브리핑
오늘 남은 일정 확인
→ 미완료 할 일 확인
→ 놓친 일이 있는지 정리
→ 문자 발송
이 구조만 보면 단순하다.
하지만 실제로는 여러 문제가 생겼다.
“문자는 왔는데 내용이 틀리는 문제”
가장 당황스러운 오류 중 하나는,
문자는 정상적으로 왔는데 내용이 틀리는 경우였다.
예를 들어 오늘 일정이 하나 있고,
내일 일정도 하나 있었다.
그런데 문자에는 오늘 일정 하나만 들어 있었다.
문자 제목은 분명히
“오늘과 내일 일정”
이라고 되어 있었다.
즉, 문자 발송은 성공했다.
문제는 그 전에 일정을 정리하는 과정에서 발생한 것이다.
이런 경우에는
오늘만 조회하고 있는지,
내일 날짜 범위를 제대로 계산했는지,
Google Calendar와 Google Tasks를 모두 읽었는지,
내일 일정이 필터 과정에서 빠졌는지
하나씩 확인해야 했다.
이때 다시 느꼈다.
문자가 왔다고 해서 시스템 전체가 정상인 것은 아니다.
반대로 문자가 아예 안 오는 경우도 있었다
또 어떤 날은 ChatGPT 예약 알림은 정상적으로 왔는데,
Santiago Brain에서 보내야 할 문자는 오지 않았다.
이 경우는 문제가 완전히 달랐다.
일정 조회가 실패한 것인지,
문자 발송 API가 호출되지 않은 것인지,
API 호출은 됐는데 거부된 것인지,
인증정보가 잘못된 것인지,
서버에서 외부 문자 서비스로 나가는 연결이 막힌 것인지
확인해야 했다.
즉,
“문자 안 옴”이라는 한 가지 현상 뒤에 여러 원인이 숨어 있었다.
IP 제한 문제도 생각해야 했다
문자 API 같은 외부 서비스를 연결할 때는 보안도 중요했다.
API 키를 아무 곳에서나 사용할 수 있게 두면 위험하다.
그래서 서비스에 따라 허용 IP를 제한하거나, 인증 조건을 두기도 한다.
이런 보안 설정은 필요하지만,
서버 환경이 바뀌거나 외부 연결 방식이 달라지면 정상 발송까지 막을 수 있다.
그래서 보안을 약하게 만들지 않으면서,
정상적인 서버 발송은 허용해야 했다.
이 부분은 기술적으로 꽤 까다로웠다.
예약 작업은 실행됐는데 문자 발송이 안 될 수도 있다
처음에는 시간이 지나도 문자가 안 오면
“예약 작업이 실행되지 않았구나”
라고 생각했다.
하지만 실제로는 예약 작업이 실행됐는데,
그 안에서 문자 발송 단계만 실패할 수도 있다.
예를 들어,
오후 3시 예약 작업 실행 성공
→ 일정 조회 성공
→ 문자 내용 생성 성공
→ SMS API 호출 실패
이렇게 될 수도 있다.
그래서 자동화 시스템에서는 단순히 “실행 여부”만 보면 안 됐다.
각 단계가 어디까지 성공했는지를 확인할 수 있어야 했다.
발송 이력과 오류 로그가 중요해졌다
이런 문제를 겪다 보니,
“문자 보냈다”라는 표시만으로는 부족하다는 것을 알게 됐다.
확인해야 할 것은 더 많았다.
언제 브리핑을 만들었는지,
몇 개의 일정을 읽었는지,
문자 발송을 실제로 요청했는지,
문자 서비스가 어떤 응답을 했는지,
실패했다면 이유가 무엇인지.
그래서 앞으로는 이런 자동화 기능일수록
로그와 발송 이력을 확인할 수 있어야 한다고 생각하게 됐다.
자동화가 잘 될 때는 로그를 볼 일이 없다.
하지만 문제가 생기면 로그가 없으면 원인을 찾기가 매우 어렵다.
문자 비용도 생각해야 했다
문자는 한 통 한 통 비용이 발생한다.
개인용 앱이라고 해도,
불필요하게 자주 보내면 비용이 쌓일 수 있다.
그래서 무조건 많은 알림을 보내는 것이 좋은 것은 아니다.
예를 들어,
아침 한 번,
오후 한 번
정도로 제한하는 것이 내 사용 방식에는 더 맞았다.
또 일정이 없는데도 매번 긴 문자를 보낼 필요는 없다.
필요한 정보만 짧게 보내는 것이 좋다.
이 역시 Santiago Brain을 만들면서 계속 중요하게 생각한 원칙과 연결된다.
필요한 기능만 만들고, 반복 비용은 줄인다.
중복 문자도 막아야 했다
예약 작업을 만들다 보면 같은 작업이 두 번 실행될 가능성도 생각해야 한다.
예를 들어 서버가 재시작되거나,
예약 작업이 재시도되거나,
사용자가 수동으로 다시 실행할 수도 있다.
이때 같은 아침 브리핑이 두 번 오면 불편하다.
그래서 날짜와 브리핑 종류를 기준으로
“오늘 이미 보냈는가”
를 확인하는 방식도 필요하다.
자동화는 성공하는 것만큼이나
중복 실행을 막는 것도 중요했다.
알림이 많다고 좋은 AI 비서는 아니다
처음에는 AI 비서라면 많은 것을 알려줘야 한다고 생각했다.
하지만 실제로 사용하다 보면 알림이 너무 많으면 오히려 무시하게 된다.
그래서 Santiago Brain에서는
정말 필요한 시간에,
필요한 정보만,
짧게 보내는 방향이 더 맞다고 생각했다.
아침에는 하루 계획을 잡는 데 필요한 내용.
오후에는 놓친 일을 확인하는 데 필요한 내용.
그 이상은 앱을 열었을 때 확인하면 된다.
자동화의 목적은 ‘먼저 챙겨주는 것’이다
내가 문자 기능을 만들고 싶었던 진짜 이유는
문자 자체가 아니었다.
앱을 내가 매번 열지 않아도,
Santiago Brain이 먼저 나를 찾아오는 경험을 만들고 싶었다.
아침에
“오늘 일정은 이것입니다.”
오후에
“아직 남은 일이 있습니다.”
이렇게 먼저 알려주는 것.
이것이 내가 생각하는 개인 AI 비서에 더 가까웠다.
만들면서 느낀 점
자동 문자 기능은 겉으로 보면 아주 작은 기능이다.
하지만 그 뒤에는
일정 조회,
날짜 계산,
외부 API,
인증,
서버 예약 작업,
오류 처리,
중복 방지,
비용 관리,
보안
이 모두 연결되어 있었다.
그래서 이번에도 같은 결론에 도달했다.
자동화는 기능을 만드는 것보다 믿을 수 있게 만드는 것이 더 어렵다.
Santiago Brain의 문자 기능도 아직 계속 다듬고 있다.
하지만 한 단계씩 문제를 해결하면서,
앱을 열어야만 일정을 볼 수 있는 시스템에서
내가 잊기 전에 먼저 알려주는 시스템으로 조금씩 바뀌고 있다.
다음 글 예고
8편 — Supabase 데이터베이스에서 가장 어려웠던 부분
다음 글에서는 화면에서는 잘 보이지 않지만 Santiago Brain의 거의 모든 기능을 떠받치고 있는 데이터베이스 이야기를 해보려고 한다.
목표와 프로젝트를 어떻게 연결했는지,
같은 할 일이 중복 저장되는 문제,
삭제했을 때 연결 데이터가 어떻게 되는지,
DB 구조를 바꾸면서 기존 데이터와 충돌했던 문제,
그리고 왜 데이터베이스 수정은 화면 수정보다 훨씬 조심해야 했는지를 실제 경험 중심으로 정리해보겠다.