Claude Desktop의 채팅 모드에서 파일 액세스 (File access) 기능이 한동안 불안정했습니다. 어떤 때는 작동하고 어떤 때는 작동하지 않았으며, 명확한 패턴도 없었습니다. 일반적인 해결 방법, 즉 Claude가 일반 채팅에서 직접 알려주는 방법은 claude_desktop_config.json 파일을 직접 편집하는 것입니다. 저는 그렇게 했고, 그것이 제대로 작동하는지 확인하기도 전에 다른 사실을 발견했습니다. 완전히 다른 두 개의 사이드바 레이블 아래에 동일한 파일 시스템 (Filesystem) 설정이 들어 있었으며, 이들이 같은 페이지라는 설명은 어디에도 없었습니다. 제가 이를 알아챈 이유는 Claude에게 Mac에 대한 직접적인 제어 권한을 부여하는 관련 없는 확장 프로그램을 활성화했고, 이를 사용하여 설정을 제대로 감사 (audit) 할 수 있었기 때문입니다.

이 글에서 다룰 내용

• 내가 실제로 답을 얻어야 했던 질문
• 별 도움이 되지 않는 해결책
• 하나의 페이지, 두 개의 사이드바 레이블
• 감사를 통해 발견한 것
• GitHub: 아키텍처를 결정지은 버그
• 올바르게 보이는 것과 실제로 작동하는 것의 차이
• 그래서, 당신은 정말로 알고 있습니까?
• 다음 단계

내가 실제로 답을 얻어야 했던 질문

저는 두 대의 Mac을 사용하여 주로 Claude가 읽고 쓰는 개인 운영 위키 (personal ops wiki)를 운영하고 있습니다. Claude Desktop의 일반 채팅 모드에서의 파일 액세스 (File access)는 한 번도 완전히 신뢰할 수 있는 느낌을 주지 못했습니다. 제가 인지한 설정 변경이 없었음에도 불구하고, 어떤 세션에서는 잘 작동하다가 다음 세션에서는 실패하곤 했습니다. 쉬운 답변은 "대신 Cowork 모드를 사용하세요"라는 것이며, 이는 괜찮은 조언이지만 해결책(workaround)일 뿐 진단(diagnosis)은 아닙니다. 저는 가벼운 채팅 모드 액세스를 고칠 가치가 없다고 결정하기 전에, 실제로 무엇이 구성되어 있는지 알고 싶었습니다.

별 도움이 되지 않는 해결책

일반 채팅에서 Claude에게 이를 어떻게 설정하는지 물어보면, claude_desktop_config.json을 가리킵니다. 즉, 서버당 하나의 항목을 수동으로 편집하는 전형적인 mcpServers JSON 블록입니다. 대부분의 가이드에서 제시하는 답변이 바로 이것입니다.

저는 범위가 지정된 파일시스템 (filesystem) 항목을 작성하고 재시작했습니다. 제가 하지 않았던, 그리고 했어야 했던 일은 해당 항목이 실제로 액세스를 제어하고 있는지, 아니면 그 아래에서 이미 무언가가 실행 중인지를 확인하는 것이었습니다. 저는 "다른 것은 아무것도 없고 JSON 항목만 존재하는" 상태의 깨끗한 테스트를 결코 분리하여 수행하지 않았습니다. 실제로 무엇이 액세스를 허용하고 있는지 확인하러 갔을 때, 저는 이미 활성화되어 있고 이미 설정되어 있는 두 번째 설정 화면을 발견했습니다. 그것이 얼마나 오래 실행되어 왔는지, 혹은 제가 방금 작성한 내용과 어떤 관련이 있는지 전혀 알 수 없었습니다.

한 페이지, 두 개의 사이드바 레이블

존재하는지도 몰랐던 설정 화면을 발견한 것만으로도 추측을 멈추기에는 충분한 이유가 되었습니다. 저는 Claude가 단일 화면의 주장만을 믿는 대신, 이전에 관련 없는 자동화를 위해 활성화하여 Mac에 대한 직접적인 AppleScript 및 쉘 (shell) 제어 권한을 부여했던 별도의 확장 프로그램 (extension)을 사용하여 관련된 모든 설정 파일을 읽도록 했습니다.

그 결과 드러난 것은 서로 싸우고 있는 세 개의 독립적인 시스템이 아니었습니다. 그것은 훨씬 더 구체적으로 짜증 나는 상황이었습니다. 동일한 파일시스템 (Filesystem) 설정 화면이 사이드바의 완전히 다른 두 곳에서 접근 가능하며, 스타일은 동일하지만, 두 곳이 같은 페이지라는 것을 알려주는 상호 참조가 전혀 없었습니다. Desktop app → Extensions → Filesystem을 통해 탐색하면 한 페이지에 도달합니다. Customize → Connectors → Filesystem을 통해 탐색하면 정확히 똑같은 페이지에 도달합니다. 동일한 토글, 동일한 두 개의 허용된 디렉토리, 동일한 도구 권한 (tool-permission) 목록이 픽셀 단위로 일치합니다. 두 개의 문이 있지만 방은 하나뿐이며, 어느 문에도 다른 문에 대한 언급이 없습니다.

그 아래에는 진정으로 별개인 두 번째 요소가 있습니다. 바로 가공되지 않은 claude_desktop_config.json의 mcpServers 블록입니다. 이것은 이를 수행하는 이전 방식이며, Anthropic이 통합 화면으로 병합하지 않은 모든 것(예: GitHub의 서버와 같은 제3자 서버)에 대해서는 여전히 올바른 방식입니다.

따라서 실제 구조는 세 개의 설정 인터페이스가 아닙니다. 그것은 하나의 레거시 JSON 방식과 하나의 현재 GUI 시스템입니다. Anthropic의 자체 내비게이션조차 이 시스템을 "Extensions (확장 기능)"라고 불러야 할지, 아니면 "Connectors (커넥터)"라고 불러야 할지 결정하지 못한 듯하며, 명칭을 변경하는 과정에서 동일한 화면을 두 카테고리 모두에 등록해 두었지만 이 중복에 대해 설명하는 것은 아무것도 없습니다. 만약 당신이 수개월간의 점진적인 UI 변경 사항을 거치며 Claude Desktop을 사용해 왔다면, 서로 다르게 보이는 두 개의 메뉴를 통해 서로 다른 두 시점에 한 가지 설정을 두 번 설정했을 뿐인데, 마치 두 가지 서로 다른 것을 설정했다고 믿게 만들기 딱 좋은 환경입니다.

감사(Audit)를 통해 발견한 내용

파일 시스템 액세스 (Filesystem access) 권한은 제가 JSON 항목을 작성하기도 전에 이미 GUI 화면에 의해 제어되고 있었습니다. 제가 정확히 기억하지 못하는 더 이른 시점에, 제가 실제로 원했던 두 개의 폴더보다 더 긴 폴더 목록으로 설정되어 있었습니다. 수개월에 걸쳐 하나씩 추가되었고 전체적으로 검토된 적이 없는 오래된 프로젝트의 옛 폴더들이었습니다. 내용물에 극적인 것은 없었습니다. 그저 의도했던 것보다 많았을 뿐이며, 그 모든 것을 의도적으로 선택했다는 기억은 없었습니다.

정작 중요한 부분은 이것입니다: 제가 방금 작성한 JSON 항목이 GUI 화면의 자체 설정과 동시에 mcpServers에 활성화된 상태로 놓여 있었고, 저는 JSON 설정이 무언가를 하고 있는지, 부분적으로만 작동하는지, 아니면 완전히 비활성 상태인지 알 방법이 없었습니다. 동일한 작업을 수행한다고 주장하는 두 개의 별개 파일 시스템 MCP 서버가 실제로 어떤 결과를 초래하는지 시행착오를 통해 확인하고 싶지는 않았습니다. 가장 유력한 추측은 다음과 같습니다: 선택기(picker)에 중복된 도구들이 나타나거나, 두 서버가 모두 read_file과 같은 기능을 등록할 경우 도구 선택이 모호해질 수 있습니다. 이는 추측일 뿐, 확인된 실패 모드(failure mode)는 아닙니다. 그래서 저는 문제를 해결하는 대신 불확실성을 제거하기로 했습니다. JSON 항목을 빈 mcpServers: {}로 되돌리고, GUI 화면만이 유일하게 활성화된 상태로 남겨두었습니다.

여기서 진짜 위험한 점은 JSON 방식이 쓸모없어졌다는 것이 아닙니다(이 또한 제가 증명할 수 있는 부분은 아닙니다). 진짜 문제는 만약 동일한 기능에 대해 'Extensions'라고 표시된 뷰와 'Connectors'라고 표시된 뷰가 서로 다른 폴더 목록을 보여주게 될 경우입니다. 즉, 단순히 하나의 방으로 통하는 두 개의 문이 아니라, 두 문이 실제로 서로 어긋나 버리는 상황 말입니다. UI 상에서는 어떤 것이 실제인지, 혹은 두 설정이 서로 달라졌는지조차 알려주는 것이 아무것도 없습니다. 따라서 이들이 동기화되어 있다고 가정하기보다는 실제로 나란히 놓고 확인해 볼 가치가 있습니다.

GitHub: 아키텍처를 결정지은 버그

별개로, 저는 GitHub push 권한이 필요했습니다. Anthropic은 네이티브 GitHub Integration 커넥터(Connector)를 제공합니다: Settings → Connectors, 클릭, 승인, 완료. 아주 명확한 경로입니다.

하지만 2026년 7월 말 기준으로, 해당 커넥터의 OAuth 권한이 읽기 권한(read access)은 잘 부여하지만, git push를 포함한 모든 쓰기 작업(write operation)에서 403 Resource not accessible by integration 오류와 함께 실패하는 미해결된 버그가 존재합니다. 확인되었고, 보고되었으며, 제가 확인했을 때도 여전히 열려 있는 상태였습니다. 확인도 없이 토글을 켜버리면, 연결된 것처럼 보이지만 정작 필요한 기능은 조용히 실패하는 커넥터를 갖게 됩니다.

해결 방법(Workaround): Anthropic의 GitHub App 대신, Docker를 통해 로컬에서 실행되고 세분화된 개인 액세스 토큰(fine-grained personal access token)으로 인증되는 GitHub 자체의 공식 MCP 서버를 사용하는 것입니다.

{
  "mcpServers": {
    "github": {
...

이것은 진정으로 mcpServers에 포함되어야 하는 항목입니다. GitHub는 Claude Extension으로 제공되지 않으므로, 여기서는 기존 방식이 올바른 방식입니다. 하지만 이것 또한 일종의 작은 함정입니다. 무언가를 설정할 올바른 위치가 Anthropic이 그것을 Extension으로 출시했는지 여부에 전적으로 달려 있으며, 그 사실을 사전에 알려주는 것도 아무것도 없기 때문입니다.

'맞아 보인다'는 것이 '작동한다'는 것과 같지는 않다

파일 시스템 액세스에서

단순히 유효한 토큰(token)을 가진 것을 넘어, 실제 저장소(repo)에 대한 쓰기 권한(write permission)이 있는가:

curl -s -H "Authorization: Bearer $TOKEN" https://api.github.com/repos/me/my-repo

저는 특히 permissions 객체에서 "push": true 여부를 확인했습니다.

수동 테스트가 아니라, 실제 Claude Desktop 프로세스가 깔끔하게 연결되었는지 로그를 추적(tailing)하여 확인했는가:

~/Library/Logs/Claude/mcp-server-github.log

실제 재시작 후에 readOnly=false, lockdownEnabled=false, 그리고 깔끔한 Server started and connected successfully 메시지가 나타나는지 확인해야 합니다.

그렇다면, 실제로 알고 계신가요?

만약 Claude Desktop을 실행 중이면서 현재 무엇이 파일 액세스 권한을 가지고 있는지 알고 있다고 생각하신다면, 가이드의 답변이 아닌 실제 답변은 다음과 같습니다.

Desktop app → Extensions → Filesystem과 Customize → Connectors → Filesystem을 모두 확인하고, 각각 무엇을 보여주는지 비교해 보십시오. 저의 경우, 폴더 목록을 수정한 후에는 두 설정이 일치했는데, 이는 하나의 근본적인 화면이 두 개의 레이블로 분류되어 일관되게 표시된 것이었습니다. 모든 설치 환경에서 이것이 보장되는지는 확인하지 않았으므로, 제 말을 믿기보다는 직접 확인해 보시기 바랍니다. 만약 각 설정에서 서로 다른 폴더를 보여준다면, 그것이 바로 실제로 문제가 되는 상황입니다. 두 설정 모두 그럴듯하게 "진짜"처럼 보이지만 서로 충돌하고 있으며, Claude가 어떤 것을 사용하는지 알려주는 것은 아무것도 없는 상태 말입니다.

그다음, JSON 방식이 조용히 섞여 있지는 않은지 확인하십시오:

cat ~/Library/Application\ Support/Claude/claude_desktop_config.json

만약 mcpServers 아래에 filesystem 키가 나타난다면, 이는 동시에 활성화되어 있을 가능성이 있는 세 번째 요소입니다. 이 설정과 GUI 화면이 모두 활성화되어 있을 때 어떤 일이 발생하는지는 알 수 없으며, 저는 확인하지 않기로 했습니다. 테스트하기보다는 삭제하는 편을 택하겠습니다.

Anthropic이 통합 화면에 포함시키지 않은 모든 항목, 즉 자체 Extension이 없는 제3자(third-party) MCP 서버의 경우, 이를 위한 GUI 카드가 전혀 없기 때문에 JSON 파일이 올바르고 현재 유효한 설정 위치입니다.

Extensions(확장)와 Connectors(커넥터)가 하나의 데이터 저장소가 두 개의 문 뒤에 있는 형태인지, 동기화되어 유지되는 두 개의 저장소인지, 아니면 조용히 어긋날 수 있는 두 개의 저장소인지에 대해 저는 제 사례에 대한 직접적인 증거만 가지고 있으며, 수정 후에는 일관된 상태로 안착되었습니다. 더 확신을 가지고 말할 수 있는 것은, 제품 내 그 어떤 것도 이것이 어떤 방식인지 알려주지 않는다는 점이며, 이는 맹목적으로 믿기보다는 직접 확인해 볼 가치가 있다는 것입니다.

다음 단계

여기서 정리된 모든 것은 로컬 Mac 설정입니다. 아직 손대지 않은 더 큰 부분은 홈 Proxmox LXC에서 실행되도록 의도된 커스텀 MCP 서버입니다. 이는 네트워크를 통해 읽기 전용 검색 및 린트(lint) 도구를 노출하는 작은 TypeScript 서비스로, Anthropic의 Custom Connectors 대신 mcp-remote stdio 브릿지를 통해 접근하도록 설계되었습니다. Custom Connectors는 공용 인터넷 연결이 필요하여 홈 LAN 환경에는 적합하지 않기 때문입니다. 현재는 설계 문서 단계이며, 작성된 코드는 전혀 없습니다. 이 설정 또한 '두 개의 문' 구조를 가지고 있을 것이라는 점은 거의 확실해 보입니다.

만약 여러분도 Claude Desktop 설정을 조사하다가 설정했다고 생각했던 것과 일치하지 않는 부분을 발견했다면, 그것이 무엇이었는지 듣고 싶습니다.