영업팀 CRM, 총무팀 그룹웨어, 창고 재고 테이블을 AI가 알아서 읽고 답하게 해 달라는 요청이 늘었습니다. 요청은 한 문장이지만, 받는 쪽에서는 서버를 한 대 새로 만드는 일입니다.
MCP는 이 연결 방식을 정리한 오픈 표준입니다. 앤트로픽이 2024년 11월 25일에 공개했고, 현재 규격 리비전은 2026년 7월 28일자입니다. 무엇을 만들고 무엇을 열어 주는지가 규격 안에 꽤 구체적으로 적혀 있습니다.
연결해 달라는 말은 서버를 한 대 만들자는 말입니다
MCP의 구조는 세 조각입니다. AI 앱인 호스트, 그 안의 연결 담당인 클라이언트, 그리고 사내 시스템 쪽에 서는 서버입니다. 셋은 JSON-RPC 2.0 형식의 메시지로 주고받습니다.
여기서 개발사가 만드는 것은 서버입니다. AI가 사내 DB에 직접 접속하는 것이 아니라, DB 앞에 서버를 하나 세우고 그 서버가 허용한 것만 내주는 구조입니다. 모델에 접속 정보를 건네주는 일이 아닙니다.
그래서 산출물은 'AI 도입'이 아니라 서버 코드 한 벌, 배포 환경, 그 서버가 쓸 계정 세 가지입니다. 견적서에 이 세 줄이 없으면 아직 범위가 잡히지 않은 것입니다.
서버가 내주는 것은 자료와 도구로 나뉩니다
규격상 서버가 내놓을 수 있는 것은 리소스, 도구, 프롬프트 세 종류입니다. 리소스는 URI로 식별되는 읽을거리이고, 도구는 모델이 실제로 실행하는 함수이며, 프롬프트는 정형화된 작업 틀입니다.
실무 언어로 옮기면 리소스는 '보여 줄 것', 도구는 '시킬 것'입니다. 사내 규정집 PDF는 리소스이고, 휴가 신청을 실제로 등록하는 동작은 도구입니다. 이 구분이 견적의 뼈대가 됩니다.
리소스는 목록과 조회를 붙이면 끝나지만, 도구는 하나하나 입력값을 설계하고 검증해야 합니다. 개발 기간이 늘어나는 쪽은 언제나 도구입니다.
허용 도구 범위는 함수 목록을 한 줄씩 적는 일입니다
도구는 이름, 설명, 입력 스키마를 갖춘 항목으로 등록됩니다. 클라이언트가 목록을 요청하면 서버가 이 목록을 돌려주고, 모델은 그 목록 안에서만 움직입니다.
즉 목록에 적히지 않은 기능은 AI 입장에서 존재하지 않습니다. 그래서 요구사항은 'CRM 연결'이 아니라 '고객 조회', '최근 상담 이력 조회', '담당자 변경' 같은 줄 단위 목록이어야 합니다.
규격은 도구 목록이 요청에 실린 권한에 따라 달라질 수 있다고 명시합니다. 영업팀 계정과 재무팀 계정에 서로 다른 목록을 보여 주는 설계가 가능하다는 뜻입니다.
읽기 전용과 쓰기 권한은 이 기준으로 가르세요
도구에는 성격을 표시하는 항목이 있습니다. 공식 스키마의 기본값은 '읽기 전용 아님', '파괴적일 수 있음', '멱등하지 않음', '외부와 연결됨'입니다. 아무것도 적지 않으면 가장 위험한 쪽으로 간주된다는 뜻입니다.
가르는 기준은 세 가지면 충분합니다. 되돌릴 수 있는 동작인지, 결과가 회사 밖으로 나가는지, 틀렸을 때 누가 언제 발견하는지입니다. 세 번째에서 '아무도 모른다'가 나오면 읽기 전용으로 두세요.
- 읽기 전용으로 둘 것: 조회, 검색, 집계 요약, 문서 본문 가져오기
- 쓰기를 열어도 되는 것: 임시 저장, 초안 생성, 내부 메모 등록
- 사람 승인을 반드시 거칠 것: 메일·메신저 발송, 결제와 발주, 삭제와 일괄 수정, 외부 API 전송
도구에 붙인 표시는 자물쇠가 아닙니다
규격은 클라이언트가 신뢰할 수 있는 서버에서 온 것이 아니라면 도구의 성격 표시를 신뢰해서는 안 된다고 못 박습니다. '읽기 전용'이라고 적어 두는 것은 선언일 뿐 차단 장치가 아닙니다.
실제로 막는 것은 서버 코드와 계정 권한입니다. 규격도 서버 쪽에 입력 검증, 접근 제어, 호출 속도 제한, 출력 정제를 의무로 요구합니다. 조회용 도구는 조회 권한만 가진 계정으로 돌려야 합니다.
읽기 전용이라는 말은 도구 설명에 적는 것이 아니라, 그 도구가 쓰는 계정에 쓰기 권한이 없다는 뜻이어야 합니다.
감사 로그는 프로토콜이 주지 않으니 따로 만들어야 합니다
규격이 감사에 대해 말하는 것은 클라이언트가 감사 목적으로 도구 사용을 기록하는 것이 좋다는 권고 한 줄입니다. 의무도 아니고 서버 쪽 규정도 아닙니다.
서버가 로그 메시지를 보내던 기능은 2026년 7월 28일자 리비전에서 폐기 예정으로 표시됐습니다. 이전 경로로는 표준 오류 출력과 OpenTelemetry가 제시돼 있습니다. 감사 로그는 애플리케이션이 직접 만들어야 하는 항목입니다.
남길 것은 누가, 언제, 어떤 도구를, 어떤 인자로 불렀고, 몇 건이 나왔으며, 승인 절차를 거쳤는지입니다. 이 표가 견적에 없으면 사고가 났을 때 답할 방법이 없습니다.
사내 문서가 외부로 나가는 통로는 도구가 돌려주는 값입니다
도구와 리소스가 돌려준 내용은 모델이 읽는 맥락으로 들어갑니다. 외부 모델 API를 쓴다면 그 내용이 그대로 외부로 전송됩니다. 이것이 사실상 유일하고 가장 큰 통로입니다.
규격의 원칙은 호스트가 사용자 데이터를 서버에 노출하기 전에 명시적 동의를 받아야 하고, 리소스 데이터를 동의 없이 다른 곳으로 전송해서는 안 된다는 것입니다. 다만 강제하는 주체는 AI 앱이지 프로토콜이 아닙니다.
따라서 통제점은 도구가 한 번에 돌려주는 필드와 건수입니다. 결과에 고객 전화번호를 넣으면 그 번호는 모델로 나갑니다. 마스킹은 서버에서 끝내야 합니다.
로컬로 붙일지 원격으로 붙일지에 따라 인증이 달라집니다
담당자 PC에서 실행하는 방식은 자격 증명을 환경 변수 등에서 가져옵니다. 규격은 이 방식에 OAuth 절차를 적용하지 말라고 안내합니다. 대신 서버는 PC 사용자와 같은 권한으로 돌아갑니다.
여러 부서가 붙는 원격 방식은 OAuth 2.1 기반입니다. 서버는 보호 리소스 메타데이터 공개가 의무이고, 클라이언트는 토큰을 어느 서버에 쓸지 지정하는 리소스 파라미터를 반드시 보내야 합니다.
여기서 계약상 중요한 문장이 하나 있습니다. 서버는 자기 앞으로 발급된 토큰만 받아야 하고, 다른 용도로 발급된 토큰을 받거나 그대로 넘겨서는 안 됩니다. 이 금지 조항을 지키는지가 구현 품질을 가릅니다.
견적과 계약에서는 이 항목을 문서로 받으세요
아래 항목에 답이 채워지지 않으면 금액을 비교할 근거가 없습니다. 같은 'MCP 연동 개발'이라도 도구가 3개인지 30개인지, 쓰기가 열리는지에 따라 일이 전혀 달라집니다.
- 도구 목록과 도구별 읽기·쓰기 구분, 부서별로 보이는 목록
- 도구마다 사용하는 계정과 그 계정에 부여된 권한
- 결과에 포함되는 필드 목록과 마스킹 규칙
- 모델 호출 위치와 사업자명, 즉 데이터가 어디로 가는지
- 감사 로그 항목, 보관 기간, 조회 방법
- 연결 방식과 인증 방식, 토큰 대상 검증 여부
- 발송·결제·삭제 도구의 사람 승인 화면 유무
이런 경우에는 MCP 연결이 맞지 않습니다
숫자가 정확해야 하는 정산과 대량 집계에는 맞지 않습니다. 모델이 도구를 골라 부르는 구조라서 호출이 빠지거나 중복돼도 사용자 화면에서는 티가 나지 않습니다. 정기 리포트는 기존 배치가 더 안전합니다.
외부에서 들어온 글을 다루는 쓰기 도구도 권하지 않습니다. 고객 문의 본문이나 외부 문서가 모델 맥락에 들어가면, 그 안의 문장이 지시처럼 작동할 여지가 있습니다. 규격이 도구 설명과 표시를 신뢰하지 말라고 하는 이유도 같은 맥락입니다.
연결 대상이 한 곳이고 쓰는 화면도 정해져 있다면, API를 직접 붙이는 편이 쌉니다. MCP는 여러 시스템을 같은 방식으로 여러 AI 앱에 열어 줄 때 값을 합니다. 관련 글은 실무 가이드에서 이어서 보실 수 있고, 규격 원문은 MCP 공식 명세에 공개돼 있습니다. 사내 시스템 연동 범위를 잡는 단계라면 Codeforest로 문의해 주세요.
결론: 목록과 계정으로 범위를 확정하세요
사내 데이터를 AI에 붙이는 일은 서버를 한 대 만들고, 그 서버가 내줄 도구 목록을 한 줄씩 적고, 도구마다 계정 권한을 나누는 작업입니다. 열어 주는 범위는 도구 목록과 계정 권한 두 가지로 결정됩니다.
계약 전에 도구 목록, 계정 권한, 결과 필드, 감사 로그, 모델 호출 위치 다섯 가지를 문서로 받으세요. 이 다섯 줄이 정리되면 금액 비교가 가능해지고, 쓰기 권한을 어디서 멈출지도 회사가 직접 정할 수 있습니다.
