Cursor·Copilot·Windsurf로 “AI를 팀원처럼” 쓰는 법 (2026년 6월판): Rules/MCP/Agent를 프로젝트에 안전하게 붙이는 실전 튜토리얼

게시 2026/06/28

By Daewook Kwon

16 분읽는 시간

들어가며

AI 코딩 어시스턴트의 진짜 병목은 “코드 생성 능력”이 아니라 컨텍스트 주입(규칙/문서/레포 구조) + 실행 권한(터미널/PR/외부 API) + 비용 통제입니다. 2026년 6월 시점의 Cursor / GitHub Copilot / Windsurf(Cascade)는 모두 agentic workflow로 수렴했고, MCP(Model Context Protocol) 같은 표준을 통해 “IDE 밖 정보/도구”까지 연결되기 시작했습니다. Cursor는 Agent 실행 승인 흐름을 “Auto-review run mode”로 강화했고(쉘/MCP/Fetch 중심), Windsurf는 Cascade에서 MCP를 설정 파일로 직접 제어하며 도구 수 제한(최대 100)을 명시합니다. (cursor.com)

언제 쓰면 좋은가

모노레포/마이크로서비스처럼 “변경 범위가 넓고 반복 작업(스캐폴딩/리팩터/테스트 보강)”이 잦을 때
PR 단위로 diff → 테스트 → 린트 → 수정 루프를 자동화하고 싶을 때
MCP로 GitHub/Jira/DB/문서 인덱스 등을 연결해 “복붙 컨텍스트”를 줄이고 싶을 때 (windsurf.com)

언제 쓰면 안 되는가

규제/보안상 코드를 외부 모델로 보내기 어려운데, 사내 정책/격리 실행/감사 로깅이 준비되지 않았을 때(특히 Agent의 Shell 실행)
비용 상한이 없는 상태에서 대형 레포 전체를 지속 스캔하게 만들 때(2026-06-01 이후 Copilot은 AI Credits 기반 과금 전환 이슈가 크게 체감됨) (heresthebest.com)
“정확한 설계 의도” 없이 AI에게 통째로 위임할 때: 결과는 나오지만 아키텍처 부채가 더 빨리 쌓입니다.

🔧 핵심 개념

1) Rules/Instructions = “지속 컨텍스트 레이어”

LLM은 기본적으로 상태를 기억하지 않습니다. 그래서 2026년형 도구들은 모두 프로젝트 단위의 규칙 파일을 “프롬프트 앞단에 자동 삽입”하는 방식으로 일관성을 만듭니다.

Cursor: .cursor/rules/*.mdc에 Project Rules를 두고, Always / Auto Attached(글롭) / ... 방식으로 적용 범위를 제어합니다. 레거시 .cursorrules는 deprecated. (docs.cursor.com)
Copilot: 레포/워크스페이스에 instructions 파일을 두는 패턴이 정착(에코시스템에서 .github/copilot-instructions.md가 널리 언급). (reddit.com)
Windsurf(Cascade): .codeiumignore로 컨텍스트에서 제외할 파일을 통제하고, “Write/Chat” 모드로 변경 권한과 상호작용 성격을 분리합니다. (docs.codeium.org.cn)

핵심은 “규칙을 글로 잘 쓰기”가 아니라, 규칙을 (1) 범위 스코프, (2) 변경 정책, (3) 검증 규칙(테스트/린트)까지 포함한 실행 가능한 계약으로 만드는 겁니다.

2) MCP = “툴 접근 표준 인터페이스”

MCP는 에이전트가 외부 시스템(예: GitHub, DB, 사내 API)에 접근할 때, 각 서비스별 SDK를 붙이는 대신 표준화된 서버(tool provider)로 연결하는 방식입니다.

Windsurf: ~/.codeium/windsurf/mcp_config.json에 MCP 서버를 선언하고, Cascade는 stdio / Streamable HTTP / SSE 트랜스포트를 지원합니다. 또한 “활성 툴 총합 100개 제한”을 명시합니다. (docs.windsurf.com)
Copilot CLI: MCP 서버 생태계를 공식적으로 언급하며, 상호작용은 플랜의 AI Credits를 소모합니다. (github.com)

이 구조가 중요한 이유: “컨텍스트(읽기)”와 “행동(쓰기/실행)”을 분리해 거버넌스를 걸 수 있기 때문입니다. 예를 들어 GitHub MCP는 issue/PR 조회는 허용하되, merge는 막는 식의 운영이 가능해집니다(조직 정책과 결합).

3) Agent 실행 모델: 승인(Approvals)과 샌드박스

Agent가 강해질수록 위험도 커집니다. Cursor는 “Auto-review Run Mode”에서 Shell/MCP/Fetch 호출을 allowlist/샌드박스/분류(subagent)로 나눠 더 오래 작업하게 하되 위험을 줄이려는 방향을 공개했습니다. (cursor.com)
이 관점에서 보면, 생산성은 단순히 “자동 수정”이 아니라 “안전하게 오래 돌릴 수 있는 실행 파이프라인”에서 나옵니다.

💻 실전 코드

아래는 “내 프로젝트에 바로 적용”을 목표로 한 예시입니다. 시나리오: TypeScript(Node.js) 모노레포에서 API 변경이 발생했고, AI agent가 PR 단위로 변경을 끝내려면 (1) 규칙, (2) MCP(GitHub), (3) 로컬 검증 커맨드가 일관되게 제공돼야 합니다.

0) 전제: 레포 구조(예시)

apps/api : Express/Fastify API
packages/sdk : API client SDK
packages/shared : zod 스키마, 유틸
테스트: pnpm -r test, 린트: pnpm -r lint

1) Cursor Rules로 “변경 정책 + 검증 루프” 고정

Cursor는 .cursor/rules/*.mdc 기반 Project Rules를 권장합니다. (docs.cursor.com)
아래 규칙은 agent가 바꾼 뒤 반드시 검증하고, 실패 시 “최소 수정”으로 되돌리게 만드는 장치입니다.

  
mkdir -p .cursor/rules
cat > .cursor/rules/monorepo-quality-gate.mdc <<'EOF'
---
description: "Monorepo quality gate for agent edits"
alwaysApply: true
---

You are editing a pnpm monorepo.

Hard rules:
1) Never change generated files, lockfiles, or snapshots unless explicitly asked.
2) For any API contract change, you MUST update:
   - apps/api handlers + validators
   - packages/sdk client types
   - relevant tests
3) After edits, run:
   - pnpm -r lint
   - pnpm -r test
4) If tests fail, fix with the smallest possible diff. Do NOT refactor unrelated code.
5) Prefer adding regression tests over adding comments.
EOF

의도: “AI가 열심히 일하다가 레포를 갈아엎는” 패턴을 규칙으로 차단합니다. (이 한 파일이 팀의 AI 사용 기준선이 됩니다.)

2) Windsurf(Cascade) MCP: GitHub 서버 연결(설정 파일)

Windsurf 문서에 따르면 Cascade의 MCP 서버 목록은 ~/.codeium/windsurf/mcp_config.json로 관리합니다. (docs.windsurf.com)
GitHub MCP를 붙여서 “이슈/PR 요구사항 → 변경 범위 결정”을 자동화할 수 있습니다.

  
mkdir -p ~/.codeium/windsurf

cat > ~/.codeium/windsurf/mcp_config.json <<'EOF'
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "REPLACE_ME"
      }
    }
  }
}
EOF

예상 동작

Cascade에서 MCPs 메뉴/설정으로 서버가 인식됨
Cascade가 github tool을 통해 issue/PR 내용을 읽고, 체크리스트를 만들고, 필요한 파일 변경을 제안

현실 체크

Windsurf는 “활성 툴 총합 100개 제한”이 있으니 MCP 서버를 많이 붙이기보다, 레포에서 필요한 것만 켜는 쪽이 안전합니다. (docs.windsurf.com)

3) “프로젝트에서 바로 먹히는” 현실적 작업 프롬프트(예시)

아래 프롬프트는 Cursor/Windsurf/Copilot 공통으로 통합니다. 핵심은 (1) 작업 경계, (2) 검증 커맨드, (3) 산출물 형태를 고정하는 겁니다.

Goal:
- Implement API change: POST /v1/orders now requires "idempotencyKey" header.
- Update SDK in packages/sdk accordingly.
- Add regression tests.

Constraints:
- Touch only: apps/api/**, packages/sdk/**, packages/shared/**, tests/**
- Run: pnpm -r lint && pnpm -r test
- If failing, fix minimally.

Deliverables:
1) List impacted files
2) Step-by-step plan
3) Apply changes
4) Paste test output summary

왜 이렇게 쓰나

Agent가 “계획 → 실행 → 검증” 루프를 강제로 밟게 하면, 단발성 코드 생성보다 성공률이 올라갑니다.
변경 범위(allowed paths)를 제한하면, 대형 레포에서 컨텍스트 폭발/비용 폭발을 줄일 수 있습니다(특히 Credits 과금 체계에서). (heresthebest.com)

⚡ 실전 팁 & 함정

Best Practice (2~3)

1) Rules는 ‘코딩 스타일’보다 ‘품질 게이트’에 투자

포맷팅/네이밍보다 “무조건 테스트 실행, 실패 시 최소 수정” 같은 운영 규칙이 ROI가 큽니다.
Cursor는 Rules가 “지속 컨텍스트로 모델 앞단에 포함”된다고 명시합니다. 즉 규칙은 항상 적용되는 프롬프트 코드입니다. (docs.cursor.com)

2) MCP는 ‘정보 읽기’부터 붙이고, ‘쓰기/실행’은 마지막에

처음부터 Jira/GitHub/DB write 권한을 열면 사고가 납니다.
Windsurf도 MCP 연결은 쉽지만, 툴 수/구성 복잡도가 곧 안정성 리스크가 됩니다(툴 100개 제한). (docs.windsurf.com)

3) Agent 실행 모드는 “승인 전략”이 곧 생산성

Cursor의 Auto-review는 Shell/MCP/Fetch 호출을 더 오래 돌리게 하되 allowlist/샌드박스/분류로 통제합니다. 팀에서 이 철학(무엇은 자동, 무엇은 승인)을 먼저 합의해야 합니다. (cursor.com)

흔한 함정/안티패턴

“레포 전체를 읽고 알아서 해줘”: 컨텍스트/토큰/크레딧이 터지고, 변경이 산만해집니다.
MCP 서버를 잔뜩 켜서 ‘만능 에이전트’ 만들기: 툴 선택이 흔들리면 답변도 흔들립니다(게다가 Windsurf는 도구 제한이 명시돼 있음). (docs.windsurf.com)
검증 없는 자동 커밋/대규모 리팩터: 나중에 사람이 롤백 비용을 지불합니다. “테스트 통과”를 AI 작업의 Definition of Done으로 못 박아야 합니다.

비용/성능/안정성 트레이드오프

Copilot: 2026-06-01 전후로 AI Credits 기반 과금 전환이 언급되며, “대화/에이전트 작업을 얼마나 돌리느냐”가 비용이 됩니다. 반복 프롬프트/대형 컨텍스트는 곧 비용. (heresthebest.com)
Cursor/Windsurf: 모델 선택 자유도가 높을수록(다양한 frontier 모델) 품질은 올라가도 비용/지연/정책 이슈가 생깁니다. 실무에서는 “작업 유형별 모델/모드 고정”이 안정적입니다.
안정성: Agent가 Shell/MCP까지 실행하는 순간, IDE는 “코드 편집기”가 아니라 “자동 실행기”가 됩니다. 승인/샌드박스/권한 분리가 필수입니다. (cursor.com)

🚀 마무리

2026년 6월 기준으로 Cursor·Copilot·Windsurf의 공통 분모는 명확합니다: Rules/Instructions로 지속 컨텍스트를 고정하고, MCP로 외부 도구를 표준 연결하며, Agent 실행을 승인/샌드박스로 통제하는 쪽이 “진짜 생산성”을 만듭니다. (docs.cursor.com)

도입 판단 기준(현실적인 체크리스트)

레포에 “AI 품질 게이트 규칙(테스트/린트/변경 범위)”을 넣을 수 있는가?
MCP로 가져오고 싶은 핵심 컨텍스트가 명확한가? (GitHub/문서/DB 중 1~2개로 시작)
비용 상한(크레딧/토큰)과 승인 정책(무자동/반자동/자동)을 팀 합의로 문서화했는가?

다음 학습 추천

Cursor: .cursor/rules 스코프 전략(글롭/alwaysApply)과 Agent 승인 설정(특히 Auto-review)의 운영 가이드 정리 (docs.cursor.com)
Windsurf: mcp_config.json 기반 MCP 서버 최소 구성 → 툴 개수/권한을 점진적으로 확장 (docs.windsurf.com)
Copilot: Copilot CLI + MCP 생태계로 “IDE 밖 자동화”를 붙이되, AI Credits 소모를 측정 가능한 작업부터 적용 (github.com)

AI, Coding

ai coding trend 2026-06