MCP를 이해했다고 해서 곧바로 자동화가 완성되지는 않습니다. 진짜 차이는 무엇을 연결하느냐에서 납니다. 솔로 빌더에게 외부 도구 연결은 장식이 아니라 생산성의 천장입니다. 에이전트가 코드를 잘 짜더라도 이슈를 못 읽고, 브라우저를 못 만지고, 데이터베이스 상태를 못 보면 결국 마지막 30퍼센트는 사람이 손으로 메워야 합니다.
그래서 이 장에서는 '무슨 MCP를 붙일까'가 아니라 '어떤 순서로 붙이면 혼자 제품을 만들고 운영하는 흐름이 닫히는가'를 보겠습니다. 결론부터 말하면, 대부분의 솔로 빌더는 GitHub, Playwright, Database, 그리고 자기 제품 전용 MCP 서버 이 네 축만 제대로 잡아도 자동화 체감이 확 달라집니다.
![[4부] 솔로 빌더를 위한 MCP 스택](https://images.tilnote.io/pages/301ac697-0bb7-4b8e-ac68-6ec82484ece5.webp)
자동화 한계는 연결에서 결정된다
클로드 코드에서 MCP 서버는 로컬, 프로젝트, 사용자 범위로 관리할 수 있고, 프로젝트 범위 설정은 .mcp.json으로 공유할 수 있습니다. 팀을 위한 기능처럼 보이지만 솔로 빌더에게도 중요합니다. 노트북과 데스크톱, 개인 프로젝트와 수익 프로젝트를 오갈 때 설정이 흐트러지지 않기 때문입니다.1
여기서 핵심은 도구를 많이 붙이는 일이 아닙니다. 작업의 입구, 검증, 진실 공급원, 제품 전용 액션을 각각 하나씩 확보하는 일입니다. 이 관점으로 보면 선택이 단순해집니다.
GitHub는 일이 들어오고 나가는 문입니다. Playwright는 브라우저에서 실제로 무슨 일이 벌어지는지 보여 줍니다. 데이터베이스는 제품의 진실을 들고 있습니다. 그리고 자체 MCP 서버는 당신 제품만의 동사를 에이전트가 다룰 수 있게 만듭니다. 이 네 개가 연결되면 클로드 코드는 단순한 코딩 도우미에서 작은 운영 시스템으로 바뀝니다.
12.1 GitHub MCP - 일이 들어오고 나가는 문
솔로 빌더가 가장 먼저 붙일 MCP를 하나만 고르라면 저는 GitHub를 고르겠습니다. 이유는 단순합니다. 당신의 일감, 코드, 리뷰 기록, 배포 전후 맥락이 한곳에 모이기 때문입니다.
오늘날 GitHub MCP 계열 서버는 저장소, 이슈, 풀 리퀘스트, 액션, 보안 알림처럼 실제 개발 흐름에 필요한 도구들을 비교적 넓게 노출합니다. 일부 구현은 원격 서버로 붙고, 일부는 로컬 실행이나 컨테이너로도 운용할 수 있습니다.2 중요한 것은 구현 방식보다 도구 묶음을 어떻게 좁혀서 쓰느냐입니다.
솔로 빌더의 기본 패턴은 이렇습니다. GitHub 이슈를 읽고, 저장소를 검색하고, 수정한 뒤, 드래프트 PR을 만들고, Actions 결과를 확인하는 흐름입니다. 이 다섯 단계를 한 세션에서 닫을 수 있으면 생각보다 많은 일이 자동화됩니다. 특히 사이드 프로젝트를 퇴근 후에 운영하는 사람에게는 '다음에 다시 들어왔을 때 어디까지 했는지'가 늘 문제인데, GitHub는 그 상태를 남기기에 좋습니다.
여기서 욕심을 줄이는 것이 중요합니다. 처음부터 조직 관리, 시크릿 관리, 광범위한 보안 도구까지 다 열 필요는 없습니다. 대개는 repos, issues, pull_requests, actions 정도면 충분합니다.2 솔로 빌더에게 필요한 것은 만능 리모컨이 아니라 자주 쓰는 버튼 네 개짜리 리모컨입니다.
제가 권하는 운영 규칙은 간단합니다. 생성은 자동화하고, 병합은 사람에게 남겨 두는 것입니다. 다시 말해 클로드가 이슈를 읽고 코드를 고치고 PR 설명까지 써도 괜찮습니다. 하지만 merge는 본인이 직접 누르는 편이 좋습니다. 이 한 단계만 남겨도 사고 비용이 크게 줄어듭니다.
GitHub MCP가 특히 빛나는 장면은 두 가지입니다. 첫째, 요구사항을 구현으로 연결할 때입니다. 예를 들어 '이 이슈를 구현하고 테스트 계획까지 포함한 드래프트 PR을 만들어 줘' 같은 요청이 자연스러워집니다. 둘째, 운영 루프를 닫을 때입니다. 장애 이슈를 읽고, 관련 파일을 찾고, 수정 후 PR을 열고, Actions가 통과했는지 확인하는 흐름이 하나로 이어집니다.
한마디로 GitHub MCP는 코드 저장소를 연결하는 도구가 아니라 일의 출발점과 종료 지점을 같은 손 안에 넣는 도구입니다.
12.2 Playwright MCP - 브라우저를 팀원으로 만드는 법
GitHub가 일을 가져오는 문이라면, Playwright MCP는 현실 검증 담당자입니다. 코드가 아무리 그럴듯해도 브라우저에서 깨지면 사용자는 그 코드의 철학을 읽어주지 않습니다. 그냥 떠납니다.
공식 Playwright MCP 서버는 접근성 스냅샷을 기반으로 페이지를 읽고 조작합니다. 즉, 화면을 픽셀로 더듬는 대신 버튼, 입력창, 링크 같은 구조를 텍스트로 받아서 다루기 때문에 더 결정론적이고 토큰도 덜 먹는 편입니다. 게다가 비전 모델이 없어도 동작합니다.3 이 차이는 생각보다 큽니다. 솔로 빌더는 멋진 데모보다 재현 가능한 검증이 더 필요하기 때문입니다.
다만 Playwright MCP 생태계는 한 줄로 정리되지 않습니다. 공식 패키지인 @playwright/mcp가 있고, 커뮤니티 구현인 @executeautomation/playwright-mcp-server처럼 스크린샷, 코드 생성, 다양한 상호작용 도구를 더 강하게 내세우는 계열도 있습니다.4 둘 다 쓸 수 있지만, 혼자 운영하는 제품이라면 먼저 하나를 정해서 표준으로 삼는 편이 낫습니다. 기준이 흔들리면 프롬프트와 워크플로우도 계속 흔들립니다.
제 추천은 이렇습니다. 기본선은 공식 Playwright MCP로 잡으세요. 브라우저 자동화의 표준적인 흐름을 익히기에 좋고, Claude Code와 함께 쓸 때도 동작 방식이 비교적 예측 가능합니다.35 그리고 스크린샷 중심 시연이나 특정 부가 기능이 꼭 필요할 때만 커뮤니티 구현을 추가로 검토하세요.4
Playwright MCP의 실전 연결 패턴은 세 가지가 핵심입니다.
첫째, 셀프 QA입니다. 로컬호스트나 스테이징 앱을 열어 방금 만든 기능을 직접 검증하게 하세요. '결제 플로우를 끝까지 테스트해 줘'보다 '가격 변경 후 장바구니 총액, 쿠폰 적용, 결제 완료 메시지까지 확인해 줘'처럼 기대 결과를 같이 말하면 훨씬 잘 움직입니다.
둘째, 버그 재현입니다. 사용자 제보는 늘 모호합니다. 하지만 Playwright MCP가 있으면 '모바일 폭 375px에서 가입 버튼이 안 보인다는 제보를 재현해 줘'처럼 구체적인 탐색이 가능합니다. 사람은 재현하다 짜증이 나지만, 에이전트는 짜증이 없습니다. 이건 아주 좋은 성격입니다.
셋째, 탐색을 테스트 코드로 바꾸는 흐름입니다. Playwright MCP는 탐색과 디버깅에 강합니다. 하지만 반복 실행이 목적이라면 결국 표준 Playwright 테스트 파일로 굳혀야 합니다. 실제로 실전 가이드들도 MCP는 탐색, 셀프 QA, 플로우 발견에 쓰고, 반복 실행은 CLI와 테스트 스위트로 넘기는 하이브리드 방식을 권합니다.5
로그인이 필요한 제품이라면 저장 상태를 활용하는 것도 중요합니다. 공식 문서는 세션 쿠키와 로컬 스토리지를 저장했다가 다시 불러오는 storage state 방식을 지원하고, 기본적으로는 눈에 보이는 브라우저 모드로 실행됩니다. 필요하면 --headless, --isolated, 브라우저 선택 옵션도 쓸 수 있습니다.3 이 조합을 익히면 '매번 로그인부터 다시 시작하는 피곤한 자동화'에서 벗어날 수 있습니다.
짧게 정리하면 이렇습니다. Playwright MCP는 테스트 프레임워크의 대체재가 아니라 브라우저 현실을 빠르게 읽고, 재현하고, 테스트로 변환하는 탐색 엔진입니다.
12.3 Database MCP - 제품의 진실 공급원에 연결하기
GitHub가 할 일을 말해 주고, Playwright가 화면을 보여 준다면, 데이터베이스는 실제로 무슨 일이 일어났는지를 말해 줍니다. 솔로 빌더에게 이 연결은 가장 강력하면서도 가장 위험합니다.
왜 강력할까요. 제품 운영의 중요한 질문은 대부분 DB에 묻기 때문입니다. 누가 결제에 실패했는지, 어떤 플랜에서 이탈이 늘었는지, 특정 기능을 실제로 누가 썼는지, 오류가 난 사용자가 공통으로 가진 속성이 무엇인지 같은 질문 말입니다. SQL MCP Server 같은 구현은 RBAC와 텔레메트리, 검증된 데이터 계층을 바탕으로 AI 에이전트가 더 안전하게 SQL 시스템과 상호작용하도록 설계되어 있습니다.6
왜 위험할까요. 데이터베이스는 대체로 가장 민감한 진실을 품고 있기 때문입니다. 고객 데이터, 결제 상태, 내부 운영 정보가 모두 여기 있습니다. 게다가 MCP 역사에서는 읽기 전용처럼 보이는 구현이 실제로는 SQL 인젝션 우회를 막지 못했던 사례도 있었습니다. 그래서 DB 연결에서는 프롬프트보다 권한 설계가 먼저입니다.7
저는 솔로 빌더에게 데이터베이스 MCP를 세 층으로 나눠 쓰라고 권합니다.
첫 번째 층은 프로덕션 읽기 전용입니다. 이것이 기본입니다. 고객 지원, 장애 분석, 지표 확인은 대부분 여기서 해결됩니다. 읽기 전용 계정, 행 수 제한, 허용된 스키마만 노출하는 설정이 우선입니다.7
두 번째 층은 스테이징 읽기/쓰기입니다. 마이그레이션 실험, 데이터 보정 리허설, 쿼리 튜닝은 스테이징에서 먼저 검증합니다. 프로덕션에 쓰기 권한을 바로 주는 순간 마음이 편해지는 대신 수명이 짧아질 수 있습니다.
세 번째 층은 비즈니스 작업용 도구입니다. 이것이 중요합니다. 에이전트에게 범용 execute_sql만 주면 결국 모든 일이 망치 하나로 보입니다. 대신 find_failed_checkouts, preview_refund_impact, list_stuck_webhooks처럼 목적이 분명한 도구를 노출하는 편이 훨씬 안전하고 실용적입니다.78
스키마를 그대로 다 보여 주는 것도 좋지 않습니다. 실전에서는 허용 목록 테이블만 노출하거나, 뷰를 만들어 MCP 전용 인터페이스로 쓰거나, 아예 미리 정의된 쿼리 템플릿만 제공하는 방식이 더 낫습니다.7 예를 들어 고객 요약 뷰를 하나 만들고, 민감한 컬럼은 애초에 제외한 채 에이전트가 그 뷰만 보게 하면 많은 문제가 사라집니다.
솔로 빌더가 체감하기 쉬운 패턴은 이런 것입니다. '지난 14일간 결제 시도는 했지만 성공하지 못한 사용자 20명을 찾아 원인을 분류해 줘.' 이 요청은 DB 조회로 시작하지만, 이후 GitHub 이슈 생성이나 Playwright 재현 테스트로 자연스럽게 이어질 수 있습니다. 즉, Database MCP의 진짜 가치는 SQL 실행 자체보다 다른 도구와 연결될 때 생기는 진실 기반 자동화에 있습니다.
12.4 자체 MCP 서버 만들기 - 내 제품 전용 손잡이 만들기
여기까지 오면 대개 이런 생각이 듭니다. GitHub도 붙였고, Playwright도 붙였고, DB도 붙였다. 그런데 아직도 내 제품만의 귀찮은 작업이 남아 있습니다. 예를 들면 실패한 웹훅 재전송, 체험판 만료 예정 사용자 정리, 특정 결제사의 상태 재동기화, 내부 관리자 액션 같은 것들입니다.
바로 이때 자체 MCP 서버를 만들 차례입니다.
중요한 기준이 하나 있습니다. 반복되고, 제품 특화되어 있고, 앞으로도 남을 일인지를 먼저 보세요. 단발성 스크립트라면 MCP 서버까지 만들 필요가 없습니다. 이미 잘 만들어진 MCP 서버가 있다면 또 만들 이유도 없습니다. 반대로 내부 API나 운영 스크립트를 자꾸 복붙해서 돌리고 있다면, 그건 MCP로 승격할 후보입니다.8
좋은 자체 MCP 서버는 API 전체를 드러내지 않습니다. 에이전트가 실제로 풀어야 하는 일을 기준으로 도구를 고릅니다. 도구 이름은 동사 중심으로, 입력은 타입이 명확하게, 출력은 필요한 정보만, 오류는 다음 행동이 보이도록 설계해야 합니다.8 do_thing 같은 이름은 사람에게도 나쁘지만 에이전트에게는 더 나쁩니다. 반면 replay_failed_webhook, get_customer_subscription_summary, generate_weekly_mrr_report 같은 이름은 무엇을 할지 바로 보입니다.
처음에는 다섯 개 안팎의 핵심 도구만 만드세요. 가장 자주 쓰는 운영 액션부터 감싸는 편이 좋습니다.8 솔로 빌더에게는 도구 수보다 적중률이 중요합니다. 30개짜리 부실한 서버보다 5개짜리 날카로운 서버가 훨씬 낫습니다.
구조 선택도 현실적으로 가면 됩니다. 자기 컴퓨터나 단일 서버에서만 쓰는 내부 도구라면 stdio 기반 로컬 서버가 가장 단순합니다. 반대로 모바일이나 웹 대시보드, 원격 워커, 여러 머신에서 공용으로 써야 한다면 HTTP 기반 원격 MCP 서버가 더 맞습니다.910 전자는 만들기 쉽고, 후자는 확장하기 쉽습니다.
다만 자체 서버가 조금만 커져도 금방 '내 장난감'에서 '내 인프라'로 변합니다. 그 순간부터는 연결 풀, 인증, 속도 제한, 구조화된 에러 처리, 헬스체크 같은 생산 환경 기본기가 필요해집니다.9 특히 하나의 도구가 외부 API 비용을 쓰거나, 결제 같은 민감한 작업을 건드린다면 권한 경계와 감사 로그는 꼭 넣어야 합니다.
제가 좋아하는 질문이 있습니다. '이 일을 내가 사람에게 시킨다면 어떤 버튼 이름을 붙일까?' 그 이름이 곧 MCP 도구 이름이 되면 좋습니다. 결국 자체 MCP 서버는 당신 제품의 내부 기능을 에이전트가 이해할 수 있는 손잡이로 다시 설계하는 작업입니다.
솔로 빌더용 권장 스타터 스택
처음부터 거대한 MCP 왕국을 만들 필요는 없습니다. 오히려 순서가 중요합니다.
GitHub MCP부터 붙이세요. 일감, 코드, PR, CI가 한 흐름으로 이어집니다.
그다음 Playwright MCP를 붙이세요. 화면에서 실제로 되는지 확인하는 루프가 생깁니다.
세 번째로 Database MCP를 읽기 전용으로 여세요. 제품의 진실을 가져올 수 있습니다.
마지막으로 자체 MCP 서버를 하나 만드세요. 가장 귀찮은 내부 운영 작업을 감싸면 됩니다.
이 순서가 좋은 이유는 단순합니다. 앞의 세 개는 대부분의 제품에서 공통이고, 마지막 하나가 당신만의 차별화된 자동화를 만들기 때문입니다. 다시 말해, 공통 인프라 위에 제품 전용 손잡이를 얹는 구조입니다.
이 구성을 마치고 나면 클로드 코드에게 이런 식으로 일 시키는 것이 가능해집니다. GitHub 이슈를 읽고, 관련 코드를 고치고, Playwright로 스테이징에서 검증하고, 실패 사용자 패턴을 DB에서 확인하고, 필요하면 내부 운영 도구로 웹훅을 재전송한 뒤, 드래프트 PR까지 열어 달라고 말하는 식입니다. 혼자 일하는데도 흐름만 보면 작은 팀처럼 움직이게 됩니다.
연결이 많아질수록 더 중요한 것
마지막으로 꼭 기억할 점이 있습니다. MCP 스택의 목표는 도구 수집이 아닙니다. 반복되는 일의 마찰을 줄이는 것입니다.
연결이 늘어나면 가능한 일은 많아지지만, 동시에 잘못 시킬 수 있는 일도 많아집니다. 그래서 스택을 키울수록 원칙은 더 단순해야 합니다. 읽기 전용부터 시작하고, 생성은 자동화하되 최종 승인 단계는 남기고, 범용 도구보다 목적형 도구를 선호하고, 제품의 핵심 루프와 직접 연결된 것만 오래 유지하세요.
솔로 빌더에게 좋은 MCP 스택은 화려한 스택이 아닙니다. 밤 11시에 피곤한 상태로도 믿고 맡길 수 있는 스택입니다.
GitHub는 일을 받아 주고, Playwright는 현실을 보여 주고, 데이터베이스는 진실을 말해 주고, 자체 MCP 서버는 당신 제품만의 동사를 실행합니다. 이 네 가지가 맞물리면 클로드 코드는 단지 코드를 써주는 모델이 아니라, 혼자 만드는 제품의 작은 운영체제가 됩니다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.