도구 호출 성공과 문서 작업 완료는 다르다: MCP·A2A의 책임 경계
MCP 도구 결과와 A2A 작업 상태가 무엇을 보증하는지 구분한다. 문서 버전과 산출물 해시가 엇갈리는 예제로 인계와 검수 완료 조건을 설명한다.
문서 자동화에서는 DOCX를 내용 원본으로, HWP를 양식 원본으로 삼아 초안 내용을 양식에 맞춰 넣고 전체 페이지를 검수한다.
MCP는 에이전트와 kordoc의 호출 규약이다
에이전트는 파일 확장자만 보고 문서 구조를 이해하지 못한다. DOCX의 제목, 문단, 표를 읽고 HWP의 단 구성과 서식을 그대로 살리려면 문서 전용 도구인 kordoc이 필요하다.
MCP의 도구 호출과 A2A의 task·artifact 계약은 각각의 공식 명세에서 확인할 수 있다. 공식 자료 1 (https://github.com/chrisryugj/kordoc (새 창)) · 공식 자료 2 (https://modelcontextprotocol.io/specification/2026-07-28 (새 창))
kordoc은 HWP, HWPX, DOCX, PDF를 파싱하고, 편집한 내용을 원본 HWP/HWPX에 다시 반영하며, 결과를 이미지나 SVG로 렌더링한다. 이를 MCP 서버로 연결하면 에이전트는 parse_document, patch_document, render_document 같은 도구를 정해진 스키마에 맞춰 호출한다.
MCP는 연결과 호출을 담당한다. 사용할 수 있는 도구를 찾고 입력값 형식을 맞추며 결과와 오류를 돌려받는 방식을 정한다. 문서 에이전트는 kordoc의 TypeScript API 내부를 일일이 알 필요 없이 MCP 도구의 이름과 스키마만 보고 필요한 작업을 요청하면 된다.
문서의 의미를 판단하거나 여러 에이전트에게 책임을 나누는 일은 MCP의 몫이 아니다. “저자명이 초안에 없으니 임의로 만들지 않는다”는 기준은 에이전트의 정책이며, “본문이 두 단을 넘쳤을 때 어느 문단을 줄일지”도 도구 연결만으로 결정되지 않는다.
| 구분 | 상대 | 주고받는 단위 |
|---|---|---|
| MCP | 문서 에이전트 ↔ kordoc 도구 | 파싱·패치·렌더링의 입력과 결과 |
| A2A | 편집 에이전트 ↔ 검수 에이전트 | 위임한 작업의 상태·산출물·완료 |
A2A는 작업 책임을 넘기는 규약이다
같은 과정을 여러 전문 에이전트로 나누는 경우를 보자.
문서 분석 에이전트는 DOCX에서 제목, 초록, 본문, 참고문헌을 추출한다. 편집 에이전트는 HWP 양식의 슬롯과 서식을 확인해 내용을 배치한다. 검수 에이전트는 전체 페이지 렌더링 결과에서 단 넘침, 잘린 표, 빈 페이지를 찾는다. 승인 에이전트는 초안에 없던 저자명·소속·이메일이 새로 생기지 않았는지 확인한다.
이 에이전트들이 서로 다른 프로세스나 조직에서 동작한다면 단순한 도구 호출 규약만으로는 부족하다. 각자 수행 가능한 기능을 공개하고, 작업을 위임받아 중간 상태와 산출물을 주고받으며 완료나 실패 여부를 알려야 한다. 이 영역을 A2A가 다룬다.
Linux Foundation의 설명대로 MCP와 A2A는 경쟁 관계가 아니다. MCP는 에이전트와 내부 도구·데이터의 연결을, A2A는 서로 다른 에이전트 간의 협업을 다룬다. 문서 분석 에이전트가 내부에서 kordoc MCP를 쓰고 A2A로 검수 에이전트에게 결과를 넘기는 구성도 가능하다.
한 에이전트가 처리하는 편이 나을 때
프로토콜이 있다고 해서 모든 작업을 여러 에이전트로 나눌 필요는 없다. DOCX와 HWP 두 파일을 읽어 한 번의 결과를 만드는 작업이라면 에이전트 하나가 여러 MCP 도구를 차례로 호출하는 구성이 더 단순하다. 상태를 전달하는 과정에서 정보가 누락될 가능성도 줄어든다.
A2A는 책임과 실행 경계가 실제로 나뉠 때 필요하다. 문서 내용은 내부망에서만 처리하고 외부 기관의 형식 검증 서비스에는 비식별 결과만 보내야 할 수 있다. 에이전트마다 서로 다른 자격증명과 승인 절차가 필요한 경우도 있다. 이때 분리는 단순한 구조 장식이 아니라 보안과 감사의 경계가 된다.
프로토콜을 고르기 전에 정할 것
먼저 누락된 정보가 있으면 어디서 멈출지, 어느 서식까지 보존할지, 시각 검수에서 무엇을 실패로 처리할지 정한다. 호출 성공만으로 문서 작업의 성공을 판단할 수는 없다.
성공 조건에는 원문에 없는 저자명·소속·이메일을 만들지 않는 것과 미확정 참고문헌을 보존하는 것이 포함된다. 결과 파일을 열어 보는 데서 그치지 않고 전체 페이지를 렌더링해 검수해야 한다.
한 에이전트가 도구를 호출해 끝낼 수 있다면 MCP 연결부터 구성한다. 독립된 실행 주체에 작업 책임을 넘겨야 할 때 A2A의 상태·산출물·완료 계약을 검토한다.
가상 문서 작업에서 편집 도구가 파일 V2를 저장했고 검수 에이전트는 V1의 렌더 이미지를 확인했다고 하자. MCP 호출은 성공했으며 A2A 작업도 완료로 보고될 수 있지만, 정작 최종 파일 V2는 검수되지 않았다. 통신 규약이 맞아도 어떤 산출물 버전을 검증했는지가 빠지면 업무 완료를 잘못 판단한다. 작업을 인계할 때는 산출물 식별자·해시와 검수 대상 버전을 함께 연결해야 한다.
상태도 구분한다. 도구가 요청을 받았다는 응답, 파일 저장 완료, 내용 검사 통과, 페이지 검수 통과는 서로 다른 사건이다. A2A의 작업 완료 상태에 어떤 업무 조건을 대응시킬지는 해당 서비스가 정한다. 문서 검수를 맡겼다면 검수 산출물이 존재하는지, 실패 항목이 남았는지, 검사한 해시가 최종 파일과 같은지를 확인한다.
응답이 끊겼을 때 새 작업을 무조건 생성하면 같은 파일을 두 번 수정할 수 있다. 원래 task 식별자와 서비스의 재조회·재시도 계약을 사용해 상태를 확인하고, 쓰기 중복 방지는 실행 서비스가 명시적으로 보장하도록 한다. MCP나 A2A 연결만으로 모든 외부 효과가 알아서 한 번만 실행된다고 가정해서는 안 된다.
참고 자료
kordoc GitHub 저장소 (https://github.com/chrisryugj/kordoc (새 창))
Model Context Protocol 2026-07-28 명세 (https://modelcontextprotocol.io/specification/2026-07-28 (새 창))
A2A Protocol의 역할과 MCP와의 관계 (https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year (새 창))
