MCP(Model Context Protocol)를 둘러싼 논의가 '무엇을 설치하면 좋은가'에서 '어떻게 팀 인프라로 굳히는가'로 빠르게 이동하고 있다. dev.to에 올라온 두 편의 실사용 보고서와 국내 개발자의 Shrimp Task Manager 적용기를 나란히 읽으면, 공통된 패턴이 보인다. MCP 서버 하나하나는 단순한 API 래퍼지만, 이것들이 체계적으로 연결될 때 '도구 묶음'이 아니라 '자동화 파이프라인'이 된다.
핵심 이슈: MCP는 개인 생산성 도구가 아니다
dev.to의 Kjetil Furas는 Claude Code에 MCP 서버 9개를 붙여 3개월간 운영한 결과를 공개했다. 그가 강조하는 선택 기준은 단순하다. "일주일에 두 번 이상 손으로 하는 작업이 있는가." GitHub stars 기준이 아니라 실제 수작업 대체율 기준이다. Context7로 라이브 문서를 끌어오고, YouTube Analytics MCP로 15분짜리 주간 리포트를 30초로 줄이고, GSC MCP로 키워드 분석부터 블로그 발행까지 터미널 밖을 나가지 않는다. 각 서버가 대체한 것은 '기능'이 아니라 '컨텍스트 전환 비용'이다.
이 관점을 팀 단위로 확장한 것이 Swrly의 DevOps AI 워크플로우 사례다. PagerDuty 웹훅이 새벽 2시에 터지면, 기존엔 온콜 엔지니어가 알림 확인 → 최근 배포 확인 → 에러 로그 확인 → 심각도 판단 → 알림 전파 순서를 손으로 밟았다. Swrly 기반 인시던트 대응 워크플로우는 이 시퀀스를 멀티에이전트로 대체한다. PagerDuty 노드와 Sentry 노드가 병렬 실행으로 데이터를 동시에 수집하고, Incident Analyst 에이전트가 세 소스(PagerDuty·Sentry·GitHub 커밋 이력)를 상관 분석해 근본 원인 가설과 심각도를 구조화된 JSON으로 뱉는다. Incident Responder 에이전트가 그 결과를 받아 단계별 런북과 이해관계자 커뮤니케이션 템플릿을 생성하고, 컨디션 노드가 심각도에 따라 #incidents-critical 또는 #ops-log로 라우팅한다. 온콜 엔지니어가 Slack을 열면 이미 분석 결과와 대응 지침이 기다리고 있다.
맥락 해석: 자동화의 단위는 '기능'이 아니라 '시퀀스'다
세 사례를 관통하는 설계 원칙은 동일하다. 자동화할 가치가 있는 것은 단일 작업이 아니라 반복되는 작업 시퀀스다. Shrimp Task Manager 적용기가 특히 흥미로운 이유가 여기 있다. ROADMAP.md 하나를 Claude에 넘기면 plan_task가 실행 가능한 태스크 목록으로 변환하고, split_tasks가 과도하게 큰 태스크를 적절한 단위로 분할하고, execute_task와 verify_task가 실행·검증 루프를 돌린다. 검증 실패 시 자동으로 재작업에 들어간다. 필자가 표현한 변화가 정확하다. "계획 짜는 사람"에서 "결과 검토하는 사람"으로의 역할 이동.
이 역할 이동은 팀 수준에서도 동일하게 작동한다. Swrly의 배포 모니터링 워크플로우는 30분 크론으로 돌면서 Sentry 에러 볼륨을 AI 에이전트가 분석한다. 기존의 임계치 기반 알림이 놓치는 패턴—"auth 모듈에서 마지막 배포 20분 후 새로운 TypeError 3건 발생"—을 감지하는 게 핵심이다. 규칙이 아니라 패턴 인식으로 품질을 잡는다는 점에서, 이것은 모니터링 도구가 아니라 주니어 SRE의 야간 근무를 자동화한 것에 가깝다.
시사점: 팀에 MCP 파이프라인을 뿌리내리려면
실무에서 바로 적용 가능한 레이어를 세 단계로 나눠볼 수 있다.
1단계 — 수작업 감사부터 시작하라. Kjetil의 방법이 맞다. 팀원들이 일주일 동안 Claude Code를 벗어나 다른 앱으로 이동하는 순간을 기록한다. 그 이동 지점 각각이 MCP 서버 후보다. GitHub UI, Jira, Slack, 로그 대시보드—컨텍스트 전환이 발생하는 모든 지점.
2단계 — 파이프라인 단위로 묶어라. 서버를 개별적으로 설치하는 것과 시퀀스로 연결하는 것은 다르다. Incident Response 워크플로우처럼, 트리거 → 데이터 수집(병렬) → AI 분석 → 조건 분기 → 알림 구조를 먼저 그리고 서버를 채워넣어야 한다. Shrimp처럼 태스크 라이프사이클(계획 → 분할 → 실행 → 검증) 전체를 하나의 파이프라인으로 설계해야 에이전트가 중간에 길을 잃지 않는다.
3단계 — CLAUDE.md에 팀 컨텍스트를 명문화하라. Shrimp 적용기에서 "처음에 조금 공들여서 프로젝트 목적, 디렉토리 구조, 절대 건드리지 말 것들까지 써두는 게 훨씬 낫다"는 조언은 MCP 파이프라인 전반에 적용된다. 에이전트가 잘못된 방향으로 작업하는 비용은 사람이 수작업하는 비용보다 빠르게 커진다. 규칙을 파일로 명문화해 에이전트의 작업 범위를 사전에 제한하는 것이 자동화 품질의 첫 번째 레버다.
전망: MCP가 팀 인프라로 굳는 조건
솔직히 말하면, 지금 MCP 생태계는 아직 개인 헤비유저의 영역에 가깝다. FastMCP로 커스텀 서버를 직접 만들고, 서버별 credentials를 관리하고, 불필요한 서버가 startup time을 잡아먹는 걸 모니터링하는 작업—이걸 팀 전체가 할 수 있는 수준으로 표준화하는 데는 학습 비용이 든다. Kjetil도 "어떤 서버는 2일 만에 없어서 안 되고, 어떤 서버는 2주가 지나도 한 번도 안 쓴다"고 인정한다. 팀에 붙이려면 개인 실험 단계를 거쳐 팀 표준 설정 파일로 굳히는 과정이 반드시 필요하다.
그럼에도 방향은 분명하다. DevOps, 콘텐츠 파이프라인, 태스크 관리—도메인이 달라도 MCP가 가져오는 변화는 동일하다. 사람이 도구 간 컨텍스트를 중계하던 자리를 에이전트가 채우고, 사람은 결과를 검토하고 판단하는 자리로 이동한다. 이 이동이 팀 전체에서 일어나려면, MCP 서버 목록이 아니라 팀의 반복 업무 시퀀스 지도가 먼저 있어야 한다. 파이프라인은 서버를 고르는 것으로 시작하지 않는다. 어떤 시퀀스를 자동화할지 결정하는 것으로 시작한다.