들어가며

많은 회사에는 이름은 조금씩 달라도 꼭 하나쯤 있는 ‘그 프로그램’이 있습니다. 10년 넘게 써온 자체 개발 ERP나 구형 발주·정산 프로그램, 혹은 거래처마다 제각각으로 만들어 둔 외부 협력사 포털 같은 것들 말이죠. 만약 해당 업무에 바로 쓸 수 있는 연동 규격(API)이 열려 있지 않고 당시 프로그램을 짰던 담당자까지 바뀌거나 퇴사해 시스템을 선뜻 고치기 어려운 상황이라면 어떨까요? 회사의 핵심 데이터는 여전히 그 안에 들어 있으니 매일 아침 실무자들이 이메일과 엑셀 창을 나란히 띄워 놓고 똑같은 숫자와 문자를 손으로 옮겨 적게 됩니다.

구매팀 직원이 거래처에서 온 납기 변경 요청 메일을 읽고 API가 없는 사내 발주 프로그램 화면을 열어서 품목과 수량을 일일이 입력했다고 가정해봅시다. 화면 입력은 끝났고 분명히 저장 버튼도 눌렀는데 화면이 잠시 멈추더니 접수 번호가 보이지 않습니다. 숙련된 직원은 여기서 저장 버튼을 무작정 다시 누르지 않습니다. 자칫하면 똑같은 발주가 두 번 들어간다는 걸 알기 때문에, 먼저 발주 조회 화면으로 넘어가 방금 입력한 내역이 반영됐는지부터 확인하죠.

최근 AI 공급사들의 데모 영상을 보면, AI가 사람처럼 직접 컴퓨터 화면을 보고 마우스를 움직여 버튼을 클릭하고 키보드로 글자를 입력합니다. 이른바 ‘컴퓨터 사용(Computer Use)’ 기술입니다. 경영진 입장에서는 솔깃할 수밖에 없습니다. 시스템을 새로 개발하거나 API를 뚫지 않고도 AI에게 저 프로그램을 그대로 맡길 수 있을 것처럼 보이기 때문입니다.

AI가 API 없는 사내 프로그램을 화면으로 조작하는 것은 기술적으로 가능합니다. 하지만 화면 속 버튼을 누를 수 있다는 사실과, 앞서 본 구매팀 직원처럼 예외 상황에서 사고를 막으며 실무를 완수할 수 있다는 것은 전혀 다른 이야기입니다. 지금부터 컴퓨터 사용 기술이 어떻게 작동하는지, 기존 자동화 도구와는 무엇이 다른지, 그리고 우리 회사에서 가장 먼저 안전하게 맡길 수 있는 업무 구간은 어디인지 알아보겠습니다.

화면을 보고 조작한다는 것의 정확한 의미

우리가 현업에서 “저 구형 프로그램은 API가 없어서 AI를 못 붙인다"라고 말할 때, 정확히 무엇이 없다는 뜻일까요? AI 모델을 부르는 API나 화면 실행 도구가 없다는 뜻이 아닙니다. 우리가 다루는 대상 업무 프로그램 쪽에 외부 시스템과 데이터를 주고받을 공식 연결 통로가 없다는 뜻입니다. 연결 규격이 있는 시스템끼리는 정해진 양식으로 요청과 응답을 주고받지만 구형 프로그램은 오직 사람이 보는 모니터 화면과 마우스·키보드만 열어 두고 있습니다.

컴퓨터 사용(Anthropic 컴퓨터 사용 도구 문서 )은 이 화면을 새로운 연결 경로로 삼는 방식입니다. 세 단계를 반복하며 작동합니다. 먼저 실행 환경이 현재 화면을 이미지(스크린샷)로 찍어 AI 모델에게 전달합니다. 모델은 화면 이미지를 해석해 어느 위치를 클릭할지, 무슨 글자를 입력할지, 화면을 스크롤할지 다음 행동을 선택합니다. 실행기가 그 지시대로 마우스와 키보드를 조작하면 바뀐 화면을 다시 찍어 모델에게 보여줍니다. 모델은 이 화면을 보고 다음 행동을 결정합니다. 이렇게 관찰과 실행의 루프를 이어갑니다(OpenAI Computer-Using Agent 발표 ).

이해하기 쉽게 우리 부서에 오늘 막 파견 온 신입 직원을 떠올려 봅시다. 사내 전산망을 뜯어고쳐 별도의 연동 통로를 만들어 줄 수는 없지만 신입 직원에게 PC 한 대를 내어주고 화면을 눈으로 보면서 일하게 할 수는 있습니다. 컴퓨터 사용이 일하는 방식이 바로 이렇습니다. 다만 화면이라는 새로운 연결 경로가 생겼다고 해서 기존 계정의 권한이나 회사의 업무 규칙까지 달라지는 것은 아닙니다. AI 모델이 다음 행동을 제안하더라도 실제 권한과 실행 환경은 애플리케이션을 운영하는 회사 쪽에서 제공합니다.

이 기능의 현재 성숙도를 두고 아직은 전부 실험실 연구용이라고 묶어 보는 것도 정확하지 않습니다. 마이크로소프트는 2026년 5월 코파일럿 스튜디오(Copilot Studio) 변경 이력에 컴퓨터 사용의 일반 제공(GA)을 기록했습니다(Microsoft Copilot Studio 변경 이력 ). 이제 기업들이 정식 기능으로 도입해 쓸 수 있습니다. 다만 제품의 일반 제공 여부는 구매와 사용 가능성에 관한 정보일 뿐, 우리 회사 고유 업무를 무인으로 맡겨도 될 만큼 신뢰도가 확보됐다는 측정값은 아니므로 별도의 검증이 필요합니다.

API 연동, 기존 RPA와 무엇이 다를까요?

이 설명을 들으면 많은 임원분들이 기존에 도입했던 RPA(로보틱 프로세스 자동화)를 떠올리십니다. “화면을 대신 눌러주는 거라면 RPA와 무엇이 다른가? 이제 RPA를 대체하면 되는가?“라는 질문이 자연스럽게 따라오죠.

우선 기존 RPA를 모니터의 고정 좌표만 녹화해서 누르는 단순 매크로로 묘사하면 부정확합니다. 마이크로소프트 파워 오토메이트(Power Automate) 같은 실제 RPA 도구는 고정 좌표나 이미지만 보지 않습니다. 창 내부의 버튼이나 입력칸 같은 UI 요소와 선택자(Selector)를 식별해 작동합니다(Microsoft Power Automate UI 요소 문서 ). 업무 절차와 화면 구조가 일정한 환경에서는 미리 정의한 단계와 규칙에 따라 안정적으로 움직입니다. 반면 화면 기반 컴퓨터 사용은 현재 화면 이미지를 해석해 다음 행동을 결정합니다. 그래서 사람이 읽을 수 있는 화면이라면 비정형 문맥이나 화면 변화를 읽고 대응할 여지가 넓습니다(Microsoft Copilot Studio 컴퓨터 사용 문서 ).

하지만 공급사가 설명하는 화면 변경 적응 기능을 두고 화면이 어떻게 바뀌든 알아서 안전하게 처리한다고 단정해서는 안 됩니다. 버튼 위치가 달라졌을 때 의미를 읽고 다시 찾을 가능성과, 업무적인 의미까지 달라진 변경을 안전하게 처리하는 것은 별개의 문제이기 때문입니다. 예를 들어 구매 요청 화면의 ‘저장’ 버튼이 시스템 개편 후 ‘저장 후 발주’로 바뀌었다면 어떨까요? 위치를 잘 찾아서 누르는 것만으로는 충분하지 않습니다. 원래 허용한 작업이 초안 저장이라면 외부 발주까지 진행해서는 안 됩니다. 이때 필요한 것은 버튼 재탐색이 아니라 행동 범위의 재확인입니다.

유지·검증 부담도 서로 다릅니다. 예를 들어 API 통합에서는 인터페이스 규격과 인증, 버전 변경, 재시도 규칙이나 응답 성공과 실제 업무 완료의 일치 여부 등을 관리해야 합니다. RPA에서는 선택자와 분기·대기·예외 처리를 유지해야 하죠. 컴퓨터 사용에서는 화면 관찰 오류와 판단 편차, 호출 시간, 완료 판정까지 관리해야 합니다. 따라서 실제 도입에서는 세 방식을 배타적으로 고르기보다 업무 특성에 맞춰 섞어 쓰고 비교 시험으로 판단해야 합니다. 공식 API가 있으면 안정성과 검증 가능성을 먼저 비교하고 API가 없고 절차가 일정하면 기존 RPA와 건당 추론·예외 처리 비용을 비교합니다. 화면 해석이 꼭 필요한 구간만 AI에 맡기고 나머지 조회·계산·검증은 구조화된 수단으로 처리하는 혼합 구성을 검토하는 편이 타당합니다.

공개된 도입 사례가 보여주는 현실적인 결합 방식

실제 기업들은 이 기술을 어디에 어떻게 배치하고 있을까요? 문서화된 공개 사례 속 기업들은 순수 화면 조작만으로 API 없는 기업 레거시 전체를 무인 운영하는 대신 구조화된 사전 검증과 사람의 검토를 결합하고 있습니다.

대표적인 예가 마이크로소프트가 공개한 임직원 이전 서비스 기업 그레이벨(Graebel)의 고객 사례입니다(Microsoft가 공개한 Graebel 도입 사례 ). 그레이벨은 고객과 파트너가 다양한 형식으로 보내는 서비스 요청 이메일을 읽어 사내 플랫폼인 ‘글로벌커넥트(globalCONNECT)‘에 입력해야 했는데 이 플랫폼에는 해당 업무에 쓸 수 있는 API가 없었습니다.

그레이벨은 화면 입력 앞뒤에 검증과 사람 검토를 두도록 설계했습니다. 지정된 메일함에 들어온 이메일 자료를 먼저 구조화해 추출하고 사내 서비스 로직과 규정 준수 규칙을 검증한 뒤에야 컴퓨터 사용 기능으로 글로벌커넥트 UI에 데이터를 입력합니다. 특히 신뢰도가 낮거나 예외가 발생한 건, 그리고 승인이 필요한 건은 자동으로 밀어붙이지 않고 사람 검토자에게 보냅니다. 또한 처음부터 모든 주문에 전면 배포한 것이 아니라 일부 고빈도 서비스 주문 유형을 대상으로 한 파일럿으로 시작했습니다.

보조 사례인 리플릿(Replit)의 앱 검증 구현에서도 비슷한 방식을 볼 수 있습니다(Replit의 자동 자체 테스트 기술 블로그 ). 리플릿은 생성된 앱을 시험할 때 스크린샷과 클릭에만 의존하지 않고 코드 실행과 브라우저 자동화(Playwright), 화면 관찰에 더해 읽기 전용 데이터베이스 조회와 로그 확인을 결합합니다. 화면이 겉보기에 그럴듯한 것과 실제 기능이 제대로 작동하는 것을 구분하려면 결과 상태를 읽어야 합니다. 코드나 데이터베이스 접근이 없는 레거시 프로그램에서 똑같은 검증 강도를 얻기는 어렵지만 화면 조작 앞뒤에 검증 경로와 사람 검토를 붙여야 한다는 원칙만큼은 이 사례도 분명하게 보여줍니다.

실무에 투입하기 전 반드시 설계해야 할 네 가지 안전장치

파견 온 신입 직원에게 업무용 PC를 맡길 때 첫날부터 대표이사의 공동인증서나 최종 결재권을 주지 않듯, 컴퓨터 사용을 사내 업무에 연결할 때도 네 가지 운영 안전장치를 먼저 설계해야 합니다. 무엇을 바꿀 권한이 있는가, 누가 승인하는가, 같은 작업을 두 번 하지 않았는가, 실제 저장 결과를 어디서 확인할 것인가의 문제입니다.

첫째는 인간 로그인과 최소권한 실행 환경입니다. 모델에게 직원의 비밀번호를 직접 넘기거나 모든 사내망이 열려 있는 PC에서 돌아가게 두어서는 안 됩니다. 공식 문서에서도 전용 최소권한 환경에서 실행할 것을 권고합니다(Anthropic 컴퓨터 사용 도구 문서 ). 로그인이나 인증은 사람이 직접 마친 뒤 세션을 넘겨주거나, 애초에 조회와 초안 입력만 허용된 전용 계정을 부여해 권한의 울타리를 쳐야 합니다. 로그인에 성공했다는 사실과 개별 거래를 승인했다는 것은 철저히 구분해야 합니다.

둘째는 화면 속 외부 지시 위험과 인간 승인입니다. 거래처가 보낸 이메일이나 화면 속 메모란에 작업 지시를 왜곡하는 문구가 적혀 있다면, 화면을 읽는 AI가 이를 원래 업무 지시로 오인해 허용되지 않은 행동을 시도할 위험이 있습니다. 이때 AI 모델이 스스로 위험을 감지해 사람에게 확인을 요청하는 기능만 믿어서는 충분하지 않습니다. 마이크로소프트는 감독 문서와 FAQ에서 모델 기반 확인 요청이 필요한 모든 순간에 발생한다고 보장하지 않습니다. 추가 통제와 최소권한 환경이 필요하다고도 안내합니다(Microsoft Copilot Studio 인간 감독 문서 , Microsoft Copilot Studio 컴퓨터 사용 FAQ ). 외부 발송이나 자금 이동 같은 중요한 결정은 모델의 재량이 아니라 시스템 규칙으로 멈추고 사람이 승인하게 만들어야 합니다.

셋째는 중복 제출 위험의 관리입니다. 물론 API 연동에서도 중복 요청을 막으려면 별도의 식별 키나 중복 방지 설계를 넣어야 합니다. 하지만 화면만 조작하는 환경에서는 요청 처리 상태나 멱등성(같은 요청을 여러 번 보내도 한 번만 반영되는 성질)을 확인할 수단이 더욱 부족해 한 번만 정확히 처리되는 것(exactly-once)을 보장하기 어렵습니다. 제출 버튼을 누른 뒤 화면 응답이 없을 때 AI가 다시 버튼을 누르면 똑같은 주문이 두 번 들어갈 수 있습니다. 따라서 운영 설계 차원에서 제출 전 기존 등록 여부를 먼저 조회하게 하고 제출 클릭은 한 번으로 제한해야 합니다. 응답이 지연되거나 불분명할 때는 재클릭 대신 조회 화면으로 이동해 확인하거나 사람에게 인계하는 절차도 두어야 합니다.

넷째는 결과 상태 검증입니다. 신입 직원이 “다 입력했습니다"라고 말해도 실제 시스템에 접수 번호가 생성됐는지는 별개로 확인해야 하듯, AI가 버튼을 눌렀다고 해서 업무가 완료된 것은 아닙니다. 입력 작업 뒤에는 생성된 업무 키나 접수 번호를 조회 화면이나 감사 기록에서 다시 읽어 들여 실제 결과 상태가 정상 반영됐는지 재조회하는 단계를 반드시 포함해야 합니다.

우리 회사에서는 어떤 좁은 업무부터 맡겨야 할까요?

이 네 가지 안전장치를 놓고 보면 처음부터 사내 프로그램 전체를 AI에게 통째로 맡기는 접근이 왜 위험한지 드러납니다. 도입 성공률을 높이려면 단위를 ‘프로그램 전체’가 아니라 ‘시작 조건과 완료 조건이 명확하고 되돌릴 수 있는 업무 한 구간’으로 잡아야 합니다. 특히 초안 입력(Draft)과 되돌릴 수 없는 최종 제출(Submission)을 분리하는 순간 도입의 문턱이 크게 낮아집니다.

가장 먼저 맡길 만한 구간은 원본 데이터를 바꾸지 않는 조회와 자료 대조입니다. 예를 들어 매일 여러 협력사 포털이나 API 없는 구형 프로그램 화면을 열어 입고 수량을 확인하고 사내 정산 내역과 숫자가 맞는지 대조해 불일치 항목만 정리하는 업무가 그렇습니다. 화면 값을 잘못 읽어 후속 판단이 틀어지거나 민감한 정보가 노출되지 않도록 접근 범위는 관리해야겠죠. 적어도 원본 시스템에 잘못된 데이터를 덮어쓰는 위험은 줄일 수 있어 초기 정확도를 검증하기에 적합합니다.

그다음으로 넓힐 수 있는 구간은 입력 초안 작성입니다. 이메일이나 첨부 문서에서 읽은 정보를 바탕으로 사내 프로그램의 입력 칸을 채우되, 최종 등록이나 외부 발송 직전의 ‘임시 저장’ 상태까지만 AI에게 맡기는 것입니다. 또는 운영 시스템과 분리된 테스트 환경에서 테스트용 데이터를 가지고 사내 프로그램 업데이트 후 화면 기능이 정상 작동하는지 살피는 내부 테스트 업무 역시 좋은 첫 후보가 됩니다.

되돌릴 수 있는 초안 작성과 되돌릴 수 없는 확정·승인을 이렇게 분리하면 조직의 수용 방식이 완전히 달라집니다. 실제 계정 권한과 화면 설정에서 AI가 최종 확정이나 외부 전송을 직접 실행하지 못하게 막아 둡니다. 실무자는 빈 화면에 수십 개 항목을 일일이 타이핑하는 대신 AI가 채워 넣은 초안에서 금액·수량·거래처 같은 핵심 항목을 대조해 확인한 뒤 승인 여부를 결정합니다. 이렇게 하면 잘못된 최종 반영 위험을 낮추면서 현업의 반복 입력 손품을 줄일 수 있습니다. 사람이 초안을 수정하거나 예외를 처리한 기록을 바탕으로 적용 범위를 단계적으로 넓혀갈 수도 있습니다.

나가며

결국 “API 없는 사내 프로그램도 AI가 사용할 수 있을까?“라는 질문의 답은 기술 데모 화면이 아니라 우리의 운영 설계 안에 있습니다. 도입 판단의 기준은 ‘AI가 화면 속 버튼을 누를 수 있는가’에서 ‘허용된 권한 안에서 정확하게 끝났는지 확인하고, 실패했을 때 안전하게 복구할 수 있는가’로 옮겨가야 합니다.

우리 회사에 적용을 검토하신다면 시작 조건과 완료 조건, 그리고 예외 인계 조건이 명확한 작은 업무 하나를 먼저 골라보시기 바랍니다. 공식 API나 기존 RPA로 풀 수 있는 구간은 구조화된 수단에 맡기고 화면 해석이 꼭 필요한 조회·대조·입력 초안 구간부터 시험한 뒤, 확인이 끝난 완료 건당 총비용과 사람 개입 시간을 기준으로 확대 여부를 결정하는 편이 좋습니다.

우리 조직의 레거시 프로그램 업무 중 어디를 첫 적용 구간으로 잡아야 할지, 로그인·승인·중복 방지·완료 재확인 절차를 어떻게 설계해야 실무에서 안심하고 운영할 수 있을지 고민되신다면 언제든 엡실론델타와 상의해 주시기 바랍니다. 현업 업무 분석부터 우리 환경에 맞는 에이전트 비교 시험과 운영 설계까지, contact@epsilondelta.ai 로 메일 주시면 여러분 조직을 위해 가장 실질적인 해법을 함께 찾겠습니다.