---
title: 멀티 에이전트란
description: 멀티에이전트의 개념 설명, 장점, 실제 구축을 통한 경험 공유를 세미나에서 발표하기 위한 발표 스크립트 및 발표자료 작성용 문서입니다.
---
# AI Agent란?

## General
AI 에이전트(AI Agent)는 단순히 사용자의 텍스트 입력을 받아 응답을 생성하는 대화형 인터페이스(Chatbot)를 넘어, 주어진 최종 목표(Goal)를 자율적으로 달성하기 위해 환경을 인식(Perceive)하고, 스스로 계획(Planning) 및 추론(Reasoning)하며, 도구를 사용해 물리적/디지털적 행동(Action)을 수행하는 LLM 기반 소프트웨어 시스템입니다.

LLM 기반 에이전트 시스템 아키텍처는 크게 다음 3가지 핵심 요소로 구성됩니다:
1. **Planning (계획 및 추론)**
   - **Task Decomposition (작업 분해)**: 거대하고 복잡한 목표를 실행 가능한 작은 단위의 세부 태스크로 쪼갭니다. (예: Chain of Thought, Tree of Thoughts 등)
   - **Self-Reflection (자기 성찰 및 피드백)**: 행동의 결과를 스스로 분석하고 실수를 교정하여 향후 계획을 실시간으로 수정합니다. (예: ReAct, Reflexion 프레임워크)
2. **Memory (기억 장치)**
   - **Short-term Memory (단기 기억)**: 현재 대화나 컨텍스트 윈도우 내에서 실시간으로 유지되는 즉각적인 대화 맥락 정보입니다.
   - **Long-term Memory (장기 기억)**: 외부 데이터베이스나 벡터 DB(Vector DB) 등을 활용하여 과거 대화 기록, 대량의 지식을 인덱싱하고 필요시 RAG(검색 증강 생성) 기법으로 다시 불러오는 정보 보존 공간입니다.
3. **Tool Use (도구 활용)**
   - 에이전트가 학습되지 않은 외부 정보에 접근하거나 외부 시스템에 영향을 미치기 위해 계산기, 코드 실행용 샌드박스, 웹 브라우저, 외부 API 등을 주도적으로 호출하는 능력입니다.

	   ![[assets/images/Screenshot 2026-06-25 at 9.39.07 pm.png]]

## AI Agent를 더욱 강력하게 만드는 Skills
Skills(기술/도구 패키지)는 AI 에이전트가 외부 환경과 동적으로 상호작용할 수 있도록 결합하는 기능적 실행 모듈입니다. 단순히 LLM에게 행동 지침을 주는 프롬프트 엔지니어링 수준을 넘어, 에이전트가 특정 목표를 위해 직접 실행할 수 있는 코드, 도구의 명세 스키마(Tool Schema), 사용 설명 및 예시(Few-shot Examples) 등이 하나의 단위로 패키징된 자율적 확장 도구 모음입니다.
- **동적 모듈화**: 에이전트는 상황에 따라 특정 기술을 필요할 때 로드하여 사용하고 완료 후 반환합니다.
- **작업 수행 한계 돌파**: 텍스트 생성이라는 언어 모델 자체의 한계를 넘어, 시스템 레벨의 파일 제어, 서버 배포, 물리 데이터 수집 등의 적극적인 업무 대행 능력을 에이전트에 제공합니다.

## Claude cowork와 code
- AI Agent의 대표 주자인 Claude는 Claude desktop 이라는 프로그램으로 자신들의 뛰어난 모델을 서비스하고 있으며, Claude Desktop App에서 우리는 Claude Cowork와 Claude Code라는 다른 서비스를 사용할 수 있음
- Claude Cowork와 Claude Code는 같은 모델을 사용하지만 작동하는 방식이 완전히 다름. Claude Cowork의 경우 사무 작업 등 일상적인 업무의 비서 역할을 수행하며, Claude Code는 Coding 작업에 특화된 Coding Agent라고 소개함
- 두 서비스는 동일하게 내부 컴퓨터의 특정 디렉터리에서 작업을 수행하지만 내부적인 작동 절차를 확인해보면 Claude Cowork는 Cloud에서 모델이 필요한 기능을 제공하여 pdf, word, excel, ppt 등 다양한 파일을 읽고 쓸 수 있도록 AI 모델의 기능을 확장한 서비스임
- 반면에 Claude Code는 필요한 모듈, 소프트웨어가 있다면 Local Computer에 설치해서 사용한다는 차이점이 있음.

	![[assets/images/Screenshot 2026-06-25 at 10.04.54 pm.png]]

- Claude Cowork와 Claude Code를 비교하면 Claude Cowork가 더 좋아보일 수 있지만 Claude Code를 잘 조련하면 Claude Cowork 보다 훨씬 좋은 결과를 기대할 수 있음.



## Skills 사례 소개
에이전트가 업무 현장에서 유용하게 사용하는 대표적인 Skills 사례들은 다음과 같습니다:
1. **코드베이스 분석 및 관리 Skill**
   - 프로젝트 소스코드를 탐색(Grep), 특정 코드 조각을 치환(File replace), 변경 사항 검증(Linting), 최종 커밋 및 푸시 등을 처리하는 개발 자동화 Skill입니다.
2. **브라우저 자동화 및 스크래핑 Skill**
   - 헤드리스 브라우저(Playwright, Puppeteer 등)를 기동하여 실시간 웹 트렌드 조사, 경쟁사 데이터 수집, 웹 UI에 대한 QA 테스트를 자율적으로 수행하는 Skill입니다.
3. **인프라스트럭처 제어 및 DevOps Skill**
   - 클라우드 환경(AWS, GCP 등)이나 Firebase Hosting, Cloud Firestore 등과 같은 서버리스 백엔드 서비스의 배포 및 데이터베이스 규칙 수정을 지원하는 시스템 운영용 Skill입니다.
4. **학술/도메인 특화 API Skill**
   - 생화학 데이터베이스(ChEMBL), 의학 학술 논문(PubMed, arXiv), 유전학 정보(dbSNP, ClinVar) 등 전문 영역의 연구용 OpenAPI와 연동하여 자율 연구원(Researcher) 역할을 돕는 조사용 Skill입니다.

### Github를 점령한 Skills
![[assets/images/Screenshot 2026-06-25 at 9.43.29 pm.png]]

### Understand skill
Turn any codebase, knowledge base, or docs into an interactive knowledge graph you can explore, search, and ask questions about.
![[assets/images/Screenshot 2026-06-25 at 9.41.27 pm.png|927]]

### 유행이라 개발해본 multi-agent-mux skill

![[assets/images/Screenshot 2026-06-25 at 9.45.01 pm.png]]

![[assets/images/Recording Jun 25, 2026 - 11_56 AM.mp4]]



# Multi-Agent란

## General
멀티 에이전트(Multi-Agent) 시스템은 단일 에이전트(Single Agent)의 한계를 극복하기 위해, 서로 다른 페르소나와 전문 도구(Skills)를 갖춘 여러 개의 에이전트들이 협력 네트워크를 형성하여 복잡한 목표를 조율(Orchestration)하고 분할 해결하는 구조입니다.

단일 에이전트는 대규모 컨텍스트를 처리할 때 정보 누락(Lost in the middle) 현상이 발생하기 쉽고, 여러 도구를 한꺼번에 다루어야 할 때 환각(Hallucination)율이 증가하는 문제가 있습니다. 멀티 에이전트의 필요성은 다음과 같습니다:
1. **분할 정복 (Divide and Conquer)**: 하나의 거대한 프로젝트를 설계, 구현, 검증, 연구 등의 독립적인 세부 태스크로 분산시켜 병렬 및 정밀 처리를 지원합니다.
2. **역할 정의 및 노이즈 최소화 (Role Specialization)**: 각 에이전트에게 한정된 역할(예: PM, Developer, QA, Researcher)과 타겟 도구만 부여하므로, 불필요한 프롬프트 노이즈를 제어하고 추론 정확도를 극대화할 수 있습니다.
3. **이종 모델 융합 및 교차 검증**: 서로 다른 LLM을 각 역할에 최적화하여 융합 배치하고, 상호 비평 및 검토 루프를 구현함으로써 최종 결과물의 신뢰성을 극대화합니다.

## Multi Agent의 예시

### Subagent란
Subagent는 부모 에이전트(Parent Agent 또는 Orchestrator)에 의해 동적으로 생성되어 특정 국소적이고 독립적인 태스크를 대행한 뒤, 결과를 상위로 반환하고 소멸하는 종속형 에이전트입니다.
- **컨텍스트 격리**: 상위 에이전트의 전체 대화 컨텍스트를 오염시키지 않기 위해 하위 작업의 맥락만을 분기(Branch)하여 처리함으로써, 에이전트 실행 도중 누적되는 토큰 소모량을 최적화하고 속도를 개선합니다.
- **예시**: 메인 에이전트가 "전체 코드 리팩토링"을 수행하면서, 특정 모듈에 대한 에러 복구 작업만을 subagent에게 위임하여 독립적으로 문제를 해결하게 하는 경우입니다.

![[assets/images/Pasted image 20260625224821.png|605]]

![[assets/images/Pasted image 20260625224849.png]]

### Team agent란
Team agent는 단일 계층적인 수직 구조를 넘어, 수평적이고 다양한 역할을 맡은 여러 독립 에이전트가 협의체(Crew/Team)를 구성하여 대화형 협력(Multi-agent Debate) 및 협상을 통해 목표를 완수하는 협동형 에이전트 구성 방식입니다.
- **의견 충돌 및 합의**: 특정 설계안에 대해 아키텍트 에이전트와 보안 담당 에이전트가 서로의 입장에서 논쟁(Debate)을 벌이고, 최종적으로 합의된 결과를 PM 에이전트가 도출하는 식의 인간 워크플로우 모사가 가능합니다.
- **협력적 의사결정**: 복잡한 비선형적 문제 해결에 있어 각 에이전트가 피드백을 실시간으로 주고받으며 점진적으로 답을 고도화합니다.

![[assets/images/Pasted image 20260625230135.png]]

![[assets/images/Pasted image 20260625224919.png]]

### Context Engineering (Lang Graph)란
컨텍스트 엔지니어링(Context Engineering)은 다중 에이전트 시스템에서 에이전트들 간의 대화 흐름, 전달되는 컨텍스트(State), 복잡한 제어 루프를 효율적으로 설계하고 유지하는 방법론적 학문입니다. 이를 구현하는 대표적인 상태 보존형 프레임워크가 LangGraph입니다.
- **상태 보존 및 순환 제어(Stateful & Cyclic Control)**: 단순 선형적 체인 구조를 탈피하여, 에이전트 간의 루프(반복 검증), 조건부 분기(Conditional branching), 실패 시 롤백 등을 순환형 그래프(Cyclic Graph) 구조로 관리합니다.
- **영속적 상태 관리**: 협업 과정에서 축적되는 다양한 상태 변화(State)를 중앙 저장소에서 추적 및 동기화하므로, 대형 워크플로우 도중 특정 노드가 실패하더라도 이전 상태부터 안전하게 재시작할 수 있습니다.

### CrewAI, Sana 등 Multi agent orchestration을 지원하기 위한 소프트웨어

![[assets/images/Screenshot 2026-06-25 at 10.52.04 pm.png]]
1. **CrewAI**
- 역할 기반(Role-based) 협업을 설계하는 데 특화된 프레임워크입니다. 각 에이전트에게 명확한 역할(Role), 목표(Goal), 배경 설명(Backstory)을 부여하고, 이들을 업무 프로세스(Sequential 또는 Hierarchical)에 따라 배치해 '크루(Crew)' 단위로 조율합니다.
1. **Microsoft AutoGen**
- 대중 에이전트 간 대화(Conversational Agentic Design)에 중점을 둔 프레임워크입니다. 다양한 LLM과 도구(Tools)가 연결된 여러 에이전트가 서로 대화를 주고받으며 코드 실행 및 피드백을 처리할 수 있으며, 동적 워크플로우 및 인간의 개입(Human-in-the-loop)을 풍부하게 지원합니다.
1. **BeeAI**
- BeeAI는 프레임워크 전반에서 [AI 에이전트](https://www.ibm.com/kr-ko/think/topics/ai-agents)를 탐색, 실행 및 공유할 수 있는 중앙 집중형 환경을 제공하는 [오픈소스](https://www.ibm.com/kr-ko/think/topics/open-source) 플랫폼입니다. IBM이 개발한 BeeAI는 에이전트 통신 프로토콜(ACP)을 기반으로 구축되었으며 Linux Foundation에서 호스팅됩니다. 팀은 BeeAI 프레임워크를 사용하여 사일로화된 에코시스템 외부에 에이전트를 배포할 수 있습니다.

## Multi Agent 환경 구성을 위한 Protocols

### MCP/ACP
다양한 서비스와 이종 에이전트들이 상호 작용하기 위해 필요한 개방형 표준 통신 프로토콜입니다.
- **Model Context Protocol (MCP)**: Anthropic이 2024년 11월 발표한 오픈 소스 프로토콜로, AI 애플리케이션(Host) 내부의 클라이언트(Client)가 로컬/원격의 도구(Tools), 데이터 소스(Resources), 그리고 컨텍스트 템플릿(Prompts)을 통일된 규격으로 안전하게 호출할 수 있는 공통 인터페이스입니다.
- **Agent Communication Protocol (ACP)**: IBM Research가 BeeAI 프레임워크 구동을 지원하기 위해 2025년 3월 발표했던 오픈 표준 에이전트 통신 인터페이스입니다. 이종 에이전트 간의 서비스 발견(Service Discovery), 상호작용 방법 협상, 태스크 위임 프로세스를 규격화하였으며, 이후 2025년 8월 27일 공식 깃허브 저장소가 아카이빙되며 Linux Foundation AI & Data 하위의 A2A(Agent-to-Agent) 프로토콜로 공식 통합 및 병합되었습니다.

### A2A
- **A2A (Agent-to-Agent) 프로토콜**: Google이 2025년 4월에 50여 파트너사들과 공동 발표하고 2025년 6월 Linux Foundation에 기증한 이종 에이전트 간 통합 통신 오픈 표준입니다. 서로 다른 벤더가 구현한 에이전트나 다양한 아키텍처 기반의 에이전트가 복잡한 결합 코드(Glue code) 없이도 협업 메시지를 교환하고 상태를 추적할 수 있습니다.
- **Agent Card (에이전트 카드)**: A2A 생태계에서 에이전트의 기능 명세서 역할을 하는 JSON 포맷의 표준 규격서입니다. 에이전트 카드에는 해당 에이전트의 명칭, 제공 가능한 역량(Capabilities), 호출 엔드포인트 정보, 요청 시 통과해야 하는 보안 인증 사양(Authentication) 등이 명시되어 있어 서비스 검색 시스템(Service Discovery)이 에이전트의 역할을 실시간으로 탐색할 수 있도록 돕습니다. 주로 `/.well-known/agent-card.json` 경로에서 탐색 가능하도록 배포됩니다.

# 실제 Multi Agent Orchestration을 구현하며 겪은 문제점들

![[assets/images/Pasted image 20260625230628.png]]
1. **Agent들과 각 Agent들의 세션 관리**
   - 다수의 에이전트와 그 아래에 동적으로 생성되는 subagent들의 생명주기(Lifecycle) 및 고유 식별자(UUID)를 동기화하고 상태를 지속적으로 보존하는 일관된 세션 관리 시스템이 필요합니다.
2. **에이전트 상호 탐색(Service Discovery)과 역할 식별**
   - 새로운 에이전트가 네트워크에 진입했을 때 어떤 에이전트가 어떤 과업을 처리할 수 있는지 동적으로 파악해야 합니다.
     - **마스터 - 슬레이브(Master-Slave) 방식**: 중앙 오케스트레이터가 전권을 쥐고 세션을 직접 관리 및 명령하므로 통제는 쉬우나, 오케스트레이터의 에러가 시스템 전체의 단일 실패점(SPOF)이 될 위험이 있습니다.
     - **P2P 및 보고(P2P and Report) 방식**: 에이전트들이 동등한 위치에서 협상하며 자율적으로 탐색하고, 작업 결과를 동기적으로 혹은 비동기적으로 기록 보관소에 보고하는 방식이지만 네트워크 관리 비용이 큽니다.
3. **실시간 메시징과 이벤트 예외 처리의 복잡성**
   - 태스크 위임 완료 후, 작업 결과와 성공/실패 여부를 교환하는 통신 채널이 중단되거나 유실될 수 있습니다.
     - **송신/수신 주체의 돌발 종료**: A 에이전트가 작업을 위임한 후 예상치 못하게 다운되었다가 재가동(Restart)된다면, B 에이전트가 작업을 완료한 뒤 발송한 비동기식 실시간 알람이 허공으로 날아가 결국 전체 협업 루프가 끊어집니다.
     - **무한 대기 및 리소스 누수(Deadlock & Resource Leak)**: 작업을 전달받은 subagent가 아무런 예외 통보(Timeout 또는 Error Event) 없이 갑자기 고사(Silent death)하는 경우, 작업을 위임하고 대기하던 부모 에이전트는 무한 대기(Blocking) 상태에 빠져 리소스를 계속 낭비하게 되며 시스템 모니터링에서도 이를 감지하기 어렵습니다.

# Multi Agent Orchestration 의 장점

1. **프롬프트의 간소화 및 루프 엔진의 진화**
   - 기존의 길고 장황한 단일 "Super Prompt" 엔지니어링 시대에서 벗어나, 에이전트를 구동하고 제어하는 자율 루프(Loop Architecture) 설계 중심으로 패러다임이 이동하고 있습니다.
   - *PSPDFKit 창업자이자 오픈소스 AI 에이전트 프로젝트인 OpenClaw의 크리에이터인 페터 슈타인베르거(Peter Steinberger, 2026년 초 OpenAI 합류)는 **"코딩 에이전트에 프롬프트를 더 넣지 말고, 에이전트를 구동하는 루프를 설계하라"**(Stop prompting your coding agents; start designing loops that prompt your agents)고 강조한 바 있습니다.*
   - 멀티 에이전트 구조에서는 작업 지시 PM 에이전트, 작업 수행 Worker 에이전트, 유효성 검증 Reviewer 에이전트로 나뉨으로써 프롬프트가 단편적이고 명료해집니다.
2. **컨텍스트 설명 불필요 (Context-Free Sharing)**
   - 공유 작업 환경(Shared Workspaces)과 Git 같은 버전 관리 시스템을 에이전트들이 공유하므로, 새로 합류한 에이전트에게 변경 이력이나 현재 맥락을 다시 텍스트로 설명하느라 불필요한 토큰과 대기 시간을 낭비할 필요가 없습니다.
3. **이종 모델 피드백을 통한 고품질 산출물 교차 검증**
   - 특정 한 모델 계열만으로 결과물을 짜고 동일한 계열에 검토를 시키는 것보다, 서로 다른 아키텍처와 특징을 지닌 이종 모델(예: Gemini로 작성한 내용을 Claude 기반 에이전트에게 피드백받음) 간에 상호 보완하도록 할 때 결과물의 신뢰성이 극적으로 향상됩니다. 이종 모델들이 세상을 바라보는 가중치와 강점이 다르기 때문에 보이지 않는 맹점(Blind spot)을 상호 보완해 줍니다.
4. **비용 효율적인 토큰 분배 (Cost Optimization)**
   - 모든 에이전트가 값비싼 최상위 프론티어 LLM 모델만을 사용할 필요가 없습니다. 작업의 요구 난이도와 속도, 정확성을 저울질하여 쉬운 코드 생성이나 정보 검색은 경량화된 저비용 모델(예: Gemini Flash 세대)을 탑재한 에이전트에 분산 위임하고, 고난도의 논리적 추론이 필요한 부분에만 최상위 고비용 모델을 탑재한 에이전트를 적절히 매칭함으로써 종합적인 API 비용을 효율적으로 제어할 수 있습니다.

# What We Need?
성공적인 Multi-Agent Orchestration 구현을 위해 갖추어야 할 기본 필수 구성요소들입니다:
1. **Agent 간 작업 환경 공유 (A2A의 Agent Card 기반)**
   - 특정 에이전트에게 태스크를 안전하게 위임하고 위임받기 위해선, 각 에이전트 카드를 통해 서로의 역할, 엔드포인트, 입력 명세 스키마를 신뢰할 수 있는 방식으로 확인하고 동기화할 수 있어야 합니다.
2. **에이전트 작동 인프라스트럭처 (Agent Working Infrastructure)**
   - 에이전트들이 통신에 사용할 서비스 주소와 포트를 동적으로 조회할 수 있는 서비스 디스커버리(Service Discovery) 기능 및 자동 라우팅 체계가 내재되어야 합니다.
3. **일관성 있는 워크플로우 추적 및 공유 (Issue & Workflow Tracking)**
   - 서로 다른 에이전트가 동일한 작업을 재수행할 때 동일한 프로세스와 출력을 일관되게 얻을 수 있도록 워크플로우 사양이 제어되어야 합니다. 또한 에러나 중간 정지가 일어났을 때 복구 및 추적이 용이하도록 규격화된 이슈 추적 인터페이스(Issue Tracking Interface)를 마련해야 합니다.
		
		![[assets/images/Pasted image 20260625230351.png]]

4. **고성능 양방향 메시징 시스템 (Advanced Messaging System)**
   - 고용량의 코드 블록, 이미지 및 멀티모달 센서 데이터 등을 대량으로 빠르고 정확하게 공유하기 위해서는 기존의 MQTT나 단순 메시지 큐(MQ) 방식은 토픽 세분화와 페이로드 크기 한계로 인해 통신 병목을 겪을 수밖에 없습니다.
   - 단편적인 이벤트 알림만 전송하는 구조에서 탈피하여 상세 에러 트레이스, 상태 구조체, 이미지 바이너리 등을 한꺼번에 담을 수 있는 풍부한 페이로드 지원 메시징 규격이 필수적입니다. 나아가 대용량 멀티모달 푸시(Push)와 양방향 스트리밍을 지원하기 위해 HTTP/3의 멀티 스트리밍 등 고성능 통신이 수반되어야 합니다.
5. **작업 및 태스크 관리 시스템 (Job & Task Lifecycle Controller)**
   - 하나의 부모 작업을 하위 스크럼(Scrum) 단위로 쪼개어 서브에이전트들에게 뿌려주는 라이프사이클 관리 기능이 있어야 합니다. 각 서브에이전트의 생성부터 소멸까지의 메시징 토픽과 임시 토큰을 정리해야 하며, 이 과정에서 부하를 고르게 배분하고 실력 있는 에이전트를 매칭하기 위한 로드 밸런싱(Load Balancing) 기법이 병행되어야 합니다.

## Why we need gRPC?
이러한 해결 과제와 인프라 요구사항 속에서 **gRPC (Google Remote Procedure Call)** 프로토콜은 멀티 에이전트 인프라의 핵심 백본으로 기능합니다.
1. **A2A 프로토콜과의 높은 호환성 및 스마트 팩토리/팜 최적화**
   - 개발 인터페이스 모듈은 스마트 팜, 스마트 팩토리와 같은 AIoT 서비스를 주요 타겟으로 개발되고 있습니다. 대역폭 및 성능 제약이 극심한 초경량 센서 디바이스 계층에서는 MQTT/CoAP 등을 보완적으로 혼용할 수 있으나, 상위의 데이터 수집 게이트웨이 및 엣지 연산 계층에서는 gRPC가 자율 통합 제어를 위한 강력하고 최적의 통신 프로토콜이 됩니다.
2. **고성능 멀티 모달 바이너리 스트리밍 및 Pub/Sub 네이티브 지원**
   - AIoT나 지능형 에이전트 시스템은 텍스트뿐만 아니라 고해상도 이미지, 소리 주파수 등 대량의 멀티모달 데이터를 처리합니다. HTTP/2 또는 HTTP/3 기반으로 작동하는 gRPC는 양방향 스트리밍(Bidirectional Streaming)과 Request/Response, Pub/Sub 통신 스타일을 단일 포트에서 완벽히 소화하여, 복잡한 네트워크 요구사항을 단숨에 통합시킵니다.
   - 마이크로서비스 아키텍처(MSA)에서 메인 인터페이스로 gRPC가 통용되고 있으므로, 현업 시스템으로의 이식 및 확장 속도가 독보적으로 빠릅니다.
3. **구조화된 직렬화 기반의 효율적 태스크 생명주기 및 부하 분산**
   - Protobuf(Protocol Buffers)를 통한 강력한 스키마 정의는 대량의 동적 서브에이전트들과 오케스트레이터 간에 쏟아지는 통신 메시지를 JSON 문자열 파싱 대비 수배 이상 빠르고 메모리 효율적으로 처리할 수 있게 합니다.
   - 이미 검증된 수많은 gRPC 기반 로드 밸런싱 및 이슈 트래킹 도구(예: Envoy, Kubernetes gRPC liveness probe 등)를 적극 도입함으로써, 에이전트 라이프사이클 감시 체계를 커스텀 빌드할 필요 없이 기성 인프라로 손쉽게 구축할 수 있습니다.