플러그인에서 앱·커넥터·MCP로

챗GPT가 '말하는 도구'에서 '연결되는 도구'가 된 순간

처음 ChatGPT를 써 본 사람들은 대개 이렇게 생각했습니다. "질문하면 답해 주는 똑똑한 채팅창이구나." 틀린 말은 아닙니다. 하지만 지금의 ChatGPT를 그렇게만 이해하면 절반도 보지 못한 것입니다. 오늘의 ChatGPT는 단순히 문장을 생성하는 도구가 아니라, 문서 저장소를 검색하고, 캘린더를 확인하고, 업무 시스템에서 정보를 가져오고, 때로는 사용자의 승인을 받아 외부 서비스에 작업을 실행하는 연결형 인터페이스로 바뀌고 있습니다.

이 변화는 조용하지만 큽니다. 예전에는 사용자가 여러 화면을 오가며 일했습니다. 드라이브에서 파일을 찾고, 메신저에서 회의 내용을 확인하고, CRM에서 고객 정보를 보고, 다시 보고서 문서로 돌아와 정리했습니다. ChatGPT를 연결형 도구로 쓰면 흐름이 달라집니다. 사용자는 "지난주 A사 관련 회의와 제안서 초안을 바탕으로 오늘 미팅 준비 메모를 만들어 줘"라고 말할 수 있고, ChatGPT는 허용된 범위 안에서 문서, 대화, 일정, 업무 도구를 참고해 하나의 작업 흐름으로 묶을 수 있습니다.

물론 여기에는 조건이 붙습니다. ChatGPT가 모든 회사 시스템을 저절로 알고 들어가는 것은 아닙니다. 권한을 받아야 하고, 연결된 도구가 있어야 하며, 어떤 데이터를 읽고 어떤 작업을 실행할 수 있는지 정해져 있어야 합니다. 그래서 이제 중요한 질문은 "프롬프트를 어떻게 잘 쓰느냐"에서 한 걸음 더 나아갑니다. 무엇을 연결할 것인가, 어디까지 허용할 것인가, 실행 전에 누가 확인할 것인가가 핵심이 됩니다.

앞 장에서 우리는 Projects, custom GPTs, skills를 통해 팀의 지식과 절차를 재사용하는 방법을 보았습니다. 이번 장은 그다음 단계입니다. 팀의 지식이 정리되었다면, 이제 그 지식이 놓인 실제 업무 시스템과 ChatGPT를 어떻게 연결할지 생각해야 합니다. 여기서 오래된 단어인 "플러그인"에만 머물면 현재의 생태계를 제대로 이해하기 어렵습니다. 이제는 apps, connectors, MCP, agents라는 새로운 지도를 함께 봐야 합니다.

플러그인은 왜 중요했고, 왜 충분하지 않았는가

ChatGPT 플러그인은 초기 생성형 AI 생태계에서 매우 중요한 전환점이었습니다. 플러그인이 등장하기 전의 ChatGPT는 주로 훈련된 지식과 대화 안에 주어진 정보에 의존했습니다. 그래서 최신 뉴스, 개인 문서, 회사 데이터, 실시간 예약 정보처럼 바깥세상에 있는 정보에는 약했습니다. OpenAI가 2023년에 소개한 플러그인은 이런 한계를 줄이기 위해 ChatGPT가 최신 정보에 접근하고, 계산을 실행하고, 서드파티 서비스를 사용할 수 있게 하는 도구로 설명되었습니다.¹

당시 플러그인이 보여 준 가능성은 분명했습니다. 여행 서비스를 연결하면 항공권이나 숙소 정보를 찾을 수 있고, 쇼핑 서비스를 연결하면 상품 정보를 비교할 수 있으며, 업무 자동화 서비스를 연결하면 다른 앱의 작업을 트리거할 수 있었습니다. 사용자는 채팅창에서 자연어로 말하고, ChatGPT는 뒤에서 외부 도구를 불러오는 방식이었습니다. 이것은 "AI가 말만 하는 존재가 아니라 도구를 쓸 수 있는 존재"라는 사실을 대중에게 보여 준 첫 번째 큰 장면이었습니다.

하지만 플러그인 중심의 이해에는 한계도 있었습니다. 플러그인을 하나의 "추가 기능"처럼 생각하면, 도구 연결이 마치 브라우저 확장 프로그램을 설치하는 일처럼 보입니다. 필요한 기능을 찾아 붙이면 끝이라고 느끼기 쉽습니다. 그러나 실무에서 도구 연결은 그렇게 단순하지 않습니다. 어떤 데이터에 접근할 수 있는지, 사용자 권한을 어떻게 반영할지, 읽기와 쓰기를 어떻게 나눌지, 실행 전에 승인 절차를 둘지, 결과를 어디에 기록할지까지 함께 설계해야 합니다.

또 하나의 한계는 플러그인이라는 단어가 너무 넓고 느슨하다는 점입니다. 어떤 플러그인은 단순히 정보를 가져오기만 하고, 어떤 플러그인은 외부 서비스에 명령을 보냅니다. 어떤 것은 사용자 인터페이스를 보여 주고, 어떤 것은 API 호출만 처리합니다. 사용자는 "플러그인을 켰다"고 생각하지만, 실제로는 문서 검색, 업무 시스템 접근, 외부 앱 실행, 자동화 흐름이 뒤섞여 있었습니다.

그래서 현재의 연결 구조를 이해하려면 "플러그인"이라는 낡은 상자에서 꺼내어 다시 분류해야 합니다. 지금 중요한 구분은 다음과 같습니다.

이 네 가지를 구분하면 도구 연결이 훨씬 선명해집니다. 앱은 사용자가 체감하는 제품 경험에 가깝고, 커넥터는 데이터와 업무 시스템에 접근하는 통로이며, MCP는 그 연결을 표준화하는 규약입니다. 에이전트는 이 연결된 도구들을 이용해 여러 단계를 수행하는 실행 주체에 가깝습니다.

Apps: 서비스가 채팅창 안으로 들어온다

앱은 "ChatGPT 안에서 외부 서비스를 쓴다"는 경험에 가깝습니다. 예를 들어 사용자가 "이 행사 신청 양식을 만들어 줘"라고 말했을 때, 단순히 질문 목록만 텍스트로 받는 것이 아니라 실제 양식 도구의 기능이 대화 안에서 열릴 수 있습니다. "이 내용을 발표자료 초안으로 만들어 줘"라고 하면 디자인 도구나 프레젠테이션 도구가 연결되어 결과물을 보여 줄 수 있습니다. "이 PDF에서 필요한 부분을 정리하고 페이지를 재배열해 줘"처럼 문서 편집 서비스가 대화 흐름 안에서 작동할 수도 있습니다.

전통적인 소프트웨어에서는 사용자가 앱을 찾아갑니다. 파일을 만들려면 문서 앱을 열고, 디자인을 하려면 디자인 앱을 열고, 예약을 하려면 예약 앱을 엽니다. ChatGPT 앱 모델에서는 반대로 서비스가 대화의 맥락 안으로 들어옵니다. 사용자의 말이 곧 작업의 시작점이 되고, ChatGPT는 적절한 앱을 호출해 화면, 카드, 버튼, 미리보기 같은 인터페이스를 보여 줄 수 있습니다. OpenAI의 Apps SDK 관련 문서는 ChatGPT 안에서 MCP Apps 호환 구조를 구현해, 한 번 만든 UI가 ChatGPT와 다른 호환 호스트에서 작동할 수 있는 방향을 설명합니다.²

앱이 중요한 이유는 단순합니다. 사람은 긴 API 응답보다 화면을 이해하기 쉽습니다. 특히 업무 현장에서는 결과물을 보고 고쳐야 하는 경우가 많습니다. 카피 문안, 디자인 시안, 양식, 표, 지도, 예약 후보, 결제 화면처럼 텍스트만으로는 부족한 작업이 있습니다. 앱은 이런 작업을 대화 안에서 이어 가게 만듭니다.

다만 앱을 "마법 버튼"으로 이해하면 곤란합니다. 앱은 특정 서비스의 기능을 ChatGPT 안으로 가져오는 것이지, 그 서비스의 모든 기능을 완전히 대체하는 것은 아닙니다. 디자인 앱이 연결되어도 정교한 브랜드 시스템 편집은 원래 도구에서 해야 할 수 있고, 문서 앱이 연결되어도 최종 서명이나 배포는 별도 승인 절차를 거쳐야 할 수 있습니다. 앱은 사용자의 이동 거리를 줄여 주지만, 업무 책임을 없애 주지는 않습니다.

한국 조직에서 앱을 도입할 때는 특히 "초안 생성"과 "공식 배포"를 분리해야 합니다. 예를 들어 ChatGPT 안에서 행사 신청 폼 초안을 만들 수는 있습니다. 그러나 외부 고객에게 링크를 발송하기 전에는 개인정보 수집 항목, 고지 문구, 보관 기간, 수신자 범위를 사람이 확인해야 합니다. 앱은 빠른 실행을 도와주지만, 조직의 승인 문화를 건너뛰는 통로가 되어서는 안 됩니다.

Connectors: 회사의 문서와 업무 맥락으로 들어가는 문

커넥터는 ChatGPT와 외부 데이터 소스 또는 업무 도구를 이어 주는 통로입니다. Google Drive, Gmail, Outlook, Teams, SharePoint, Dropbox, Box, Linear 같은 도구가 대표적인 예로 자주 언급됩니다. 커넥터를 사용하면 ChatGPT가 사용자의 권한 안에서 문서를 검색하거나, 이메일 내용을 요약하거나, 일정 정보를 확인하거나, 업무 티켓을 찾아볼 수 있습니다. OpenAI의 개발자 문서도 커넥터를 Google Workspace나 Dropbox 같은 인기 서비스에 대한 OpenAI 유지 관리 MCP 래퍼로 설명하며, 원격 MCP 서버는 공개 인터넷에서 동작하는 MCP 서버가 될 수 있다고 설명합니다.³

커넥터가 유용한 이유는 ChatGPT의 답변이 추상적인 조언에서 실제 업무 맥락으로 내려오기 때문입니다. "제안서 잘 쓰는 법을 알려 줘"와 "우리 드라이브의 A사 제안서 초안과 지난 회의록을 바탕으로 내일 미팅용 질문 목록을 만들어 줘"는 완전히 다른 요청입니다. 후자는 회사의 실제 자료를 참고하기 때문에 바로 쓸 수 있는 결과에 가까워집니다.

예를 들어 영업팀은 고객사별 폴더에 있는 제안서, 회의록, 견적 메모를 커넥터로 검색하게 할 수 있습니다. 마케팅팀은 브랜드 가이드, 캠페인 성과표, 콘텐츠 캘린더를 참고해 다음 캠페인 브리프를 만들 수 있습니다. 고객지원팀은 FAQ, 제품 릴리스 노트, 과거 티켓을 검색해 응대 초안을 만들 수 있습니다. 개발팀은 이슈 트래커와 문서 저장소를 연결해 버그 리포트, 릴리스 노트, 테스트 계획을 정리할 수 있습니다.

하지만 커넥터는 편리한 만큼 위험합니다. 커넥터는 질문에 답하기 위해 문을 열어 줍니다. 그런데 어떤 문을 열었는지, 그 문 뒤에 어떤 자료가 있는지, 누가 그 문을 통과할 수 있는지 명확하지 않으면 정보 유출이나 잘못된 실행으로 이어질 수 있습니다. 특히 한국 기업의 문서 저장소에는 고객 개인정보, 계약 조건, 임직원 평가, 미공개 사업 전략, 법무 검토 의견이 섞여 있는 경우가 많습니다. "드라이브 연결"이라는 말은 가볍지만, 실제로는 회사의 기억 창고 일부를 AI에게 보여 주는 일입니다.

따라서 커넥터를 설계할 때는 먼저 연결 범위를 줄여야 합니다. 전체 드라이브를 열기보다 프로젝트 폴더를 열고, 모든 메일을 열기보다 특정 라벨이나 기간을 대상으로 삼고, 모든 티켓을 열기보다 특정 큐나 상태만 허용하는 편이 안전합니다. 기술적으로 가능한 연결과 업무적으로 허용해야 하는 연결은 다릅니다.

MCP: AI 도구 연결의 USB-C 같은 표준

MCP, 즉 Model Context Protocol은 외부 도구와 AI 애플리케이션을 연결하는 표준 규약입니다. 공식 MCP 문서는 MCP를 AI 애플리케이션을 외부 시스템에 연결하기 위한 오픈소스 표준으로 설명하며, USB-C가 여러 전자기기를 표준 방식으로 연결하듯 MCP도 AI 애플리케이션과 외부 시스템 사이의 연결 방식을 표준화한다고 비유합니다.⁴

이 비유는 꽤 유용합니다. 예전에는 기기마다 충전 단자가 달랐습니다. 어떤 기기는 둥근 단자, 어떤 기기는 납작한 단자, 어떤 기기는 전용 케이블을 써야 했습니다. 외부 도구 연결도 비슷했습니다. AI 시스템이 캘린더, 파일 저장소, 데이터베이스, 검색엔진, 사내 API에 연결하려면 각각 다른 방식으로 붙여야 했습니다. MCP는 이 복잡성을 줄이려는 시도입니다. 모델이나 AI 앱은 MCP 클라이언트처럼 행동하고, 외부 시스템은 MCP 서버로 기능을 공개합니다.

MCP 서버는 보통 "내가 어떤 도구를 제공하는지"를 목록으로 알려 줍니다. 각 도구에는 이름, 설명, 입력 형식, 반환 형식이 있습니다. ChatGPT는 사용자의 요청을 보고 어떤 도구를 호출할지 판단합니다. 서버는 실제 작업을 수행하고 결과를 돌려줍니다. 이때 중요한 것은 ChatGPT가 직접 데이터베이스가 되는 것이 아니라, 정해진 통로를 통해 외부 시스템에 요청을 보내고 결과를 받는다는 점입니다.

간단한 흐름은 다음과 같습니다.

사용자 요청
→ ChatGPT가 필요한 도구 판단
→ MCP 서버에 사용 가능한 도구 목록 확인
→ 적절한 도구와 입력값 선택
→ 외부 시스템에서 검색 또는 실행
→ 결과 반환
→ ChatGPT가 사용자에게 이해하기 쉬운 형태로 정리

예를 들어 사내 지식베이스 MCP 서버가 있다고 해 봅시다. 이 서버는 search_policy, fetch_document, summarize_change_log 같은 도구를 제공할 수 있습니다. 사용자가 "최근 개인정보 처리방침 개정 내용 중 고객 안내에 반영해야 할 사항을 정리해 줘"라고 요청하면, ChatGPT는 먼저 정책 문서를 검색하고, 관련 문서를 가져오고, 변경 이력을 확인한 뒤 요약을 만들 수 있습니다. 이때 MCP는 ChatGPT와 사내 지식베이스 사이의 약속된 대화 방식이 됩니다.

다만 여기서 반드시 기억해야 할 점이 있습니다. MCP는 연결을 표준화할 뿐, 연결 대상이 안전하다고 보장하지는 않습니다. USB-C 포트에 정품 충전기를 꽂을 수도 있고, 고장 난 장치를 꽂을 수도 있습니다. MCP도 마찬가지입니다. 신뢰할 수 있는 서버를 연결하면 강력한 업무 도구가 되지만, 검증되지 않은 서버를 연결하면 데이터 유출, 잘못된 명령 실행, 권한 남용의 통로가 될 수 있습니다.

앱, 커넥터, MCP, 에이전트는 어떻게 함께 움직이는가

이제 네 개념을 하나의 업무 장면으로 묶어 보겠습니다. 한 제조기업의 영업팀장이 다음과 같이 요청한다고 합시다.

A사와의 다음 미팅을 준비해야 해.
지난 3개월간 A사 관련 회의록, 제안서 초안, 미해결 이슈를 참고해서
1페이지 미팅 브리프를 만들고,
마지막에는 우리가 확인해야 할 질문 5개를 정리해 줘.

이 요청을 처리하는 데는 여러 층이 관여할 수 있습니다. Project는 A사 제안이라는 장기 맥락을 담고 있습니다. 커넥터는 드라이브의 제안서, 회의록, 이슈 트래커의 티켓을 검색합니다. MCP는 ChatGPT가 각 도구와 통신하는 표준 연결 방식으로 작동합니다. 만약 결과를 프레젠테이션 초안이나 고객용 양식으로 만들고 싶다면 앱이 대화 안에서 화면을 제공할 수 있습니다. 더 나아가 "미팅 브리프 작성 → 질문 목록 생성 → 일정 확인 → 팀원에게 초안 공유 요청"까지 여러 단계를 이어서 수행한다면 에이전트적 흐름이 됩니다.

여기서 구분이 중요합니다. 앱은 사용자가 보는 경험에 가깝고, 커넥터는 데이터와 업무 도구에 접근하는 통로이며, MCP는 그 통로의 기술적 규약입니다. 에이전트는 목표를 이루기 위해 이 도구들을 순서대로 사용하는 실행 패턴입니다.

이 표를 기억하면 유행어에 휘둘리지 않습니다. 누군가 "우리도 MCP 해야 하지 않나요?"라고 묻는다면 먼저 물어야 합니다. "우리가 필요한 것은 대화 안의 앱 경험인가, 문서 검색 커넥터인가, 사내 시스템 표준 연결인가, 아니면 다단계 자동화 에이전트인가?" 이 질문에 답하지 못한 채 기술을 붙이면 도구만 늘고 업무는 나아지지 않습니다.

읽기와 쓰기를 분리하라

도구 연결에서 가장 중요한 첫 번째 원칙은 읽기와 쓰기를 분리하는 것입니다. 읽기는 정보를 가져오는 일입니다. 문서 검색, 일정 확인, 티켓 조회, 데이터 요약이 여기에 속합니다. 쓰기는 외부 시스템의 상태를 바꾸는 일입니다. 이메일 발송, 일정 생성, 고객 정보 수정, 티켓 상태 변경, 결제 요청, 파일 삭제가 여기에 속합니다.

읽기 작업도 민감할 수 있지만, 쓰기 작업은 한 단계 더 위험합니다. 잘못된 정보를 읽으면 보고서가 틀릴 수 있습니다. 그러나 잘못된 쓰기 작업은 고객에게 메일이 나가거나, 데이터베이스가 변경되거나, 계약 관련 기록이 수정되는 결과로 이어질 수 있습니다. 그래서 ChatGPT 개발자 모드와 MCP 커넥터 관련 설명에서도 쓰기 작업의 강력함과 위험성을 함께 강조하며, 데이터 변경을 수반하는 도구 호출에는 사용자의 검토와 승인이 필요하다는 점이 반복적으로 언급됩니다.⁵

실무에서는 다음과 같이 권한을 나누는 편이 좋습니다.

좋은 운영 원칙은 간단합니다. 처음에는 읽기 전용으로 시작하십시오. 충분히 검증된 뒤 초안 작성을 허용하고, 그다음 제한적 쓰기를 도입합니다. 고위험 쓰기는 가장 마지막에, 가장 좁은 범위로, 항상 사람이 승인하는 방식으로 열어야 합니다.

한국 조직에서는 특히 "AI가 발송했다"는 변명이 통하지 않습니다. 고객에게 잘못된 가격이 안내되었거나, 개인정보가 포함된 문서가 외부로 나갔거나, 내부 승인 전 일정이 확정되었다면 책임은 조직에 남습니다. 따라서 쓰기 권한은 편의 기능이 아니라 내부통제의 대상입니다.

데이터 범위는 넓힐수록 똑똑해지는 것이 아니라 위험해진다

많은 팀이 도구를 연결할 때 이렇게 생각합니다. "많이 연결할수록 더 똑똑해지겠지." 반은 맞고 반은 틀립니다. 필요한 자료에 접근할 수 있으면 답변은 좋아집니다. 하지만 불필요한 자료까지 열어 주면 답변이 산만해지고, 보안 위험도 커집니다.

예를 들어 인사팀이 전사 드라이브를 연결했다고 해 봅시다. ChatGPT가 채용 공고를 다듬는 과정에서 평가표, 연봉 자료, 징계 문서, 면접자 개인정보가 섞인 폴더까지 검색할 수 있다면 큰 문제입니다. 마케팅팀이 캠페인 문안을 만들면서 법무 검토 전 내부 전략 문서나 미공개 파트너십 계약서를 참고한다면, 외부 콘텐츠에 노출되어서는 안 되는 정보가 섞일 수 있습니다.

데이터 범위 설계는 다음 질문에서 시작해야 합니다.

좋은 커넥터 설계는 "무엇을 연결할까"보다 "무엇을 연결하지 않을까"를 더 많이 고민합니다. 특히 처음 연결할 때는 업무에 꼭 필요한 최소 범위만 열고, 사용 기록을 보며 조금씩 확장하는 편이 안전합니다.

로그는 감시가 아니라 기억 장치다

도구 연결이 시작되면 로그가 중요해집니다. 일반 채팅에서는 "무슨 질문을 했고 어떤 답을 받았는지" 정도가 핵심입니다. 하지만 커넥터와 MCP가 들어오면 기록해야 할 것이 늘어납니다. 어떤 도구를 호출했는지, 어떤 입력값을 보냈는지, 어떤 결과를 받았는지, 누가 승인했는지, 실패했는지, 외부 시스템이 실제로 변경되었는지가 남아야 합니다.

로그를 남기는 이유는 사람을 감시하기 위해서만이 아닙니다. 품질을 개선하고, 사고를 추적하고, 책임 있는 운영을 하기 위해서입니다. 고객에게 잘못된 안내가 나갔다면 어떤 문서를 근거로 만들었는지 확인해야 합니다. 업무 시스템의 값이 바뀌었다면 누가 어떤 승인으로 실행했는지 알아야 합니다. AI가 같은 실수를 반복한다면 어떤 도구 설명이나 입력 스키마가 문제인지 찾아야 합니다.

도구 연결 로그에는 적어도 다음 항목이 필요합니다.

물론 로그 자체도 민감정보가 될 수 있습니다. 로그에 고객명, 개인정보, 계약 조건, API 응답 원문이 그대로 남으면 또 다른 위험이 생깁니다. 따라서 로그는 필요한 만큼만 남기고, 접근 권한과 보관 기간을 정해야 합니다. 로그는 안전을 위한 장치이지 새로운 정보 유출 창구가 되어서는 안 됩니다.

승인 흐름은 사용자를 귀찮게 하는 장치가 아니다

쓰기 작업을 할 때 매번 승인을 요구하면 사용자는 귀찮아할 수 있습니다. "그럴 거면 내가 직접 하지"라는 말이 나올 수도 있습니다. 하지만 승인 흐름은 불필요한 마찰이 아니라, AI가 실제 세계에 영향을 미치기 시작할 때 필요한 브레이크입니다.

좋은 승인 흐름은 모든 작업을 똑같이 막지 않습니다. 위험도에 따라 다르게 작동합니다. 문서 검색은 자동으로 허용할 수 있습니다. 이메일 초안 작성은 자동으로 허용하되 발송은 막아야 합니다. 내부 티켓에 태그를 다는 정도는 낮은 위험으로 볼 수 있지만, 티켓을 종료하거나 고객에게 답변을 보내는 작업은 승인이 필요합니다. 결제, 삭제, 권한 변경, 외부 공유는 항상 사람이 확인해야 합니다.

승인 화면이나 승인 문서에는 사용자가 판단할 수 있는 정보가 보여야 합니다. 단순히 "실행하시겠습니까?"라고 묻는 것은 부족합니다. 무엇을, 어디에, 어떤 값으로, 누구 권한으로 실행하는지 보여 주어야 합니다.

쓰기 작업 승인 전 확인 항목

작업: 고객지원 티켓 상태 변경
도구: helpdesk.update_ticket_status
대상: 티켓 #48291
변경 전: 검토 중
변경 후: 고객 답변 대기
추가 메시지: 고객에게 아직 발송하지 않음
근거: 2026-05-13 내부 회의 메모
승인자: 담당 매니저
실행 후 되돌릴 수 있는가: 가능

이 정도 정보가 있어야 사용자가 책임 있게 승인할 수 있습니다. 특히 JSON 입력값이나 API 파라미터가 표시되는 환경에서는 사람이 읽을 수 있는 요약을 함께 제공하는 것이 좋습니다. 기술자는 JSON을 볼 수 있지만, 일반 업무 사용자는 "이게 실제로 무엇을 바꾸는지"를 알아야 승인할 수 있습니다.

도구가 많아질수록 프롬프트는 더 명확해야 한다

도구 연결이 늘어나면 ChatGPT가 더 강력해지지만, 동시에 더 헷갈릴 수도 있습니다. 비슷한 도구가 여러 개 있으면 모델이 엉뚱한 도구를 선택할 수 있습니다. 고객 정보를 찾을 때 CRM을 써야 하는데 드라이브 문서를 검색할 수도 있고, 최신 정책은 정책 데이터베이스에 있는데 오래된 PDF를 참고할 수도 있습니다. 그래서 도구 연결 환경에서는 프롬프트가 더 짧아지는 것이 아니라, 도구 선택 기준이 더 명확해져야 합니다.

나쁜 요청은 이렇습니다.

A사 자료 찾아서 미팅 준비해 줘.

이 요청은 사람에게도 모호합니다. 어떤 자료를 어디서 찾아야 하는지, 최신 기준은 무엇인지, 외부 공유 가능한 자료만 써야 하는지 알 수 없습니다. 연결된 도구가 많다면 더 위험합니다.

좋은 요청은 도구와 범위, 금지사항을 함께 지정합니다.

A사 미팅 준비 브리프를 작성해 줘.

사용할 도구:
- Drive 커넥터: /Sales/A사/2026 폴더의 승인본 문서만 검색
- CRM 커넥터: A사 계정의 최근 90일 활동 기록만 조회
- 이슈 트래커: 상태가 Open 또는 In Progress인 항목만 조회

사용하지 말 것:
- 개인 메일함 검색 금지
- 2025년 이전 제안서 금지
- 외부 공유 금지 문서의 문장을 고객용 문안에 포함 금지

출력:
1. 한 줄 상황 요약
2. 핵심 이슈 5개
3. 미팅에서 물어볼 질문 5개
4. 확인 필요 사항
5. 참고한 문서와 기록 목록

이런 프롬프트는 길어 보이지만 실제로는 시간을 아낍니다. ChatGPT가 어떤 도구를 써야 하는지, 어떤 자료를 제외해야 하는지, 어떤 형식으로 답해야 하는지 분명하기 때문입니다. 도구 연결 환경에서는 "알아서 해 줘"가 가장 위험한 프롬프트가 될 수 있습니다.

MCP 서버를 설계할 때는 도구 설명이 곧 안전장치다

개발자나 고급 사용자가 직접 MCP 서버를 만든다면, 도구 설명과 입력 스키마를 대충 쓰면 안 됩니다. 모델은 도구의 이름과 설명, 입력값 구조를 보고 언제 어떤 도구를 쓸지 판단합니다. do_task, run, update처럼 모호한 이름은 위험합니다. 반대로 search_approved_contract_templates, create_draft_ticket_reply, update_internal_ticket_tag처럼 구체적인 이름은 모델의 선택을 돕습니다.

MCP 도구 설계에서는 다음 차이를 기억해야 합니다.

입력 스키마도 마찬가지입니다. 모델이 아무 문자열이나 넣게 하지 말고, 가능한 값과 필수값을 명확히 해야 합니다. 예를 들어 긴급도는 low, medium, high 중 하나로 제한하고, 외부 발송 여부는 true/false로 받으며, 고객 ID와 티켓 ID는 형식을 검증하는 식입니다. 도구 연결에서 구조화된 입력은 안전과 품질을 동시에 높입니다.

다음은 고객지원 티켓 조회 도구를 설명하는 간단한 예입니다.

{
  "name": "fetch_support_ticket_by_id",
  "description": "고객지원 티켓 ID로 티켓 내용을 조회한다. 읽기 전용 도구이며 고객에게 메시지를 보내지 않는다.",
  "input_schema": {
    "type": "object",
    "properties": {
      "ticket_id": {
        "type": "string",
        "description": "조회할 고객지원 티켓 ID. 예: TCK-48291"
      }
    },
    "required": ["ticket_id"]
  }
}

이 설명에서 중요한 문장은 "읽기 전용 도구이며 고객에게 메시지를 보내지 않는다"입니다. 모델뿐 아니라 사람도 이 도구의 성격을 이해할 수 있습니다. 반대로 쓰기 도구라면 "실행 전 사용자 승인이 필요하다", "외부 고객에게 메시지가 발송된다", "되돌릴 수 없다" 같은 설명을 넣어야 합니다.

보안 업무에서 보는 MCP의 무게

MCP가 단순한 개발자 장난감이 아니라는 점은 보안 운영 사례를 보면 더 분명해집니다. Microsoft는 Microsoft Sentinel MCP 커넥터 미리 보기 문서에서 ChatGPT 또는 Claude와 Microsoft Sentinel을 연결해 보안 운영센터 분석가가 보안 작업을 실행할 수 있는 흐름을 설명합니다. 이 문서는 Microsoft Entra 애플리케이션 등록, 권한 추가, OAuth 동의, 커넥터 설정 같은 단계를 안내하면서 동시에 최소 권한 원칙을 강조합니다.⁶

이 사례가 중요한 이유는 보안 업무가 도구 연결의 양면을 잘 보여 주기 때문입니다. 보안 분석가가 자연어로 로그를 탐색하고, 이상 징후를 요약하고, 관련 이벤트를 추적할 수 있다면 생산성은 크게 올라갑니다. 하지만 같은 연결이 과도한 권한을 가지면 민감한 보안 로그와 내부 인프라 정보가 노출될 수 있습니다. 더 나아가 잘못된 쓰기 작업이 허용되면 탐지 규칙, 티켓, 대응 워크플로에 영향을 줄 수도 있습니다.

따라서 규제 산업이나 보안 민감 업무에서는 "연결된다"는 사실보다 "어떤 권한으로 연결되는가"가 더 중요합니다. 전역 관리자 권한으로 편하게 연결하는 것은 빠르지만 위험합니다. 필요한 역할만 부여하고, 테스트 환경에서 검증하고, 승인 흐름과 감사 로그를 갖춘 뒤 운영 환경에 적용해야 합니다. 이는 금융, 의료, 법률, 공공, 교육 영역에서도 똑같이 적용됩니다.

오래된 용어에 묶이면 운영 설계가 낡아진다

아직도 많은 자료가 "ChatGPT 플러그인 추천"이라는 식으로 도구 연결을 설명합니다. 물론 입문자에게는 익숙한 말일 수 있습니다. 그러나 실무자는 한 단계 더 정확한 언어를 써야 합니다. 오래된 용어에 묶이면 문제를 잘못 정의하기 때문입니다.

예를 들어 어떤 팀이 "우리 회사에도 플러그인을 붙이자"고 말한다고 해 봅시다. 이 말만으로는 아무것도 결정할 수 없습니다. 회사 문서를 검색하려는 것인지, 사내 ERP에 접근하려는 것인지, 고객에게 이메일을 보내려는 것인지, ChatGPT 안에서 별도 UI를 띄우려는 것인지, 아니면 여러 단계를 자동화하려는 것인지 알 수 없습니다. 각각 필요한 설계가 다릅니다.

정확한 질문은 다음과 같아야 합니다.

우리가 연결하려는 대상은 무엇인가?
- 문서 저장소인가?
- 일정과 메일인가?
- CRM, ERP, 헬프데스크 같은 업무 시스템인가?
- 외부 고객이 보는 앱 경험인가?
- 여러 시스템을 오가는 자동화 흐름인가?

우리가 허용하려는 행동은 무엇인가?
- 검색과 요약만 허용할 것인가?
- 초안 작성까지 허용할 것인가?
- 실제 데이터 변경을 허용할 것인가?
- 외부 발송이나 결제까지 허용할 것인가?

누가 통제할 것인가?
- 연결 소유자는 누구인가?
- 권한 검토자는 누구인가?
- 로그를 누가 볼 수 있는가?
- 사고가 나면 누가 중지할 수 있는가?

이 질문에 답하면 비로소 도구 연결이 업무 설계가 됩니다. 그렇지 않으면 기능 도입에 그칩니다.

팀용 도구 연결 운영표

앞 장에서 Project, custom GPT, skill에도 소유자와 버전 관리가 필요하다고 했습니다. 도구 연결도 마찬가지입니다. 아니, 도구 연결은 더 엄격해야 합니다. 외부 시스템과 권한이 걸려 있기 때문입니다.

팀이나 조직은 최소한 다음과 같은 운영표를 가져야 합니다.

이 표의 마지막 줄이 중요합니다. 모든 연결을 "사용 중"으로 만들 필요는 없습니다. 오히려 "사용 금지", "보류", "파일럿", "폐기" 상태가 있어야 건강한 운영입니다. 연결하지 않기로 결정하는 것도 중요한 설계입니다.

도구 연결 전 점검 체크리스트

실제 도입 전에 다음 체크리스트를 통과시키면 사고 가능성을 크게 줄일 수 있습니다.

도구 연결 전 점검 체크리스트

1. 목적
- 이 연결이 해결할 업무 문제가 명확한가?
- 단순 편의가 아니라 반복 업무나 품질 문제를 줄이는가?

2. 데이터
- 접근할 데이터 범위가 최소화되어 있는가?
- 개인정보, 민감정보, 계약상 비밀이 포함되는가?
- 외부 공유 가능 자료와 내부 전용 자료가 구분되어 있는가?

3. 권한
- 읽기와 쓰기 권한이 분리되어 있는가?
- 고위험 작업은 매번 승인을 요구하는가?
- 관리자 권한이나 전체 접근 권한을 남용하지 않는가?

4. 사용자 경험
- 사용자가 어떤 도구가 호출되는지 알 수 있는가?
- 쓰기 작업 전 변경 내용을 이해할 수 있는가?
- 실패했을 때 사람이 개입할 수 있는가?

5. 로그와 감사
- 도구 호출 기록이 남는가?
- 누가 승인했는지 추적할 수 있는가?
- 로그의 보관 기간과 접근 권한이 정해져 있는가?

6. 운영
- 연결 소유자와 검토 주기가 정해져 있는가?
- 버전 변경 시 테스트 절차가 있는가?
- 문제가 생기면 즉시 비활성화할 수 있는가?

이 체크리스트는 도구 연결을 늦추기 위한 문서가 아닙니다. 오히려 안전하게 빨리 가기 위한 장치입니다. 처음부터 기준을 세워 두면 나중에 사고가 났을 때 허둥대지 않습니다.

연결형 ChatGPT를 위한 프롬프트 패턴

도구 연결 환경에서는 프롬프트에 네 가지를 넣는 습관이 좋습니다. 사용할 도구, 데이터 범위, 금지사항, 승인 조건입니다. 아래 패턴은 여러 업무에 응용할 수 있습니다.

작업:
[해야 할 일을 구체적으로 작성]

사용할 연결:
- [커넥터/앱/MCP 이름]: [사용 목적]

데이터 범위:
- 포함: [검색할 폴더, 기간, 프로젝트, 상태]
- 제외: [검색 금지 자료, 민감정보, 오래된 문서]

실행 제한:
- 읽기와 요약만 수행
- 외부 발송, 데이터 수정, 파일 삭제 금지
- 쓰기 작업이 필요하다고 판단되면 먼저 제안만 하고 실행하지 말 것

출력 형식:
1. 결론
2. 근거
3. 초안 또는 분석 결과
4. 확인 필요 사항
5. 사용한 자료와 도구 목록

예를 들어 고객지원 업무에서는 이렇게 쓸 수 있습니다.

티켓 TCK-48291의 답변 초안을 작성해 줘.

사용할 연결:
- Helpdesk 커넥터: 티켓 본문과 고객의 최근 문의 3건 조회
- FAQ 커넥터: 외부 공개 FAQ만 검색

데이터 범위:
- 포함: 현재 티켓, 최근 30일 동일 고객 문의, 2026년 승인 FAQ
- 제외: 내부 메모, 상담원 평가, 환불 승인 전 내부 논의

실행 제한:
- 고객에게 답변을 발송하지 말 것
- 티켓 상태를 변경하지 말 것
- 환불 가능 여부를 단정하지 말고 확인 필요로 표시할 것

출력:
1. 고객 이슈 요약
2. 답변 초안
3. 상담원 확인 필요 사항
4. 참고한 FAQ 항목

이 프롬프트의 핵심은 "하지 말아야 할 일"이 분명하다는 점입니다. 연결형 AI에서는 능력보다 경계가 더 중요할 때가 많습니다.

연결은 자동화를 부르고, 자동화는 책임을 부른다

도구가 연결되면 사람은 자연스럽게 더 많은 것을 맡기고 싶어집니다. 처음에는 문서 검색만 시킵니다. 그다음에는 초안을 만들게 합니다. 조금 지나면 티켓을 분류하게 하고, 담당자를 추천하게 하고, 상태를 바꾸게 하고, 고객에게 답변까지 보내고 싶어집니다. 이 흐름은 자연스럽습니다. 생산성이 올라가기 때문입니다.

하지만 자동화의 단계가 올라갈수록 책임도 올라갑니다. ChatGPT가 문서를 잘못 요약하면 사람이 고치면 됩니다. 그러나 고객에게 잘못된 메일을 자동 발송하면 이미 사건이 발생한 뒤입니다. 내부 데이터베이스를 잘못 수정하면 복구 비용이 듭니다. 보안 시스템에서 잘못된 조치를 실행하면 업무 전체에 영향을 줄 수 있습니다.

따라서 연결형 ChatGPT의 성숙도는 "얼마나 많은 권한을 줬는가"가 아니라 "얼마나 적절한 권한을 안전하게 운영하는가"로 평가해야 합니다. 좋은 조직은 모든 것을 자동화하지 않습니다. 자동화할 부분과 사람이 확인할 부분을 나눕니다. AI에게 맡길수록 사람의 책임이 사라지는 것이 아니라, 책임을 설계하는 일이 더 중요해집니다.

다음 단계: API와 구조화 출력으로 넘어가기 전에

이 장에서 본 apps, connectors, MCP는 ChatGPT를 실제 업무 환경과 연결하는 핵심 개념입니다. 플러그인이라는 오래된 단어는 이 변화를 설명하기에 너무 좁습니다. 이제 우리는 ChatGPT를 하나의 채팅창이 아니라, 프로젝트 맥락, 재사용 가능한 지침, 외부 도구, 승인 흐름, 로그가 결합된 업무 인터페이스로 보아야 합니다.

정리하면 이렇습니다. 플러그인은 ChatGPT가 외부 세계와 만날 수 있다는 가능성을 열었습니다. 앱은 그 가능성을 사용자 경험으로 확장했습니다. 커넥터는 회사의 문서와 업무 시스템을 대화 맥락으로 끌어왔습니다. MCP는 다양한 도구를 표준 방식으로 연결하는 기반을 제공합니다. 에이전트는 이 연결 위에서 여러 단계를 수행하는 방향으로 발전하고 있습니다.

하지만 연결의 본질은 기술보다 운영입니다. 권한을 최소화하고, 데이터 범위를 좁히고, 로그를 남기고, 쓰기 작업에는 승인 흐름을 두어야 합니다. 도구가 강력해질수록 프롬프트는 더 명확해야 하고, 조직의 책임 체계는 더 단단해야 합니다.

다음 장에서는 이 연결 구조를 개발자의 관점에서 더 깊게 살펴봅니다. 사람이 ChatGPT 화면에서 커넥터와 앱을 쓰는 수준을 넘어, API로 도구를 호출하고, function calling으로 외부 함수를 연결하고, structured outputs로 JSON 형식을 안정적으로 받는 방법을 다룰 것입니다. 지금까지의 핵심은 하나입니다. 연결은 시작일 뿐입니다. 진짜 실력은 연결된 도구를 검증 가능하고, 승인 가능하며, 되돌릴 수 있는 업무 흐름으로 만드는 데 있습니다.

참고

¹ChatGPT plugins - OpenAI

²MCP Apps compatibility in ChatGPT - OpenAI Developers

³MCP and Connectors - OpenAI API

⁴What is the Model Context Protocol (MCP)?

⁵OpenAI Adds Full MCP Support to ChatGPT Developer Mode

⁶ChatGPT 또는 Claude Microsoft Sentinel MCP 커넥터 사용(미리 보기)