얼마 전 저는 AI 에이전트가 Remote Debugging Protocol을 통해 Firefox를 조사하고 제어할 수 있게 해주는 MCP 서버를 작성했습니다. 이 프로젝트는 Mozilla 조직에 채택되었습니다. 이는 멋진 자랑거리이며 기쁘게 받아들이겠지만, 정작 더 유용한 이야기인 제가 이것을 '왜' 만들었는지는 가려지게 됩니다. 에이전트에게 브라우저를 주기 위해 만든 것이 아닙니다. 에이전트가 스스로 테스트를 작성하게 만들기 위해 만든 것입니다.

진짜 문제: 브라우징이 아니라 e2e 테스트

멀티 에이전트 오케스트레이션 (Multi-agent orchestration)은 어느 정도 다룰 수 있게 되었습니다. 저를 실제로 괴롭히고 저녁 시간을 갉아먹는 문제는 바로 엔드 투 엔드 (e2e) 테스트입니다. 아무도 작성하고 싶어 하지 않고, UI가 바뀌는 순간 부식(rot)되어 버리며, 바로 당신이 넘겨주고 싶어 할 법한 기계적이면서도 까다로운 작업의 전형입니다.

그래서 제가 실제로 관심을 두는 흐름은 다음과 같습니다:

1. Claude는 Firefox MCP를 사용하여 앱을 클릭하며 탐색하라는

서버에서 실행하기에 더 가볍습니다 (Leaner to run on a server). 저는 이것을 제 노트북에서 실행하지 않습니다. 이것은 Claude CLI나 Codex 세션, 그리고 그 외 다른 것들과 함께 서버에서 실행됩니다. 하나의 박스(box)에 여러 에이전트(agent)를 쌓아 올릴 때, 더 가벼운 헤드리스 브라우저 (headless browser)를 사용하는 것은 설치가 가능하느냐 아니면 교체해야 하느냐의 차이를 만듭니다. 그리고 제 설정에서는, 헤드리스 Firefox (headless Firefox)가 더 가벼운 선택지입니다. (본인의 환경에서 직접 측정해 보세요. 무엇을 로드하느냐에 따라 달라집니다.)

오픈 소스입니다 (It's open source). 제가 직접 구축한 인프라에서 실행하고 마음대로 만져보고 싶은 대상이라면, 이 점은 그 자체로 충분한 설명이 됩니다.

이것이 일반적인 MCP 서버에 대해 시사하는 점

이 과정을 통해 제가 계속해서 얻는 결론은 다음과 같습니다: 최고의 MCP 서버는 워크플로우 (workflow)를 위한 스캐폴딩 (scaffolding)이지, 영구적인 부속물이 아닙니다. Firefox MCP는 에이전트가 흐름을 학습하고 이를 실제 테스트로 코드화하는 데 걸리는 몇 분 동안 가장 가치 있습니다. 그 이후에는 일반적인 playwright test 명령어가 그 역할을 수행합니다: 에이전트도, MCP도, 토큰 (token)도 필요 없습니다.

그렇게 설계하는 것(