오픈클로_MCP연동

오픈클로 MCP 연동 가이드 – Gmail, GitHub, Slack을 AI 에이전트에 연결하는 방법

by

오픈클로를 한동안 써보면 이런 순간이 온다. “이메일 정리해줘”라고 했더니 잘 해주고, “일정 확인해줘”라고 했더니 잘 알려준다. 그런데 어느 날 “GitHub에서 버그 이슈 확인해줘”라고 했더니 멈칫한다. “Notion에 오늘 회의록 정리해줘”라고 했더니 할 수 없다고 한다. 기본 스킬만으로는 닿지 않는 영역이 생기기 시작하는 거다.

여기서 두 가지 길이 갈린다. 하나는 커스텀 스킬을 직접 만들어서 API를 연동하는 방법이고, 다른 하나는 MCP(Model Context Protocol)를 쓰는 방법이다. 나는 처음에 커스텀 스킬로 GitHub API를 연동하려다가 인증 처리, 토큰 갱신, 에러 핸들링에 반나절을 썼다. 그러다 MCP를 발견하고 나서는 같은 작업을 15분 만에 끝냈다. 커뮤니티가 이미 만들어놓은 MCP 서버를 가져다 쓰면 되니까.

이 글에서는 MCP가 뭔지, 오픈클로에서 어떻게 작동하는지, 그리고 실제로 GitHub, Gmail, Slack, 데이터베이스 같은 외부 서비스를 연결하는 방법을 단계별로 다룬다. 오픈클로가 처음이라면 오픈클로 완벽 가이드를 먼저 읽고 오면 좋겠다.

MCP란 무엇인가 – AI 세계의 USB-C

MCP(Model Context Protocol)는 Anthropic이 2024년 말에 공개한 오픈 표준이다. AI 에이전트가 외부 도구나 데이터 소스에 접근할 때 사용하는 통일된 통신 규약이라고 보면 된다. 가장 많이 쓰이는 비유가 “AI의 USB-C”다. USB-C가 나오기 전에는 기기마다 충전 단자가 달랐듯이, MCP 이전에는 AI 도구마다 외부 서비스 연결 방식이 전부 달랐다. MCP는 이걸 하나의 표준으로 통일한다.

기술적으로 보면 MCP는 JSON-RPC 2.0 기반의 프로토콜이다. MCP 서버가 외부 서비스(GitHub, Gmail, 데이터베이스 등)와의 연결을 담당하고, AI 에이전트(MCP 호스트)가 이 서버를 통해 도구를 호출하는 구조다. 에이전트가 “GitHub에서 열린 이슈 목록 가져와”라고 판단하면, GitHub MCP 서버에 요청을 보내고, 서버가 GitHub API를 호출해서 결과를 돌려주는 식이다.

왜 이게 중요한가. MCP 이전에는 외부 서비스 하나를 연동하려면 커스텀 플러그인을 직접 만들어야 했다. API 인증, 데이터 포맷 변환, 에러 처리를 전부 각 서비스에 맞게 따로 구현해야 했다. N개의 AI 도구가 M개의 서비스를 지원하려면 N x M개의 커스텀 통합이 필요한, 이른바 “N x M 문제”가 있었다. MCP는 이걸 N + M으로 줄인다. AI 도구는 MCP만 지원하면 되고, 서비스 제공자는 MCP 서버만 만들면 되니까.

2025년 12월, MCP는 Linux Foundation 산하의 Agentic AI Foundation(AAIF)에 기증됐다. 공동 설립자가 Anthropic, Block, 그리고 OpenAI다. 경쟁 관계인 이 세 회사가 함께 표준을 만들고 있다는 건, MCP가 특정 기업의 전유물이 아니라 업계 공통 인프라로 자리잡았다는 의미다. 2026년 4월 기준으로 커뮤니티에서 만든 MCP 서버가 1,000개를 넘어섰고, Claude, ChatGPT, VS Code, Cursor 등 주요 AI 플랫폼이 모두 MCP를 지원한다.

오픈클로에서 MCP가 작동하는 구조

오픈클로는 MCP 호스트로 동작한다. 여러 MCP 서버를 동시에 연결해두고, 사용자의 요청에 따라 적절한 서버의 도구를 호출한다. “GitHub에서 이슈 확인해줘”라고 하면 GitHub MCP 서버를, “이메일 요약해줘”라고 하면 Gmail MCP 서버를 알아서 선택한다.

MCP 서버는 두 가지 방식으로 통신한다. stdio 방식은 로컬 프로세스로 실행되면서 표준 입출력으로 통신한다. 설정이 간단하고 별도의 네트워크 구성이 필요 없어서, 개인 사용자에게 가장 추천하는 방식이다. HTTP/SSE 방식은 웹 서비스로 실행되면서 네트워크를 통해 통신한다. 팀 환경이나 리모트 서버에서 MCP 서버를 공유할 때 적합하다.

오픈클로에서 MCP 서버를 관리하는 방법도 두 가지가 있다. 첫째는 openclaw.json 설정 파일에서 직접 mcpServers 블록을 편집하는 방법이고, 둘째는 mcporter라는 내장 스킬을 통해 자연어로 관리하는 방법이다. mcporter를 쓰면 “GitHub MCP 서버 추가해줘”라고 말하는 것만으로 설정이 완료된다. JSON을 직접 편집할 필요가 없어서 훨씬 편하다.

스킬과 MCP의 차이도 이해해둘 필요가 있다. 스킬은 에이전트에게 “어떻게 행동할지”를 알려주는 플레이북이고, MCP는 “어떤 도구에 접근할 수 있는지”를 제공하는 연결 레이어다. 비유하자면 스킬은 요리 레시피이고, MCP는 냉장고에 어떤 재료가 있는지 알려주는 인벤토리다. 둘은 상호 보완적이다. 실전에서는 파일 조작이나 웹 검색 같은 기본 기능은 스킬로 처리하고, API 기반의 외부 서비스 연결은 MCP로 처리하는 패턴이 가장 일반적이다.

MCP 도입 전과 후의 차이를 체감하려면 개발 워크플로우를 예로 들면 된다. MCP 없이는 GitHub의 이슈를 확인하려면 브라우저를 열고, 저장소에 가서, 필터를 설정하고, 내용을 읽고, 다시 에이전트에게 복사해서 전달해야 했다. MCP를 연결하면 “이번 주에 새로 열린 버그 이슈 알려줘”라고 말하는 것만으로 끝난다. 에이전트가 GitHub MCP 서버를 호출하고, 결과를 분석해서, 요약까지 해준다. 이 차이가 하루에 몇 번씩 반복되면 누적 시간 절약이 상당하다.

첫 번째 MCP 서버 연결해보기 – 파일시스템

가장 간단한 MCP 서버부터 시작해보자. 파일시스템 MCP 서버는 에이전트에게 로컬 파일에 대한 읽기/쓰기 권한을 부여한다. 오픈클로의 기본 파일 스킬과 겹치는 부분도 있지만, MCP 서버는 허용 경로를 명시적으로 제한할 수 있어서 보안 관리가 더 세밀하다.

설정 파일(~/.openclaw/openclaw.json 또는 mcp_config.json)에 다음 블록을 추가한다.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontext/server-filesystem", "/home/user/workspace"],
      "env": {}
    }
  }
}

여기서 args의 마지막 항목이 에이전트가 접근할 수 있는 디렉토리 경로다. 이 경로 밖의 파일에는 접근할 수 없으니, 민감한 디렉토리(~/.ssh, ~/.config 등)가 포함되지 않도록 주의해야 한다.

설정을 저장하고 게이트웨이를 재시작하면, 에이전트가 자동으로 MCP 서버를 인식한다. 테스트로 “workspace 디렉토리에 어떤 파일이 있어?”라고 물어보면, 파일시스템 MCP 서버를 통해 디렉토리 목록을 가져와서 답해준다.

mcporter를 쓰면 이 과정이 더 간단하다. 에이전트에게 직접 말하면 된다.

"파일시스템 MCP 서버 추가해줘. 경로는 /home/user/workspace로 설정해줘."

mcporter가 알아서 설정 파일을 업데이트하고 서버를 등록한다.

GitHub 연동 – 이슈, PR, 코드 리뷰를 대화로 관리

개발자에게 가장 실용적인 MCP 연동이 GitHub이다. GitHub MCP 서버를 연결하면 에이전트가 이슈 목록을 조회하고, PR을 확인하고, 코드 변경사항을 요약하고, 이슈에 댓글을 달 수 있다.

먼저 GitHub Personal Access Token이 필요하다. github.com의 Settings → Developer settings → Personal access tokens에서 생성한다. repo, issues, pull_requests 스코프를 포함시킨다. 그 다음 MCP 설정을 추가한다.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontext/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_여기에토큰을넣는다"
      }
    }
  }
}

보안상 토큰을 설정 파일에 직접 넣는 것보다는 환경변수로 관리하는 게 좋다. 환경변수에 미리 설정해두면 env 블록에서 참조만 하면 된다.

연결이 완료되면 이런 대화가 가능해진다. “openclaw 저장소에서 bug 태그가 붙은 열린 이슈 목록 알려줘.” 에이전트가 GitHub MCP 서버를 호출해서 이슈 목록을 가져오고 요약해준다. 실제로 테스트해보면 약 4초 정도 걸린다. 브라우저를 열어서 GitHub에 접속하고, 이슈 탭으로 이동하고, 필터를 설정하는 것보다 훨씬 빠르다.

크론잡과 결합하면 더 강력해진다. 매일 아침 “새로 생긴 이슈와 머지된 PR을 요약해서 슬랙으로 보내줘”를 자동으로 실행시킬 수 있다. 이건 개발팀 데일리 스탠드업의 절반을 자동화하는 셈이다.

Gmail, Slack, 데이터베이스까지 확장하기

같은 패턴으로 다른 서비스도 연결할 수 있다. mcpServers 블록에 서버를 추가하면, 오픈클로가 여러 MCP 서버를 동시에 관리하면서 요청에 따라 적절한 서버를 자동 선택한다.

데이터베이스 연동도 MCP로 가능하다. PostgreSQL, MySQL, SQLite 모두 MCP 서버가 있다. 연결하면 에이전트에게 “이번 달 가입한 활성 사용자 수 알려줘”라고 자연어로 질의할 수 있다. 에이전트가 SQL 쿼리를 생성하고 실행해서 결과를 돌려준다.

데이터베이스를 연결할 때 반드시 지켜야 할 원칙이 있다. 읽기 전용 사용자로 연결하는 거다. 에이전트가 실수로 DELETE나 DROP을 실행하면 복구할 수 없다. 프로덕션 데이터베이스에 직접 연결하는 건 당연히 피해야 하고, 리플리카나 별도의 분석용 DB에 연결하는 게 안전하다.

웹 크롤링용 MCP 서버도 있다. fetch 서버를 연결하면 에이전트가 URL을 가져와서 마크다운으로 변환해준다. 리서치 작업, 경쟁사 페이지 확인, 문서 내용 검증 같은 작업에서 가장 자주 쓰인다. 별도의 인증이 필요 없어서 설정이 가장 간단한 MCP 서버이기도 하다. 내부적으로 헤드리스 브라우저를 사용하기 때문에, 자바스크립트로 렌더링되는 페이지도 처리할 수 있다.

한 개발자의 실전 사례가 재미있었다. 다섯 개의 MCP 서버(파일시스템, GitHub, 데이터베이스, 웹 크롤링, 슬랙)를 동시에 연결해놓고 운영하고 있는데, 각 서버는 별도의 프로세스로 돌아간다. 오픈클로가 요청을 분석해서 적절한 서버로 라우팅하는 걸 자동으로 처리하니까, 사용자 입장에서는 그냥 자연어로 말하면 된다.

기업 환경에서 MCP가 특히 강력한 지점은 기존 내부 시스템과의 연결이다. 대부분의 기업은 사내 전용 API나 레거시 시스템을 운영하고 있는데, MCP 서버를 직접 만들면 이런 시스템도 에이전트에 연결할 수 있다. MCP SDK가 TypeScript와 Python 모두 지원하고, JSON-RPC 2.0을 지원하는 언어라면 어떤 것으로든 서버를 만들 수 있다. 사내 ERP 시스템의 재고 조회 API를 MCP 서버로 감싸면, 에이전트에게 “A 제품 현재 재고량 알려줘”라고 물어보는 것만으로 ERP에서 데이터를 가져올 수 있다. 커스텀 MCP 서버를 만드는 건 일반 REST API 서버를 만드는 것보다 간단하다. MCP SDK가 프로토콜 핸들링을 전부 처리해주니까, 개발자는 비즈니스 로직만 작성하면 된다.

스킬과 MCP를 조합하는 실전 패턴

MCP만으로 모든 걸 해결할 수 있는 건 아니다. 스킬과 MCP를 조합했을 때 가장 강력한 워크플로우가 만들어진다.

내가 실제로 쓰고 있는 패턴 하나를 소개한다. 매일 아침 실행되는 “개발 브리핑” 크론잡이다. GitHub MCP 서버로 어젯밤 머지된 PR과 새로 열린 이슈를 가져오고, 데이터베이스 MCP 서버로 주요 지표(가입자 수, 에러율)를 조회하고, 웹 크롤링 MCP 서버로 경쟁사 변경 사항을 확인한다. 그 다음 스킬이 이 모든 정보를 종합해서 브리핑 형식으로 정리하고, 텔레그램으로 보내준다. MCP가 “데이터 수집”을 담당하고, 스킬이 “데이터 가공과 전달”을 담당하는 구조다.

또 다른 패턴은 “고객 문의 자동 리서치”다. 고객 지원 메일이 도착하면 에이전트가 메일 내용을 분석하고, 관련 GitHub 이슈가 있는지 MCP로 검색하고, 내부 문서를 파일시스템 MCP로 찾아보고, 이 정보를 종합해서 답변 초안을 작성한다. 사람은 초안을 확인하고 보내기만 하면 된다.

MCP 서버 간의 복잡한 인증 문제가 실전에서 가장 골치 아픈 부분이다. 커뮤니티 MCP 서버가 OAuth 토큰 갱신을 제대로 처리하지 못하는 경우가 있다. 이런 상황에서는 n8n 같은 워크플로우 도구를 중간 레이어로 두고, n8n이 인증을 처리한 뒤 MCP가 n8n의 웹훅을 호출하는 우회 방식이 커뮤니티에서 많이 쓰인다. 복잡해 보이지만, 한 번 세팅해놓으면 인증 문제 없이 안정적으로 돌아간다.

보안 – MCP를 쓸 때 반드시 지켜야 할 것

MCP는 에이전트에게 외부 서비스 접근 권한을 부여하는 거다. 그만큼 보안이 중요하다. 기본 원칙 네 가지를 정리한다.

첫째, API 키와 토큰은 절대 설정 파일에 직접 넣지 않는다. 환경변수나 시크릿 매니저를 사용한다. 설정 파일이 실수로 깃에 커밋되거나 백업에 포함되면 키가 노출된다.

둘째, 최소 권한 원칙을 적용한다. GitHub 토큰은 필요한 스코프만 포함시키고, 데이터베이스는 읽기 전용 사용자로 연결하고, 파일시스템은 필요한 디렉토리만 허용한다.

셋째, 민감한 MCP 서버는 별도 컨테이너에서 격리한다. 프로덕션 시스템에 접근하는 MCP 서버는 네트워크 세그먼트를 분리해서 운영하는 게 안전하다.

넷째, 로그를 모니터링한다. 에이전트가 MCP 서버를 통해 어떤 도구를 호출했는지, 어떤 데이터에 접근했는지 감사 로그를 확인하는 습관이 필요하다. 예상치 못한 도구 호출이나 비정상적인 데이터 패턴이 보이면 프롬프트 인젝션 가능성을 의심해봐야 한다. 보안에 대해 더 자세히 알고 싶다면 오픈클로 보안 취약점 총정리 글을 참고하자.

마무리

MCP는 오픈클로를 “똑똑한 대화 상대”에서 “실제로 일하는 시스템”으로 전환시키는 핵심 레이어다. 기본 스킬만으로는 닿지 않던 GitHub, Gmail, Slack, 데이터베이스 같은 외부 서비스가 MCP를 통해 에이전트의 손이 닿는 영역이 된다. 1,000개 이상의 커뮤니티 MCP 서버가 이미 만들어져 있으니, 대부분의 서비스 연동은 설정 몇 줄로 해결된다.

핵심을 정리하면 이렇다. MCP는 AI 에이전트와 외부 도구를 연결하는 표준 프로토콜이고, USB-C처럼 “한 번 만들면 어디서든 쓸 수 있는” 구조다. 오픈클로에서는 openclaw.json의 mcpServers 블록에 서버를 추가하는 것만으로 연결이 완료된다. 개인 사용자는 stdio 방식이 가장 간단하고, 팀 환경에서는 HTTP/SSE 방식을 쓴다. 스킬이 “행동 방법”을 정의하고 MCP가 “접근 가능한 도구”를 제공하는 상호 보완 구조다. Linux Foundation 산하의 오픈 거버넌스로 운영되고 있어서, 특정 기업에 종속될 걱정 없이 안심하고 도입할 수 있다. MCP를 연결하는 순간, 오픈클로는 더 이상 혼자 일하는 비서가 아니라, 모든 디지털 도구를 손에 쥔 팀 리더가 된다.

Leave a Comment