API가 없는 시스템이 남아 있는 회사
대부분의 기업에는 연동 인터페이스가 없는 시스템이 하나쯤 남아 있습니다. 거래처가 운영하는 발주 포털, 로그인 후 조회만 가능한 관공서 사이트, 20년 전에 만들어져 소스 코드도 담당자도 사라진 사내 화면이 대표적입니다. 이런 곳에는 결국 사람이 붙어 매일 같은 화면을 열고, 같은 값을 옮겨 적습니다.
2026년 들어 브라우저·컴퓨터 사용 에이전트는 자동화 도구의 별도 카테고리로 자리를 잡았습니다. 기존 자동화가 정해진 경로를 반복하는 방식이었다면, 이 계열은 화면을 이미지와 접근성 트리로 인식하고 목표를 향해 경로를 스스로 찾아 실행합니다. 주요 RPA 벤더들이 기존 제품군을 에이전틱 프로세스 자동화로 재편하고 있는 것도 같은 흐름입니다.
RPA와 무엇이 다른가
가장 큰 차이는 깨지는 방식입니다.
업무 성격으로 나누면 경계가 분명해집니다. 동일한 입력에 동일한 결과가 나와야 하는 결정론적 반복은 RPA가 유리하고, 서식이 제각각이고 예외 판단이 잦은 업무는 에이전트가 유리합니다.
비용 구조도 다릅니다. RPA는 초기 개발과 유지보수 공수에 비용이 실립니다. 화면이 분기마다 바뀌는 사이트라면 연간 유지보수가 최초 개발 공수를 넘기는 일도 흔합니다. 반면 에이전트는 건당 토큰과 실행 시간에 비용이 실립니다. 한 건에 30~60초, 수십 회의 화면 판단이 필요하다면 건당 비용은 수백 원대까지 올라갑니다. 월 200건이면 감당할 수 있지만 월 20만 건이면 계산이 완전히 달라집니다.
어떤 업무부터 붙일 것인가
적합한 조건
부적합한 조건
그리고 해당 시스템에 API가 생길 가능성이 있다면, 에이전트는 처음부터 '임시 다리'로 설계해야 합니다. 업무 로직을 에이전트 프롬프트 안에 녹여 두면 나중에 API로 갈아탈 때 전부 다시 만들어야 합니다. 로직은 우리 시스템에 두고, 에이전트에게는 화면 조작이라는 어댑터 역할만 맡기는 구조가 안전합니다.
권한과 감사 로그를 먼저 설계합니다
급할 때 가장 흔히 저지르는 실수가 담당자 계정을 그대로 에이전트에게 넘기는 것입니다. 이렇게 하면 감사 로그에 남는 행위자가 사람과 구분되지 않아, 사고가 났을 때 원인 추적이 불가능해집니다.
실패를 전제로 한 운영
에이전트는 반드시 멈춥니다. 화면 개편, 예상치 못한 팝업, 캡차, 세션 만료가 주된 원인입니다.
도입 순서
거창한 전사 계획보다 업무 1건으로 시작하는 편이 빠릅니다.
POLYGLOTSOFT는 AI 연계 시스템 개발 경험을 바탕으로, 에이전트와 사내 시스템 사이에 검증 계층을 두는 방식을 권장합니다. 에이전트가 화면에서 읽어 온 값을 바로 반영하지 않고, 업무 규칙 검증과 사람 확인 단계를 거쳐 들어오게 하는 구조입니다. 레거시 화면 자동화를 검토 중이시라면 대상 업무 선정부터 권한·감사 설계까지 함께 살펴보겠습니다. 부담 없이 문의해 주세요.