이 포스트의 글과 이미지는 AI와의 토론을 통해 작성되었습니다. 해당 분야에 익숙한 분들도 계시겠지만, 자동화, 에이전트, MCP, A2A 등의 개념이 아직 낯선 분들께 작은 도움이 되기를 바랍니다
디지털 노동의 구조적 전환
우리는 지금까지 디지털 전환의 가속화 속에서 노동의 본질적인 변화를 목격하고 있습니다. 지난 수십 년간 기업과 소프트웨어 엔지니어링의 지배적인 패러다임은 '자동화(Automation)'였습니다. 이는 명확히 정의된 규칙과 구조화된 데이터를 기반으로, 인간의 개입을 최소화하며 반복적인 작업을 처리하는 결정론적 시스템이었습니다. 그러나 비정형 데이터의 폭증, 비즈니스 환경의 불확실성, 그리고 단순 반복을 넘어선 의사결정의 필요성은 기존 자동화 기술의 한계를 드러내기 시작했습니다. 이러한 배경 속에서 대규모 언어 모델의 비약적인 발전과 함께 등장한 'AI 에이전트(AI Agents)'는 단순한 기술적 진보를 넘어, 디지털 시스템이 수동적인 도구에서 자율적인 주체로 진화하는 것을 시사하고 있습니다.
1. Automation: 결정론적 효율성 기반
AI 에이전트의 혁신성을 이해하기 위해서는 그 기반이 되는 '자동화’의 본질을 먼저 이해해야 합니다. 자동화는 기술을 활용하여 인간의 개입을 줄이고 프로세스를 수행하는 것을 의미하며, 그 핵심은 '예측 가능성’과 '일관성’에 있습니다.
1.1 전통적 자동화의 아키텍처와 결정론
전통적인 자동화 시스템은 철저히 결정론적 로직에 기반합니다. 이는 시스템의 입력과 초기 상태가 주어지면, 그 결과가 언제나 동일하게 도출됨을 의미합니다. 이러한 시스템의 핵심 메커니즘은 "만약 X가 발생하면, Y를 수행하라(If X, then do Y)"라는 조건부 루프입니다.
이러한 구조는 데이터가 고도로 구조화되어 있고, 변수가 통제 가능한 환경에서 극대화된 효율을 발휘합니다. 예를 들어, 데이터베이스 간의 동기화, 정형화된 엑셀 파일의 데이터 추출, 사전 정의된 포맷의 출력 처리 등이 이에 해당합니다. 자동화 시스템은 지치지 않고, 실수 없이, 인간보다 훨씬 빠른 속도로 이 작업을 수행합니다. 그러나 이 결정론적 특성은 동시에 가장 큰 취약점이기도 합니다. 입력 데이터의 형식이 조금이라도 바뀌거나, 예상치 못한 예외 상황이 발생할 경우, 전통적인 자동화 스크립트는 오류를 일으키며 중단됩니다.
1.2 RPA(Robotic Process Automation)의 역할과 한계
자동화 기술의 정점에는 RPA가 있습니다. RPA는 인간이 사용자 인터페이스(UI)를 통해 수행하는 작업을 소프트웨어 봇이 모방하여 수행하는 기술입니다. 이는 '디지털 워크포스(Digital Workforce)'라고도 불리며, 금융, 제조, 물류 등 다양한 산업 분야에서 백오피스 업무의 효율성을 혁신적으로 높여왔습니다.
RPA 봇은 마치 공장의 조립 라인에 설치된 로봇 팔과 유사합니다. 로봇 팔이 매번 정확히 같은 좌표에 용접을 수행하듯, RPA 봇은 화면의 특정 좌표나 요소를 클릭하고 텍스트를 입력합니다. 그러나 만약 조립 라인에 부품이 거꾸로 놓인다면(비정형 상황), 로봇 팔은 이를 인지하지 못하고 허공에 용접을 하거나 부품을 파손시킵니다. 마찬가지로 RPA 역시 화면의 버튼 위치가 바뀌거나, 웹사이트의 로딩 속도가 달라지면 작업을 실패합니다. RPA는 “무엇을(What)” 해야 하는지는 알지만, “왜(Why)” 해야 하는지, 혹은 상황이 바뀌었을 때 “어떻게(How)” 대처해야 하는지에 대한 인지 능력이 부재하기 때문입니다.
1.3 자동화의 확장성 문제와 유지보수 비용
자동화 시스템, 특히 RPA의 또 다른 구조적 한계는 확장성(Scalability)의 문제입니다. RPA의 확장은 선형적입니다. 새로운 유형의 업무를 자동화하려면, 그 업무에 맞는 새로운 스크립트를 처음부터 작성해야 합니다. 기존의 스크립트가 새로운 업무를 스스로 학습하거나 적응하지 못하기 때문입니다.
또한, 유지보수 비용이 높습니다. 기업의 IT 환경은 끊임없이 변화합니다. 보안 업데이트로 인해 로그인 절차가 바뀌거나, 사용하는 SaaS 애플리케이션의 UI가 업데이트될 때마다, 관련된 모든 자동화 봇을 수동으로 수정하고 재배포해야 합니다. 이는 자동화 도입 초기에는 높은 투자 대비 수익을 보이다가도, 시간이 지날수록 유지보수 비용이 증가하여 효율이 저하되는 '자동화의 역설’을 초래하기도 합니다.
2. AI Agents: 인지적 아키텍처의 부상
AI 에이전트는 자동화의 결정론적 한계를 극복하기 위해 등장한 개념으로, ‘**확률론적 추론’**과 ‘**자율성’**을 핵심으로 합니다. 에이전트는 환경을 인식하고(Perceive), 목표를 달성하기 위해 추론(Reason)하며, 도구를 사용하여 행동(Act)하는 시스템으로 정의됩니다. 이는 단순한 명령 수행자가 아니라, 목표를 추구하는 주체입니다.
2.1 AI Agents의 핵심 구성 요소
AI 에이전트는 단순한 소프트웨어 스크립트가 아니라, 인간의 인지 과정을 모방한 정교한 아키텍처를 갖추고 있습니다. 이 아키텍처는 크게 Brain, Memory, Tools, 그리고 Planning으로 구성됩니다.
-
Brain(LLM): 에이전트의 핵심은 대규모 언어 모델입니다. GPT, Claude, Gemini와 같은 모델들은 단순한 텍스트 생성을 넘어, 주어진 상황을 이해하고 논리적으로 추론하는 능력을 제공합니다. 두뇌는 사용자의 모호한 명령(“다음 주 마케팅 캠페인 준비해줘”)을 구체적인 작업 단위로 해석하고, 어떤 도구를 사용해야 할지 결정합니다.
-
Memory: LLM 자체는 상태가 없는 시스템입니다. 에이전트가 지속적인 상호작용을 하기 위해서는 기억이 필수적입니다.
-
단기 기억(Short-term Memory): 현재 수행 중인 작업의 컨텍스트나 대화의 흐름을 유지합니다. LLM의 컨텍스트 윈도우(Context Window)가 이 역할을 수행합니다.
-
장기 기억(Long-term Memory): 벡터 데이터베이스(Vector DB)나 기존의 SQL 데이터베이스를 활용하여 과거의 상호작용, 사용자 선호도, 외부 지식(RAG) 등을 저장하고 검색합니다.
-
-
Tools: 에이전트가 현실 세계에 영향을 미치기 위한 수단입니다. LLM 자체는 텍스트만 생성할 뿐, 실제로 이메일을 보내거나 서버를 재부팅할 수 없습니다. 도구는 API 호출, 웹 검색, 코드 실행기, 데이터베이스 쿼리 등의 형태로 제공되며, 에이전트는 자신의 추론 결과에 따라 적절한 도구를 호출(Function Calling)합니다.
-
Planning: 복잡한 목표를 달성하기 위해 에이전트는 작업을 더 작은 하위 작업으로 분해하고, 수행 순서를 정합니다. ‘ReAct(Reasoning + Acting)’ 패턴이나 ‘Chain-of-Thought(CoT)’ 프롬프팅 기법이 에이전트의 계획 능력을 뒷받침합니다.
2.2 확률론적 자율성과 적응력
AI 에이전트의 가장 큰 특징은 자율성(Autonomy)과 적응력(Adaptability)입니다.
전통적 자동화가 "A 버튼을 클릭하라"는 명령을 수행한다면, AI 에이전트는 "이 문서를 처리하라"는 목표를 받습니다. 만약 문서 처리 시스템의 버튼 위치가 바뀌었다면, 에이전트는 화면을 분석하여 “제출” 버튼과 유사한 요소를 찾아내고, 문맥을 파악하여 스스로 판단하고 클릭합니다.
또한, AI 에이전트는 비정형 데이터 처리에 탁월합니다. 고객이 보낸 불만 이메일이 맞춤법이 틀리고 감정적으로 작성되어 있어도, 에이전트는 그 의도를 파악하고, 핵심 정보를 추출하여, 적절한 사과 메일을 작성하거나 환불 절차를 안내할 수 있습니다. 심지어 도구 사용에 실패했을 때(예: API 에러), 에이전트는 오류 메시지를 분석하여 재시도를 하거나, 대체 경로를 모색하는 ‘자기 수정(Self-Correction)’ 능력을 발휘할 수도 있습니다.
2.3 “스마트 로봇” 에 비유
앞서 언급한 공장의 로봇 팔 비유를 다시 가져오자면, AI 에이전트는 카메라와 센서, 그리고 AI 프로세서가 장착된 '지능형 로봇’입니다. 이 로봇은 부품이 거꾸로 놓여 있으면, 이를 시각적으로 인지하고(Perception), "부품을 먼저 올바르게 돌려놓아야 한다"고 판단(Planning)한 뒤, 집게를 사용해 부품을 회전시키고(Action), 다시 용접을 수행합니다. 즉, 환경의 변화에 동적으로 대응하며 목표를 달성해내는 것입니다.
3. Automation vs. AI Agents
'자동화’와 'AI 에이전트’는 종종 혼용되지만, 기술적 깊이와 적용 범위에서 분명한 차이를 보입니다. 최근에는 이 둘의 장점을 결합한 '에이전트형 자동화(Agentic Automation)'라는 개념이 등장하며 기업의 운영 효율성을 새로운 차원으로 끌어올리고 있습니다.
3.1 Automation vs. AI Agents
다음은 자동화와 AI 에이전트의 주요 차이점에 대한 비교 입니다.
3.2 패러다임의 통합: Automation + AI Agents
현재 가장 진보된 형태의 업무 자동화는 RPA와 AI 에이전트를 상호보완적으로 사용하는 하이브리드 모델입니다.
-
RPA의 역할 (The Hands): 레거시 시스템과의 상호작용, 단순 데이터 입력 등 정확성과 속도가 생명인 영역을 담당합니다.
-
AI 에이전트의 역할 (The Brain): 프로세스의 오케스트레이션을 담당합니다. 비정형 데이터를 해석하여 RPA에게 구조화된 데이터를 넘겨주거나, RPA가 처리하지 못한 예외 상황(Exception Handling)을 넘겨받아 판단하고 처리합니다.
예를 들어, 배포 장애가 발생한 상황에서 RPA는 문제가 발생한 노드의 콘솔에 접속해 상태 정보를 수집하고, 로그 파일을 다운로드하며, 지정된 포털에 장애 티켓을 자동으로 생성하는 역할을 수행합니다. AI 에이전트는 수집된 로그와 이벤트 메시지를 분석해 장애의 가능 원인을 1차적으로 판단한 뒤, 필요하면 RPA에게 롤백 또는 재배포를 수행하도록 지시하거나, 판단이 애매한 경우 엔지니어에게 요약된 원인 분석 보고서를 전달합니다.
3.3 선택
어떤 기술을 언제 도입할지 전략적으로 판단해야 합니다.
-
자동화가 필요한 경우: 프로세스가 매우 안정적이고(변경이 적음), 처리량이 방대하며, 100%의 정확도(환각 현상 제로)가 요구되는 경우.
-
AI 에이전트가 필요한 경우: 입력 데이터가 매번 다르고(이메일, 채팅), 판단이 필요하며, 여러 소스의 정보를 종합해야 하는 경우.
4. MCP (Model Context Protocol): AI 연결성의 표준화
AI 에이전트가 실제 현장에 적용되면서 마주한 가장 큰 기술적 장벽은 ‘연동의 복잡성’ 문제였습니다. 수많은 AI 모델(Claude, GPT, Gemini, Llama 등)과 수많은 데이터 소스(Google Drive, Slack, GitHub, PostgreSQL, Notion 등)를 연결해야 하는 상황에서, 모든 모델과 모든 도구 간에 개별적인 연동 코드를 작성하는 것은 기하급수적인 노력을 요구합니다.
이러한 파편화 문제를 해결하기 위해 Anthropic은 2024년 말, MCP(Model Context Protocol)라는 오픈 표준 프로토콜을 제안했습니다. MCP는 AI 애플리케이션과 데이터 소스 간의 연결 방식을 표준화함으로써, 마치 USB-C 포트 하나로 다양한 기기를 연결하듯 AI 생태계의 호환성을 보장하는 것을 목표로 MCP를 제안하게 됩니다.
4.1 MCP의 기술적 아키텍처
MCP는 클라이언트-호스트-서버(Client-Host-Server) 모델을 따르며, JSON-RPC 2.0 프로토콜을 기반으로 통신합니다. 이 아키텍처의 핵심은 AI 모델(Brain)과 데이터 소스(Context)를 완전히 분리(Decoupling)하는 것입니다.
4.1.1 핵심 구성 요소
-
MCP Host: AI 모델이 구동되는 애플리케이션입니다. Claude Desktop App, Cursor 혹은 개발자가 만든 커스텀 AI 챗봇이 여기에 해당합니다. 호스트는 사용자와의 상호작용을 담당하고, 필요한 경우 MCP 클라이언트를 통해 서버에 데이터를 요청합니다.
-
MCP Client: 호스트 애플리케이션 내부에 위치하며, 실제 MCP 서버와의 연결을 유지하고 프로토콜 통신을 관리하는 모듈입니다. 클라이언트는 서버와 1:1 연결을 맺고, 협상을 수행합니다.
-
MCP Server: 특정 데이터나 기능을 제공하는 독립적인 프로그램입니다. 예를 들어 ‘Google Drive MCP 서버’, ‘PostgreSQL MCP 서버’ 등이 있습니다. 중요한 점은 서버는 자신을 호출하는 AI 모델이 무엇인지 알 필요가 없다는 것입니다. 서버는 오직 표준화된 MCP 프로토콜에 맞춰 기능과 데이터를 노출할 뿐입니다. ← “AI 모델과 데이터 소스의 완전한 분리”
-
전송 계층 (Transport Layer): MCP는 두 가지 주요 통신 방식을 지원합니다.
-
Stdio: 로컬 프로세스 간 통신(Standard Input/Output)을 사용합니다. 보안성이 높고 지연 시간이 거의 없어 로컬 파일 시스템이나 데스크톱 앱 제어에 적합합니다.
-
SSE (Server-Sent Events): HTTP를 통한 원격 통신을 지원합니다. 이를 통해 클라우드에 있는 에이전트가 로컬 서버에 접속하거나, 서로 다른 서버 간의 통신이 가능합니다.
-
4.2 MCP의 3대 핵심 요소
MCP는 서버가 호스트(에이전트)에게 제공할 수 있는 기능을 크게 세 가지 기본 요소로 정의합니다.
-
리소스 (Resources - Context/Reading):
-
에이전트가 읽을 수 있는 수동적인 데이터 소스입니다.
-
예: 파일의 내용, 데이터베이스의 특정 레코드, 시스템 로그의 마지막 100줄.
-
에이전트는 리소스의 URI를 통해 데이터에 접근하며, 리소스가 변경될 경우 알림을 구독하여 실시간으로 최신 정보를 유지할 수 있습니다. 이는 에이전트에게 "눈"을 제공하는 것과 같습니다.
-
-
도구 (Tools - Action/Execution):
-
에이전트가 실행할 수 있는 함수나 명령어입니다.
-
예:
git commit,send_email,query_db,calculator. -
서버는 도구의 이름, 설명, 필요한 인자의 스키마를 정의하여 노출합니다. 에이전트(LLM)는 이 스키마를 보고 어떤 도구를 어떻게 호출할지 결정합니다. 이는 에이전트에게 "손"을 제공하는 것입니다.
-
-
프롬프트 (Prompts - Templates):
-
서버가 제공하는 재사용 가능한 프롬프트 템플릿입니다.
-
예: 코드 리뷰 MCP 서버가 제공하는 “코드 버그 분석” 프롬프트.
-
이는 사용자가 에이전트를 더 효과적으로 사용할 수 있도록 돕는 가이드 역할을 하며, 서버 특화된 지식을 프롬프트 형태로 미리 정의해 둔 것입니다.
-
4.3 MCP가 가져온 변화
MCP 이전에는 개발자가 Claude를 사용해 사내 데이터베이스를 조회하려면, Claude API에 맞는 'Tool Definition’을 하드코딩해야 했습니다. 만약 나중에 모델을 GPT-4로 바꾸려면, OpenAI의 ‘Function Calling’ 포맷에 맞춰 코드를 전부 다시 짜야 했습니다(Lock-in).
하지만 MCP 환경에서는 개발자가 'PostgreSQL MCP 서버’를 한 번만 만들면 됩니다.
-
Claude Desktop이 이 서버에 접속하여 DB를 조회할 수 있습니다.
-
Cursor IDE가 이 서버에 접속하여 코드 맥락에 맞는 테이블 스키마를 가져올 수 있습니다.
-
LangChain으로 만든 커스텀 에이전트도 이 서버를 즉시 사용할 수 있습니다.
이처럼 MCP는 도구 개발과 에이전트 개발을 분리시킴으로써, AI 생태계의 폭발적인 확장을 가능하게 하는 인프라가 되었습니다. 이는 마치 웹의 HTTP, 컴퓨터 주변기기의 USB와 같은 위상을 가집니다.
5. MCP vs. AI Agents
MCP와 AI 에이전트의 관계를 명확히 하는 것은 매우 중요합니다. MCP는 프로토콜(통신 규약)이고, AI 에이전트는 애플리케이션(응용 프로그램)입니다. 이 둘은 경쟁 관계가 아니라 상호 의존적인 관계입니다.
5.1 관계의 정립
-
AI 에이전트는 MCP의 '사용자(Consumer)'입니다. 에이전트는 두뇌(LLM)를 사용하여 판단하고, MCP를 통해 외부와 소통합니다.
-
MCP는 에이전트가 사용하는 ‘인터페이스’. 에이전트가 망치를 집어 들거나(도구 사용), 책을 읽을 때(리소스 접근) 사용하는 표준화된 방식입니다.
-
비유: AI 에이전트가 '목수’라면, MCP는 목수가 사용하는 모든 공구(망치, 톱, 드릴)의 손잡이 규격입니다. 손잡이 규격이 통일되어 있기 때문에 목수는 어떤 브랜드의 공구든 자유롭게 집어서 작업을 수행할 수 있습니다.
5.2 MCP와 OpenAI Function Calling의 비교
OpenAI의 Function Calling(또는 Tool Use) 과 MCP를 혼동할 수 있습니다. 이 둘은 목적은 유사하지만(AI가 외부 도구를 사용함), 작동 방식과 스케일에서 차이가 있습니다.
Function Calling은 단일 스크립트나 간단한 챗봇을 만들 때 빠르고 효율적입니다. 그러나 사용자의 구글 드라이브, 슬랙, 지라, 깃허브 등 수십 개의 도구를 지속적으로 연결해야 하는 ‘에이전트 운영체제(OS)’ 급의 시스템을 구축할 때는 MCP가 필수적입니다. 모든 도구의 정의를 매번 API 호출에 포함시키는 것은 토큰 비용 측면에서도 비효율적이며, 관리 불가능한 복잡성을 초래하기 때문입니다. MCP는 도구의 정의를 서버에 위임하고, 호스트가 필요할 때 동적으로 기능을 탐색하도록 설계되어 있습니다.
6. A2A (Agent-to-Agent): 에이전트 인터넷의 서막
MCP가 에이전트와 도구 간의 소통을 표준화했다면, A2A(Agent-to-Agent) 프로토콜은 에이전트와 에이전트 간의 소통을 표준화하는 기술입니다.
6.1 사일로(Silo) 문제의 해결
현재의 AI 에이전트 생태계는 파편화되어 있습니다. LangChain으로 만든 '여행 상담 에이전트’는 CrewAI로 만든 '항공권 예약 에이전트’와 직접 대화할 수 있는 표준화된 방법이 없습니다. 서로 다른 프레임워크, 서로 다른 내부 로직을 사용하기 때문입니다. 이로 인해 거대한 단일 에이전트(Monolithic Agent)를 만들거나, 복잡한 커스텀 코드를 작성해야 했습니다.
6.2 A2A 프로토콜 표준
Google과 Linux Foundation이 주도하는 A2A 프로토콜은 이러한 장벽을 허물고, 에이전트 간의 상호운용성(Interoperability)을 보장하기 위해 등장했습니다. "에이전트를 위한 HTTP"라고 부를 수 있을 것 같습니다.
6.2.1 A2A의 핵심 개념
-
에이전트 카드 (Agent Card): 에이전트의 디지털 신분증이자 명함입니다. JSON 형식으로 정의되며, 웹의
.well-known/agent-card.json경로에 위치합니다.-
Identity: 에이전트 이름, 설명, 버전.
-
Skills: 이 에이전트가 수행할 수 있는 작업 목록 (예: “호텔 예약”, “법률 자문”).
-
Capabilities: 스트리밍 지원 여부, 푸시 알림 지원 여부 등 통신 능력.
-
이 카드를 통해 클라이언트 에이전트는 네트워크상의 다른 에이전트를 발견하고, 무엇을 시킬 수 있는지 파악합니다.
-
-
태스크 수명주기 (Task Lifecycle): A2A의 통신은 상태(Stateful)를 가집니다.
-
초기화: 클라이언트가 작업을 요청하면 서버 에이전트는
taskId를 발급합니다. -
비동기 처리: 에이전트의 추론은 시간이 걸리기 때문에(API처럼 즉답이 오지 않을 수 있음), A2A는 폴링이나 웹훅을 통해 작업 진행 상황을 비동기적으로 확인하는 메커니즘을 내장하고 있습니다.
-
-
불투명성 (Opacity): A2A의 가장 중요한 특징 중 하나는 보안과 관련된 불투명성입니다. '변호사 에이전트’는 '영업 에이전트’의 계약서 검토 요청을 처리해주지만, 자신의 내부 프롬프트나 사용하는 법률 데이터베이스를 영업 에이전트에게 공개하지 않습니다. 오직 결과물(Artifact)만 공유합니다. 이는 기업 간(B2B) 에이전트 협업에서 지식재산권을 보호하는 핵심 요소입니다.
6.3 A2A와 MCP의 상호보완적 관계
A2A와 MCP는 서로 다른 레이어에서 작동하며 상호 보완합니다.
향후 복잡한 시스템은 "매니저 에이전트"가 A2A를 통해 하위의 전문화된 "워커 에이전트(코더, 디자이너, 분석가)"들에게 업무를 분장하고, 각 워커 에이전트는 MCP를 통해 자신에게 필요한 도구(IDE, Figma, DB)를 사용하여 실무를 처리하는 형태로 발전할 것으로 보여집니다.
마무리: 자율적 에이전트 생태계로의 도약
지금까지 '자동화’에서 'AI 에이전트’로의 변화 과정을 살펴보았습니다.
**자동화(Automation)**는 디지털 작업의 산업화를 이끌었습니다. 규칙 기반의 견고함은 대량 반복 업무에서 여전히 유효하지만, 급변하는 비즈니스 환경과 비정형 데이터 앞에서는 그 한계를 드러냈습니다.
**AI 에이전트(AI Agents)**는 이 한계를 극복하는 인지적 레이어를 제공합니다. 확률론적 추론을 통해 에이전트는 모호한 상황에서 스스로 판단하고, 계획하며, 적응합니다. 이는 단순한 도구의 사용을 넘어, 목표를 달성하는 디지털 주체의 탄생을 의미합니다.
MCP는 이러한 에이전트들이 도구와 데이터를 자유롭게 사용할 수 있도록 연결의 복잡성을 해결한 핵심 인프라입니다. 표준화된 'AI용 USB 포트’인 MCP 덕분에, 에이전트 개발자는 연동의 늪에서 벗어나 기능 자체에 집중할 수 있게 되었습니다.
마지막으로 A2A 프로토콜은 개별 에이전트들을 연결하여 '에이전트 인터넷’을 구축하고 있습니다. 전문화된 에이전트들이 서로 협력하여 단일 모델로는 해결할 수 없는 복합적인 문제를 해결하는 에이전트 집단지성의 시대를 예고합니다.
앞으로의 방향성이 점차 선명해지고 있는 것 같습니다. 자동화는 이제 경직된 스크립트 중심의 방식에서 벗어나, MCP를 활용해 시스템 간 연결성을 높이고, A2A 기반의 유연한 에이전트 생태계를 고려할 시점입니다. 기존의 정적인 자동화만으로는 한계가 있을 수 있으며, 점차 더 유연하게 상호 작용하는 자율 에이전트의 흐름이 확산되고 있는 듯 합니다.
(생각해보니 저부터도 글을 쓰는 방식이 많이 바뀌았네요 자료 조사를 검색이나 책이 아닌 에이전트로…)
