SMS 포워더가 송금을 감지했다면, 주문을 마감해도 될까?

'SMS 포워더 온라인'이라는 표시는 시스템의 어떤 구성 요소가 최근에 응답했다는 뜻일 뿐입니다. 그것만으로 포워더가 은행 알림을 받고 있고, 금액을 정확히 추출하며, 모든 이벤트를 전달한다는 결론은 나오지 않습니다. P2P 운영자에게 이 차이는 곧 돈 문제입니다. 놓친 메시지는 입금 인정을 늦추고, 잘못 해석된 메시지는 존재하지 않는 돈을 확인해 버릴 수 있습니다.

여기서 포워더란 허용된 거래 알림을 단말기나 합의된 다른 출처에서 프로세싱 시스템으로 전달하는 도구를 말합니다. 포워더는 입금 가능성을 더 빨리 발견하도록 돕습니다. 돈을 받는 쪽의 계약상 역할, 해당 운영 모델에 대한 은행의 허가, 금융적 인정의 근거는 별도로 정해집니다. 앱을 설치한다고 이 조건 중 어느 것도 바뀌지 않습니다.

은행과 주문 사이에는 여러 독립적인 이벤트가 있다

먼저 은행이 거래를 반영합니다. 그다음 알림을 생성해 단말기로 전송합니다. 운영체제는 부여된 권한 범위 안에서 메시지를 앱이 볼 수 있게 합니다. 포워더는 필요한 필드를 추출해 이벤트를 저장하고 서버로 보내며, 서버는 수신을 확인합니다. 그 후 알고리즘이 맞는 주문을 찾아 증빙을 평가합니다.

어느 구간이든 지연되거나 인접 구간과 따로 끝날 수 있습니다. 은행은 입금을 처리했지만 알림이 아직 오지 않았을 수 있습니다. 단말기는 메시지를 받았지만 네트워크가 끊겼을 수 있습니다. 서버는 이벤트를 저장했지만 응답이 도달하지 않아 앱이 재전송했을 수 있습니다. 시스템이 알림을 주문과 매칭했는데 나중에 은행 거래 내역에 다른 금액이 찍혔을 수도 있습니다. 고객 화면에서는 모두 '결제가 멈췄다'로 보이지만, 이 상황들은 각기 다른 조치가 필요합니다.

그래서 이벤트에는 거래 시각(신뢰할 수 있게 확인 가능한 경우), 단말기 수신 시각, 서버 수신 시각을 저장합니다. 파싱과 매칭 시각은 따로 기록할 수 있습니다. 이를 하나의 타임스탬프로 섞어 버리면 은행, 단말기, 네트워크, 자체 처리 대기열 중 어디가 느린지 알 수 없습니다.

먼저 어떤 데이터가 필요한지부터 합의하자

입금을 찾는 데는 보통 금액, 통화, 일부만 표시된 계좌 식별자, 은행 참조 번호, 확인 가능한 시각, 이벤트 유형이 유용합니다. 구체적인 항목은 출처에 따라 다릅니다. 개별 결제 주문을 마감하는 데 전체 SMS 기록, 개인 대화, 다른 계좌의 잔액, 로그인 코드는 필요하지 않습니다.

권한은 단말기와 데이터의 소유자가 특정 목적과 특정 수신자를 위해 부여합니다. 알림 접근 권한을 휴대폰의 모든 내용을 전송해도 된다는 동의로 해석해서는 안 됩니다. Google Play는 SMS와 통화 기록 접근을 별도로 제한합니다. 기술적으로 읽을 수 있다는 것이 앱의 배포나 사용이 허용된다는 뜻은 아닙니다. 적용되는 플랫폼과 은행의 요건은 출시 전에 확인합니다.

인증 메시지, 일회용 코드, 거래 승인 요청은 이 채널에서 제외합니다. 필터링은 불필요한 전송을 막아야 하며, 비밀 정보가 이미 서버에 들어간 뒤 지우려 해서는 안 됩니다. 허용 가능한 알림을 확실히 분리할 수 없다면 그 출처는 적합하지 않습니다. 대사의 편의를 위해 더 넓은 접근 권한을 내주는 것은 합리적인 대가가 아닙니다.

진짜 메시지에서도 파서는 틀릴 수 있다

연습용 알림에 입금 12 000과 새 잔액 524 000이 들어 있다고 합시다. 은행 템플릿이 바뀐 뒤, 처음 나오는 금액을 추출하는 로직이 거래 금액 대신 계좌 잔액을 반환하기 시작합니다. 메시지는 진짜이고, 발신자도 익숙하고, 연결도 보호되어 있지만, 처리 결과는 금융적으로 틀렸습니다.

그래서 템플릿과 파서의 버전은 증빙 기록의 일부가 됩니다. 알 수 없는 형식은 대략적인 일치로 확신에 찬 결과를 내지 말고 검토로 보내야 합니다. 프로토콜은 입금, 출금, 취소, 안내 메시지를 구분해야 합니다. 모든 양수를 새로운 입금으로 바꿔서는 안 됩니다.

같은 12 000짜리 주문 두 건이 동시에 열려 있다면 '금액 + 가장 가까운 시각' 조합만으로도 부족합니다. 추가 특징은 출처가 실제로 전달하는 범위 안에서만 사용합니다. 필요한 참조 번호가 없다면 시스템은 모호함을 인정합니다. 매칭을 끝내기 위해 주문 번호로 참조 번호를 지어내지 않습니다.

재전송은 지루하게 처리되어야 한다

서버가 알림을 저장했지만 단말기가 확인 응답을 받지 못했다고 합시다. 재전송은 두 번째 금융 기록을 만들지 않고, 이미 수신된 이벤트에 대한 참조를 돌려줘야 합니다. 안정적인 메시지 식별자와 저장된 전송 상태가 재전송과 새 이벤트를 구분하는 데 도움이 됩니다. 하지만 두 알림의 문구가 같다고 실제 송금이 한 건뿐이었다는 증거가 되지는 않습니다.

은행 데이터가 들어오면 관찰 결과들을 실제 입금을 중심으로 묶습니다. SMS, 푸시, 거래 내역 한 줄이 같은 거래에 해당할 수 있습니다. 반대로 같은 금액에 은행 참조 번호가 두 개라면 결제 두 건을 확인해 주는 것일 수 있습니다. 따라서 전송 채널의 중복 제거와 입금의 중복 제거는 서로 다른 문제를 해결합니다.

연결이 복구되면 대기열은 원래 시각을 유지한 채 통제된 방식으로 전송됩니다. 서버가 지금 받았다는 이유만으로 오래된 메시지가 새로운 결제처럼 보여서는 안 됩니다. 관련 주문 중 일부는 이미 만료되었거나 수동 검토로 넘어갔을 수 있으므로, 처리 시 현재 상태와 발급된 계좌 정보의 이력을 고려해야 합니다.

'단말기가 살아 있다'와 '출처가 작동한다'는 따로 확인한다

운영 대시보드는 마지막 연결, 허용된 출처의 상태, 전송되지 않은 가장 오래된 이벤트의 경과 시간, 확인되지 않은 전송 건수, 마지막으로 성공한 대사를 보여 줄 수 있습니다. 거래가 없으면 알림이 없는 것이 정상일 수 있습니다. 그러나 은행에는 입금이 보이는데 채널이 조용하다면, 이는 이미 관찰 가능한 불일치입니다.

Android는 알림 리스너의 연결과 해제 상태를 문서화하고 있으며, 절전 모드는 백그라운드 네트워크 작업을 지연시킬 수 있습니다. 테스트에서 이런 특성을 고려해야 합니다. 그렇다고 권한을 몰래 확대하거나 단말기 보안을 우회하는 것이 정당화되지는 않습니다. 실무 아키텍처에는 장애 감지, 명확한 에스컬레이션, 입금을 확인하는 허용된 대체 수단이 포함됩니다.

신뢰할 수 있는 출처를 잃으면 운영자는 영향을 받은 경로에 대한 신규 배정을 중단하되, 이미 안내한 결제 정보에 대한 처리는 유지할 수 있습니다. 기존 고객은 여전히 송금할 수 있기 때문입니다. 열린 주문 목록 없이 채널을 그냥 끄면, 불확실성이 가장 큰 바로 그 순간에 입금이 관찰 범위 밖에 남게 됩니다.

메시지 수가 아니라 은행 기준으로 결과를 측정한다

확인된 은행 입금이 100건인 하루를 생각해 봅시다. 포워더는 그중 95건의 알림을 제때 전달했고, 3건은 늦게 전달했으며, 2건은 놓쳤습니다. 이와 별도로 8건의 이벤트가 중복으로 들어왔습니다. 서버는 106건의 메시지를 받았습니다. 고유 관찰 98건에 중복 8건입니다.

'결제 100건당 이벤트 106건'이라는 지표는 품질에 대해 아무것도 말해 주지 않습니다. 이 예에서 감지 완전성은 98%, 전체 입금 대비 적시성은 95%입니다. 매칭 오류, 예외 건의 경과 시간, 대사에서야 발견된 거래 비중은 따로 계산합니다. 독립적인 은행 데이터가 없으면 놓친 메시지는 아예 분모에 들어가지 않고, 시스템은 실제보다 좋아 보이게 됩니다.

포워더의 최종 결과물은 이후 결정에 쓸 수 있는 검증 가능한 관찰입니다. 계약상 더 약한 신호로 조기 인정을 허용한다면, 그것은 한도, 책임자, 사후 대사를 갖춘 별도의 의식적인 리스크입니다. 이런 신호를 최종 은행 확인이라고 불러서는 안 됩니다. 좋은 자동화는 돈을 찾는 시간을 줄이면서도 실제로 어떤 돈을 받았는지 증명할 수 있는 능력을 지켜 줍니다.