지금까지 쓴 n8n-MCP는 API로 인스턴스에 직접 데이터를 써 넣는 방식이었습니다. 빠르고 저렴하지만, 결국 '보이지 않는 뒷문'으로 워크플로우를 만드는 셈이죠. 이번 강의에서는 전혀 다른 접근, 즉 에이전트가 '진짜 브라우저'를 사람처럼 조종하게 하는 Playwright MCP를 소개합니다.
Playwright MCP = 손이 달린 에이전트
Playwright는 원래 브라우저를 자동으로 조작하는 도구입니다. 이것을 MCP로 연결하면, Claude Code가 실제로 브라우저 창에서 n8n을 열고, 노드 메뉴를 검색하고, 노드를 끌어다 놓고, 모델 설정을 클릭하는 등 '사람이 마우스로 하는 일'을 그대로 흉내 냅니다. n8n-MCP가 뒷문으로 조용히 쓰는 것이라면, Playwright MCP는 앞문으로 들어와 화면 앞에 앉아 직접 클릭하는 직원입니다.
두 갈래 접근 — API 직통 vs 브라우저 조종
n8n-MCP = API 직통 (뒷문)
- Claude Code가 API 호출로 n8n 인스턴스에 노드 직접 생성
- 빠름
- 토큰 저렴
'짓기'에 최적
Playwright MCP = 브라우저 조종 (앞문)
- Claude Code가 클릭/드래그로 🖥️ 실제 브라우저의 n8n 화면 조작
- 사람처럼 조작
- 느림 · 토큰 많이 씀
'테스트·검증'과 'UI로만 되는 일'에 최적
같은 목적지(n8n)로 가는 두 길입니다. 하나는 뒷문 API, 하나는 앞문 브라우저. 속도·비용·용도가 서로 다릅니다.
설정: mcp.json + 역할 부여
설정은 n8n-MCP 때와 똑같이 mcp.json에 Playwright MCP 항목을 추가하는 것으로 시작합니다.
mcp.json — Playwright MCP 추가
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["@playwright/mcp@latest"]
}
}
}그리고 CLAUDE.md에 에이전트의 역할을 정해 줍니다. 어느 n8n 주소를 다루는지 알려 주고, 로그인이 필요하면 나에게 물어보라고 시키는 것이 핵심입니다. 이렇게 하면 에이전트에게 비밀번호를 넘기지 않고, 브라우저 창이 로그인 화면에서 멈췄을 때 내가 직접 타이핑해 넣을 수 있습니다.
CLAUDE.md — Playwright 역할 지정
# 역할
너의 역할은 Playwright MCP로 n8n 워크플로우를 만들고 관리하는 것이다.
n8n 인스턴스 주소: https://내워크스페이스.app.n8n.cloud
- 브라우저로 위 주소를 열어서 작업한다.
- 로그인이 필요하면 진행하지 말고 나에게 알려라.
(아이디/비밀번호는 내가 브라우저에 직접 입력한다)자격 증명(로그인 정보)을 채팅으로 넘기지 않는 것이 안전의 핵심입니다. 에이전트는 로그인 페이지까지만 열고, 실제 아이디·비밀번호 입력은 사람이 브라우저에서 직접 하도록 역할을 나누세요.
가장 빛나는 순간: 자동 테스트/QA
Playwright MCP의 진짜 강점은 '만들기'보다 '테스트하기'에 있습니다. 예를 들어 이미 만들어 둔 AI 챗봇 워크플로우가 제대로 도는지 확인하려면, 사람이 채팅창을 열어 여러 질문을 던지고 답을 살펴봐야 합니다. Playwright MCP는 이 지루한 검증을 대신합니다. 브라우저로 챗봇을 열고, 테스트 메시지를 순서대로 보내고, 이전 대화를 기억하는지(메모리)·웹 검색 도구가 작동하는지를 실제 화면에서 확인해 줍니다.
Playwright가 대신 눌러 주며 검증하는 챗봇 워크플로우
검증 대상 — AI 챗봇
- 채팅 시작 Chat Trigger
- 사용자 메시지 AI Agent 질문에 답변 Chat Model 🧠, Memory 🧷 기억, Web Search 🔧
- 결과 응답 출력 챗봇 답변
Playwright MCP가 브라우저로 이 챗봇의 채팅창을 열어 테스트 메시지를 던지고, 메모리(이전 대화 기억)와 웹 검색 도구가 실제로 작동하는지를 사람 대신 확인합니다.
n8n-MCP vs Playwright MCP — 언제 뭘 쓸까
| 기준 | n8n-MCP | Playwright MCP |
|---|---|---|
| 작동 방식 | API로 직접 쓰기 | 실제 브라우저 클릭·드래그 |
| 속도 | 빠름 | 느림 |
| 토큰 비용 | 저렴 | 많이 씀 |
| 인스턴스 반영 | 즉시 직접 쓰기 | 화면 조작으로 반영 |
| 가장 잘하는 일 | 워크플로우 '짓기' | '테스트·검증' 및 UI 전용 작업 |
| 약점 | 화면으로만 되는 일은 못함 | 매 빌드마다 쓰기엔 비쌈 |
실전 조합은 이렇습니다. 만들 때는 빠르고 저렴한 n8n-MCP로 짓고, 다 지은 뒤 잘 도는지는 Playwright MCP로 사람처럼 눌러 검증합니다. '건설은 뒷문, 품질검사는 앞문'이라고 기억하세요.
명확한 프롬프트가 절반이다
어떤 MCP를 쓰든, 결과 품질은 프롬프트의 구체성에 크게 좌우됩니다. '고객 문의 자동화 만들어줘'처럼 두루뭉술하게 던지면, 에이전트가 필요 이상으로 복잡하거나 엉뚱한 노드를 넣고, 연결이 헐겁게 이어진 워크플로우가 나오기 쉽습니다. 좋은 방법은 에이전트가 곧바로 만들지 않고, 먼저 '설계안을 제안하고 빠진 정보를 되묻게' 하는 것입니다.
두루뭉술 프롬프트 vs 제안·질문형 프롬프트
두루뭉술
- "고객 문의 자동화 만들어줘"
- 과잉 복잡 / 엉뚱한 노드 / 헐거운 연결
추측이 많아 재작업 급증 ✗
명확 (제안 + 질문형)
- "만들기 전에 먼저 물어봐: 트리거는? 어떤 모델? 메모리 종류는?"
- "그다음 설계안을 제시하고, 내가 승인하면 만들어"
- 질문 → 확정 → 정확하고 단순한 워크플로우
의도에 맞는 깔끔한 결과 ✔
먼저 묻게 만들면, 에이전트의 추측이 줄고 내 의도에 맞는 깔끔한 워크플로우가 나옵니다. 되묻기 한 번이 재작업 열 번을 아낍니다.
'먼저 제안하고 되묻게' 하는 프롬프트
고객 문의 자동화를 만들고 싶어. 바로 만들지 말고 이렇게 진행해줘.
1) 먼저 나에게 확인 질문을 해줘:
- 트리거는 무엇으로 할까? (폼 제출 / 스케줄 / 웹훅 등)
- 어떤 AI 모델을 쓸까?
- 메모리가 필요해? 필요하면 어떤 종류?
- 분기 조건과 알림 채널은?
2) 내 답을 받아 설계안(노드 목록 + 연결 순서)을 제시해줘.
3) 내가 "좋아"라고 하면 그때 n8n-MCP로 실제로 만들어줘.이것으로 'AI 코딩 에이전트로 n8n 만들기' 섹션을 마칩니다. 정리하면, Claude Code로 뼈대를 빠르게 짓되 결과물은 n8n의 투명한 캔버스로 소유하고, n8n-MCP로 만들고 Playwright MCP로 검증하며, SOP와 CLAUDE.md로 의도를 문서화하고, 스크린샷 피드백으로 다듬어 나가면 됩니다. 이 루프를 반복할수록 여러분의 CLAUDE.md는 점점 똑똑한 '나만의 자동화 빌더'로 자라날 것입니다.