올해 당신이 AI 어시스턴트를 캘린더, 파일, 데이터베이스, GitHub 등 그 무엇인가에 연결했다면, MCP가 그 연결을 수행하고 있었을 가능성이 높습니다. Model Context Protocol (MCP)은 AI가 채팅창 너머로 확장되는 표준적인 방식이 되어 조용히 자리 잡았습니다. 하나의 프로토콜, 수천 개의 도구, 플러그 앤 플레이 (plug and play). 이는 진정으로 훌륭하며 어디에나 존재합니다.

따라서 DoSync와 같이 AI와 물리적 장치 사이의 프로토콜이라고 스스로를 설명하는 프로젝트가 등장했을 때, 합당한 질문은 다음과 같습니다: "왜 그것이 필요하죠? 제 AI는 이미 MCP를 통해 도구를 호출하고 있는데요. 전등을 제어하는 것도 그저 또 다른 도구 호출 아닌가요?"

그것은 올바른 질문입니다. 사람들은 MCP와 DoSync가 마치 경쟁 관계인 것처럼 그 차이점을 계속해서 찾고 있으며, 저는 정직하게 답변하고자 합니다. 여기에는 "아마도 당신은 DoSync가 필요하지 않을 것입니다"라는 부분도 포함됩니다. 다른 무엇보다 먼저 투명하게 밝힙니다: 저는 DoSync를 만듭니다. 이 점을 염두에 두고 아래의 모든 내용을 읽어주세요.

MCP란 정확히 무엇인가

MCP는 Anthropic이 도입한 개방형 프로토콜로, AI 애플리케이션이 도구 및 데이터에 연결되는 방식을 표준화합니다. MCP 이전에는 모든 통합이 맞춤형(bespoke)이었습니다. 캘린더를 위한 커넥터 하나, 데이터베이스를 위한 또 다른 커넥터 하나가 각각의 AI 제품에 맞춰 작성되었습니다. MCP는 이를 단일 계약(contract)으로 대체합니다. 한쪽에는 AI 클라이언트가 있고, 다른 한쪽에는 수많은 "MCP 서버"가 있으며, 각 서버는 모델이 발견하고 호출할 수 있는 도구들을 노출합니다.

모두가 사용하는 비유는 USB-C이며, 이는 적절한 비유입니다. 하나의 포트에 무엇이든 꽂을 수 있으니까요. 비유가 아닌 정확하게 말하자면, MCP는 모델이 어떤 도구가 존재하는지 _발견(discovers)_하고 그것들을 _호출(invokes)_하는 방식을 정의하며, 요청과 결과를 양방향으로 충실하게 전달합니다. 도구가 호출되었을 때 실제로 무엇을 하는지는 전적으로 도구의 영역입니다.
전송(Transport)은 판단(judgment)하지 않습니다. 이것은 결함이 아니라 설계입니다. 이 문구를 기억하세요. 이 글의 나머지 내용은 모두 이 문구에 달려 있습니다.

사용 시점: AI가 자신 외부의 무언가에 접근해야 할 때마다 사용합니다. 오늘날에는 거의 항상 그렇습니다. 만약 당신의 AI가 이메일을 읽거나, 데이터베이스를 쿼리(Query)하거나, 티켓을 생성한다면 MCP가 적절한 계층(Layer)이며, 그 작업에는 충분합니다. 그 아래 단계의 무엇도 이를 바꾸지 못합니다.

DoSync란 정확히 무엇인가

DoSync는 AI와 물리적 장치(physical devices), 조명, 잠금장치, 센서, 알람 사이에 위치하는 오픈 프로토콜 (Apache 2.0)입니다. DoSync는 단 한 가지 작업만 수행합니다. 평이한 용어로 표현된 목표를 조정되고, 감독되며, 기록된 일련의 물리적 행동 세트로 변환하는 것입니다.

여기서 핵심이 되는 단어는 _목표(goal)_입니다. 당신은 DoSync에 "램프 3번을 켜고, 그다음 램프 4번을 켜고, 그다음 문을 열어라"라고 보내지 않습니다. 대신 당신은 의도(intent), 즉 _ensure_safety(안전 확보)_를 보내고, 리졸버(resolver, 어떤 장치가 중요한지 파악하는 부분)가 이를 장치들이 연결될 때 스스로 선언한 기능(capabilities)과 대조합니다. 그러면 일반적인 도구 계층(tool layer)은 해주지 못하는 세 가지 일이 일어납니다.

• 운영자의 자체 규칙이 적용됩니다. 정책(Policies)은 운영자가 제어하는 파일에 선언된 해당 공간의 고정 규칙입니다 — "밤샘 시간에는 이 문들을 절대 열지 마라", "이 구역은 알람 패턴에서 제외한다", "사이렌은 명시적인 확인이 필요하다" 등입니다. AI는 이를 기억할 필요가 없으며, 대화를 통해 이를 우회할 수도 없습니다.
• 모든 행동은 기록됩니다. 조작 방지 기능이 있는 감사 로그(audit log)에 기록됩니다 — 무엇이, 언제, 왜 작동했는지가 기록되며, 이력 변경이 감지 가능한 해시 체인(hash chain) 구조를 가집니다. 이는 디버그 로그(debug log)가 아니라, 나중에 누군가에게 보여줄 수 있는 기록입니다.
• 완료는 가정되는 것이 아니라 확인됩니다. 명령이 _수락(accepted)_되었다는 것이 _완료(done)_되었다는 것과 같지는 않습니다. DoSync는 단계를 완료되었다고 호출하기 전에 장치가 실제 상황을 확인해 줄 때까지 기다립니다.

사용 시점: AI가 호출하는 "도구"가 물리적 세계이고, 이를 잘못 처리했을 때의 결과가 단순한 API 호출 실패 이상의 파급력을 가질 때 사용합니다.

그들은 라이벌이 아닙니다. 하나가 말 그대로 다른 하나를 사용합니다.

대립 구도를 해소하는 부분은 바로 이것입니다: DoSync는 MCP 서버로 제공됩니다. AI가 DoSync에 도달하는 방식 그 자체가 MCP입니다.

수많은 장치로 가득 찬 건물, 사무실, 클리닉, 창고, 혹은 상점을 상상해 보세요. 새벽 2시이고 무언가 잘못되었습니다. 담당자는 AI에게 한 문장을 입력합니다: "건물에 비상 상황이 발생했습니다." 복도 조명이 최대 밝기로 켜지고, 비상구가 잠금 해제되며, 경보가 울리고, 당직자들에게 메시지가 전송됩니다. 이는 스무 번의 우연한 대응이 아니라, 하나의 조율된 대응으로 이루어집니다. 일어난 일을 역순으로 따라가 봅시다: 모델이 문장을 이해했고(그것이 AI입니다), dosync_fire_intent라는 이름의 도구(tool)를 찾아 호출했으며(그것이 MCP가 정확히 제 역할을 수행하여 호출을 전달하는 것입니다), 그 단 한 번의 호출이 모든 관련 장치에 걸쳐 조율되고 기록된 대응이 되었습니다(그것이 DoSync입니다). 세 개의 계층, 하나의 루프, 충돌 제로. (분명히 말씀드리자면, 이것은 가상의 메커니즘이 아닙니다. 레퍼런스 구현체(reference implementation)는 실제 하드웨어에서 이 정확한 루프를 24시간 내내 실행하고 있습니다. 이 시나리오가 일반적인 이유는 프로토콜 자체가 어떤 종류의 건물을 서비스하는지 가정하지 않기 때문입니다.)

이제 건물에 자체적인 규칙을 하나 부여해 봅시다. 모든 실제 건물에는 규칙이 있으니까요. 예를 들어 이곳이 요양 시설이고, 한쪽 구역에는 깜빡이는 조명에 절대 놀라서는 안 되는 환자들이 거주한다고 가정해 봅시다. 그래서 운영자는 다음과 같은 정책을 선언했습니다: "해당 구역의 조명은 경보 패턴에서 제외한다. 예외는 없다. 비상 상황이라도 마찬가지다." 비상 상황이 발생했을 때, 리졸버(resolver)는 해당 조명을 포함하여 도움을 줄 수 있는 모든 장치를 — 정확하게 — 제안합니다. 그 조명들은 실제로 깜빡일 수 있으며, 사실대로 그렇게 말합니다. 하지만 정책이 어떤 동작이 실행되기 전에 해당 장치들을 제외하며, 기록에는 두 가지 사실이 모두 남습니다: 무엇이 제안되었는지, 그리고 건물의 자체 규칙이 무엇을 결정했는지 말입니다. 모델도, 전송 계층(transport)도, 리졸버도 그 누구도 실수하지 않았음에 주목하십시오. 모두가 자신의 역할을 제대로 수행했으며, _자신의 건물_에 대한 운영자의 판단이 여전히 최종 결정권을 가졌습니다. 그것이 바로 이 계층(layer)의 역할입니다.

한눈에 보기:

DoSync가 MCP에 더해주는 것

만약 당신이 물리적 세계와 접촉하는 에이전트 (agents)를 구축하고 있다면, DoSync는 MCP를 진지하게 사용할 수 있을 만큼 더 안전하게 만들어 줍니다:

• 50개 대신 단 하나의 도구. 조정 계층 (coordination layer)이 없다면, 장치로 가득 찬 건물을 제어하는 에이전트는 동작당 장치별로 하나의 도구가 필요하며, 모델은 압박 속에서 20개의 호출을 정확하고 순서대로 조율해야 합니다. DoSync를 사용하면 에이전트는 하나의 목표를 가진 단 하나의 도구만을 호출합니다. 조율은 언어 모델 (language model)의 컨디션 난조가 이를 망가뜨릴 수 없는 하위 계층에서 결정론적 (deterministically)으로 이루어집니다.
• 소유자의 규칙이 거주하는 곳. MCP는 도구가 무엇을 거부해야 하는지에 대해 의도적으로 의견을 갖지 않습니다. 그것은 도구의 역할입니다. DoSync는 해당 공간을 소유한 인간에 의해 거부 사항이 한 번에 선언되고, AI가 무엇을 요청하든 상관없이 강제되는 곳입니다.
• 기록. 에이전트가 세상에 작용할 때, "정확히 무엇이 왜 일어났는가"는 디버깅 (debugging)의 문제를 넘어 책임 소재 (accountability)의 문제가 됩니다.

MCP가 DoSync에 더해주는 것

이 방향성 또한 똑같이 중요하며, 이것이 DoSync가 자체적인 AI 인터페이스를 발명하지 않은 이유입니다:

• 모든 MCP 지원 AI는 이미 DoSync 클라이언트 (client)입니다. 오늘은 Claude가, 내일은 MCP를 지원하는 모든 모델이나 에이전트 프레임워크 (agent framework)가 그 역할을 할 것입니다. 모델별 통합도, 유지 관리해야 할 SDK도 필요 없습니다. MCP는 DoSync에 전체 정문 (front door)을 무료로 제공했습니다.
• 지능은 원래 있어야 할 곳에 머뭅니다. DoSync는 의도적으로 언어 모델을 포함하지 않습니다. "밤새 모든 것이 안전하도록 확인해줘"를 이해하는 것은 AI의 기술이며, MCP는 그 이해가 깔끔하고 구조화된 의도 (intent)로 전달되게 하는 역할을 합니다. DoSync는 코드 한 줄 바꾸지 않고도 모델이 발전할 때마다 함께 똑똑해집니다.

이것이 솔직한 구조입니다. DoSync와 같은 것이 없는 MCP는 물리적 세계에 닿을 수는 있지만, 그곳에 판단력을 가져다주지는 못합니다. MCP가 없는 DoSync는 뇌가 연결되지 않은 신경계와 같습니다. 각각은 서로의 가치를 높여줍니다.

그리고 대부분의 프로젝트가 말하지 않을 부분

오늘날 사람들이 MCP를 사용하는 대다수의 용도 — 이메일, 캘린더, 코드, 파일, 데이터베이스 — 에 대해서는 DoSync가 필요하지 않습니다. MCP만으로도 그 목적을 달성하기에 충분하며, 그것으로 끝입니다.