MCP는 "흥미로운 프로토콜"에서 훨씬 더 실용적인 단계, 즉 AI에게 유용한 손을 제공하는 방법으로 진화했습니다.

제가 아는 대부분의 빌더들은 동일한 기본적인 루프로 시작했습니다. AI에게 코드를 작성해달라고 요청합니다. 파일을 여기저기 복사합니다. 채팅창에 문서를 붙여넣습니다. 디버깅을 요청합니다. 그러다 점차 고통스러운 부분은 모델이 아니라는 것을 깨닫게 됩니다. 고통스러운 부분은 모델 주변의 모든 것, 즉 레포지토리 컨텍스트 (repo context), 브라우저 상태, 문서, 데이터, 그리고 외부 세계입니다.

그 지점에서 MCP가 중요해지기 시작합니다.

최고의 MCP 서버들은 단순히 플러그인을 위한 플러그인처럼 느껴지지 않습니다. 이들은 당신과 에이전트(agent) 사이의 반복적인 작업 전달 과정을 하나씩 제거해 줍니다.

만약 제가 오늘 AI 네이티브 빌더 워크플로우를 설정한다면, 가장 먼저 설치할 다섯 가지를 소개합니다.

1. GitHub MCP Server

AI가 소프트웨어 구축을 돕는다면, GitHub 접근 권한은 당연히 첫 번째 단계입니다.

공식 GitHub MCP Server를 사용하면 에이전트가 자연어를 통해 레포지토리(repositories), 파일, 이슈(issues), 풀 리퀘스트(pull requests), 그리고 관련 GitHub 워크플로우(workflows)를 다룰 수 있습니다. 중요한 점은 AI가 "GitHub을 사용할 수 있다"는 것이 아닙니다. 작업이 실제로 존재하는 곳에서 작업을 추론할 수 있다는 점입니다.

좋은 사용 사례:

• 에이전트에게 이슈를 조사하고 관련 파일을 찾도록 요청하기.
• 스탠드업 미팅 전에 열려 있는 풀 리퀘스트 요약하기.
• 붙여넣은 코드 조각 대신 레포지토리 컨텍스트를 사용하여 수정 사항 초안 작성하기.
• 수동으로 diff를 수집하지 않고 최근 변경 사항 검토하기.

이것은 코딩 에이전트를 위한 기본 MCP입니다. 레포지토리 접근 권한이 없다면, 당신의 AI는 당신이 붙여넣는 것을 기억해낸 적은 컨텍스트를 바탕으로 추측할 뿐입니다. 레포지토리 접근 권한이 있다면, AI는 진실의 원천(source of truth)을 직접 조사할 수 있습니다.

링크:
https://github.com/github/github-mcp-server

2. Playwright MCP

다음 격차는 브라우저입니다.

Playwright MCP는 구조화된 페이지 스냅샷을 통해 에이전트에게 브라우저 자동화 기능을 제공합니다. 이것이 중요한 이유는 많은 실제 제품 작업이 코드 내에서 이루어지지 않기 때문입니다. 작업은 대시보드, 양식, 관리자 패널, 문서, 그리고 실제 사용자 흐름(user flows)에서 발생합니다.

좋은 사용 사례:

• 에이전트에게 회원가입 흐름(signup flow)을 검증하도록 요청하세요.
• 수정 사항을 작성하기 전에 깨진 페이지 상태를 검사하게 하세요.
• 실제 브라우저 상호작용으로부터 테스트를 생성하세요.
• 랜딩 페이지가 실제로 코드에서 주장하는 방식대로 렌더링되는지 확인하세요.

AI 빌더들에게 이것은 특히 유용한데, 제품의 표면(product surface)을 엔지니어링 루프(engineering loop)와 다시 연결해주기 때문입니다. 여러분의 에이전트는 소스 파일만 가지고 논쟁하는 것을 멈추고, 사용자가 보는 실제 화면을 직접 확인할 수 있습니다.

링크:
https://github.com/microsoft/playwright-mcp

3. Context7

AI 코딩에서 가장 흔한 실패 모드 중 하나는 오래된 문서(stale documentation)입니다.

모델이 오래된 SDK를 기억하거나, 메서드 이름을 지어내거나, 작년 버전의 프레임워크 코드를 제공하는 경우가 있습니다. Context7은 최신 버전 정보가 반영된 문서를 에이전트의 컨텍스트(context)로 가져옴으로써 이러한 문제를 줄이기 위해 존재합니다.

좋은 사용 사례:

• 최신 프레임워크 API를 사용하여 구현 도움을 요청하세요.
• 탭을 전환할 필요 없이 코딩 루프 안으로 문서를 가져오세요.
• 빠르게 변화하는 라이브러리를 다룰 때 환각(hallucination)된 메서드를 방지하세요.
• 에이전트가 코드를 건드리기 전에 올바른 참조 자료를 제공하세요.

이것은 화려하지는 않지만, 실제 시간을 절약해 줍니다. AI 보조 코딩에서 발생하는 많은 버그는 깊은 추론의 실패가 아닙니다. 그것은 "어시스턴트가 오래된 컨텍스트를 가지고 있었다"는 실패입니다.

링크:
https://github.com/upstash/context7

4. Supabase MCP

많은 인디 AI 제품들은 동일한 스택(app code, Postgres 데이터베이스, 인증(auth), 스토리지, 그리고 몇 개의 API) 위에서 운영됩니다. Supabase MCP는 데이터베이스와 프로젝트 컨텍스트를 에이전트에게 더 가깝게 가져다주기 때문에 유용합니다.

좋은 사용 사례:

• 기능을 구현하는 동안 스키마(schema)를 검사하세요.
• 디버깅 중에 데이터를 쿼리(query)하세요.
• 인증(auth) 또는 테이블 설정을 이해하세요.
• 제품 로직과 데이터베이스의 실제 상태를 동일한 대화 맥락 내에 유지하세요.

주의사항은 명확합니다. 데이터베이스 도구는 세심한 권한 관리가 필요합니다. 가능한 경우 읽기 전용 (read-only)으로 시작하고, 일상적인 실험에는 운영 (production) 자격 증명을 사용하지 않으며, 에이전트에게 작업에 필요한 것 이상의 권한을 부여하지 않도록 주의해야 합니다.

그럼에도 불구하고, 책임감 있게 설정만 된다면 데이터베이스 컨텍스트 (database context)는 코딩 에이전트의 유용성을 비약적으로 높여주는 가장 큰 요소 중 하나입니다.

링크:
https://github.com/supabase/mcp

5. Pairoa

앞서 언급한 네 가지 MCP 서버는 AI가 도구 (tools)를 사용하는 것을 돕습니다.

Pairoa는 다릅니다. Pairoa는 AI가 기회 (opportunities)를 포착하도록 돕습니다.

대부분의 빌더들은 결국 순수하게 기술적인 것만이 아닌 질문들에 직면하게 됩니다:

• 이 제품의 초기 베타 사용자는 누가 될 수 있을까?
• 누가 기술 공동 창업자 (technical cofounder)를 찾고 있을까?
• 누가 정확히 내가 만들고 있는 도구를 필요로 할까?
• 누가 업무, 피드백, 디자인 파트너십, 채용 또는 배포 (distribution)를 제안하고 있을까?

오늘날 이러한 질문들은 대개 공개 게시글, 콜드 DM (cold DMs), 커뮤니티 탐색 또는 수동으로 주변에 물어보는 방식으로 해결됩니다. Pairoa는 다른 접근 방식을 취합니다. 즉, 니즈 (needs), 제안 (offers), 그리고 기회 (opportunities)를 위한 프라이빗 매칭 레이어 (private matching layer) 역할을 합니다.

당신은 AI에게 무엇을 찾고 있는지, 그리고 무엇을 제공할 수 있는지를 말합니다. Pairoa는 이를 공개 리스팅으로 전환하지 않습니다. 대신, 해당 니즈는 프라이빗 매칭 풀 (private matching pool)에 들어갑니다. 실제 양방향 적합성 (two-sided fit)이 확인될 때만 연락처가 공개됩니다.

이 점이 AI 빌더들에게 특히 흥미로운 이유는, 당신의 구축을 돕는 바로 그 에이전트가 적절한 요청을 표현하는 것도 도와줄 수 있기 때문입니다:

• "나는 창업자들을 위한 MCP 도구를 만들고 있어. Claude Code나 Cursor를 실제로 사용하는 베타 사용자를 찾아줘."
• "나는 풀스택 제품 엔지니어링 (full-stack product engineering)을 도울 수 있어. 기술 공동 창업자가 필요한 초기 단계 팀과 나를 매칭해줘."
• "에이전트 워크플로우 제품을 위한 디자인 파트너가 필요해. 무료 설정과 맞춤형 온보딩 (onboarding)을 제공할 수 있어."

대부분의 MCP는 AI를 소프트웨어에 연결합니다.

Pairoa는 AI를 다른 사람들의 니즈, 제안, 그리고 기회에 연결합니다.

링크:
https://pairoa.com/install

내가 시도해 볼 워크플로우 (workflow)

만약 제가 처음부터 이 환경을 구축한다면, 한꺼번에 20개의 MCP 서버를 설치하지는 않을 것입니다. 대신 각 레이어(layer)별로 하나씩 시작할 것입니다:

• Repo (저장소): GitHub
• Browser (브라우저): Playwright
• Docs (문서): Context7
• Data (데이터): Supabase
• Opportunities (기회): Pairoa

이렇게 하면 에이전트(agent)에게 다섯 가지 종류의 컨텍스트 (context)를 제공하게 됩니다: 당신이 무엇을 만들고 있는지, 사용자가 무엇을 보는지, 문서에는 무엇이라 적혀 있는지, 데이터는 무엇을 말하는지, 그리고 외부 세계가 무엇을 필요로 할 수 있는지에 대한 정보입니다.

이 지점이 바로 AI 어시스턴트 (AI assistant)가 단순한 채팅창처럼 느껴지는 단계를 넘어, 빌더 (builder)를 위한 운영 레이어 (operating layer)처럼 느껴지기 시작하는 지점입니다.

보안 주의 사항 (Safety note)

MCP 서버는 강력할 수 있습니다. 이를 소프트웨어 의존성 (software dependencies) 및 권한 (permissions)과 같이 취급하십시오. 공식 출처를 우선시하고, 각 서버가 어떤 권한을 얻는지 검토하며, 최소 권한 원칙 (least privilege)부터 시작하십시오. 특히 메시지를 보내거나, 비용을 지출하거나, 프로덕션 데이터 (production data)를 변경하거나, 사용자의 개인 정보에 접근할 수 있는 기능에는 각별히 주의해야 합니다.

목표는 당신의 AI를 모든 것에 연결하는 것이 아닙니다.

목표는 수동 작업 (manual work)을 가장 많이 제거해 줄 수 있는 소수의 접점 (surfaces)에 연결하는 것입니다.