읽기 전용 MCP 서버 vs 읽기·쓰기 MCP 서버: 에이전트 메모리를 가르는 차이

두 제품이 모두 기능 페이지에 "MCP 서버"를 내걸고, 둘 다 90초 남짓이면 Claude에 연결되며, 그 말이 둘 다 사실일 수 있습니다. 저희는 2026년 9월 5일 Recall의 MCP 및 API 문서를 읽었는데, 거기서 드러나는 차이는 보통 일주일은 써 봐야 알게 되는 종류의 것이었습니다. 같은 이름표를 단 두 서버가 근본적으로 다른 일을 할 수 있다는 것입니다.

차이는 속도도, 제공하는 도구의 수도, 지원하는 클라이언트도 아닙니다. 단 하나의 질문입니다. 어시스턴트가 무언가를 다시 넣을 수 있는가?

읽기 전용이 실제로 뜻하는 것

읽기 전용 MCP 서버는 어시스턴트가 라이브러리에 접근해 무언가를 꺼내 오게 해 줍니다. 검색하고, 문서를 가져오고, 무엇이 있는지 목록을 볼 수 있습니다. 하지만 무언가를 추가할 수는 없습니다. 라이브러리는 오직 사용자를 통해서만, 즉 앱, 확장 프로그램, 직접 붙여 넣기를 통해서만 늘어납니다.

상당수 작업에서는 이것으로 전혀 문제가 없습니다. 라이브러리가 이미 갖춰져 있고 거기에 질문하는 것이 목적이라면 읽기 전용이면 충분합니다. 더 안전한 기본값이기도 합니다. 어시스턴트에게는 쓸 수단이 없으니, 어시스턴트가 무엇을 하든 저장해 둔 것이 훼손될 일이 없습니다.

현재 가장 분명한 예는 Recall이며, Recall의 문서는 이 점을 감탄스러울 만큼 솔직하게 밝힙니다. 2026년 7월 28일에 마지막으로 업데이트된 개발자 문서 기준이며, 2026년 9월 5일에 다시 확인했습니다.

MCP 서버는 현재 지식 베이스에 대한 읽기 전용 접근을 제공합니다. 쓰기 기능은 곧 제공될 예정입니다.

설계도 일관되게 이를 따릅니다. OAuth 흐름은 정확히 하나의 스코프, 즉 "Read your saved content"(저장한 콘텐츠 읽기)로 설명된 kb:read만 요청합니다. 서버는 search, filter_by_metadata, get_document_content, explore_kb의 네 가지 도구를 제공하며, 모두 그 하나의 읽기 스코프만 필요로 합니다. 부여할 쓰기 스코프가 없습니다. 그것을 부여할 대상 자체가 없기 때문입니다.

이는 실수가 아니라 일관된 제품 결정입니다. 동시에 명시적으로 일시적이기도 합니다. "곧 제공 예정"이라는 말은 이 비교에 유효 기간이 있다는 뜻이니, 게시 후 몇 달이 지나 이 글을 읽고 있다면 이 문단을 믿기보다 그들의 문서를 확인하세요.

2026년 10월 4일 업데이트: 2026-10-04 기준으로 Recall의 MCP 서버는 여전히 읽기 전용(kb:read 스코프 하나, 도구 네 개)이고, REST API도 여전히 GET 엔드포인트 세 개뿐입니다. Recall은 쓰기 접근을 곧 제공하겠다고 발표했습니다. 공개 변경 내역의 2026년 9월 12일과 25일 항목에서 "Coming Next"(다음 예정) 아래에 "MCP 2.0 with write access"(쓰기 접근이 가능한 MCP 2.0)를 올려 두었습니다. 출시되면 이 글을 업데이트하겠습니다.

어시스턴트가 쓸 수 있으면 달라지는 것

이번에는 쓰기를 받아들이는 서버로 같은 한 주의 작업을 생각해 봅시다.

리서치 에이전트에게 무언가를 조사해 달라고 합니다. 에이전트는 출처 20개를 읽고, 그중 3개는 정말 남겨 둘 가치가 있습니다. 읽기 전용 서버라면 에이전트는 그 3개가 무엇인지 알려 주고, 사용자는 다른 탭에서 하나씩 직접 저장해야 합니다. 발견은 에이전트가 했지만 정리는 전부 수작업입니다.

읽기·쓰기 서버라면 에이전트가 직접 저장합니다. 세 출처가 태그가 붙은 채 라이브러리에 들어가고, 다음 세션에서 질의할 수 있습니다. 에이전트가 한 작업이 그 작업이 이루어진 대화가 끝난 뒤에도 남습니다.

BrainTube의 MCP 서버는 읽기·쓰기입니다. 쓰기 도구는 공개 연결 페이지에 나와 있습니다. 항목 하나를 저장하는 ingest_content, 여러 항목을 한 번에 저장하는 bulk_ingest, 어시스턴트 자신의 관찰을 남기는 add_note, 저장 후 정리를 위한 tag_item입니다. 이 도구들은 예상할 만한 읽기 도구인 search_knowledge, list_recent, get_stats와 나란히 있습니다.

여기서는 기능 범위의 형태를 설명하는 것이지, 점수판에서 이겼다고 주장하는 것이 아닙니다. 읽기·쓰기 서버는 더 많은 일을 할 수 있는 만큼 덜 안전합니다. 쓰기 권한이 있는 어시스턴트는 엉뚱한 것을 저장하거나, 태그를 일관성 없이 붙이거나, 원하지 않는 자료로 라이브러리를 채울 수 있습니다. 읽기 전용 서버는 그런 실수를 할 수 없고, 바로 그 이유로 읽기 전용을 선호하는 팀도 있습니다.

왜 하필 에이전트 워크플로를 좌우하는가

키보드 앞에 앉은 사람에게 이 차이는 성가신 정도입니다. 에이전트의 요약을 읽고, 링크를 복사하고, 저장하면 됩니다. 30초면 끝납니다.

무인으로 돌아가는 에이전트에게 이 차이는 치명적입니다. 정리를 맡아 줄 사람이 루프 안에 없습니다. 서버가 읽기 전용이면 에이전트가 찾은 것은 대화 기록 안에만 존재하는데, 대화 기록은 지식 베이스가 아닙니다. 세션을 넘나들며 검색할 수 없고, 인덱싱되지 않으며, 그것이 필요한 다음 에이전트가 접근할 수도 없습니다. 컨텍스트 창이 닫히면 작업은 증발합니다.

기능 비교에서 놓치는 부분이 바로 이것입니다. "MCP 지원"은 예/아니요로 취급되지만, 실제로는 전혀 그렇지 않습니다. 읽기 전용 MCP 서버는 라이브러리를 에이전트가 이용할 수 있게 만듭니다. 읽기·쓰기 서버는 에이전트를 라이브러리의 기여자로 만듭니다. 같은 세 글자 이름표를 단 서로 다른 제품입니다.

실용적인 판단 기준은 이렇습니다. 지켜보지 않아도 돌아가는 무언가를 만든다면, 예를 들어 예약된 리서치 작업, 배운 것을 기억해야 하는 코딩 에이전트, 문서를 정리해 넣는 파이프라인이라면, 읽기 전용은 우회할 수 있는 제약이 아닙니다. 호출할 쓰기 엔드포인트 자체가 없습니다.

확인해 볼 질문

MCP 서버가 있는 도구에 아카이브를 맡기기 전에, 금방 확인할 수 있지만 거의 광고되지 않는 세 가지가 있습니다.

OAuth 흐름이 어떤 스코프를 요청하는가? 가장 빠른 판별법이며, 문서가 명확하든 아니든 연결할 때 바로 볼 수 있습니다. 읽기 스코프가 하나뿐이라면 기능 페이지에 뭐라고 적혀 있든 읽기 전용입니다.

도구 이름에서 무엇을 알 수 있는가? search, get, list, explore 같은 이름의 도구는 읽기용입니다. 목록에 생성을 암시하는 것이 하나도 없다면, 아무것도 생성하지 않습니다.

쓰기가 로드맵에 있고, 날짜가 있는가? 날짜 없는 "곧 제공 예정"은 언제까지든 늘어날 수 있는 말입니다. 분기라도 명시하는 업체는 그렇지 않은 업체보다 더 쓸모 있는 정보를 주는 셈입니다.

이 중 어느 것을 확인하든 비교 페이지를 믿을 필요는 없습니다. 저희 페이지도 마찬가지입니다. 이 글의 모든 주장은 업체의 공개 문서에서 나왔으며, 직접 찾아가 확인할 수 있습니다.

읽기/쓰기 지원은 MCP 기반 메모리 도구 비교에서 저희가 사용하는 기준 중 하나입니다.

솔직한 요약

라이브러리가 갖춰져 있고 거기에 질문하고 싶다면 읽기 전용 MCP가 정답입니다. 더 단순하고 더 안전하며, 어시스턴트를 대화형으로 쓰는 대부분의 사람에게는 충분합니다.

어시스턴트가 배운 것이 오래 남는 곳에 쌓이길 원한다면 읽기·쓰기 MCP가 정답입니다. 오늘날에는 더 좁은 수요입니다. 하지만 저희가 보기에는 이 카테고리가 향하는 방향이기도 합니다. 사람이 아닌 에이전트가 읽는 양은 한 방향으로만 늘고 있고, 정리해 넣을 수 없다면 그 어느 것도 큰 가치가 없습니다.

둘 중 어느 쪽이 내 한 주를 더 잘 설명하는지에 따라 고르세요. 다만 "MCP 지원"이라는 말이 이 질문에 답해 주었다고 생각하지는 마세요. 답해 주지 않았으니까요.

BrainTube의 현재 위치

BrainTube는 라이브러리 전체를 다루는 읽기·쓰기 MCP 서버 하나(https://mcp.brain-tube.com/mcp)를 운영합니다. 모든 계정에 ingest_content와 bulk_ingest를 포함한 38개 도구가 제공되고, MCP 접근은 무료를 포함한 모든 요금제에 포함되어 있습니다. 그래서 쓰기 기능을 믿고 넘어갈 필요 없이 $0 계정에서 직접 시험해 볼 수 있습니다.

이 설계의 반대편도 분명히 밝혀 둘 가치가 있습니다. 서버 하나가 라이브러리 전체를 다루므로 Brain별 범위 지정이 없습니다. 연결한 클라이언트는 라이브러리의 일부가 아니라 라이브러리 전체에 접근합니다. 자체 모델을 가져와 쓰는 옵션도 없습니다. 특정 클라이언트 하나에서 읽기 전용이 실제로 무엇을 뜻하는지는 Claude가 Recall에 저장할 수 있을까에서 자세히 다뤘습니다.

수치 확인 방법

Recall의 읽기 전용 상태, kb:read 스코프, 네 가지 도구 목록은 2026년 9월 5일 docs.recall.it/developer/mcp의 MCP 문서에서 읽었으며, 해당 페이지에는 2026년 7월 28일에 마지막으로 업데이트되었다고 적혀 있습니다. 그 페이지는 MCP 쓰기 기능을 날짜 없이 "곧 제공 예정"이라고 설명합니다. 같은 날 읽은 별도의 REST API 레퍼런스(docs.recall.it/developer/api, 2026년 7월 27일 마지막 업데이트)도 읽기 전용입니다. GET 엔드포인트 세 개만 있고 POST, PUT, PATCH는 없으며, 쓰기 API는 "로드맵에 있다"고 적혀 있습니다. 이 글을 읽을 때쯤에는 둘 중 하나가 이미 출시되었을 수도 있으며, 기준은 이 페이지가 아니라 그들의 문서입니다.

BrainTube의 MCP 도구에 관한 내용은 2026년 9월 5일에 읽은 brain-tube.com/connect.md에 게시된 도구를 기준으로 합니다. 게시된 전체 개수와 함께 구체적인 쓰기 도구 이름도 밝혔습니다.

여기서 낡은 내용이 있다면 알려 주세요. 날짜를 밝혀 바로잡겠습니다.