Claude Code + MCP로 자동화하여 실제로 시간을 아껴준 7가지(그리고 실패한 3가지)

대부분의 "AI로 자동화한 것들" 목록은 희망 사항에 불과합니다. 그것들이 무엇이 가능한지 설명하고, 스크린샷을 찍기 위해 한 번 실행해 본 뒤, 화요일에 작동이 멈춰서 저자가 조용히 수작업으로 돌아갔다는 사실은 절대 언급하지 않습니다. 이것은 정직한 버전입니다. 다음은 제가 Claude Code + MCP로 구축했으며, 실제로 시간을 아껴주기 때문에 몇 주가 지난 지금까지도 여전히 실행 중인 자동화 사례들입니다. 각각은 명확한 트리거(Trigger), 명확한 출력(Output), 그리고 살아남은 이유를 가지고 있습니다. 그리고 — 성공 사례만 나열하는 것은 현장 보고서가 아니라 판매 문구이기 때문에 — 제가 구축하고, 측정하고, 삭제한 세 가지 사례와 그 이유도 보여드리겠습니다. 관통하는 핵심은 이렇습니다: 자동화는 그것이 절약하는 시간이 관리(babysit)하는 데 드는 시간보다 많을 때만 가치가 있습니다. 대부분의 AI 자동화는 이 테스트를 소리 없이 통과하지 못합니다. 비결은 의도적으로 이를 측정하는 것입니다.

빠른 배경 설명: MCP가 실제로 제공하는 것
이 분야가 처음이라면 — MCP (Model Context Protocol)는 Claude Code가 브라우저, 파일 시스템, 캘린더, 데이터베이스, API와 같은 작은 서버들을 통해 외부 도구 및 데이터 소스에 호출할 수 있게 해주는 표준입니다. 모델은 단순한 채팅창을 넘어 행동할 수 있는 무언가가 됩니다. Claude Code는 터미널에서 이를 구동하는 에이전트 런타임 (agent runtime)입니다. 저에게 가장 도움이 된 사고 모델은 이렇습니다: "모델이 이것을 할 수 있는가?"라고 묻지 마세요. 대신 "모델이 추측하지 않아도 되도록 내가 건네줄 수 있는 가장 작고 신뢰할 수 있는 도구는 무엇인가?"라고 물으세요. 아래의 성공 사례 대부분은 제가 영리한 프롬프트 (prompt)를 작성했기 때문이 아니라, 에이전트에게 정밀한 도구를 제공했기 때문에 얻은 결과입니다.

살아남은 7가지

1. 로그인된 페이지를 읽고 구조화된 데이터로 변환하기
   제 실제 로그인된 브라우저 세션에 연결된 브라우저 MCP (DevTools Protocol을 통해) 덕분에, 에이전트는 인증이 필요한 페이지(대시보드, 계정 페이지, 분석 페이지 등)를 읽을 수 있으며, 제가 UI를 뚫어지게 쳐다보는 대신 구조화된 데이터를 돌려줍니다. 여기서 성공 포인트는 "브라우징을 한다"가 아닙니다. 제 로그인이 필요한 페이지를 제가 아무것도 내보내지 않고도 이제 기계가 읽을 수 있는 상태로 만든다는 점입니다.
   트리거: "X에서 현재 수치를 가져와줘."
   출력: 깔끔한 표.

이것이 살아남은 이유: 대안은 내보내기 버튼이 없는 대시보드에서 제가 직접 복사하여 붙여넣는 것뿐이었습니다. 2. 제가 먼저 승인하는 계획을 통한 다중 파일 리팩터링 (Multi-file refactors) Claude Code는 디렉토리 전체를 읽고 구체적인 수정 계획을 제안하며, 제가 승인한 후에만 변경 사항을 적용합니다. 단일 파일 어시스턴트(Single-file assistant) 대비 가치는 '폭발 반경 (Blast radius)'을 파악한다는 점입니다. 즉, 제가 이름을 바꾸려는 요소를 임포트(Import)하고 있는 다른 세 개의 파일을 찾아냅니다. 승인 단계 (Approval gate)는 타협할 수 없는 원칙입니다. 저는 각 키 입력(Keystroke)이 아니라 계획을 승인합니다. 트리거: "프로젝트 전체에서 이 개념의 이름을 변경해줘." 출력: 제가 검토할 수 있는 디프 (Diff). 이것이 살아남은 이유: 제가 놓칠 수 있는 참조(References)를 잡아내며, 계획 우선 방식 덕분에 저를 놀라게 하는 일이 없습니다. 3. 실제 제 제약 사항이 반영된 템플릿을 통한 초안 작성 저는 보고서, 브리프 (Briefs), 설정 파일 (Configs) 등 정해진 형태를 따르는 반복적인 구조화된 문서들을 가지고 있습니다. 저는 에이전트에게 템플릿과 규칙(필수 섹션, 어조, 금지 사항)을 재사용 가능한 지침으로 제공했습니다. 이제 "내일 보고서 초안을 작성해줘"라고 하면, 빈 페이지 대신 제가 수정만 하면 되는 80% 완성된 결과물이 나옵니다. 트리거: 일간/주간 주기. 출력: 완성에 가까운 초안. 이것이 살아남은 이유: 지루한 80%의 작업이 바로 제가 미루는 작업이기 때문입니다. 모델은 미루지 않습니다. 4. 파일 시스템 전역 검색 및 요약 (Filesystem-wide search-and-summarize) 파일 시스템 MCP (Filesystem MCP)를 사용하면 에이전트가 지저분한 지식 베이스 전체를 그렙 (Grep)하여 "X에 대해 어디에 적었지? 그리고 결론이 뭐였지?"라는 질문에 답할 수 있습니다. 이는 결정 사항이 어느 파일에 들어있었는지 기억하기 위해 12개의 파일을 일일이 열어보던 정말 끔찍한 워크플로 (Workflow)를 대체했습니다. 트리거: "Y에 대해 내가 무엇을 결정했지?" 출력: 답변과 파일 경로. 이것이 살아남은 이유: 저의 메모를 쿼리 가능한 (Queryable) 상태로 만들어줍니다. 경로는 중요합니다. 저는 맹목적으로 믿는 것이 아니라 직접 확인하고 싶기 때문입니다. 5. 검증 루프 (Validation-loop) 양식/데이터 입력 입력을 검증하는 양식이나 시스템에 구조화된 데이터를 입력해야 할 때, 에이전트는 제가 개입하지 않아도 데이터를 입력하고, 거부 메시지를 읽고, 수정하여 다시 시도합니다. 저는 사실 관계를 제공하고, 에이전트가 노동과 오류 복구 (Error recovery)를 수행합니다.

(이것이 정확히 어디서 멈추는지에 대해서는 별도의 글을 작성했습니다. 그 경계는 타이핑 여부가 아니라 개인적인 사실과 정체성입니다.) 트리거(Trigger): "이것을 이 값들로 채워줘." 출력(Output): 완료되고 검증된 항목. 살아남은 이유: 수정 사이클(correction cycle)이 지루한 부분인데, 이제 그 일이 제 업무에서 제외되었기 때문입니다. 6. 게시되는 모든 것에 대한 읽기-다시-확인(Read-back verification). 이것은 제가 큰 코 다친 경험에서 탄생한 메타 자동화(meta-automation)입니다 (한 번에 빈 기사 4개를 게시한 적이 있는데, 긴 이야기입니다). 외부 시스템에 기록하는 모든 단계 뒤에는 이제 결과를 다시 읽어와서 그것이 정확한지 확인(assert)하는 단계가 뒤따릅니다. 에이전트가 게시한 후, 실제 결과물(artifact)을 가져와서 소스(source)와 비교(diff)합니다. 트리거(Trigger): 모든 게시/쓰기 단계. 출력(Output): "실제로 작업이 제대로 반영되었는가"에 대한 통과/실패 여부. 살아남은 이유: 200 응답을 반환하면서 쓰레기 데이터를 배포하는 침묵의 실패(silent failures)를 잡아냈기 때문입니다. 최악의 실패 모드에 대비한 저렴한 보험입니다. 7. 거친 나의 목소리가 담긴 브리프(brief)를 정해진 페르소나(persona)를 가진 초안으로 변환하기. 저는 페르소나/목소리 정의를 파일로 유지합니다. 에이전트는 적절한 파일을 로드하고 몇 개의 불렛 포인트(bullet points)를 바탕으로 해당 목소리로 초안을 작성합니다. 이점은 매번 목소리를 다시 설명할 필요 없이 많은 출력물에서 일관성을 유지할 수 있다는 것입니다. 제약 사항(constraints)이 제 머릿속이나 각 프롬프트(prompt)가 아닌 파일에 존재하기 때문입니다. 트리거(Trigger): "이것을 ~로서 초안을 작성해줘." 출력(Output): 설정된 목소리에 맞는 초안. 살아남은 이유: 콘텐츠 시리즈 전반에 걸쳐 목소리가 변하는 현상(voice drift)은 실제로 발생하며, 파일 기반의 페르소나는 이를 차단합니다. 7가지 사례의 공통 패턴은 다음과 같습니다. 이들을 다시 읽어보십시오. 살아남은 모든 사례는 동일한 형태를 가집니다: 모호한 "똑똑하게 행동해"가 아닌 정밀한 도구(특정 MCP 서버). 명확한 트리거와 명확한 결과물(artifact)이 있어, 작동 여부를 즉시 알 수 있습니다. 판단이 필요한 지점—계획 승인, 사실 제공, 최종 검토—에는 정확히 인간 게이트(human gate)를 두고, 판단이 필요 없는 모든 곳에는 완전한 자동화를 적용합니다. 성공하는 것들은 노동(labor)을 자동화합니다. 판단은 저에게 남겨둡니다. 자동화가 판단까지 소유하려 드는 순간, 그것은 절약하는 것보다 더 많은 비용을 치르게 합니다. 이것이 제가 삭제한 항목들로 이어집니다.

삭제한 3가지

삭제 1: 인간의 검토(human gate)가 없는 완전 자율형 발행
콘텐츠 파이프라인이 리뷰 없이 바로 발행하도록 시도해 보았고, 읽기 검사(read-back check)가 문제를 잡아낼 것이라 믿었습니다. 읽기 검사는 서식 오류(formatting failures)는 잘 잡아냈습니다. 하지만 "이 초안은 괜찮지만, 지금 이 시점에 말하기에는 부적절한 내용이다"라는 점은 잡아낼 수 없었습니다. 그것은 판단(judgment)의 영역이며, 저는 그 판단력을 자동화로 없애버린 셈이었습니다. 검토 단계가 없는 버전은 삭제했습니다. 읽기 검사는 유지하되, 검토 단계(review gate)를 다시 복구했습니다. 교훈: 검증(verification)은 망가진 것(broken)은 잡아낼 수 있지만, 잘못된 것(wrong)은 잡아낼 수 없습니다.

삭제 2: "모든 것을 모니터링하고 나에게 알림을 주는" 에이전트
여러 소스를 감시하다가 주목할 만한 사항이 있으면 저에게 핑(ping)을 보내는 에이전트를 만들었습니다. 그런데 끊임없이 핑이 왔습니다. 제가 완전히 명시하지 않은 맥락(context)에 따라 "주목할 만한 것"은 판단의 영역이 되기 때문에, 신호 대 잡음비(signal-to-noise ratio)가 최악이었습니다. 하루에 한 번 직접 소스를 확인하는 것보다 에이전트의 알림을 분류(triaging)하는 데 더 많은 시간을 썼습니다. 결국 삭제했습니다. 교훈: 자신의 출력물을 평가하기 위해 추가적인 업무를 생성하는 자동화는 대개 마이너스(-) 요인입니다. 폴링(polling)하고 판단(judging)하는 것은 함정입니다.

삭제 3: 과하게 설계된 "에이전트를 만드는 에이전트"
필요할 때마다 작업별 하위 에이전트(sub-agents)를 생성하는 메타 에이전트(meta-agent)를 만들려고 시도했습니다. 훌륭한 데모였지만 유지보수의 늪이었습니다. 간접 계층(layer of indirection)이 하나씩 추가될 때마다 무언가가 조용히 고장 날 수 있는 새로운 지점이 생겼고, 오류를 디버깅하려면 "어떤 에이전트가 무엇을 결정했는지"를 세 단계나 거슬러 올라가야 했습니다. 결국 한 번에 이해할 수 있는 단일 목적의 자동화 목록(flat list)으로 대체했습니다. 교훈: 간접성(indirection)은 디버깅할 때마다 영원히 지불해야 하는 비용입니다. 영리하고 중첩된(nested) 구조보다 단순하고 지루한(flat) 구조가 승리합니다.

실제로 여러분이 해야 할 일
Claude Code + MCP로 시작한다면, 인상적인 것들을 쫓지 마세요. 대신 이렇게 하세요:
판단이 아닌 노동(labor)에 해당하는, 반복적으로 수행하는 작업 하나를 고르세요. 양식 입력, 템플릿 기반 초안 작성, 검색 및 요약 같은 것들입니다. "내 전략을 결정하라"는 식은 안 됩니다. 에이전트에게 가장 작고 정밀한 도구를 부여하세요. MCP 서버 5개가 아니라 딱 하나면 충분합니다. 판단이 필요한 지점에 정확히 인간의 검토 단계(human gate)를 두고, 그 주변의 모든 것을 자동화하세요.

만약 작업이 어딘가에 무언가를 작성한다면, 다시 읽어 확인하는 단계(read-back check)를 추가하세요. 2주 동안 측정해 보세요. 만약 자동화 도구를 관리(babysitting)하는 데 드는 시간이 절약되는 시간보다 더 많다면, 미련 없이 삭제하세요. 저는 세 개를 삭제했습니다. 그것은 실패가 아니라, 측정이 제대로 작동했다는 증거입니다. 이 글의 과장된 버전이라면 10번의 성공과 삭제 사례 0건을 말하겠지만, 실제 지식은 바로 그 삭제 과정에서 나옵니다. 노동을 자동화하는 것은 수익이 됩니다. 하지만 판단(judgment), 모니터링(monitoring), 그리고 메타 오케스트레이션(meta-orchestration)을 자동화하는 것은 대부분 수익이 되지 않습니다. 적어도 아직은, 단독으로는, 그리고 절약된 비용을 조용히 갉아먹는 관리 비용(babysitting cost) 없이는 말이죠. 먼저 구축하세요. 정직하게 측정하세요. 수익이 나지 않는 것은 삭제하세요. 설계는 나중에 수렴됩니다. 그리고 그 '나중'은 보통 "당신이 영리한 것을 삭제하고, 제대로 작동하는 지루한 것을 남긴 후"를 의미합니다. — Sai

이 내용이 유용했다면: 제가 실제로 자율 에이전트(autonomous agents)를 실행하는 데 사용하는 프롬프트들을 두 개의 필드 팩(field packs)으로 구성했습니다 — '자율 에이전트를 위한 100가지 프롬프트(100 Prompts for Autonomous Agents)'와 'Claude Code 파워 유저 프롬프트(Claude Code Power-User Prompts)'. 동일한 '선 구축(build-first)' 마인드셋으로, 터미널에 바로 붙여넣을 수 있도록 준비되어 있습니다.