_Originally published on NextFuture

Claude Code를 설정하여 에이전트가 Playwright를 통해 UI 테스트를 자동으로 실행하게 할 때, 즉시 선택해야 하는 것이 있습니다: Playwright MCP server를 설치할지, 아니면 에이전트가 이미 존재하는 셸을 통해 Playwright CLI를 직접 호출하도록 할지? 잘못된 방향을 선택하면 에이전트가 브라우저 조작의 각 단계마다 추가적인 토큰과 시간을 소모하게 될 수 있습니다. 이 글은 Dev.to 커뮤니티의 새로운 분석을 기반으로 두 가지 접근 방식을 직접 비교하여, 프로젝트 시작부터 올바른 것을 선택할 수 있도록 돕습니다.

Playwright MCP: 가장 익숙한 선택지

원문 기사에 따르면,

질문 "MCP 서버 vs CLI 직접 사용"은 Playwright에만 국한되지 않습니다. 같은 날 Dev.to에 올라온 다른 글에서 Postgres와 연결되는 MCP 서버 구축에 대해 다루며, 이 질문을 더 넓은 규모로 던지고 있습니다. 저자에 따르면, 실제 현장의 대부분의 MCP 서버는 "데이터베이스를 감싼 얇은 Wrapper일 뿐입니다 — 레코드를 찾고, 라인을 만들고, 필드를 수정하는 식"이며, 서버 자체는 "주로 JSON-RPC와 SQL 사이의 번역기 역할만 합니다". 저자는 역으로 질문을 던집니다. 만약 MCP 서버가 하루 종일 Postgres와 대화하는 것뿐이라면, 왜 항상 필요한 곳 바로 옆에서 실행되지 않는 걸까요?

두 글을 나란히 놓고 보면 같은 논리가 보입니다: 에이전트가 이미 직접적인 접근 권한(셸 또는 데이터베이스로의 내부 네트워크)을 가지고 있다면, 중간 MCP 서버 계층은 적절한 가치를 더하지 못하고 지연 시간과 운영 비용만 추가할 수 있습니다. MCP는 여러 에이전트/여러 클라이언트가 공유하는 도구를 표준화해야 할 때 여전히 올바른 선택이지만, 모든 상황의 기본 선택지는 아닙니다.

예시: agent가 Playwright CLI를 직접 호출하는 경우

# 중간 MCP 서버를 거치지 않고 shell 접근 권한을 가진 agent가 Playwright를 직접 호출하는 방식 예시
npx playwright test tests/checkout.spec.ts --project=chromium

이것은 Playwright의 일반적인 CLI 구문을 보여주는 예시일 뿐, 출처에서 인용한 것은 아니며 — MCP 도구를 통해 호출하는 것과의 차이를 상상하기 위한 것입니다.

그렇다면 언제 CLI를 선택하고, 언제 MCP를 유지해야 할까요?

위 두 글을 바탕으로 베트남 프로젝트에 적용할 수 있는 실용적인 가이드라인을 도출할 수 있습니다:

만약 Claude Code가 쉘 접근(shell access)이 가능한 환경(개발자 PC, 전용 CI runner 등)에서 실행된다면, Playwright CLI를 먼저 시도해 보세요. 중간 계층을 줄인다는 것은 각 단계마다 필요한 토큰과 지연 시간을 줄인다는 의미입니다.

만약 동일한 테스트 도구 세트를 여러 에이전트나 다른 클라이언트(Claude Code에 국한되지 않음)에게 노출해야 한다면, MCP 서버가 인터페이스를 표준화한다는 점에서 여전히 더 합리적일 수 있습니다.

MCP 서버 자체에 관해서는 (Playwright와 무관하게), 만약 해당 서버가 에이전트가 직접 접근할 수 있는 데이터베이스나 서비스와의 입출력 역할만 수행한다면, MCP 계층을 제거하고 에이전트가 직접 호출하도록 고려해 보세요.

이는 두 글의 논리를 바탕으로 한 일반적인 분석이며, 구체적인 벤치마크 수치는 아닙니다. 따라서 토큰/시간 절약에 대한 정확한 수치가 필요하다면, 설정을 완전히 변경하기 전에 실제 워크플로우에서 직접 측정하는 것이 좋습니다.

다음 단계

만약 팀이 Claude Code를 위해 Playwright MCP를 사용하고 있다면, 빠른 벤치마크를 시도해 보세요. MCP를 거쳐 실행한 테스트 스위트와 CLI를 통해 실행한 테스트 스위트를 모두 돌려보고, 설정을 변경하기 전에 토큰 수와 실제 시간을 비교하는 것이 좋습니다. 아울러 팀 내부의 다른 MCP 서버들도 검토하세요. 에이전트가 직접 호출할 수 있는 서비스 주변을 감싸는 얇은(wrapper) 서버라면, 중간 계층을 제거해 볼 첫 번째 후보입니다.

본 기사는 NextFuture에 원래 게시되었습니다. 더 많은 풀스택 및 AI 엔지니어링 콘텐츠를 원하시면 팔로우해주세요.