연재: AI에게 일자리를 빼앗길 불안에서 시작하는 하네스(Harness) 작성 입문 제7회 - MCP 서버를 '도구 상자'로 분할하는 사고방식

연재: AI에게 일자리를 빼앗길 불안에서 시작하는 하네스(Harness) 작성 입문

전 24회 (주 2회 · 12주간) | 제7회 / 24

이 연재는 AI에게 일자리를 빼앗길지도 모른다는 불안을 '하네스(AI 에이전트 제어 메커니즘)'를 직접 만드는 행동으로 바꾸는 시리즈입니다.

"MCP 서버를 어떻게 분할해야 할지 모르겠다" —— 이는 마이크로서비스 설계에서도 오랫동안 논의되어 온 문제입니다.

지난 회차(제6회)에서 디렉터리 구성을 만들었지만, 그 안의 mcp_servers/에 무엇을 둘 것인가가 다음 과제입니다. SE(시스템 엔지니어) 경험자라면 '모듈 분할'이나 '책임 분리(Separation of Concerns)'의 사고방식에 익숙할 것입니다. 그 경험을 MCP 서버 분할에 활용해 봅시다.

• SE · 프로그래머 경험 3년 이상인 분
• 모듈 분할이나 마이크로서비스 경험이 있는(또는 관심이 있는) 분
• MCP 서버를 어떻게 나눌지 고민 중인 분
• 지난 연재를 읽어온 분 (읽지 않았어도 OK)

MCP 서버의 분할은 SE가 일상적으로 수행하는 '책임 분리'의 사고방식 그대로입니다. '1개의 MCP 서버에 1개의 책임'을 원칙으로 하되, 프로젝트의 규모나 페이즈(Phase)에 따라 유연하게 조정하는 것이 현실적입니다.

MCP 서버 분할을 잘못하면 다음과 같은 문제가 발생합니다.

거대 서버 문제: 1개의 MCP에 모든 기능을 담으면 수정 시 영향 범위가 넓어짐 -
과도한 분할 문제: 너무 세밀하게 분할하면 MCP 간의 연동 비용이 증가함 -
모호한 경계 문제: 어떤 기능이 어느 MCP의 책임인지 불명확하면 중복이나 누락이 발생함

SE라면 이러한 문제들이 '모놀리식(Monolithic) 시스템 vs 마이크로서비스'의 논의와 같다는 것을 깨달을 것입니다.

SE 경험	MCP 분할에의 활용
클래스의 책임 분리 (SRP)	1 MCP = 1 책임의 원칙
...

MCP 서버를 '도구 상자'라고 생각하면 분할 판단이 쉬워집니다.

드라이버 세트 (나사를 돌리는 도구): 데이터를 조작하는 MCP -
톱 세트 (나무를 자르는 도구): 콘텐츠를 생성하는 MCP -
측정 도구 (재는 도구): 품질을 검증하는 MCP -
수납함 (물건을 보관하는 도구): 지식을 기록 · 검색하는 MCP -

실제 하네스에서의 분할 사례를 살펴봅시다.

다음은 이 연재의 하네스에서 실제로 사용하고 있는 MCP 서버 책임표입니다.

MCP 서버	책임	주요 도구 (입력)	주요 출력	도구 상자 카테고리
article_mcp	기사 작성 · 관리	테마, 브리프, 아웃라인	Markdown 기사	톱 세트
...

"이 MCP를 분리해야 할까?"라고 고민될 때의 판단 기준을 제시합니다.

변경 빈도가 다르다 → 분리해야 함 (예: 기사 작성과 게시물 등록은 조합이 바뀌기 쉬움) -
데이터의 소유자가 다르다 → 분리해야 함 (예: 지식 데이터와 기사 데이터는 별도 관리) -
스케일이 다르다 → 분리해야 함 (예: 검색은 무겁지만 기사 생성은 가벼움) -
항상 함께 사용한다 → 묶어도 됨 (예: 리뷰와 Markdown 검증은 동일한 MCP여도 무방) -
팀이 다르다 → 분리해야 함 (예: 프론트엔드와 백엔드)

주의점	이유	대책
처음부터 너무 세밀하게 나누지 말 것	개인 개발에서 MCP가 10개나 있으면 관리가 불가능함	3~5개 정도부터 시작할 것
...

• 자신의 하네스에 필요한 MCP 서버를 3~5개 적어보기
• 각 MCP에 '책임', '주요 도구', '입출력'을 정의하기 (MCP 책임표)
• MCP 간의 데이터 흐름을 화살표로 그려보기
• 순환 의존(Circular Dependency)이 없는지 확인하기
• (발전) '도구 상자 카테고리'로 분류해 보기

이번에는 MCP 서버의 분할을 '도구 상자' 메타포로 생각하는 방법을 제시했습니다.

키 포인트

• MCP 분할은 SE의 '책임 분리' 경험을 그대로 사용할 수 있음
• '1 MCP = 1 책임'을 원칙으로, 3~5개부터 시작할 것
• '도구 상자' 개념으로 분류하면 역할이 명확해짐
• 분할의 판단 기준은 '변경 빈도', '데이터 소유자', '스케일'의 차이
• 처음부터 완벽한 분할을 목표로 하지 말고 정기적으로 재검토할 것

**제8회 「MCP 서버의 최소 구현 — FastMCP로 첫 번째 도구 만들기」**에서는 이번에 설계한 책임표를 '동작하는 코드'로 구현합니다.

• FastMCP를 사용한 MCP 서버의 최소 구현

• health_check + 업무 도구 1개의 구현 예시

• 도구의 시그니처 (Signature) 설계 (타입 힌트 (Type Hint) · docstring · 기본값)

• 동작하는 최소 MCP 서버 (health_check + create_article_project)

• 이번 MCP 책임표를 곁에 두기 (다음 회차에서 article_mcp의 첫 번째 도구를 구현합니다)

• Python 가상 환경 (venv) 준비하기

• pip install mcp로 FastMCP 설치해 두기

회차	제목	상태
제1회	「AI에게 일을 빼앗긴다」는 불안의 정체를 분해하기	✅
...
연재: AI에게 일을 빼앗길 불안에서 시작하는 하네스(Harness) 작성 입문

저자: @and-and-and ｜ 주 2회 업데이트

다음 회차는 「MCP 서버의 최소 구현 — FastMCP로 첫 번째 도구 만들기」를 예정하고 있습니다.