API 없는 웹 업무, AI가 화면을 눌러 연결합니다

업무 자료는 웹페이지에 있는데 연결할 API가 없어, 사람이 화면을 옮겨 다니며 입력하고 계신가요? Microsoft가 2026년 10월 19일 정식 출시한 Foundry의 Browser Automation Tool은 에이전트에 관리형 브라우저를 연결해 웹 탐색·내용 확인·폼 입력 같은 작업을 수행하도록 합니다. 다만 도구를 켜는 것만으로 사내 시스템 전체가 연결되지는 않습니다. 별도 Playwright Workspace와 접근 권한을 구성해야 하며, 비공개 웹사이트 탐색은 아직 Public preview입니다. Microsoft 공식 발표

API 연결이 끊긴 곳에서, 화면 조작을 이어갑니다

API는 다른 프로그램이 정해진 형식으로 정보를 읽거나 작업을 요청하는 통로입니다. 협력사 포털이나 오래된 업무 시스템에 이 통로가 충분하지 않으면, 자동화가 로그인 화면이나 입력 폼 앞에서 멈추기 쉽습니다.

이번 도구는 그런 웹 인터페이스를 에이전트가 다룰 수 있도록 브라우저 환경을 제공합니다. 공식 발표는 내부·외부 포털의 정보를 처리하거나, 공급사 사이트의 정보를 사내 애플리케이션으로 옮기는 작업을 예로 듭니다. 이는 Microsoft가 제시한 활용 시나리오이지, VECTORLOG가 직접 구현해 성과를 측정한 사례는 아닙니다.

작동 방식은 현재 페이지 관찰, 필요한 조작 선택, 실행, 실행 뒤 상태 확인의 반복입니다. 페이지가 다시 그려지거나 대화상자가 나타날 때도 현재 화면을 확인하며 진행하도록 설계됐습니다. 그렇다고 모든 사이트에서 성공하거나 사람이 하던 업무를 그대로 대체한다는 보장은 아닙니다. 작동 방식과 공식 시나리오

브라우저는 관리해 주지만, 연결 경계는 직접 정해야 합니다

Playwright Workspaces가 격리된 클라우드 브라우저 세션을 필요할 때 제공하므로, 에이전트 환경에 브라우저 실행 파일을 설치하고 직접 운영할 필요는 없습니다. 대신 Playwright Workspace를 별도 Azure 리소스로 준비해야 합니다.

Foundry에서는 도구를 묶어 관리하는 Toolbox에 Browser Automation을 추가하고, MCP 호환 엔드포인트로 Prompt agent나 Hosted agent에 연결할 수 있습니다. Toolbox는 여러 에이전트에 도구 구성을 재사용하는 경로이지, 각 업무에 필요한 접근 권한을 자동으로 판단해 주는 장치는 아닙니다.

Microsoft Learn은 비공개 웹사이트 탐색을 Public preview로 명시합니다. 사설 웹 애플리케이션에 접근하려면 Workspace 구성 과정에서 private network connectivity도 설정해야 한다고 발표는 안내합니다. 따라서 ‘사내 포털도 지원한다’와 ‘지금 우리 포털에 바로 접속된다’는 구분해야 합니다. 실제 네트워크·인증 구조와 지원 조건은 도입 환경에서 확인해야 합니다. 도입 문서

사람이 화면을 보고, 필요하면 직접 이어받습니다

이번 발표에서 실무적으로 중요한 부분은 Live View와 Take control입니다. Live View로 진행 중인 브라우저 화면을 볼 수 있고, Take control로 사람이 잠시 직접 조작한 뒤 에이전트에 제어를 돌려줄 수 있습니다.

예를 들어 입력값을 고르는 기준이 애매하거나 예상하지 못한 화면이 나타났을 때, 처음부터 전체 작업을 다시 실행하는 대신 상황을 확인하고 이어갈 수 있도록 하는 장치입니다. 다만 사람에게 제어를 넘길 수 있다는 기능과, 어떤 행동 전에 반드시 승인을 받도록 설정했는지는 별개의 문제입니다.

Microsoft는 민감하거나 상태를 바꾸는 행동에 승인 요구를 두고, 작업에 필요한 도구만 허용하며, 관리형 ID와 Azure RBAC로 최소 권한을 적용하도록 안내합니다. 처음에는 탐색·페이지 확인만 허용하고, 클릭·입력·업로드는 업무에 필요한 경우에만 열어 두는 접근입니다. 웹페이지의 내용은 신뢰할 수 없는 입력으로 취급해야 한다는 주의도 포함돼 있습니다. 통제와 사람 개입 기능

‘도구는 정식 출시’와 ‘주변 기능도 모두 정식 제공’은 다릅니다

Browser Automation Tool의 정식 출시와 별개로, 공식 글이 연결하는 민감한 추적 데이터 보호 절차는 Preview로 설명돼 있습니다. 로그에는 프롬프트·모델 응답·시스템 지시·도구 호출 인수와 결과처럼 민감한 내용이 들어갈 수 있습니다.

발표는 이런 생성형 AI 내용을 AppGenAIContent 테이블로 분리하고, 기본 접근을 차단한 뒤 Azure RBAC로 허용하는 문서를 안내합니다. 이 절차의 요구사항을 확인하지 않은 채 ‘브라우저 도구가 GA이므로 기록 보호도 검토가 끝났다’고 판단해서는 안 됩니다. 민감한 추적 내용 접근 제한

무료 제공이나 특정 월 비용도 이번 발표만으로 확정할 수 없습니다. Workspace와 모델 사용, 추적 데이터 등 실제 구성에 따른 비용을 별도로 확인해야 합니다. 개인정보가 있는 운영 화면을 첫 시험 대상으로 삼기보다, 비운영 자료로 흐름을 확인하는 편이 적절합니다.

작은 자동화 하나를 고른다면, ‘성공’보다 실패 경로부터 정합니다

VECTORLOG의 해석으로는 이번 변화가 특히 유용할 수 있는 곳은 API가 충분하지 않지만 작업 순서와 입력 기준은 비교적 명확한 웹 업무입니다. 여러 페이지를 넘나드는 자료 조회나 반복 입력이 후보입니다. 반면 결제·계약 확정·고객 대량 발송처럼 잘못 실행했을 때 되돌리기 어려운 단계는 별도 승인 경계가 필요합니다.

도입을 검토한다면 한 업무를 세 구간으로 나눠 보세요. 읽기만 하는 구간, 시스템 값을 바꾸는 구간, 사람 판단이 필요한 구간입니다. 각 구간에서 어떤 계정과 도구를 허용할지 정하면 ‘브라우저를 쓸 수 있는가’보다 구체적인 설계가 됩니다.

시험 기준도 미리 적을 수 있습니다. 로그인 만료 시 멈추는지, 같은 제출을 재시도할 때 중복 등록되지 않는지, 예상 밖 페이지에서 다른 링크로 진행하지 않는지, 완료 메시지와 실제 저장 결과가 맞는지를 확인하는 것입니다. 이는 권장 시험 항목이며, 이 기사에서 실제로 수행한 테스트 결과는 아닙니다.

예상 영향은 조건부입니다. 브라우저 환경을 직접 운영하는 부담과 API 부재로 끊긴 업무 연결을 줄일 가능성은 있지만, 화면 변경·인증 만료·승인 대기·로그 관리라는 운영 과제는 남습니다. 성공률과 처리 시간, 사람 개입 횟수를 시험에서 함께 기록해야 기존 방식보다 나은지 판단할 수 있습니다. API가 충분하고 안정적인 업무라면 굳이 화면 조작으로 바꿀 이유도 따져봐야 합니다.

이미 다룬 에이전트에게 별도 계정과 권한을 주는 문제와 완료 보고를 독립적으로 검증하는 원칙은 브라우저 자동화에도 이어집니다. 화면을 누를 수 있게 된 뒤의 질문은 같습니다. 어떤 행동을 허용했고, 실제로 무엇이 바뀌었으며, 그 결과를 누가 확인할 수 있을까요?

---

대표 출처: Microsoft Foundry Blog, 2026년 10월 19일 발표. 원문 확인: 2026년 10월 20일 KST. 직접 사용·성능 검증 없이 공개 발표와 문서를 정리한 News입니다.