browser-use를 QA에 도입할까
며칠째 이어지던 QA Agent 구조 개편의 설계를 마무리한 날이었다.
browser-use라는 브라우저 자동화 도구를 검토하고 OpenCode를 오케스트레이션 계층으로 유지하면서 런타임 복잡도를 줄일 구조를 잡았다.
browser-use는 Python 기반 Playwright 자동화 라이브러리다.
브라우저를 제어하는 데 특화되어 있어서 QA Agent 브라우저 자동화를 이걸로 바꿀까 검토했다.
그 전까지 QA Agent는 Playwright MCP로 브라우저를 제어하고 있었다.
Playwright MCP는 프로바이더를 직접 호출할 수 있어서 내가 쓰는 LLM 프로바이더를 그대로 연결할 수 있다.
반면 browser-use는 자체 LLM 레이어를 가지고 있어서 OpenAI, Anthropic, Gemini API 키를 따로 넣어야 한다.
내가 쓰는 프로바이더를 직접 호출할 수가 없다.
QA 용도로는 Playwright MCP가 더 맞았다.
그래서 browser-use는 도입하지 않기로 했다.
browser-use는 나중에 다른 프로젝트에서 다시 검토하게 됐다. 뉴스 수집 파이프라인에서는 자체 LLM 레이어가 있어도 크게 문제가 없었기 때문이다.
그때 CDP 연동 관련 함정들을 꽤 많이 만났는데, 그건 다른 이야기다.
OpenCode를 오케스트레이션 계층으로
browser-use를 도입하지 않기로 하면서 런타임 전체를 갈아엎을 필요가 없어졌다.
OpenCode를 오케스트레이션 계층으로 유지하기로 했다.
OpenCode는 AI 에이전트 워크플로우 시스템이다.
여러 에이전트가 협력해서 작업을 처리하는 구조다.
플랫폼을 바꾸는 게 아니라, OpenCode 안에서 구조를 재정렬하는 방향으로 잡았다.
이건 “플랫폼을 교체하지 말고, 그 안에서 재구성하라”는 판단이었다.
런타임을 통째로 바꾸면 검증해야 할 게 너무 많아진다.
기존에 잘 돌아가던 걸 버리고 새 걸 만드는 건 리스크가 크다.
단일 함수에서 멀티 에이전트로
가장 큰 결정은 QA Agent를 단일 함수에서 멀티 에이전트 구조로 전환하는 계획이었다.
그 전까지 QA Agent는 QA 실행 함수이라는 단일 함수가 계획부터 실행, 리포팅까지 순차적으로 다
처리했다.
케이스가 적을 때는 문제가 없었다.
근데 케이스가 늘어나면서 한계가 드러났다.
병렬 실행도 어렵고 재시도 처리도 까다로웠고 상태 관리도 엉망이 됐다.
그래서 역할을 나누기로 했다.
Planner는 실행 계획을 세우고 Executor가 실제 테스트를 돌리고 Inspector가 막힌 케이스를 분석한다.
각 역할마다 전용 에이전트를 두는 구조다.
이 외에도 병렬 실행 워커인 Sub-executor, 결과 정리를 담당하는 Cleaner까지 여러 에이전트가 협력한다.
DAG 기반 스케줄링
테스트 케이스 간의 의존성을 DAG로 관리하기로 했다.
케이스들이 의존성 그래프를 이루고 Planner가 병렬 실행이 가능한 Lane을 찾아낸다.
하나의 케이스가 실패하면, 그 케이스에 의존하는 하위 케이스를 자동으로 막는 플래그도 만들었다.
이 멀티 에이전트 구조는 앞으로 3주에 걸쳐서 단계적으로 실행된다.
먼저 불필요한 도구를 정리하고 의존성 그래프를 단순화하고 마지막으로 역할 분리 구조를 완성하는 순서다.
컨텍스트 연속성 트레이드오프
이 멀티 에이전트 전환을 설계하면서 근본적인 고민이 하나 있었다.
병렬로 에이전트를 돌리면 컨텍스트가 단절된다는 거다.
Executor 네 개가 각자 격리된 프로세스로 돌면, 한 Executor가 알아낸 걸 다른 Executor가 모른다.
케이스 1.1에서 찾은 라우팅 경로를 케이스 1.4에서 쓸 수가 없다.
이걸 Fixture Knowledge라는 SQLite 저장소로 보완했다.
프로세스는 분리하되, 알아낸 지식은 데이터베이스에 저장해서 에이전트 간에 공유한다.
근데 이 트레이드오프는 생각보다 까다로운 문제였다.
병렬로 돌리면 컨텍스트가 단절되고 그렇다고 하나의 세션에서 순차로 돌리면 컨텍스트 윈도우가 넘쳐서 압축이 들어가고 압축이 들어가면 이전 케이스 컨텍스트가 날아간다.
연속성을 얻으려다가 오히려 잃게 되는 역설이다.
이건 약 석 달 뒤에 다시 나를 찾아올 문제였다.
마무리
이날 세 가지 결정이 전부 이어져 있었다.
browser-use는 내 프로바이더를 못 쓰니까 Playwright MCP를 유지하고 OpenCode를 플랫폼으로 두고 그 안에서 역할을 나눈 멀티 에이전트 구조로 전환하기로 했다.
멀티 에이전트 구조는 병렬 속도 이점을 가져다줬다.
근데 컨텍스트 단절이라는 새로운 비용을 만들어냈다.
이 비용은 Fixture Knowledge로 당장은 막았지만 근본적으로는 병렬성과 컨텍스트 연속성 사이의 트레이드오프 문제였다.
그리고 그 트레이드오프는 시간이 지나면서 점점 더 날카로워졌다.