browser-use와 streamlit을 활용한 웹앱 테스트 자동화 도구 구현
안녕하세요. 지난주에 MCP를 활용하여 웹 서비스 테스트 자동화 가능성에 대해 공유한 적이 있습니다. 그때 excel-mcp-server와 mcp-browser-use 같은 MCP 도구들을 중심으로, AI 기반 테스트 자동화의 가능성에 대해 알아봤습니다.
오늘은 새로운 프로젝트인 AutoBrowserTester를 공유해 드리려고 합니다. 이 프로젝트는 MCP 도구를 테스트해보며 그 한계를 느끼고, 대신 browser-use 와 streamlit 을 활용해 간단한 웹앱 테스트 자동화 도구를 구현한 프로젝트입니다.
AutoBrowserTester: browser-use와 streamlit으로 구현한 테스트 자동화 도구
AutoBrowserTester 프로젝트는 처음 계획했던 완전한 구현은 아니지만, browser-use를 활용하여 웹 브라우저를 제어하고 streamlit으로 간단한 웹 인터페이스를 구축해 테스트 자동화의 기본 개념을 보여주는 프로젝트입니다.
이 프로젝트는 웹 브라우저의 다양한 동작을 자동화하고, 기본적인 테스트 시나리오를 실행할 수 있는 기능을 제공합니다.
프로젝트 소스 코드는 다음 GitHub 저장소에서 확인할 수 있습니다.
* GitHub 저장소: https://github.com/jeongsk/AutoBrowserTester
이 저장소에는 browser-use를 활용한 브라우저 자동화 방법과 streamlit으로 구현한 간단한 웹 인터페이스 코드가 포함되어 있습니다. 코드를 살펴보면 browser-use를 통해 웹 페이지 열기, 요소 클릭, 텍스트 입력 등의 기본적인 브라우저 작업을 어떻게 자동화하는지 이해하는 데 도움이 될 것입니다.
프로젝트의 실제 작동 모습은 다음 유튜브 링크에서 확인할 수 있습니다.
* 데모 영상: https://www.youtube.com/watch?v=b7mGRdDSs4Y
영상에서는 AutoBrowserTester가 browser-use를 통해 웹 브라우저를 제어하며 자동화된 테스트를 수행하는 과정을 보여줍니다. 처음 구상했던 MCP 기반의 완전한 구현은 아니지만, 웹 테스트 자동화의 기본 개념과 가능성을 보여주는 좋은 사례입니다.
한계점과 고려사항
이 프로젝트를 개발하고 테스트하면서 몇 가지 중요한 한계점을 발견했습니다:
1. LLM의 예측 불확실성 (할루시네이션 포함)
LLM은 주어진 테스트 시나리오 설명을 바탕으로 테스트 절차를 생성할 때, 때때로 설명을 잘못 해석하거나 사실과 다른 내용을 생성하는 할루시네이션 현상을 보일 수 있습니다. 이로 인해 예상치 못한 동작이나 잘못된 테스트 수행으로 이어질 가능성이 있습니다.
이 위험을 줄이려면 LLM에게 입력하는 테스트 시나리오 설명이 매우 명확하고 구체적이어야 하며, 모호하게 해석될 여지를 최소화해야 합니다. 즉, 상세하고 잘 정의된 테스트 케이스 작성이 더욱 중요해집니다.
2. 프롬프트 엔지니어링의 난이도
LLM이 의도한 대로 정확하게 동작하는 자연어 프롬프트를 설계하고 최적화하는 작업은 생각보다 훨씬 어렵습니다. 효과적인 프롬프트를 개발하는 것은 상당한 기술과 반복적인 실험이 필요하며, 시간과 노력이 많이 드는 과제입니다.
3. 엘리먼트 식별의 어려움 (비표준/동적 UI)
웹 페이지가 시맨틱 HTML 구조를 따르지 않거나, 사용자 상호작용에 따라 구조가 동적으로 크게 변경되는 복잡한 웹사이트의 경우, LLM이 자연어만으로 정확한 UI 요소(버튼, 입력 필드 등)를 안정적으로 식별하고 상호작용하는 데 어려움을 겪는 경우가 자주 발생합니다.
이에 대한 대응 방안으로는 웹사이트 개발 시 웹 표준 및 시맨틱 마크업을 준수하는 것이 근본적인 해결책이 될 수 있습니다. 또한, 한계 상황에서는 LLM에게 명시적인 CSS 선택자나 XPath 같은 정보를 프롬프트에 함께 제공하여 요소 식별 정확도를 높이는 접근 방식을 고려할 수 있습니다.
프로젝트 개발 과정에서 느낀 점과 향후 발전 방향
MCP 도구는 매우 유용하지만 점점 한계를 느끼고 있습니다. 그래서 browser-use와 streamlit이라는 더 직접적이고 제어 가능한 도구를 선택했습니다. 이러한 경험을 통해 알게 된 몇 가지 중요한 점들이 있습니다:
* 현실적인 도구 선택의 중요성: 아직 발전 중인 기술인 MCP보다 현재 안정적으로 사용 가능한 도구를 선택하는 것이 실용적인 프로젝트 구현에 더 효과적일 수 있습니다.
* 단계적 자동화 접근: 완전한 AI 주도 테스트보다는 기본적인 브라우저 자동화부터 시작해 점진적으로 지능형 요소를 추가하는 접근 방식이 더 현실적입니다.
* 사용자 인터페이스의 중요성: streamlit을 활용한 간단한 웹 인터페이스는 테스트 자동화 도구를 더 접근하기 쉽고 사용하기 편리하게 만듭니다.
이 프로젝트는 앞으로 다음과 같은 방향으로 발전할 수 있을 것입니다:
* 더 다양한 브라우저 작업 지원: 현재 기본적인 작업 외에도 더 복잡한 브라우저 상호작용을 지원하도록 확장
* AI 요소의 점진적 통합: 단순한 브라우저 자동화를 넘어, 테스트 결과 분석이나 테스트 시나리오 생성에 AI를 활용하는 기능 추가
* 테스트 결과 보고 기능 강화: 테스트 실행 결과를 더 상세하고 가시적으로 보여주는 보고서 생성 기능
마치며
지난주에 MCP 기반 웹 서비스 테스트 자동화 개념을 공유했지만, 실제 구현 과정에서는 MCP 도구의 한계를 느끼고 browser-use와 streamlit을 활용한 더 직접적인 접근 방식을 선택했습니다. 이렇게 만든 AutoBrowserTester 프로젝트와 데모 영상을 통해, 웹 테스트 자동화의 가능성을 엿볼 수 있습니다.
이 프로젝트가 웹 테스트 자동화 분야에서 현실적인 접근 방식을 모색하는 데 도움이 되길 바랍니다. GitHub 저장소를 살펴보시고, 데모 영상을 통해 browser-use와 streamlit을 활용한 자동화가 어떤 모습인지 확인해 보세요. 비록 처음 구상했던 시스템의 완전한 구현은 아니지만, 이러한 경험과 실험은 더 발전된 테스트 자동화 도구를 개발하는 데 중요한 밑거름이 될 것이라고 생각합니다.
참고 자료
이 프로젝트를 개발하는 과정에서 다음 글에서 많은 인사이트를 얻었습니다:
- Automating 44 E2E Tests with AI-Powered Browser Control for Under $1