나는 왜 Notion MCP 대신 Notion CLI를 선택했는가

내가 해결하고 싶었던 문제는 단순하다. 직접 작성한 노트와 AI가 생성한 마크다운 문서를 효율적으로 기록하고 관리하는 것이다. 때로는 로컬 파일 시스템에 파일 형태로 존재하기도 하는 이 문서들을 관리하기 위해 처음에는 **옵시디언(Obsidian)**을 고려했다. 하지만 옵시디언의 가장 큰 문제는 ‘동기화(Sync)‘였다. 동기화를 위해 추가 비용을 지불하고 싶지 않았고, Git이나 iCloud, Google Drive를 이용한 방식은 어느 것 하나 매끄럽지 않았다. 특히 보안이 강화된 VPC 환경에서는 동기화 단계가 너무 오래 걸려 실용성이 떨어졌다.

그 다음 선택지는 **노션(Notion)**이었다. 노션은 동기화에 대한 고민을 완벽히 해결해 주었지만, 다른 문제가 있었다. 이미 구독 중인 외부 AI 서비스의 도움을 받기가 힘들었고, 대안인 ‘노션 AI’는 기능에 비해 비용이 비싸다고 느꼈다. 나에게 필요한 것은 복잡한 협업 기능이 아니라, 마크다운 내용을 생성하고 관리하는 미니멀한 기능뿐이었다.

기존 AI 서비스와 노션을 연결하기 위해 가장 먼저 떠올린 것은 **Notion MCP(Model Context Protocol)**였다. MCP Client를 지원하는 서비스에 플러그인 형태로 쉽게 연결할 수 있어 셋업은 매우 간편했다. 하지만 실제 사용해 본 Notion MCP는 내 환경에 맞지 않았다. 가장 큰 문제는 노션 MCP가 너무 **‘Heavy’**하다는 점이다. 나는 단순히 마크다운을 업로드하고 불러오는 정도의 동작을 원했는데, 노션 MCP가 제공하는 도구의 개수는 지나치게 많았다.

도구가 많다는 것은 곧 불필요한 컨텍스트(Context) 소비로 이어진다. AI 서비스가 도구를 호출하기 위해서는 list_tools 요청을 통해 모든 도구 명세서를 읽고 이를 컨텍스트에 주입해야 한다. 이 과정에서 컨텍스트가 길어지고 전체적인 추론 효율이 떨어진다. 데이터베이스 단위로 페이지를 관리하는 단순한 작업을 위해 매번 AI에게 이 무거운 명세서를 읽게 하는 것은 불필요한 오버헤드였다.

여기서 관점을 완전히 바꾸었다. AI에 도구를 ‘붙이는’ 것이 아니라, AI를 위한 **‘Agent Harness’**를 만드는 것이다. Agent Harness란 AI를 위한 일종의 ‘미니멀 OS’다. OS가 파일 시스템과 메모리 구조를 가지고 Bash 같은 도구를 제공하듯이, 에이전트의 실행 환경에 노션 조작을 위한 전용 도구와 설명서를 부여하는 것이다. 이는 단순히 도구를 호출하게 시키는 것을 넘어 에이전트 설계의 **멘탈 모델(Mental Model)**을 변화시키는 작업이다.

Agent 실행환경을 구축해서 얻는 장점은 다음과 같다

• Programmatic Control: AI의 응답 결과에만 의존하는 것이 아니라, 내가 작성한 Notion CLI를 통해 정해진 DB에 페이지 콘텐츠를 프로그램적으로 업로드한다.
• 최소한의 컨텍스트: 필요한 기능만 담은 미니멀한 인터페이스를 제공하여 AI의 컨텍스트 낭비를 막는다.
• 예측 가능한 동작: AI가 도구를 어떻게 사용할지 고민하게 만드는 것이 아니라, 내가 설계한 틀 위에서 명확하게 동작하도록 제어한다.

결국 중요한 것은 AI에게 모든 권한을 주는 것이 아니라, 에이전트가 가장 효율적으로 일할 수 있는 ‘최적의 실행 환경’을 제공하는 것이다. Notion CLI를 통한 접근은 단순한 도구 활용을 넘어, 내가 원하는 워크플로우를 코드로 고정하고 그 위에서 AI가 결과물만 얹게 만드는 가장 확실한 방법이었다.