소개
예약부터 텔레그램 알림까지 실제로 연결해봤어요
KTX 예매 에이전트를 이용하면서 겪은 연결 끊김 문제를 해결하기 위해, Aside가 예약을 진행하고 Claude Code로 만든 웹페이지를 경유해 텔레그램으로 알림을 보내는 구조를 개발했어요.
처음에는 수동으로 만든 예약을 Aside가 확인하고 알림을 보내는 부분부터 테스트했습니다. 이후에는 Aside가 직접 좌석을 선택하고 예약을 완료한 뒤 알림까지 보내는 실전 테스트로 범위를 넓혔어요.
그 결과, Aside의 직접 예약과 알림 웹페이지의 전송 완료를 확인했고, 텔레그램 실제 수신도 제가 확인했습니다. 로그인 문제는 Mac의 ‘암호’에 저장된 정보를 이용해 코레일 로그인까지 완료하는 단계로 이어졌어요.
단, 이번 테스트를 장기 반복이나 완전 무인 운영까지 검증한 것으로 보지는 않았습니다.
이런 분들께 도움돼요
예약 에이전트와 알림 서비스 사이의 연결에 어려움을 겪는 분
브라우저 에이전트와 Claude Code로 만든 도구를 함께 활용하고 싶은 분
결제는 직접 하면서 예약과 알림만 자동화하고 싶은 분
자동화의 경계부터 정했어요
목표는 다음과 같았어요.
예약 실행 → 예약내역 확인 → 텔레그램 알림 → 직접 결제
자동화는 예약과 알림까지만 담당합니다. 결제와 발권은 제가 직접 하는 원칙을 유지했어요.
연결 끊김의 정확한 원인이나 장기적인 재발 방지 효과는 아직 확인하지 못했습니다. 그래서 이번 글은 “문제를 완전히 해결했다”는 성과보다, 연결 구조를 바꾸고 실제 동작을 검증한 과정에 초점을 맞췄어요.
예약 작업과 알림 전달 사이의 연결 문제를 표현한 설명용 일러스트예요.
진행 방법
사용한 도구
Aside: 코레일 화면 조작, 좌석 선택과 예약, 예약내역 확인, 알림 웹페이지 조작, 실행 루틴 등록
Claude Code: 텔레그램 전달용 웹페이지 제작
코레일 웹사이트: 열차 조회와 예약, 좌석·예약상태·결제기한 확인
텔레그램: 예약 후 결제 안내 수신
Mac 암호: 저장된 로그인 정보를 이용한 코레일 로그인
Mac mini: Aside와 로컬 알림 서비스를 운영하는 환경
1. 누가 예약하고 누가 알림을 보내는지 명확히 했어요
초기 대화에서는 Aside가 Claude Code의 예약 완료를 기다렸다가 알림만 보내는 것으로 역할을 잘못 이해했어요.
제가 원한 것은 Aside가 예약부터 결과 확인, 알림 전송까지 이어서 수행하는 것이었습니다. 다음 요청으로 역할을 바로잡았어요.
아니야. 너가 예약을 한 후 예약정보 알림 페이지에서 알림메시지를 전달하는 거야정리한 목표 구조는 다음과 같습니다.
Aside가 코레일에서 예약 진행핵심은 예약 버튼을 누른 것과 예약이 완료된 것을 구분하는 것이었어요. 성공 알림은 실제 예약내역을 확인한 뒤에만 보내도록 했습니다.
예약 실행, 결과 확인, 웹페이지를 경유한 알림 전달의 역할 분담을 표현했어요. 실제 제품 화면은 아닙니다.
2. 처음에는 수동 예약으로 알림 구간부터 검증했어요
첫 테스트에서는 로그인과 날짜 선택 문제가 있었습니다. Aside가 읽은 달력에서는 목표 날짜를 선택할 수 없는 것으로 보여 자동 예약을 제출하지 않았어요.
그런데 저는 같은 날짜의 표를 수동으로 예약할 수 있었어요. 그래서 먼저 제가 예약을 만들고, Aside가 예약내역을 확인하도록 했습니다.
아니 내가 수동으로 12월3일 예매가 가능해. 내가 예약을 해볼테니 너가 검토해줘이 테스트에서 확인한 예약은 12월 3일 나주→행신 KTX 422, 13:59–16:27, 특실 3호차 5A였어요.
Aside가 예약을 확인한 뒤 알림 웹페이지에서 전송을 실행했고, 화면에 ‘전송 완료’가 표시됐습니다.
이 단계의 예약 주체는 저였어요. 따라서 예약 확인과 알림 전달 구간을 검증한 결과이지, Aside의 직접 예약 성공으로 기록하지 않았습니다.
3. 일회성 실전 테스트로 직접 예약까지 확인했어요
다음에는 아직 확인하지 못한 부분을 실제로 테스트하기로 했어요.
사용한 테스트 요청 전문은 다음과 같습니다.
Aside가 직접 예약을 완료하는 전체 흐름10월 4일 밤 9시 30분에 실행되는 일회성 테스트를 등록했습니다. 다만 실행 시 코레일이 로그아웃 상태였고, 당시 Aside Vault에는 사용할 수 있는 코레일 로그인 항목이 없어 제가 직접 로그인해야 했어요.
로그인 후 Aside는 다음 순서로 진행했습니다.
발권된 승차권과 미결제 예약을 확인해 중복 예약 여부를 점검했어요.
12월 4일 나주→행신 열차를 조회했어요.
목표 시각인 13:59–16:27의 KTX 422 특실을 선택했어요.
좌석 우선순위의 첫 번째인 4A를 선택했어요.
예약을 제출하고 예약 상세 화면에서 결과를 확인했어요.
직접 예약이 완료된 내용은 다음과 같아요.
출발일: 2026년 12월 4일 금요일
열차: KTX 422
구간: 나주 13:59 → 행신 16:27
좌석: 특실 4호차 4A
상태: 미결제 예약
당시 표시된 결제기한: 2026년 10월 4일 22:13
이 예약은 Aside가 직접 좌석 선택과 예약 제출을 수행한 결과입니다. 결제와 발권은 하지 않았어요.
4. 웹페이지 전송과 실제 수신을 따로 확인했어요
예약 확인 후 Aside가 알림 웹페이지에 메시지를 입력하고 ‘텔레그램으로 보내기’를 눌렀습니다.
메시지에는 출발일, 열차번호, 구간과 시각, 특실·호차·좌석, 미결제 상태, 결제기한을 포함했어요. 테스트 메시지임을 구분하는 표시도 넣었습니다.
검증은 두 단계로 나눴어요.
웹페이지 전송 완료: Aside가 화면에서 직접 확인
텔레그램 실제 수신: 제가 대화방에서 확인하고 도착했다고 응답
앞선 테스트에서 남아 있던 실제 수신 확인까지 이번에는 진행한 셈이에요.
5. 로그인 문제는 Mac 암호 활용으로 이어졌어요
실전 테스트에서는 직접 로그인이 필요했기 때문에, 매번 같은 개입을 반복하지 않을 방법도 살펴봤습니다.
Aside Vault에 CSV로 로그인 정보를 가져오는 과정에서는 웹사이트 주소 칸에 다른 입력 내용이 섞인 항목이 만들어졌어요. 이를 통해 항목이 목록에 생기는 것만으로 저장 성공을 판단하면 안 된다는 점을 확인했습니다.
주소, 사용자 이름, 비밀번호가 각각 올바른 칸에 저장됐는지 확인해야 해요.
이후 저는 Mac의 ‘암호’에 저장된 정보를 이용해 코레일 예약 페이지 로그인까지 완료했습니다. 이 결과는 제 확인을 기반으로 기록합니다.
다만 Mac 암호를 이용한 로그인이 예약 루틴 실행 중에도 사용자 개입 없이 작동하는지는 별도로 검증해야 합니다. 현재 로그인 성공을 장기 무인 로그인 검증과 동일하게 보지는 않았어요.
6. 반복 일정은 출발일이 아니라 표 오픈일 기준으로 잡았어요
반복 예약 대상은 다음과 같아요.
매주 월요일: 행신→나주, 10:10–12:46
매주 목요일: 나주→행신, 13:59–16:27
제가 전달한 운영 기준은 출발일 두 달 전 오전 7시에 표가 열리면, 그날 오전 8시에 예약한다는 것이었어요. 이는 제가 지정한 기준이며, 코레일의 모든 열차에 적용되는 공식 판매 규칙을 별도로 검증한 것은 아닙니다.
작업 기록에서는 첫 두 건의 루틴 등록을 확인했어요.
12월 7일 출발분: 10월 7일 오전 8시 실행
12월 10일 출발분: 10월 10일 오전 8시 실행
각 실행에서 다음 주 같은 노선의 일정을 이어서 등록하도록 구성했습니다. 이번 금요일 테스트는 일회성이므로 기존 월·목 반복 일정과는 분리했습니다.
결과와 배운 점
처음의 미검증 목록을 업데이트했어요
Aside의 직접 예약: 확인했어요. 12월 4일 표를 직접 예약했습니다.
텔레그램 실제 수신: 제가 도착을 확인했어요.
다음 주 루틴의 장기 반복: 아직 검증하지 못했어요.
연결 끊김 재발 여부: 이번 예약·전송 과정에서는 관찰되지 않았지만, 장기적인 재발 방지는 미검증입니다.
완전 무인 운영: 이번 실행에는 직접 로그인이 필요했으므로 검증 완료로 볼 수 없어요.
Mac 암호를 이용한 로그인: 로그인 완료를 확인했지만, 예약 루틴에서의 무개입 동작은 추가 테스트가 필요합니다.
시행착오: 한 번의 성공과 지속 가능한 운영은 달랐어요
이번 작업에서는 예약과 알림이 실제로 이어지는 것을 확인했어요. 하지만 계속 운영하려면 로그인 유지, 실행 권한, 컴퓨터와 서비스 상태까지 함께 점검해야 합니다.
기존 반복 루틴은 당시 기록에서 guard 권한으로 등록됐고, 권한을 높이려는 요청은 실행 환경에서 거부됐어요. 루틴이 등록됐다는 사실만으로 승인 없는 실행을 보장할 수는 없었습니다.
Mac mini가 잠들거나 Aside 데몬과 로컬 알림 서비스가 종료되는 상황도 별도 운영 과제예요.
다음에도 활용할 수 있는 교훈
역할을 먼저 정하기
누가 예약하고, 누가 결과를 확인하며, 누가 알림을 보내는지 명확해야 해요.검증 단계를 나누기
예약 제출, 예약내역 확인, 웹페이지 전송, 실제 수신은 서로 다른 확인 단계입니다.막힌 구간부터 분리해 테스트하기
수동 예약으로 알림 구간부터 검증한 뒤 직접 예약으로 범위를 넓혔어요.로그인 항목의 존재와 정확성을 구분하기
저장소 목록 에 항목이 있어도 주소와 자격증명이 올바르게 분리돼 있는지 확인해야 합니다.자동화의 경계를 유지하기
예약과 알림은 자동화하되 결제·발권은 직접 하는 원칙을 유지했어요.
자동화가 맡는 예약·확인·알림과, 사람이 맡는 결제의 경계를 표현한 일러스트예요.
앞으로 확인할 부분
다음 테스트에서는 Mac 암호를 이용한 로그인부터 예약·알림까지 사용자 개입 없이 이어지는지 확인하려고 해요.
이후에는 다음 주 루틴의 실제 등록과 실행, 로그인 만료·매진·서비스 중단 때의 처리, 연결 끊김 재발 여부를 지속적으로 관찰할 필요가 있습니다.
이번에 얻은 결과는 “직접 예약과 알림 전달이 실제로 작동했다”는 것이에요. 다음 목표는 이를 한 번의 성공이 아니라, 실패 지점도 확인할 수 있는 반복 운영으로 발전시키는 것입니다.
도움 받은 글 (옵션)
작업에 사용한 「Mac mini Aside 인수인계: KTX 주간 예약 자동화」 문서
Aside Password Manager 안내 (https://docs.aside.com/help/password-manager)
Aside 비밀번호 자동입력 설정 안내 (https://docs.aside.com/help/passwords)
지피터스 사례글 작성 스킬: 지아코모(안재흥) 제작, 닿님의 write-post 기반
