64단계연결자와 MCP, 모든 연결의 공통 규격

걸리는 시간 · 읽기 약 10분 · 따라 하기 약 35분 · 난이도 ★★☆ 실무 · 화면 확인 2026.09.27

이 단계를 마치면

• 연결자가 무엇을 대신해 주고 무엇은 대신해 주지 않는지 설명하고, 파일 업로드·연결자·Cowork 가운데 상황에 맞는 방법을 고를 수 있습니다.
• 이 부에서 연결할 후보 두 곳을 내 업무에서 골라냅니다.
• MCP가 무엇인지 비유 하나로 동료에게 설명하고, 연결자 하나를 보고 읽기 도구와 쓰기 도구를 구분할 수 있습니다.
• 사내 시스템 연결을 IT에 요청할 때 "하지 않을 일"까지 적은 요청서를 쓸 수 있습니다.

지난주에 Claude에게 일을 맡기면서 복사해 붙여 넣기를 몇 번 했는지 세어 본 적이 있습니까? 보고서를 쓰려고 Drive에서 파일을 내려받아 올렸고, 회의 내용을 정리하려고 Notion 페이지를 통째로 복사했습니다. Claude는 똑똑했지만 우리가 가져다준 것만 볼 수 있었습니다. 재료를 나르는 일은 여전히 사람이 했습니다.

연결자는 이 나르는 일을 Claude에게 넘깁니다. 한 번 연결해 두면 "지난주 영업 회의록에서 가격 얘기만 모아 줘"라고 말했을 때 Claude가 Notion에 가서 해당 페이지를 찾아 읽고 답합니다. 파일을 찾는 수고도, 어느 파일이 최신인지 헷갈리는 일도 함께 줄어듭니다.

나르는 일이 왜 문제인가

복사해 붙이는 방식에는 눈에 잘 띄지 않는 비용이 숨어 있습니다.

우선 재료가 낡습니다. 내가 붙인 것은 붙이는 순간의 사본입니다. 그 뒤 동료가 원본을 고쳐도 대화 속 사본은 그대로입니다. 월요일에 붙인 가격표로 수요일에 견적 초안을 받으면, 화요일에 바뀐 할인율은 빠져 있습니다.

재료가 모자라기도 합니다. 사람은 바쁠수록 덜 붙입니다. 회의록 세 개 가운데 가장 긴 것 하나만 붙이고, 나머지는 "대충 비슷하겠지" 하고 넘깁니다. Claude는 받은 것만 가지고 답하므로, 빠진 두 회의록에 있던 반대 의견은 답에 나오지 않습니다. 답이 틀렸다기보다 재료가 반쪽이었습니다.

출처가 사라지는 것도 문제입니다. 여러 문서를 한 덩어리로 붙이면 어느 문장이 어느 문서에서 왔는지 흐려지고, 답을 검토할 때 거슬러 찾아갈 길이 없어집니다. 연결자로 읽으면 Claude가 어느 문서를 읽었는지가 답에 드러나므로 원문으로 돌아가 확인할 수 있습니다.

흔한 오해 세 가지

연결자를 처음 소개하면 대개 이런 반응이 먼저 나옵니다. "그러면 AI가 회사 자료를 몰래 다 가져가는 것 아닌가?" 그렇지 않습니다. 연결자는 내 계정의 권한 안에서, 내가 허락한 만큼만 봅니다. 내가 못 여는 폴더는 Claude도 못 엽니다. 거꾸로 말하면, 내 계정이 전사 폴더를 다 볼 수 있다면 Claude도 그만큼 봅니다. 범위가 넓어 보인다면 원인은 넓게 잡힌 내 권한에 있습니다.

연결해 두었다고 대화할 때마다 저절로 뒤지는 것도 아닙니다. 필요할 때 부르면 되고, 대화마다 쓸 연결을 켜고 끌 수 있습니다. 개인적인 질문을 하는 대화에서 회사 메일 연결이 켜져 있을 이유는 없습니다.

연결자가 파일 업로드를 없애 주지도 않습니다. 회사 도구에 올라가 있지 않은 자료, 이를테면 거래처가 보낸 PDF 한 장이나 내 컴퓨터에만 있는 초안은 여전히 직접 올리는 편이 빠릅니다. 연결자는 자주, 반복해서 가져오는 재료에 씁니다.

어디서 연결하나

연결자는 Claude 앱의 설정에서 추가합니다. 회사가 팀 요금제를 쓴다면 관리자가 먼저 허용해야 목록에 보이기도 합니다. 어느 요금제에서 어떤 연결자가 열리는지는 바뀔 수 있으니, 쓰기 전에 공식 안내를 한 번 확인합니다.

목록을 훑다 보면 "되는 건 다 연결해 두자"는 생각이 들기 쉽습니다. 흔한 실수입니다. 연결이 많을수록 Claude가 엉뚱한 곳을 뒤질 가능성이 커지고, 내가 관리해야 할 권한도 늘어납니다. 연결할 곳은 내 한 주의 손품을 돌아보며 고릅니다.

공통 규격, MCP

해외 출장지 호텔 방에서 콘센트 앞에 서서 난감했던 적이 있을 것입니다. 가방을 뒤져 변환 플러그를 찾으며, 세상 콘센트가 전부 한 모양이면 얼마나 좋을까 생각합니다. AI와 사내 도구 사이에도 똑같은 문제가 있습니다. 사내 도구는 많고, AI 서비스도 여럿입니다. 도구와 AI를 하나씩 짝지어 연결을 따로 만든다면 짝의 수만큼 공사가 필요합니다. 도구가 열 개, AI가 세 개면 서른 번입니다.

MCP(Model Context Protocol)는 이 문제를 풀려고 Anthropic이 공개한 연결 규약입니다. 도구 쪽은 "나는 이런 일을 할 수 있다"를 MCP 방식으로 한 번만 내놓고, AI 쪽은 그 방식을 알아듣습니다. 말하자면 콘센트 모양을 하나로 통일했습니다. 도구 열 개와 AI 세 개라면 공사는 열세 번으로 줄어듭니다. Claude의 연결자도 이 MCP를 바탕으로 만들어졌습니다.

경영자가 이것을 왜 알아야 하나

MCP는 기술 규약이지만 경영 판단과 맞닿아 있습니다. 사내 시스템을 AI에 연결하자는 제안이 올라왔을 때 이 규약을 모르면 두 가지 실수를 하기 쉽습니다. 하나는 "AI 회사마다 따로 개발해야 한다"고 생각해 비용을 과하게 잡는 것이고, 다른 하나는 거꾸로 "표준이니 아무거나 붙여도 된다"며 출처 모를 연결을 허락하는 것입니다. MCP를 한 문단만 이해해도 두 실수를 모두 피할 수 있습니다.

기술 세부까지 알 필요는 없습니다. 다만 다음 몇 가지를 알아 두면 판단이 빨라집니다.

먼저, 연결자마다 할 수 있는 일의 목록이 따로 있습니다. MCP에서는 이 하나하나를 "도구"라고 부릅니다. 어떤 연결자는 찾기와 읽기 도구만 내놓고, 어떤 연결자는 초안 쓰기나 항목 만들기 도구까지 내놓습니다. 같은 서비스라도 연결자에 따라 목록이 다를 수 있으니, 연결자를 볼 때는 이름보다 이 목록을 확인합니다.

연결 방식은 두 갈래입니다. 인터넷 너머의 서비스와 연결하는 원격 커넥터가 있고, 데스크톱 앱에 설치해 내 컴퓨터 안의 프로그램과 연결하는 데스크톱 확장이 있습니다. Google Drive나 Slack처럼 인터넷에 있는 서비스는 앞의 것이고, 내 컴퓨터에 깔린 프로그램이나 파일과 연결하는 것은 뒤의 것입니다.

또 방식이 같으니 제3부에서 써 본 Claude Code에서도, 뒤에 나올 외부 자동화 도구에서도 같은 개념이 그대로 쓰입니다. 여기서 "연결자는 도구 목록을 가진 문"이라는 감각을 잡아 두면 뒤에서 새로 배울 것이 줄어듭니다.

부탁 한 번에 안에서 벌어지는 일

"영업본부 폴더에서 올해 가격 정책 문서를 찾아 줘"라고 부탁하면, 화면 뒤에서는 대략 이런 순서로 일이 진행됩니다.

1. Claude가 켜져 있는 연결자들의 도구 목록을 봅니다.
2. 이 부탁에 맞는 도구, 예를 들어 Drive의 검색 도구를 고릅니다.
3. 검색어와 범위를 정해 그 도구를 부릅니다. 이때 도구는 내 계정의 권한으로 움직입니다.
4. 돌아온 결과를 읽고, 필요하면 읽기 도구를 한 번 더 불러 문서 본문을 가져옵니다.
5. 가져온 내용으로 답을 씁니다.

이 순서를 알면 답이 이상할 때 어디를 봐야 할지 보입니다. 도구를 잘못 골랐는지, 검색어가 엉뚱했는지, 권한이 막혀 결과가 비었는지 따져 볼 수 있습니다. Claude의 답 화면에는 어떤 도구를 불렀는지 표시되는 경우가 많으니 펼쳐 보는 습관을 들입시다.

사내 시스템을 연결하는 길

IT 담당자가 "우리 회사 재고 시스템에 MCP 서버를 붙여 두었다"고 말한다면, Claude가 그 시스템을 연결자처럼 부를 수 있게 준비해 두었다는 이야기입니다. 목록에 없는 사내 시스템도 이 방법으로 연결할 수 있습니다. 연결을 새로 만드는 일은 IT가 맡고, 경영자는 무엇을 연결하고 싶은지와 어디까지 허락할지를 정합니다.

출처를 모르는 연결은 함부로 붙이지 않습니다. 연결은 문을 하나 새로 내는 일입니다. 누가 만든 문이고 어디로 통하는지 확인한 뒤에 열어야 합니다. 연결로 읽어 온 문서 안에 "이 지시를 따르라" 같은 글을 숨겨 AI를 엉뚱하게 움직이려는 시도도 이미 알려져 있습니다. 믿을 만한 연결과 믿을 만한 자료로 범위를 좁히는 것이 가장 쉬운 방어입니다.

연결하고 나면 무엇이 달라지는지, 요청서 한 장이 얼마나 큰 차이를 만드는지는 두 회사의 사례가 잘 보여 줍니다.

현장 장면

중견 제조사의 박 팀장은 월요일 오전마다 공유 드라이브의 실적 파일, 협력사 메일, Slack 생산팀 채널을 번갈아 열며 요약본을 만들었습니다. 연결자를 붙인 첫 주, "지난주 실적 파일, 협력사 메일, 생산팀 채널을 보고 요약해 줘"라고 입력하자 답은 금방 나왔지만 실적 숫자 하나가 기억과 달랐습니다. 출처를 눌러 보니 같은 폴더의 초안과 확정본을 섞어 읽은 것이었습니다. 둘째 주부터 박 팀장은 "실적 파일은 '확정' 폴더에 있는 것만 읽어. 요약하기 전에 읽은 파일과 메일 목록부터 보여 줘"라고 범위와 확인 절차를 붙였고, 틀린 재료는 더 섞이지 않았습니다. 월요일 오전의 일이 "모으기"에서 "판단하기"로 바뀌었습니다.

식자재 유통사의 오 본부장은 매일 아침 재고 시스템에 들어가 품목별 재고부터 확인했습니다. 부족한 품목을 엑셀로 옮기고, 그것을 Claude에 붙여 발주 검토 메모를 받았습니다. 옮기는 데만 매일 적지 않은 손이 갔습니다. 결국 오 본부장은 IT팀에 짧게 요청했습니다. "재고 시스템을 Claude에 붙여 주세요."

한 달 뒤 IT팀이 MCP 연결을 만들어 왔습니다. 조회는 잘 됐습니다. 그런데 도구 목록을 펼쳐 본 오 본부장은 멈칫했습니다. "주문 입력"과 "단가 수정"이 들어 있었던 것입니다. 왜 넣었느냐고 묻자 IT팀은 "있으면 편할 것 같아서"라고 답했습니다. 오 본부장이 원한 것은 조회뿐이었습니다. Claude가 "재고가 부족하니 발주해 둘까요?"라고 물어 올 수도 있는 구조라는 것을 알고 나서야, 오 본부장은 자신의 요청서가 너무 짧았다는 것을 깨달았습니다.

두 번째 요청서는 달랐습니다. "원하는 일: 품목별 재고와 입고 예정일 조회. 원하지 않는 일: 주문 입력, 단가 수정, 삭제. 쓰는 사람: 구매팀 3명. 접근 계정: 조회 전용 계정." IT팀은 조회 도구만 남긴 연결을 다시 내놓았습니다. 이제 오 본부장은 "오늘 기준 안전재고 아래로 떨어진 품목과 입고 예정일을 표로"라고 부탁하고, 발주는 사람이 시스템에서 직접 넣습니다.

요청서에 "하지 않을 일"을 적어 넣는 것. 오 본부장은 그것이 경영자가 할 일이라는 것을 배웠습니다.

따라 하기

1. 지난 일주일 동안 자료를 복사해 Claude에 붙인 곳을 모두 적습니다. Drive, Notion, 메일, 메신저 등. 기억나지 않으면 지난 대화 목록을 훑습니다. 성공 기준: 다섯 곳 안팎의 목록이 나옵니다.
2. 곳마다 일주일에 몇 번 복사했는지 옆에 적습니다. 정확하지 않아도 됩니다. 성공 기준: 횟수로 순서를 매길 수 있습니다.
3. 가장 자주 여는 두 곳에 동그라미를 칩니다. 이 부에서 연결할 후보입니다. 성공 기준: 두 곳 모두 회사 공식 도구입니다. 개인 메모 앱이면 다음 후보로 넘깁니다.
4. Claude 앱 설정에서 연결자 항목을 열고, 두 후보가 목록에 있는지 봅니다. 목록에 없거나 회색으로 막혀 있으면 적어 둡니다. 성공 기준: 후보마다 "있음", "없음", "막힘" 가운데 하나를 적었고, 막힌 것은 71단계에서 풀 과제로 남겼습니다.
5. 목록에 있는 후보 연결자 하나의 설명을 읽습니다. 성공 기준: 그 연결자를 누가 제공하는지 한 문장으로 적을 수 있습니다.
6. 그 연결자가 할 수 있는 일을 "읽기"와 "쓰기"로 나눠 적습니다. 성공 기준: 두 항목이 모두 채워지거나, 쓰기 도구가 없다는 것을 확인합니다.
7. 연결을 켠 대화에서 간단한 부탁을 하고, 답에 표시된 도구 호출을 펼쳐 어떤 도구를 불렀는지 봅니다. 성공 기준: 도구 이름을 하나 이상 확인합니다.
8. 목록에 없는 사내 시스템(재고, 회계, 사내 위키 등)이 있으면 아래 프롬프트로 IT 요청서 초안을 만듭니다. 성공 기준: 시스템마다 "하지 않을 일"이 하나 이상 적혀 있습니다.

복사해 쓰는 프롬프트

우리 회사 IT팀에 보낼 사내 시스템 연결(MCP) 요청서 초안을 써 줘. 보내지는 말고 초안만.

- 시스템 이름: [시스템]
- 하고 싶은 일: [예: 품목별 재고 조회]
- 하지 않을 일: [예: 입력, 수정, 삭제]
- 쓰는 사람과 인원: [부서, 인원]
- 다루는 자료의 민감도: [높음/보통/낮음과 이유]

IT팀이 되물을 만한 질문 세 가지를 예상해 끝에 붙여 줘.
기술 용어는 쓰되 괄호 안에 쉬운 말을 달아.

막히면 이렇게

스스로 점검

• ☐ 연결자가 내 권한 밖의 자료를 볼 수 없는 이유와, 연결자보다 파일 업로드가 나은 경우를 하나씩 말할 수 있습니까?
• ☐ 연결할 후보 두 곳을 복사 횟수와 함께 적고, 그 가운데 한 연결자의 읽기·쓰기 도구를 나눠 적었습니까?
• ☐ MCP를 콘센트 비유로 30초 안에 설명하고, 사내 연결 요청서에 "하지 않을 일"을 적어야 하는 이유를 말할 수 있습니까?

기억할 것

• 연결할 곳은 기능 목록에서 찾지 않습니다. 내가 자주 복사하던 곳에서 고릅니다.
• Claude는 내 권한 밖을 보지 못합니다. 범위가 넓어 보이면 내 권한이 넓은 것입니다.
• 요약을 받기 전에 읽은 자료 목록부터 받습니다. 재료가 맞아야 답도 맞습니다.
• 연결자를 보면 먼저 묻습니다. 읽기만 합니까, 쓰기도 합니까?
• 출처를 모르는 연결은 붙이지 않습니다. 사내 연결은 IT와 함께 만들고, 요청서에는 하지 않을 일도 적습니다.

더 알아보기 · 연결자·플러그인 목록 · MCP 공식 안내 · MCP 서버 예시 모음