카드 결제하면 아이폰 단축어로 서버까지 자동으로 배포됩니다

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

아이폰 단축어로 카드 결제 문자를 서버에 자동 전송해 장부에 기록하고, 이를 처리하는 Cloudflare 서버를 검증·배포하는 과정을 보여준다.

📌 핵심 요점

1. 상시 켜두는 맥미니를 주 경로에서 빼고, 아이폰이 결제 문자를 서버로 직접 보내도록 단순화했다. 맥미니 수집기는 예비 경로와 과거 거래 이관용으로 남겼다.
2. 아이폰 개인용 자동화가 ‘KB 국민’ 포함 메시지를 감지하면 단축어가 즉시 실행된다. 단축어는 문자 내용을 POST 요청으로 보내고 서버 응답을 알림으로 표시한다.
3. 수신 워커와 화면 워커는 같은 D1 데이터베이스를 쓰지만 인증과 역할을 나눈다. 수신 토큰으로는 장부를 조회하거나 삭제할 수 없도록 설계했다.
4. Claude Haiku는 계정 과목을 제안하고 사용자가 확정한다. 확정한 가게에는 규칙이 생겨 다음 거래부터 AI 호출을 줄이며, AI에 보내는 정보와 월 사용량도 제한한다.
5. 운영의 핵심은 중복 방지와 예외 처리다. 실제 체크카드 문자에서 드러난 누락을 수정하고, 읽지 못한 카드 문자는 보관하며, 취소는 원거래가 확실할 때만 연결한다.

🧩 배경과 문제 정의

카드 결제 문자를 사람이 읽고 장부에 옮기는 과정을 자동화하려는 개인 개발 사례다. 처음에는 상시 가동하는 맥미니가 메시지 데이터를 읽어 서버에 보내도록 만들었지만, 문자 전달·절전·권한·프로그램 중단 등 관리할 지점이 많았다. ‘단순하게 가자’는 결정에 따라 아이폰 단축어가 서버로 직접 보내는 구조로 바꿨다.

최종 구조는 아이폰 메시지 자동화, 문자 수신 워커, 장부 화면 워커, 공용 D1 데이터베이스로 구성된다. AI는 계정 과목 제안을 보조하며 확정은 사용자가 맡는다. 영상은 자동 전송 설정뿐 아니라 인증, 중복 제거, 실제 문자 예외, 취소 연결, 서버 배포와 사후 확인까지 다룬다.

🕒 시간순 섹션별 상세정리

1. 결제 직후 도착한 알림과 설계 전환

• 카드 결제 문자 뒤에 ‘created’ 알림이 도착한다. 발표자는 아무것도 누르지 않았고, 결제가 장부에 자동으로 한 줄 기록됐다는 의미라고 보여준다. [00:18]
• 처음에는 맥미니를 계속 켜두는 구조였지만, 단순하게 만들자는 결정으로 아이폰이 서버에 직접 보내도록 바꿨다. [00:55]

2. 문자에서 장부까지 이어지는 전체 구조

• ‘KB 국민’이 포함된 메시지를 받으면 아이폰 단축어가 실행되어 문자 내용을 서버 주소로 보낸다. Cloudflare 워커가 처리하므로 개인 컴퓨터를 켜둘 필요가 없다. [01:41]
• 수신 워커는 날짜·금액·가게 이름·카드 끝자리를 추출해 D1에 기록한다. 화면 워커는 같은 데이터베이스를 사용해 장부를 보여준다. [02:08]
• Claude Haiku는 가게 이름을 보고 계정 과목을 제안하며, 최종 확정은 사용자가 한다. [02:23]

3. 맥미니 경로의 한계와 개발 과정

• 기존 수집기는 메시지 데이터 파일을 30초마다 읽었다. 문자 전달 중단, 맥미니 절전, 권한 해제, 프로그램 중단이 장부 누락으로 이어질 수 있었다. [03:01]
• 직접 전송 구조에서는 주요 점검 대상을 아이폰 자동화와 인터넷 연결로 줄였다. 기존 맥미니 경로는 예비로 남기고 과거 결제 72건을 옮기는 데 사용했다. [03:20]
• 초기 개발에는 이틀이 걸렸고, ChatGPT로 기획을 정리하고 Claude로 코드를 작성했다. 첫날에는 합성 문자만 사용했으며 이 대목에서는 자동 테스트 35개를 언급한다. [03:36]

4. 개인·사업자 장부와 지출 화면

• 카드 끝 네 자리로 개인·사업자 장부를 구분한다. 월 대시보드에는 총지출, 예산 사용량, 계정 과목별 지출, 일별 추이와 최근 거래가 나온다. [04:20]
• 거래 목록에서는 월과 미분류 거래를 골라볼 수 있다. 통계는 3개월·6개월·1년 단위로 지출과 건수를 이전 기간과 비교하고, 주요 가게와 요일·시간대 패턴을 보여준다. [05:20]
• 수입 표시색은 색각 이상 검사에서 코랄색과 구분이 어려웠던 초록색 대신 파란색으로 바꿨다. [05:36]

5. AI 제안과 사용자 확정으로 쌓는 규칙

• 개인·사업자 장부는 계정 과목을 따로 사용한다. AI에는 가게 이름, 구간으로 바꾼 금액대, 개인·사업자 구분, 과목 목록만 보내며 카드 번호·문자 원문·날짜는 보내지 않는다. [06:25]
• 사용자가 제안을 확정하면 가게 규칙이 생긴다. 같은 가게의 다음 거래는 해당 규칙을 사용하므로 AI 호출을 줄일 수 있다. [06:41]
• 호출당 비용은 약 0.09원으로 보여준다. 월 500회 또는 1달러를 넘으면 추가 AI 호출을 차단하도록 설정했다. [06:54]

6. 단축어의 전송 동작과 응답 알림

• 같은 Apple 계정의 맥과 아이폰은 iCloud로 단축어를 공유한다. 시연한 단축어는 다섯 동작으로 구성되며, 핵심은 URL 콘텐츠 가져오기와 알림 표시다. [07:34]
• 수신 워커 주소로 POST 요청을 보내고 Authorization에 Bearer 토큰을 넣는다. User-Agent도 지정하지만, 실제 인증을 담당하는 것은 토큰이라고 구분한다. [08:42]
• JSON 본문에는 자동화에서 받은 문자 내용을 넣는다. 알림 동작은 서버 응답을 그대로 표시하며, 처음 등장한 ‘created’도 이 결과다. [09:04]

7. 토큰을 옮기고 보관하는 방식

• 토큰 원문은 맥북의 접근 권한을 제한한 파일에서 클립보드로 복사해 단축어에 붙여 넣는다. 아이폰에서는 유니버설 클립보드를 활용할 수 있다고 보여준다. [09:34]
• 입력 후에는 빈 문자열로 클립보드를 덮어쓴다. 서버에는 토큰 원문 대신 해시를 저장한다고 보여준다. [09:51]

8. 아이폰 개인용 자동화 설정

• 단축어 자체는 동기화되지만 메시지 수신을 조건으로 하는 개인용 자동화는 기기별로 만들어야 한다. 실제 사용하는 자동화는 아이폰에만 둔다. [10:22]
• 메시지 포함 내용에 ‘KB 국민’을 넣고 ‘즉시 실행’을 선택한다. 보낸 사람 조건과 함께 쓰면 불안정하다는 사용자 보고를 이유로 문구 조건만 사용했으며, 즉시 실행 선택지는 iOS 17부터 제공된다고 보여준다. [11:08]
• 실행할 단축어를 지정하면 받은 메시지가 입력으로 전달된다. 맥에도 같은 자동화를 저장하면 중복 전송될 수 있어 시연에서는 저장하지 않는다. [11:33]

9. 비결제 문자와 인증 실패, 중복 요청 시험

• ‘KB 국민’ 조건은 은행 문자까지 잡기 때문에 서버에서 구분해야 한다. 합성 인증번호 문자를 보내자 결제 문자가 아니라는 응답이 돌아오고 장부에는 기록되지 않는다. [12:15]
• 토큰을 제거한 요청에는 인증 실패 응답이 돌아온다. 발표자는 토큰이 없거나 틀리면 아무것도 저장하지 않는다고 보여준다. [12:26]
• 로컬 시험 서버에 합성 결제 문자를 보내 정상 생성 응답을 확인하고, 같은 문자를 다시 보내면 ‘already processed’가 반환되는 것을 확인한다. [12:43]

10. 워커 분리와 중복 방지의 원리

• 처음 고려했던 Cloudflare Access가 단축어의 수신 주소까지 막는 문제 때문에 수신 워커를 분리했다. 현재 화면 로그인은 앱이 직접 접속 코드를 확인한다. [13:13]
• 수신 토큰은 수신 기능에만 쓰이고 장부 조회·삭제에는 사용할 수 없다. 화면 워커는 로그인 쿠키를 확인하며, 접속 코드는 같은 곳에서 15분 동안 다섯 번 틀리면 일시 차단한다. [13:51]
• 문자 공백과 줄바꿈을 정규화한 지문을 고유 번호로 사용한다. 동일 문자 동시 10회 전송에서도 거래는 한 건만 생겼고, 같은 금액의 별도 결제는 문자 속 누적 금액 차이로 구분한다고 보여준다. [14:35]

11. 배포 전 검증부터 운영 상태 확인까지

• 촬영에서는 코드를 바꾸지 않고 재배포한다. 공용 규칙 15개·맥 수집기 163개·웹 137개로 총 315개 테스트가 통과했고, 타입 검사 후 D1 복구 지점을 확보한다. [15:33]
• 원격 마이그레이션은 기존 8단계가 이미 적용된 상태였다. 화면을 빌드한 뒤 두 워커를 배포하며, 화면 워커는 AI를 켜고 수신 워커는 가게 규칙만 사용하도록 설정한다. [17:04]
• 대시보드에서 도메인·비밀값·D1의 12개 테이블을 확인하고, 새로고침 후 장부 합계가 배포 전과 같은지 점검한다. 기존 월 5달러 요금제 안에서 운영될 것으로 예상하며 앱 요청량은 월 수천 건이라고 보여준다. [18:14]

12. 실사용 누락 수정과 취소 거래 연결

• 배포 다음 날 개인 체크카드가 허용 목록에 없어 누락됐고, 목록을 늘린 뒤에는 ‘KB 국민 체크’로 시작하는 실제 문자 형식을 처리하지 못했다. 실제 캡처를 확인해 규칙을 수정했다. [18:50]
• 카드별 장부 대응표를 관리하고, 읽지 못한 국민카드 문자는 보관해 규칙 수정 후 재처리하도록 바꿨다. 은행 문자는 보관하지 않으며, 놓친 두 거래는 다시 보내 기록했다. [19:16]
• 취소는 같은 카드의 선행 거래 중 180일 이내이며 취소액 이상인 거래를 후보로 삼는다. 원결제일의 후보와 가게·금액을 따져 확실할 때만 연결하며, 기존 취소 9건 중 7건을 연결하고 나머지는 보류했다. 원거래가 나중에 들어오면 자동으로 연결한다. [20:22]

13. 단순해진 전달 경로와 남은 서버의 책임

• ‘created’ 알림 뒤에는 토큰 확인, 중복 방지 지문, 사용자가 확정한 가게 규칙, 보수적인 취소 연결이 있다. 중간 컴퓨터를 빼도 필터링과 검증의 책임은 서버에 남는다. [20:59]
• 아이폰을 쓰고 결제 문자를 받으며 문자 형식을 확인할 수 있는 사람에게 맞는 방식이다. 푸시 알림만 받거나 은행 계좌 직접 연결을 원하는 경우에는 적합하지 않다고 보여준다. [21:20]
• 결제 문자를 장부에 한 줄이 생겼다는 신호로 받아들이게 됐다고 마무리한다. 설명란에 단축어 설정 순서와 서버 응답표를 정리하겠다고 안내한 뒤 영상을 끝낸다. [21:36]

🧾 결론

• 자동화의 성과는 결제 문자를 확인하고 옮겨 적는 일을 장부 기록과 처리 결과 알림으로 바꾼 데 있다.
• 중간 컴퓨터를 제거하면 전달 경로의 고장 지점은 줄지만, 문자 필터링·인증·중복 제거·취소 연결의 책임은 서버에 남는다.
• 합성 문자와 자동 테스트만으로 실제 문자 형식을 모두 검증하지 못했다. 실사용에서 발견한 예외를 보관·수정·재처리하는 과정이 필요했다.
• 이 방식은 아이폰으로 카드 결제 문자를 받고 문자 형식을 확인할 수 있는 사용자에게 적합하다. 푸시 알림만 받거나 은행 계좌 직접 연결을 원하는 경우에는 적합성이 떨어진다.

📈 투자·시사 포인트

• 비용 판단에서는 기존 요금제와 추가 사용량을 구분해야 한다. 발표자는 기존 월 5달러 요금제 안에서 운영될 것으로 예상하며, 앱의 요청량은 월 수천 건이라고 설명한다.
• AI는 전체 시스템을 대신하기보다 미분류 거래의 과목 제안에 제한적으로 쓰인다. 사용자의 확정을 규칙으로 축적하면 반복 호출과 비용을 줄일 수 있다는 사례다.
• 개인용 도구도 배포 전 테스트·타입 검사·복구 지점 확보와 배포 후 데이터 확인이 중요하다. 기능 구현 이후의 운영 절차가 장부의 신뢰도를 좌우한다.
• 문자 자동화의 활용 범위는 결제 알림 방식과 기기 설정에 묶인다. 다른 카드사나 사용자에게 확장하려면 실제 문자 형식과 자동화 조건을 별도로 검증해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 제목만으로는 결제할 때마다 서버가 자동 배포되는 것으로 읽힐 수 있다. 본문에서 결제로 자동 실행되는 것은 문자 전송과 장부 기록이며, 서버 배포는 터미널에서 별도로 시연한다.
• 월 5달러 요금제 안에서 해결된다는 설명은 예상이다. AI 호출당 약 0.09원이라는 수치도 영상의 설명값이며, 실제 월 청구 결과는 제시되지 않는다.
• 문자 도착부터 기록까지 ‘몇십 밀리초’라는 설명에는 측정 구간과 반복 측정 결과가 없다. 사용자 체감 전체 지연과 같은 값인지는 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 카드 결제를 SMS로 받는지 확인하고, 아이폰에 메시지 조건과 ‘즉시 실행’을 설정한다. 영상에서 설명한 지원 기준은 iOS 17 이상이다.
• 실제 사용하는 신용카드·체크카드의 문자 형식을 확인하고, 허용 카드 목록과 개인·사업자 장부 대응표를 점검한다.
• 단축어의 수신 주소, POST 메서드, Bearer 토큰, User-Agent, JSON 본문의 문자 입력 연결을 확인한다.
• 합성 문자로 정상 기록, 비결제 문자 무시, 인증 실패, 동일 문자 재전송을 각각 시험한다. 실제 결제 후에는 장부 반영 여부도 대조한다.

❓ 열린 질문

• 다른 카드사나 새로운 문자 형식으로 확장할 때, 어떤 실제 사례를 확보해야 누락을 충분히 줄일 수 있을까?
• 아이폰 자동화나 인터넷 연결이 실패했을 때, 사용자가 누락을 발견하고 복구하는 절차는 어떻게 운영할까?
• 동일한 가게의 개인·사업자 지출이나 계정 과목이 달라지는 경우, 확정된 가게 규칙을 어떻게 관리할까?