MCP는 AX에서 어떤 의미가 있는가

이 글은 솔직히 먼저 적어 둔다. 나는 MCP(Model Context Protocol)를 깊게 운영해 본 경험이 아직 얕다. 그래서 “MCP를 이렇게 쓰면 좋다”는 사용기가 아니라, MCP를 AX 설계에 둘 때 내가 묻게 되는 것에 대한 글에 가깝다. 결론이 덜 난 채로 남겨 두는 글이다.

MCP의 매력은 모델과 도구·데이터의 연결을 표준으로 쉽게 만든다는 데 있다. 그런데 운영에서 진짜 묻게 되는 건, 그 연결이 끊겼을 때 일이 굴러가느냐다.

표준이 낮추는 비용

큰 그림은 단순하다. MCP는 모델이 외부 도구와 데이터에 닿는 방식을 표준화하려는 규약이다. 그동안 도구·데이터를 모델에 붙이는 일은 매번 따로 만들어야 했는데, 그걸 공통 규약으로 정리한다는 게 핵심이다.

AX 관점에서 이게 왜 의미 있나. AX란 무엇인가에서 데이터 접근과 워크플로우 연결을 핵심 계층으로 뒀는데, AX 설계의 상당 부분이 바로 “모델을 실제 업무 데이터와 도구에 연결하는 일”이다. MCP는 그 연결의 비용을 낮춘다는 점에서 에이전트 워크플로우를 짜는 데 직접 영향을 준다.

끊기면 어떻게 되나

연결이 쉬워진다는 건 그 연결에 의존하게 된다는 뜻이기도 하다. 그리고 의존하는 연결은 언젠가 끊긴다. 외부 앱 연동(connector)의 인증이 비어 있어 호출이 실패한 적이 있고, 그때는 같은 일을 CLI로 우회해서 처리했다. 이 가이드 작업 중에도 비슷한 일이 있었다 — 브라우저를 띄워 화면을 확인하는 도구 연결이 중간중간 끊겨서, 결국 빌드 결과와 출력 HTML을 직접 뜯어보는 쪽으로 물러서서 검증을 이어 갔다.

이 경험들이 알려준 건, MCP를 AX 운영에 둘 때 내가 물어야 할 질문이 “얼마나 많은 도구를 연결하나”가 아니라는 점이다. 진짜 질문은 그 연결이 끊겼을 때 일이 멈추느냐, 아니면 다른 길로 굴러가느냐다. Codex 글에서 무인 러너에 “못 하면 멈추지 말고 한계를 기록하고 진행하라”를 넣었던 것과 같은 이야기다 — 표준이 연결을 매끄럽게 해 줄수록, 그 매끄러움이 사라졌을 때의 폴백을 미리 정해 둬야 한다.

그래서 지금 보는 것

정리하면, MCP의 값은 분명하다 — 연결을 표준화해 AX의 큰 비용 한 덩어리를 줄여 준다. 다만 나는 그 값을 “도구를 많이 붙일 수 있다”로 받기보다, “이 연결에 얼마나 기대도 되나”로 따지는 편이다. 표준은 연결을 쉽게 만들지만 끊기지 않게 만들어 주지는 않으니까.

MCP 자체를 깊게 운영한 글은 더 써본 뒤에 쓴다. 빠르게 바뀌는 규약이라 사실 확인 없이 단정하지 않으려 하고, 세부는 그때 1차 소스로 다시 확인할 것이다. 지금은 “연결의 신뢰성과 폴백”이라는 문제의식까지를 이 자리에 남겨 둔다.

변경 로그

• 2026-06-23초안에서 발행. 연결 표준의 값 + 끊김·폴백 문제의식 정리. MCP 심화 사용기는 보류 (성숙도: 탐색 중)
• 예정MCP 직접 운영 경험·구체 구성을 1차 소스 확인 후 보강