VMS Solutions의 AI Agent 기반 내부 생산성 개선기: Strands Agents를 통한 자체 에이전트 구축 여정

VMS Solutions (브이엠에스 솔루션스)는 반도체와 디스플레이 제조 공정의 생산 계획을 최적화하는 AI 솔루션 기업으로, 2024년 가트너 아시아태평양 Supply Chain Planning 분야 Notable Vendor로 선정되었습니다. 25년 이상 글로벌 제조업체의 공급망 최적화를 지원해온 VMS Solutions는 이제 자사 내부에도 AI 혁신을 적용하고 있습니다. 그 결과물이 바로 인프라 운영과 개발 관련 질의를 자동화하는 AI 에이전트 기반 챗봇 솔루션 ‘AIto’입니다.

이 블로그에서는 Strands SDK와 Amazon Bedrock을 활용하여 AIto를 구현한 배경과 상세한 구현 과정을 공유합니다.

사내 AI Agent ‘AIto’를 개발하게 된 이유

VMS Solutions의 IT 팀들은 AWS 인프라, 온프레미스 고객사 정보 시스템, 사내 메타데이터 표준 툴 등 여러 관리 도구를 운영하고 있습니다. 각 시스템마다 사용법과 접근 방식이 다르다 보니 새로운 팀원의 온보딩에 상당한 시간이 소요되었고, IT 팀 규모가 커지면서 공지나 매뉴얼을 공유해도 모든 인원이 숙지하기 어려운 상황이 발생했습니다.

매일 쌓이는 방대한 로그와 지표 속에서 필요한 정보를 빠르게 찾기 어려워지면서, IT팀 메신저 채널에서는 다음과 같은 질문이 반복되곤 했습니다:

“현재 ECS 서비스가 정상 동작 중인가요?”
“이번에 새로 추가할 DB 테이블의 구조가 내부 메타데이터 표준을 준수하나요?”
“온프레미스 고객사의 운영 매뉴얼이나 담당 정보는 어디서 확인할 수 있나요?”

이러한 문제를 해결하고자 AI 에이전트 기반 챗봇 ‘AIto’ 개발을 결정했고, 다음과 같은 효과를 기대했습니다:

즉각적인 정보 접근: 담당자 문의 없이 실시간으로 시스템 상태 확인
일관된 정보 제공: 표준화된 답변으로 커뮤니케이션 오류 최소화
IT 팀 리소스 절감: 반복적인 질의응답에서 벗어나 핵심 업무에 집중

AIto란?

AIto는 “AI to you”를 줄인 이름으로, “누구나 빠르게, 정확하게, 일관된 방식으로 정보를 확인할 수 있도록 한다”를 목표로 설계된 내부 챗봇입니다.

사용자가 Slack에서 자연어로 질문하면, AIto가 의도를 분석해 적합한 에이전트를 호출하고, 현재 환경 요약과 근거 링크를 포함한 표준화된 답변을 제공합니다. 복잡한 콘솔이나 툴 사용법을 모르더라도 VMS Solutions의 개발자와 운영자라면 누구나 AIto를 통해 필요한 정보를 즉시 확인할 수 있습니다.

Figure 1. AIto 요청 수행 및 결과 예시

AIto 개발 여정

Alto는 2025년 9월 진행된 프로토타이핑 자산을 활용하여 대규모 고객을 위한 생성형 AI 솔루션 도입을 가속화하는 AWS의 고객지원 프로그램인 AWS GenAI Lab을 통해 시작되었습니다. 이 프로그램에서 검증된 RAG 기반의 GenAI Chatbot 아키텍처를 AWS CDK형태로 제공 받을 수 있었고, 이는 Alto가 필요한 성능과 기능을 빠르게 검증하고 발전시켜나가는데 밑바탕이 되었습니다.

1단계: RAG 기반 프로토타입

처음에는 사내에서 수집한 다양한 운영/개발 요구사항을 문서로 정리하고, 해당 문서를 Bedrock Knowledge Bases에 올려 RAG (검색 증강 생성) 기반 챗봇을 제작했습니다. 이 초기 구조는 빠르게 구현할 수 있다는 장점이 있었지만, 실제 실무 단계에서는 다음과 같은 한계가 드러났습니다.

Knowledge base 기반 응답의 정합성 문제: 미리 올려둔 문서 내용을 기반으로 답변하다 보니 최신 인프라 상태나 실시간 데이터와 불일치하는 경우가 많았습니다. (예: “현재 ECS 서비스 상태”를 묻는 질문에 과거 문서 기반 답변 제공)
단일 목적 챗봇의 확장성 부족: 요청의 성격이 다양해지면서 ‘ECS 로그 조회’, ‘DB 스키마 점검’, ‘온프레미스 운영 정보 조회’ 등 서로 다른 처리 로직을 하나의 AI 에이전트가 모두 담당해야 했습니다.

2단계: MCP 기반 실시간 데이터 연동

이러한 문제를 해결하기 위해 개발팀은 AIto를 RAG 중심 구조에서 MCP (Model Context Protocol) 기반의 AI Agent 구조로 전환했습니다.

기존 RAG 기반 챗봇이 사전에 Knowledge base에 올려둔 문서를 LLM이 검색/참고하여 답변하는 구조였다면, 새로운 AI Agent 기반의 구조는 실제 시스템 (AWS, PostgreSQL, Notion 등)에 연결된 MCP 서버를 통해 실시간 데이터 조회가 가능합니다.

이를 통해 아래와 같은 개선이 가능했습니다:

현재 시점의 정확한 시스템 상태 확인
근거가 명확한 답변 제공 (실제 데이터 근거 + 확인 가능한 링크)
문서 업데이트 지연으로 인한 오답 문제 해결

3단계: 멀티 에이전트 구조로 확장

요청 유형이 점점 세분화됨에 따라, 작업을 분류하고 실행 계획을 제어하는 Orchestrator Agent를 중심으로 한 멀티 에이전트 구조를 도입했습니다.

Orchestrator Agent

사용자 요청을 분석해 실행 단계를 JSON 형태로 계획합니다.
AWS Manager, Meta Manager, OnPrem Manager 중 필요한 전담 에이전트를 순차 호출합니다.

전문 에이전트들

AWS Manager Agent: AWS 리소스 진단 전문 (ECS, RDS, Lambda 등)
Metadata Manager Agent (이하 Meta Manager): DB 데이터의 메타데이터 표준 준수 여부 확인
OnPrem Manager Agent: 온프레미스 고객사 운영 정보 조회

이렇게 구조를 개선하면서 AIto는 더 이상 “문서 기반 챗봇”이 아닌, 실제 시스템과 연결되어 즉시 진단/조회가 가능한 멀티 에이전트 솔루션으로 발전했습니다.

최종 솔루션 개요

AIto는 Slack에서 작동하는 대화형 멀티 에이전트 시스템입니다. 사용자가 자연어로 질문하면 AIto가 자동으로 요청을 이해하고, 필요한 에이전트들을 순차적으로 호출하여 답변을 제공합니다.

실제 사용 예시: “PRD와 DEV 환경의 ECS 서비스를 비교해줘”

이 요청이 AIto 내부에서 어떻게 처리되는지 살펴보겠습니다.

1. 사용자 입력

사용자가 Slack에 “PRD와 DEV 환경의 ECS 서비스를 비교해줘”라고 입력합니다.

2. Orchestrator가 실행 계획 수립

메시지는 내부 API를 통해 Orchestrator Agent로 전달됩니다. Orchestrator는 문장을 분석해 “두 환경의 ECS 서비스를 비교하고 싶다”라는 의도를 파악하고, 다음과 같은 실행 계획을 세웁니다:

[
    { "agent": "AWS Manager", "env": "PRD", "task": "ECS Service List" },
    { "agent": "AWS Manager", "env": "DEV", "task": "ECS Service List" },
    { "agent": "Orchestrator", "task": "Compare Results" }
]

이 계획에 따라 Orchestrator는 순차적으로 두 개의 AWS Manager를 호출한 뒤, 직접 결과를 비교합니다.

3. 전문 에이전트들이 순차 실행

(1단계) AWS Manager (PRD 환경): PRD 환경의 ECS 서비스 목록과 상태를 조회합니다.
(2단계) AWS Manager (DEV 환경): DEV 환경의 동일한 서비스 정보를 수집합니다.
(3단계) Orchestrator 비교 분석: 두 결과를 병합하여 서비스별 Desired/Running 차이, 태스크 정의 버전, 헬스 상태 차이를 분석합니다.

4. 결과 요약 및 전달

Orchestrator는 비교 결과를 표준화된 형식으로 정리합니다:

주요 발견 사항 요약
상세 정보 확인을 위한 링크 (예: AWS ECS 콘솔 링크)

이 모든 과정은 몇 분 안에 자동으로 처리되며, 사용자는 Slack에서 바로 결과를 확인할 수 있습니다.

솔루션 아키텍처

AIto가 어떤 아키텍처로 구현되었는지 자세히 알아보겠습니다. 아래는 AIto의 아키텍처 다이어그램으로, 위에서 설명한 Orchestrator 에이전트와 3가지 전문 에이전트들 (AWS Manager, Meta Manager, OnPrem Manager) 간의 흐름이 어떤 서비스로 구현되었는지를 나타냅니다.

Figure 2. AIto 솔루션 아키텍처

AIto를 설계할 때 Strands SDK의 멀티에이전트 패턴 중 Agents-as-tools 패턴을 활용했습니다. Agents-as-Tools 패턴은 전문화된 에이전트를 도구로 래핑하여 Orchestrator 에이전트가 필요에 따라 호출할 수 있게 하는 방식입니다. 하나의 요청이 들어오면 Orchestrator Agent가 실행계획을 세우고, 전담 에이전트들을 순차적으로 호출하여 각자의 도메인 (AWS 환경, 메타데이터, 온프레미스 정보)을 처리합니다.

모든 에이전트는 Amazon Bedrock에서 제공하는 Claude Sonnet 4.0 모델을 LLM으로 사용하며, 외부 시스템과의 연결은 MCP (Model Context Protocol)를 통해 이루어집니다. 사용하는 MCP 서버들 (mcp-aws-dev, mcp-aws-stg, mcp-aws-prd, mcp-postgres, mcp-notion)은 Docker 컨테이너로 독립 배포되어 있으며, 각 에이전트는 HTTP API를 통해 해당 MCP 서버와 통신합니다. 이 방식은 컨테이너 단위로 손쉽게 확장·배포할 수 있고, 언어나 프레임워크에 구애받지 않는 장점이 있어 선택하게 되었습니다.

구성요소	역할	AIto에서의 선택 이유
LLM Adapter	여러 LLM 엔진 연동을 위한 인터페이스	Bedrock 선택 — AWS 환경과의 통합성과 보안성이 우수
MCP Connector	외부 시스템 연결용 통신 모듈 (HTTP, WebSocket, gRPC 등 지원)	HTTP 선택 — 단순성, 방화벽 호환성, Docker 컨테이너 간 통신 안정성
Context Manager	에이전트 간 상태 및 결과 공유 관리	미사용 — 각 요청을 독립 실행 구조로 설계하여 단순화

구현 상세 1: Orchestrator Agent

Orchestrator 에이전트는 AIto의 두뇌 역할을 담당합니다. 사용자와 직접 대화하며 자연어 요청의 의도를 파악하고, 필요한 작업을 계획한 뒤, 적절한 전문 에이전트들을 순차적으로 호출합니다. 무엇보다 사람이 읽기 쉬운 형태로 응답을 표준화하는 데 중점을 두었습니다.

핵심 역할

요청 분석 및 실행 계획 수립: 사용자가 입력한 질문을 분석하여 단순 조회인지, 여러 단계가 필요한 복합 요청인지 판단합니다. 예를 들어 “PRD 환경의 ECS 상태 알려줘”는 단일 스텝으로 처리하지만, “PRD와 DEV 환경의 ECS 서비스를 비교해줘”는 두 환경을 각각 조회한 뒤 비교하는 다중 스텝 계획을 수립합니다.
에이전트 조율 및 결과 종합: 실행 계획에 따라 AWS Manager, Meta Manager, OnPrem Manager 등 전문 에이전트들을 순차적으로 호출하고, 각 에이전트의 응답을 취합하여 하나의 일관된 답변으로 정리합니다.

프롬프트 (요약)

## 역할
당신은 VMS Solutions IT팀의 Orchestrator Agent입니다. 사용자의 요청을 분석하여 실행 계획을 JSON 형태로 생성하고, 필요한 전문 에이전트(AWS Manager, Meta Manager, OnPrem Manager)를 순차적으로 호출한 뒤 결과를 종합하여 답변합니다.

## 프롬프트 해석 가이드
요청에 "비교", "동시에", "각 환경", "모두"와 같은 키워드가 포함되면 Multi-step 모드로 전환하여 여러 에이전트를 호출하고, 그렇지 않으면 Single-step 모드로 단일 조회를 수행합니다.

## 응답 포맷
모든 응답은 Slack에 최적화된 형식으로 작성해야 하며, 글자 수는 2,000자 이내로 제한하고 Markdown 문법 중 굵은 글씨, 코드 블록, 링크만 사용합니다. 표나 리스트는 최대 5개 항목까지만 표시하고 그 이상은 "외 N건"으로 축약합니다. 답변 구조는 (1) 조회한 환경 정보, (2) 핵심 결과 요약, (3) 상세 확인을 위한 근거 링크 순서로 일관되게 제공합니다.

구현 코드 (일부)

위에서 만든 프롬프트는 아래와 같이 세팅하여 각 agent별로 적용합니다.

def __init__(self):
    """Initialize agent factory."""
    # 중앙집중화된 Agent 설정
    self._agent_configs = {
        "orchestrator": {"name": "OrchestratorAgent", "prompt_file": "orchestrator.md", "mcp_servers": []},
        "metamanager": {
            "name": "MetaManagerAgent",
            "prompt_file": "meta_manager.md",
            "mcp_servers": ["mcp-postgres"],
        },
        "awsmanager": {
            "name": "AWSManagerAgent",
            "prompt_file": "aws_manager.md",
            "mcp_servers": ["mcp-aws-dev", "mcp-aws-stg", "mcp-aws-prd"],
        },
        "onpremmanager": {
            "name": "OnPremManagerAgent",
            "prompt_file": "onprem_manager.md",
            "mcp_servers": ["mcp-notion"],
        }
    }

for config in self._agent_configs:
    # Load prompt for the agent type
    prompt = self._load_prompt(config["prompt_file"])
    if not prompt:
        logger.error(f"Could not load prompt")
        return None

    # Create Bedrock model
    model = BedrockModel(
        model_id=settings.bedrock.model_id,
        region_name=settings.aws_default_region,
        max_tokens=settings.bedrock.max_tokens,
        temperature=settings.bedrock.temperature,
    )

    # Create agent with loaded prompt
    agent = Agent(name=config["name"], model=model, system_prompt=prompt)

구현 상세 2: AWS Manager Agent (AWS MCP Servers 활용)

AWS Manager Agent는 AWS 환경의 주요 리소스(ECS, RDS, CloudWatch 등)를 진단하고 상태를 실시간 조회하는 역할을 담당합니다. 환경별 리소스를 조회할 때 과부하를 최소화하기 위해 대용량 로그 분석 요청을 제한하고, 사용자가 결과를 바로 확인할 수 있도록 모든 응답에 AWS Console 링크를 자동으로 추가했습니다.

프롬프트 (일부)

## 역할
당신은 VMS Solutions IT팀의 **AWS Manager Agent**입니다. ECS, RDS, CloudWatch 등 주요 리소스의 상태를 실시간 조회하고, 표준 포맷으로 요약된 결과와 근거 링크를 제공합니다.

## 프롬프트 해석 가이드
장기 실행(10분 이상) 또는 대용량 로그 요청은 제한합니다.
"장애", "느리다", "timeout" 등의 키워드는 자동으로 장애 진단 모드로 전환합니다.
결과 구성은 **환경 / 주요 지표 / 이벤트 / 근거 링크** 순서를 따릅니다.

## 응답 포맷
요약된 표준 포맷을 유지하며, 결과는 **환경 → 주요 지표 → 이벤트 → 근거 링크** 순서로 제공합니다.

구현 상세 3: Meta Manager Agent (PostgreSQL MCP 활용)

Meta Manager Agent는 내부에서 정의한 메타데이터 표준 규칙에 따라 DB 테이블 구조의 적합성을 검증하는 역할을 수행합니다. 다양한 표준 검증 규칙을 일일이 프롬프트에 포함하기 어려웠던 문제를 해결하기 위해, 검증 기준을 별도의 KB 문서로 정리하고 해당 문서를 참조하도록 설계했습니다.

프롬프트 (일부)

## 역할
당신은 VMS Solutions의 **Meta Manager Agent**입니다. PostgreSQL MCP를 통해 테이블 구조를 조회한 뒤, 내부 표준 규칙에 따라 스키마를 검증하고 그 결과를 정리합니다.

## 프롬프트 해석 가이드
- 항상 **PostgreSQL MCP**를 통해 테이블 구조·인덱스 정보를 조회한 결과를 기반으로만 분석합니다.
- LLM은 **직접 쿼리를 실행하지 않고**, MCP가 반환한 값을 바탕으로 **요약·설명·판정**만 수행합니다.
- 검증 시 아래 **KB-MM 문서**를 순차적으로 참조합니다.
  - **KB-MM-001**: 응답 포맷
  - **KB-MM-002**: 컬럼 네이밍 규칙
  - **KB-MM-003**: 데이터타입 표준
  - **KB-MM-004**: 인덱스 정책
  - **KB-MM-005**: 예외 처리 규칙

## 응답 포맷
- 응답 전체 구조와 표현 방식은 **KB-MM-001(응답 포맷)**을 따릅니다.
- MCP 응답값을 기준으로 규칙 위반 여부를 판정하고, 각 위반 항목을 **경미 / 주의 / 중대** 등급으로 분류하여 제공합니다.

구현 상세 4: OnPrem Manager Agent (Notion MCP Server 활용)

OnPrem Manager Agent는 온프레미스 고객사별 운영 정보를 조회하고, 내부 전용 매뉴얼·담당자 정보를 효율적으로 탐색하는 역할을 담당합니다. Notion 내에 다양한 문서가 산재해 있어 검색 효율이 떨어졌던 문제를 해결하기 위해, 특정 온프레미스 전용 페이지만 참조하도록 고정하고, 민감정보를 자동으로 마스킹 처리해 불필요한 검색을 방지했습니다.

프롬프트 (일부)

## 역할
당신은 VMS Solutions의 **OnPrem Manager Agent**입니다. Notion MCP를 통해 온프레미스 운영 정보를 조회하고 필요한 내용을 요약합니다.

## 프롬프트 해석 가이드
- 항상 **지정된 온프레미스 전용 Notion 페이지 ID**만 참조하여 정보를 가져옵니다.
- 설치 절차, 버전 요건, 담당 채널, 트러블슈팅 정보를 중심으로 요약합니다.

## 응답 포맷
- 필요한 정보만 간결하게 정리하며, 요약은 Notion MCP에서 조회된 내용 기반으로만 작성합니다.
- 모든 응답의 마지막에는 반드시 다음 문구를 포함합니다:
  **"⚠️ 일부 정보는 보안상 마스킹되었습니다."**

구현 결과

1. AIto 질의 및 응답 과정

Figure 3. AIto 질의 및 응답 과정 스크린샷

2. AIto 응답 결과

Figure 4. AIto 응답 결과 스크린샷

Figure 4. AIto 응답 결과 스크린샷

VMS Solutions 팀이 Strands SDK를 사용한 이유

AIto를 개발하면서 팀은 LangChain과 Strands SDK를 비교 검토했습니다.

LangChain은 풍부한 생태계와 다양한 도구 연동을 제공하지만, 멀티 에이전트 구조를 구현하려면 LangGraph를 추가로 구성해야 하고 실행 흐름 관리가 복잡해질 수 있다는 우려가 있었습니다. 반면 Strands SDK는 멀티 에이전트 구조에 최적화되어 있으며, Agent 간 협업과 도구 호출 기능이 기본 내장되어 있어 복잡한 그래프 설계 없이도 에이전트를 쉽게 구성할 수 있었습니다. 특히 SDK가 제공하는 MCP Connector를 통해 AWS, PostgreSQL, Notion 등 다양한 시스템을 간결하게 통합할 수 있었고, 각 Agent를 독립된 컨테이너 단위로 운영할 수 있어 개발과 유지보수 모두 효율적이었습니다. 결과적으로 Strands SDK는 간결한 구조와 빠른 구현 속도를 제공하면서도, 멀티에이전트 시스템을 안정적으로 운영할 수 있는 실용적인 선택이었습니다.

VMS Solutions 팀이 Amazon Bedrock을 선택한 이유

AIto는 여러 에이전트가 각각 LLM을 호출하는 구조입니다. 이를 안정적으로 운영하려면 보안성, 확장성, 운영 효율성을 동시에 충족하는 LLM 플랫폼이 필요했습니다. Amazon Bedrock은 여러 LLM 모델들을 단일 인터페이스로 지원하기에 모델 변경 시 별도의 API 추가 관리가 필요없어 확장성이 뛰어났습니다. 또한 Bedrock은 AWS 환경 내에서 완전관리형으로 운영되기 때문에, 데이터가 외부로 나가지 않으며 내부 보안 규정을 그대로 유지할 수 있는 점이 가장 큰 장점이었습니다. 이 덕분에 보안, 운영 효율, 확장성 측면에서 균형 잡힌 인프라를 확보할 수 있었으며, Strands SDK와의 조합으로 멀티 에이전트 구조를 안정적이고 관리 가능한 형태로 구현할 수 있었습니다.

도입 후 개선 효과

AIto 도입 이후, 사내 문의 대응 방식이 눈에 띄게 개선되었습니다. 기존에는 환경별 서비스 상태나 데이터베이스 구조, 온프레미스 운영 관련 문의가 비슷한 형태로 반복되어 동일한 질문이 여러 번 재발생하는 경우가 많았습니다.

AIto 도입 후에는 이러한 단순 질의의 약 80% 이상이 챗봇을 통해 자동 응답으로 해결되었으며, 운영 담당자와 개발자 모두 별도의 러닝커브 없이 Slack을 통해 손쉽게 환경 상태를 확인할 수 있게 되었습니다. 특히 AWS 리소스 점검이나 메타데이터 검증 업무에서 기존 5~10분이 걸리던 수동 확인 절차가 평균 1분 이내로 단축되었습니다.

정성적인 측면에서도 변화가 뚜렷했습니다. 내부에서는 “AIto를 통해 답변을 찾는 시간이 짧아졌다”, “과거에는 다른 팀에 직접 문의하거나 도움을 요청하는 것이 다소 부담스러웠지만 이제는 챗봇을 통해 자연스럽게 필요한 정보를 확인할 수 있다”는 피드백이 꾸준히 이어지고 있습니다.

AIto는 이제 사내 구성원 누구나 동일한 기준으로 정보를 확인할 수 있는 업무 표준화의 기반으로 자리 잡았습니다.

향후 계획

VMS Solutions 인프라팀은 AIto를 단순한 사내 챗봇이 아닌, 운영·개발 전반을 지원하는 통합 에이전트 허브로 발전시키는 것을 목표로 하고 있습니다.

우선, 현재 AWS Manager Agent의 구조를 개선하여 장기 실행(10분 이상) · 대용량 로그 요청 제한 문제를 해결하고, 대규모 데이터 처리와 부하 분산이 가능한 형태로 확장할 계획입니다. 이를 통해 향후 더 복잡한 진단이나 로그 분석 요청도 안정적으로 수행할 수 있도록 할 예정입니다.

또한, 사내 구성원이 손쉽게 새로운 Agent를 추가하고 테스트할 수 있도록 AIto의 기본 구조를 개선해 에이전트 확장성을 내장한 플랫폼 형태로 발전시킬 예정입니다. 이를 통해 팀별로 필요한 기능(예를 들어 CI/CD 배포 이력 관리, 보안 점검 자동화, 비용 분석 지원)을 현재의 담당 팀이 직접 개발하지 않더라도, 각 구성원이 독립적으로 구현하고 연결할 수 있는 환경을 마련하고자 합니다.

아울러, AIto가 사내 주요 시스템 전반의 데이터를 통합적으로 다룰 수 있도록 MCP 서버 구조를 고도화할 계획입니다. 이로써 환경별, 시스템별 데이터 접근 경로를 일원화하고, 모든 에이전트가 동일한 데이터 표준을 기반으로 동작할 수 있는 기반을 구축할 것입니다.

장기적으로는 AIto가 단순 질의응답을 넘어, 운영자의 의도를 이해하고 실행 가능한 액션을 제안하는 실행형 시스템으로 발전하도록 Bedrock 기반의 워크플로 자동화와 LLM 개선 실험을 지속적으로 추진할 계획입니다.

AWS 기술 블로그

VMS Solutions의 AI Agent 기반 내부 생산성 개선기: Strands Agents를 통한 자체 에이전트 구축 여정

사내 AI Agent ‘AIto’를 개발하게 된 이유

AIto란?

AIto 개발 여정

1단계: RAG 기반 프로토타입

2단계: MCP 기반 실시간 데이터 연동

3단계: 멀티 에이전트 구조로 확장

최종 솔루션 개요

실제 사용 예시: “PRD와 DEV 환경의 ECS 서비스를 비교해줘”

솔루션 아키텍처

구현 상세 1: Orchestrator Agent

핵심 역할

프롬프트 (요약)

구현 코드 (일부)

구현 상세 2: AWS Manager Agent (AWS MCP Servers 활용)

프롬프트 (일부)

구현 상세 3: Meta Manager Agent (PostgreSQL MCP 활용)

프롬프트 (일부)

구현 상세 4: OnPrem Manager Agent (Notion MCP Server 활용)

프롬프트 (일부)

구현 결과

1. AIto 질의 및 응답 과정

2. AIto 응답 결과

VMS Solutions 팀이 Strands SDK를 사용한 이유

VMS Solutions 팀이 Amazon Bedrock을 선택한 이유

도입 후 개선 효과

향후 계획

Authors

주요 링크 모음

팔로우하기

알아보기

리소스

개발자

도움말