MCP 서버의 진짜 역할은 API 연결이 아니라 실행 경계다
MCP를 붙였는데도 에이전트가 “그래서 지금 무엇을 해야 하나?”에 답하지 못한다면, 문제는 도구의 개수가 아니라 실행 경계의 부재일 수 있다. 이 글은 API wrapper와 운영 workflow를 가르는 기준을 정리하고, 작은 실험으로 적용하는 방법을 설명한다.
TL;DR
- 운영 판단은 원시 지표를 조회하는 일과 다르다.
- MCP 도구는 데이터뿐 아니라 상태, 정책, 다음 행동의 조건을 전달해야 한다.
- 제안과 실제 실행 권한을 분리하고, 완료 증거를 반환해야 중복 실행을 줄일 수 있다.
- 모든 도구를 두껍게 만들 필요는 없다. 판단이 필요한 좁은 workflow부터 경계를 설계하면 된다.
왜 지금 중요한가
MCP는 기존 API를 에이전트가 호출할 수 있게 만드는 자연스러운 출발점이다. 하지만 운영 현장에서 사용자가 원하는 질문은 “CPU 사용률을 보여줘”보다 “지금 서버가 괜찮은가, 무슨 일이 일어났고, 다음에 무엇을 해야 하는가”에 가깝다.
이 질문은 단순한 데이터 조회가 아니라 판단 workflow다. 신호 수집 기준, 예외 정책, 상태 분류, 액션 권한, 완료 증거가 함께 필요하다. API를 도구로 포장하는 것만으로는 이 책임이 사라지지 않는다. 책임이 MCP client의 프롬프트와 모델 판단 속으로 흩어질 뿐이다.
핵심 관점: MCP의 차별화는 연결 가능한 도구 수가 아니라, 잘못된 실행을 줄이는 경계의 명확성이다.
핵심 흐름: wrapper에서 boundary로
1. 원시 신호를 그대로 노출하지 않는다
원시 지표는 풍부하지만 판단을 대신하지 않는다. get_cpu_usage 같은 도구는 값을 반환할 뿐, 어떤 시간창을 봐야 하는지, 어떤 신호와 함께 해석해야 하는지 알려주지 않는다.
단순 조회라면 얇은 wrapper가 충분하다. 그러나 장애 대응처럼 여러 신호를 묶어야 하는 작업이라면, 도구의 출력이 다음 판단에 필요한 맥락까지 포함해야 한다.
2. 상태 계약을 만든다
운영 workflow에는 최소한 다음과 같은 상태가 필요하다.
healthy: 기준선 안에 있음degraded: 이상 신호가 있으나 추가 관찰이 필요함incident: 정책상 대응이 필요한 상태unknown: 데이터가 부족하거나 신호가 충돌함
unknown을 숨기지 않는 것이 중요하다. 모르는 상태를 정상으로 포장하면 에이전트는 가장 위험한 종류의 자신감을 만든다.
3. 다음 행동과 권한을 분리한다
MCP server는 “재시작하라”가 아니라 “재시작 후보이며, 이 근거와 조건이 충족되어야 한다”를 반환할 수 있다. 실제 실행은 별도의 권한, 승인, 중복 방지 계약을 통과해야 한다.
이 분리를 해두면 에이전트는 관찰과 제안을 빠르게 수행하면서도, 영향이 큰 변경은 더 엄격한 레인으로 보낼 수 있다.
4. 완료 증거를 반환한다
API 호출 성공과 workflow 완료는 다르다. 실행 ID, 변경된 상태, 검증 시각, 실패 이유를 결과에 포함해야 한다. 그래야 에이전트가 같은 작업을 다시 실행하지 않고, 사용자가 무엇이 실제로 끝났는지 확인할 수 있다.
실제 사례에서 본 신호
최근 공유된 MCP incident triage 사례는 단순한 metric 조회를 넘어 원시 신호를 모으는 기준과 운영 정책을 적용하고, 전체 상황을 판단해 다음 행동을 제안해야 한다는 문제를 제기한다. 핵심은 MCP server가 어디까지 책임져야 하는가다.
또 다른 방향은 작은 에이전틱 모델이다. GeekNews에 소개된 Needle 2는 범용 대화보다 도구 호출, 기기 제어, 구조화 추출에 집중하는 소형 모델로 소개됐다. 이 사례가 보여주는 가능성은 분명하다. 모든 판단을 큰 모델 하나에 맡기기보다, 좁은 계약을 정확히 실행하는 구성요소를 조합할 수 있다는 점이다.
다만 특정 모델의 성능과 비용은 평가 조건과 시점에 따라 달라진다. 제품 설계에서는 모델 이름보다 입력 계약, 실패 처리, 검증 결과를 먼저 고정하는 편이 안전하다.
실전 활용 팁: 실행 경계를 설계하는 체크리스트
MCP 도구나 AI 유틸을 만들 때 다음 질문을 출력 계약에 넣어본다.
| 질문 | 좋은 경계의 형태 |
|---|---|
| 무엇을 읽는가? | 신호와 시간창, 출처가 명시됨 |
| 어떻게 판단하는가? | 정책·임계값·예외가 보임 |
| 무엇을 할 수 있는가? | 제안과 실제 실행 권한이 분리됨 |
| 언제 끝났는가? | 상태·실행 ID·검증 증거가 반환됨 |
| 모르면 어떻게 하는가? | unknown과 추가 확인 경로가 존재함 |
이 기준은 서버 운영에만 적용되지 않는다. SQL을 ERD로 변환하는 유틸이라면 입력 SQL, 추론한 관계, 검증되지 않은 부분, 사용자가 수정한 내용, export 완료 상태를 함께 보여줄 수 있다. 결과물만 내놓는 대신 판단 경로를 남기는 것이다.
바로 해볼 실험
처음부터 운영 플랫폼 전체를 만들 필요는 없다. 판정이 쉬운 좁은 workflow를 고른다.
- 입력과 출력이 명확한 작업 하나를 선택한다.
- 결과에
status,reason,next_action,evidence필드를 추가한다. - 정상·실패·정보 부족 세 가지 입력을 준비한다.
- 실제 실행 없이 제안만 하는 모드와 실행 모드를 분리한다.
- 같은 요청을 두 번 보냈을 때 중복 실행을 막고, 그 결과를 로그에 남긴다.
1~3일이면 충분하다. 이 실험의 목표는 모델의 말솜씨가 아니라, 에이전트가 모르는 상태를 드러내고 실제 완료를 구분하는지 확인하는 것이다.
리스크 / 반론
서버에 판단 책임을 과도하게 넣으면 MCP가 특정 client에 종속될 수 있다. 여러 환경에서 재사용할 수 있는 상태·정책·증거와 제품별 orchestration은 분리해야 한다.
반대로 모든 workflow가 server-side decision을 필요로 하는 것도 아니다. 단순 조회나 변환은 얇은 wrapper가 더 빠르고 유지보수하기 쉽다. 경계가 필요한지부터 판단해야 한다.
시뮬레이션이나 소형 모델의 성능 주장도 실제 환경에서 그대로 재현되지 않을 수 있다. 원래의 평가셋, 비용 조건, 실패율을 확인하고 자신의 입력으로 작은 검증을 먼저 돌려야 한다.
결론
MCP는 API를 에이전트가 읽게 만드는 기술에서, 실행을 안전하게 구조화하는 인터페이스로 이동하고 있다. 모든 도구에 판단을 넣으라는 뜻은 아니다. 판단이 필요한 workflow라면 입력, 정책, 상태, 권한, 완료 증거를 경계 안에 명시해야 한다.
다음 AI 기능을 만들 때 먼저 물어보자.
- 이 결과는 어떤 입력과 조건에서 나왔는가?
- 사용자는 제안과 실제 실행을 구분할 수 있는가?
- 모르는 상태와 실패 이유가 남는가?
- 같은 작업을 다시 실행해도 안전한가?
좋은 에이전트 제품은 더 많은 일을 약속하는 대신, 무엇을 알고 무엇을 모르는지와 실제로 무엇이 끝났는지를 보여준다.