API 없어도 자동화된다 — 화면 조작형 AI 에이전트가 개발 판도를 바꾸는 이유

한줄 요약

API 없이도 화면을 조작하는 AI 에이전트, 외주 개발 수요 지형을 바꾼다.

본문

AI 에이전트의 새로운 유형이 등장하고 있다. 기존 자동화 도구처럼 API 연동에 의존하지 않고, 클라우드 가상 컴퓨터 위에서 사람처럼 화면을 직접 조작하는 방식이다. 지시는 메신저로 하고, 결과 보고도 대화로 돌아온다. 노트북을 꺼도 작업은 계속 돌아가며, 승인이 필요한 순간에만 사용자에게 물어온다.

이게 개발 업계 입장에서 단순한 신제품 소식으로 끝나지 않는 이유가 있다.

---

이 기술이 기존 자동화와 다른 게 뭔가

자동화 프로젝트를 외주 개발사에 의뢰할 때 가장 먼저 맞닥뜨리는 벽이 API다. 연동하려는 시스템이 API를 제공하지 않거나, 레거시 인프라라 문서조차 없는 경우 개발 비용과 기간이 급격히 불어난다. 기업용 그룹웨어, 오래된 ERP, 특정 공공 포털 같은 곳이 대표적이다.

화면 조작형 에이전트는 이 문제를 우회한다. API가 없어도 화면에 뭔가 보이면 조작할 수 있다. 사람이 마우스로 클릭하고 키보드로 입력하듯, 에이전트가 가상 데스크톱 위에서 똑같이 작동한다. 기술적으로 새로운 개념은 아니지만, 이걸 일반 사용자가 대화만으로 제어할 수 있는 수준까지 가져온 게 달라진 점이다.

외주 개발 관점에서 보면 두 가지 의미가 있다. 첫째, 자동화 가능한 업무의 범위가 넓어진다. 기존엔 API가 없으면 개발 자체를 포기하거나 화면 크롤링 방식의 고비용 커스텀 개발로 갔는데, 이 경계가 흐려지고 있다. 둘째, 일부 단순 반복 업무는 개발 없이 에이전트 설정만으로 해결되기 시작한다.

그럼 개발 외주 수요가 줄어드나

단기적으로는 그렇지 않다. 화면 조작형 에이전트가 잘 처리하는 건 정해진 패턴의 반복 업무다. 데이터 복사·붙여넣기, 정기 리포트 수집, 양식 제출 같은 것들. 이런 업무는 원래도 외주 개발의 핵심 타깃이 아니었다. 사람이 직접 하거나, 간단한 RPA 툴로 처리하던 영역이다.

반면 비즈니스 로직이 복잡하거나, 여러 시스템을 유기적으로 연결해야 하거나, 보안·데이터 주권 요건이 붙는 프로젝트는 여전히 전문 개발이 필요하다. 오히려 에이전트가 처리하지 못하는 영역의 윤곽이 더 선명해지면서, 외주 개발사에 오는 의뢰가 더 복잡하고 고도화된 쪽으로 이동할 가능성이 있다.

중장기적으로는 다른 얘기다. 에이전트 품질이 높아질수록 "개발로 만들 것"과 "에이전트로 처리할 것"의 경계를 판단하는 능력 자체가 외주 개발사의 경쟁력이 된다.

클라이언트 입장에서 뭘 판단해야 하나

화면 조작형 에이전트를 도입하려는 기업이라면 몇 가지를 먼저 확인해야 한다.

첫째, 보안이다. 에이전트가 클라우드 VM에서 돌아간다는 건, 회사 계정 접근 권한을 외부 클라우드에 위임한다는 뜻이다. 민감한 내부 시스템에 연결하기 전에 데이터 처리 위치와 접근 로그 확인 방법을 반드시 따져야 한다.

둘째, 예외 처리다. 에이전트는 정해진 시나리오 안에서 강하고 예외 상황에서 약하다. 화면 레이아웃이 바뀌거나, 예상치 못한 팝업이 뜨거나, 시스템 점검으로 로그인이 막히면 에이전트는 멈추거나 잘못된 동작을 할 수 있다. 이 실패를 누가, 어떻게 감지하고 복구하는지 설계가 없으면 자동화가 오히려 리스크가 된다.

셋째, 유지보수다. 에이전트가 의존하는 화면 구조가 바뀌면 다시 세팅해야 한다. 이게 서비스형 제품 안에서 자동으로 해결되는지, 아니면 관리자가 직접 손봐야 하는지 미리 확인해야 한다.

AI 에이전트 시대, 개발 외주를 맡길 때 달라지는 것

이제 개발 외주를 검토할 때 단순히 "이 기능을 개발해 줄 수 있냐"를 넘어서 "이게 개발이 맞냐, 에이전트 설정이 맞냐"를 같이 판단해 줄 수 있는 파트너인지를 봐야 하는 시기가 됐다.

좋은 외주 개발사라면 클라이언트의 업무를 분석해서 에이전트로 처리할 영역과 커스텀 개발이 필요한 영역을 구분해 줄 수 있어야 한다. 무조건 개발로 해결하려 하거나, 반대로 에이전트 하나로 다 된다고 과장하는 곳 모두 경계 대상이다.

AI 도구가 빠르게 바뀌는 만큼, 처음 설계를 잘 잡아두는 게 나중의 전환 비용을 줄인다. 지금 쓰는 도구가 1년 뒤에도 최선이리라는 보장이 없기 때문에, 특정 도구에 과도하게 종속되지 않는 구조를 잡는 것도 외주 개발사가 함께 고민해야 할 부분이다.