MCP는 개발자만의 영역이 아닙니다. 제품 팀도 이를 이해해야 합니다.

제품 관련 대화에서 계속해서 등장하지만, 거의 항상 똑같은 방식으로 마무리되는 어떤 것에 대해 이야기하고 싶습니다.

개발자가 MCP를 언급합니다. 프로덕트 매니저(Product Manager)는 고개를 끄덕입니다. 회의는 다음 단계로 넘어갑니다. 그것이 실제로 무엇을 변화시키는지 묻기 위해 멈춰 서는 사람은 아무도 없습니다.

이것은 문제입니다. 왜냐하면 Model Context Protocol (MCP)은 꽤 많은 것을 변화시키며, 그 영향은 단지 기술적인 것에 그치지 않기 때문입니다.

그렇다면 MCP란 실제로 무엇인가?

Model Context Protocol (MCP)은 AI 모델이 외부 도구, 데이터 소스 및 서비스에 연결되는 방식을 정의하는 개방형 표준 (Open Standard)입니다. MCP 이전에는 모든 AI 통합이 본질적으로 맞춤형 글루 코드 (Glue Code)였습니다. 즉, 모델과 특정 도구 사이의 일회성 연결이었으며, 매번 다르게 구축되고 다른 모든 것과 별도로 유지 관리되었습니다.

MCP는 해당 연결 계층 (Connection Layer)을 표준화합니다. 맞춤형 통합 대신, 호환 가능한 모든 AI 모델이 호환 가능한 모든 도구와 통신하는 데 사용할 수 있는 일관된 프로토콜을 갖게 됩니다.

USB를 생각해보세요. USB 이전에는 모든 주변 기기가 각자의 커넥터, 각자의 드라이버, 각자의 설정 프로세스를 가지고 있었습니다. USB가 주변 기기를 더 강력하게 만든 것은 아닙니다. USB는 그것들을 연결하는 과정을 극적으로 더 단순하고 예측 가능하게 만들었습니다. MCP는 AI와 그것이 작동하는 도구들에 대해 이와 유사한 역할을 수행합니다.

이것이 실제로 해제하는 것

여기서부터 제품 팀에게 흥미로운 지점이 시작됩니다.

MCP 이전에는 제품에 AI를 추가한다는 것이 AI가 무엇을 건드릴 수 있는지 사전에 정확히 결정하는 것을 의미했습니다. 통합 범위를 정하고, 연결을 구축하고, 배포했습니다. 만약 AI가 새로운 무언가에 접근해야 한다면, 또 다른 통합을 구축해야 했습니다. AI의 역량은 본질적으로 빌드 타임 (Build Time)에 연결된 상태로 고정되었습니다.

MCP를 사용하면 연결 계층이 표준화되고 조합 가능 (Composable)해집니다. 제품 내부의 AI 에이전트 (AI Agent)는 원칙적으로 각 도구마다 별도의 맞춤형 통합 없이도 모든 MCP 호환 도구 또는 데이터 소스에 도달할 수 있습니다. 새로운 기능이 추가된다고 해서 모든 조합에 대해 새로운 글루 코드 (Glue Code)를 작성할 필요가 없습니다.

제품 팀의 경우, 이는 대화의 주제를 "AI가 무엇을 할 수 있게 만들 것인가"에서 "AI에게 무엇을 허용할 것인가"로 변화시킵니다. 이는 근본적으로 다른 종류의 결정이며, 단순한 엔지니어링이 아닌 제품 사고 (Product Thinking)의 영역에 속합니다.

제품 팀이 던져야 할 질문들

만약 귀하의 제품에 AI 기능을 추가하고 있거나 추가할 계획이라면, MCP를 프로토콜 명세 (Protocol Spec) 수준이 아닌 그 함의 (Implications) 측면에서 개념적으로 이해할 가치가 있습니다.

AI에게 실제로 어떤 컨텍스트 (Context)가 필요한가? MCP는 AI 모델이 라이브 데이터, 사용자 상태, 외부 서비스 및 내부 도구에 접근하는 것을 더 쉽게 만듭니다. 이는 AI를 단순히 더 많이 연결하는 것이 아니라, 어떤 컨텍스트가 AI를 진정으로 더 유용하게 만드는지에 대해 깊이 고민했을 때에만 유용합니다.

권한 경계 (Permission Boundary)를 어디에 설정할 것인가? 도구를 연결하는 것이 쉬워질수록, AI가 무엇을 만질 수 있고 무엇을 만질 수 없는지에 대해 신중하게 결정하는 것이 더욱 중요해집니다. 이는 기술적인 결정이기 이전에 제품 및 신뢰에 관한 결정입니다.

이것이 기능 로드맵 (Feature Roadmap)을 어떻게 변화시키는가? AI 기능이 더 이상 모든 데이터 소스에 대해 맞춤형 통합 (Custom Integration)을 요구하지 않는다면, 제약 사항은 "이 연결을 구축할 수 있는가"에서 "이 기능을 출시해야 하는가"로 이동합니다. 범위 밖 (Out of scope)처럼 보였던 일부 사항들이 현실적으로 변합니다. 이는 어느 한쪽의 추측이 아니라, 제품 팀과 엔지니어링 팀 간의 논의가 필요한 부분입니다.

이것이 겉보기보다 중요한 이유

향후 몇 년 동안 가장 유용한 AI 기능을 구축할 팀은 반드시 최고의 모델을 가진 팀은 아닙니다. 그들은 자신의 AI가 무엇을 할 수 있어야 하는지, 어떤 데이터에 접근할 수 있어야 하는지, 그리고 경계가 어디인지가 명확한 팀들입니다.

MCP는 AI를 제품 스택의 나머지 부분과 연결하는 기술적 장벽을 낮춰줍니다. 이는 진정으로 유용합니다. 하지만 장벽이 낮아진다는 것은 무엇을 연결하고 무엇을 연결하지 않을지에 대한 결정이 이전보다 더 중요하다는 것을 의미합니다.

MCP를 개발자의 세부 사항으로 취급하는 제품 팀(Product teams)은 제품 수준에서 내려졌어야 할 기능 결정 사항들에 대해 사후 대응을 하게 되는 상황에 직면할 것입니다.

만약 여러분의 팀이 웹 애플리케이션 내부의 AI 통합(AI integration)이 어떤 모습일지 고민하고 있다면, 구축(build) 이전에 이루어지는 아키텍처 결정(architectural decisions)은 구축 자체만큼이나 중요합니다. 처음부터 AI 기능이 내장된 맞춤형 웹 애플리케이션 개발을 진행하는 팀은 기존 시스템에 AI를 사후에 적용(retrofitting)하는 팀보다 더 깔끔한 결과물을 얻는 경향이 있습니다.