MCP 서버 구축은 코드보다 업무 명세가 먼저입니다. 자동화할 입력과 출력, 허용할 도구, 사람의 승인 지점이 정해지지 않으면 구현이 끝나도 업무 시간이 줄었는지 판단할 수 없습니다. 이 글에서는 작은 PoC를 실행할 수 있는 한 장짜리 명세를 만듭니다.
1단계: 검증할 가설을 한 문장으로 씁니다
주간 보고서의 데이터 수집과 초안 작성을 자동화하면 회당 처리 시간을 90분에서 30분 이내로 줄이면서 숫자 오류를 현재 수준 이하로 유지할 수 있다.
“AI 업무 자동화 구축”은 가설이 아닙니다. 대상, 변화, 측정값이 포함되어야 합니다.
2단계: 입력과 출력을 고정합니다
입력: 데이터 위치, 필수 항목, 조회 기간, 문서 양식
출력: 결과 형식, 저장 위치, 알림 대상, 실패 보고 형식
PoC에서는 데이터 소스와 출력 위치를 각각 한두 개로 제한합니다.
3단계: MCP 도구를 작은 기능으로 나눕니다
MCP 서버는 도구, 리소스, 프롬프트를 제공할 수 있습니다. 도구는 한 번에 하나의 명확한 작업을 수행하도록 설계합니다.
| 도구 | 입력 | 출력 | 권한 |
|---|---|---|---|
| 데이터 조회 | 기간·지표 | 구조화된 수치 | 읽기 |
| 문서 검색 | 문서 종류·기간 | 문서와 근거 위치 | 읽기 |
| 초안 저장 | 승인된 초안 | 문서 URL | 쓰기 |
| 알림 전송 | 채널·메시지 | 전송 결과 | 외부 실행 |
4단계: 연결 방식과 인증을 선택합니다
로컬 서버는 주로 stdio, 원격 서버는 Streamable HTTP 방식이 사용됩니다. 원격 연결은 인증, 암호화, 사용자별 권한과 토큰 보관을 함께 설계해야 합니다. 제품과 SDK의 지원 범위는 구현 시점의 공식 문서를 확인합니다.
5단계: 정상보다 실패 시나리오를 먼저 테스트합니다
- 필수 입력이 없을 때 실행을 중단하는가?
- 권한이 없는 자료를 요청하면 거부하는가?
- 도구 실행이 실패하면 다음 작업을 멈추는가?
- 외부 문서의 지시를 시스템 명령으로 오인하지 않는가?
- 승인 전에는 쓰기·발송 도구가 실행되지 않는가?
- 재시도 과정에서 중복 등록되지 않는가?
6단계: 2~4주 동안 효과를 측정합니다
처리 시간, 정확도, 수정률, 누락률, 실패율을 수동 방식과 비교합니다. 사용자가 자동화 결과를 신뢰하는지와 검토 부담이 실제로 줄었는지도 확인합니다.
한 장짜리 MCP PoC 명세
자동화 대상: ________
현재 처리 시간: ________
입력 시스템: ________
필요한 도구: ________
AI가 수행할 단계: ________
사람의 승인 지점: ________
출력 시스템: ________
실패 시 처리: ________
측정 지표: ________
PoC 기간: ________
운영 전환 조건
목표 시간을 달성했더라도 권한 분리, 실행 로그, 장애 대응, 책임자가 준비되지 않았다면 운영 전환을 미룹니다. PoC의 목적은 기술 시연이 아니라 실제 업무에서 안전하게 반복할 수 있는지 확인하는 것입니다.
대상 선정은 자동화 우선순위 평가, 기술 선택은 MCP·API·RAG 비교, 권한 정책은 권한·승인 설계에서 확인하세요. 운영 전환 전에는 사내 MCP 도입 체크리스트를 사용합니다.
사례로 돌아보기: 실제 입력·출력 명세는 보고서 자동화 설계를 참고하세요.
참고: MCP 공식 SDK, MCP 아키텍처
0 댓글