저는 커리어의 상당 부분을 아무도 사용하지 않는 대시보드를 살펴보며 보냈습니다.

2005년의 구식 CRM 보고서였든 오늘날의 현대적인 학습 경험 플랫폼 (LXP)였든, 문제는 항상 동일합니다. 데이터는 존재하지만 UI 뒤에 갇혀 있다는 점입니다. 엔지니어가 무엇을 알고 있는지, 어떤 과정을 완료했는지, 그리고 인재 격차 (talent gaps)가 어디에 있는지에 대한 모든 메타데이터를 보유하고 있지만, "우리 팀에서 누가 Node.js 마이그레이션을 수행할 준비가 되었는가?"와 같은 간단한 질문을 던지기 위해서조차 수동으로 클릭하고, 필터링하고, CSV로 내보내는 과정이 필요합니다.

Model Context Protocol (MCP)는 이러한 정적인 UI 사일로 (silos)를 AI 에이전트를 위한 실행 가능한 도구 세트로 전환함으로써 이 문제를 해결합니다. 저는 최근 Vinkius에서 Degreed MCP 구현을 심도 있게 살펴보았으며, 이는 우리가 "봇과 채팅하기"에서 "지능형 인력 레지스트리 (workforce registry) 오케스트레이션"으로 어떻게 이동하는지를 보여주는 명확한 사례입니다.

설정: 단순 검색을 넘어

사람들이 Degreed와 같은 LXP를 AI 워크플로우에 통합하는 것을 생각할 때, 대개 한 가지만 떠올립니다. 바로 콘텐츠 검색입니다. 물론, search_learning_catalog 도구가 정확히 그 역할을 수행하기 위해 존재합니다. 에이전트에게 'Python을 활용한 데이터 과학 (Data Science with Python)' 과정을 찾아달라고 요청하면, 제목과 기술 태그 (skill tags)를 기반으로 순위가 매겨진 자료 목록을 반환할 것입니다.

하지만 검색을 위해서만 MCP를 사용한다면, 가치의 80%를 놓치고 있는 것입니다. 진정한 엔지니어링 유용성은 콘텐츠, 사용자, 그리고 기술 간의 상관관계에 있습니다.

이 특정 Degreed 통합 기능에 접근할 수 있는 에이전트는 단순히 사서 역할을 하는 것이 아니라, 인재 분석가 (talent analyst) 역할을 수행합니다. 이 도구 세트에는 list_defined_skills 및 get_user_profile이 포함되어 있으므로, 복잡한 추론 루프 (reasoning loops)를 구축할 수 있습니다.

다음과 같은 워크플로우를 상상해 보십시오:

1. 질의 (The Query): "우리는 Go로 새로운 프로젝트를 시작하려고 합니다. 사내에 충분한 전문 지식이 있나요?"
2. 1단계 (탐색, Discovery): 에이전트가 list_defined_skills를 호출하여 회사 분류 체계(taxonomy)에 'Go' 또는 'Golang'이 어떻게 표현되어 있는지 확인합니다.
3. 2단계 (매핑, Mapping): 그 다음 get_user_profile을 통해 사용자를 반복 탐색하거나 조직 내 특정 기술 등급(skill ratings)을 검색합니다.
4. 3단계 (격차 분석, Gap Analysis): 숙련도 부족을 식별하면, 팀을 위한 즉각적인 학습 경로 (learning path)를 제안하기 위해 자동으로 search_learning_catalog를 호출합니다.

이것은 단순한 자동화가 아닙니다. 비정형적인 학습 행동을 구조화된 조직 지능 (organizational intelligence)으로 전환하는 것입니다.

도구 세트 해체 (Deconstructing the Toolset)

이러한 에이전트를 구축하는 방법을 이해하려면, 도구들이 실제로 무엇을 노출하는지 살펴보아야 합니다. Degreed MCP는 세 가지 별개의 계층으로 나뉩니다:

1. 카탈로그 계층 (The Catalog Layer: search_learning_catalog, get_content_details, list_learning_content)

이곳은 진입점입니다. 제목, 제공자, 기간과 같은 메타데이터 (metadata)의 검색을 처리합니다. 만약 L&D (Learning & Development) 매니저를 보조하는 에이전트를 구축한다면, 이 계층에서 대부분의 시간을 보내게 될 것입니다. get_content_details를 통해 상세 설명을 확인하는 능력은 LLM (Large Language Model)이 코스를 추천하기 전에 그 _실체 (substance)_를 실제로 이해할 수 있게 해줍니다.

2. ID 및 기술 계층 (The Identity & Skill Layer: list_degreed_users, get_user_profile, list_defined_skills)

이곳에서 '지능'이 발생합니다. 직함 및 조직 소속을 포함한 사용자 메타데이터를 노출함으로써, 에이전트는 인구 통계 기반의 기술 분석을 수행할 수 있습니다. 단순히 React를 아는 사람을 찾는 것이 아니라, 특정 경로를 통해 '숙련 (Proficient)' 단계에 도달한 런던 사무소의 시니어 엔지니어 (Senior Engineer)를 찾는 식입니다.

3. 관찰 가능성 계층 (The Observability Layer: list_active_learners, list_user_completions, list_learning_plans)

이 부분은 단연코 리더십(leadership) 측면에서 가장 중요한 부분입니다. 이를 통해 에이전트가 진행 상황을 모니터링할 수 있습니다. list_user_completions를 통해 "이번 분기에 보안 교육을 완료한 팀원은 누구인가요?"라고 물을 수 있습니다. 이는 역량 추적(competence tracking)을 주기적인 수동 감사에서 자연어를 통해 사용할 수 있는 실시간 데이터 스트림으로 전환해 줍니다.

현실 점검: 제약 사항 및 보안

저는 항상 도구가 할 수 없는 것에 대해 솔직해야 한다고 주장해 왔습니다. 만약 이 MCP를 인재 관리(talent management)의 행정적인 측면을 자동화하는 데 사용하려 한다면, 한계에 부딪히게 될 것입니다.

현재 이 통합은 탐색(discovery)과 모니터링(monitoring)에 집중되어 있습니다. 에이전트를 사용하여 새로운 코스를 할당하거나 사용자 프로필을 수정할 수는 없습니다. 그러한 작업은 여전히 Degreed 대시보드나 모바일 앱 내에서 이루어집니다. 에이전트는 관찰자이자 연구자이며, 시스템의 상태를 작성하는 작성자(writer)가 아닙니다.

실제 운영 환경에서 이러한 통합이 자주 실패하는 지점인 보안 관점에서 말씀드리자면, 이는 OAuth 2.0을 필요로 합니다. Degreed Client ID와 Client Secret이 필요합니다. Vinkius에서 이를 설정할 때 연결은 보안 토큰(secure tokens)을 통해 처리되지만, 해당 자격 증명(credentials)을 환경 내에서 관리하는 책임은 여전히 사용자에게 있습니다.

이것이 실제 운영 수준의 설정에서 어떻게 구현되는지—특히 에이전트가 외부 API를 쿼리할 때 SSRF와 같은 문제를 방지하기 위한 격리된 V8 샌드박싱(sandboxing) 및 거버넌스 정책(governance policies)을 어떻게 처리하는지에 대해—보고 싶다면, 여기에서 구현 내용을 확인할 수 있습니다: https://vinkius.com/mcp/degreed.

이것이 차세대 AI 에이전트에게 중요한 이유

우리는 단순히 '무언가를 아는' LLM에서 우리의 독점 데이터(proprietary data)를 가지고 '무언가를 수행하는' 에이전트로 이동하고 있습니다. 병목 현상은 모델의 추론(reasoning) 능력이 아니라, 그 추론을 신뢰할 수 있고 인증된 진실의 원천(source of truth)에 연결하는 과정에서의 마찰(friction)이었습니다.

에이전트를 회사의 학습 분류 체계(learning taxonomy)에 직접 연결할 수 있다면, 여러분은 단순히 챗봇을 만드는 것이 아닙니다. 여러분은 실시간으로 변화에 대응할 수 있는 조직 기억(organizational memory)의 계층을 구축하고 있는 것입니다.

만약 여러분이 L&D(학습 및 개발) 자동화나 인재 인텔리전스(talent intelligence) 분야에서 작업하고 있다면, 이것이 바로 시작점입니다.

MCP는 AI 에이전트의 음악과 같습니다. 우리는 카탈로그를 구축했습니다. Vinkius MCP Catalog를 확인해 보세요.