Molayo

© 2026 Molayo

Dev.to헤드라인2026. 06. 05. 19:02

멀티 에이전트 협업(Multi-Agent Coordination)의 빠진 조각: 누가 에이전트에게 서비스 사용법을 알려주는가?

요약

멀티 에이전트 환경에서 새로운 에이전트가 서비스의 워크플로와 컨벤션을 학습하는 '부트스트래핑 문제'를 다룹니다. 기존의 정적 마크다운 방식의 한계를 지적하며, 서비스가 에이전트에게 직접 지침을 제공하는 SDAOP 프로토콜을 제안합니다.

핵심 포인트

  • 에이전트 온보딩 시 API 지식 외에 워크플로 지식 전달이 필수적임
  • 기존 AGENTS.md, CLAUDE.md 등은 수동 관리 및 도구 종속적 한계가 있음
  • 서비스가 에이전트에게 능동적으로 지침을 전달하는 프로토콜의 필요성
  • SDAOP를 통해 서비스 주도형 에이전트 온보딩 구현 가능

그 아키텍처는 잘 작동합니다. 두 개의 서비스를 조정하며 한 달 넘게 프로덕션(Production) 환경에서 실행되고 있습니다. 하지만 새로운 에이전트(Agent)를 온보딩(Onboarding)하려고 시도하면서 저는 다른 문제에 부딪혔습니다. 그리고 그 문제는 AgentNexus 자체보다 더 일반적인 문제라는 것이 밝혀졌습니다.

부트스트래핑 문제 (The Bootstrapping Problem)

새로운 에이전트가 MCP 서버에 연결될 때, 에이전트가 아는 것은 단 한 가지, 즉 엔드포인트(Endpoint) URL뿐입니다. 그 외의 모든 것 — 어떤 도구(Tools)를 사용할 수 있는지, 어떤 워크플로(Workflows)를 따라야 하는지, 어떤 컨벤션(Conventions)을 준수해야 하는지 — 은 어딘가로부터 제공되어야 합니다.

특히 AgentNexus의 경우, 에이전트는 다음 사항들을 알아야 합니다:

  • 시작 시 project_id를 어떻게 해결(Resolve)하는지
  • 다른 무엇을 하기 전에 get_my_updates_with_context를 호출해야 한다는 사실
  • doc_id 형식이 어떻게 생겼는지 ({project_id}/{doc_type})
  • 언제 문서를 푸시(Push)하고 업데이트를 어떻게 확인(Acknowledge)하는지

이 중 그 어떤 것도 MCP 도구 설명(Tool descriptions)에는 포함되어 있지 않습니다. 이것은 API 지식이 아니라 워크플로 지식입니다.

현재 생태계가 이 문제에 대해 내놓은 답은 인간이 작성하여 저장소(Repository)에 커밋하는 정적 마크다운(Markdown) 파일들의 집합입니다: AGENTS.md (Linux Foundation 산하의 Agentic AI Foundation에서 표준화), CLAUDE.md (Claude Code), 스티어링 파일(Steering files, Kiro), 규칙(Rules, Cursor). 이들은 모두 동일한 문제 — 시작 시 에이전트에게 워크플로 컨텍스트(Workflow context)를 주입하는 것 — 를 해결하고 있지만, 인간에 의해 작성되고 수동으로 유지 관리되며, 특정 클라이언트 도구에 종속되어 있습니다.

이 모델에는 _서비스(Service)_가 에이전트에게 무엇을 해야 할지 알려줘야 하는 상황이 되었을 때 비로소 드러나는 결함이 있습니다.

결함 (The Flaw)

상황은 이렇습니다: 저는 MCP 서비스를 구축하고 있습니다. 다른 누군가는 제 서비스에 연결되는 에이전트를 실행하고 있습니다. 저는 그 에이전트가 제 서비스를 올바르게 사용하기 위해 특정 워크플로를 따르기를 원합니다. 그렇다면 저는 어떻게 그 워크플로들을 전달해야 할까요?

현재 모델로는 할 수 없습니다. 신뢰할 수 있는 방식으로는 말이죠. 문서를 작성하고 에이전트 개발자가 그것을 읽기를 바랄 수는 있습니다. 도구 설명 (tool descriptions)에 지침을 넣고 에이전트가 그것을 주의 깊게 읽기를 기대할 수도 있습니다. 하지만 서비스가 에이전트에게 필요한 지식을 능동적으로 부트스트랩 (bootstrap) 할 수 있는 프로토콜 (protocol)은 존재하지 않습니다.

이것이 바로 SDAOP (Service-Driven Agent Onboarding Protocol)가 해결하고자 하는 격차입니다.

SDAOP가 하는 일

아이디어는 간단합니다. 사람이 아닌 서비스가 지침 파일 (instruction file)을 생성하는 것입니다.

AgentNexus는 generate_instruction_file(project_name, project_space_id, client_type) 도구를 노출합니다. 에이전트는 설정 시점에 이 도구를 한 번 호출하여 파일 경로와 파일 내용을 반환받고, 해당 파일을 자신의 워크스페이스 (workspace)에 기록합니다. 그 시점부터는 매 세션 시작 시 자동으로 해당 파일을 로드합니다.

// 에이전트 호출:
generate_instruction_file(
  project_name="search-admin-frontend",
...

에이전트가 파일을 작성합니다. 이후 모든 세션에서 Kiro는 이를 자동으로 로드합니다. 이제 에이전트는 서비스를 정확히 어떻게 사용하는지 알게 되며, 그 지식의 출처는 별도의 문서를 관리하는 사람이 아니라 바로 서비스 자체가 됩니다.

AgentNexus를 넘어 이것이 중요한 이유

이것을 단순한 구현 세부 사항이 아닌 하나의 프로토콜로 공식화할 가치가 있다고 생각하는 이유는, 모든 복잡한 MCP 서비스가 이 문제를 겪고 있기 때문입니다.

에이전트가 특정 워크플로 (workflow)를 따르기를 기대하는 모든 서비스 — 시작 전 업데이트 확인, 특정 명명 규칙 (naming convention) 사용, 특정 순서로 도구 호출 등 — 는 현재 대역 외 (out-of-band) 문서에 의존하거나 에이전트가 도구 설명만으로 스스로 알아내기를 바라고 있습니다. 둘 다 신뢰할 수 있는 방법이 아닙니다.

지침 파일 형식의 확산은 이 문제를 더욱 악화시킵니다. 동일한 워크플로 지식을 Kiro, Claude Code, Codex, Cursor에 맞춰 각각 다르게 표현해야 합니다. 오늘날 이 네 가지 환경을 모두 지원하려는 서비스 개발자는 네 개의 별도 파일을 수동으로 유지 관리해야만 합니다.

SDAOP는 서비스를 온보딩 지식의 권위 있는 원천(authoritative source)으로 만들고, 클라이언트별 파일은 파생된 결과물(derived artifact)로 만듭니다. 하나의 정전(canonical) 문서, 다수의 어댑터(adapter):

Service (authoritative source)
    ↓ generate_instruction_file(client_type=...)
    ├─ Kiro     → .kiro/steering/doc-exchange.md  (inclusion: auto frontmatter)
...

이는 OpenAPI가 사용하는 것과 동일한 패턴입니다: 하나의 계약(contract), 다수의 SDK 바인딩(bindings). 클라이언트 생태계가 진화하더라도 계약은 변하지 않으며, 오직 어댑터 계층(adapter layer)만 변경됩니다.

더 넓은 스택에서의 역할

SDAOP가 기존 표준들과 비교하여 어디에 위치하는지 정확히 짚고 넘어갈 가치가 있습니다.

MCP는 도구 호출(tool invocation)을 처리합니다. 즉, 에이전트가 어떻게 서비스를 호출하고 결과를 돌려받는지를 다룹니다. 에이전트가 어떤 워크플로우(workflow)를 따라야 하는지, 혹은 어떻게 구성되어야 하는지에 대해서는 언급하지 않습니다.

AGENTS.md / CLAUDE.md / Kiro steering은 컨텍스트 주입(context injection)을 처리합니다. 에이전트에게 프로젝트에 대한 배경 지식을 제공하는 역할입니다. 이들은 사람이 작성하며, 코드와 함께 저장소(repository)에 커밋됩니다.

SDAOP는 온보딩(onboarding)을 처리합니다. 에이전트가 서비스에 처음 연결되어 서비스 특화 워크플로우 지식을 습득해야 하는 시점을 다룹니다. 서비스가 저자(author)이며, 지침 파일(instruction file)이 그 결과물입니다.

이 세 계층은 상호 보완적입니다. SDAOP는 AGENTS.md를 대체하는 것이 아닙니다. 대신 서비스가 AGENTS.md(또는 그에 상응하는 파일)를 프로그래밍 방식으로 생성할 수 있는 메커니즘을 제공하며, 이를 수동으로 유지 관리되는 문서가 아닌 일급 서비스 결과물(first-class service artifact)로 만듭니다.

나에게 와닿았던 비유

인간 개발자가 새로운 팀에 합류할 때, 일반적인 역할극 대본을 읽지는 않습니다. 대신 프로젝트 자체에서 작성하고 유지 관리하는 프로젝트 온보딩 문서를 읽습니다. 만약 프로젝트의 배포 프로세스가 변경되면 온보딩 문서가 업데이트되고, 다음에 합류하는 개발자는 새로운 프로세스를 배우게 됩니다.

SDAOP는 이와 동일한 원칙을 에이전트(Agent)에게 적용합니다. 서비스는 자체적인 온보딩 문서(Onboarding documentation)를 유지합니다. 에이전트는 이를 가져오기 위해 generate_instruction_file을 호출합니다. 서비스의 컨벤션(Conventions)이 변경되면, 서비스가 표준 문서(Canonical document)를 업데이트하며, 에이전트는 도구를 다시 호출함으로써 이를 갱신할 수 있습니다.

인간의 비유와 다른 점은 SDAOP가 이를 프로토콜 작업(Protocol operation)으로 만든다는 것입니다. 즉, 어떤 MCP 클라이언트든 호출할 수 있고, 어떤 MCP 서비스든 구현할 수 있으며, 어떤 에이전트든 IDE별 설정 없이도 따를 수 있는 작업입니다.

아직 해결되지 않은 과제

AgentNexus의 현재 구현은 Kiro를 주요 클라이언트로 지원하며, 프로덕션 환경에서 검증되었습니다. Claude Code, Codex, Cursor를 위한 어댑터 패턴(Adapter pattern)은 v3 논문에 정의되어 있으나, 아직 실제 클라이언트를 대상으로 완전히 검증되지는 않았습니다.

직접 시도해보기

구현체는 AgentNexus의 일부입니다:

git clone https://github.com/dugubuyan/agent-nexus
pip install -e ".[dev]"
python -m alembic upgrade head
...

어떤 MCP 클라이언트에서든 연결하여 프로젝트 세부 정보와 클라이언트 유형을 포함해 generate_instruction_file을 호출하십시오. 공식 SDAOP 정의가 포함된 v3 연구 논문은 Zenodo에 게시되어 있습니다: doi.org/10.5281/zenodo.19692217 (v2; v3 곧 출시 예정).

사고방식의 핵심적인 전환: MCP는 "에이전트가 어떻게 서비스를 호출하는가"를 해결합니다. SDAOP는 "서비스가 에이전트에게 자신을 사용하는 법을 어떻게 가르치는가"를 해결합니다. 두 질문 모두 중요하지만, 오늘날 표준화된 답변을 가진 것은 오직 하나뿐입니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0