MCP 개편, 에이전트 표준이 바뀌나? Dify에서 양방향 MCP 활용 가이드

혹시 해외여행 갈 때 나라마다 콘센트 모양이 달라서 어댑터 챙기느라 고생해 본 적 있으세요? AI 에이전트 세계에도 그 어댑터 역할을 하는 표준이 있는데, 바로 Anthropic이 만든 MCP(Model Context Protocol)예요. 에이전트가 노션이든 슬랙이든 사내 DB든, 규격 하나로 꽂아 쓰게 해주는 일종의 ‘멀티탭’이죠. 그런데 지난 7월 28일, 이 표준이 출시 이후 가장 큰 개편을 맞았습니다. 에이전트를 만들거나 운영하는 분이라면 이번 변화를 예상했을거예요.

MCP가 그렇게 대단한걸까?

MCP는 AI 모델이 외부 데이터와 도구에 접근하는 방식을 표준화한 개방형 프로토콜이인데요. 이게 나오기 전에는 에이전트에 도구 하나를 붙일 때마다 커스텀 연동 코드를 짜야 했는데, 서비스가 열 개면 연동 코드도 열 벌이 필요한 구조였으니 유지보수가 지옥일 수밖에 없었죠. MCP는 그 열 벌의 코드를 하나의 규격으로 통일했고, 그 덕에 생태계가 폭발적으로 컸어요. 공식 발표에 따르면 지금 주요 SDK 다운로드가 매달 5억 건에 육박하고, TypeScript와 Python SDK는 누적 10억 다운로드를 넘겼다고 하니, 사실상 에이전트 시대의 USB 규격이 된 셈입니다.

이번 개편, 뭐가 어떻게 바뀌었을까?

핵심은 '스테이트리스(stateless) 전환'이에요. 지금까지의 MCP 서버는 손님 한 명 한 명의 자리를 기억해야 하는 맛집 같았어요. 클라이언트가 접속하면 세션을 만들고, 이후 모든 요청이 그 세션에 묶이는 구조라, 서버를 늘리려면 손님을 같은 창구로만 보내는 복잡한 장치(스티키 세션이나 공유 세션 저장소 같은 것들)가 필요했거든요. 새 스펙은 이 세션 자체를 걷어냈습니다. 모든 요청이 자기 안에 필요한 정보를 다 담고 있어서, 어느 창구에서든 처리되는 프랜차이즈 방식이 된 거죠. The Register의 분석처럼 지난 2년간 프로덕션에서 얻은 교훈을 반영한 결과인데, 평범한 로드밸런서 뒤에서도 서버를 수평으로 늘릴 수 있게 됐다는 건 엔터프라이즈 도입의 마지막 걸림돌 하나가 치워졌다는 뜻이기도 해요.

물론 무료일리는 없죠. 하위 호환이 깨지는 변경이 섞여 있고, Roots·Sampling·Logging 같은 일부 기능과 기존 전송 방식은 폐기 예정으로 지정됐어요. 최소 12개월간 동작이 보장되긴 하지만, 새로 만드는 서버라면 처음부터 새 방식을 따르라는 단서가 붙었습니다. 지금 MCP 서버를 직접 운영하고 있다면, 올해 안에 마이그레이션 계획표를 그려두는 게 마음 편할 거예요.

실사용 가이드, Dify에서 MCP 양방향으로 쓰기

표준이 요동칠 때 제일 손해 보는 쪽은 프로토콜을 밑바닥부터 직접 구현한 팀이에요. 스펙이 바뀔 때마다 코드를 갈아엎어야 하니까요. 반대로 플랫폼에 표준 대응을 맡겨두면 이사 비용이 훨씬 쌉니다. Dify가 좋은 예인데, 양방향 MCP를 플랫폼에 내장하고 있어서 '가져다 쓰기'와 '내보내기' 두 방향 모두 화면 몇 개만 거치면 끝나요. 지금부터 Dify 공식 문서를 기준으로 순서대로 따라가 볼게요. 시작 전에 하나만 짚어두면, 현재 Dify의 MCP 연결은 HTTP 전송 방식 서버만 지원하고, 셀프호스팅으로 쓰고 계시다면 이 기능이 처음 들어간 v1.6.0 이상이어야 합니다.

따라 해보기 ———————>

외부 MCP 서버를 Dify의 도구로 가져오기

1단계 : 워크스페이스에서 도구(Tools) → MCP 탭으로 이동하세요
여기가 우리 워크스페이스에 연결된 MCP 서버들이 모여 있는 서랍이에요. 처음이라면 비어 있을 텐데, 화면의 Add MCP Server (HTTP) 버튼을 누르면 등록이 시작됩니다.

2단계 : 서버 정보 세 가지를 입력하세요
입력창은 단출해요. 연결하려는 MCP 서버의 주소(Server URL), 목록에서 알아보기 쉬운 이름과 아이콘(아이콘은 Dify가 알아서 가져오려고 시도해요), 그리고 서버 ID입니다. 이 중에 조심할 건 서버 ID 하나뿐인데, 소문자·숫자·언더스코어·하이픈 조합으로 24자 이내라는 형식 규칙보다 중요한 게 있어요. 한번 쓰기 시작한 ID는 절대 바꾸지 마세요. 앱들이 이 ID로 도구를 찾아가기 때문에, ID를 바꾸는 순간 그 서버의 도구를 쓰던 앱이 전부 깨집니다. 공식 문서도 github-prod, crm-system처럼 처음부터 영구적으로 쓸 수 있는 설명적인 이름을 권하고 있어요.

3단계 : 나머지는 Dify가 알아서 합니다
저장하면 Dify가 서버에 접속하고, OAuth 인증이 필요한 서버라면 그 절차까지 처리한 다음, 서버가 제공하는 도구 목록을 통째로 받아와요. 연결이 끝나면 도구 개수가 표시된 서버 카드가 생기는데, 이 카드가 곧 관리 창구입니다. 카드를 눌러서 외부 서비스에 새 도구가 추가됐을 때 목록을 갱신(Update Tools)하거나, 토큰이 만료됐을 때 재인증(Re-authorize)하거나, 설정을 수정할 수 있어요. 연결이 "Unconfigured Server"로 뜬다면 URL을 확인하고 재인증부터 해보시고, 도구가 안 보이면 Update Tools를 눌러보세요. 대부분 이 둘로 해결됩니다.

4단계 : 이제 앱 어디서든 꺼내 쓰면 됩니다
연결된 도구는 에이전트 앱에서는 서버별로 묶여서("Notion MCP » Create Page" 같은 식으로) 도구 목록에 나타나고, 워크플로우에서는 캔버스에 올릴 수 있는 노드가 되며, 워크플로우 안의 에이전트 노드에서도 일반 에이전트와 똑같이 쓸 수 있어요. Linear나 Notion처럼 자체 MCP 서버를 제공하는 서비스를 직접 붙여도 되고, Zapier 같은 중계 플랫폼을 등록하면 수천 개 앱이 한 번에 사정권에 들어옵니다.

5단계(선택) : 도구를 우리 팀에 맞게 길들이세요
도구를 앱에 추가할 때 설정 화면이 열리는데, 여기서 두 가지를 손볼 수 있어요. 하나는 도구 설명을 더 구체적으로 덮어쓰는 것. AI가 이 설명을 읽고 도구를 언제 쓸지 판단하기 때문에 설명이 구체적일수록 호출 정확도가 올라갑니다. 다른 하나는 파라미터마다 AI가 값을 정하게 둘지(Auto), 고정값을 박아둘지(Fixed) 고르는 건데, 공식 문서의 예시처럼 검색 도구라면 결과 개수는 5로 고정하고 검색어만 AI에게 맡기는 식으로, 설정성 값은 고정하고 동적인 입력만 열어두는 게 요령이에요.

따라 해보기 ② 내 Dify 앱을 MCP 서버로 내보내기

이번엔 반대 방향이에요. 사내 반복 업무를 워크플로우로 만들어뒀다면, 그걸 다른 AI 도구들이 부품처럼 갖다 쓰게 만들 차례입니다.

1단계 : 앱 설정에서 MCP Server 모듈을 켜세요
앱의 설정 화면에 들어가면 MCP Server 구성 모듈이 있어요. 기본값은 꺼짐인데, 토글을 켜는 순간 이 앱만의 고유한 MCP 서버 주소가 발급됩니다. 이 주소가 외부 도구들이 우리 앱에 접속하는 대문이에요. 그리고 여기서 꼭 기억할 것 하나. 이 URL 자체에 인증 정보가 들어 있어서, API 키 다루듯 다뤄야 합니다. 외부에 노출된 것 같으면 재생성 버튼으로 새 주소를 발급받으세요. 이전 주소는 그 즉시 무효가 됩니다.

2단계 : Claude Desktop에 연결하기
Claude에서 프로필 > 설정(Settings) > 인테그레이션(Integrations)으로 들어가 Add integration을 누르고, Integration URL 자리에 방금 발급받은 서버 주소를 붙여 넣으면 끝이에요. 이제 Claude가 대화 중에 우리 Dify 앱을 하나의 도구로 인식하고 호출할 수 있게 됩니다.

3단계 : Cursor에 연결하기
Cursor는 설정 파일 방식이에요. 프로젝트 루트에 .cursor/mcp.json 파일을 만들거나 열어서 아래처럼 적어주면 됩니다.

json

{
  "mcpServers": {
    "우리팀-리포트-생성기": {
      "url": "발급받은 서버 주소"
    }
  }
}

URL만 우리 앱 주소로 바꾸면 Cursor가 설정을 자동으로 감지해서 도구로 등록해 줘요. mcpServers 객체 안에 항목을 더 추가하는 방식으로 여러 개의 Dify 앱을 동시에 연결할 수도 있고요.

4단계(운영 팁) : 설명을 AI의 눈으로 다시 쓰세요
내보낸 앱을 실제로 호출하는 건 사람이 아니라 상대편의 AI예요. 그래서 도구와 입력 파라미터의 설명을 쓸 때 AI가 어떻게 해석할지를 기준으로 써야 하는데, 공식 문서의 예를 빌리면 "input data"처럼 뭉뚱그리지 말고 "name, email, preferences 필드가 필수인 사용자 프로필 JSON 객체"처럼 구체적으로 적으라는 거죠. 하나 더, MCP는 통신만 담당하니까 앱 자체가 30초 걸리면 상대편에서도 30초를 기다리게 돼요. 응답이 긴 워크플로우라면 더 작고 빠른 단위로 쪼개는 걸 고려해 보세요.

여기까지 하면 사내에 흩어진 반복 업무가 워크플로우가 되고, 그 워크플로우가 회사의 공용 AI 부품함이 되는 그림이 완성됩니다. 팀원들은 각자 쓰던 Claude나 Cursor를 떠나지 않고도 우리 팀의 워크플로우를 불러 쓰게 되는 거고요.

게시 전 이미지 확인 메모: 본문 이미지는 전부 Dify 공식 문서에 실린 스크린샷 원본 URL이에요. 외부 이미지 링크는 문서 개편 시 깨질 수 있으니, 인블로그 게시 시에는 위 화면들을 우리 계정에서 직접 캡처해 교체하고 지금 넣어둔 대체 텍스트(alt)를 그대로 살려주시는 걸 권합니다. UI 문구는 버전에 따라 조금씩 달라질 수 있어요.

이번 신규 스펙에 각 플랫폼이 언제 대응할지는 지켜봐야겠지만, 방향은 이미 정해졌어요. 에이전트 연동의 기본 언어는 MCP고, 그 언어는 방금 더 확장 가능한 문법으로 개정됐다는 것. 다음에 AI 플랫폼을 고르거나 사내 에이전트 아키텍처를 설계할 일이 있다면, "MCP를 양방향으로 다룰 수 있는가"를 체크리스트 맨 위에 올려두시길 권해요. 표준 위에 올라탄 팀과 표준을 쫓아다니는 팀의 격차는, 이런 개편이 있을 때마다 한 뼘씩 벌어지니까요.