MCP(Model Context Protocol)란 AI 모델이 메일 서버 같은 외부 시스템의 데이터와 도구에 접근할 수 있도록 연결하는 개방형 규약입니다. 메일 시스템에 MCP를 붙이면 AI 비서가 로그인한 사용자의 자격으로 그 사람의 사서함을 읽고 요약해 주지만, 읽는 범위는 그 사람의 사서함과 그 사람의 권한까지입니다. 퇴사한 직원의 메일, 다른 팀의 거래 이력, 부서 전체의 흐름처럼 회사가 정말 묻고 싶은 질문은 개인 권한 밖에 있고, 그 질문에 답하려면 회사가 보관한 메일 전체를 회사가 정한 권한대로 읽는 구조가 따로 필요합니다.
핵심 요약
- MCP로 연결된 AI는 로그인한 사용자의 자격으로 메일 서버에 접근하므로 내가 볼 수 있는 메일만 읽습니다.
- 퇴사자의 사서함, 3년 전 영업팀이 합의한 조건, 회사 전체의 도메인 교신 여부, 구매팀 전체의 계좌 변경 요청 건수는 개인 권한으로는 답할 수 없습니다.
- 메일 아카이브 기반 방식은 회사 자산으로 보관된 메일 전체를 대상으로 하고, 누가 어디까지 보는지는 회사가 정한 역할·부서 권한이 결정합니다.
- 모든 질문과 답에 근거 메일이 함께 따라와 AI의 답을 그대로 믿지 않고 원문을 확인할 수 있습니다.
- 둘은 경쟁 관계가 아니라 개인 생산성과 조직의 기록·감사·보안이라는 다른 용도를 맡습니다.
MCP로 연결한 AI는 어디까지 읽나
로그인한 사용자의 사서함, 그 사람의 권한까지 읽습니다. 요즘 메일 시스템에 MCP를 붙여 AI 비서가 내 메일을 읽고 요약하게 하는 사례가 늘고 있습니다. "오늘 온 메일 중 답장이 필요한 것만 추려 줘", "지난주 그 거래처와 주고받은 내용을 정리해 줘" 같은 요청이 바로 됩니다. 좋은 방식이고, 저희도 씁니다.
다만 MCP로 연결된 AI는 로그인한 사용자의 자격으로 메일 서버에 접근합니다. 내가 볼 수 있는 메일을 대신 읽어 주는 것이지, 회사의 메일을 읽는 것이 아닙니다. 그래서 다음과 같은 질문에는 답할 수 없습니다.
- 퇴사한 홍길동 사원이 A고객사에 가격 제안을 얼마에 했지? — 그 사서함은 내 것이 아닙니다. 대개는 계정이 비활성화돼 아무도 열어 보지 못합니다.
- 3년 전 영업팀이 A사와 합의한 조건이 뭐였지? — 담당자가 바뀌었고, 그때의 메일은 당시 담당자의 PC나 PST 파일 어딘가에 있습니다.
- 우리 회사와 이 도메인이 교신한 적이 있나? — 내 사서함에 없다고 회사에 없는 것은 아닙니다.
- 이번 달 구매팀 전체에 들어온 계좌 변경 요청이 몇 건이지? — 부서 단위의 질문은 개인 권한으로는 세어 볼 수 없습니다.
개인 생산성 도구로는 충분하지만, 회사가 메일에서 얻고 싶은 조직 차원의 인사이트에는 닿지 않습니다.
회사의 메일을 권한대로 읽는다는 것은 무엇인가
개인 사서함이 아니라 회사 자산으로 보관된 메일 전체를 대상으로 하고, 누가 어디까지 볼 수 있는지를 회사가 정한 권한이 결정하는 방식입니다. 메일 아카이브란 회사가 주고받은 메일을 개인 계정과 별개로 회사 자산으로 보관하는 저장소이며, 이 방식은 그 아카이브 위에서 동작합니다. 출발점이 다릅니다.
- 퇴사자 메일 — 계정이 사라져도 보관된 메일은 남습니다. 후임자나 관리자가 권한 범위 안에서 "그 담당자가 그 고객과 무엇을 약속했는지"를 찾을 수 있습니다.
- 팀·부서 단위 검색 — 팀장은 팀의, 부서장은 부서의 메일을 한 번에 검색합니다. 거래처별·담당자별·일자별로 정리된 답을 받습니다.
- 감사·관리자 관점 — 외부로 나간 개인정보 포함 메일, 특정 기간의 컴플레인 메일처럼 조직 전체를 가로지르는 질문에 답합니다.
- 관계 기반 피싱 분석 — 회사 전체의 교신 이력이 있어야 "처음 보는 도메인", "같은 이름, 다른 주소"를 가려낼 수 있습니다. 개인 사서함 하나로는 불가능하며, 그 원리는 메일 게이트웨이가 BEC 메일을 놓치는 이유 글에서 설명했습니다.
권한은 느슨해지지 않습니다. 사원은 자기 메일을, 팀장은 팀의 메일을, 감사자는 정해진 범위를 봅니다. 모든 질문과 답에는 근거 메일이 함께 따라오므로 AI의 답을 그대로 믿지 않고 원문을 확인할 수 있습니다. 이는 회사 데이터와 RAG 글에서 정리한 권한과 출처 원칙 그대로입니다.
두 방식은 무엇이 다른가
둘은 경쟁 관계가 아니라 읽는 범위와 권한 기준, 적합한 용도가 다른 방식입니다.
| 구분 | 메일 시스템 + MCP | MailInsight |
|---|---|---|
| 읽는 범위 | 로그인한 사람의 사서함 | 회사가 보관한 메일 전체 |
| 권한 기준 | 개인 계정의 권한 | 회사가 정한 역할·부서 권한 |
| 퇴사자 메일 | 접근 불가(계정 비활성화) | 보관 상태 그대로 검색 |
| 팀·부서 단위 질문 | 불가 | 가능 |
| 피싱·사칭 판단 | 메일 한 통 기준 | 회사 전체 교신 이력과 비교 |
| 적합한 용도 | 개인 생산성 | 조직의 기록·감사·보안 |
개인이 자기 메일을 더 빨리 처리하는 데는 MCP 연결이 좋습니다. 회사가 메일을 조직의 기억으로 쓰려면, 보관된 전체 메일을 권한에 따라 읽을 수 있는 구조가 필요합니다. 저희 MailInsight는 그 두 번째 자리를 위해 만들었습니다.
자주 묻는 질문
Q. MCP로 AI를 메일에 연결하면 퇴사한 직원의 메일도 볼 수 있나요?
볼 수 없습니다. MCP로 연결된 AI는 로그인한 사용자의 자격으로 메일 서버에 접근하므로 그 사람의 사서함만 읽습니다. 퇴사자의 계정은 대개 비활성화돼 아무도 열어 보지 못하며, 보관된 메일을 권한 범위 안에서 찾으려면 회사 자산으로 메일을 보관하는 아카이브 기반 구조가 필요합니다.
Q. 회사 메일 전체를 AI가 읽으면 권한이 느슨해지지 않나요?
느슨해지지 않습니다. 사원은 자기 메일을, 팀장은 팀의 메일을, 감사자는 정해진 범위만 봅니다. 대상이 회사가 보관한 메일 전체라는 뜻이지 누구나 전체를 본다는 뜻이 아니며, 누가 어디까지 보는지는 회사가 정한 역할·부서 권한이 결정합니다. 모든 답에는 근거 메일이 함께 따라옵니다.
Q. MCP 연결과 메일 아카이브 기반 AI 중 무엇을 선택해야 하나요?
용도가 다르므로 하나를 고르는 문제가 아닙니다. 개인이 자기 메일을 더 빨리 처리하려면 MCP 연결이 좋고, 퇴사자 메일 조회나 팀·부서 단위 검색, 감사, 회사 전체 교신 이력과 비교하는 피싱 분석처럼 조직 차원의 질문에 답하려면 메일 아카이브 기반 구조가 필요합니다. 두 가지를 함께 쓸 수 있습니다.
