Cursor 밖의 일을 Cursor 안으로 가져오기
Cursor를 오래 쓰다 보면 한계가 분명해진다. 코드는 잘 읽고 고치지만, 제품을 운영하는 데 필요한 정보는 대부분 편집기 밖에 있다. 이슈는 GitHub에 있고, 디자인은 Figma에 있고, 에러는 Sentry에 있고, 고객 피드백은 Slack에 있으며, 실제 데이터는 데이터베이스에 있다.
이때 솔로 메이커는 계속 창을 옮겨 다닌다. 에러 로그를 복사해 Cursor에 붙여 넣고, GitHub PR 링크를 열고, Figma 값을 확인하고, 다시 코드로 돌아온다. 이 과정에서 시간보다 더 많이 잃는 것은 맥락이다.
MCP는 이 문제를 줄이기 위한 연결 계층이다. Model Context Protocol, 즉 MCP는 AI 애플리케이션이 로컬 파일, 데이터베이스, 외부 도구, 작업 흐름에 표준 방식으로 연결되도록 만든 오픈 표준이다. 공식 문서에서는 이를 "AI 애플리케이션을 위한 USB-C 포트"에 비유한다.1 도구마다 다른 방식으로 붙는 대신, Cursor가 하나의 공통 규칙으로 외부 시스템을 읽고 사용할 수 있게 만드는 것이다.
중요한 변화는 이것이다. Cursor는 더 이상 코드 편집기 안에 갇힌 도구가 아니다. MCP를 붙이면 Cursor는 제품 운영 시스템의 허브가 된다. 코드 수정, 이슈 조사, 디자인 확인, 장애 분석, PR 검토를 하나의 대화 흐름 안에서 이어갈 수 있다.
AI 생성 이미지
MCP는 어떻게 동작하는가
MCP를 실무적으로 이해하는 방식은 단순하다.
Cursor가 MCP 클라이언트 역할을 하고, GitHub·Figma·Sentry·데이터베이스 같은 외부 도구가 MCP 서버로 붙는다. 사용자가 Cursor에서 "최근 Sentry 이슈 중 결제 관련 오류를 찾아줘"라고 요청하면, Cursor는 연결된 Sentry MCP 서버에 필요한 도구 호출을 보낸다. 서버는 외부 시스템에서 데이터를 가져오고, Cursor는 그 결과를 바탕으로 코드와 함께 분석한다.
이때 서버와 클라이언트는 보통 JSON-RPC 기반 메시지로 통신한다. JSON-RPC는 JSON 형식으로 "어떤 함수를 어떤 인자로 호출할지" 표현하는 가벼운 통신 방식이다. 개발자가 직접 이 프로토콜을 매일 다룰 일은 많지 않지만, 원리를 알고 있으면 문제를 진단하기 쉽다. MCP 서버는 마법이 아니라 "AI가 호출할 수 있는 도구 목록"을 제공하는 작은 프로그램이다.
전송 방식은 크게 두 가지로 볼 수 있다.
stdio: 로컬에서 실행되는 MCP 서버와 표준 입력·출력으로 통신한다. 로컬 Git, 내부 스크립트, Docker로 띄운 도구에 어울린다.
HTTP / Streamable HTTP: 원격 서버 URL에 연결한다. GitHub, Sentry, Figma처럼 클라우드 서비스와 연결할 때 자주 사용한다.
따라서 MCP 설정을 볼 때는 세 가지를 확인하면 된다.
이 서버는 로컬에서 실행되는가, 원격 URL로 연결되는가?
인증은 PAT, OAuth, 환경 변수 중 무엇을 쓰는가?
이 서버가 읽기만 할 수 있는가, 쓰기나 삭제도 할 수 있는가?
세 번째 질문이 가장 중요하다. MCP는 Cursor를 강하게 만들지만, 동시에 Cursor가 건드릴 수 있는 표면도 넓힌다.
전역 설정과 프로젝트 설정을 나누기
Cursor의 MCP 설정은 크게 두 위치에 둔다.
~/.cursor/mcp.json # 사용자 전역 설정
.cursor/mcp.json # 프로젝트별 설정전역 설정은 개인 계정과 강하게 연결된 도구에 적합하다. GitHub, Sentry, Slack처럼 OAuth나 PAT가 필요한 도구가 여기에 해당한다. 같은 노트북에서 여러 프로젝트를 열어도 개인 인증은 한곳에서 관리하는 편이 편하다.
프로젝트 설정은 저장소와 함께 재현되어야 하는 도구에 적합하다. 예를 들어 로컬 개발용 Postgres MCP, 프로젝트 전용 문서 검색 서버, 내부 API 스키마 조회 도구는 .cursor/mcp.json에 두는 편이 낫다. 이렇게 하면 나중에 다른 환경에서 프로젝트를 열어도 "이 제품은 어떤 외부 도구와 연결되는지" 알 수 있다.
다만 비밀값은 저장소에 넣지 않는다. 토큰, PAT, API 키, 데이터베이스 비밀번호는 환경 변수나 개인 설정에 둔다. .cursor/mcp.json을 커밋할 때는 다음 원칙을 지킨다.
서버 이름과 실행 방식은 커밋해도 된다.
실제 토큰과 비밀번호는 커밋하지 않는다.
production 데이터베이스 연결은 기본값으로 넣지 않는다.
읽기 전용 계정을 먼저 만든다.
쓰기 권한이 필요한 MCP는 별도 승인 절차를 둔다.
MCP는 편리함의 문제가 아니라 권한 설계의 문제다.
GitHub MCP: 이슈와 PR 맥락을 가져오기
GitHub MCP는 가장 먼저 연결해 볼 만한 서버다. 솔로 메이커에게 GitHub는 코드 저장소이면서 이슈 관리 도구이고, PR 리뷰 공간이며, 배포 흐름의 출발점이기 때문이다.
GitHub 공식 MCP 서버를 Cursor에서 사용할 때는 원격 서버 방식이 권장된다. 설정은 전역 MCP 파일인 ~/.cursor/mcp.json에 추가할 수 있다. 공식 설치 가이드는 GitHub 호스팅 서버 URL로 https://api.githubcopilot.com/mcp/를 사용하며, Streamable HTTP를 지원하는 Cursor 버전과 GitHub PAT가 필요하다고 안내한다.2
예시는 다음과 같다.
{
"mcpServers": {
"github": {
"url": "https://api.githubcopilot.com/mcp/",
"headers": {
"Authorization": "Bearer YOUR_GITHUB_PAT"
}
}
}
}로컬 방식도 가능하다. 이 경우 Docker가 필요하고, 공식 Docker 이미지를 실행해 GitHub MCP 서버를 띄운다.2
{
"mcpServers": {
"github": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"GITHUB_PERSONAL_ACCESS_TOKEN",
"ghcr.io/github/github-mcp-server"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "YOUR_GITHUB_PAT"
}
}
}
}처음 연결했을 때는 쓰기 작업부터 시도하지 않는다. 다음처럼 읽기 중심으로 검증한다.
내 GitHub 저장소 목록을 보여줘.
이 저장소의 열린 이슈를 우선순위별로 요약해줘.
최근 PR에서 결제 관련 변경이 있었는지 찾아줘.GitHub MCP의 첫 목적은 "Cursor가 GitHub를 대신 조작하게 하는 것"이 아니다. 먼저 Cursor가 이슈, PR, 브랜치 맥락을 이해하게 만드는 것이다. 이 기반이 생기면 Agent에게 작업을 맡길 때 설명해야 할 양이 줄어든다.
Figma MCP: 디자인을 코드 옆에 두기
UI 작업에서 가장 흔한 낭비는 디자인과 코드 사이의 번역이다. Figma에서는 간격, 변수, 컴포넌트 이름이 보이지만, Cursor는 그 맥락을 모른다. 그래서 개발자는 값을 눈으로 확인하고, 복사하고, 추측하고, 다시 브라우저에서 비교한다.
Figma MCP는 이 간격을 줄인다. Figma 공식 안내에 따르면 Cursor 채팅에서 /add-plugin figma를 입력해 플러그인을 추가하고, Cursor 설정의 Tools & MCP에서 연결과 인증을 완료할 수 있다.3 연결이 끝나면 Cursor는 Figma의 컴포넌트, 변수, 레이아웃 데이터, FigJam 콘텐츠 같은 정보를 참고할 수 있다.3
사용 방식은 이렇게 시작하는 것이 좋다.
선택한 Figma 프레임을 기준으로 UI 구조를 분석해줘.
아직 코드는 작성하지 말고, 컴포넌트 계층과 필요한 상태를 먼저 정리해줘.
이 디자인에서 사용된 색상과 spacing token을 찾아서
현재 프로젝트의 design token과 매핑해줘.여기서 중요한 점은 Figma 레이어를 그대로 코드 구조로 옮기지 않는 것이다. 디자인 파일의 레이어 구조는 디자이너의 작업 편의를 위해 만들어진 경우가 많다. 코드에서는 재사용성, 상태 관리, 접근성, 반응형 구조가 더 중요하다.
Figma MCP는 정답 코드를 만들어 주는 도구가 아니다. 디자인 의도를 Cursor가 더 잘 읽도록 돕는 통역사다.
Sentry MCP: 운영 에러를 코드와 연결하기
제품을 출시한 뒤에는 코드보다 운영 정보가 더 중요해지는 순간이 온다. 사용자는 "버튼이 안 눌려요"라고 말하지만, 실제 문제는 특정 API의 500 에러일 수도 있고, 배포 직후 생긴 타입 불일치일 수도 있다.
Sentry MCP는 이런 운영 맥락을 Cursor 안으로 가져온다. Sentry의 안내에 따르면 Cursor의 Settings → Tools & Integrations → New MCP Server에서 전역 MCP 서버로 다음 설정을 추가할 수 있다.4
{
"mcpServers": {
"sentry": {
"url": "https://mcp.sentry.dev/mcp"
}
}
}저장 후 OAuth로 Sentry 계정 인증을 마치면, Cursor에서 조직, 프로젝트, 이슈를 조회할 수 있다. 연결 확인은 다음 질문으로 시작할 수 있다.
내가 접근할 수 있는 Sentry 조직을 보여줘.Sentry MCP가 유용한 이유는 단순히 에러 목록을 가져오기 때문이 아니다. 최신 이슈, stack trace, 파일과 라인 번호, 발생 빈도, 사용자 영향, 배포 시점과의 관계 같은 디버깅 맥락을 코드 옆에 놓을 수 있기 때문이다.4
예를 들어 다음과 같이 요청할 수 있다.
지난 24시간 동안 unresolved 상태인 결제 관련 Sentry 이슈를 찾아줘.
사용자 영향이 큰 순서로 정리하고,
각 이슈의 stack trace가 가리키는 코드 파일을 함께 알려줘.
아직 수정하지 말고 원인 후보만 제시해줘.이 프롬프트에서 핵심은 "아직 수정하지 말고"다. 운영 데이터가 연결되면 Agent가 더 자신 있게 움직일 수 있다. 그래서 더더욱 조사, 계획, 구현을 분리해야 한다.
데이터베이스 MCP는 가장 조심스럽게
데이터베이스 MCP는 강력하다. 실제 스키마를 확인하고, 샘플 데이터를 살펴보고, 버그가 특정 사용자군에서만 발생하는지 조사할 수 있다. 하지만 가장 위험한 MCP이기도 하다.
솔로 메이커는 특히 다음 원칙을 지켜야 한다.
production DB는 기본적으로 읽기 전용 계정만 연결한다.
가능하면 staging 또는 anonymized replica를 먼저 연결한다.
개인정보, 결제 정보, 토큰, 세션 값은 조회 대상에서 제외한다.
DELETE,UPDATE, migration 실행 권한은 MCP에 주지 않는다.데이터 수정은 Agent가 아니라 사람이 별도 절차로 수행한다.
좋은 데이터베이스 MCP 사용 예시는 이런 것이다.
staging DB에서 subscriptions 테이블 구조를 확인해줘.
최근 실패한 결제 웹훅과 관련될 수 있는 컬럼을 설명해줘.
데이터는 집계 수준으로만 보고, 개인정보는 조회하지 마.나쁜 예시는 이런 것이다.
production DB에서 이상한 결제 데이터를 찾아서 고쳐줘.후자는 빠른 길처럼 보이지만, 실제로는 사고를 부르는 지시다. MCP를 붙인 Agent는 사용자의 권한을 빌려 움직인다. 권한이 크면 실수의 반경도 커진다.
MCP를 붙일 때의 기본 순서
처음부터 GitHub, Figma, Sentry, Slack, Postgres를 모두 붙이지 말자. 도구가 많아지면 Agent는 어떤 도구를 써야 할지 혼란스러워지고, 사용자는 어떤 권한이 열려 있는지 잊기 쉽다.
추천 순서는 다음과 같다.
읽기 전용 도구 하나로 시작한다. GitHub 저장소 목록 조회나 Sentry 조직 조회처럼 안전한 작업을 고른다.
Tools & MCP에서 초록색 연결 상태를 확인한다. 연결이 안 되면 설정 파일, URL, 토큰, OAuth 계정을 점검한다.
짧은 테스트 프롬프트를 실행한다. "내 저장소 목록 보여줘", "Sentry 조직 보여줘"처럼 단순한 질문으로 확인한다.
작업 프롬프트에 도구 사용 범위를 명시한다. "GitHub 이슈만 읽고 코드는 수정하지 마"처럼 제한을 둔다.
성공한 설정만 남긴다. 쓰지 않는 MCP 서버는 비활성화한다.
MCP는 많이 붙일수록 좋은 시스템이 아니다. 필요한 순간에 필요한 서버만 켜는 시스템이 좋다.
솔로 메이커의 MCP 안전선
MCP를 도입할 때는 다음 문장을 기준으로 삼자.
Agent에게 줄 수 없는 권한은 MCP에도 주지 않는다.
특히 다음 영역은 기본적으로 사람 승인을 요구해야 한다.
production 데이터 수정
결제 상태 변경
사용자 권한 변경
계정 삭제 또는 데이터 삭제
이메일 대량 발송
외부 고객에게 메시지 전송
배포 실행
secret, token, private key 접근
반대로 MCP에 잘 맡길 수 있는 일도 있다.
GitHub 이슈 요약
PR 변경 범위 파악
Sentry 이슈와 stack trace 정리
Figma 디자인 토큰 확인
Slack 피드백을 요구사항 초안으로 정리
staging 데이터 기준의 원인 조사
장애 보고서 초안 작성
핵심은 읽기와 쓰기를 분리하는 것이다. 읽기는 Agent에게 넓게 맡길 수 있다. 쓰기는 좁게 열고, 중요한 쓰기는 사람이 승인한다.
연결보다 중요한 것은 운영 방식이다
MCP를 붙이면 Cursor는 훨씬 강력해진다. 하지만 강력함이 곧 좋은 워크플로우는 아니다. GitHub를 연결했다고 좋은 이슈 관리가 되는 것은 아니고, Sentry를 연결했다고 자동으로 좋은 디버깅이 되는 것도 아니다.
좋은 흐름은 항상 같다.
외부 시스템에서 사실을 가져온다.
Cursor에게 원인 후보를 정리하게 한다.
Plan Mode로 수정 범위와 검증 방법을 세운다.
작은 단위로 구현한다.
테스트와 diff를 사람이 확인한다.
필요한 경우 PR, 이슈, 운영 문서를 업데이트한다.
MCP는 이 흐름의 첫 단계를 강하게 만든다. Cursor가 더 많은 사실을 볼 수 있게 해준다. 그러나 최종 판단은 여전히 사람의 일이다.
솔로 메이커에게 MCP의 가치는 "AI가 모든 도구를 마음대로 쓰게 하는 것"이 아니다. 흩어진 제품 운영 정보를 한곳에 모아, 더 적은 전환 비용으로 더 나은 판단을 하게 만드는 것이다. Cursor는 코드를 고치는 도구에서 출발했지만, MCP를 통해 제품을 이해하고 운영하는 작업대로 확장된다.
참고
1What is the Model Context Protocol (MCP)?
2GitHub MCP Server Cursor 설치 가이드
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.