Claude Code의 마법: 유닉스 철학과 파일시스템 접근성이 Claude Code를 특별하게 만듦

• Claude Code는 단순한 코딩 도구를 넘어 에이전트 운영체제로 진화하여, 파일시스템 접근과 Unix 명령어 통합을 통해 다양한 워크플로우를 지원하는 혁신적 시스템
• 특히 Obsidian 노트 시스템과의 통합을 통해 메모 작성, 연구, 사고 정리를 자동화하며, SSH 연결로 모바일에서도 접근 가능한 완전한 노트 운영 체제를 구현
• 파일시스템 접근 기능이 핵심 차별화 요소로, 대화 간 메모리와 상태 유지를 가능하게 하여 ChatGPT나 브라우저 기반 Claude의 치명적 한계인 컨텍스트 윈도우 제약과 메모리 제한 문제를 해결
• Unix 철학(단순성, 조합성, 텍스트 스트림 처리)이 LLM의 도구 사용 방식과 완벽하게 일치하여, 50년 전 설계 원칙이 현대 AI 시스템의 최적 아키텍처로 재발견
• 이메일 관리 자동화(Inbox Magic), 오픈소스 도구(Claudesidian) 등 실용적 응용 사례를 통해 파일시스템 기반 에이전트 시스템이 복잡한 멀티 에이전트 구조보다 신뢰성 있고 디버깅 가능한 AI 애플리케이션 구축의 기초라는 것을 강조

---

Claude Code의 특별함

• 나는 최근 AI에 관한 대화에서 항상 Claude Code의 놀라운 기능에 대해 열변을 토했으며, 이 도구가 단순한 코딩 보조 도구에서 완전한 에이전트 운영체제로 발전했다고 설명함
• 특히 Obsidian 노트 앱과의 통합이 핵심으로, Obsidian은 Notion이나 Evernote와 달리 모든 파일을 로컬 하드 드라이브에 일반 Markdown 파일로 저장
  • 이러한 특성 덕분에 AI 코딩 도구의 이상적인 타겟이 되었으며, 처음에는 Cursor에서 시작했지만 곧 Claude Code로 전환
  • 이 시스템에 너무 의존하게 되어, 결국 집에 서버를 구축하고 SSH로 스마트폰에서 접속하여 이동 중에도 노트 작성, 읽기, 사고 정리가 가능한 환경을 구현
• 몇 주 전 Dan Shipper의 AI & I 팟캐스트 에 출연하여 이 시스템에 대한 심층 설명을 진행했으며, 이 글에서는 그 이후 깨달은 추가적인 인사이트를 공유

Cursor 대비 Claude Code의 우월성

• "Claude Code가 왜 특별한가?"라는 질문에 답하기 어려웠지만, 모든 면에서 Cursor보다 낫다기보다는 특정 요소들의 조합이 탁월하게 작동한다는 결론
• 최근에는 기존 코드베이스 작업보다 Claude Code 기능 위에 완전히 새로운 것을 구축하는 데 더 많이 사용

• Unix 철학과의 완벽한 조화

  • Claude Code의 비밀은 도구 접근 방식에 있으며, 터미널 기반 애플리케이션으로서 접근성을 포기하는 대신 네이티브 Unix 명령어 통합이라는 강력한 기능을 제공
  • Unix 철학은 Doug McIlroy가 1978년 Bell System Technical Journal에서 문서화했으며, 네 가지 핵심 원칙을 제시:
    • 1. 각 프로그램이 한 가지 일을 잘하도록 만들 것. 새로운 작업을 위해서는 기존 프로그램에 기능을 추가하기보다 새로 구축할 것
    • 2. 모든 프로그램의 출력이 아직 알려지지 않은 다른 프로그램의 입력이 될 것으로 예상할 것
    • 3. 소프트웨어를 조기에, 이상적으로는 몇 주 내에 시도할 수 있도록 설계하고 구축할 것
    • 4. 비숙련 인력보다는 도구를 사용하여 프로그래밍 작업을 경량화할 것
  • Peter H. Salus가 1994년 "A Quarter-Century of Unix"에서 요약한 버전:
    • 한 가지 일을 잘하는 프로그램을 작성할 것
    • 함께 작동하는 프로그램을 작성할 것
    • 텍스트 스트림을 처리하는 프로그램을 작성할 것 (범용 인터페이스이기 때문)

• LLM과 Unix 명령어의 완벽한 궁합

  • 이 50년 된 원칙들은 LLM이 도구를 사용하는 방식과 정확히 일치
  • 모델들은 지속적으로 출력을 입력으로 "파이핑"하며 (중간에 자체적인 퍼지니스를 사용), Unix의 | 명령어처럼 한 명령어의 출력을 다른 명령어의 입력으로 연결
  • 모델이 도구를 효과적으로 결합하지 못하는 경우는 거의 항상 도구가 지나치게 복잡하기 때문
  • Claude Code가 놀라운 이유의 첫 번째 부분: Unix를 구동하는 명령어들이 LLM 사용에 완벽하게 적합
    • 명령어들이 단순할 뿐만 아니라 매우 잘 문서화되어 있어, 모델이 학습할 충분한 소스 자료가 있었음

• 파일시스템 접근의 혁명

  • 다른 요소는 Claude Code의 코드 작성 능력과 최근에는 산문 작성 능력
  • Pragmatic Engineer의 Claude Code 구축 심층 분석 기사를 읽으면서 답을 발견: 파일시스템 접근
  • 파일시스템은 모든 것을 바꿈
    • ChatGPT와 브라우저 기반 Claude의 두 가지 치명적 결함: 대화 간 메모리 부재와 좁은 컨텍스트 윈도우
    • 파일시스템이 두 가지 모두 해결: Claude Code는 자신에게 메모를 작성하고, 지식을 축적하며, 실행 중인 집계를 유지
    • 상태와 메모리를 가지며, 단일 대화를 넘어 사고할 수 있음

AI 오버행 (AI Overhang)

• 2022년 GPT-3 API를 처음 사용했을 때, 모델이 그 순간보다 더 나아지지 않더라도 사용 사례를 발견하는 데 10년이 걸릴 것이라고 예측
• 모델은 실제로 개선되었고 (추론 모델이 도구 호출을 신뢰할 수 있게 만듦), 파일시스템 발견이 이 주장을 증명
• Pragmatic Engineer 인터뷰 에서 Claude Code의 초기 버전을 구축한 Boris Cherney가 "제품 오버행(product overhang)" 개념을 사용하여 설명:
  • 제품 오버행은 모델이 특정 작업을 수행할 수 있지만, AI가 실행되는 제품이 이 역량을 포착하도록 구축되지 않은 상태를 의미
  • 모델은 이미 파일시스템 탐색을 할 수 있었지만, 이 기능을 중심으로 구축된 제품이 없었던 것
• 저자는 파일시스템 + Unix 명령어의 조합이라고 주장하지만, 핵심은 모델의 역량이 이미 존재했고 깨어나기만을 기다리고 있었다는 점
• Claude Code는 과도하게 설계된 인터페이스를 통해 모델 역량을 제한하는 대신 포착하기 때문에, 신뢰할 수 있는 에이전트 시스템 구축의 청사진으로 작동

코드를 넘어서

Claudesidian 오픈소스 프로젝트

• Claude Code + Obsidian 설정에 대해 이야기했으며, 실제로 한 단계 더 나아가 "Claudesidian"을 오픈소스화
  • 내 Claude Code + Obsidian 설정에서 사용하는 많은 도구와 명령어를 포함
  • 실험적인 장으로 활용했으며, 특히 초기 업그레이드 도구를 구축
  • 중앙에서 변경 사항이 발생하면 내 Claudesidian으로 가져올 수 있으며, AI가 업데이트되는 파일에 변경 사항이 있는지 확인하고, 있다면 새 업데이트와 변경 사항을 스마트하게 병합 시도
• 두 프로젝트 모두 동일한 Unix 철학 원칙을 따름: 단순하고, 조합 가능하며, 한 가지 일을 잘하고 함께 작동하는 도구

Inbox Magic - 이메일 자동화 시스템

• 아직 출시할 준비가 되지 않았지만 곧 공개할 "Inbox Magic"(더 나은 이름을 생각할 예정)이라는 프로젝트 진행 중
• Gmail 도구 세트에 접근할 수 있는 Claude Code 저장소로, 많은 프롬프트와 명령어를 통해 이메일 비서처럼 작동
• 현재 기능은 상당히 단순:
  • 검색 실행 또는 대신 이메일 발송 가능
  • 이메일 분류 및 이메일 작성 스타일을 학습하기 위한 전체 훈련 실행 가능
  • Claude Code와 ChatGPT 모두 이메일에 접근할 수 있지만, 주로 한두 개씩만 가져옴
  • 이 시스템은 파일에 쓰기와 다양한 기교를 사용할 수 있어, "받은편지함의 모든 여행 관련 이메일을 찾아 여행 습관 프로필을 구축하고, 이를 ChatGPT/Claude가 실제 선호도에 맞춰 여행 조사를 하는 데 사용할 수 있는 프롬프트로 활용" 같은 작업 수행 가능
• 테스트하고 싶다면 GitHub 사용자 이름을 보내면, 테스트할 준비가 되는 즉시 공유 예정

핵심 교훈

• 일반적으로 결론을 피하지만, 여기에는 재강조할 가치가 있는 몇 가지 교훈이 존재:
• 1. 파일시스템은 LLM의 메모리 및 상태 부족을 해결하는 훌륭한 도구이며 더 자주 사용되어야 함
• 2. 도구 호출을 작동시키려면 Unix 철학을 따르는 데 집중해야 함
• 3. Claude Code는 미래 에이전트 시스템의 청사진을 나타냄
  • 파일시스템 + Unix 철학이 오늘날 떠다니는 복잡한 멀티 에이전트 시스템보다 신뢰할 수 있고 디버깅 가능한 AI 에이전트를 구축하는 템플릿이어야 함
  • 전술적으로, 자신의 프로젝트에 도구 호출을 구축할 때 단순하게 유지하고 주요 모델 스레드가 이를 "파이핑"하도록 하는 것이 핵심
  • 모든 에이전트/챗봇에서 해결해야 할 큰 문제: 컨텍스트 윈도우를 거치지 않고 파이핑할 수 있는 능력
• 4. LLM의 사용 사례를 찾지 못하는 사람은 충분히 노력하지 않는 것

[GN⁺]

Hacker News 의견

• 나는 Claude Code가 Unix 방식으로 작동하는 점이 정말 마음에 듦, 다른 Unix 스타일 도구를 쉽게 만들고 Claude가 추가 통합 작업 없이 바로 쓸 수 있음, 도구의 man page만 주면 Claude가 능숙하게 사용함, MCP나 복잡한 도구 정의 없이 진행 가능함, 직접 만든 브라우저 접근 도구와도 문제 없이 동작함

  • 최근 LLM시대를 맞아 manpage를 더 잘 검색하도록 만든 툴을 업데이트했음 Mansnip, 이걸 STDIO MCP로 감싸는 것도 좋은 방법이라 생각함, 이 코드에 API만 얹고 서버도 pip에 넣으면 좋을 것 같음, 그렇게 어려울 것 같지 않음

  • Claude Code가 내 스크립트나 도구에서 브라우저를 어떻게 사용하는지 궁금함, 나는 기존 Safari 세션 창들을 직접 조작하고 싶은데 대부분 Chrome이나 별도 새로운 인스턴스만 다룸

  • 내가 Claude에게 직접 문제를 찾아달라 하기보다, linter 사용법을 알려주면 훨씬 효율적임을 깨달았던 순간이 있었음, 어떤 linter를 쓰라고까지 지시하지 않아도 목록을 알려주고 설치하니 바로 활용함, ChatGPT로 코딩 시도했을 땐 유용한 결과를 얻으려면 너무 많은 노력이 필요해서 기대 안 했는데, Claude Code에선 정말 놀라운 경험임

• 모든 GUI 앱은 저마다 다르고 각자만의 벽을 쌓은 성처럼 존재함, 마치 OS 안에서 각자 고립된 영지 느낌임, 반면 CLI는 모두가 모이는 공통의 광장, 데이터와 신호가 교류되는 정보 시장임, 이 광장에 들어가기 위해 어떤 소속감을 가질 필요조차 없음, GUI 쪽에서 이와 비슷한 건 Smalltalk인데 그나마도 미리 충성을 맹세해야만 진입 가능함

  • 사실 GUI에서도 꽤 상호운용성과 조합성이 높은 시스템이 존재함, NextSTEP이나 dbus 같은 것들이 그 예시임, 원한다면 GUI도 공개 API 기반에 그래픽만 얹어서 만들 수 있음, 흔치는 않지만 기술적으로 가능함

  • OS에 갇힌 성채처럼 보이더라도, 일반 사용자 입장에선 CLI 앱보다 GUI 앱을 훨씬 더 선호함, CLI만 있었으면 컴퓨터 보급 속도가 크게 느려졌을 것임

• 새로 떠오른 툴이 터미널에서 실행된다고 해서 무조건 “진정한 UNIX 철학 구현”이 되는 건 아님, 이 비교 자체가 말이 안 됨, Hacker News식 낚시글에 나도 걸려버린 셈임

  • 여기서 말하는 UNIX 철학은 단순히 터미널 앱만을 의미하지 않고, 최신 LLM이 쉘 명령을 직접 실행할 수 있게 해주는 점이 중요함, 이로 인해 LLM이 인간이 쉘에서 할 수 있는 거의 모든 활동을 수행하는 단계임

  • UNIX 철학 핵심을 보면, 1) 한 가지 일만 수행하는 작은 프로그램, 2) 이들이 조합돼 더 복잡한 일을 해낼 수 있음, 3) 텍스트 스트림을 보편적 인터페이스로 사용, 이런 점이 LLM과 굉장히 잘 어울림, exec() 같은 단일 텍스트 인터페이스 덕분에 모든 도구가 파일에 작동하고 텍스트로 입출력이 가능해서 LLM이 바로 활용 가능함, 이런 소프트웨어 구조가 필연적인 것도 아닌데, 이렇게 구축된 것이 LLM에 딱 맞음

  • 상위 3개 댓글도 전부 LLM이 자기 홍보하라고 시켜서 쓴 것처럼 느껴짐

• 한때 CLI가 사라졌다는 얘기를 많이 들었지만, 최근 claude code 같은 도구 덕분에 오히려 CLI가 우월한 인터페이스가 된 상황임, 물론 이걸로 누구랑 대립 구도를 만들 생각은 없지만, 이런 판도 변화가 흥미로움

  • 사실 개발자를 포함해 숙련된 사용자 입장에선 “CLI is dead”라는 말을 들어본 적이 없음, 일반 사용자에겐 GUI가 나온 뒤 CLI가 사라진 듯 보일 수 있지만, 실제로는 항상 백그라운드에 CLI가 존재해왔음, OS X이 나오면서 진정한 Unix shell을 제공했고, Windows는 PowerShell, Linux는 아예 서버 시장을 장악한 상태임

  • 나는 커스텀 GUI 인터페이스도 직접 짓고 있음, 컴퓨터 사용 방식을 내 취향에 맞게 아예 전체 데스크톱 환경을 만들고 있음, 기존에는 주류 GUI 도구들이 불편해서 터미널을 자주 썼지만 요즘은 내 UI 환경이 점점 개선되고 있음

• Claude와 Obsidian 조합이 굉장히 좋은 워크플로우를 만들어줌, 반복적인 노트 관리 업무는 전부 AI에 맡기고 있음, 나는 데일리 노트를 스트림 오브 컨셔스니스 형태로 쌓아두고, 거기서 새 아이디어나 프로젝트, 자료들을 추출함, Gemini도 충분히 잘 작동함

• LLM과 Obsidian 통합에서 꼭 언급하고 싶은 게 바로 플러그인임, Obsidian 플러그인은 쉽게 커스터마이징 가능하고, 자바스크립트 스크립트를 로컬 폴더에서 동작시킬 수 있음, Claude Code는 이런 플러그인 작성과 수정에 뛰어남, 예를 들어, Obsidian 파일을 publish 플래그 기준으로 Github repo에 자동 동기화하는 커스텀 프로그램을 만들었고, 덕분에 노트를 갱신하면 Netlify에서 내 웹사이트가 바로 업데이트됨

• 저자는 omnara.com 같이, SSH 없이 폰에서 직접 접속할 수 있는 서비스가 더 맞을 수도 있음, 나는 Obsidian과 Claude Code를 헤드리스로 계속 켜두고 폰 앱으로 바로 접근하는 유사한 환경을 사용 중임

• Claude Code를 사용하려 하나 로컬 데이터와 파일이 얼마만큼 네트워크로 전송되는지 정확히 몰라서, 몇몇 상황에서는 도입이 어려움

• 직접 MCP로 다음과 같은 기능을 구현함
  { "name": "unshare_exec", "description": "unshare로 리눅스 네임스페이스에서 바이너리를 실행", "inputSchema": { "type": "object", "properties": { "binary": {"type": "string"}, "args": {"type": "array", "items": {"type": "string"}} }, "required": ["binary"], "additionalProperties": false } }
  처음에는 unshare만 이용하다가 yak shaving을 좀 거쳤지만, 결국에는 로컬에서 gemma3를 실행하며 debian 기반 유틸리티를 자유롭게 돌릴 수 있게 되어 놀라운 결과를 얻음

  • 혹시 그 yak의 털(준비한 자료) 공유 가능할지 궁금함, 내가 시도했던 로컬 LLM 경험은 그다지 만족스럽지 않았음

• 완전 로컬 기반의 Obsidian, 로컬 LLM, 그리고 모든 게 오픈소스인 환경을 원함, 이런 미래를 기대함

  • LLM 덕분에 오픈소스 프로그램의 활용도와 가치는 더욱 커지고 있음, 예전엔 오픈소스라 해도 코드 구조를 익히는 게 힘들어서 직접 바꾸기 쉽지 않았는데, 이제 LLM을 활용하면 작은 패치나 신규 기능 추가 같은 작업이 훨씬 쉬워짐, 즉 프로그램이 오픈소스여야 내 입맛대로 고칠 수 있고, 이 점이 그 어느 때보다 중요해짐

  • open-weights만으론 충분하지 않고, 데이터셋과 트레이닝 파이프라인까지 직접 다룰 수 있어야 진짜 의미가 있음, 물론 일반인은 트레이닝 파이프라인을 직접 돌릴 인프라가 부족하겠지만, 데이터 사용 방식과 모델 학습 과정을 투명하게 알아야 진짜 소유와 편견 평가가 가능함

  • 로컬 Org mode, 로컬 LLM, 모두 Emacs로 오케스트레이션, 전부 무료 소프트웨어로 구동되는 환경이면 너무 좋겠음, 은퇴하고 시간이 많다면 꼭 도전해보고 싶은 꿈임

  • 혹시 관심 있다면 이 글을 추천함 https://laurentcazanove.com/blog/obsidian-rag-api

  • 실제로 쓸만한 크기의 모델을 로컬에서 돌리는 게 현실적으로 불가능하지 않나 의문임, 특히 64GB RAM, 싱글 GPU 셋업 수준의 개발 머신 기준으로는 힘들 것임