62단계MCP, 모든 연결의 공통 규격

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

이 단계를 마치면

• MCP가 무엇인지 비유 하나로 동료에게 설명할 수 있다.
• 연결자 하나를 보고 읽기 도구와 쓰기 도구를 구분할 수 있다.
• 사내 시스템 연결을 IT에 요청할 때 "하지 않을 일"까지 적은 요청서를 쓸 수 있다.

해외 출장지 호텔 방에서 콘센트 앞에 서서 난감했던 적이 있을 것이다. 가방을 뒤져 변환 플러그를 찾으며, 세상 콘센트가 전부 한 모양이면 얼마나 좋을까 생각한다. 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를 엉뚱하게 움직이려는 시도도 이미 알려져 있다. 믿을 만한 연결과 믿을 만한 자료로 범위를 좁히는 것이 가장 쉬운 방어다.

요청서 한 장이 얼마나 큰 차이를 만드는지는 한 식자재 유통사의 사례가 잘 보여 준다.

현장 장면

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

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

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

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

따라 하기

1. 설정의 연결자 목록에서 연결자 하나를 골라 설명을 읽는다. 성공 기준: 그 연결자를 누가 제공하는지 한 문장으로 적을 수 있다.
2. 그 연결자가 할 수 있는 일을 "읽기"와 "쓰기"로 나눠 적는다. 성공 기준: 두 항목이 모두 채워지거나, 쓰기 도구가 없다는 것을 확인한다.
3. 연결을 켠 대화에서 간단한 부탁을 하고, 답에 표시된 도구 호출을 펼쳐 어떤 도구를 불렀는지 본다. 성공 기준: 도구 이름을 하나 이상 확인한다.
4. 목록에 없는 사내 시스템(재고, 회계, 사내 위키 등)이 있으면 아래 프롬프트로 IT 요청서 초안을 만든다. 성공 기준: 시스템마다 "하지 않을 일"이 하나 이상 적혀 있다.

복사해 쓰는 프롬프트

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

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

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

막히면 이렇게

스스로 점검

• ☐ MCP를 콘센트 비유로 30초 안에 설명할 수 있다.
• ☐ 내가 본 연결자 하나의 읽기·쓰기 도구를 나눠 적었다.
• ☐ 사내 연결 요청서에 "하지 않을 일"을 적어야 하는 이유를 말할 수 있다.

기억할 것

• 연결자를 보면 먼저 묻는다. 읽기만 하는가, 쓰기도 하는가?
• 출처를 모르는 연결은 붙이지 않는다. 사내 연결은 IT와 함께 만든다.
• 연결을 요청할 때는 하고 싶은 일과 함께 하지 않을 일도 적는다.

더 알아보기 · MCP 공식 안내 · MCP 서버 예시 모음