공동인증서·OTP가 걸린 결제 업무도 자동화할 수 있을까?

🍎 바쁘다면 알짜배기만이라도 !

• 기술 가능성 — 공동인증서와 보안키보드는 사이트별 검증이 필요합니다.
• 보안 경계 — OTP와 캡차는 우회보다 승인·공식 연동을 먼저 봐야 합니다.
• 운영 기준 — 결제 전 승인, 한도, 중복 방지, 결과 대조가 함께 있어야 합니다.

공동인증서가 있으면 결제 자동화는 불가능할까요?

구매나 이체 업무를 자동화하려는 기업이 가장 먼저 묻는 질문은 “로그인과 결제까지 정말 가능한가”입니다. 엑셀에서 주문 정보를 읽고 장바구니를 채우는 데까지는 금방 설명되지만, 공동인증서·가상 보안키보드·OTP가 등장하면 답이 흐려집니다. 결론부터 말하면 가능 여부는 보안 수단의 이름 하나로 결정되지 않습니다.

같은 공동인증서를 쓰더라도 인증서 선택 창이 운영체제 표준 창인지, 별도 보안 프로그램이 띄운 화면인지, 인증서가 로컬 PC와 이동식 매체 중 어디에 있는지에 따라 구현 방식이 달라집니다. 결제 버튼을 누를 수 있다는 사실과 결제 업무를 안전하게 운영할 수 있다는 사실도 구분해야 합니다.

자동화 범위는 한 번 정하고 끝나는 값도 아닙니다. 사이트 보안 모듈이 바뀌거나 인증서가 갱신되고 결제 정책이 달라지면 다시 시험해야 합니다. 구축 가능성뿐 아니라 변경 뒤 재검증을 누가 맡는지까지 보아야 실제 운영 비용을 판단할 수 있습니다.

그래서 첫 검토에서 “됩니다” 또는 “안 됩니다”라고 단정하면 안 됩니다. 실제 계정의 테스트 환경에서 로그인부터 완료 화면까지 지나가 보고, 사람이 반드시 개입해야 하는 구간과 자동 실행해도 되는 구간을 나누는 것이 먼저입니다.

네 가지 보안 장벽은 왜 같은 방식으로 풀 수 없을까요?

공동인증서는 개인키를 이용해 사용자를 증명하고, 보안키보드는 입력값 탈취를 어렵게 만들며, OTP는 한 번만 쓸 수 있는 값을 추가로 요구합니다. 캡차는 애초에 사람과 자동화된 접근을 구분하려는 장치입니다. 겉으로는 모두 “로그인을 막는 화면”처럼 보여도 목적과 허용되는 해법이 다릅니다.

보안 프로그램을 끄거나 입력 보호 기능을 우회하는 방식은 운영 설계가 아닙니다. 업데이트 한 번에 멈출 수 있고, 서비스 약관이나 내부 보안 정책과 충돌할 수 있기 때문입니다. 지원되는 입력 경로, 공식 API, 기업용 계정, 사람 승인 중 어떤 조합이 가능한지부터 확인해야 합니다.

공동인증서와 보안키보드는 무엇을 시험해야 할까요?

공동인증서 화면에서는 인증서 목록을 안정적으로 식별할 수 있는지, 비밀번호 입력이 정상적으로 전달되는지, 만료·갱신·저장 위치 변경이 발생했을 때 누가 조치할지를 봐야 합니다. 화면 좌표만 외운 자동화는 창 위치나 해상도가 바뀌면 다른 항목을 누를 수 있습니다. 인증서 선택 결과와 로그인된 법인 계정이 맞는지까지 검증해야 한 단계가 끝납니다.

가상 보안키보드는 키 배열이 매번 바뀌는지, 키가 화면 이미지인지 접근 가능한 요소인지, 키보드 입력과 마우스 입력 중 무엇을 허용하는지에 따라 난도가 달라집니다. 기술적으로 클릭이 가능해도 보안 모듈이 자동 입력을 탐지해 세션을 끝낼 수 있습니다. 이때는 탐지를 피하는 방향이 아니라 사이트 운영자에게 허용된 연동 방식이 있는지 확인해야 합니다.

웹 화면이 자주 바뀔 때 자동화가 왜 멈추는지를 함께 보면, 좌표 기반 조작과 구조를 읽는 자동화의 차이를 이해하기 쉽습니다. 인증 화면은 일반 상품 페이지보다 변경과 보안 통제가 잦아 복구 기준까지 같이 정해야 합니다.

OTP와 캡차는 자동으로 넘겨도 될까요?

NIST SP 800-63B-4, 2025는 OTP를 인증자가 생성하고 한 번만 사용하는 값으로 정의합니다. 사람이 별도 기기에서 받은 OTP를 같은 로봇 실행 환경이 읽도록 만들면 기술적으로 편해질 수는 있지만, 인증 요소를 분리한 목적은 약해집니다. OTP 비밀값을 봇에 저장하는 것보다 승인 알림을 사람에게 보내거나 공식 인증 연동을 쓰는 편이 안전합니다.

캡차는 더 명확합니다. OWASP의 Bot Management and Anti-Automation 지침, 2026은 캡차를 자동화된 악용을 줄이는 방어 수단으로 다룹니다. 캡차를 푸는 서비스를 붙여 계속 진행하는 방식은 정상적인 기업 자동화의 전제가 되기 어렵습니다.

캡차가 나타나면 작업을 중단하고 담당자에게 넘기거나, 서비스 제공자가 허용한 API·파트너 계정·화이트리스트를 협의해야 합니다. 캡차가 자주 뜬다면 자동화 기술보다 접근 빈도, 계정 정책, 서비스가 허용하는 이용 방식부터 다시 봐야 합니다.

결제 버튼 앞에서 사람은 어디에 남아야 할까요?

결제·이체는 한 번의 오류가 비용과 거래처 관계로 이어집니다. 처음부터 전 과정을 무인 실행하기보다 로봇이 상품 조회, 수량 대조, 장바구니 구성, 결제 예정 금액 계산까지 맡고 금액·수취인·수량을 사람이 확인한 뒤 실행하는 구조가 현실적입니다.

승인 화면에는 “결제하시겠습니까?”만 보여주면 부족합니다. 원본 주문번호, 구매처, 품목과 수량, 총액, 배송지, 결제수단을 함께 보여줘야 합니다. 신규 수취인, 평소보다 큰 금액, 품절 대체품처럼 위험이 높은 조건은 별도 승인으로 올리고, 나머지도 정해진 한도 안에서만 실행해야 합니다.

결제 뒤에는 성공 메시지만 믿지 말고 주문번호나 거래번호를 수집해 원본 요청과 대조해야 합니다. 페이지 응답이 늦어 재실행되더라도 같은 주문이 두 번 나가지 않도록 업무별 고유 식별자를 남겨야 합니다. 이커머스에서 RPA를 적용하는 기본 흐름보다 결제 구간은 권한과 결과 대조가 한 단계 더 필요합니다.

구축 전에 무엇을 계약서와 운영표에 적어야 할까요?

기술 검증이 끝나도 운영 기준이 비어 있으면 자동화는 결제 담당자의 불안을 줄이지 못합니다. 최소한 계정과 인증서의 소유자, 자동 실행 금액과 건수 한도, 허용된 구매처와 수취인, 중복 방지 방식, 로그 보관 범위를 정해야 합니다. 장애가 났을 때 누가 멈추고 몇 분 안에 확인하며 잘못된 주문을 누가 취소할지도 문서에 있어야 합니다.

모니터링은 프로그램이 켜져 있는지만 보는 일이 아닙니다. 요청 건수와 완료 건수, 승인 후 미실행 건, 중복 시도, 결제 금액 차이, 취소가 필요한 예외를 함께 봐야 합니다. 화면 변경으로 버튼을 못 누른 장애와 잘못된 금액으로 결제한 장애는 복구 순서와 책임이 다릅니다.

자동화 공급자가 인증정보를 어떻게 보관하고 누가 접근할 수 있는지도 확인해야 합니다. 개발자 개인 PC나 메신저에 인증서 비밀번호를 남기는 구조라면 자동화 범위를 줄이는 것이 맞습니다. 못 넘는 보안 장벽을 억지로 넘는 것보다, 승인 지점을 남기고 운영 책임을 명확히 하는 편이 더 오래갑니다.

다음 단계

공동인증서·보안키보드·OTP가 있는 업무는 실제 화면과 계정 정책을 봐야 자동화 범위를 판단할 수 있습니다. 로그인부터 결제 완료까지 한 번 지나가며 무인 실행, 승인 후 실행, 사람 이관 구간을 나누면 필요한 기술과 운영 비용이 선명해집니다.

구매·결제 업무의 자동화 가능 범위 확인하기