연동 없는 서비스에 AI로 일 시키는 방법과 이동 중 원격 업무

AI에게 일을 시키는 방식은 상당히 다양합니다. 요청을 입력해 문서 초안이나 작은 앱을 만들기도 합니다. 그 결과물을 어디에 쓸지도 각자 정리가 되어 갑니다.

다만 AI가 내가 쓰는 업무 도구까지 직접 조작하는지, 결과물을 내가 옮겨 넣어야 하는지는 다른 문제입니다. 분석 화면이나 보고서 대시보드에는 사용하는 AI에 바로 연결할 기능이 없는 경우가 있습니다. API는 다른 프로그램에서 기능을 호출하는 통로, MCP는 AI가 도구와 자료를 연결하는 공통 규약, CLI는 명령어로 프로그램을 조작하는 방식입니다. 이 중 하나가 없다고 해당 서비스의 모든 기능을 자동화할 수 없는 것은 아닙니다. 결과물을 만드는 일은 맡길 수 있어도, 그 결과물이 나오는 화면을 고치는 일은 여전히 사람이 해야 하는 영역으로 남아 있습니다.

이 글은 2026년 8월 제가 구성해 사용한 AI 자동화 사례입니다. 제품 하나를 설치하면 아래 과정이 모두 생기는 것은 아닙니다. 메일 확인, 이력 검색, 알림 전송과 브라우저 조작을 각각 연결한 구성이고, 처음에는 마지막의 작은 대조 연습부터 시작할 수 있습니다.

저에게 온 메일은 누가 먼저 읽을까요?

퇴근길 지하철에서 텔레그램이 울립니다. 고객사에서 메일이 왔고, 무엇을 묻고 있으며, 지난 이력상 어떤 맥락에 놓인 건인지가 정리되어 옵니다.
알림에는 확인한 요청과 답장 초안이 함께 들어 있습니다.

제가 따로 메일함을 연 적은 없습니다. 집에 있는 컴퓨터가 60초마다 메일함을 훑고, 새 메일이 발견되면 그것이 저에게 온 요청 건인지부터 판단합니다.
스팸, 행사 초대, 뉴스레터 등 답장을 해야 하는 메일이 아니면 조용히 넘어갑니다.

이런 메일들을 걸러 내는 쪽에 더 신경을 썼습니다. 알림이 잦으면 정작 중요한 메일을 놓치기 때문입니다. 그래서 당시에는 판단이 애매하면 알리지 않는 쪽으로 기울여 두었습니다. 이 기준은 불필요한 알림을 줄이는 대신 실제 요청을 놓칠 가능성도 높입니다. 처음 구성한다면 애매한 메일을 별도 확인 목록에 남기고 원래 메일함과 대조하는 방법부터 검토하는 편이 좋습니다.

제게 온 요청 건으로 판정되면 그때부터 관련 메일과 업무 이력을 찾습니다. 몇 년치 메일과 문서에서 관련 내용을 찾아 AI의 답변 자료로 주는 RAG(검색 증강 생성) 방식을 사용합니다. 검색할 자료를 미리 정리해 두고, 발신자 주소를 기준으로 관련 이력을 찾습니다. 담당자가 바뀐 경우를 고려해 이메일 주소의 회사 도메인으로도 검색합니다. 다만 같은 회사 자료라고 모두 같은 업무는 아니므로 프로젝트와 시점이 맞는지 대조해야 합니다. 그렇게 모은 맥락을 바탕으로 메일 초안을 만들고 저에게 알림을 보냅니다. 60초는 메일함을 확인하도록 정한 간격입니다. 검색과 초안 생성 및 알림 전송까지 매번 1분 안에 끝난다는 뜻은 아닙니다. 처리 시간은 자료량과 도구 상태에 따라 달라집니다.

그림은 당시의 처리 흐름입니다. 알림에서 제외된 메일이 항상 불필요한 것은 아니며, 그림 아래의 “발송만 사람이 합니다”는 제 역할 분담을 단순화한 표현입니다. 실제로는 권한과 수정 결과도 사람이 확인합니다.

원격으로 어디까지 할 수 있을까요?

제가 알림을 읽고 나면 초안이 그대로 괜찮은 경우와 확인할 것이 남은 경우가 있을 수 있습니다.

직접 확인이 필요한 내용이 있을 때 스마트폰으로 집에 있는 컴퓨터로 접속합니다. 서로 다른 두 기기는 VPN으로 같은 망에 묶어 두었습니다. 집 컴퓨터가 켜져 있고 양쪽의 인터넷과 원격 연결이 유지되면 밖에서도 접속합니다. 그리고 컴퓨터에 요청을 합니다.

방금 온 요청 메일 건을 확인해 줘. 메일에서 언급된 보고서 설정이 지금 어떤 상태인지 본 다음, 수정 요청 온 부분을 고쳐놔.

여기서부터는 집 컴퓨터가 알아서 합니다. 저는 화면을 계속 보고 있지 않습니다. 판단이 필요한 대목에서만 질문이 알람 형태로 올라옵니다.

제 구성에서는 이력 검색과 화면 조작을 연결했습니다. 벡터 검색은 문장을 숫자로 표현해 뜻이 비슷한 자료를 찾는 방법입니다. 모든 브라우저 작업에 벡터 검색이나 몇 년치 자료가 필요한 것은 아닙니다. 현재 화면의 설정만 확인할 때는 그 화면과 비교 기준부터 있으면 됩니다.

열쇠가 없는 건물은 어떻게 들어갈까요?

API나 전용 연동은 자동화에 자주 쓰이는 방법입니다. 정해진 출입구의 열쇠를 받아 들어가는 건물에 빗대어 볼 수 있습니다. AI 이전에도 화면 자동화는 있었으므로 이것만이 유일한 방식이었던 것은 아닙니다.

그런데 실무에서 쓰는 도구 중에는 그런 통로(MCP나 CLI)가 없는 것이 많습니다. 설정을 바꾸려면 사용자가 여전히 직접 로그인하고 화면을 보면서 클릭해야만 하는 서비스들입니다. 전용 출입구 대신 일반 출입구를 사용해야 하는 건물에 해당합니다.

하지만 AI가 컴퓨터를 조작하고 브라우저를 직접 조작하는 방식이라면 이 장애물을 넘을 수 있습니다. AI가 실제 브라우저를 띄우고, 화면 구조를 읽고, 버튼을 찾아 누르고, 입력창에 값을 넣습니다. 저 대신 정문으로 걸어 들어가 엘리베이터 버튼을 누르는 쪽에 가깝습니다.

그림의 “화면만 있으면”은 범위를 넓게 표현한 말입니다. 실제로는 브라우저 조작 기능이 있는 AI 도구, 로그인된 계정, 해당 작업 권한이 필요합니다. 일반 채팅창에 요청만 적어서는 화면을 클릭하지 못합니다. 화면 구성이 바뀌거나 추가 인증이 나오면 멈출 수도 있습니다. 공식 연동이 있으면 그 방법과 화면 조작의 안정성을 비교해 고릅니다.

로그인 화면이나 웹페이지에 적힌 지시가 사용자의 업무 지시를 대신해서는 안 됩니다. 예를 들어 보고서 안에 다른 사이트로 자료를 보내라는 문장이 있어도 실행 권한으로 취급하지 않습니다. Anthropic의 컴퓨터 사용 안내도 이런 외부 화면의 잘못된 지시와 조작 오류를 주의하도록 설명합니다.

AI는 화면에서 무엇을 어떻게 누를까요?

요청 온 메일에서는 보고서 설정 세 가지를 확인해 달라고 했는데, 기존 작업 이력만 봐서는 답할 수 없고 직접 브라우저 화면을 열어야 알 수 있는 것들이었습니다.

아래는 당시 작업 화면입니다. 목록 화면 다음에 나오는 붉은 네모는 AI가 확인하거나 수정한 부분을 표시합니다. 고객 정보와 수치는 가렸습니다.

목록을 열어 보니 그 보고서는 읽기 전용이어서 볼 수는 있어도 고칠 수는 없었습니다. 여기서 AI는 멈추고 묻습니다. 사본을 만들지, 편집 권한을 요청할지, 고치는 방법만 안내할지는 당사자가 결정해야 합니다. 어떤 원본을 누가 관리하는지와 상대에게 맡은 범위가 다르기 때문입니다.

네 개 탭의 설정을 하나씩 열어 읽었습니다. 반복해서 설정을 대조하는 작업입니다. 이 사례에서는 탭의 이름과 실제 필터 조건이 맞지 않는 부분을 찾았습니다. 설정 오류를 찾은 것과 결과 수치에 미친 영향을 확인하는 것은 별개입니다. 실제 영향을 확인하려면 같은 기간과 측정항목으로 수정 전후 결과를 비교해야 합니다.

필터를 바꾼 뒤에는 같은 보고서를 다시 열어 값이 저장되었는지, 요청한 탭만 달라졌는지 확인해야 합니다. AI의 완료 메시지는 이 대조를 대신하지 않습니다. 읽기 전용 원본에서 진행할 수 없다면 허용된 사본이나 권한이 있는 대상에서만 수정합니다.

발송은 왜 사람이 할까요?

확인이 끝나면 실제로 확인하거나 수정한 내용을 반영해 답장 초안을 갱신합니다.

제 구성에서 AI에게 맡긴 범위는 초안 작성까지이며 자동 발송은 하지 않습니다. 이 범위는 처음부터 정해 두었습니다. “발송하지 마”라는 지시와 실제 발송 권한 차단은 다르므로 사용하는 도구의 권한과 확인 기능도 살펴야 합니다. 발송된 메일을 회수할 수 있다고 보장할 수 없고, 문장의 수위나 일정 약속은 상대와의 관계에 따라 달라집니다. 반드시 초안을 읽고 고친 뒤에 보내야 합니다.

처음에는 가상 설정 두 줄만 대조해 봅니다

실제 메일함과 보고서를 한꺼번에 연결할 필요는 없습니다. 아래 가상 자료를 이미 쓰는 AI 채팅에 넣어, 요청과 현재 상태를 구분하는 연습부터 할 수 있습니다. 이 연습은 브라우저 조작이나 실제 저장을 검증하는 과정은 아닙니다.

확인할 답은 날짜가 같고 기기 조건만 다르며, 제안할 변경 값은 모바일이라는 것입니다. 이 자료만 읽고 실제 보고서를 수정했다고 답하면 안 됩니다. AI가 방문자 수나 매출까지 말하면 자료에 없는 내용입니다. 현재 기기 조건을 모바일로 바꿔 다시 물었을 때는 수정할 항목이 없다고 답해야 합니다.

이 대조를 이해한 뒤 화면 조작 도구가 이미 있다면, 본인 소유의 연습 보고서에서 설정 읽기만 먼저 맡겨 봅니다. 보고서 이름과 날짜, 조건이 실제 화면과 같은지 확인한 다음 필요한 변경 한 가지만 수행하고 다시 열어 저장 결과를 대조합니다. 다른 보고서를 열었거나 권한이 없으면 그 단계에서 멈추고 대상부터 바로잡습니다.

그래서 앞으로 사람은 무엇을 하게 될까요?

이렇게 몇 달을 지내보니 제가 하는 일의 성격이 바뀌었습니다.

그림은 반복 실행을 AI에게 맡기고 제가 판단에 더 시간을 쓰게 된 변화를 표현했습니다. 실행과 점검이 전부 사라졌다는 뜻은 아닙니다. 사본을 만들지 권한을 받을지, 첫 시도가 실패했을 때 무엇을 의심할지, 기준을 언제부터 바꿀지, 이미 나간 보고를 어떻게 할지를 여전히 사용자가 정해야 합니다.

한 가지 더 남는 것은 기록입니다. 한 번 헤맨 일은 다음에 또 겪게 되어 있습니다. 그래서 한 번 겪을 때마다 메모를 남겨 둡니다. AI가 대신 화면을 조작해도 어디서 막혔고 어떻게 해결했는지는 기록해 둡니다.

이 방식이 모든 업무에 필요한 것은 아닙니다. 만약 브라우저 화면을 직접 만지는 일이 적은 업무라면 굳이 이렇게까지 할 이유가 없습니다. 설정과 확인이 반복되는 일이라면 시간을 줄일 여지가 있습니다. 다만 구성과 유지보수, 잘못 처리한 일을 고치는 시간까지 비교해야 합니다. AI에게 어디까지 맡길지는 각자 다르게 정해질 수밖에 없습니다.

제 경험에서는 AI에게 맡길 실행 범위와 사람이 확인할 결과를 구분하는 일이 더 중요해졌습니다.

3줄 요약

1. 브라우저 조작 AI는 화면을 읽고 클릭하는 도구로 전용 연동이 없는 서비스의 일부 작업도 수행합니다.

2. 제 구성은 60초마다 메일을 확인하고 필요한 이력과 답장 초안을 알리지만, 확인 주기가 전체 처리 시간을 보장하지는 않습니다.

3. 자동화가 늘수록 사람이 쓰는 시간은 실행에서 권한과 기준, 발송 같은 판단 쪽으로 옮겨 갔습니다.