에이전트·하네스·MCP·A2A — 뒤섞여 쓰이는 AI 개념을 한 줄씩 정리했다

어떤 단어들은 자주 같이 쓰이다 보면 아예 같은 뜻인 줄 알게 된다. 에이전트, 하네스, 컨텍스트, 메모리가 그랬다. AI 시스템 설계 문서를 읽다 보면 사람마다 가리키는 게 달라서 혼란스러운 순간이 온다. 특히 여러 팀이 같은 시스템을 함께 만들 때, 단어 하나가 서로 다른 층을 가리키면 같은 회의에서 완전히 다른 이야기를 하게 된다. 개념을 하나씩 구분해서 부르기만 해도 설계 논의가 한결 수월해진다.

에이전트와 하네스 구분

에이전트는 목표를 받아 스스로 판단하고 도구를 호출하는 소프트웨어 단위를 말한다. LLM, 즉 대규모 언어 모델을 중심에 두고 다음 행동을 결정하는 주체라고 보면 된다. 예를 들어 “이 코드 저장소에서 버그를 찾아줘”라는 지시를 받으면 어떤 파일을 먼저 읽을지, 어떤 검색 도구를 쓸지, 결과를 어떻게 종합할지 판단하는 것이 에이전트의 역할이다. 하네스는 그 에이전트가 실제로 돌아가는 실행 환경을 말한다. 어떤 모델을 쓸지, 도구 호출 결과를 어떻게 처리할지, 오류가 나면 어떻게 재시도할지를 하네스가 맡는다.

에이전트가 “무엇을 할지 결정하는 층”이라면 하네스는 “그 결정이 돌아가도록 관리하는 층”이다. 둘을 같은 말로 쓰는 경우가 생각보다 많고, 그러면 설계 논의가 처음부터 어긋난다. “에이전트에 오류 처리를 추가하자”는 말이 하네스 수정을 가리키는지, 에이전트 내부 로직을 가리키는지 불명확해진다. 도구 호출이 실패했을 때 최대 세 번까지 재시도하도록 바꾸는 건 하네스 설정이고, 실패했을 때 다른 도구를 대신 쓰도록 판단을 바꾸는 건 에이전트 로직이다. 이 둘을 각각 구분해서 부르는 것만으로 어떤 코드를 수정해야 할지 훨씬 이해하기 쉬워진다.

에이전트는 직원이고 하네스는 그 직원이 일하는 사무실 시스템이다. 직원이 어떤 판단을 내리는지와 사무실이 어떤 장비, 규칙, 비상 대응 절차를 제공하는지는 다른 이야기다. 같은 에이전트 로직을 다른 하네스 위에서 돌릴 수도 있고, 같은 하네스 안에서 다른 에이전트를 돌릴 수도 있다. 이 분리 덕분에 모델을 바꾸거나 재시도 정책을 조정할 때 에이전트 코드를 건드리지 않아도 된다.

컨텍스트와 메모리 차이

컨텍스트는 현재 대화가 진행되는 동안 모델이 참고하는 정보를 말한다. 메시지 목록, 시스템 프롬프트, 도구 호출 결과가 모두 여기 들어간다. 파일을 읽어서 분석 중이라면 그 파일 내용도 컨텍스트 안에 있고, 이번 대화에서 사용자가 말한 요구사항도 컨텍스트에 포함된다. 대화가 끝나면 이 모든 정보는 사라진다. 메모리는 그 바깥에 있다. 대화와 대화 사이를 넘어 지속되는 정보를 따로 저장하고 불러오는 구조를 말한다.

컨텍스트와 메모리를 혼동하면 어디에 무엇을 저장해야 하는지 헷갈리기 쉽다. “이 정보를 컨텍스트에 넣자”와 “이 정보를 메모리에 저장하자”는 전혀 다른 결정이다. 사용자의 이름, 선호 언어, 자주 쓰는 프로젝트 경로처럼 매번 다시 묻기 불편한 정보는 메모리에 두는 게 맞다. 컨텍스트에만 넣으면 그 대화 안에서만 살고, 다음 대화가 시작될 때 에이전트는 그 정보를 전혀 모르는 상태가 된다. 설계 단계에서 이 구분이 불분명하면 나중에 엉뚱한 곳에서 데이터가 사라지거나 같은 정보를 컨텍스트와 메모리 양쪽에 중복 저장하는 일이 생긴다.

화이트보드에 쓴 것은 회의가 끝나면 지워지고, 노트북에 적은 것은 다음 회의에서도 꺼내 볼 수 있다. 컨텍스트는 화이트보드고 메모리는 노트북이다. 어떤 정보가 다음 대화까지 살아남아야 하는지 먼저 결정하고, 그다음에 저장 위치를 고르면 된다.

MCP와 A2A가 나온 이유

에이전트가 외부 도구나 다른 에이전트와 연결해야 할 때, 처음에는 REST API를 각자 구현하는 방식을 많이 썼다. REST API는 웹에서 데이터를 주고받는 일반적인 인터페이스 방식을 말한다. 연결할 에이전트가 하나둘 늘어나면 연결 코드도 그에 맞춰 늘어났다. 에이전트 열 개가 각자 다른 도구 다섯 개에 연결하면 구현해야 할 연결이 최대 오십 가지가 되고, 각 연결마다 인증 방식과 오류 처리 코드가 제각각이어서 유지보수 비용이 급격히 올라간다. 도구 하나의 API 형식이 바뀌면 그 도구를 쓰는 에이전트를 전부 찾아 수정해야 했다.

MCP는 Anthropic이 제안한 프로토콜이다. 모델이 외부 도구나 데이터 소스에 접근하는 방식을 규격화한 것이다. 에이전트가 도구를 어떻게 정의하고, 리소스를 어떻게 요청하고, 결과를 어떻게 받는지를 정해둔 계약이라고 보면 된다. Anthropic이 공개한 MCP 발표를 보면 도구 정의, 리소스 접근, 프롬프트 템플릿이 하나의 규격 안에 담겨 있다. USB 포트처럼 어떤 도구든 같은 방식으로 꽂히게 만드는 게 목표다.

A2A는 에이전트와 에이전트 사이의 통신을 다룬다. MCP가 모델과 도구 사이를 연결한다면, A2A는 에이전트 두 개가 서로 작업을 주고받는 방식을 정의한다. 에이전트가 자신의 능력을 광고하고, 다른 에이전트가 그걸 발견해서 호출하는 구조다. Google의 A2A 발표에는 조사 에이전트가 작업을 분해해 전문 에이전트들에게 위임하는 멀티 에이전트 시나리오가 구체적으로 설명되어 있다. MCP와 A2A는 서로 다른 레이어를 다루기 때문에 충돌하지 않고 함께 쓸 수 있다.

이 두 프로토콜의 차이를 이해하고 나면 REST로 연결하던 방식이 왜 쉽게 복잡해지는지 알 수 있다. 각 에이전트가 자기 방식대로 통신하면, 에이전트가 하나 추가될 때마다 기존 연결 전체를 다시 살펴봐야 한다. 표준이 있으면 새 에이전트를 연결할 때 매번 처음부터 다시 짜지 않아도 되고, 팀이 달라도 같은 규격으로 맞출 수 있다. A2A 스펙 문서에는 MCP와의 관계가 명시적으로 정리되어 있어서, 두 프로토콜이 어느 층에서 작동하는지 한눈에 파악할 수 있다. 이미 MCP로 도구를 연결해둔 팀이라면 A2A를 추가해 에이전트 간 협업 레이어만 따로 확장하는 방식도 가능하다.

혼동하기 쉬운 개념 정리

아래는 용어, 한 줄 설명, 비유를 짝지은 목록이다. 실제 설계 회의에서 누군가 이 단어들을 섞어 쓸 때 어느 층 이야기인지 빠르게 분류하는 기준으로 쓸 수 있다.

• 에이전트: 목표를 받아 스스로 판단하고 도구를 호출하는 주체. 어떤 행동을 취할지 결정하는 두뇌 역할을 한다. 비유: 직원.
• 하네스: 에이전트가 실행되는 환경. 모델 선택, 오류 처리, 재시도를 관리한다. 에이전트 코드를 바꾸지 않아도 하네스 설정만 변경해 다른 모델로 교체할 수 있다. 비유: 사무실 시스템.
• 컨텍스트: 현재 대화 안에서 살아있는 정보. 대화가 끝나면 사라진다. 비유: 화이트보드.
• 메모리: 대화 밖에 따로 저장하는 지속 정보. 다음 대화에서도 꺼내 쓴다. 무엇을 저장하고 언제 불러올지를 명시적으로 설계해야 작동한다. 비유: 노트북.
• MCP: 모델과 외부 도구 사이의 통신 표준. Anthropic이 제안했다. 비유: USB 규격.
• A2A: 에이전트와 에이전트 사이의 통신 표준. Google이 제안했다. 비유: 사내 메신저 프로토콜.

이 구분을 머릿속에 두면 AI 시스템 설계 문서를 읽을 때 혼선이 줄어든다. 용어를 섞어 쓰는 게 문제가 아니라, 섞어 쓰는지 모르는 게 문제다. 어떤 단어가 어느 층을 가리키는지 알고 나면, 대화가 어긋나는 순간을 빠르게 잡아낼 수 있다. 팀원이 “에이전트를 수정하자”고 말할 때 그것이 판단 로직의 문제인지 실행 환경의 문제인지부터 짚고 넘어가면 된다.