본인인증 자동화는 왜 매번 사람 손에서 멈췄나?
본인인증 자동화가 매번 사람 손에서 멈춘 원인은 화면에 뜬 문구가 아니라 화면 밖의 상태였습니다. 생년월일을 넣자 값이 따라 들어간 숨은 주민번호 칸, 렌더러를 붙잡은 브라우저 알림창, 부분 일치로 엉뚱하게 고른 통신사 버튼이 그 정체였습니다. 이 글은 정부 포털과 본인인증 팝업을 브라우저 자동화로 끝까지 처리하려다 부딪힌 실패를, 처음 잰 숫자와 틀린 가설과 고친 뒤 다시 잰 숫자 순서로 적은 기록입니다.
정부24·홈택스·위택스 같은 공공 사이트에는 쓸 만한 공개 API가 거의 없습니다. 서류 한 장을 떼려 해도 로그인, 간편인증이나 문자 인증, 폼 입력, 발급 버튼까지 사람이 화면을 눌러야 합니다. 그래서 AI 에이전트에게 브라우저와 휴대폰을 직접 조작하게 했습니다. 그런데 자동화가 가장 자주 멈추는 자리가 하필 본인인증이었습니다. 멈출 때마다 에이전트는 “이 버튼을 눌러 주세요”, “인증서가 없는 것 같습니다”라며 사람을 불렀고, 그 호출 한 번이 자동화를 만든 이유를 지웠습니다.
비용은 세 갈래로 드러났습니다. 첫째는 시간입니다. 브라우저 명령 하나에 4초 넘게 걸려 스텝이 수십 개인 폼은 명령 대기만으로 한참이 갔습니다. 둘째는 실패율입니다. 같은 간편인증을 제공자 네 곳이 연달아 거절했고, 다른 인증 팝업은 4번 연속 실패했습니다. 셋째는 사람의 화면입니다. 에이전트가 운영자가 쓰고 있는 PC의 마우스·키보드 입력을 가로챈 기록이 쌓이고 있었습니다.
웹페이지 안의 버튼·링크·폼 클릭은 사람에게 넘기지 않는다. “이 버튼 눌러주세요”는 실패 보고이지 정상 응답이 아니다.
운영 규칙은 처음부터 이렇게 적혀 있었습니다. 사람에게 넘겨도 괜찮은 경우는 CAPTCHA·2단계 인증·생체 인증처럼 기계가 원리상 못 넘는 벽뿐입니다. 아이디와 비밀번호가 이미 채워진 로그인 버튼은 에이전트가 누릅니다. 로그인은 틀려도 다시 하면 그만이라 되돌릴 수 없는 작업이 아니기 때문입니다. 규칙과 현실 사이의 틈이 이번 개선의 출발점이었습니다.
처음 잰 숫자: 명령 1건 4.2초, 입력 탈취 228건
측정은 두 군데에서 했습니다. 하나는 에이전트의 화면 동작을 전부 남기는 동작 기록 데이터베이스입니다. 화면 좌표를 보고 누르는 조작 루프, 명령줄 도구, Playwright 세션이 한 일이 한 테이블에 쌓이고, 명령 한 줄로 기간별 입력 탈취율을 뽑을 수 있습니다. 다른 하나는 인증을 시도할 때마다 남긴 회차 기록입니다. 몇 회차에 어떤 응답 코드가 왔는지, 사람을 몇 번 불렀는지를 회차 단위로 적었습니다.
속도부터 보겠습니다. 크롬을 원격으로 조작하는 CDP 명령 한 건이 약 4.2초 걸렸습니다(동작 기록 기준 실측). 에이전트는 WSL 리눅스 안에서 돌고 크롬은 Windows에서 돌기 때문에, 명령마다 Windows 쪽 PowerShell을 새로 띄워 다리를 놓는 구조였습니다. 결재 상신처럼 스텝이 수십 개인 흐름이면 그 4.2초가 스텝 수만큼 곱해집니다.
입력 탈취는 전 기간 228건이었습니다. 그중 180건이 웹 페이지를 화면 좌표 조작 루프로 누른 경우였습니다. 브라우저 안의 버튼은 페이지 구조(DOM)로 찾아 누를 수 있는데, 화면 캡처를 보고 좌표로 누르는 방식이 운영자의 마우스를 같이 움직였습니다.
실패 쪽 숫자는 이렇습니다. 2026년 9월 11일 정부24 간편인증에서 카카오·PASS·토스·삼성패스 네 곳이 모두 같은 거절을 돌려줬습니다. 화면 문구는 “인증서를 발급하지 않으셨다면…”이었고 응답 코드는 OACX_NO_USER였습니다. 2026년 9월 18일 Siren24 문자 인증에서는 “인증실패! 본인확인에 실패하였습니다”가 4번 연속 떴습니다. 같은 9월 11일 안전신문고 문자 인증 1회차는 인증번호를 보낸 직후부터 모든 브라우저 명령이 WebSocketTimeout으로 죽었습니다.
이 숫자들을 한 장에 놓으면 문제의 모양이 보입니다. 느린 것은 불편이지만, 인증 거절과 입력 탈취는 자동화를 아예 쓸 수 없게 만듭니다. 인증에서 멈추면 사람이 불려 오고, 사람이 PC를 쓰는 사이 에이전트가 화면을 누르면 둘 다 일을 못 합니다.
세운 가설: 인증서가 없거나, 환경이 막았거나
증상마다 그럴듯한 설명이 있었습니다. 간편인증 네 곳 거절은 화면이 대놓고 “인증서를 발급하지 않으셨다면”이라고 말했으니, 그 제공자에 인증서가 없다는 해석이 가장 자연스러웠습니다. 사람에게 “카카오 인증서를 새로 발급해 주세요”라고 부탁하면 끝날 일처럼 보였습니다.
Siren24 4연속 실패는 문자가 오지 않았다는 점에서 환경 문제로 보였습니다. 자동화 브라우저라서 사이트가 막았거나, 명의가 맞지 않거나, 접속 IP가 의심을 샀다는 식입니다. 본인확인 서비스가 자동화를 경계한다는 이야기는 흔하니 의심할 이유가 적었습니다.
WebSocketTimeout은 페이지가 멈췄거나 사이트 서버가 느리다는 신호로 읽었습니다. 4.2초라는 명령 속도도 공공 사이트가 원래 무겁다는 말로 넘겼습니다. 입력 탈취는 운영자가 PC를 쓰는 시간과 겹친 운 나쁜 사고로 봤습니다.
돌아보면 네 가설에는 공통점이 있습니다. 원인을 전부 우리 밖에 둔다는 점입니다. 원인이 사이트나 통신사나 운영자 쪽에 있으면 저희가 할 수 있는 일은 사람을 부르는 것뿐입니다. 가설이 맞다면 자동화는 거기서 끝이었고, 그래서 이 가설들은 확인하기 전부터 편했습니다.
가설은 어디서 틀렸나?
첫 균열은 간편인증에서 나왔습니다. 한 사람이 카카오·PASS·토스·삼성패스 네 곳에 동시에 인증서가 없을 가능성은 낮습니다. 넷이 같은 시각에 같은 코드로 거절했다면 제공자 쪽 사정보다 저희가 보낸 요청이 공통 원인일 가능성이 컸습니다. 요청 본문을 들여다보자 가설은 바로 무너졌습니다. 숨은 칸을 비우고 다시 보내자 PASS가 곧바로 OACX_SUCCESS를 돌려줬습니다. 인증서는 처음부터 있었습니다.
Siren24도 같은 방식으로 깨졌습니다. 환경·명의·IP를 의심하기 전에 화면에서 선택한 통신사 값부터 읽어 보니 KT가 아니라 SKT를 고른 상태였습니다. 다른 통신사로 문자를 요청했으니 KT 번호에는 문자가 올 수 없었습니다. 4번의 실패는 사이트가 자동화를 막은 결과가 아니라 매번 같은 오선택을 반복한 결과였습니다.
WebSocketTimeout을 오래 붙잡게 만든 것은 우리 도구였습니다. 팝업을 닫는 dismiss-dialog 명령이 “차단 팝업 없음. 진행 가능”이라고 초록불을 줬습니다. 그 명령은 Windows 네이티브 창만 보는데, 막고 있던 것은 브라우저 안의 자바스크립트 alert였습니다. 초록불을 믿으면 원인을 엉뚱한 데서 찾습니다. 화면 캡처로 직접 보니 알림창이 떠 있었습니다.
- 간편인증 4곳 거절: “인증서 없음”이 아니라 우리 요청에 섞인 값이 원인
- Siren24 4연속 실패: “환경 차단”이 아니라 통신사 오선택
- WebSocketTimeout: “페이지 멈춤”이 아니라 알림창이 렌더러를 붙잡음
- 4.2초: “사이트가 무거움”이 아니라 명령마다 PowerShell을 띄우는 구조
네 가설 모두 밖을 가리켰고, 네 원인 모두 안에 있었습니다. 그리고 넷 다 화면에 보이는 문구만 읽어서는 찾을 수 없었습니다. 화면 문구는 사이트가 사람에게 보여 주려고 고른 말이고, 실제 판정은 응답 코드와 입력값과 브라우저 상태에 남아 있었습니다.
진짜 원인은 무엇이었나? 화면 밖 네 가지
가장 찾기 어려웠던 것은 숨은 주민번호 칸입니다. 정부24 “간편인증”은 iframe 안의 OACX 모듈(Vue로 만든 화면)입니다. 보이는 입력칸은 이름(#oacx_name), 생년월일(#oacx_birth), 휴대폰(#oacx_phone2)입니다. 그런데 생년월일을 자바스크립트로 주입하고 나면 보이지 않는 주민번호 칸(#oacx_num1, 내부 상태 UserInfoStore.ssn1)에 월 두 자리가 따라 들어갔습니다. 이 값이 요청에 함께 실리자 제공자는 그 사람을 찾지 못했고, 네 곳 모두 OACX_NO_USER를 돌려줬습니다. 사람이 손으로 입력할 때는 생기지 않고 자동화가 값을 밀어 넣을 때만 생기는 오염이었습니다.
두 번째는 부분 일치입니다. Playwright의 locator('button', has_text='KT')는 글자가 포함되기만 하면 잡습니다. 통신사 목록에서 “SKT”가 먼저 나오니 매번 그 버튼을 눌렀습니다. 코드는 정상으로 돌았고 에러도 없었습니다. 누른 버튼만 틀렸습니다.
세 번째는 알림창입니다. 인증번호를 보내면 사이트가 발송 안내를 담은 alert를 띄웁니다. 이 알림이 열려 있는 동안 브라우저는 페이지의 자바스크립트를 멈추고, 그 뒤로 보내는 CDP 명령은 전부 시간 초과로 끝납니다. 네이티브 창이 아니니 Windows UI 자동화 도구에도 잡히지 않습니다. 커스텀 select에 값을 넣은 뒤 다른 칸을 채우면 select의 change 핸들러가 그 칸을 초기화하는 함정도 같은 부류의 폼에 있었습니다(2026년 9월 8일 전자가족관계등록시스템에서 두 함정이 한 폼에 함께 나왔습니다).
네 번째는 속도와 입력 탈취를 함께 만든 구조입니다. 명령 하나마다 PowerShell을 새로 띄우니 한 콜이 약 4.2초였고, 브라우저를 화면 좌표로 누르는 루프가 열려 있으니 운영자의 마우스를 가로챘습니다. 웹 페이지는 DOM으로 다룰 수 있는데 굳이 화면 위 픽셀로 다룬 것이 탈취 180건의 출처였습니다.
조치: 문구 대신 응답 코드를 읽고, 입력칸을 먼저 비운다
간편인증은 요청을 보내기 전에 숨은 칸부터 비우게 바꿨습니다. UserInfoStore.ssn1을 빈 문자열로, #oacx_num1을 빈 값으로 만든 뒤 요청 버튼을 누릅니다. 이름·생년월일·번호 같은 민감한 값은 시크릿 저장소에서 임시칸으로 넣고, 자바스크립트로 진짜 칸에 옮기면서 native value setter와 input 이벤트를 쏩니다. 값이 화면 기록이나 명령 인자에 남지 않게 하려는 장치입니다.
거절당했을 때 읽는 대상도 바꿨습니다. 화면 문구를 해석하지 않고, XHR의 loadend에 걸어 /oacx/api/v1.0/authen/request 응답에서 oacxCode와 clientMessage만 뽑습니다. “인증서를 발급하지 않으셨다면”이라는 문장을 봐도 인증서 미발급으로 단정하지 않는다는 규칙을 문서에 남겼습니다.
통신사 버튼은 정확히 일치하는 이름으로만 고르게 했습니다. get_by_role('button', name='KT', exact=True)입니다. 그리고 환경이나 명의를 의심하기 전에 지금 선택한 값부터 읽는 순서를 규칙으로 못 박았습니다.
알림창은 미리 가로챕니다. 인증번호 요청 버튼을 누르기 전에 window.alert와 window.confirm을 덮어써서 메시지를 배열에 쌓기만 하게 만듭니다. 버튼 자체도 setTimeout으로 50밀리초 뒤에 누르도록 예약해, 클릭 명령이 응답을 기다리다 묶이지 않게 했습니다. 인증이 끝났는지는 숨은 완료 필드나 쌓인 메시지 속 인증 완료 문구로 판정합니다.
문자 인증번호는 휴대폰을 ADB(안드로이드 디버그 브리지)로 PC에 연결해 직접 읽습니다. 요청 직전 시각에서 20초를 뺀 값을 기준으로 그보다 뒤에 온 문자만 보고, 발신처로 한 번 더 좁히고, 최대 90초 기다립니다. 20초는 휴대폰과 PC 시계의 차이를 흡수하는 여유입니다. 6자리 코드는 명령 인자에도 응답에도 싣지 않고 자릿수만 돌려줍니다.
인증 수단을 고르는 순서도 정했습니다. 본인인증 창이 문자·PASS·카카오 중 하나를 고르게 하면 항상 문자를 고릅니다. 문자만 휴대폰 브리지로 끝까지 무인이고, PASS와 카카오는 지문 한 번이 남기 때문입니다.
속도는 구조로 풀었습니다. 스텝이 10개를 넘는 흐름은 명령을 하나씩 보내지 않고, 크롬으로 가는 통로(릴레이)를 한 번 연 뒤 WSL의 Playwright로 한 세션 안에서 돌립니다. 이때 browser.close()는 금지입니다. 붙어 있는 크롬 창 자체를 닫아 버리기 때문입니다. 화면 배율(DPR)이 1.5라 스크린샷 좌표로 클릭하지 않고 locator로 요소를 찾습니다.
입력 탈취는 길을 막았습니다. 2026년 9월 11일부터 화면 좌표 조작 루프는 브라우저 본창(주소창·탭 포함)을 거절합니다. 주소 이동·탭 전환·파일 선택은 CDP 전용 명령으로만 합니다. 2026년 9월 17일부터는 에이전트가 직접 하는 웹 작업의 기본 실행 장소를 VirtualBox 게스트 VM 안의 크롬으로 옮겼습니다. 게스트가 죽어 있으면 조용히 운영자의 PC로 넘어가지 않고 실패합니다. 넘어가면 다시 남의 화면을 누르기 때문입니다. 브라우저 자동화에서 클릭 순서가 결과를 바꾼 다른 사례는 브라우저 자동화 표 삽입 실패 기록에 적어 두었습니다.
재측정 결과: 121초·사람 입력 0, 스텝당 0.09초
숨은 칸을 비운 뒤 정부24 간편인증은 PASS가 곧바로 OACX_SUCCESS였습니다. 같은 날인 2026년 9월 11일 14시 50분, 13회차에서는 카카오 인증으로 정부24 로그인까지 마쳤습니다. 2026년 9월 18일에는 위택스 PASS 로그인을 사람 호출 0번으로 끝냈고, 같은 날 12시 43분 홈택스 PASS 로그인도 사람 몫 0으로 통과했습니다. 홈택스 건은 PASS 서명용 인증서 PIN 6자리를 에이전트가 시크릿 저장소 값으로 보안 키패드에 직접 입력했고, 오입력 잠금을 피하려 1회만 시도합니다.
문자 인증은 안전신문고 비회원 신고에서 처음부터 끝까지 다시 쟀습니다. 인증번호 요청부터 인증 완료까지 121초였고 사람 입력은 0이었습니다. 1회차를 죽였던 알림창은 미리 덮어쓴 함수가 배열로 받아 냈습니다.
속도는 스텝당 약 0.09초로 내려갔습니다. 명령마다 PowerShell을 띄우던 약 4.2초와 비교하면 45배 빠릅니다. 측정은 결재 상신처럼 스텝이 많은 흐름을 같은 크롬에 붙어 한 세션으로 돌리는 방식으로 했습니다. 다만 짧은 단발 작업은 여전히 명령 단위로 보냅니다. 통로를 여는 준비 과정이 있어서 스텝이 적으면 이득이 작습니다.
인증 모듈은 하나씩 범위를 넓혔습니다. 2026년 10월 8일에는 4대사회보험 정보연계센터 로그인을 사람 호출 0번으로 마쳤습니다. 이 사이트는 간편인증을 iframe이 아니라 팝업으로 띄우는데 자동화 크롬에서는 팝업이 열리지 않아, window.open을 덮어 같은 페이지 iframe에 띄우고 요청 전에 opener를 붙였습니다. 2026년 10월 14일 NHN KCP 본인인증도 같은 문자 인증 순서로 실측해 사이트별 입력칸 표에 한 줄을 더했습니다.
하나를 덧붙이면, 2026년 9월 8일 전자가족관계등록시스템 제적등본 발급은 알림창과 select 초기화라는 두 함정을 같은 폼에서 넘어 완주했습니다. select를 먼저 채우고 텍스트를 나중에 넣는 순서, 그리고 넣은 직후가 아니라 제출 직전에 모든 값을 다시 읽는 확인을 그대로 따랐습니다.
남는 한계: 지문 한 번과 아직 못 본 인증 모듈
사람 손이 완전히 빠진 것은 아닙니다. PASS와 카카오는 여전히 지문 한 번이 남습니다. 그래서 인증 수단을 고를 수 있으면 문자를 고르는 규칙을 둔 것이고, 고를 수 없는 사이트에서는 지문 한 번을 사람에게 넘깁니다. reCAPTCHA나 hCaptcha 이미지 퍼즐처럼 풀리지 않는 보안문자도 같은 처지입니다.
휴대폰은 공유 자원이라는 문제도 남았습니다. 10회차 때 옆 작업 창의 에이전트가 LinkedIn 로그인 확인을 누르는 사이 PASS 서명 화면이 밀려났습니다. 지금은 여러 단계를 누를 때 휴대폰을 점유(hold)하고 끝나면 풀게 했지만, 이 장치를 거치지 않고 adb shell input을 직접 쏘는 코드는 점유 표시를 모릅니다. 문자 인증도 발신처와 시각으로 좁히지 않으면 남의 인증 문자를 집을 수 있습니다.
시간 제약도 있습니다. PASS 요청의 기한은 요청 후 약 5분이고, 넘기면 일치하는 데이터가 없다는 오류가 납니다. KG모빌리언스 인증 창은 40분 넘게 열어 둔 채 인증을 끝내면 창은 닫히는데 부모 폼에 결과가 넘어오지 않았습니다. PASS 알림은 한 번 누르면 사라지고, 같은 요청을 다시 여는 방법은 아직 모릅니다.
- NICE·KMC·다날 본인인증 팝업은 아직 실측하지 않았다
- 4대사회보험 정보연계센터 온라인 발급은 확인용뿐이라 제출용은 창구 청구가 필요하다
- 입력 탈취는 거절 규칙을 넣은 뒤 건수를 다시 잰 값이 이 기록에 없다
- dismiss-dialog는 여전히 네이티브 창만 본다. 초록불을 브라우저 알림창 부재로 읽지 않는다
마지막 항목은 정직하게 적어 둡니다. 입력 탈취 228건 중 180건의 출처를 막는 규칙은 넣었지만, 그 뒤 탈취율이 얼마로 내려갔는지는 아직 다시 재지 않았습니다. 동작 기록 데이터베이스에서 같은 명령으로 날짜만 바꿔 뽑으면 끝나는 일이라, 다음 측정의 첫 항목으로 남겨 두었습니다.
본인인증 자동화가 막히면 무엇부터 확인해야 하나?
이번 일에서 얻은 점검 순서를 그대로 적습니다. 원인을 밖에서 찾기 전에 안에서 찾을 수 있는 것부터 봅니다.
- 거절 문구 대신 응답 코드를 읽는다. XHR 응답의 코드·메시지만 뽑는다
- 보내기 직전 요청에 실린 값을 전부 읽는다. 숨은 칸에 따라 들어간 값이 없는지
- 고른 버튼의 실제 값을 읽는다. 부분 일치 선택자가 다른 항목을 잡지 않았는지
- 시간 초과가 나면 화면을 직접 본다. 브라우저 알림창은 네이티브 창 검사에 안 잡힌다
- 값은 넣은 직후가 아니라 제출 직전에 다시 읽는다. select 핸들러가 다른 칸을 비울 수 있다
공통 원리는 하나입니다. 화면 문구는 사람을 위한 요약이고, 판정은 데이터에 남아 있습니다. 공공 사이트나 본인인증이 낀 업무를 자동화하려는데 어디서 막히는지 모르겠다면, 이 순서로 먼저 확인해 보시고 그래도 막히면 상담으로 상황을 알려 주세요.