파트너 정산 송금을 접근성 서비스로 자동화한 과정

송금 자동화 배경

파트너 정산 처리량이 늘면서 수기 송금 부담이 한계점 도달. 결제대행사 정산 사이클 밖의 즉시 송금 건은 사람이 직접 은행 앱을 두드려야 했음. 안드로이드 접근성 서비스로 은행 앱 폼을 자동으로 채우는 보조 수단을 도입함. 결제 플랫폼 본 흐름은 그대로 두고, 운영팀 손이 닿는 부분만 줄이는 게 목표였음.

• 메신저 알림 수신 → 송금 요청 메시지 파싱
• 접근성 서비스가 대상 은행 앱 화면 감지
• 계좌/금액/메모 필드 자동 입력
• 최종 확인은 사람이 직접. 자동 확인 절대 금지

은행별 폼 매핑

같은 송금 흐름이라도 은행별 WebView DOM 구조가 다 달라서 한 번에 통일 못함. 매핑 테이블로 분리해놓음.

새 은행 들어오면 매핑만 늘리면 끝. 코어 로직은 공통으로 뽑아둠.

자동 입력 로직

windowStateChanged 이벤트 수신
  → 화면 식별 (앱 패키지 + 액티비티 + URL)
  → 매핑 테이블 조회
  → 노드 트리에서 타겟 검색
  → SET_TEXT 액션 디스패치
  → 입력 검증 후 다음 단계

처음엔 텍스트 세팅만 썼는데 일부 은행 필드는 붙여넣기로만 반응함. 클립보드 fallback 경로 끼워넣고 해결됨. 입력 후 실제 노드 텍스트를 다시 읽어서 일치하는지 가드 검증함. 침묵 실패가 가장 무서운 시나리오라서 한 단계라도 어긋나면 즉시 중단하고 알림 쏘게 함.

디버그 수신기

QA 단계에서 매번 메신저로 진짜 메시지 쏠 수 없으니 디버그 브로드캐스트 수신기 만듦. 매니페스트에서 빌드 타입 분기 걸어 운영 빌드엔 빠지게 함.

• 시나리오 주입을 셸 스크립트로 자동화
• 트레이스 자동 캡쳐, 로그 레벨 상승
• 권한·접근성 서비스 활성 여부 사전 점검

회고

가장 까다로운 건 은행 앱 업데이트로 DOM이 갈아엎힐 때였음. 매핑 깨지면 사용자 모르게 송금이 헛돌 위험이 있어서, 입력 후 검증을 의무화함. 접근성 서비스라는 권한은 강력해서 본 기능 외 다른 화면을 절대 건드리지 않게 화이트리스트로 좁혀둠. 다음 은행 추가는 매핑 PR 한 장이면 충분하도록 정리됨.

다음