MCP 서버 큐레이션 리스트

MCP는 많이 붙일수록 좋은 것이 아니다

MCP 서버를 처음 알게 되면 마음이 급해진다. GitHub도 붙이고, Figma도 붙이고, Postgres도 붙이고, Slack도 붙이고, 브라우저 자동화도 붙이고 싶어진다. 마치 새 노트북을 산 첫날 생산성 앱을 잔뜩 설치하는 기분이다.

하지만 솔로 메이커에게 MCP의 핵심은 "얼마나 많이 연결했는가"가 아니라 "지금 막힌 병목을 얼마나 안전하게 줄였는가"다. Cursor Marketplace와 여러 MCP 디렉터리에는 이미 수많은 서버가 올라와 있고, 설치 버튼 하나로 붙일 수 있는 것들도 늘고 있다.¹ 문제는 선택지가 많아질수록 에이전트가 사용할 수 있는 도구도 많아지고, 도구 설명 자체가 컨텍스트를 차지하며, 권한 관리도 복잡해진다는 점이다.

MCP를 제품 개발의 배선반이라고 생각하자. 전선을 많이 꽂는다고 전기가 더 안정되는 것은 아니다. 오히려 어디서 누전이 나는지 알기 어려워진다. 좋은 MCP 구성은 단순하다. 자주 쓰는 도구는 전역으로, 프로젝트에 묶인 도구는 로컬로, 위험한 도구는 읽기 전용으로, 운영 데이터는 가능한 한 멀리 둔다.

이 부록에서는 솔로 메이커가 실제로 쓸 만한 MCP 서버를 목적별로 정리하고, 어떤 순서로 도입하면 좋은지 제안한다. 여기서 목표는 "멋진 MCP 컬렉션"을 만드는 것이 아니라, 혼자서 제품을 만들고 운영할 때 필요한 외부 연결을 필요한 만큼만 추가하는 것이다.

먼저 기억할 네 가지 원칙

MCP 서버는 Cursor Agent가 외부 도구를 호출하게 해주는 연결 장치다. Cursor는 MCP를 통해 도구, 리소스, 프롬프트 같은 기능을 사용할 수 있으며, 로컬 프로세스 방식인 stdio와 원격 연결 방식인 HTTP 계열 전송을 지원한다.² 이 말은 곧, MCP 서버가 가진 권한만큼 에이전트도 외부 세계를 만질 수 있다는 뜻이다.

따라서 설치 전에 네 가지 원칙을 정해두면 좋다.

첫째, 읽기부터 시작한다. GitHub 이슈를 읽고, DB 스키마를 보고, Sentry 에러를 조회하는 것은 비교적 안전하다. 반대로 PR을 만들고, Slack에 메시지를 보내고, 데이터베이스에 쓰고, 배포 환경 변수를 바꾸는 일은 훨씬 조심해야 한다.

둘째, 프로젝트별 도구와 개인 도구를 분리한다. 모든 프로젝트에서 쓰는 문서 검색, GitHub, 시간 도구는 전역 설정에 둘 수 있다. 특정 제품의 Postgres, Supabase, Figma, Sentry는 프로젝트 로컬 설정에 두는 편이 낫다. Cursor는 전역 MCP 설정과 프로젝트별 MCP 설정을 모두 지원하며, 프로젝트 설정이 같은 이름의 전역 설정을 덮어쓸 수 있다.³

셋째, 토큰은 설정 파일에 직접 쓰지 않는다. 특히 .cursor/mcp.json을 Git에 커밋할 가능성이 있다면 API 키를 절대 하드코딩하지 말아야 한다. 환경 변수로 주입하고, 토큰은 최소 권한과 만료 기간을 가진 별도 토큰으로 만든다.

넷째, 도구 수를 관리한다. Cursor에는 활성 MCP 도구 수에 실질적인 한계가 있다. 여러 자료에서 약 40개 도구를 넘기면 에이전트가 일부 도구를 보지 못하거나 도구 선택 품질이 떨어질 수 있다고 설명한다.⁴ "서버 수"보다 중요한 것은 "서버가 노출하는 도구 수"다. 도구 3개짜리 서버 5개와 도구 25개짜리 서버 2개는 체감이 완전히 다르다.

도입 우선순위: 솔로 메이커용 4단계

처음부터 풀세트를 설치하지 말자. 아래 순서대로 하나씩 붙여보고, 실제로 일주일 이상 쓰는 것만 남긴다.

0순위: 생각을 정리하는 도구

이 단계의 MCP는 외부 서비스 권한이 거의 없거나 낮다. 설치 부담이 작고, 보안 리스크도 상대적으로 낮다. Cursor를 처음 MCP와 함께 쓰는 사람에게 좋은 출발점이다.

sequentialthinking은 복잡한 문제를 단계별 사고로 쪼개는 데 도움을 준다. 외부 API를 연결한다기보다, 에이전트가 "한 번에 답을 내기"보다 "문제를 나누어 풀기"에 가깝게 움직이도록 도와주는 도구다. 복잡한 리팩토링, 마이그레이션 계획, 장애 원인 분석처럼 순서가 중요한 작업에 잘 맞는다.

time MCP는 시간대 변환, 현재 시간 확인, 날짜 계산 같은 사소하지만 자주 필요한 일을 맡긴다. 예를 들어 "한국 시간으로 내일 오전 9시에 실행될 cron 표현식을 만들어줘" 같은 요청에서 유용하다. 제품 운영을 하다 보면 UTC, KST, 사용자의 현지 시간이 뒤섞이는데, 이때 작은 실수를 줄여준다.

이 둘은 "권한이 낮고 효용이 넓은 도구"라서 전역 설정에 두기 좋다.

1순위: 코드와 이슈의 현실을 연결하는 도구

다음은 GitHub와 Git이다. 솔로 메이커라도 GitHub는 사실상 협업 도구다. 협업 상대가 다른 사람이 아니라 "미래의 나"일 뿐이다.

GitHub MCP는 이슈 조회, PR 확인, 코드 검색, 브랜치나 PR 작업에 유용하다. 예를 들어 "최근 열린 버그 이슈를 보고 이번 배포에 포함할 수정 후보를 정리해줘"라고 요청하면 Cursor가 GitHub의 실제 이슈를 읽고 작업 계획을 세울 수 있다. GitHub 공식 MCP나 Marketplace의 검증된 설치 경로를 우선 확인하는 것이 좋다. MCP 생태계는 빠르게 바뀌므로 패키지 이름을 인터넷 글 하나만 믿고 고정하지 말고, 공식 문서나 Marketplace에서 현재 권장 설치 방식을 확인하자.¹

Git MCP는 원격 GitHub API가 아니라 로컬 저장소의 변경 이력과 diff를 다룰 때 좋다. "이번 변경에서 인증 관련 파일만 요약해줘", "마지막 커밋 이후 바뀐 파일을 기준으로 릴리즈 노트를 써줘" 같은 작업에 맞다. 이미 Cursor가 워크스페이스를 읽을 수 있더라도, Git 도구가 있으면 변경 이력 중심의 질문을 더 명확히 처리할 수 있다.

이 단계부터는 권한을 신경 써야 한다. GitHub 토큰은 가능하면 fine-grained token으로 만들고, 필요한 저장소와 필요한 권한만 부여한다. 모든 저장소에 대한 전체 권한을 가진 classic token을 넣는 습관은 버리자.

2순위: 제품의 실제 상태를 읽는 도구

이 단계부터 MCP는 제품의 내부 상태를 직접 읽기 시작한다. 효용은 매우 크지만, 실수의 비용도 커진다. Postgres, Supabase, Sentry가 여기에 속한다.

Postgres MCP는 데이터베이스 스키마 확인, 읽기 쿼리, 간단한 데이터 분석에 강력하다. "지난 7일 가입자 수를 일별로 보여줘", "orders 테이블과 payments 테이블의 관계를 설명해줘", "이 마이그레이션이 기존 컬럼과 충돌할 가능성이 있는지 봐줘" 같은 요청을 할 수 있다. MCP를 통해 Cursor가 실제 DB 스키마를 볼 수 있으면, 모델이 존재하지 않는 컬럼이나 잘못된 관계를 상상해서 코드를 쓰는 일을 줄일 수 있다.⁵

Sentry MCP는 운영 중 발생한 에러를 코드 수정 흐름으로 끌고 들어온다. 에러 ID, stack trace, 발생 빈도, 영향을 받은 사용자 수 같은 정보를 보고 "가장 많이 터지는 에러부터 고쳐줘"라고 요청할 수 있다. 솔로 메이커에게 특히 중요하다. 팀이 없을수록 장애를 발견하고 재현하고 수정하는 시간이 길어지는데, Sentry MCP는 이 시간을 줄여준다.

단, Postgres와 Sentry는 반드시 읽기 권한부터 시작한다. 개발 DB에는 어느 정도 실험 권한을 줄 수 있지만, production DB에 쓰기 권한을 주는 것은 거의 항상 나쁜 선택이다.

3순위: 디자인과 커뮤니케이션을 연결하는 도구

Figma와 Slack은 제품의 "코드 밖 맥락"을 연결한다.

Figma MCP는 선택한 프레임, 컴포넌트 구조, 오토레이아웃, 간격, 스타일 정보를 Cursor가 읽게 해준다. 스크린샷을 보고 추측하는 것보다 훨씬 정확하다. 특히 12장에서 다룬 것처럼 UI 작업에서는 "대충 비슷한 화면"보다 "디자인 시스템의 간격과 토큰을 지키는 화면"이 중요하다. Figma MCP는 디자인을 코드로 옮기는 반복 작업을 줄여준다.

Slack MCP는 혼자 일하는 사람에게도 의외로 유용하다. 고객 피드백 채널, 알림 채널, 커뮤니티 채널을 운영한다면 Slack은 요구사항의 원천이 된다. "지난주 결제 오류 관련 메시지를 모아서 원인별로 분류해줘" 같은 요청이 가능하다. 다만 Slack은 대화 기록에 민감한 정보가 섞이기 쉽다. 처음에는 읽기 전용 검색만 허용하고, 메시지 전송 도구는 비활성화하는 편이 안전하다.

이 단계의 도구는 프로젝트마다 필요 여부가 크게 갈린다. 디자인 중심 제품이라면 Figma가 1순위에 가까울 수 있고, 고객 커뮤니티를 Slack으로 운영한다면 Slack이 Sentry만큼 중요할 수 있다. 반대로 혼자 로컬 앱을 만드는 중이라면 당장 필요 없을 수도 있다.

목적별 MCP 서버 큐레이션

아래 목록은 "설치하면 멋져 보이는 것"이 아니라 "솔로 메이커가 실제 워크플로우에서 자주 쓸 수 있는 것"을 기준으로 정리했다. 패키지 이름과 설치 방식은 바뀔 수 있으므로, 실제 설치 전에는 Cursor Marketplace, 각 서비스 공식 문서, 서버 저장소의 README를 확인하자.

표에서 "선택"이라고 표시한 도구가 덜 중요하다는 뜻은 아니다. 단지 모든 솔로 메이커에게 동시에 필요한 것은 아니라는 뜻이다. MCP는 병목을 해결할 때 빛난다. 지금 병목이 UI 검증이면 Playwright가 우선이고, 장애 대응이면 Sentry가 우선이며, API 스키마 불일치가 문제라면 Postgres나 API 문서 MCP가 우선이다.

핵심 MCP별 사용 장면

GitHub: 브라우저 탭을 줄이는 첫 번째 연결

GitHub MCP는 가장 먼저 고려할 만한 도구다. 코드를 쓰는 일은 대부분 GitHub의 이슈, PR, 액션 결과, 릴리즈 기록과 연결되어 있다. Cursor에게 "현재 변경사항으로 PR 설명을 작성해줘"라고 시키는 것과 "열린 이슈 중 결제 관련 버그를 읽고 수정 계획을 세워줘"라고 시키는 것은 완전히 다른 경험이다. 후자는 Cursor가 실제 제품 운영 흐름에 들어온다는 뜻이다.

다만 GitHub MCP에 쓰기 권한을 줄 때는 신중해야 한다. 이슈 생성이나 PR 생성은 편리하지만, 브랜치 삭제, 워크플로우 실행, 릴리즈 생성까지 허용하면 실수의 폭이 커진다. 처음에는 repository contents 읽기, issues 읽기, pull requests 읽기 정도로 시작하고, 필요할 때만 쓰기 권한을 추가하자.

Git: 코드 변경의 문맥을 잡는 도구

Git MCP는 로컬 저장소의 변경 흐름을 이해하는 데 좋다. "내가 방금 뭘 바꿨지?"라는 질문은 생각보다 자주 나온다. 솔로 메이커는 PM, 개발자, QA, 운영자를 모두 겸하기 때문에 작업 전환이 잦다. 오전에는 결제 버그를 고치고, 오후에는 랜딩 페이지를 만지고, 밤에는 이메일 템플릿을 수정한다. 하루가 끝날 때 변경사항을 요약하려면 Git 기반 도구가 유용하다.

Git MCP를 쓰면 커밋 메시지 작성, 릴리즈 노트 초안, 변경 파일 중심 코드리뷰, 특정 커밋 이후 영향 범위 분석을 맡길 수 있다. GitHub MCP가 "원격 협업 상태"를 다룬다면, Git MCP는 "내 작업 디렉터리의 현재 상태"를 다룬다.

Postgres: 스키마를 붙여넣지 않기

Postgres MCP는 백엔드와 데이터 중심 제품에서 체감이 크다. MCP가 없으면 Cursor에게 DB 스키마를 설명하기 위해 schema.sql을 붙여넣거나, Prisma schema를 열어 보여주거나, 쿼리 결과를 복사해야 한다. MCP가 있으면 Cursor가 직접 스키마를 조회하고 필요한 SQL을 실행할 수 있다.

하지만 여기에는 강한 경계가 필요하다. 개발 DB는 실험 공간이다. 스테이징 DB는 실제와 비슷한 검증 공간이다. 프로덕션 DB는 고객의 현실이다. 이 세 공간을 같은 권한으로 Cursor에 연결하면 안 된다.

Postgres MCP에는 가능하면 읽기 전용 계정을 사용하자. 예를 들어 개발 환경에서는 app_dev_ai 계정을 만들고 읽기와 제한적 쓰기를 허용할 수 있다. 스테이징에서는 읽기와 테스트 데이터에 대한 제한적 쓰기만 허용한다. 프로덕션에서는 읽기 전용 replica나 분석용 뷰만 연결하고, 원본 테이블 쓰기는 금지한다.

Figma: 화면을 상상하지 않게 만들기

Figma MCP는 UI 구현에서 "비슷하게 만들어줘"의 한계를 줄인다. 이미지 한 장을 보고 코드를 생성하면 모델은 간격, 컴포넌트 구조, 상태, 토큰을 추측한다. 반면 Figma MCP는 디자인 파일의 구조화된 정보를 제공할 수 있다. 레이어 계층, 오토레이아웃, 색상, 텍스트 스타일 같은 정보를 기반으로 구현하게 되므로 결과물이 더 안정적이다.

Figma MCP는 프로젝트 로컬 설정에 두는 것이 좋다. 제품마다 Figma 파일, 팀, 토큰 체계가 다르기 때문이다. 개인 실험용 프로젝트에서 쓰는 Figma 토큰과 실제 제품 디자인 파일에 접근하는 토큰을 분리하자. 쓰기 기능이 있는 Figma MCP를 사용할 때는 더 조심해야 한다. 코드 구현을 위해 디자인을 읽는 것과 AI가 디자인 파일을 수정하는 것은 다른 문제다.

Slack: 대화를 요구사항으로 바꾸기

Slack MCP는 고객 피드백, 운영 알림, 의사결정 기록을 Cursor 안으로 가져온다. "지난달 온보딩 관련 불만을 요약해줘", "결제 실패 알림 중 Stripe timeout과 관련된 메시지만 모아줘", "이 기능에 대해 내가 Slack에서 뭐라고 결정했는지 찾아줘" 같은 요청이 가능하다.

하지만 Slack은 사적인 대화와 민감한 정보가 섞일 수 있는 공간이다. 솔로 메이커라도 고객 이메일, 결제 정보, 내부 토큰, 임시 비밀번호가 메시지에 들어갈 수 있다. Slack MCP는 기본적으로 읽기 범위를 특정 채널로 제한하고, DM 접근은 가급적 막자. 메시지 전송 기능은 배포 알림처럼 정해진 채널에만 허용하는 것이 좋다.

Sentry: 에러를 수정 가능한 작업으로 바꾸기

Sentry MCP는 운영 단계에서 가치가 커진다. 에러 모니터링 도구는 알림을 보내지만, 알림을 보고 코드를 고치는 일은 여전히 사람의 몫이었다. Sentry MCP를 붙이면 Cursor가 에러 발생 위치, stack trace, 릴리즈 버전, 빈도, 사용자 영향 범위를 보고 수정 후보를 제안할 수 있다.

예를 들어 이렇게 요청할 수 있다.

Sentry에서 지난 24시간 동안 가장 많이 발생한 에러 3개를 확인하고,
각 에러의 원인 후보와 수정할 파일을 제안해줘.
프로덕션 데이터에는 쓰기 작업을 하지 마.

이때 중요한 것은 "조회"와 "조치"를 분리하는 것이다. Sentry에서 에러를 읽는 것은 허용하되, 배포 롤백, 알림 설정 변경, 이슈 상태 변경 같은 작업은 처음에는 수동 승인으로 남겨두자.

time: 작지만 은근히 중요한 운영 도구

시간 관련 버그는 사소해 보이지만 실제 제품에서는 치명적이다. 무료 체험 만료일, 구독 갱신일, 예약 발송, cron, 리포트 집계 기준일은 모두 시간 계산에 걸려 있다. time MCP는 이런 질문을 빠르게 처리한다.

"매주 월요일 오전 9시 KST에 실행되는 cron을 UTC 기준으로 작성해줘", "미국 태평양 시간 기준 금요일 오후 5시는 한국 시간으로 언제야?", "오늘부터 14일 뒤 23:59:59 UTC를 ISO 문자열로 만들어줘" 같은 요청은 작지만 반복적이다. 이런 작업을 AI가 정확히 도와주면 운영 실수가 줄어든다.

sequentialthinking: 큰 작업의 브레이크

Cursor Agent는 때때로 너무 빨리 구현으로 달려간다. 이때 sequentialthinking은 브레이크 역할을 한다. "먼저 문제를 분해하고, 가정과 위험을 적고, 그다음 구현 계획을 세워줘"라는 식으로 요청하면 복잡한 작업에서 실수가 줄어든다.

특히 다음 작업에 잘 맞는다.

• 인증 구조 변경처럼 영향 범위가 넓은 리팩토링

• DB 마이그레이션과 코드 변경이 함께 필요한 기능

• 장애 원인이 여러 층에 걸쳐 있을 수 있는 디버깅

• 외부 API 교체처럼 테스트 시나리오가 많은 작업

이 도구는 외부 권한보다 사고 흐름을 다루기 때문에, 전역에 두고 자주 사용해도 부담이 적다.

전역 설정과 프로젝트 로컬 설정 나누기

Cursor의 MCP 설정은 보통 두 위치로 나눈다. 전역 설정은 모든 프로젝트에서 쓰는 도구에 적합하고, 프로젝트 로컬 설정은 특정 제품의 데이터와 연결된 도구에 적합하다.³

전역 설정 파일은 macOS와 Linux 기준으로 보통 다음 위치에 둔다.

~/.cursor/mcp.json

프로젝트 로컬 설정은 프로젝트 루트 아래에 둔다.

.cursor/mcp.json

전역 설정에는 "개인 작업 습관"에 가까운 도구를 둔다.

{
  "mcpServers": {
    "sequentialthinking": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
    },
    "time": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-time"]
    },
    "github": {
      "url": "https://mcp.github.com",
      "headers": {
        "Authorization": "Bearer ${GITHUB_TOKEN}"
      }
    }
  }
}

위 예시는 개념을 보여주기 위한 형태다. GitHub MCP는 공식 권장 방식이 바뀔 수 있으므로 실제로는 현재 GitHub와 Cursor 문서를 확인하자. 중요한 것은 토큰을 직접 쓰지 않고 ${GITHUB_TOKEN}처럼 환경 변수로 주입한다는 점이다.

프로젝트 로컬 설정에는 해당 제품에만 필요한 도구를 둔다.

{
  "mcpServers": {
    "app-postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "${APP_READONLY_DATABASE_URL}"
      }
    },
    "app-sentry": {
      "command": "npx",
      "args": ["-y", "@sentry/mcp-server"],
      "env": {
        "SENTRY_AUTH_TOKEN": "${SENTRY_READONLY_TOKEN}",
        "SENTRY_ORG": "${SENTRY_ORG}",
        "SENTRY_PROJECT": "${SENTRY_PROJECT}"
      }
    },
    "app-figma": {
      "command": "npx",
      "args": ["-y", "figma-mcp-server"],
      "env": {
        "FIGMA_TOKEN": "${FIGMA_READONLY_TOKEN}",
        "FIGMA_FILE_KEY": "${FIGMA_FILE_KEY}"
      }
    }
  }
}

여기서도 핵심은 토큰을 파일에 쓰지 않는 것이다. .cursor/mcp.json을 팀과 공유하거나 Git에 커밋해야 한다면, 실제 값은 각자의 쉘 환경이나 비밀 관리 도구에서 주입한다.

export GITHUB_TOKEN="github_pat_..."
export APP_READONLY_DATABASE_URL="postgresql://readonly_user:password@localhost:5432/app_dev"
export SENTRY_READONLY_TOKEN="sntrys_..."
export FIGMA_READONLY_TOKEN="figd_..."

솔로 메이커라도 이 습관을 들여야 한다. 혼자 만든 프로젝트가 나중에 팀이 될 수도 있고, 오픈소스로 공개될 수도 있으며, 실수로 GitHub에 올라갈 수도 있다.

개발·스테이징·프로덕션 접근 정책

MCP 접근 정책은 복잡한 보안 문서처럼 시작할 필요가 없다. 아래 정도만 정해도 사고 가능성이 크게 줄어든다.

가장 중요한 원칙은 production에 대해 "AI가 직접 바꿀 수 있는 길"을 최소화하는 것이다. 특히 데이터베이스, 결제, 인증, 배포 환경 변수는 MCP를 통해 자동 변경하지 않는 편이 좋다. 필요하다면 Cursor에게 SQL이나 변경 계획을 "작성만" 하게 하고, 실행은 사람이 별도 도구에서 검토 후 수행한다.

예를 들어 production DB에 대해서는 이렇게 지시한다.

이 프로젝트의 production 데이터베이스에 대해서는 읽기 전용 쿼리만 허용한다.
INSERT, UPDATE, DELETE, ALTER, DROP, TRUNCATE, CREATE INDEX는 실행하지 말고,
필요하면 별도 SQL 파일로 제안만 작성한다.

이 규칙은 .cursor/rules/에도 넣을 수 있고, MCP를 사용하는 요청마다 반복해도 된다. 특히 Auto-run 모드를 켜두었다면 production 관련 MCP는 비활성화하는 것이 안전하다. MCP 보안 가이드들은 MCP 서버가 사용자 권한과 토큰을 가지고 실행된다는 점을 반복해서 강조한다.⁶

40개 도구 제한과 컨텍스트 비용 관리

MCP 서버 하나가 도구 하나를 의미하지는 않는다. 어떤 서버는 도구를 2~3개만 노출하고, 어떤 서버는 20개 이상 노출한다. Cursor Agent는 작업할 때 사용할 수 있는 도구 설명을 함께 고려해야 하므로, 도구가 많아질수록 컨텍스트 비용이 늘고 선택지도 복잡해진다.

실전에서는 다음 기준을 쓰면 좋다.

• 평소 켜두는 MCP 도구는 15개 안팎으로 유지한다.

• 한 프로젝트에서 활성 서버는 3~6개 정도로 시작한다.

• 도구가 많은 서버는 필요한 도구만 켜거나, 작업이 끝나면 비활성화한다.

• 한 달 동안 한 번도 호출하지 않은 MCP는 제거 후보로 본다.

• 같은 목적의 MCP를 여러 개 설치하지 않는다.

예를 들어 웹 정보를 읽기 위해 Brave Search, Firecrawl, Browser MCP, Playwright MCP를 모두 켜둘 필요는 없다. "검색"이 필요하면 검색 MCP 하나, "페이지 본문 추출"이 필요하면 Firecrawl류 하나, "실제 UI 조작"이 필요하면 Playwright 하나면 충분하다. 세 도구의 역할이 다르긴 하지만, 매일 모두 필요한 것은 아니다.

또한 MCP는 컨텍스트 창을 마법처럼 무한대로 늘려주지 않는다. 오히려 잘못 설치하면 에이전트가 코드보다 도구 설명을 더 많이 고려하게 된다. MCP는 컨텍스트 관리의 대체재가 아니라, 컨텍스트를 더 정확하게 가져오기 위한 통로다.

추천 시작 구성

처음 MCP를 구성한다면 아래처럼 시작하자.

개인 전역 설정에는 다음 네 가지 정도면 충분하다.

{
  "mcpServers": {
    "sequentialthinking": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
    },
    "time": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-time"]
    },
    "github": {
      "url": "https://mcp.github.com",
      "headers": {
        "Authorization": "Bearer ${GITHUB_TOKEN}"
      }
    },
    "docs": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }
  }
}

제품 프로젝트의 로컬 설정에는 처음부터 모든 것을 넣지 말고, 현재 병목에 맞춰 하나만 추가한다.

{
  "mcpServers": {
    "app-postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "${APP_READONLY_DATABASE_URL}"
      }
    }
  }
}

UI 구현이 병목이면 Postgres 대신 Figma를 넣는다. 장애 대응이 병목이면 Sentry를 넣는다. 고객 피드백 정리가 병목이면 Slack을 넣는다. "언젠가 쓸 것 같아서" 설치하지 말고, "오늘 이 작업을 줄이기 위해" 설치하자.

상황별 추천 조합

새 SaaS 제품을 만드는 중이라면

처음에는 GitHub, sequentialthinking, time, 문서 MCP 정도로 충분하다. 백엔드 스키마가 생기면 Postgres를 추가하고, 배포 후 에러가 쌓이기 시작하면 Sentry를 붙인다. 디자인 시스템이 Figma에 있다면 Figma MCP를 프로젝트 로컬로 추가한다.

이 조합의 목표는 기획, 구현, 검증의 루프를 줄이는 것이다. GitHub에서 이슈를 읽고, sequentialthinking으로 계획을 세우고, Postgres로 실제 스키마를 확인하고, Sentry로 운영 에러를 다시 코드 수정으로 가져온다.

랜딩 페이지와 UI 작업이 많다면

Figma, Playwright, GitHub, time 조합이 좋다. Figma로 디자인 구조를 읽고, Cursor가 구현한 뒤, Playwright로 실제 브라우저에서 확인한다. GitHub는 변경사항을 PR로 묶고, time은 예약 공개나 캠페인 일정 계산에 쓴다.

이때 Postgres나 Slack은 당장 필요하지 않을 수 있다. UI 작업 중에는 도구를 적게 유지하는 편이 좋다. 디자인과 브라우저 검증에 집중하자.

이미 운영 중인 제품이라면

Sentry, Postgres, GitHub, Slack 조합이 강력하다. Sentry에서 에러를 찾고, Postgres에서 영향 범위를 확인하고, GitHub에서 수정 이슈와 PR을 만들고, Slack에서 고객 제보나 운영 알림을 확인한다.

단, 이 조합은 권한이 강하다. production 접근은 읽기 전용으로 묶고, Slack은 특정 채널만 허용하며, GitHub 쓰기 권한은 필요한 범위로 제한해야 한다. 운영 중인 제품에는 "편리함"보다 "되돌릴 수 있음"이 중요하다.

데이터 분석과 리포트가 많다면

Postgres, time, 문서 MCP, GitHub 조합이 좋다. "지난 30일 활성 사용자", "구독 전환율", "기능별 사용량" 같은 질문을 Cursor에게 시키려면 DB 읽기 권한과 시간 계산이 중요하다.

다만 Cursor를 BI 도구처럼 쓰기 시작하면 위험하다. 에이전트가 생성한 SQL은 항상 확인하고, production 원본 DB가 아니라 replica나 warehouse를 쓰는 편이 좋다. 분석용 뷰를 따로 만들어두면 더 안전하다.

설치 전 체크리스트

MCP 서버를 하나 추가하기 전에 아래 질문에 답해보자.

• 이 MCP가 지금 내 작업 시간을 실제로 줄여주는가?

• 같은 목적의 MCP가 이미 켜져 있지는 않은가?

• 이 서버가 노출하는 도구 수는 몇 개인가?

• 읽기 권한만으로 충분한가, 정말 쓰기 권한이 필요한가?

• 토큰은 최소 권한과 만료 기간을 갖고 있는가?

• 설정 파일에 비밀 값이 직접 들어가 있지는 않은가?

• production 데이터나 결제 시스템에 직접 접근하지 않는가?

• 문제가 생겼을 때 이 MCP를 즉시 끌 수 있는가?

이 질문에 답하기 어렵다면 아직 설치하지 않는 편이 낫다. MCP는 나중에 붙여도 늦지 않다. 오히려 너무 일찍 붙이면 워크플로우가 복잡해진다.

제거 기준도 정해두기

도입 기준만큼 중요한 것이 제거 기준이다. MCP는 설치보다 방치가 더 위험하다. 토큰이 만료되었거나, 서버가 오래 업데이트되지 않았거나, 더 이상 쓰지 않는 도구가 남아 있으면 보안과 성능 양쪽에서 손해다.

한 달에 한 번 정도 MCP 설정을 열고 다음을 확인하자.

• 최근 한 달간 실제로 사용한 서버만 남긴다.

• 빨간 상태로 실패하는 서버는 고치거나 제거한다.

• 토큰 권한과 만료일을 확인한다.

• production 접근이 생겼다면 읽기 전용인지 다시 확인한다.

• 도구 수가 늘었다면 비활성화할 도구를 고른다.

솔로 메이커의 장점은 가볍게 움직일 수 있다는 것이다. MCP 구성도 가벼워야 한다. 지금 필요한 연결만 남겨두고, 나머지는 과감히 끄자.

마지막 추천: 세 개만 고르라면

만약 딱 세 개만 고르라면, 대부분의 솔로 메이커에게는 다음 구성을 추천한다.

첫 번째는 GitHub다. 이슈, PR, 코드 검색, 릴리즈 흐름이 연결되면 Cursor가 단순 코드 작성기를 넘어 작업 관리자처럼 움직일 수 있다.

두 번째는 Postgres 또는 Figma다. 백엔드 중심 제품이면 Postgres, UI 중심 제품이면 Figma를 고른다. 둘 다 "Cursor가 추측하지 않게 만드는 도구"다. 실제 스키마나 실제 디자인을 보게 하는 것만으로 결과 품질이 달라진다.

세 번째는 Sentry 또는 sequentialthinking이다. 이미 운영 중이라면 Sentry가 우선이다. 아직 만드는 중이라면 sequentialthinking이 더 낫다. 전자는 현실의 에러를 코드 수정으로 연결하고, 후자는 복잡한 작업을 안전한 계획으로 바꾼다.

MCP의 목적은 Cursor를 만능 로봇으로 만드는 것이 아니다. Cursor가 모르는 현실을 필요한 만큼만 보여주는 것이다. GitHub의 이슈, Postgres의 스키마, Figma의 디자인, Sentry의 에러, Slack의 대화. 그중 지금 제품을 앞으로 밀어주는 것부터 하나씩 연결하자. 잘 고른 MCP 하나는 열 개의 장식용 도구보다 낫다.

참고

¹Cursor Marketplace

²Cursor Docs

³Cursor MCP Servers: Setup Guide + Best Servers List (2026)

⁴MCP Servers in Cursor: Setup, Configuration, and Security (2026 Guide)

⁵Best MCP Servers for Cursor - CURSOR MCP

⁶Cursor MCP Server Setup Guide