AX LABS
← 블로그 사례 기록

MCP 첫 연결은 끝이 아니었다

붙이는 일보다 운영 경계가 먼저다

AX LABS 5분 읽기

첫 MCP 서버를 붙이는 날, 회의실의 공기는 금방 달라진다. “이제 사내 데이터가 대화창으로 들어온다”는 기대가 생긴다. 하지만 데모가 끝나면 질문이 바뀐다. 이 서버는 누구 권한으로 조회하는가. 잘못된 tool call은 누가 막는가. 로그는 어디에 남는가. 장애가 나면 현업은 누구에게 연락하는가.

우리가 현장에서 반복해서 본 장면은 같다. MCP는 연결 기술로 들어오지만, 실제로는 운영 경계를 드러내는 장치다.

연결은 빨랐고 책임은 늦게 왔다

MCP의 매력은 분명하다. 2025년 11월 MCP 사양은 TypeScript schema를 원천으로 두고 JSON Schema 검증을 전제로 한다. 같은 해 12월 Anthropic은 MCP를 Linux Foundation 산하 Agentic AI Foundation에 기부한다고 발표했다. 2026년 1월에는 MCP Apps가 공식 extension으로 올라와 tool이 대화 안에서 UI까지 반환하는 방향을 열었다.

이 흐름은 사내 첫 서버를 붙이는 팀에게 신호를 준다. “표준이 되고 있다. 지금 시작해야 한다.” 맞는 판단이다. 다만 표준은 운영을 대신하지 않는다.

첫 연결에서 보통 막히는 지점은 프로토콜 문법이 아니다. 사내 시스템의 권한 모델, 데이터 등급, 감사 로그, 승인 절차가 agent 실행 방식과 맞물리는 지점이다. 기존 API는 호출 주체와 화면 흐름이 비교적 고정되어 있었다. MCP 서버는 대화 중에 tool이 선택되고, 여러 tool이 이어지고, 사용자는 결과만 본다. 책임선을 더 선명하게 그어야 한다.

기대와 현실은 다른 표에 적힌다

첫날 기대는 대개 생산성 언어로 표현된다. 현실은 통제 언어로 돌아온다.

첫 기대 붙여본 뒤 드러난 현실 운영 질문
사내 검색이 쉬워진다 검색 범위보다 접근 권한이 먼저다 사용자의 실제 권한을 어떻게 반영할 것인가
업무 tool을 대화로 실행한다 실행 전 승인과 취소가 필요하다 어떤 작업을 HITL로 묶을 것인가
여러 시스템을 한 번에 묶는다 tool 조합이 새로운 위험을 만든다 조합 호출을 어디까지 허용할 것인가
표준이면 재사용된다 서버별 품질과 설명 방식이 다르다 tool description을 누가 관리할 것인가

MCP의 첫 성공은 “붙었다”가 아니라 “통제 가능한 상태로 붙었다”다.

특히 보안은 뒤로 미룰 수 없다. 2026년 3월 Coalition for Secure AI의 MCP Security 문서는 MCP가 JSON-RPC 기반 message와 tool, resources, prompts 같은 primitive를 다루며, stdio와 Streamable HTTP 같은 transport 경계를 구분한다고 설명한다. 2026년 4월 OX Security는 stdio 구성과 command execution 경계에서 발생하는 공급망 위험을 공개했다. 이 논쟁의 결론이 무엇이든 기업 내부의 결론은 이미 명확하다. 로컬 실행, 원격 서버, 사용자 입력, config 변경은 같은 운영 통제 안에 들어와야 한다.

첫 서버에는 네 가지 장부가 필요하다

사내 첫 MCP 서버를 운영으로 넘기려면 코드 저장소보다 먼저 장부가 필요하다. AX Ops에서는 이를 “agent 운영원장”으로 본다.

  1. Tool 원장: tool 이름, 설명, 입력 schema, 소유 부서, 위험 등급을 기록한다.
  2. 권한 원장: 사용자의 사내 권한이 MCP 호출에 어떻게 반영되는지 적는다.
  3. 승인 원장: 조회, 생성, 수정, 삭제 중 어떤 행위에 사람 승인이 필요한지 정한다.
  4. 관측 원장: tool call, 실패, 거절, 재시도, 사용자 승인 이력을 남긴다.
  5. 변경 원장: 서버 version, schema 변경, tool description 변경의 배포 절차를 둔다.

이 다섯 가지가 없으면 MCP 서버는 데모 자산으로 남는다. 반대로 이 장부가 있으면 첫 서버는 다음 서버의 기준선이 된다. 사내 회계, 구매, 품질, 고객지원 같은 업무로 확장할 때 매번 새로 합의하지 않는다.

데모 다음 날의 운영을 설계해야 한다

첫 MCP 서버는 크게 만들 필요가 없다. 오히려 작아야 한다. 읽기 전용 tool 몇 개, 제한된 사용자, 명확한 로그, 명시적 승인 흐름으로 시작해야 한다. 핵심은 agent가 무엇을 할 수 있는지보다, 조직이 agent의 행동을 어떻게 설명하고 멈추고 고칠 수 있는지다.

첫 서버를 붙인 기록은 기술 검토 문서로 끝나면 안 된다. 다음 세 가지 결정으로 마무리해야 한다. 어떤 tool을 표준 등록 대상으로 삼을 것인가. 어떤 호출을 금지할 것인가. 어떤 지표로 운영 안정성을 볼 것인가.

AX LABS는 MCP를 connector 목록으로 보지 않는다. agent가 사내 업무에 들어오는 운영면으로 본다. 첫 서버는 작은 실험이지만, 그 위에 권한·평가·관측·변경관리의 골격을 세우면 AX의 출발점이 된다. 다음 MCP 서버를 붙이기 전에 운영원장부터 설계하라: AX Ops 방법론 →

참고