AI/AI 관련 팁

n8n MCP로 Codex 연동하는 방법과 구글 캘린더·이메일 자동화 가이드

AIThinkLab 2026. 3. 19. 10:11
SMALL

🤖 n8n과 AI 코딩 에이전트를 함께 쓰려는 수요가 빠르게 늘고 있습니다. 특히 2025~2026년 들어 MCP(Model Context Protocol)가 사실상 표준 연결 방식으로 자리 잡으면서, n8n을 자동화 허브로 두고 Codex 같은 코딩 에이전트가 외부 도구를 더 안전하게 호출하는 구성이 실무에서 자주 언급됩니다.

 

이번 글에서는 n8n MCP가 무엇인지, Codex와 어떤 식으로 연결하는지, 그리고 n8n으로 구글 캘린더와 Gmail을 엮어 일정·메일을 자동 관리하는 흐름까지 한 번에 정리합니다. 문서 기준으로 확인 가능한 내용은 명확히 구분하고, 환경에 따라 달라질 수 있는 부분은 과장 없이 따로 짚어보겠습니다.

 

📌 n8n MCP란 무엇인가요?

먼저 MCP(Model Context Protocol)는 AI 애플리케이션이 외부 도구·데이터·워크플로를 공통 방식으로 연결하기 위한 개방형 표준입니다. modelcontextprotocol.io 소개 문서와 OpenAI Codex 문서를 보면, MCP는 로컬 프로세스 기반 STDIO 서버와 주소 기반 Streamable HTTP 서버를 통해 도구를 노출하고 호출하는 방식으로 설명됩니다.

 

n8n 쪽에서는 MCP를 두 방향으로 사용할 수 있습니다.

  • n8n이 MCP 서버가 되는 방식: n8n의 Instance-level MCP access 또는 MCP Server Trigger를 통해, 외부 AI 클라이언트가 n8n 워크플로를 도구처럼 검색·호출할 수 있습니다.
  • n8n이 MCP 클라이언트가 되는 방식: n8n의 MCP Client node 또는 MCP Client Tool node를 통해, 외부 MCP 서버가 노출한 도구를 n8n 워크플로 안에서 사용합니다.

 

즉, n8n은 자동화 허브이고, MCP는 AI 에이전트와 자동화 허브 사이의 표준 연결 규칙이라고 이해하면 가장 실무적으로 맞습니다.

 

🧠 Codex와 연동할 때 알아둘 개념

OpenAI Codex 문서 기준으로 Codex는 CLI와 IDE 확장 모두에서 MCP 서버를 지원합니다. 설정은 보통 ~/.codex/config.toml 또는 프로젝트별 .codex/config.toml에 저장되며, codex mcp add 명령으로 MCP 서버를 등록할 수 있습니다.

 

여기서 중요한 점은 “Codex와 n8n을 연동한다”는 말이 실제로는 아래 둘 중 하나라는 점입니다.

  • 방향 A: Codex가 n8n을 호출 → n8n이 MCP 서버 역할을 하며, Codex가 n8n 워크플로를 도구처럼 사용
  • 방향 B: n8n이 외부 MCP 도구를 호출 → n8n 워크플로 안의 AI Agent가 MCP Client Tool로 외부 도구를 사용

 

실무에서는 방향 A가 더 직관적입니다. 예를 들어 Codex가 “내일 일정 요약을 보내고 미팅 가능 시간도 계산해 달라”는 요청을 받으면, Codex가 직접 구글 API를 모두 다루는 대신 n8n 워크플로를 호출해 캘린더 조회, 이메일 생성, 로깅, 승인 절차를 한 번에 처리할 수 있습니다.

 

🔗 n8n MCP로 Codex를 연결하는 실제 흐름

가장 이해하기 쉬운 흐름은 다음과 같습니다.

  1. n8n에서 일정 조회 또는 메일 발송용 워크플로를 만듭니다.
  2. 해당 워크플로를 게시(publish)하고, MCP에 노출 가능한 상태로 설정합니다.
  3. n8n의 Instance-level MCP access 또는 MCP Server Trigger로 MCP 엔드포인트를 준비합니다.
  4. Codex CLI/IDE에서 해당 MCP 서버 URL을 등록합니다.
  5. Codex가 도구 목록을 읽고, 필요한 워크플로를 선택 호출합니다.

 

n8n 공식 문서 기준으로 Instance-level MCP access는 설정에서 전체 인스턴스 단위로 MCP를 켜고, 워크플로마다 개별적으로 MCP 공개를 허용하는 구조입니다. 또한 n8n은 기본적으로 모든 워크플로를 자동 공개하지 않으며, 게시된 워크플로 중 지원 트리거를 가진 것만 노출 대상으로 판단합니다.

 

지원 트리거는 문서 기준으로 Webhook, Schedule, Chat, Form입니다. 즉, 단순 초안 상태이거나 게시되지 않은 워크플로는 Codex 쪽에서 바로 보이지 않을 수 있습니다.

 

예시 시나리오를 보면 구조가 더 명확합니다.

  • Codex 프롬프트: “다음 주 화요일 오후 미팅 가능한 시간을 찾고, 후보 3개를 이메일 초안으로 만들어 줘.”
  • Codex 동작: n8n MCP 서버에 연결된 meeting_scheduler 워크플로 호출
  • n8n 내부 처리: Google Calendar Availability 조회 → 빈 시간대 정리 → Gmail Draft 생성 → 결과 반환
  • Codex 응답: 사용 가능한 시간 3개와 초안 메일 내용을 정리해 제시

 

이 구조의 장점은 업무 로직은 n8n에, 대화형 추론과 요청 해석은 Codex에 두는 분리가 가능하다는 점입니다.

 

⚙️ 연결 시 필요한 설정 포인트

OpenAI Codex 문서에 따르면 Codex는 MCP 서버를 다음 방식으로 등록할 수 있습니다.

  • STDIO 서버: 로컬 명령으로 실행되는 MCP 서버
  • Streamable HTTP 서버: URL로 접속하는 원격 MCP 서버
  • 인증 방식: Bearer Token, OAuth, 정적 헤더 등

 

n8n 공식 문서 기준으로 Instance-level MCP access는 OAuth2와 Access Token 방식을 지원합니다. Access Token은 사용자 계정에 묶여 생성되며, 재생성 시 이전 토큰이 폐기됩니다. 운영 환경에서는 토큰을 하드코딩하지 말고 환경 변수나 비밀 저장소로 분리하는 편이 안전합니다.

 

Codex 쪽 설정은 보통 아래와 같은 형태로 이해하면 됩니다. 실제 키 이름이나 URL은 환경에 따라 달라질 수 있지만, 구조 자체는 비슷합니다.

[mcp_servers.n8n]
url = "https://example-n8n.yourdomain.com/mcp"
bearer_token_env_var = "N8N_MCP_TOKEN"
startup_timeout_sec = 20
tool_timeout_sec = 60
enabled = true

 

또는 로컬 실험 환경이라면 codex mcp add 명령으로 서버를 등록한 뒤, Codex가 도구 목록을 인식하는지 먼저 확인하는 방식이 편합니다. 이때 가장 중요한 검증 포인트는 “도구가 등록되었는가”보다 원하는 워크플로 설명과 입력값이 Codex에서 충분히 읽히는가입니다. 설명이 짧거나 추상적이면 연결은 성공해도 실제 호출 품질이 낮게 나올 수 있습니다.

 

MCP Server Trigger를 직접 쓸 때는 Bearer auth 또는 Header auth를 걸 수 있습니다. 또 n8n 문서에는 리버스 프록시 환경에서 SSE 또는 streamable HTTP 설정이 올바르지 않으면 연결이 자주 끊길 수 있다고 적혀 있습니다. 특히 queue mode에서 웹훅 복제본이 여러 개인 경우에는 /mcp* 요청을 한 인스턴스로 고정 라우팅해야 합니다.

 

🚨 보안 이슈와 실패 포인트

이 구간은 실제 운영에서 가장 중요합니다.

  • 과도한 도구 노출: 필요한 워크플로만 MCP에 공개해야 합니다. 인스턴스 단위 MCP를 켜더라도 개별 워크플로 공개 범위를 좁히는 것이 안전합니다.
  • 권한 분리 부족: Gmail 발송, 캘린더 생성, DB 쓰기처럼 파급력이 큰 워크플로는 읽기 전용 흐름과 분리하는 것이 좋습니다.
  • 토큰 관리 미흡: Access Token이나 Bearer 토큰을 프롬프트나 코드 저장소에 그대로 남기면 사고로 이어질 수 있습니다.
  • SSE/프록시 문제: 프록시 버퍼링, 압축, 다중 리플리카 구성이 잘못되면 MCP 호출이 불안정해질 수 있습니다.
  • 도구 설명 부족: 워크플로 설명과 입력 스키마가 모호하면 Codex가 잘못된 도구를 고르거나 인자를 엉뚱하게 채울 수 있습니다.

 

추가로 n8n의 AI 도구 기능에서 쓰이는 $fromAI() 같은 자동 파라미터 채우기는 매우 편리하지만, 항상 사람이 승인해야 하는 작업까지 무조건 자동화하는 용도로 확대 해석하면 위험합니다. 일정 생성, 외부 발송, 삭제 작업은 조건문과 승인 단계를 두는 편이 안전합니다.

 

📅 n8n으로 구글 캘린더와 이메일을 함께 관리하는 방법

n8n 공식 문서 기준으로 Google Calendar 노드는 일정 생성·조회·수정·삭제와 Availability 조회를 지원합니다. Gmail 노드는 메시지 조회, 답장, 전송, 라벨 추가/제거, 읽음 처리 등을 지원합니다. 또한 Gmail Trigger는 새 메일 수신을 주기적으로 감지하고, Google Calendar Trigger는 이벤트 생성·수정·시작·종료·취소를 감지할 수 있습니다.

 

이 조합으로 만들 수 있는 대표 자동화는 다음과 같습니다.

  • 새 미팅 요청 메일이 오면 → 캘린더 빈 시간 조회 → 회신 초안 작성
  • 캘린더에 일정이 생성되면 → 관련 참석자에게 확인 메일 발송
  • 특정 라벨 메일이 오면 → 담당 캘린더에 후속 일정 생성
  • 일정 시작 1시간 전 → 요약 메일 또는 내부 알림 전송

 

사전 준비도 중요합니다. n8n 공식 문서의 Google OAuth 설정 가이드를 기준으로 보면, 최소한 아래 순서가 선행되어야 합니다.

  1. Google Cloud 프로젝트 생성
  2. Gmail API와 Google Calendar API 활성화
  3. OAuth 동의 화면 구성
  4. OAuth 클라이언트 생성
  5. n8n에서 해당 자격 증명 연결

 

특히 Gmail은 서비스 계정보다 OAuth2 사용이 더 일반적이고, n8n 문서도 Gmail 노드에는 OAuth2 사용을 권장합니다. 조직용 Google Workspace 환경에서는 내부/외부 사용자 범위, 승인 상태, 테스트 사용자 제한 때문에 로그인은 되는데 실제 실행이 막히는 경우가 있으므로 이 지점도 먼저 확인하는 편이 좋습니다.

 

🛠️ 실무형 예시 워크플로 1: 미팅 요청 메일을 일정 후보 메일로 전환

가장 많이 쓰이는 흐름은 아래와 같습니다.

  1. Gmail Trigger로 새 메일 수신 감지
  2. IF 또는 필터 조건으로 “meeting”, “interview”, “schedule” 같은 키워드 분기
  3. AI 또는 텍스트 파싱 단계로 요청 날짜·선호 시간·참석자 정보 추출
  4. Google Calendar Availability로 가능한 슬롯 조회
  5. Code / Set / Function 단계에서 후보 시간 2~3개 정리
  6. Gmail Draft 또는 Send로 회신 메일 초안 생성 또는 발송

 

이때 핵심은 캘린더에 바로 일정을 생성하는 것이 아니라, 먼저 Availability 조회를 통해 충돌을 검사하는 것입니다. n8n 문서에도 Google Calendar의 Availability 작업이 별도로 제공됩니다. 일정 충돌 검사를 생략하면 이중 예약이 쉽게 발생합니다.

 

📨 실무형 예시 워크플로 2: 캘린더 일정 생성 시 안내 메일 자동 발송

두 번째로 단순하지만 유용한 흐름은 다음과 같습니다.

  1. Google Calendar Trigger로 Event Created 또는 Event Updated 감지
  2. Set 노드에서 일정 제목, 시작 시각, 참석자, 회의 링크 정리
  3. Gmail Send로 참석자에게 안내 메일 발송
  4. 선택 사항으로 Notion, Slack, CRM까지 후속 기록

 

운영 관점에서는 이 흐름에 다음 조건을 같이 넣는 것이 좋습니다.

  • 개인 일정은 제외
  • 특정 캘린더 또는 특정 참석자 도메인만 처리
  • 중복 발송 방지를 위한 라벨링 또는 상태 저장
  • 실패 시 재시도와 관리자 알림 추가

 

✅ 마무리 정리

정리하면, n8n MCP는 자동화 워크플로를 AI 에이전트가 표준 방식으로 호출할 수 있게 해주는 연결 레이어이고, Codex는 이 레이어를 통해 n8n을 도구처럼 활용할 수 있습니다. 여기에 Google Calendar와 Gmail을 붙이면 단순 챗봇이 아니라, 실제 업무 흐름을 읽고 일정과 커뮤니케이션을 함께 처리하는 운영형 자동화가 가능합니다.

 

다만 운영 환경에서는 인증 방식, 토큰 보관, 프록시 설정, 공개 워크플로 범위, 승인 절차를 반드시 함께 설계해야 합니다. 특히 n8n과 Codex의 세부 UI, 노드 이름, 인증 화면은 버전과 배포 환경에 따라 달라질 수 있으므로, 공식 문서 기준을 먼저 확인한 뒤 실제 환경에 맞게 적용하는 접근이 가장 안전합니다.

 

📚 참고한 최신 문서

LIST