🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

분산된 기업 데이터를 MCP 서버로 연결하고 에이전트가 메타데이터 탐색, 권한 적용, 도구 호출, 응답 합성을 조율함으로써 사용자별 실행 가능한 비즈니스 통찰을 제공하는 아키텍처를 설명한다.

📌 핵심 요약

• 생산 관리자 사라는 다섯 개의 분리된 시스템을 오가며 설비 이상 신호, 유지보수 이력, 가동 시간, OEE, 불량률을 수작업으로 연결한 뒤에야 주의가 필요한 생산 라인을 판단할 수 있었다.
• 같은 데이터라도 관리자, 현장 감독자, 정비 기술자의 접근 권한과 데이터 최신성이 달라 PDF, 이메일, CSV 전달에 의존했고, 그 결과 몇 초면 가능해야 할 확인에 수 시간이 걸렸다.
• 제안된 방식은 아마존 베드록 에이전트코어가 오케스트레이션, 보안, 메모리, 확장을 담당하고, 기존 시스템은 사전 구축 또는 사용자 정의 MCP 서버를 통해 연결하는 구성 중심 모델이다.
• 에이전트는 세이지메이커 데이터 카탈로그 기반 시맨틱 계층에서 관련 데이터의 위치를 먼저 파악한 뒤 장비, IoT, 공급망, 품질 분석용 MCP 도구를 호출하고 결과를 종합한다.
• MCP의 느슨한 결합과 표준화된 도구 호출은 데이터 소스의 점진적 확장을 지원하지만, 사용자 정의 커넥터 설정, 상태 유지형 세션의 선호도 관리, 엔드포인트 모니터링과 버전 관리가 필요하다.

🧩 주요 포인트

1. 데이터가 부족한 것이 아니라 시스템별 문맥과 접근 권한이 분리되어 있어 사람이 통합 계층이 되며, 이는 판단 지연과 불완전한 의사결정으로 이어진다.
2. 메타데이터 탐색과 실제 데이터 조회를 분리하면 에이전트에 경로를 하드코딩하지 않고 카탈로그 등록만으로 새로운 데이터 소스를 확장할 수 있다.
3. 사전 구축 MCP와 사용자 정의 MCP를 동일한 프로토콜로 취급하면 공통 시스템은 빠르게 연결하고 특수·레거시 시스템은 점진적으로 추가할 수 있지만 운영 대상도 함께 늘어난다.

🧠 상세 정리

1. 월요일 아침의 생산 판단 문제

생산 관리자 사라 첸은 12개 조립 라인과 2,000대의 기계를 관리하며, 오전 10시 회의 전에 이번 주에 주의해야 할 라인을 찾아야 한다. IoT 대시보드에서는 4번 라인의 모터 온도가 사흘째 기준보다 12°C 높다는 신호를 확인했지만, 교정 오차인지 베어링 고장인지는 알 수 없었다. ERP에는 42번 기계의 베어링을 8개월 전에 교체했고 보증 기간이 12개월이라는 기록이 있었지만, 별도 이력 데이터베이스를 확인해야 해당 기계가 1월부터 정격의 130%로 가동됐다는 사실을 찾을 수 있었다. 이어 4번 라인의 가용성이 94%에서 87%로 떨어지고 9번 라인의 처리량도 6% 감소했으며 두 라인이 냉각수 회로를 공유한다는 관계는 어느 시스템에도 모델링되어 있지 않았다. 4번 라인의 폐기율이 지난 화요일 2.3% 상승한 반면 9번 라인에는 아직 변화가 없어, 사라는 세 명의 감독자에게 이메일을 보낸 뒤 오전 11시 15분에야 확신할 수 있는 답을 얻었다.

2. 동일한 데이터와 서로 다른 접근 수준

두 층 아래의 라인 감독자 라지 파텔도 7번 라인을 대상으로 비슷한 분석을 하고 있었지만, 분석 대시보드에 접근할 수 없어 사흘 전 상태를 담은 PDF 내보내기에 의존했다. 정비 기술자 프리야 나이르는 전주에 표시한 42번 기계의 진동이 악화됐는지만 확인하려 했으나, 데이터가 존재해도 조회 자격 증명이 없었다. 프리야의 요청은 라지를 거쳐 사라의 분석가에게 전달됐고, CSV 파일이 도착하기까지 네 시간이 걸려 프리야는 이미 다음 작업 지시로 이동한 뒤였다. 결국 세 사람은 세 가지 접근 수준으로 다섯 개의 단절된 시스템에서 같은 기반 데이터를 다루면서도 수작업 결합, 화면 전환, 승인과 전달 대기에 시간을 소비했다. 이 사례는 데이터의 부재보다 최신성, 권한, 시스템 간 문맥 연결의 부재가 현장 활용을 막는 핵심 원인임을 보여준다.

3. 데이터는 많지만 통찰은 부족한 기업 환경

본문은 일반적인 기업이 매일 5~8개의 운영·분석 시스템을 사용하며, 각 시스템이 별도의 로그인, 질의 방식, 접근 모델을 갖는다고 설명한다. 여러 시스템을 가로지르는 관점이 필요해지면 담당자가 직접 결과를 모으고 관계를 해석하는 사실상의 통합 계층이 된다. 전통적인 BI 대시보드는 주로 이미 발생한 일을 보여주고, 단일 AI 비서는 고립된 질문에는 답할 수 있지만 전체 기술 스택을 자율적으로 조정해 문맥적이고 실행 가능한 답을 제공하기는 어렵다. 복잡한 ETL 파이프라인, 분산된 저장소와 권한 체계, 여러 AI 비서와 에이전트를 함께 관리하는 일도 최종 사용자에게 추가 부담을 만든다. 완전한 사용자 정의 다중 에이전트 체계를 처음부터 만들려면 커넥터, 세션 격리, 메모리, 보안, 확장, 오케스트레이션을 구현하는 데 수개월이 필요하며, 더 큰 비용은 그동안 낡거나 일부만 반영된 정보로 내려지는 의사결정이다.

4. 코드 개발에서 구성 중심 방식으로

제안된 해법은 자율형 인텔리전스 시스템 전체를 새로 개발하는 대신 아마존 베드록 에이전트코어를 중심으로 필요한 요소를 구성하는 방식이다. 에이전트코어는 오케스트레이션, 보안, 메모리, 확장을 담당하고 기업은 자신의 데이터 소스와 업무 규칙을 제공한다. 이에 따라 사라, 라지, 프리야는 어떤 시스템에서 정보가 왔는지 알 필요 없이 자연어로 질문하고, 각자의 권한과 필요에 맞게 종합된 답을 받을 수 있다. 구성 절차는 사전 구축 MCP 서버 커넥터로 기존 시스템을 연결하고, 자연어 정책 규칙으로 사용자별 조회 범위를 정의하며, 사용자가 질문하면 에이전트코어가 나머지 실행을 조정하는 세 단계로 제시된다. 핵심은 모든 통합 개발을 없애는 것이 아니라 공통 오케스트레이션과 통제 기능을 플랫폼에 맡겨 첫 번째 업무 질문에 도달하기 전 필요한 전용 개발 범위를 줄이는 데 있다.

5. 계층형 아키텍처와 시맨틱 탐색

아키텍처는 사용자 인터페이스, 지능과 오케스트레이션, 도구 실행, 데이터 접근을 분리하는 다섯 계층으로 구성되며, 각 계층을 독립적으로 확장하거나 교체할 수 있도록 설계된다. 자연어 질문은 의도 분류와 응답 합성 과정을 거쳐 에이전트코어로 전달되고, 모든 상호작용은 인증, 정책, 메모리, 에이전트 실행을 통과한 뒤 데이터 소스에 도달한다. 에이전트코어 내부에는 격리된 실행 환경, 게이트웨이, 신원·정책 적용, 영속 메모리, 통제된 도구 레지스트리가 배치된다. 에이전트는 커넥터를 선택하기 전에 세이지메이커 데이터 카탈로그 기반 시맨틱 계층을 조회해 기업에 어떤 데이터가 있고 어디에 저장되어 있는지 파악한다. 이 메타데이터를 이용해 장비, IoT 원격 측정, 공급망, 분석 또는 사용자 정의 MCP 커넥터로 요청을 보냄으로써, 조회 경로를 에이전트에 하드코딩하지 않고 새 소스를 카탈로그에 등록하는 방식으로 확장할 수 있다.

6. 데이터 기반과 사용자 정의 MCP 서버

데이터 기반은 아파치 아이스버그와 호환되는 개방형 아마존 세이지메이커 레이크하우스로 설명되며, S3 데이터 레이크와 S3 테이블, 레드시프트 데이터 웨어하우스, 제로 ETL로 연결된 운영 저장소를 통합한다. 사전 구축 MCP 서버 중 레드시프트 서버는 공급망 재고와 OEE 분석, S3 테이블 서버는 아이스버그 형식의 과거 데이터, 오로라 PostgreSQL 서버는 장비 등록부와 유지보수 이력 조회를 담당한다. 사전 구축 옵션이 없는 영역에는 타임스트림의 온도·진동·압력 시계열을 조회하는 IoT 원격 측정 서버, 오픈서치 서버리스에서 결함 패턴과 품질 문서를 검색하는 품질 분석 서버, 데이터 카탈로그 메타데이터를 조회하는 시맨틱 계층 서버를 별도로 구성한다. 본문 예시는 FastMCP로 기계 식별자, 측정 항목, 조회 기간을 입력받는 도구 인터페이스를 정의하고 AWS SDK에 실제 조회를 위임하는 형태를 보여준다. 사용자 정의 서버도 등록 후에는 사전 구축 서버와 동일하게 도구가 발견되고 호출되므로, 기존 에이전트나 오케스트레이션 로직을 바꾸지 않고 특수 시스템을 점진적으로 추가할 수 있다.

7. MCP 도구 체계와 연결 범위

모델 콘텍스트 프로토콜인 MCP는 AI 에이전트가 도구를 발견하고 호출하는 방법을 규정하는 개방형 표준이며, 장비 상태, IoT 원격 측정, 공급망, 품질 관리 같은 업무 영역을 각각 전용 서버로 표현한다. 각 서버는 장비 상태 조회, 이상 감지, 부품 재고 확인처럼 이름, 입력 형식, 설명이 정의된 도구를 노출하고 에이전트는 API를 호출하듯 이를 사용한다. 연결 대상에는 세이지메이커 카탈로그의 시맨틱 저장소, 오로라와 RDS 같은 관계형 데이터베이스, 실시간 센서와 이벤트용 MSK, 의미·키워드 혼합 검색을 지원하는 오픈서치, 제로 ETL로 통합되는 레이크하우스와 웨어하우스가 포함된다. 세일즈포스, SAP, 서비스나우 같은 외부 서비스도 에이전트코어 게이트웨이의 OAuth 통합을 통해 REST 또는 GraphQL API로 연결할 수 있다. MCP 서버는 기본적으로 호출마다 독립적인 무상태 방식으로 실행하거나, 한 세션에서 중간 결과를 유지해야 하는 다단계 작업을 위해 상태 유지 방식으로 운영할 수 있다.

8. MCP의 장단점과 게이트웨이 역할

MCP 구조의 장점은 서버 간 결합도가 낮아 CRM 커넥터를 수정해도 IoT 커넥터를 건드릴 필요가 없고, 각 서버가 자신의 스키마와 인증 문맥을 책임진다는 점이다. 사전 구축 커넥터는 공통 데이터 소스의 연결 시간을 줄이며, 개방형 MCP 표준은 에이전트코어와 호환되는 서버를 다른 MCP 환경에서도 활용할 수 있게 한다. 반면 사전 구축 커넥터가 없는 사용자 정의·레거시 시스템은 한 차례의 저코드 템플릿 설정이 필요하고, 상태 유지형 서버는 수평 확장 환경에서 세션 선호도를 신중하게 설계해야 한다. 서버가 추가될 때마다 감시하고 버전을 관리해야 할 엔드포인트도 늘어나므로, 본문은 커넥터 종류와 관계없이 게이트웨이를 통한 연결을 고려하라고 제안한다. 게이트웨이는 모든 에이전트-도구 호출의 단일 진입점으로서 새 MCP 서버와 프로토콜 핸드셰이크를 수행하고 도구 이름, 입력 스키마, 설명을 색인한 뒤, 에이전트가 서버 주소를 알지 않아도 도구 이름에 따라 적절한 서버로 요청을 전달한다.

🧾 핵심 주장 / 시사점

• 사례의 병목은 원천 데이터 부족이 아니라 시스템별 문맥, 최신성, 권한이 분리된 데 있으며, 중앙 오케스트레이션은 이 요소들을 사용자별 정책 아래 한 응답으로 결합하려는 접근이다.
• 시맨틱 계층에서 데이터 위치를 먼저 발견하고 MCP 서버가 실제 데이터를 조회하도록 역할을 나누면, 데이터 소스 추가가 에이전트 코드 변경보다 카탈로그 등록과 커넥터 구성의 문제가 된다.
• MCP의 독립 배포와 공통 도구 규격은 연결 확장성을 높이지만, 서버 수 증가에 따른 관측·버전 관리와 상태 유지형 세션의 확장 설계는 별도의 운영 과제로 남는다.

✅ 액션 아이템

• 메타데이터 탐색과 실제 데이터 조회를 분리해 카탈로그 등록만으로 새 소스를 확장할 수 있는지 점검한다.
• 관리자·현장 감독자·정비 기술자별 접근 권한과 데이터 최신성 차이를 에이전트 권한 적용 범위에 맞춰 정의한다.
• 사용자 정의 MCP 커넥터 설정, 상태 유지형 세션 선호도, 엔드포인트 모니터링·버전 관리 범위를 정한다.

❓ 열린 질문

• 사전 구축 MCP로 먼저 연결할 공통 시스템과 사용자 정의 MCP가 필요한 특수·레거시 시스템의 경계는 어디인가?
• 세이지메이커 데이터 카탈로그 시맨틱 계층에 등록할 최소 메타데이터 기준은 무엇인가?
• 역할별 권한과 데이터 최신성 차이가 응답 합성 품질에 미치는 영향을 어떻게 판단할 것인가?