FIPA-ACL과 화행(Speech Act)의 계보

MCP 이전에, A2A 이전에 FIPA-ACL이 있었습니다. 2000년에 IEEE Foundation for Intelligent Physical Agents는 에이전트 통신 언어(Agent Communication Language; ACL)를 비준했습니다. 이 언어에는 스무 개의 수행문(performative), 두 개의 내용 언어(content language), 그리고 계약망(contract net), 구독/통지(subscribe/notify), 조건부 요청(request-when) 같은 상호작용 프로토콜(interaction protocol)이 있었습니다. 산업계에서 사라진 이유는 온톨로지(ontology) 부담이 웹에는 너무 무거웠기 때문입니다. 하지만 LLM 기반 멀티 에이전트 시스템의 부활은 같은 아이디어를 형식 의미론(formal semantics) 없이 조용히 다시 구현하고 있습니다. JSON 계약은 수행문을 대신하고, 자연어는 온톨로지를 대신합니다. 이 강의는 FIPA-ACL을 진지하게 읽습니다. 그래야 2026년의 프로토콜 결정 중 무엇이 재발명이고, 무엇이 새로운 점이며, 현재 흐름이 2000년대에 이미 풀었던 문제를 어디서 다시 발견하게 될지 볼 수 있습니다.

유형: Learn 언어: Python(stdlib) 선수 조건: Phase 16 · 01(왜 멀티 에이전트인가) 예상 시간: 약 60분

문제

2026년의 에이전트 프로토콜(agent protocol) 지형은 바쁩니다. 도구(tool) 호출을 위한 MCP, 에이전트 간 통신을 위한 A2A, 기업 감사(enterprise audit)를 위한 ACP, 탈중앙 신뢰(decentralized trust)를 위한 ANP, 자연어 콘텐츠를 위한 NLIP, 여기에 CA-MCP와 수십 개의 연구 제안까지 있습니다. 각 사양(spec)은 자신이 기초가 된다고 주장합니다.

솔직하게 읽으면, 이들 대부분은 20년 전의 매우 구체적인 의사결정 트리(decision tree)를 다시 발견하고 있을 뿐입니다. Austin(1962)과 Searle(1969)의 화행 이론(speech-act theory)은 "발화(utterance)는 곧 행동이다"라는 관점을 우리에게 주었습니다. KQML(1993)은 이를 소프트웨어 에이전트용 통신 프로토콜(wire protocol)로 바꾸었습니다. FIPA-ACL(2000년 비준)은 스무 개의 수행문, 내용 언어 SL0/SL1, 계약망과 구독/통지(subscribe-notify)를 위한 상호작용 프로토콜을 표준화한 참조 표준을 만들어 냈습니다. JADE와 JACK은 그 시대의 Java 기준 플랫폼(reference platform)이었습니다. 이 시도는 2010년 무렵 시들해졌습니다. 온톨로지 부담이 너무 무거웠고, 결국 웹 스택이 승리했기 때문입니다.

MCP의 tools/call, A2A의 과제 생명주기(task lifecycle), CA-MCP의 공유 컨텍스트 저장소(shared context store)를 들여다보면, FIPA의 결정을 더 부드럽고 JSON 친화적인 형태로 다시 만든 것을 보고 있는 셈입니다. 이 계보를 알면 두 가지를 알 수 있습니다. 새로운 "혁신" 중 무엇이 실제로는 재발명인지, 그리고 새 사양이 어떤 오래된 실패 양상(failure mode)을 다시 발견하게 될지입니다.

개념

화행을 한 문단으로

Austin은 어떤 문장이 세계를 설명하는 것이 아니라 세계를 바꾼다는 점에 주목했습니다. "약속합니다.", "요청합니다.", "선언합니다."와 같은 문장이 그렇습니다. 그는 이를 수행적 발화(performative utterance)라고 불렀습니다. Searle은 이를 단언(assertive), 지시(directive), 약속(commissive), 표현(expressive), 선언(declarative)이라는 다섯 가지 범주로 정리했습니다. KQML(Finin 등, 1993)은 이를 소프트웨어 에이전트에 맞게 작동 가능한 형태로 만들었습니다. 메시지는 수행문, 즉 행동(action)과 내용(content), 즉 그 행동이 다루는 대상으로 구성됩니다. FIPA-ACL은 KQML의 빈틈을 정리하고 약 스무 개의 수행문을 중심으로 이를 표준화했습니다.

FIPA 수행문 스무 개(일부 목록)

전체 목록은 fipa00037.pdf(FIPA ACL Message Structure)에 있습니다. 중요한 것은 이를 외우는 일이 아닙니다. 중요한 점은 이 각각의 수행문이 LLM 프로토콜이 결국 다시 추가하게 되는 원시 기능(primitive)에 대응한다는 사실입니다.

표준 FIPA-ACL 메시지

(inform
  :sender       agent1@platform
  :receiver     agent2@platform
  :content      "((price IBM 83))"
  :language     SL0
  :ontology     finance
  :protocol     fipa-request
  :conversation-id   conv-42
  :reply-with   msg-17
)

일곱 개의 필드가 프로토콜 봉투(envelope)를 구성하고, 하나의 필드인 content가 실제 페이로드(payload)를 담습니다. 나머지 필드는 JSON 프로토콜에 재시도(retry), 스레딩(threading), 온톨로지를 덧붙일 때마다 우리가 매번 다시 발명하게 되는 바로 그것들입니다.

두 개의 레거시 플랫폼

JADE(Java Agent DEvelopment framework, 1999–2020년대)는 가장 널리 쓰인 FIPA 호환 런타임(runtime)이었습니다. 에이전트는 기본 클래스를 확장하고, ACL 메시지를 주고받고, 컨테이너(container) 안에서 실행되며, "행동(behaviors)"이라는 추상으로 협력 흐름을 조정했습니다. 상호작용 프로토콜 라이브러리에는 contract-net, subscribe-notify, request-when, propose-accept가 기본으로 포함되어 있었습니다.

JACK(Agent Oriented Software, 상용 제품)은 FIPA 메시지 위에 BDI(Belief-Desire-Intention) 추론을 얹는 점을 강조했습니다. 더 형식적이었지만, 채택 폭은 더 좁았습니다.

두 플랫폼 모두 웹 스택이 멀티 에이전트의 사용 사례를 빠르게 흡수하면서 쇠퇴했습니다. 2026년의 MCP와 A2A가 바로 당시의 런타임 "컨테이너"에 해당하는 자리에 놓여 있습니다.

FIPA가 사라진 이유

• 온톨로지 부담(Ontology overhead): FIPA는 content를 파싱하려면 공유 온톨로지를 전제로 요구했습니다. 온톨로지 합의는 수년이 걸리는 표준화 과정입니다. 반면 웹은 그냥 HTTP + JSON을 사용했습니다.
• 아무도 쓰지 않은 형식 의미론(Formal semantics): SL(Semantic Language)은 엄밀한 진리 조건(truth conditions)을 제공했지만, 대부분의 운영 시스템은 자유 형식 내용을 사용하고 형식 의미론은 그냥 무시했습니다.
• 도구 잠금(Tooling lock-in): JADE는 Java 전용이었고, JACK은 상용 제품이었습니다. 여러 언어를 쓰는 팀은 결국 두 플랫폼을 모두 우회해 버렸습니다.
• 인터넷이 스택을 이겼다: REST, 이후의 JSON-RPC, 이후의 gRPC가 차례로 ACL의 전송 계층(transport)을 대체해 갔습니다.

LLM의 부활은 결국 FIPA-lite입니다

FIPA request와 MCP tools/call을 나란히 놓고 비교해 봅니다.

(request                                {
  :sender  agent1                         "jsonrpc": "2.0",
  :receiver tool-server                   "method":  "tools/call",
  :content "(lookup stock IBM)"           "params":  {"name":"lookup_stock",
  :ontology finance                                   "arguments":{"symbol":"IBM"}},
  :conversation-id c42                    "id": 42
)                                        }

같은 봉투(envelope) 구조이고, 단지 문법만 다릅니다. 둘 다 누가, 누구에게, 어떤 의도로, 어떤 페이로드를, 어떤 상관 ID(correlation id)로 보내는지를 담아냅니다. 어느 쪽도 상대에 대한 혁명이 아닙니다. 같은 설계 위에서 서로 다른 트레이드오프를 선택한 결과일 뿐입니다.

Liu 등(2025)의 조사 논문 "A Survey of Agent Interoperability Protocols: MCP, ACP, A2A, ANP"(arXiv:2505.02279)는 이 계보를 분명하게 드러냅니다. MCP는 도구 사용 화행(tool-use speech acts)에, A2A는 에이전트 간 화행(agent-peer speech acts)에, ACP는 감사 추적 화행(audit-trail speech acts)에, ANP는 탈중앙 신원 확장(decentralized-identity extensions)에 각각 대응합니다. 새로운 사양들은 결국 JSON 문법과 더 느슨해진 의미론을 가진 ACL의 후손인 셈입니다.

트레이드오프를 분명히 말하면

FIPA가 제공했지만 현대 사양이 버린 것:

• 형식 의미론 — inform이라는 메시지는 발신자가 그 내용을 믿는다는 사실을 증명 가능한 형태로 표현해 줍니다.
• 표준 수행문 목록 — "cancel이 있어야 하는가?"와 같은 논쟁을 매번 다시 할 필요가 없습니다.
• 수십 년 동안 축적된 상호작용 프로토콜 패턴 — contract-net, subscribe-notify, propose-accept — 와 알려진 정확성 속성(correctness properties).

현대 사양이 제공하지만 FIPA가 제공하지 못한 것:

• 모든 현대 도구와 호환되는 JSON 네이티브 페이로드(JSON-native payloads).
• 사람이 손수 코딩한 온톨로지 없이도 LLM이 해석할 수 있는 자연어 내용.
• 웹 스택 전송 계층(HTTP, SSE, WebSocket).
• 자기 기술 문서(self-describing document)를 통한 역량 발견(capability discovery). 예: MCP listTools, A2A Agent Card.

구현을 쉽게 만들기 위해 의도 의미론(intent semantics)을 느슨하게 풀어 준 것이며, 정확히 그것이 우리가 받아들이고 있는 트레이드오프입니다.

가져올 가치가 있는 상호작용 프로토콜

FIPA는 약 15개의 상호작용 프로토콜을 제공했습니다. 그중 세 가지는 LLM 기반 멀티 에이전트 시스템으로 가져올 가치가 있습니다.

1. 계약망 프로토콜(Contract Net Protocol; CNP): 관리자가 cfp(call for proposals)를 보내고, 입찰자(bidder)가 propose로 응답하며, 관리자가 이를 수락하거나 거절합니다. 표준적인 과제 시장(task-market) 패턴입니다(Phase 16 · 16 협상과 교섭).
2. 구독/통지(Subscribe/Notify): 구독자(subscriber)가 subscribe를 보내고, 발행자(publisher)는 주제가 변할 때마다 inform을 내려보냅니다. 2026년의 거의 모든 이벤트 버스(event bus)가 이 형태를 따릅니다.
3. 조건부 요청(Request-When): "조건 Y가 참이 되면 X를 하라"는 패턴입니다. 사전 조건(pre-condition)이 붙은 지연 행동(delayed action)이라고 볼 수 있습니다. 2026년의 대응물은 내구성 있는 워크플로 엔진(durable workflow engine)의 지연 과제(deferred task)입니다(Phase 16 · 22 프로덕션 확장).

이들 각각은 현대의 메시지 큐(message queue), HTTP + 폴링(polling), SSE 스트리밍(streaming)에 깔끔하게 매핑됩니다.

온톨로지를 버리면 무엇이 깨지는가

공유 온톨로지가 없으면 에이전트는 자연어 내용으로부터 의미를 추론할 수밖에 없습니다. 2026년에 문서화된 대표적인 실패 양상은 의미 표류(semantic drift)입니다. 두 에이전트가 "customer"처럼 같은 단어를 미묘하게 다른 개념으로 사용합니다. 수신 측 에이전트는 잘못된 해석에 따라 행동하고, 스키마 검증기(schema validator)는 그것을 잡아내지 못합니다. 만약 FIPA처럼 온톨로지를 강제했다면 이런 메시지는 파싱 단계에서 거절되었을 것입니다.

완전한 온톨로지로 가지 않으면서 위험을 완화하는 방법은 다음과 같습니다.

• content에 JSON Schema를 적용합니다. 통신 단계(wire)에서 구조 오류를 곧바로 거절할 수 있습니다.
• 타입이 있는 산출물(typed artifacts, A2A)을 사용합니다. 잘못된 모달리티(modality)를 거절할 수 있습니다.
• 봉투에 명시적인 수행문을 둡니다. 내용이 자연어이더라도 의도만큼은 모호하지 않게 표현됩니다.

2026년 사양을 화행 계보에 매핑하기

표를 위에서 아래로 읽어 내려가면 하나의 패턴이 드러납니다. 구조적 원시 기능은 그대로 유지하고, 형식성은 버리며, 그로 인해 생긴 모호성은 LLM이 덮어 주도록 맡기는 흐름입니다.

만들어보기

code/main.py는 표준 라이브러리만 사용해 FIPA-ACL 번역기를 구현합니다. 표준 ACL 봉투를 인코딩하고 디코딩하며, 모든 MCP / A2A 메시지 형태가 같은 일곱 개의 필드로 환원된다는 점을 보여줍니다. 데모는 다음과 같은 작업을 수행합니다.

• MCP 스타일과 A2A 스타일의 메시지 다섯 개를 FIPA-ACL로 인코딩합니다.
• FIPA-ACL을 다시 현대적 대응물로 디코딩합니다.
• 한 명의 관리자와 세 명의 입찰자 사이에서 cfp, propose, accept-proposal, reject-proposal을 사용해 작은 계약망 협상을 실행합니다.

실행 방법:

python3 code/main.py

출력은 각 현대 메시지를 2026년의 JSON 형태와 FIPA-ACL 형태로 나란히 보여 주고, 이어서 contract-net 입찰의 왕복 과정을 따라가는 추적(trace)입니다. 같은 프로토콜 원시 기능은 왕복 변환 이후에도 그대로 살아남습니다. 달라지는 것은 문법뿐입니다.

사용해보기

outputs/skill-fipa-mapper.md는 어떤 에이전트 프로토콜 사양이든 읽어 들여 FIPA-ACL 매핑을 만들어 주는 스킬(skill)입니다. 새 프로토콜을 채택하기 전에 "이것이 정말 새로운 것인가, 아니면 JSON 문법으로 갈아입은 inform에 불과한가?"라는 질문에 답하기 위해 사용합니다.

산출물 만들기

FIPA-ACL 그 자체를 되살리려고 하지는 마세요. 대신, 그 체크리스트만은 반드시 되살리세요.

• 각 메시지의 의도 원시 기능, 즉 수행문은 무엇입니까?
• 요청-응답과 취소를 서로 묶을 수 있는 상관 ID(correlation id)가 있습니까?
• 명시적인 내용 언어가 정해져 있습니까? JSON-RPC, 평문(plain text), 구조화된 타입 산출물(typed artifact) 가운데 무엇입니까?
• 상호작용 프로토콜이 일급(first-class) 시민으로 다뤄지고 있습니까, 아니면 매번 contract-net을 처음부터 다시 구현하고 있습니까?
• 두 에이전트가 내용의 의미에 대해 동의하지 않을 때, 즉 의미 표류(semantic drift)가 발생할 때 어떤 일이 일어납니까?

새 프로토콜을 프로덕션에 투입하기 전에 이 다섯 가지 질문을 문서로 남기세요.

연습문제

1. (쉬움) code/main.py를 실행해 보세요. 왕복 인코딩 과정을 관찰한 뒤, tools/call, resources/read, A2A 과제 생성에 각각 대응하는 FIPA 수행문이 무엇인지 식별해 보세요.
2. (중간) contract-net 데모에 cancel 수행문을 추가해, 관리자가 입찰 도중에 과제를 철회할 수 있도록 만들어 보세요. cancel은 단순한 재시도(retry)만으로는 해결되지 않는 어떤 실패 사례를 해결해 줄까요?
3. (중간) FIPA ACL Message Structure(http://www.fipa.org/specs/fipa00037/)의 4.1–4.3절을 읽어 보세요. 이 강의에서 다루지 않은 수행문 하나를 고른 뒤, 그것에 대응하는 현대 JSON-RPC 측의 메시지를 설명해 보세요.
4. (어려움) Liu 등, arXiv:2505.02279를 읽어 보세요. MCP, A2A, ACP, ANP 각각에 대해, 어떤 FIPA 수행문 계열을 유지하고 어떤 것을 버리는지 정리해서 나열해 보세요.
5. (어려움) 여러분이 다루고 있는 시스템에서 request 수행문의 content 필드를 위한 최소한의 JSON Schema를 설계해 보세요. 그 스키마는 순수한 자연어에는 없는 무엇을 제공해 주고, 그 대가로 어떤 비용을 치르게 합니까?

핵심 용어

더 읽을거리

• Liu et al. — A Survey of Agent Interoperability Protocols: MCP, ACP, A2A, ANP — 현대 사양들과 FIPA 계보를 연결해 정리한 대표적인 2025년 조사 논문입니다.
• FIPA ACL Message Structure Specification (fipa00037) — 2000년에 비준된 ACL 봉투 형식 명세입니다.
• FIPA Communicative Act Library Specification (fipa00037) — 전체 수행문 목록을 정리한 명세입니다.
• MCP specification 2025-11-25 — request/query-ref에 해당하는 현대의 도구 사용 사양입니다.
• A2A specification — contract-net과 subscribe-notify에 해당하는 현대의 에이전트 간 통신 사양입니다.