From portal-hopping to instant answers: HEMA’s journey with MCP and Amazon Bedrock

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

HEMA는 Amazon Bedrock AgentCore와 MCP로 내부 AI 도우미 HAL을 구축해 분산된 지식을 일상 업무 도구에서 조회하도록 했으며, 현재의 읽기 전용 지식 계층을 향후 작업 실행 계층으로 확장할 계획이다.

📌 핵심 요약

• 100년 역사의 네덜란드 유통기업 HEMA는 여러 국가에서 750개 이상의 매장을 운영하며, 내부 지식의 분산으로 신규 인력의 적응 지연, 답변 불일치, 잦은 도구 전환을 겪었다.
• HAL은 분산된 지식을 관리되는 단일 지식원으로 통합하고, MCP는 HAL 웹 채팅, Kiro, Claude 등에서 같은 지식과 도구에 접근하는 표준 인터페이스를 제공한다.
• HAL은 Next.js 웹 채팅과 Strands 에이전트로 시작했으며, Amazon Bedrock AgentCore의 Runtime, Memory, Gateway와 Amazon Bedrock Guardrails를 활용한다. 지식 검색은 Amazon Bedrock Knowledge Bases를, 실시간 데이터 조회는 내부 API를 이용한다.
• 외부 MCP 클라이언트에는 Microsoft Entra ID 인증을 사용하는 별도 Gateway를 추가했다. 인증 프록시는 고정된 사전 발급 클라이언트 ID로 DCR을 모방하며, 사용자는 AWS 자격 증명 없이 브라우저 로그인과 자동 토큰 갱신으로 접속한다.
• 원문은 서너 개 포털을 오가며 때로 오후 내내 찾던 답을 이제 IDE나 채팅에서 수초 안에 얻는다고 설명한다. 현재 접근은 읽기 전용이며 작업 실행 계층으로의 확장은 향후 계획이다. 제공된 본문은 테스트와 출시 설명 도중 끊겨 구체적인 검증 결과는 확인할 수 없다.

🧩 주요 포인트

1. 구조화된 서비스 카탈로그는 있었지만 접근성과 절차 지식이 부족했다 → HAL의 핵심 과제는 기존 지식의 연결과 자주 발생하는 업무 질문의 해소다.
2. MCP 표준 인터페이스와 Amazon Bedrock AgentCore의 관리형 기능을 결합했다 → 지식원·클라이언트별 맞춤 연동과 자체 MCP 서버 운영 부담을 줄이지만, 기존 API를 에이전트 친화적인 도구로 다듬는 과제는 남는다.
3. Gateway당 단일 인바운드 인증 유형이라는 제약으로 내부 IAM 경로와 외부 Microsoft Entra ID 경로를 분리했다 → 클라이언트의 AWS 자격 증명 없이 접근을 제공하고 외부 경로의 변경·장애 영향을 내부 에이전트와 분리한다.

🧠 상세 정리

1. 지식의 부재보다 접근의 어려움이 컸던 HEMA

100년 역사의 네덜란드 유통기업 HEMA는 여러 국가에서 750개 이상의 매장을 운영하며, 엔지니어·제품 책임자·비즈니스 분석가로 구성된 기술 조직이 디지털 전환을 추진하고 있다. 조직에는 사람과 팀, 팀과 서비스, 서비스와 API 및 비즈니스 역량의 관계를 기록한 서비스 카탈로그가 이미 존재했다. 문제는 지식 자체가 없다는 것이 아니라, 서로 연결되지 않은 위키와 서비스 카탈로그, IT 포털에서 필요한 답을 찾기 어렵다는 점이었다. 조직이 커지면서 옆 사람에게 직접 묻는 방식은 더 이상 충분하지 않았고, 여러 도구와 직무에서 사용할 수 있는 접근 방식이 필요해졌다. HEMA는 이를 해결하기 위해 Amazon Bedrock AgentCore 위에 지식 계층을 구축하고 내부 AI 도우미 HAL을 개발했다.

2. 구조화된 정보와 절차 지식의 서로 다른 문제

HEMA는 내부 지식 문제를 구조화된 인프라 정보와 업무 절차 지식이라는 두 층으로 구분한다. 첫 번째 층은 비교적 잘 갖춰져 있었으며, 서비스 소유 팀과 노출 API, 비즈니스 역량뿐 아니라 제품 정보 관리 시스템인 PIM과 데이터 메시 테이블의 데이터도 정리되어 있었다. 반면 API 접근을 요청하는 방법, 새 그룹을 생성받는 절차, 특정 사안에 적용되는 규칙 같은 질문에는 통합된 정보원이 없었고 문서도 부족했다. 이 차이는 신규 입사자의 적응 지연, 조회 위치에 따른 답변 불일치, 잦은 맥락 전환으로 이어져 실제 업무를 방해했다. 원문은 서너 개 포털을 오가며 때로 오후 내내 찾던 답을 이제 IDE나 채팅 창에서 수초 안에 얻는다고 설명하지만, 이를 뒷받침하는 상세 측정 방법은 제공하지 않는다.

3. HAL의 지식 통합과 MCP의 도구 내 접근

솔루션의 두 목표는 HAL과 MCP의 역할로 나뉜다. HAL은 분산된 지식을 관리되는 단일 지식원으로 통합하고, MCP는 사용자가 별도 포털로 이동하지 않고 평소 사용하는 도구에서 그 지식에 접근하도록 한다. 각 지식원을 MCP 도구로 한 번 노출하면 HAL 웹 채팅, Kiro, Claude 및 다른 호환 에이전트가 같은 도구를 사용할 수 있어 지식원과 클라이언트마다 맞춤 연동을 반복할 필요가 줄어든다. Amazon Bedrock AgentCore는 OpenAPI 명세와 AWS Lambda 함수를 도구로 바꾸는 Gateway, 인바운드 JWT 인증과 아웃바운드 OAuth2를 관리하는 Identity, 에이전트 컨테이너를 호스팅하는 Runtime을 제공한다. Memory와 Amazon Bedrock Guardrails는 대화 문맥과 콘텐츠 필터링을 지원하며, HEMA는 EU 추론 리전과 네덜란드어 지원도 활용한다. 보안은 Microsoft Entra ID OAuth와 기존 Active Directory 그룹 기반 접근 제어에 연결되며, 현재 권한 범위는 읽기 전용이다.

4. 첫 단계: 독립형 HAL과 두 가지 조회 경로

HAL은 처음부터 외부 업무 도구에 개방된 형태로 만들어진 것이 아니라, 자체 채팅 화면을 갖춘 독립형 도우미로 시작했다. 웹 채팅은 Next.js로 구현되었고, Strands 에이전트는 Linux/ARM64 컨테이너로 패키징되어 AgentCore Runtime에서 실행된다. AgentCore Memory는 단기 대화 문맥을 제공하며, Amazon Bedrock Guardrails는 Standard 등급과 네덜란드어 지원을 위한 EU Cross-Region 추론 구성으로 사용된다. 지식 조회에는 두 경로가 있는데, 의미 검색용 로컬 Strands 도구는 Gateway를 거치지 않고 Amazon Bedrock Retrieve API를 직접 호출한다. 실시간 데이터, 전체 OpenAPI 명세, 서비스 카탈로그, 사람과 팀 정보는 에이전트가 MCP로 자체 AgentCore Gateway에 연결해 조회하며, 이 Gateway는 IAM SigV4로 인증한다. 따라서 초기에는 외부 MCP 클라이언트가 없었지만, 설명된 독립형 구성의 내부 API 조회 경로에는 MCP가 사용된다.

5. 지식원 확장과 검색 품질 개선, 도구 설계의 한계

HEMA는 기존 서비스 카탈로그를 출발점으로 삼고, 업무 불편의 크기와 질문 빈도를 기준으로 가치가 높은 문서를 추가했다. Amazon Bedrock Knowledge Bases에는 IT 및 사용 방법 문서, API와 OpenAPI 명세, Kafka 토픽과 Avro 스키마, DCL 데이터 교환 채널, 사람·팀·서비스·API 정보를 담은 서비스 카탈로그가 포함된다. Gateway는 OpenAPI 명세와 Lambda 함수에서 MCP 도구를 생성하므로 별도의 MCP 서버 코드를 작성하거나 운영할 필요가 없으며, kb-search Lambda는 Retrieve API를 감싸 검색을 제공한다. 이 Lambda의 IAM 권한은 지정된 Knowledge Base ARN과 원본 문서가 있는 Amazon S3 버킷의 읽기 접근으로 제한된다. 검색은 먼저 Knowledge Base에서 답을 찾고 단일 청크로 부족하면 fetch_full_document로 전체 문서를 가져오는 두 단계 방식이며, 의미 검색 재순위화와 team_id 메타데이터 필터링으로 품질을 개선한다. 다만 시스템 간 호출용 API가 에이전트가 이해하기 좋은 도구와 항상 일치하지는 않으므로, 기존 명세의 직접 노출은 적은 노력으로 가치를 얻는 현재 방식이고 에이전트 친화적인 정의로의 개편은 남은 과제다.

6. 두 번째 단계: 외부 업무 도구를 위한 Gateway 분리

독립형 HAL이 유용성을 입증한 뒤, HEMA는 사용자가 머무는 IDE와 AI 도우미에서도 같은 지식과 도구에 접근하도록 범위를 넓혔다. Kiro와 Claude 같은 외부 MCP 클라이언트에 AWS 자격 증명을 배포하지 않기 위해 Microsoft Entra ID의 사용자 지정 JWT로 인증하는 두 번째 AgentCore Gateway를 추가했다. AgentCore Gateway는 인바운드 인증 유형을 하나만 지원하므로, 첫 단계에서 만든 IAM 인증 Gateway를 외부 클라이언트용으로 그대로 재사용할 수 없었다. 두 Gateway는 읽기 전용 Knowledge Bases만 공유하고 코드는 공유하지 않아, 외부 노출 경로의 변경이나 장애가 내부 에이전트에 영향을 주지 않도록 구성되었다. Knowledge Bases를 Gateway 도구로 노출할 때는 중간 Lambda 함수가 의미 검색을 수행하며, 실시간 내부 API는 OpenAPI 대상으로 직접 노출된다. 이 구조는 인증 요구가 다른 내부 에이전트와 외부 클라이언트를 분리하면서 기존 지식 기반을 활용하는 방식이다.

7. 인증 프록시와 실제 동적 등록이 아닌 DCR 모방

외부 클라이언트 인증에서 핵심 과제는 MCP의 OAuth 규격과 Microsoft Entra ID의 동작 차이를 연결하는 일이었다. HEMA는 Entra Gateway 앞에 Amazon API Gateway v2 HTTP API와 단일 Lambda로 구성된 MCP 인증 프록시를 배치했다. 프록시는 OAuth 탐색 문서를 제공하고 요청 범위를 리소스 앱의 invoke 범위로 바꾸며, Entra v2.0이 거부하는 기존 resource 매개변수를 제거한다. 또한 데스크톱 클라이언트가 인가 코드를 받을 수 있도록 response_mode=query를 추가하고, bearer 토큰과 함께 /mcp 요청을 전달한다. MCP 클라이언트가 기대하는 POST /register에는 사전 준비된 고정 클라이언트 ID를 반환하므로, DCR은 실제 동적 등록이 아니라 모방된 동작이다. 사용자는 프록시 URL과 빈 oauthScopes 목록만 설정하고 최초 접속 시 브라우저로 로그인하며, 이후 토큰은 자동 갱신되므로 클라이언트에 AWS 자격 증명을 둘 필요가 없다.

8. 배포 구성과 향후 확장, 제공 자료의 경계

인프라는 AWS Cloud Development Kit인 AWS CDK로 정의되며, npm workspaces를 사용하는 TypeScript 모노레포로 구성된다. 내부 에이전트는 AgentCore Runtime의 Docker 컨테이너에서 실행되고, 테넌트·클라이언트·리소스 식별자처럼 환경에 따라 달라지는 설정은 AWS Systems Manager의 SSM 매개변수로 공급된다. 원문은 개발자 도구로 시작한 HAL이 이미 여러 직무를 지원하는 도우미로 확대되었다고 설명하며, 동일한 아키텍처를 다음 단계의 기반으로 제시한다. 그 다음 단계는 읽기 전용 지식 계층을 작업 실행 계층으로 확장하는 것이지만, 현재 구현된 기능으로 서술되지는 않는다. 제공된 본문은 테스트와 출시 항목에서 운영 전 배포를 설명하려는 문장 도중 끊겨 있어, 배포 대상이나 검증 절차, 출시 결과의 구체적인 내용은 확인할 수 없다. 따라서 현재의 조회 기능과 향후 실행 기능의 계획을 구분하고, 제시되지 않은 테스트 결과를 확정하지 않는 해석이 필요하다.

🧾 핵심 주장 / 시사점

• HEMA 사례에서 지식 통합의 가치는 이미 존재하던 서비스 카탈로그를 쉽게 조회하게 만드는 일과 부족한 절차 문서를 보강하는 일을 함께 수행하는 데 있다.
• MCP는 여러 업무 도구에서 같은 기능을 소비하도록 돕지만, 기존 OpenAPI 명세가 에이전트에게 적합한 도구 설계를 자동으로 보장하지는 않는다.
• 인증 유형의 제약은 Gateway 분리로 이어졌고, 읽기 전용 지식 기반의 공유와 외부 경로의 독립적인 운영을 함께 고려하는 구조가 형성되었다.

✅ 액션 아이템

• HAL의 지식 보강에서 서비스 카탈로그와 절차 지식의 공백, 자주 발생하는 업무 질문을 우선 검토.
• 기존 API를 에이전트 친화적인 도구로 다듬는 과제와 MCP 표준 인터페이스의 활용 범위를 검토.
• 읽기 전용 지식 계층에서 작업 실행 계층으로의 확장을 검토할 때 현재 기능의 범위와 확인되지 않은 검증 결과를 구분.

❓ 열린 질문

• HAL 도입 후 수초 안에 답을 얻는 효과는 신규 인력의 적응 지연과 답변 불일치를 얼마나 줄였는가?
• 기존 API를 에이전트 친화적인 도구로 다듬을 때 어떤 업무 질문과 조회 기능을 우선할 것인가?
• HAL을 읽기 전용 지식 계층에서 작업 실행 계층으로 확장하려면 어떤 검증이 추가로 필요한가?