• 7개의 Notion 자동화 중 4개를 주말 동안 MCP 서버로 마이그레이션함

• 두 개의 워크플로우는 데이터베이스 UI가 그 어떤 도구 호출 (tool call)보다 뛰어나기 때문에 Notion에 그대로 유지함

• MCP 범위 규칙: 하나의 도구는 하나의 동사만 수행하며, 결코 맥가이버 칼 (Swiss Army) 같은 다기능 함수가 되어서는 안 됨

• 결과: 게시당 12단계의 수동 작업이 3개의 Claude 프롬프트로 압축됨

저는 주말 동안 4개의 자동화 기능을 Notion에서 추출하여 MCP 도구로 재구축하는 데 시간을 보냈습니다. 그중 3개는 더 빨라졌고, 하나는 더 좋아지기 전에 잠시 나빠졌습니다. 가장 큰 교훈은 코드에 관한 것이 아니었습니다. 애초에 어떤 작업들이 Notion을 절대 떠나서는 안 되는지를 결정하는 것에 관한 것이었습니다.

애초에 왜 Notion을 벗어나려 했는가

제 Notion 설정은 고장 난 상태가 아니었습니다. 단지 특정한 방식으로 느릴 뿐이었습니다. 저는 Notion 버튼, 수식 속성 (formula properties), 그리고 두 개의 서드파티 커넥터 (third-party connectors)를 사용하여 7개의 자동화를 엮어 놓았습니다. 블로그를 게시할 때마다 네 개의 페이지를 클릭하며 여기에서 제목을 복사하고, 저기에서 태그 목록을 붙여넣고, 확인까지 90초가 걸리는 동기화를 트리거해야 했습니다. 이를 평범한 한 달에 발행하는 18개의 기사에 곱해보면, 클릭 횟수가 상당합니다.

임계점은 어느 화요일에 찾아왔습니다. 조용히 작동을 멈춰버린 커넥터 때문에 40분을 허비했습니다. 에러도, 로그도 없었고, 그저 업데이트되지 않는 행(row) 하나가 있을 뿐이었습니다. 커넥터 대시보드를 확인해보니 모든 것이 정상이라고 나왔습니다. 하지만 정상적이지 않았습니다. 그런 종류의 보이지 않는 실패는 가장 최악입니다. 왜냐하면 믿고 있다가 믿지 못하게 될 때까지 알 수 없기 때문입니다.

MCP는 저에게 계산법을 바꾸어 놓았습니다. MCP 서버를 사용하면 Claude가 제가 만든 함수를 직접 호출할 수 있습니다. Claude가 텍스트를 쓰고 제가 그 텍스트를 수동으로 Notion에 옮기는 대신, Claude가 제 시스템에 글을 쓰는 도구를 직접 호출할 수 있습니다. 모델이 단순한 작가가 아니라 운영자 (operator)가 되는 것입니다. MCP가 실제로 무엇인지, 그리고 규모가 커질 때 왜 중요한지에 대한 더 깊은 맥락을 알고 싶다면, MCP: The 97 Million Agentic Foundation에서 더 큰 그림을 살펴볼 수 있습니다.

그래서 저는 목록을 만들었습니다. 각 자동화에 인간의 판단이 얼마나 필요한지에 따라 일곱 가지를 분류했습니다. 상단에 있는 것들은 순수하게 기계적인 단계였습니다: 이것을 포맷하고, 저것을 푸시하고, 상태를 가져오는 작업들 말이죠. 하단에 있는 것들은 제가 무언가를 보고 결정해야 하는 것들이었습니다. 금요일 밤에 커피 한 잔과 함께 수행한 그 분류 작업은 결국 주말 동안 제가 한 일 중 가장 가치 있는 일이 되었습니다. 그 작업 덕분에 어떤 4개를 재구축하고 어떤 3개를 그대로 둘지 정확히 알 수 있었습니다. 그 분류가 완벽했다고 거짓말하지는 않겠습니다. 유지했어야 할 워크플로우 하나를 옮겨버렸는데, 그 실수는 나중에 다루겠습니다. 왜냐하면 그 실수가 저에게 진정한 범위 규칙 (scope rule)을 가르쳐 주었기 때문입니다.

MCP 도구가 된 4개의 워크플로우

네 가지 자동화는 기계적이고 반복 가능했기 때문에 도구로서 타당했습니다. 각각이 어떻게 변했는지 소개합니다.

첫째, 발행 포맷터 (publish formatter)입니다. Notion에서는 이것이 TLDR 문자열과 태그 목록을 생성하는 수식 (formula) 속성이었습니다. MCP 도구로서 이것은 초안을 받아 이미 구조가 강제된 깔끔한 마크다운 (markdown)을 반환하는 하나의 함수가 되었습니다. Claude가 이를 호출하여 검증된 출력을 받아오며, 저는 더 이상 수식을 만질 필요가 없습니다. 이것만으로도 기사당 약 6분을 절약했습니다.

둘째, 상태 가져오기 (status fetcher)입니다. 예전에는 어떤 기사가 라이브 상태인지, 예약되었는지, 혹은 멈춰 있는지 확인하기 위해 데이터베이스 뷰를 열어야 했습니다. 이제 Claude는 3초 만에 동일한 목록을 반환하는 도구를 호출합니다. 탭을 전환할 필요가 없습니다. 이 도구는 동일한 신뢰할 수 있는 소스 (source of truth)로부터 읽어오며, 단지 데이터를 제 눈 대신 모델에게 전달할 뿐입니다.

셋째, 소셜 스케줄러 푸시 (social scheduler push)입니다. 기존 설정은 게시물 텍스트를 커넥터가 감시하는 Notion 테이블에 쏟아붓는 방식이었습니다. 이제 MCP 도구는 API를 통해 Buffer로 게시물을 직접 보냅니다. Claude가 세 가지 변형을 초안으로 작성하면, 제가 하나를 선택하고, 도구가 이를 대기열에 추가합니다. 더 이상 감시할 중간 테이블이 없기 때문에 90초간의 동기화 대기 시간도 사라졌습니다.

넷째, 이미지 프롬프트 빌더(image prompt builder)입니다. 이 도구는 제품 설명을 가져와서 이미지 도구에 바로 붙여넣을 수 있는 구조화된 프롬프트(structured prompt)를 반환합니다. 저는 업스케일링(upscaling)을 위해 Magnific을 통해 이러한 프롬프트들을 많이 실행하기 때문에, 처음부터 프롬프트의 형태를 제대로 잡는 것이 중요합니다. 이 도구는 종횡비(aspect ratio)와 스타일 노트를 강제하므로, 제가 이를 잊어버리는 일을 방지해 줍니다.

네 가지 워크플로우 전체에 걸친 패턴은 다음과 같습니다. 입력을 받고, 하나의 변환(transformation)을 수행한 뒤, 출력을 반환합니다. 판단이 필요하지 않습니다. 이것이 MCP 도구의 최적점(sweet spot)입니다. 만약 어떤 작업이 "X가 주어지면, 매번 Y를 생성한다"라고 설명될 수 있다면, 그것은 도구에 속해야 합니다. 작업에 제가 직접 보고 결정해야 하는 순간이 생기는 즉시, 그 도구는 적절한 거처가 아니게 됩니다. 저는 이 각각을 하나의 커다란 핸들러(handler)가 아닌 별개의 함수(function)로 구축했으며, 이 결정이 다음 섹션의 핵심입니다.

범위 규칙: 하나의 도구, 하나의 동사

제가 만든 첫 번째 버전의 MCP 서버에는 manage_content라는 하나의 거대한(fat) 도구가 있었습니다. 이 도구는 action 파라미터를 받았습니다. "format", "fetch", "schedule", "build_prompt"와 같은 식이었죠. 저는 이를 깔끔하게 유지함으로써 영리하게 행동하고 있다고 생각했습니다. 하지만 그것은 어리석은 생각이었습니다.

문제는 Claude가 이를 처음 호출했을 때 나타났습니다. 모델은 자신이 어떤 액션을 원하는지 추측해야 했고, 해당 액션에 맞는 선택적 파라미터(optional parameters)의 조합을 채워 넣어야 했으며, 적용되지 않는 파라미터들은 무시해야 했습니다. 모델은 혼란에 빠졌습니다. fetch 액션에 태그 리스트를 전달했는데 이는 아무런 동작도 하지 않았고, 모델은 마치 fetch가 실패한 것처럼 행동했습니다. 도구 설명(tool description)은 한 단락 안에 네 가지 서로 다른 작업을 설명해야 했고, 모델은 약 3분의 1의 확률로 잘못된 분기(branch)를 선택했습니다.

그래서 저는 이를 분리했습니다. 네 개의 도구, 네 개의 동사: format_draft, fetch_status, schedule_post, build_image_prompt. 각각은 정교한 설명과 소수의 필수 파라미터(required parameters) 세트를 가집니다. 오류율은 거의 0에 가깝게 떨어졌습니다. Claude는 네 가지 명확한 옵션을 읽고 당연한 것을 선택합니다. 왜냐하면 각 작업당 당연한 선택지는 단 하나뿐이기 때문입니다.

그것이 바로 제가 금요일에 누군가에게 들었으면 좋았을 범위 규칙 (scope rule)입니다. 즉, 하나의 도구는 하나의 동사만을 수행해야 한다는 것입니다. 만약 당신이 액션 파라미터 (action parameter)를 추가하고 있다면, 당신은 사실 트렌치코트를 입고 정체를 숨긴 여러 개의 도구를 하나로 뭉쳐놓은 상태입니다. 그것들을 분리하세요. 모델은 하나의 넓은 도구보다 좁은 범위의 도구 목록을 통해 더 잘 추론합니다. 왜냐하면 각 도구의 이름과 설명이 서랍에 붙은 라벨처럼 작동하기 때문입니다. 넓은 도구는 모델로 하여금 캐비닛 전체를 읽도록 강요합니다.

여기에는 비용이 따릅니다. 도구가 많아진다는 것은 유지 관리해야 할 설명이 많아지고, 매 요청마다 도구 목록이 길어진다는 것을 의미합니다. 하지만 그 트레이드오프 (tradeoff)는 분리하는 쪽으로 압도적으로 기울어져 있습니다. 조용히 실패하는 혼란스러운 모델은 약간 더 긴 도구 목록보다 훨씬 더 비용이 많이 듭니다. 저는 3분의 1의 확률로만 나타나는 잘못된 분기 버그 (wrong-branch bug)를 쫓느니, 차라리 호출당 몇 개의 토큰을 더 지불하겠습니다.

이 규칙의 나머지 절반은 명명 (naming)입니다. fetch_status는 모델에게 무엇이 반환되는지 정확히 알려줍니다. get_data는 그렇지 못합니다. 저는 실제 함수 본문 (function bodies)보다 도구의 이름과 설명에 더 많은 시간을 할애했으며, 그 비율이 적절하다고 느꼈습니다. 설명은 Claude가 추론하는 인터페이스 (interface)입니다. 제가 의존하는 전체 설정 패턴에 대해서는, Claude Blueprint에서 제가 이러한 프로젝트를 처음부터 끝까지 어떻게 구조화하는지 설명하고 있습니다.

Notion에 남겨둔 것들과 그 이유

세 가지 워크플로우 (workflows)는 Notion에 남겨두었으며, 그렇게 하길 잘했다고 생각합니다. 첫 번째는 저의 편집 캘린더 (editorial calendar)입니다. 이것은 보드 뷰 (board view)가 있는 데이터베이스로, 저는 아이디어 (idea), 초안 작성 (drafting), 준비 완료 (ready), 발행됨 (published) 열 사이로 기사 카드들을 드래그합니다. 그 드래그 앤 드롭 (drag-and-drop)은 어떤 도구 호출 (tool call)보다 빠릅니다. 왜냐하면 그 가치가 시각적이기 때문입니다. 저는 보드를 보고 아이디어는 너무 많고 준비된 초안은 부족하다는 것을 즉각적으로 파악합니다. MCP 도구가 해당 데이터를 텍스트로 반환할 수는 있겠지만, 텍스트의 벽은 보드가 주는 것과 같은 직관적인 파악 (gut read)을 제공하지 못합니다. 여기서 UI가 곧 기능입니다.

두 번째는 저의 리서치 클립보드 (research clipboard)입니다. 저는 링크, 스크린샷, 그리고 미완성된 메모들을 발견하는 대로 Notion 페이지에 쏟아붓습니다. 이는 의도적으로 무질서하게 설계되었습니다. 무엇을 가지고 있는지 알기 전에 캡처하는 것이 핵심이기 때문에 강제되는 구조가 없습니다. 비구조화된 캡처 (unstructured capture)를 중심으로 도구를 만들려고 시도하는 것은 그저 저의 속도를 늦출 뿐입니다. Notion의 빠른 추가 (quick-add) 기능은 이미 두 번의 탭으로 충분합니다. 그 무엇도 이를 능가할 수 없습니다.

세 번째는 제가 이전하려고 시도했다가 후회한 것입니다. 저의 아이디어 점수 산정 (idea-scoring) 워크플로우는 Notion 수식 (formula)을 사용하여 몇 가지 가중치 요인에 따라 기사 아이디어의 순위를 매겼습니다. 저는 이를 위해 MCP 도구를 구축했고, 기술적으로는 작동했습니다. 하지만 아이디어에 점수를 매길 때는 제가 그 숫자를 보고 절반 정도는 거부해야 했습니다. 왜냐하면 수식은 제가 무엇을 쓰는 것에 지루함을 느끼는지 알지 못하기 때문입니다. 도구가 점수를 반환하면, 저는 그냥 그것을 빤히 바라보다가 결국 제 방식대로 결정하곤 했습니다. 즉, 도구가 단계를 제거하는 대신 오히려 단계를 추가한 셈입니다. 저는 모든 점수를 표 (table)에서 한눈에 보고 정렬할 수 있는 Notion으로 그것을 다시 옮겼습니다.

이 실패는 프로젝트 전체를 명확하게 해주었습니다. 도구는 결과물이 최종적인 작업 (tasks)을 위한 것입니다. Notion은 제가 여전히 생각 중인 작업들을 위한 것입니다. 워크플로우가 결과물을 보고 결정하는 과정을 포함하는 순간, 데이터베이스 뷰 (database view)가 승리합니다. 모든 것을 한 번에 보여주기 때문입니다. 도구는 저에게 하나의 답을 건네지만, 정렬된 표는 저에게 전체 영역을 건네줍니다. 저는 Shopify에서 제품 파이프라인을 재구축했을 때 이러한 분리의 상점 측면을 더 심도 있게 다루었는데, 거기에도 동일한 논리가 적용되었습니다: 기계적인 것은 자동화하고, 판단 (judgment)이 필요한 것은 시각적으로 유지하는 것입니다.

핵심 요약 (Bottom Line)

이번 주말을 통해 게시물 하나당 12단계의 수동 작업이 3개의 Claude 프롬프트 (prompts)로 바뀌었습니다. 그리고 승리한 것은 코드가 아니었습니다. 그것은 바로 '선별'이었습니다. 어떤 4개의 워크플로우를 옮기고 어떤 3개를 그대로 둘지 아는 것이, 이번 재구축을 좌절이 아닌 빠른 작업으로 만들어 주었습니다.

이 과정에서 한 가지만 기억한다면, 그것은 바로 범위 규칙(scope rule)입니다: 하나의 도구에는 하나의 동사(one tool, one verb)만 사용하세요. 동작 파라미터(action parameter)를 가진 비대한 도구는 깔끔해 보일 수 있지만, 논리적으로는 매우 엉망입니다. 명확한 이름을 가진 좁은 범위의 도구들로 분리하면 오류율은 자연스럽게 낮아집니다. 그리고 무엇인가를 마이그레이션(migrate)하기 전에, 그 작업에 당신의 눈이 필요한지 자문해 보세요. 만약 그렇다면, 전체 상황을 한눈에 볼 수 있는 뷰(view)에 그대로 두어야 합니다.

저는 여전히 서버를 조정하고 있습니다. 두 개의 워크플로우가 추가 후보군이지만, 그것들이 판단(judgment calls)을 가장한 것이 아니라 정말 기계적인 작업인지 확신이 들 때까지 기다리고 있습니다. 제가 이 모든 것을 구축할 때 기반으로 삼은 토대를 원하신다면, Claude Blueprint에서 제가 사용하는 패턴들을 확인하실 수 있습니다. 하나의 도구로 시작하여 배포하고, 발생하는 마찰(friction)을 통해 다음에 무엇을 만들지 결정하세요.

이 기사에는 제휴 링크가 포함되어 있습니다. 이 링크를 통해 가입하시면, 귀하에게 추가 비용 부담 없이 저에게 소정의 수수료가 지급될 수 있습니다. (광고)