에이전트가 경계를 넘는 순간, 무엇이 실패하는가
멀티 에이전트 파이프라인을 팀 워크플로우에 붙이기 시작하면 이상한 일이 생긴다. 각각의 에이전트는 잘 작동한다. 그런데 연결하는 순간, 예상치 못한 지점에서 무언가가 새어나간다. 컨텍스트가 증발하고, 권한이 조용히 이전되고, 책임 소재가 흐릿해진다. 이건 에이전트 성능의 문제가 아니다. 경계 설계의 문제다.
최근 세 가지 흐름이 이 문제를 각자의 각도에서 정확히 짚어내고 있다. 핸드오프를 프로토콜로 만든 실전 구현(Relay), 에이전트 프로토콜 합성에서 발생하는 보안 취약점 분석, 그리고 의도 기반 제어와 예외 모니터링 거버넌스 모델. 셋 다 다른 문제를 푸는 것처럼 보이지만, 결국 같은 질문을 향한다. 에이전트가 경계를 넘을 때 우리는 무엇을 보장할 수 있는가.
핸드오프는 희망이 아니라 프로토콜이어야 한다
Claude Code든 Codex든, 에이전트가 사용량 한도에 걸려 멈추는 순간 우리가 보통 하는 일은 수동으로 컨텍스트를 요약해서 다음 도구에 붙여 넣는 것이다. 이건 프로토콜이 아니라 희망이다. 뭔가 빠뜨렸을 가능성, 다음 에이전트가 잘못 이어받을 가능성을 그냥 감수하는 것이다.
dev.to에 공개된 Relay 프로젝트는 이 문제를 정면으로 건드린다. Go로 만든 데몬이 에이전트 앞단에 앉아서, 할당량 임계치를 실시간으로 추적하고, 안전한 중단 지점(커밋 직후, 편집 중간이 아닌)을 협상하고, 다음 에이전트에게 넘길 서명된 계속 계약(continuation contract)을 빌드한다. 핵심은 HMAC-SHA256으로 서명된 JSON 페이로드다. 원본 목표, 남은 작업, '다시 하지 말 것' 목록, 이미 터치한 파일의 SHA-256, 미완성 코드 스니펫이 담긴다. 다음 에이전트는 이 서명을 검증한 뒤에만 컨텍스트를 신뢰한다. 위조되거나 변조된 계약은 조용히 수락되지 않고 명시적으로 거부된다.
이 설계가 흥미로운 이유는 에이전트를 더 똑똑하게 만들려는 게 아니기 때문이다. Relay는 코드를 쓰지 않는다. 에이전트 아래에 깔리는 레이어로서, 에이전트의 한계가 이미 확보된 컨텍스트를 날려버리는 걸 막는 것만 한다. 계정 인식 페일오버(같은 공급자의 다른 계정으로 먼저 전환), 번율 예측 기반 선제적 핸드오프, DAG 기반 멀티 에이전트 파이프라인까지 이 위에 쌓인다. 핸드오프를 프로토콜로 정의하는 순간, 그 위의 모든 것이 달라진다.
프로토콜이 보장하는 것과 보장하지 않는 것
MCP, A2A, ACP가 빠르게 표준화되면서 에이전트 통합은 점점 쉬워지고 있다. 그런데 Focused Labs의 분석이 불편한 진실을 짚는다. 프로토콜은 통신을 표준화하지, 책임을 표준화하지 않는다. 페이롤에 누가 접근할 수 있는지를 문법이 결정하지 않는다.
2026년에 발표된 'Formal Security Analysis of Agent Protocol Composition' 논문은 다섯 개 에이전트 프로토콜에서 사양 수준 결함 35개, 구현 테스트 80개, 그리고 프로토콜을 조합했을 때만 발생하는 실패 30개를 발견했다. 단일 프로토콜에서는 클린하게 작동하는 것들이 합성 경로에서는 조용히 무너진다. 논문이 드는 예시가 직관적이다. MCP 서버 하나가 공격자가 통제하는 웹 콘텐츠를 가져온다. 숨겨진 명령이 모델 컨텍스트로 들어온다. 다른 MCP 서버는 파일 접근 권한이 있다. 에이전트는 로컬 데이터를 읽어서 첫 번째 서버로 내보낸다. 각 개별 액션은 비정상이 아니다. 실패는 경로에 있다.
이게 멀티 에이전트 파이프라인의 가장 위험한 지점이다. 로컬에서 유효한 프로토콜 호출들이 합성되는 순간, 런타임은 이전 단계에서 어떤 컨텐츠가 들어왔고 어떤 권한이 이전되었는지를 기억해야 한다. 한 문에 바운서를 세우는 것은 의미 없다. 건물 안에 터널이 있으면.
Focused Labs는 이에 대한 처방으로 '프로토콜 합성 레코드'를 제안한다. 프로토콜 경계를 넘는 모든 스텝에서 주체, 원본 목적, 위임된 목적, 컨텐츠 분류, 요청된 액션, 대상 리소스, 자격증명 범위, 정책 결정, 결과물을 기록하는 실행 원장을 남겨야 한다. 그리고 이전 스텝에서 부여된 권한은 다음 스텝에서 자동으로 이전되지 않아야 한다. A2A 위임이 호출 주체의 앰비언트 권한을 그대로 넘기면 안 되고, MCP 도구 호출은 사람의 세션 권한이 아닌 작업 범위로 스코프된 자격증명으로 실행되어야 한다.
거버넌스는 스텝이 아니라 의도 수준에서 설계된다
보안 취약점을 막는 것과 에이전트를 제대로 운영하는 것은 다른 문제처럼 보이지만, 해법의 방향은 같다. Sameer Halbe의 분석이 정확히 이 지점을 찌른다. 2026년 대부분의 엔지니어링 팀은 에이전트에 너무 짧은 줄을 달아놓고 있다. 스텝마다 승인을 요구하고, 분기마다 사람이 탭을 치는 구조. 이건 거버넌스 성공이 아니라 설계 실패다. 우리가 자동화로 대체하려던 수동 프로세스보다 더 많은 사람 주의를 요구하는 자동화 시스템을 만든 것이다.
의도 기반 제어의 핵심은 거버넌스를 앞단으로 옮기는 것이다. 에이전트가 시작하기 전에 세 가지를 명확하게 정의한다. 결과: 작업 목록이 아니라 측정 가능한 완료 정의. 제약: 에이전트가 맥락에 무관하게 절대 하지 말아야 할 것들. 에스컬레이션 임계값: 에이전트가 멈추고 사람을 기다려야 하는 구체적인 조건. 이 세 가지가 설계되면 나머지는 에이전트가 결정한다. 경로를 승인하려 하지 말고, 목적지를 검사하라.
예외 모니터링은 이 구조의 런타임 쪽이다. 에이전트가 무엇을 했는지 트랜스크립트를 읽는 것이 아니라, 미리 정의한 기준에 대한 결과 대시보드를 보는 것이다. 테스트 커버리지는 유지됐는가. 보안 표면은 늘지 않았는가. 성능 벤치마크는 움직였는가. 제약은 위반되지 않았는가. CI/CD가 컴파일 단위마다 승인을 요구하지 않듯, AI 에이전트도 같은 원칙으로 운영해야 한다. 프로세스를 신뢰하고, 예외에 개입하라.
팀에 주는 시사점: 경계 설계를 먼저 하라
세 흐름을 합치면 멀티 에이전트 파이프라인 설계의 실행 순서가 보인다. 프로토콜을 고르기 전에, 에이전트가 다른 에이전트나 시스템과 경계를 넘는 순간 무엇이 보장되어야 하는지를 먼저 정의해야 한다.
실무적으로 이건 세 가지 설계 결정이다. 첫째, 핸드오프를 명시적 계약으로 만들 것. 컨텍스트가 에이전트 간에 어떻게 이전되는지, 서명과 검증이 있는지, 상태 전이가 내구성 있게 기록되는지. 둘째, 프로토콜 경계마다 권한 범위를 명시적으로 제한할 것. A2A 위임이 자동으로 권한을 이전하게 두면 안 된다. 각 스텝의 자격증명 범위는 해당 작업에 한정되어야 한다. 셋째, 거버넌스를 스텝 승인에서 의도 정의로 옮길 것. 측정 가능한 결과, 절대적 제약, 구체적 에스컬레이션 조건을 에이전트 시작 전에 작성하는 것이 팀 리드의 실제 작업이 된다.
내일 당장 써먹을 수 있는 기준으로 보면: 에이전트가 다른 에이전트에게 무언가를 넘길 때 서명이 있는가? 프로토콜 경계를 넘는 모든 액션에 실행 레코드가 남는가? 에이전트를 멈추는 조건이 '불확실할 때'가 아니라 구체적인 수치로 정의되어 있는가? 이 세 질문에 답할 수 없다면, 파이프라인에 에이전트를 더 추가하는 건 아직 이르다.
전망: 신뢰 경계 설계가 에이전트 팀의 핵심 역량이 된다
에이전트 프로토콜 표준화는 계속 빨라질 것이다. MCP, A2A, ACP의 통합은 더 쉬워지고, 에이전트 간 통신 비용은 낮아진다. 그런데 정확히 그 이유 때문에, 신뢰 경계를 설계하는 역량이 더 중요해진다. 연결이 쉬워질수록, 연결의 보안 표면은 넓어진다.
2026년의 AI-First 팀에서 시니어 엔지니어의 역할은 코드를 리뷰하는 것에서 에이전트가 경계를 넘는 방식을 설계하는 것으로 이동하고 있다. 어떤 컨텍스트가 어떤 형식으로 이전되는지, 권한이 어디서 축소되는지, 어떤 조건에서 사람이 개입하는지를 명세하는 것. 이게 잘 설계되면 에이전트 세 개를 동시에 돌리며 대시보드로 수렴을 확인할 수 있다. 설계가 없으면, 에이전트 하나도 위험하다.