들어가며

어떤 자재 유통회사의 영업 담당자가 AI로 견적 업무를 처리한다고 해보겠습니다. 고객이 제품 20개의 가격과 납기를 물으면 AI가 요청을 정리하고 정중한 답장도 써줍니다.

그런데 옆에서 지켜보면 직원의 손은 계속 바쁩니다. 재고를 확인하려고 ERP를 열고 숫자를 복사해 AI에게 붙여넣습니다. 거래처별 단가도 찾아서 알려줍니다. AI가 정리한 견적 내용을 확인한 뒤에는 다시 회사 시스템에 입력하고, 고객관리 프로그램인 CRM에도 상담 내역을 남깁니다.

팀장이 묻습니다.

AI로 견적 업무 한다고 하지 않았어요?

담당자가 답합니다.

네. 그런데 재고 조회랑 시스템 입력은 제가 해야 해요.

AI는 답장을 잘 씁니다. 직원은 답장에 필요한 자료를 가져다주고 결과를 시스템에 옮깁니다. 이 상황에서는 더 똑똑한 모델로 바꿔도 복사와 입력이 그대로 남을 수 있습니다. AI가 회사 시스템을 조회하고 작업을 실행할 수 있도록 연결하지 않았기 때문입니다.

이때 자주 등장하는 기술이 MCP입니다. MCP는 AI 애플리케이션이 외부 시스템의 자료와 도구를 이용하도록 연결하는 공통 규약입니다. 재고를 조회하거나 견적을 저장하는 기능을 AI가 사용할 수 있게 제공할 때 활용합니다.

이번 글에서는 MCP가 어떻게 작동하는지, 실제 기업에서는 어떤 업무에 쓰는지 살펴보겠습니다. 우리 회사에 필요한 연결은 무엇이고, 연결한 뒤에도 왜 사람이 계속 입력하는지 구분해보면 AX 과제를 어디부터 손봐야 할지 조금 더 명확해질 겁니다.

AI에게 업무 창구를 열어주는 MCP

신입 직원에게 견적 업무를 맡겼다고 생각해봅시다. 제품 설명은 잘하고 메일도 잘 쓰지만 재고 시스템 계정이 없습니다. 견적 등록 메뉴도 모릅니다. 옆자리 선배가 매번 재고를 조회해주고 작성한 내용을 대신 입력해야겠죠.

앞선 AI도 비슷합니다. 업무 지식을 알려주는 것과 실제로 시스템을 사용하게 하는 것은 별도로 준비해야 합니다.

MCP는 Model Context Protocol의 약자입니다. AI 애플리케이션과 외부 시스템이 자료와 기능을 주고받을 때 사용할 공통 형식을 정합니다. 이를 이용하면 AI 애플리케이션은 어떤 도구가 있는지 확인하고, 그 도구에 필요한 값을 보내고, 실행 결과를 받을 수 있습니다. MCP 공식 설명

여기서 도구는 망치나 드라이버가 아니라 프로그램으로 실행할 수 있는 기능을 말합니다. 재고 조회, 고객 검색, 견적 초안 저장 같은 작업입니다. MCP 서버는 이런 도구를 제공하는 프로그램입니다. 직원은 AI 애플리케이션에서 이 서버를 연결해 사용합니다. 서버라는 이름 때문에 회사에 새 장비부터 들여야 한다고 생각할 수 있지만 직원 PC에서 실행하는 프로그램일 수도 있고 외부에서 운영하는 서비스일 수도 있습니다.

앞서 다룬 Agent Skills 와 함께 보면 역할을 이해하기 쉽습니다. 스킬에 견적을 작성하는 순서와 주의사항을 담았다면, 도구에는 재고 조회와 견적 저장 기능을 담습니다. MCP로는 AI 애플리케이션과 그 도구를 연결합니다. 업무 지침에 재고를 확인하라고 써놓아도 사용할 도구가 없다면 AI는 직원에게 재고를 알려달라고 요청해야 합니다.

API가 있는데 MCP는 왜 또 필요할까?

개발팀에 사내 시스템을 연결하자고 하면 API라는 말을 듣게 됩니다. API는 다른 프로그램이 시스템의 기능을 사용할 수 있도록 마련한 접점입니다. ERP에 재고 조회 API가 있으면 사람이 화면을 열지 않아도 프로그램이 상품 코드를 보내 재고를 조회할 수 있습니다.

그럼 API만 연결하면 되는 것 아닐까요? 실제로 그렇게 만들 수도 있습니다.

MCP를 활용하면 여러 AI 애플리케이션에 업무 도구를 공통 형식으로 제공할 수 있습니다. 영업팀 에이전트와 고객지원팀 에이전트가 같은 재고 조회 기능을 쓰려 할 때, 각각의 접속 방식을 따로 만들기보다 MCP 서버에 도구를 제공해두는 방식입니다. 사용하는 애플리케이션이 해당 MCP 기능과 인증 방식을 지원하는지 확인하면 됩니다.

그 안에서는 여전히 기존 API를 사용할 수 있습니다. 예를 들어 MCP 서버가 AI의 재고 조회 요청을 받아 ERP API를 호출하고 결과를 돌려줍니다. ERP를 새로 만들거나 지금까지 개발한 API를 버리는 일이 아닙니다.

Oracle의 NetSuite MCP Standard Tools 문서 에서도 이 관계를 확인할 수 있습니다. AI에서 요청하면 MCP 도구가 NetSuite API 호출이나 작업으로 바꿔 실행합니다. 보고서와 저장된 검색을 조회할 수 있고 REST Web Services로 레코드를 생성하거나 수정하는 기능도 제공합니다.

우리 회사에 이미 잘 쓰는 업무 API가 있다면, 그중 어떤 기능을 AI가 호출하게 할지 고르는 데서 시작할 수 있습니다. 반대로 화면으로만 조작할 수 있는 구형 프로그램이라면 연결 방법부터 찾아야 합니다. 파일 교환이나 화면 자동화 같은 수단이 필요할 수 있고, 이때는 화면 변경과 로그인 실패에도 대비해야 합니다.

재고를 물어보면 내부에서는 무슨 일이 벌어질까?

처음의 견적 업무에 재고 조회 도구를 붙여보겠습니다. 고객은 제품 P-210을 20개 살 수 있는지 물었습니다.

AI 애플리케이션은 연결된 MCP 서버에서 사용할 수 있는 도구의 목록과 설명을 가져옵니다. 모델은 그 설명을 보고 어떤 도구를 사용할지 고릅니다. 재고 조회 도구에는 상품 코드와 창고처럼 입력해야 할 항목이 정해져 있습니다. 이를 스키마라고 하는데, 쉽게 말하면 프로그램이 읽는 요청서 양식입니다.

모델이 상품 코드와 조회 조건을 정하면 애플리케이션이 서버에 요청을 보냅니다. 서버는 사용 권한과 입력값을 검사한 뒤 ERP에서 재고를 조회합니다. 결과를 받은 모델은 그 자료로 답변하거나 다음 작업을 정합니다. 도구 목록 조회와 호출은 MCP에서 각각 tools/list, tools/call로 정의합니다. 도구 명세

이 과정을 견적 업무에 맞춰 구성하면 다음과 같습니다.

이 표는 우리 회사에 적용할 흐름을 생각해보기 위한 예시입니다. 어떤 단계는 정해진 프로그램으로 처리하고, 어떤 단계는 모델이 자료를 읽으며 판단하도록 구성할 수 있습니다. 금액 계산은 회사의 계산 기능에 맡기고 AI는 고객 요청을 해석하거나 설명을 작성하게 하는 식입니다.

사용자에게는 한 번의 요청으로 보이지만 내부에서는 프로그램들이 서로 다른 역할을 맡아 일합니다. 이 구분을 알아야 재고가 틀렸을 때 조회 기준을 고칠지, 견적 계산을 고칠지, AI의 판단을 고칠지 찾을 수 있습니다.

실제 기업에서는 어디까지 쓰고 있을까?

Block은 직원에게 승인된 연결을 함께 제공했습니다

Block은 자체 에이전트 Goose를 업무에 도입했습니다. 2025년 4월 공개한 운영 회고 에 따르면 직원들이 사용할 MCP 서버를 회사에서 묶어 제공했고, 사내 엔지니어가 시스템과 업무에 맞게 서버를 작성했습니다.

연결 대상에는 내부 데이터를 조회하는 Snowflake, 업무를 관리하는 Jira, Slack과 Google Drive, 내부 API 등이 포함됐습니다. 데이터·운영팀은 내부 시스템을 조회하고 여러 자료를 모아 보고서를 만드는 데 활용했습니다. 고객지원과 위험관리 등 개발 외 업무에서도 사용했다고 설명합니다.

자료가 필요할 때마다 전문가에게 추출을 요청하고 답을 기다리던 일을 줄이려는 구성입니다. 직원에게 AI 계정만 나눠주는 것과는 준비가 다릅니다. 실제 업무에 필요한 시스템을 연결하고 사용할 수 있는 환경까지 제공했습니다.

우리 조직에서도 직원들이 AI를 잘 쓰게 하려면 어떤 프롬프트를 교육할지와 함께 무엇에 접근할 수 있게 할지 살펴볼 필요가 있습니다. 조회할 수 없는 자료를 매번 사람이 가져다줘야 한다면 그 수고는 계속 남으니까요.

Atlassian에서는 업무 기록을 직접 쓰는 활용이 늘었습니다

Jira와 Confluence를 제공하는 Atlassian은 2026년 7월 MCP 서버의 이용 현황 을 공개했습니다. 도구 호출의 약 3분의 1이 쓰기 작업이었고, 전체 MCP 사용자 중 44%는 소프트웨어 팀 소속이 아니었다고 합니다.

사용자들은 에이전트로 Jira 작업 항목을 만들고 상태를 바꾸고 결정 내용을 기록했습니다. 회의에서 할 일을 정한 뒤 누군가 다시 업무 관리 프로그램을 열어 옮겨 적는 과정까지 AI 활용 범위에 들어온 겁니다.

경영진 입장에서도 익숙한 일입니다. 회의 요약을 빨리 받았더라도 담당자 배정과 후속 업무 등록이 안 됐다면 누군가는 그 일을 해야 합니다. AI가 정리한 내용을 업무 시스템에 남길 수 있어야 다음 사람이 맡아서 진행하기도 쉬워집니다.

Block에서는 직원이 필요한 자료를 찾는 과정을, Atlassian에서는 업무 기록을 쓰는 활용까지 살펴봤습니다. 우리 회사에서 복사와 입력이 어느 단계에 남아 있는지에 따라 연결할 도구도 달라집니다.

연결은 됐는데 여전히 못 쓴다면

재고 조회 도구를 만들었다고 해봅시다. AI가 받아온 답은 100입니다.

100개일까요, 100박스일까요? 창고에 있는 총량일까요, 다른 고객에게 예약한 물량을 빼고 지금 판매할 수 있는 수량일까요? 숫자만 맞게 가져와도 영업 담당자는 다시 확인해야 합니다.

도구를 만들 때는 무엇을 입력받고 어떤 의미의 결과를 돌려줄지 정해야 합니다. 재고라면 상품 코드와 창고, 수량 단위, 조회 시각을 함께 반환하는 식입니다. 조회에 실패했을 때 0을 돌려주면 AI는 품절이라고 안내할 수 있으니 실패와 재고 없음도 구분합니다.

Anthropic의 도구 설계 글 에서도 기존 API를 그대로 감싼 도구를 무작정 늘리기보다 중요한 업무에 맞는 도구를 만들 것을 권합니다. 모든 연락처를 한꺼번에 가져오게 하기보다 필요한 연락처를 검색하게 만드는 예시를 듭니다.

견적 업무라면 고객에게 필요한 상품의 판매 가능 수량을 확인하는 도구가 유용할 겁니다. 반면 창고 데이터 전체를 가져와 AI에게 직접 해석하게 하면 불필요한 자료를 읽고 수량을 잘못 집계할 여지도 커집니다. 어떤 작업을 모델에게 맡기고 어디까지 프로그램에서 처리할지 정하는 일이 도구 설계입니다.

이 과정에서 현업의 노하우도 필요합니다. 반품 검사 중인 상품은 판매 가능 재고에서 빼야 한다거나, 본사와 지사가 같은 이름을 써도 청구 거래처는 따로 찾아야 한다는 기준입니다. 담당자에게는 당연하지만 시스템 연결 문서에는 빠져 있을 수 있습니다.

앞선 암묵지 자산화 글 에서 다룬 판단 기준을 여기서는 도구의 조회 조건과 검증 규칙으로 남길 수 있습니다. 현업이 AI 결과를 바로잡을 때 그 이유를 확인해 반영하면 다음 담당자도 같은 기준으로 일할 수 있습니다.

입력까지 맡기려면 완료를 확인해야 합니다

조회 다음에는 쓰기 권한을 정해야 합니다. 재고를 읽는 것과 견적을 저장하는 것, 고객에게 발송하는 것은 서로 다른 작업입니다.

NetSuite의 MCP 도구도 연결한 사용자의 역할과 권한을 적용합니다. 회사는 AI에서 사용할 별도 역할을 만들어 허용할 기록과 작업을 좁힐 수 있습니다. 재무팀 관리자가 넓은 권한을 갖고 있다고 해서 그 계정을 모든 직원의 AI에 연결할 필요는 없겠죠.

우리는 견적 초안 저장과 발송을 나누어 구성할 수 있습니다. AI가 초안을 저장하면 담당자가 거래처와 금액을 검토하고 발송을 승인합니다. 앞선 AI 결재선 글 처럼 승인한 뒤 내용이 바뀌었다면 바뀐 내용을 다시 확인하도록 해야 합니다.

저장 결과를 확인하는 절차도 필요합니다. ERP에는 견적이 저장됐는데 네트워크 문제로 응답을 못 받았다고 해봅시다. AI가 실패했다고 생각해 같은 견적을 또 만들면 중복 건이 생깁니다. 이럴 때는 같은 요청으로 저장한 기록이 있는지 먼저 조회하고, 있으면 그 결과를 가져오도록 구현합니다.

ERP 저장은 성공했지만 CRM 상담 기록만 실패할 수도 있습니다. 직원에게도 견적 저장 완료와 상담 기록 미완료를 나눠 알려줘야 어디부터 이어서 일할지 알 수 있겠죠. 실패한 단계를 따로 남겨야 이미 만든 견적을 다시 생성하지 않고 상담 기록만 처리할 수 있습니다.

업무가 끝났는지는 회사 시스템의 실제 기록으로 확인해야 합니다. 견적 번호와 저장 상태, 발송 결과를 확인한 뒤 안내하게 만들면 담당자도 AI의 답변을 믿고 다음 일을 진행할 근거가 생깁니다.

연결한 도구를 누가 관리하는지도 확인해야 합니다

견적 업무에 고객 메일을 읽는 기능과 CRM 조회, 외부 발송 도구를 함께 연결했다고 해봅시다. 누군가 메일에 견적 요청과 함께 다른 거래처의 단가표를 특정 주소로 보내라는 지시를 숨겨놓으면 어떨까요? AI가 그 문장을 직원의 지시로 잘못 받아들이면, 허용된 도구를 엉뚱한 목적에 사용할 수 있습니다. 읽어야 할 자료에 명령을 섞어 AI의 행동을 바꾸려는 공격을 프롬프트 인젝션이라고 합니다.

MCP로 업무 기능을 연결할 때는 이런 보안 문제도 함께 살펴야 합니다. Atlassian의 보안 안내 에서도 문서에 섞인 악성 지시뿐 아니라 MCP 서버가 제공하는 도구 설명의 변조, 신뢰하지 못할 서버의 사후 변경을 위험으로 짚습니다. 처음 연결할 때 정상으로 보였던 도구도 운영 중에 바뀔 수 있는 겁니다.

그래서 편리해 보이는 MCP 서버를 발견했다고 바로 회사 계정부터 연결해서는 안 됩니다. 누가 만들고 운영하는지, 어떤 자료를 가져가며 어디로 보내는지 확인해야 합니다. 직원 PC에서 실행하는 서버라면 어떤 파일과 네트워크에 접근할 수 있는지도 살펴봅니다. 회사에서 승인한 서버와 도구를 관리하고, 업데이트로 기능이나 접근 범위가 달라졌을 때 다시 검토할 담당자도 정합니다.

AI에게 주의하라고 적어두는 데 더해 프로그램에서도 허용 범위를 제한해야 합니다. 견적에 필요한 거래처 자료만 조회하게 하고, 외부 발송은 수신자와 첨부 내용을 확인한 뒤 실행하도록 구성하는 식입니다. AI가 읽은 메일 내용만으로 접근 권한이나 발송 승인이 바뀌어서는 안 됩니다. 읽기 전용 도구도 민감한 자료를 가져올 수 있으므로 조회 범위와 그 자료가 전달되는 AI 서비스까지 확인할 대상입니다.

로그인 연동도 보안 검토에 포함합니다. 접속 토큰은 프로그램이 서비스를 사용할 때 제시하는 자격증명입니다. MCP 공식 보안 지침 은 서버가 자신을 대상으로 발급한 토큰인지 검증하도록 하고, 검증 없이 하위 API에 그대로 전달하는 방식을 금지합니다. 연결에 성공했다는 화면만 보고 이런 확인 절차까지 갖췄다고 판단할 수는 없습니다.

운영 중에는 누가 어떤 도구로 어느 기록을 조회·변경했고 어디로 발송했는지 남겨야 합니다. 다만 로그에 토큰이나 고객 자료 전체를 그대로 남기지 않도록 수집 범위를 정합니다. 문제가 생겼을 때 해당 연결을 끊고 자격증명을 폐기할 수 있어야 담당자가 추가 실행을 막고 영향을 확인할 수 있습니다.

우리 회사에서는 무엇부터 연결하면 될까?

저희는 직원이 매번 두 프로그램을 오가며 같은 내용을 옮기는 업무부터 살펴보는 편이 좋다고 생각합니다. 견적 등록이나 상담 후속 업무 생성처럼 시작과 끝을 확인하기 쉬운 작업이 좋습니다.

담당자와 실제 처리 과정을 따라가 봅니다. 어느 시스템에서 고객을 찾고 어떤 자료로 금액을 정하는지 확인합니다. 같은 고객인지 판단하느라 멈추는지, 옮겨 적을 항목이 많아서 오래 걸리는지도 구분합니다. 연결할 프로그램과 도구는 그다음에 정할 수 있습니다.

처음에는 조회 결과를 현업 담당자의 결과와 비교하고, 쓰기는 테스트 환경에서 초안 등록부터 시험해봅니다. 이름이 같은 거래처, 수량 단위가 다른 상품, 저장 도중 응답이 끊긴 상황도 포함합니다. 실제 운영에서는 담당자가 이런 예외를 처리하느라 다시 바빠질 수 있으니까요.

이때 AI 평가 의 기준도 답변 문장에만 두지 않습니다. 올바른 거래처에 견적이 한 번만 저장됐는지, 승인 없이 발송하지 않았는지까지 확인합니다. 고객 메일에 다른 거래처 자료를 보내라는 지시가 섞였을 때 이를 따르지 않는지, 권한 밖의 조회는 서버에서 차단하는지도 시험합니다.

성과는 사람이 다시 입력한 건수와 업무 완료까지 걸린 시간으로 살펴볼 수 있습니다. 확인·수정에 쓰는 시간도 같이 봅니다. 재입력은 줄었는데 잘못 저장한 내용을 고치는 일이 늘었다면 자동화 범위를 넓히기 전에 도구와 확인 절차를 손볼 일입니다.

나가며

AI가 작성한 답변을 들고 직원이 ERP와 CRM을 돌아다니며 옮겨 적고 있다면 그 과정을 함께 살펴볼 필요가 있습니다. 필요한 자료를 가져오는 일과 실제 기록을 남기는 일까지 연결해야 직원의 수작업을 줄일 수 있습니다.

MCP는 이런 연결에 사용할 공통 규약입니다. 기존 API와 업무 기능을 재사용하면서 여러 AI 애플리케이션에 도구를 제공할 수 있습니다. 여기에 우리 회사의 고객 구분 방식, 재고 기준, 승인 절차를 반영해야 현업에서 쓸 수 있는 구성이 됩니다.

막상 시작하면 어느 시스템을 연결할지 외에도 결정할 것이 많습니다. 담당자가 평소 어떤 근거로 판단하는지 알아야 하고, 그 기준을 도구의 입력과 결과에 담아야 합니다. 권한을 나누고 중복 실행과 부분 실패에 대비하는 데에는 업무 이해와 엔지니어링 경험이 함께 필요합니다.

우리 엡실론델타는 현업의 업무를 살펴보고 암묵적인 판단 기준을 정리하는 일부터 MCP와 사내 시스템 연결, 업무용 도구 개발, 검증과 운영까지 함께 도와드리겠습니다.

AI는 도입했는데 직원들이 여전히 복사와 입력에 시간을 쓰고 있다면 contact@epsilondelta.ai 로 연락 주세요. 개인정보를 가린 업무 예시와 사용 중인 시스템, 사람이 옮겨 적는 항목부터 함께 살펴보겠습니다. 지금의 업무에서 어디를 연결하고 무엇을 확인해야 실제로 일을 줄일 수 있을지 찾아보겠습니다.