LeanX

커스텀 MCP로 교차 검증 & 시간 자동화

한 모델이 세운 플랜을 커스텀 MCP를 통해 다른 모델에게 리뷰시키면 사각지대를 줄이는 교차검증 효과를 얻을 수 있고, 이 과정을 스킬로 자동화하며, 이벤트에 반응하는 훅과 달리 /loop·스케줄은 '5분마다'처럼 시간을 기준으로 반복한다는 점에서 서로를 보완합니다.

지금까지의 오케스트레이션은 모두 클로드 안에서 이뤄졌습니다. 이번 레슨은 그 경계를 넘어, 아예 다른 모델을 오케스트레이션에 끌어들입니다. 핵심 아이디어는 단순합니다. 한 모델이 세운 플랜에는 그 모델 특유의 사각지대가 있기 마련이니, '다른 눈'에게 검토시켜 그 사각지대를 줄이자는 것입니다.

교차 검증 — 다른 모델을 리뷰어로

사람도 자기 글의 오타는 잘 못 봅니다. 모델도 마찬가지로, 자기가 세운 계획의 허점은 잘 못 봅니다. 여기서 커스텀 MCP가 등장합니다. 예를 들어 제미나이(Gemini)를 호출하는 작은 MCP 서버를 만들어 두면, 클로드가 세운 플랜을 그 서버에 넘겨 '빠진 부분과 리스크를 지적해 달라'고 시킬 수 있습니다. 두 모델이 한 플랜을 검증한 셈이 됩니다.

그런데 이 커스텀 MCP조차 손으로 만들 필요가 없습니다. 서버 코드 작성부터 settings.json 등록까지 프롬프트로 시키면 됩니다.

커스텀 MCP도 프롬프트로 — 만들고 등록까지

제미나이 API를 호출해 '플랜 리뷰'를 해 주는 작은 MCP 서버를 만들어 줘.
- 입력: 플랜 텍스트 / 출력: 빠진 부분·엣지케이스·리스크 목록
- API 키는 코드에 박지 말고 환경 변수(GEMINI_API_KEY)로 받게 해 줘
- 서버 코드를 작성한 뒤, 이 프로젝트의 .claude/settings.json(mcpServers)에 등록하고 /mcp로 연결을 확인하는 방법까지 알려 줘.
키가 필요하면 나에게 물어봐 줘.

교차 모델 플랜 리뷰 흐름

  • 클로드가 플랜 작성 plan 모드로 작업 계획을 세움
  • 커스텀 MCP로 전달 플랜을 다른 모델(예: 제미나이) 리뷰 서버에 넘김
  • 교차 리뷰 회수 빠진 부분·엣지케이스·리스크 지적을 받아옴
  • 강화된 플랜 지적을 반영해 클로드가 플랜을 보강한 뒤 구현 시작

한 모델의 초안을 다른 모델이 감수하는 구조입니다. 구현 전에 사각지대를 걷어내므로, 나중에 뒤엎는 비용을 크게 줄입니다.

교차 리뷰 요청 프롬프트

방금 세운 구현 플랜을 [교차리뷰 MCP]에 넘겨서 다른 모델의 검토를 받아 줘.
리뷰어에게 이렇게 요청해:
1. 이 플랜이 놓친 엣지 케이스나 예외 상황은?
2. 숨은 의존성이나 순서상의 위험은?
3. 더 단순하게 갈 수 있는 부분은?

리뷰 결과를 받으면, 타당한 지적만 골라 플랜에 반영하고
무엇을 왜 받아들였는지(또는 왜 무시했는지) 짧게 정리해 줘.

이 과정 전체를 커스텀 스킬로 굳혀 두면, 앞으로는 '이 플랜 교차검증해줘' 한 마디로 같은 절차가 반복 실행됩니다. 3강의 스킬 저작과 이 레슨의 MCP가 여기서 만나는 셈입니다 — 스킬이 '언제 이 절차를 쓸지'를 알고, MCP가 '무엇과 연결해 실행할지'를 담당합니다.

이벤트 기반 훅 vs 시간 기반 loop/schedule

자동화에는 두 가지 방아쇠가 있습니다. 앞 레슨의 훅은 '무슨 일이 벌어지면'(도구 실행, 세션 종료) 반응하는 이벤트 기반입니다. 반면 /loop나 스케줄 기능은 '얼마의 시간이 지나면'(5분마다, 매일 새벽) 스스로 도는 시간 기반입니다. 둘은 경쟁이 아니라 쓰임이 다릅니다.

두 가지 자동화 방아쇠

이벤트 기반 — 훅

  • 방아쇠: 특정 동작이 일어날 때
  • 예: 파일 수정 직후 포맷, 세션 종료 시 정리
  • 성격: 무언가에 '반응'한다
  • 적합: 작업 흐름에 붙는 즉각적 뒷처리

'~하면 ~한다'

시간 기반 — loop/schedule

  • 방아쇠: 정해진 시간·주기가 될 때
  • 예: 5분마다 배포 상태 확인, 매일 지표 점검
  • 성격: 스스로 '반복'한다
  • 적합: 지켜보기·주기적 점검 같은 상시 감시

'매 N분마다 ~한다'

훅은 작업에 곁들이는 반사신경, loop/schedule은 시계를 보고 도는 심장박동입니다. 큰 파이프라인에는 둘 다 필요합니다.

예를 들어 '배포를 시작한 뒤 5분마다 상태를 확인하고, 실패하면 알려 줘' 같은 지시는 시간 기반 반복(loop/schedule)으로 굴리고, 그 안에서 '실패 감지 시 Slack 알림'은 앞 레슨의 알림 훅으로 처리하는 식으로 엮을 수 있습니다.

교차검증은 '모든 작업'이 아니라 '되돌리기 비싼 결정'에만 쓰세요. 스키마 변경, 결제 로직, 대규모 리팩터 같은 곳에 교차 리뷰를 걸면 투자 대비 효과가 큽니다. 사소한 수정까지 매번 두 모델을 태우면 시간과 비용만 늡니다.

시간 기반 자동 반복에는 반드시 '정지 조건'과 '검증 게이트'를 두세요. 정지 조건 없는 반복은 그냥 계속되는 리스크입니다 — 목표 달성, 최대 횟수, 최대 시간 중 무엇으로 멈출지 미리 정하세요. 그리고 커스텀 MCP에 쓰는 다른 모델의 API 키는 절대 코드에 박지 말고 환경변수로 관리해야 합니다.

이제 다섯 부품이 모두 준비됐습니다. 스킬·서브에이전트·에이전트팀·훅·커스텀MCP. 마지막 레슨에서는 이 전부를 하나의 시나리오로 엮어, 1인 개발자가 반나절짜리 일을 30분으로 줄이는 풀 파이프라인을 직접 따라가 봅니다.