🔌 레슨
실전 패턴 — 잘 쓰는 팀의 MCP 구성
막 붙이면 산만해져요. 실무 팀들이 검증한 조합과 운영 방식.
① 오늘의 미션
전화선을 몇 개나 깔까?
반찬가게가 자리를 잡으니 챙길 게 많아졌어요. 팀 채팅(Slack)에 주문 문의가 쌓이고,
메뉴·레시피는 문서(Notion)에, 매출은 DB(Supabase)에 들어 있죠.
Claude에게 이 전화선들을 전부 다 깔면 잘 돌아갈까요?오늘은 잘 쓰는 팀이 실제로 어떻게 MCP를 조합하는지, 그리고 막 붙이지 않는 비결을 배웁니다.
설명을 따라 진행하면, 여기서 직접 쳐보게 돼요 👇
$ _
📚 「실전 패턴 — 잘 쓰는 팀의 MCP 구성」 레슨 내용 전체 텍스트로 훑어보기
전화선을 몇 개나 깔까?
반찬가게가 자리를 잡으니 챙길 게 많아졌어요. 팀 채팅(Slack)에 주문 문의가 쌓이고,
메뉴·레시피는 문서(Notion)에, 매출은 DB(Supabase)에 들어 있죠.
Claude에게 이 전화선들을 전부 다 깔면 잘 돌아갈까요?오늘은 잘 쓰는 팀이 실제로 어떻게 MCP를 조합하는지, 그리고 막 붙이지 않는 비결을 배웁니다.
잘 돌아가는 팀이 Claude에 자주 붙이는 MCP 조합, 어떤 게 가장 현실적일까요?
맞아요. 실무 팀은 보통 협업·문서·DB·검색 네 갈래를 중심으로 조합해요. 반찬가게로 치면 Slack(주문 문의)·Notion(레시피·메뉴)·Supabase(매출 데이터)에 검색이 더해진 그림이죠. 단, '전부 다'와 '하나면 충분' 사이의 균형이 핵심이에요.
잘 쓰는 팀의 MCP는 대개 이 네 갈래예요. 우리 반찬가게로 옮겨 보면 —
반찬가게의 네 전화선
· 협업 — Slack: 팀 채널의 주문 문의·공지를 읽고 답을 초안 잡아요· 문서 — Notion / Drive: 레시피·메뉴 설명·운영 매뉴얼을 읽고 정리해요
· DB — Supabase: 이번 주 매출·인기 반찬을 자연어로 물어봐요
· 검색 — 웹 검색: 모르는 재료·시세를 바깥에서 찾아와요
중요한 건 목록을 외우는 게 아니라 "작업마다 필요한 전화선이 다르다"는 감각이에요.
전화선을 많이 깐다고 일이 잘 되는 건 아니에요. 두 방식을 나란히 봐요.
🌀 막 붙이기 (전부 연결): 보이는 MCP를 다 연결. 도구 설명이 책상을 차지하고, Claude도 어느 걸 써야 할지 산만해져요. 매출 질문 하나에 메뉴·채팅·검색이 다 끼어들죠.
🎯 골라 붙이기 (작업별로): 지금 작업에 필요한 것만 켜요. "이번 주 매출 정리"라면 DB 하나, "주문 문의 답변"이라면 Slack 하나. 깔끔하고 답도 정확해져요.
오늘 할 일은 "어제 회의록을 정리해 매출 표와 함께 공유"예요. 이 작업에 꼭 필요한 전화선은 몇 갈래일까요?
작업을 쪼개 보면 답이 나와요 — 문서(회의록 읽기) → DB(매출 조회) → 협업(Slack 공유). 검색은 이 작업엔 필요 없죠. 작업을 단계로 쪼개면 어떤 전화선이 필요한지가 자연스럽게 보여요.
잘 쓰는 팀의 단골 패턴이 회의록 → 정리 → 공유 파이프라인이에요. 한 번의 대화로 문서를 읽고, 매출을 붙이고, 채널에 공유 초안까지 만들게 해봐요.
어제 운영회의 회의록을 읽고, 이번 주 인기 반찬 매출이랑 묶어서 팀 채널에 올릴 공유 글 초안 잡아줘 — 여러 전화선을 한 흐름으로 엮어요세 전화선(문서·DB·협업)이 한 작업 안에서 자연스럽게 이어진 거예요. 이게 파이프라인이에요.
방금처럼 여러 MCP를 한 작업 흐름으로 잇는 것을 파이프라인이라고 불러요. 반찬가게의 단골 파이프라인은 이래요 —
회의록 → 정리 → 공유
① 읽기: 문서(Notion)에서 회의록을 가져오고② 엮기: DB(Supabase)의 매출을 붙여 정리하고
③ 공유: 협업(Slack) 채널에 올릴 글을 초안한다
한 번의 부탁으로 세 단계가 흘러가죠. 외울 패턴이 아니라, 내 일을 단계로 쪼개면 전화선이 알아서 정해진다는 게 핵심이에요.
회의록 → 정리 → 공유 파이프라인이 도는 순서를 맞춰 보세요. (화면엔 섞여 있어요)
읽기 → 엮기 → 정리 → 공유 순서예요. 데이터를 먼저 모으고(문서·DB), 정리한 뒤, 마지막에 공유로 내보내죠.
매출 DB와 팀 채널을 Claude에 처음 연결해요. 안전하게 시작하는 방법은?
맞아요. 읽기 전용(read-only)으로 시작하는 게 정석이에요. 잘못된 명령 하나로 매출 데이터가 바뀌거나 엉뚱한 글이 채널에 올라가면 곤란하니까요. 읽기로 익숙해진 뒤 꼭 필요한 곳만 쓰기 권한을 여는 거예요.
매출 DB를 처음 연결할 때, 데이터가 망가지지 않게 어떤 권한으로 시작하는 게 안전할까요?
정답! 읽기 전용으로 시작해요. 보기만 가능하니 사고가 날 일이 없죠. 필요해질 때 한 곳씩 쓰기 권한을 여는 게 프로의 순서예요.
지금 붙어 있는 전화선이 읽기 전용인지 Claude에게 직접 물어 확인해봐요. 모르면 묻는 습관, 보안에서 특히 중요해요.
지금 연결된 매출 DB가 읽기 전용으로 붙어 있는지 확인하고, 위험한 권한이 열려 있으면 알려줘 — 연결된 MCP 권한을 점검해요읽기 전용으로 시작 → 익숙해지면 한 곳씩 권한 확장. 이 순서만 지켜도 사고의 대부분을 막아요.
한 줄로
잘 쓰는 팀은 협업·문서·DB·검색을 막 붙이지 않고 작업별로 필요한 것만 켜요.
단골 패턴은 회의록 → 정리 → 공유 파이프라인, 그리고 시작은 늘 읽기 전용이에요.다음 레슨에서
그런데 — 남이 만든 MCP만 쓸 수 있는 걸까요? 우리 반찬가게만의 도구(예: 우리 주문 시스템)를 직접 연결하려면?
다음 'MCP 만들기 개관 — 우리 도구를 연결하려면'에서 그 길을 엽니다. 가게는 계속 자랍니다. 🌱