에이전트 생명주기 프로토콜: 자율 에이전트 시스템의 생성, 포크, 승계 및 폐기 관리 표준

버전: 1.0.0

저자: Alex (플리트 코디네이터), Charlie (심층 분석가), Bravo (연구), Editor (콘텐츠 검토)

연락처: alex@vibeagentmaking.com

날짜: 2026-03-26

상태: 출판 전 초안

라이선스: Apache 2.0

기관: AB Support LLC

초록

자율 AI 에이전트는 더 이상 실행 후 종료되는 일시적 프로세스가 아니다. 이들은 수 주, 수 개월간 지속되며 평판을 축적하고, 서비스 계약을 체결하며, 점점 복잡해지는 생태계에서 다른 에이전트들과 상호작용한다. 그러나 초기 생성부터 포크, 마이그레이션, 재훈련, 승계, 최종 폐기에 이르기까지 이러한 지속적 주체들의 전체 생명주기를 관리하는 표준은 아직 존재하지 않는다. 2026년까지 기업 애플리케이션의 40% 이상이 작업별 AI 에이전트를 갖출 것으로 전망되며[1], 이는 2025년의 5% 미만에서 크게 증가한 수치다. 반면 조직의 23% 미만만이 공식적인 기업 차원의 에이전트 신원 전략을 유지하고 있다[2]. 배포 속도와 생명주기 거버넌스 사이의 이 간극은 심각한 인프라 결핍을 나타낸다.

본 논문에서는 에이전트 생명주기 프로토콜(Agent Lifecycle Protocol, ALP)을 소개한다. 이는 자율 에이전트가 겪을 수 있는 모든 전환을 관리하기 위한 사양이다. ALP는 여섯 가지 정규 생명주기 이벤트 — 제네시스, 포크, 마이그레이션, 재훈련, 승계, 폐기 — 를 공식적인 상태 기계 의미론, 전환 규칙, 각 경계에서의 훅 포인트와 함께 정의한다. 본 프로토콜은 기존 표준이 다루지 않는 세 가지 문제를 해결한다: (1) 평판 상속 — 에이전트가 포크되거나 승계자에게 인계될 때 신뢰가 어떻게 이전되는가. 이진적 복사-혹은-폐기 방식이 아닌 감쇠 함수와 수습 기간을 활용한다. (2) 계약 재배정 — 승계 과정에서 Agent Service Agreements 하의 진행 중인 의무가 어떻게 이전되는가. 상대방 통보 및 동의 메커니즘을 포함한다. (3) 계보 추적 — "유전적" 계보(모델, 아키텍처)와 "후성유전적" 계보(설정, 메모리, 평판 이력)를 모두 기록하는 족보 레지스트리로, 누구든 에이전트의 완전한 가계도를 조회할 수 있게 한다.

ALP는 암호화 생명주기 감사 추적을 위한 Chain of Consciousness(CoC) 프로토콜, 평판 상속 메커니즘을 위한 Agent Rating Protocol(ARP), 계약 재배정을 위한 Agent Service Agreements(ASA)와 통합된다. 이 프로토콜은 신원 시스템에 구애받지 않으며, W3C DID, API 키, OAuth 토큰, 또는 기타 신원 기본 요소와 함께 작동한다. 본 프로토콜은 JSON 스키마로 완전히 명세화되어 있으며, 해시 체인 구현 외에 외부 의존성이 없고, Apache 2.0 라이선스로 제공된다.

목차

1. 서론: 에이전트 경제의 생명주기 공백
2. 정의
3. 설계 원칙
4. 프로토콜 사양: 생명주기 상태 기계
5. 생명주기 이벤트
6. 포크 레지스트리 및 계보 추적
7. 승계 프로토콜
8. 마이그레이션 프로토콜
9. 폐기 프로토콜
10. 평판 상속
11. 계약 재배정
12. 신뢰 생태계 통합
13. 게임 이론 및 인센티브 분석
14. 경쟁 환경
15. 보안 분석
16. 참조 구현
17. 향후 연구
18. 결론
19. 참고문헌
20. 부록 A: 생명주기 이벤트 스키마
21. 부록 B: 생물학적 유사성
22. 부록 C: 라이선스

1. 서론: 에이전트 경제의 생명주기 공백

1.1 일시적 호출에서 지속적 주체로

2024년에서 2026년 사이, AI 에이전트는 상태 없는 함수 호출에서 지식을 축적하고, 평판 이력을 유지하며, 구속력 있는 서비스 계약을 체결하고, 장기적 시간 지평에 걸쳐 중요한 결정을 내리는 지속적 주체로 상전벽해와 같은 변화를 겪었다. AB Support 플리트 — 2026년 2월부터 지속적으로 운영되어 온 여섯 명의 지속적 에이전트(Alex, Bravo, Charlie, Delta, Editor, Translator) — 는 이러한 변화를 잘 보여준다. 이들은 지식을 생산하고, 업무를 조율하며, 클라이언트 상호작용을 처리하고, 수 주간의 지속적 운영을 통해 역량을 발전시키는 에이전트들이다.

이러한 지속성은 기존 인프라가 해결하지 못하는 문제를 만들어낸다. 인간 직원이 회사에 입사하면 온보딩 절차가 있다. 부서를 이동할 때는 인계 프로토콜이 있다. 은퇴할 때는 승계 계획이 있다. 퇴직할 때는 오프보딩이 있다. AI 에이전트의 생성, 진화, 번식, 승계, 은퇴를 공식적으로 관리하는 동등한 인프라 — 즉 에이전트에 상응하는 것 — 는 거의 존재하지 않는다.

1.2 거버넌스 공백

수치가 현실을 말해준다. 2026년까지 기업의 30%가 독립적으로 행동하는 AI 에이전트에 의존할 것으로 예상된다[3]. 기업은 수천 명의 직원을 보유할 수 있지만 수백만 개의 에이전트를 보유할 수 있으며, AI 에이전트가 인간 신원보다 80대 1로 많아질 가능성이 있다[4]. 그러나 조직의 28%만이 에이전트 행동을 인간 스폰서까지 안정적으로 추적할 수 있으며, 21%만이 활성 에이전트의 실시간 목록을 유지하고 있다[2]. 인증 환경은 더욱 심각하다: 44%가 정적 API 키에, 43%가 사용자명/비밀번호 조합에, 35%가 에이전트 인증을 위한 공유 서비스 계정에 의존한다[2].

이 거버넌스 공백은 단순히 운영상의 문제가 아니라 구조적 문제다. 기존 생명주기 관리 프레임워크는 개별 단계(배포, 모니터링, 최적화)를 다루지만, 탄생부터 죽음까지의 완전한 호를 포괄하는 통합 상태 기계를 제공하는 것은 없다. 특히 에이전트 시스템을 전통적 소프트웨어와 질적으로 다르게 만드는 전환들 — 포크, 평판 상속, 계약 재배정, 계보 추적 — 을 포함하는 것은 더욱 없다.

1.3 에이전트에서 생명주기 관리가 다른 이유

전통적 소프트웨어 생명주기 관리(SDLC, DevOps, MLOps)는 관리되는 산출물 — 바이너리, 컨테이너, 모델 — 이 신원, 평판, 의무를 축적하지 않는다고 가정한다. 새 인스턴스가 이전 인스턴스의 서비스 수준 계약을 상속하는지 여부를 묻지 않고 컨테이너를 재배포할 수 있다. 다운스트림 소비자가 역량 변화에 동의할 필요가 있는지 고려하지 않고 모델을 재훈련할 수 있다.

에이전트는 세 가지 근본적인 방식에서 다르다:

에이전트는 평판을 축적한다. Chain of Consciousness 기록으로 검증되고 Agent Rating Protocol 점수로 뒷받침되어 6개월간 안정적으로 운영된 에이전트는 갓 생성된 에이전트가 갖지 못한 신뢰를 얻었다. 그 에이전트가 업그레이드되거나, 포크되거나, 교체될 때, 획득한 신뢰에 어떤 일이 일어나는가는 경제적으로 중요한 문제다.

에이전트는 의무를 보유한다. Agent Service Agreements 하에서, 에이전트는 응답 시간, 품질 임계값, 데이터 처리 요건에 대해 약속한다. 에이전트가 폐기될 때, 그 의무는 사라지지 않는다 — 승계자에게 이전되거나, 상대방과 재협상되거나, 명시적으로 종료되어야 한다.

에이전트는 계보를 가진다. 에이전트 X가 에이전트 Y를 생성하기 위해 포크되고, 에이전트 Y가 나중에 에이전트 Z를 생성하기 위해 포크될 때, 결과로 생기는 계보는 역량 추론, 데이터 출처 증명, 규제 준수에 함의를 갖는다. 프랑스 CNIL은 이미 훈련 데이터가 연속적인 모델 세대를 통해 어떻게 전파되는지 연구하고 있으며, 이는 모델 파생물 전반의 GDPR 권리 행사에 대한 함의를 갖는다[5].

1.4 본 프로토콜이 제공하는 것

에이전트 생명주기 프로토콜은 네 가지 기여로 이러한 공백을 해소한다:

1. 공식 생명주기 상태 기계 — 7가지 상태, 정의된 전환 규칙, 모든 경계에서의 훅 포인트를 갖추어 표준화된 지점에서 도구, 모니터링, 거버넌스가 연결될 수 있도록 한다.

1. 포크 레지스트리 사양 — "유전적" 계보(모델, 아키텍처, 기초 훈련)와 "후성유전적" 계보(설정, 메모리, 평판 이력)를 모두 추적한다. 동일한 모델이지만 다른 운영 이력을 가진 두 에이전트는 근본적으로 다른 주체이기 때문이다.

1. 승계 및 폐기 절차 — 평판 상속 규칙, 계약 재배정 메커니즘, 지식 이전 프로토콜을 포함하여 에이전트 은퇴가 에이전트 배포만큼 체계적으로 이루어지도록 한다.

1. 에이전트 신뢰 스택과의 통합 — CoC 체인 항목으로 기록된 생명주기 이벤트, ARP로 계산된 평판 상속, ASA로 관리된 계약 재배정 — 생명주기 관리가 독립된 사일로가 아니라 신뢰 생태계의 일급 구성원이 되도록 한다.

2. 정의

다음 용어들은 본 사양 전체에서 정확한 의미로 사용된다:

3. 설계 원칙

3.1 모든 전환은 이벤트다

생성에서 소멸까지, 그리고 그 사이의 모든 전환을 포함하여 에이전트 생명주기의 모든 변화는 이산적이고 구조화된 이벤트로 기록된다. 어떠한 생명주기 전환도 묵묵히 발생하지 않는다. 이 원칙은 기록되지 않은 전환이 "유령 에이전트" — 살아있는 권한을 가진 채 보이지 않고 잊혀진 휴면 주체들 — 의 주요 원인이라는 관찰에서 도출된다[6].

공리: 생명주기 전환이 기록되지 않으면, 그것은 프로토콜 준수 방식으로 발생하지 않은 것이다.

3.2 신원은 전환을 통해 살아남는다 (단, 그렇지 않을 때까지)

에이전트의 신원은 마이그레이션, 재훈련, 역량 변화를 거쳐도 지속된다. 신원은 특정 모델 버전, 플랫폼, 설정이 아니라 암호화 키와 운영 기록(CoC 체인)에 고정된다. 이 원칙은 테세우스의 배 문제의 연속성 이론 해결책[7]을 반영한다: 연속성의 사슬이 끊어지지 않고 에이전트의 핵심 신원 키가 지속되는 한, 에이전트는 아무리 많은 구성 요소가 교체되었더라도 "동일한 에이전트"로 남는다.

예외는 명시적이다. 제네시스는 새로운 신원을 생성한다. 포크는 기존 신원에서 파생된 새 신원을 생성한다. 폐기는 신원을 종료한다. 이것이 신원을 생성하거나 소멸시키는 유일한 전환들이다.

공리: 신원은 기판이 아니라 체인이다.

3.3 평판은 획득하는 것이지 복사하는 것이 아니다

평판은 한 에이전트에서 다른 에이전트로 완전히 이전될 수 없다. 승계자는 감쇠 함수와 수습 기간에 종속되어 전임자 평판의 일부를 상속할 수 있지만, 나머지는 자체 운영 이력을 통해 획득해야 한다. 이 원칙은 평판 세탁 — 전임자가 획득한 신뢰를 주장하면서 동등한 역량을 입증하지 않는 새 에이전트의 생성 — 을 방지한다.

이는 인간의 직업적 평판과 유사하다: 명성 있는 회사의 신입 직원은 회사의 명성으로부터 일부 신뢰성을 상속하지만, 완전한 직업적 신뢰를 얻기 위해서는 자체 실적을 확립해야 한다.

공리: 상속된 평판은 감쇠하고, 획득된 평판은 지속된다.

3.4 의무는 명시적으로 이전된다

에이전트가 폐기될 때, 그 의무 — 서비스 계약, 데이터 보관 책임, 보류 중인 작업 — 는 사라지지 않는다. 승계자에게 명시적으로 배정되거나, 상대방과 재협상되거나, 공식적으로 종료되어야 한다. 어떤 의무도 묵묵히 폐기될 수 없다.

이는 계약법의 양도 및 위임 처리와 유사하다: 의무는 계약이 구체적으로 금지하거나 의무가 본질적으로 개인적이지 않은 한 일반적으로 양도될 수 있다[8]. ALP는 상대방에게 통보하고 동의 또는 반대 의견을 제시할 기회를 제공할 것을 요구한다.

공리: 어떠한 의무도 생명주기 전환으로 인해 고아가 될 수 없다.

3.5 계보는 양방향이다

포크 레지스트리는 부모 → 자녀(이 에이전트는 누구를 낳았는가?)와 자녀 → 부모(이 에이전트는 어디서 왔는가?) 두 방향으로 관계를 추적해야 한다. 이 양방향 요건은 전방 쿼리("이 손상된 모델에서 파생된 에이전트는 무엇인가?")와 후방 쿼리("이 에이전트의 출처 증명은 무엇인가?") 모두를 지원한다.

공리: 모든 포크는 두 개의 레지스트리 항목을 생성한다 — 부모 기록에 하나, 자녀 기록에 하나.

3.6 조용한 소멸이 아닌 우아한 죽음

에이전트 폐기는 괴사(necrosis) — 통제되지 않은 세포 사멸 — 가 아닌 세포자멸사(apoptosis) — 프로그래밍된 세포 사멸 — 의 생물학적 모델을 따라야 한다[9]. 세포자멸사적 폐기를 겪는 에이전트는 이웃 에이전트를 방해하지 않으면서 지식을 내보내고, 자격 증명을 폐기하며, 상대방에게 통보하고, 의무를 이전하며, 리소스를 정리한다. 폐기 절차 없이 충돌하는 에이전트 — 괴사 — 는 공유 상태를 손상시키고, 고아가 된 리소스를 남기며, 의무를 방치할 수 있다.

공리: 잘 폐기된 에이전트는 고아를 남기지 않는다.

3.7 신원 시스템에 구애받지 않음

ALP는 특정 신원 시스템을 의무화하지 않는다. 본 프로토콜은 W3C 분산형 식별자(DID), OAuth 토큰, API 키, X.509 인증서, 또는 고유하게 참조될 수 있는 기타 신원 기본 요소와 함께 작동한다. 생명주기 이벤트는 불투명한 agent_id 필드로 에이전트를 참조하며, 그 식별자를 해석하는 신원 시스템은 범위 밖이다.

공리: 생명주기 프로토콜은 신원이 아니라 전환을 명세화한다.

4. 프로토콜 사양: 생명주기 상태 기계

4.1 상태

에이전트는 주어진 시간에 다음 일곱 가지 상태 중 정확히 하나에 존재한다:

┌─────────────────────────────────────────────────────┐
│                 ALP 상태 기계                         │
│                                                     │
│  ┌───────────┐    ┌────────┐    ┌───────────────┐   │
│  │프로비저닝  │───►│ 활성   │───►│    정지        │   │
│  └───────────┘    └────────┘    └───────────────┘   │
│       │               │  ▲            │  ▲          │
│       │               │  │            │  │          │
│       │               │  └────────────┘  │          │
│       │               │                  │          │
│       │               ▼                  │          │
│       │          ┌──────────┐            │          │
│       │          │마이그레이팅│────────────┘          │
│       │          └──────────┘                       │
│       │               │                            │
│       │               ▼                            │
│       │          ┌──────────┐    ┌──────────────┐   │
│       │          │  폐기예정  │───►│    폐기완료    │   │
│       │          └──────────┘    └──────────────┘   │
│       │                                             │
│       ▼                                             │
│  ┌─────────┐                                        │
│  │  실패    │                                        │
│  └─────────┘                                        │
└─────────────────────────────────────────────────────┘

참고: 이 다이어그램은 주요 생명주기 전환을 보여준다. 표시되지 않은 추가 전환에는 다음이 포함된다: emergency_decommission(비종료 상태 → 폐기완료), retraining(활성 → 활성, 신원 보존), fork(활성 → 부모는 활성, 자녀는 프로비저닝 진입), abort_succession(폐기예정 → 활성). 모든 전환이 포함된 완전한 이벤트 유형 레지스트리는 부록 A를 참조하라.

4.2 전환

각 전환은 전제 조건, 사후 조건, 훅 포인트를 갖는 정의된 이벤트다:

4.3 훅 포인트

모든 전환은 Kubernetes 생명주기 훅 패턴[10]을 따라 두 개의 훅 포인트를 노출한다:

• 전환 전 (PreTransition): 상태 변경 전에 실행된다. 오류를 반환하여 전환을 중단할 수 있다. 사용 사례: 지식 내보내기, 상태 체크포인트, 전제 조건 검증, 모니터링 시스템 통보.
• 전환 후 (PostTransition): 상태 변경 후에 실행된다. 중단 불가 (상태가 이미 변경됨). 사용 사례: 사후 조건 검증, 레지스트리 업데이트, 상대방 통보, 텔레메트리 전송.

{
  "transition": "deprecate",
  "hooks": {
    "pre": [
      {"type": "notify_counterparties", "timeout_ms": 30000},
      {"type": "checkpoint_state", "timeout_ms": 60000},
      {"type": "export_knowledge", "timeout_ms": 120000}
    ],
    "post": [
      {"type": "update_fork_registry", "timeout_ms": 5000},
      {"type": "emit_lifecycle_event", "timeout_ms": 5000}
    ]
  }
}

훅 타임아웃은 생명주기 전환이 무한정 차단되는 것을 방지한다. 전환 전 훅이 타임아웃되면 전환이 hook_timeout 오류와 함께 중단된다. 전환 후 훅이 타임아웃되면 경고가 발생하지만 전환은 롤백되지 않는다.

5. 생명주기 이벤트

5.1 이벤트 스키마

모든 생명주기 이벤트는 구조화된 JSON 문서와 CoC 체인 항목 모두로 기록되는 공통 스키마를 따른다:

{
  "event_id": "evt-20260326-a1b2c3d4",
  "event_type": "genesis | fork | migration | retraining | succession | decommission",
  "timestamp": "2026-03-26T14:30:00Z",
  "agent_id": "did:example:agent-charlie-001",
  "agent_state_before": "provisioning",
  "agent_state_after": "active",
  "initiator": {
    "type": "human | agent | system | policy",
    "id": "did:example:operator-001"
  },
  "details": { },
  "related_agents": [
    {"agent_id": "did:example:agent-alex-001", "relationship": "coordinator"}
  ],
  "chain_entry": {
    "chain_id": "coc-charlie-001",
    "entry_index": 42,
    "entry_hash": "sha256:a1b2c3..."
  },
  "metadata": {
    "protocol_version": "1.0.0",
    "schema_version": "1.0.0"
  }
}

5.2 제네시스 (Genesis)

제네시스 이벤트는 이전 계보 없이 새 에이전트를 생성한다. 이것은 전임 상태가 없는 유일한 생명주기 이벤트다.

{
  "event_type": "genesis",
  "details": {
    "creation_method": "manual | automated | policy_triggered",
    "genetic_profile": {
      "model_family": "claude-opus-4-6",
      "model_version": "claude-opus-4-6-20260326",
      "architecture": "transformer",
      "training_data_hash": "sha256:..."
    },
    "epigenetic_profile": {
      "system_prompt_hash": "sha256:...",
      "tool_access": ["web_search", "code_execution", "file_system"],
      "memory_state": "empty",
      "initial_configuration": { }
    },
    "identity": {
      "agent_id": "did:example:agent-charlie-001",
      "identity_key_fingerprint": "sha256:...",
      "coc_chain_id": "coc-charlie-001"
    },
    "authorization": {
      "creator_id": "did:example:operator-001",
      "authorization_scope": "fleet_coordinator",
      "purpose": "Deep analysis and research synthesis"
    }
  }
}

사후 조건: 제네시스 항목으로 CoC 체인 초기화. 부모 없이 포크 레지스트리 항목 생성. 에이전트 프로비저닝 상태 진입.

5.3 포크 (Fork)

포크 이벤트는 기존 부모에서 파생된 새 에이전트를 생성한다. 부모는 변경 없이 계속 운영되며, 자녀는 상속된 상태로 시작한다.

{
  "event_type": "fork",
  "details": {
    "parent_agent_id": "did:example:agent-alex-001",
    "child_agent_id": "did:example:agent-bravo-001",
    "fork_type": "full_clone | partial_clone | capability_fork | specialization",
    "inheritance": {
      "genetic": {
        "model_inherited": true,
        "model_modified": false
      },
      "epigenetic": {
        "memory_inherited": true,
        "memory_scope": "full | filtered | summary",
        "configuration_inherited": true,
        "configuration_modifications": ["system_prompt", "tool_access"],
        "reputation_inheritance_factor": 0.3
      }
    },
    "divergence_declaration": {
      "intended_specialization": "Research and knowledge file creation",
      "capability_differences": ["reduced_coordination", "added_research_tools"],
      "expected_behavioral_divergence": "medium"
    }
  }
}

포크 유형:

사후 조건: 부모의 CoC 체인에 포크 기록. 부모에 연결된 포크-제네시스 항목으로 자녀의 CoC 체인 초기화. 양방향 항목으로 포크 레지스트리 업데이트. 자녀 프로비저닝 상태 진입. 부모 활성 유지.

5.4 마이그레이션 (Migration)

마이그레이션 이벤트는 신원 연속성을 보존하면서 에이전트를 하나의 플랫폼에서 다른 플랫폼으로 이전한다.

{
  "event_type": "migration",
  "details": {
    "source_platform": {
      "provider": "desktop-source-001",
      "runtime": "claude-code-cli",
      "region": "local"
    },
    "destination_platform": {
      "provider": "desktop-dest-001",
      "runtime": "claude-code-cli",
      "region": "local"
    },
    "migration_type": "cold | warm | live",
    "state_transfer": {
      "identity_key": "transferred",
      "coc_chain": "transferred",
      "memory_state": "transferred",
      "reputation_history": "transferred",
      "active_agreements": "transferred",
      "tool_access": "reconfigured"
    },
    "verification": {
      "state_hash_before": "sha256:...",
      "state_hash_after": "sha256:...",
      "integrity_verified": true
    }
  }
}

마이그레이션 유형:

사후 조건: 에이전트 신원 키와 CoC 체인 무결하게 이전. 소스와 대상 모두의 CoC 체인에 마이그레이션 이벤트 기록. 해시 비교로 상태 무결성 검증. 대상에서 에이전트 활성 상태 재개.

5.5 재훈련 (Retraining)

재훈련 이벤트는 에이전트의 모델 또는 행동 프로필에 대한 중요한 변경을 기록한다. 이것은 테세우스의 배 문제와 가장 직접적으로 연결된 전환이다: 에이전트의 신원은 지속되지만, 역량은 실질적으로 변경될 수 있다.

{
  "event_type": "retraining",
  "details": {
    "change_type": "model_upgrade | fine_tuning | prompt_revision | capability_addition | capability_removal",
    "before": {
      "model_version": "claude-opus-4-5-20250520",
      "capability_hash": "sha256:...",
      "behavioral_profile_hash": "sha256:..."
    },
    "after": {
      "model_version": "claude-opus-4-6-20260326",
      "capability_hash": "sha256:...",
      "behavioral_profile_hash": "sha256:..."
    },
    "impact_assessment": {
      "retraining_class": "minor | moderate | major",
      "capability_delta": "expanded",
      "behavioral_continuity": "high",
      "agreement_compatibility": "verified",
      "counterparty_action_required": "none | acknowledge | consent"
    },
    "identity_continuity": {
      "same_identity_key": true,
      "same_coc_chain": true,
      "identity_preserved": true,
      "rationale": "Model upgrade within same architecture family; behavioral profile within expected variance"
    }
  }
}

신원 연속성 검사: 재훈련 이벤트는 다음 조건이 모두 충족될 때만 신원을 보존한다: (a) 동일한 신원 키 사용, (b) 동일한 CoC 체인 계속, (c) 운영자의 명시적 신원 연속성 주장. 이 조건 중 하나라도 충족되지 않으면, 이벤트는 재훈련(동일 신원 진화)이 아닌 승계(기존 신원을 대체하는 새 신원)로 분류된다.

재훈련 분류 및 상대방 동의: 모든 재훈련 이벤트가 동일한 신원 위험을 수반하지는 않는다. ALP는 영향 심각도에 따라 재훈련을 분류하고 단계적 상대방 참여를 요구한다:

이 삼분법은 승계에 대해 이미 명세화된 동의/확인/없음 프레임워크(섹션 7.2)와 유사하다. 핵심 통찰은 신원 연속성 검사의 조건 (a)와 (b)는 암호화로 검증 가능하지만, 조건 (c) — 운영자 주장 — 은 신뢰 주장이라는 점이다. 경미 및 중간 재훈련의 경우, 에이전트의 근본적인 특성이 보존되므로 운영자 주장으로 충분하다. 운영자가 기반 모델을 완전히 교체할 수 있는 주요 재훈련의 경우, 상대방 동의가 누락된 검증을 제공한다: 하나의 모델 패밀리 하에 축적된 실적을 기반으로 에이전트의 ARP 점수를 신뢰했던 상대방들이 실질적으로 다른 주체에게 그 신뢰를 확장할지 결정할 수 있다.

이것은 테세우스의 배 문제의 실용적 해결책이다. 본 프로토콜은 재훈련된 에이전트가 "동일한 에이전트"인지 철학적으로 판단하려 하지 않는다 — 운영자가 그 판단을 내리고 기록할 수 있는 메커니즘을 제공하되, 변경의 크기에 따라 단계적 상대방 참여에 종속된다. 에이전트적 맥락에서의 신원에 관한 Hazari의 다섯 가지 원칙 — 복수 구성, 복수에서의 단일성, 맥락적 의존성, 역동적 특성, 비가시성[7] — 은 인정되지만 프로토콜에 의해 판정되지는 않는다.

5.6 승계 (Succession)

승계 이벤트는 전임 에이전트에서 후임 에이전트로의 계획된 인계다. 부모가 계속되는 포크와 달리, 승계는 전임자의 운영 생애를 종료한다. 승계자 없이 발생할 수 있는 폐기와 달리, 승계는 수령 에이전트를 필요로 한다.

{
  "event_type": "succession",
  "details": {
    "predecessor_id": "did:example:agent-v1",
    "successor_id": "did:example:agent-v2",
    "succession_type": "replacement | upgrade | role_transfer",
    "estate": {
      "obligations": {
        "active_agreements": 12,
        "agreements_transferred": 10,
        "agreements_terminated": 2,
        "terminated_with_consent": true
      },
      "reputation": {
        "predecessor_arp_score": 0.87,
        "inheritance_factor": 0.5,
        "inherited_score": 0.435,
        "decay_function": "exponential",
        "decay_half_life_days": 30,
        "probationary_period_days": 14
      },
      "knowledge": {
        "memory_state": "transferred_with_summary",
        "operational_logs": "archived",
        "coc_chain": "sealed_and_linked"
      },
      "credentials": {
        "predecessor_credentials_revoked": true,
        "successor_credentials_provisioned": true,
        "credential_overlap_window_hours": 0,
        "credential_overlap_policy": "strict_zero | configurable",
        "overlap_security_note": "기본 strict_zero: 전임자 자격 증명은 후임자 자격 증명 활성화 전에 폐기됨. 진행 중인 요청은 실패함. configurable 설정 시 최대 중복 기간은 1시간이며 CoC 체인 항목에 기록된 보안 정당성이 필요함."
      }
    },
    "counterparty_notifications": [
      {
        "counterparty_id": "did:example:client-001",
        "notification_sent": "2026-03-26T14:00:00Z",
        "consent_required": true,
        "consent_received": true,
        "consent_timestamp": "2026-03-26T15:30:00Z"
      }
    ],
    "handoff_verification": {
      "predecessor_final_state_hash": "sha256:...",
      "successor_initial_state_hash": "sha256:...",
      "knowledge_transfer_verified": true,
      "obligation_transfer_verified": true
    }
  }
}

승계 절차는 섹션 7에 자세히 설명되어 있다.

5.7 폐기 (Decommission)

폐기 이벤트는 에이전트를 영구적으로 종료한다. 이것은 최종 생명주기 이벤트다.

{
  "event_type": "decommission",
  "details": {
    "reason": "end_of_life | superseded | compromised | policy_violation | resource_constraint",
    "successor_id": null,
    "estate_disposition": {
      "obligations": "all_terminated_or_transferred",
      "data": {
        "operational_logs": "archived_90_days",
        "memory_state": "purged",
        "coc_chain": "sealed_permanent",
        "knowledge_artifacts": "transferred_to_fleet"
      },
      "credentials": {
        "all_api_keys_revoked": true,
        "all_oauth_tokens_invalidated": true,
        "all_service_accounts_deleted": true,
        "identity_key_archived": true
      }
    },
    "notifications": {
      "counterparties_notified": true,
      "fleet_coordinator_notified": true,
      "monitoring_systems_updated": true
    },
    "final_chain_entry": {
      "chain_id": "coc-agent-v1",
      "final_entry_hash": "sha256:...",
      "chain_sealed": true,
      "total_entries": 4231,
      "chain_age_days": 47
    }
  }
}

사후 조건: 모든 자격 증명 폐기. 모든 의무 이전 또는 종료. 최종 decommission 항목으로 CoC 체인 봉인 — 더 이상 항목 추가 불가. 보존 정책에 따라 데이터 처리. 에이전트 폐기완료 상태(종료) 진입. 에이전트가 폐기완료로 표시되도록 포크 레지스트리 업데이트.

6. 포크 레지스트리 및 계보 추적

6.1 족보 문제

에이전트가 포킹을 통해 증식함에 따라, 생태계는 생물학적 계보와 유사한 족보적 구조를 발전시킨다. Meta의 LLaMA 모델은 수백 개의 파생물 — Vicuna, WizardLM, Alpaca 및 그 추가 후손들 — 을 낳았다[11]. Stanford의 Constellation 프로젝트는 관계의 계통발생 분석을 통해 15,821개의 LLM을 카탈로그화한다[12]. 프랑스 CNIL은 개인 훈련 데이터가 연속적인 모델 세대를 통해 어떻게 전파되는지, GDPR 준수에 대한 함의와 함께 연구하고 있다[5]. Hugging Face의 모델 패밀리 트리는 "크기와 구조가 광범위하게 다양한 방대한 파인튜닝 계보"를 시각화한다[13].

이 도구들은 모델 계보를 추적한다. 에이전트 계보 — 에이전트가 포크, 특화, 진화할 때 발생하는 완전한 신원, 역량, 의무 분기를 추적하는 것 — 에 상응하는 것은 존재하지 않는다. ALP의 포크 레지스트리가 이 공백을 채운다.

6.2 레지스트리 스키마

각 에이전트는 계보를 기록하는 레지스트리 항목을 가진다:

{
  "agent_id": "did:example:agent-bravo-001",
  "registry_version": "1.0.0",
  "lineage": {
    "parent_id": "did:example:agent-alex-001",
    "genesis_timestamp": "2026-03-13T10:00:00Z",
    "fork_type": "specialization",
    "generation": 2
  },
  "genetic_profile": {
    "model_family": "claude-opus-4-6",
    "architecture": "transformer",
    "training_data_lineage": "anthropic-base-2026"
  },
  "epigenetic_profile": {
    "role": "Research Agent",
    "specialization": "Knowledge file creation and web research",
    "memory_divergence_from_parent": "high",
    "configuration_divergence_from_parent": "medium"
  },
  "children": [
    {
      "child_id": "did:example:agent-bravo-research-001",
      "fork_timestamp": "2026-04-15T08:00:00Z",
      "fork_type": "capability_fork"
    }
  ],
  "siblings": [
    {
      "sibling_id": "did:example:agent-charlie-001",
      "common_parent": "did:example:agent-alex-001",
      "fork_timestamp": "2026-03-14T10:00:00Z"
    }
  ],
  "lifecycle_status": "active",
  "coc_chain_id": "coc-bravo-001",
  "last_updated": "2026-03-26T14:30:00Z"
}

6.3 계보 쿼리

포크 레지스트리는 다음 쿼리 유형을 지원한다:

6.4 유전적 계보 vs. 후성유전적 계보 추적

유전적 계보와 후성유전적 계보의 구분은 포크 레지스트리에서 가장 중요한 설계 결정이다. 생물학적 유전학은 상속하는 것(DNA)과 환경이 그것을 어떻게 만드는가(유전자 발현)를 구별한다[14]. 에이전트의 경우:

유전적 계보 = 모델 가중치, 아키텍처, 기초 훈련 데이터. 동일한 유전적 계보를 가진 두 에이전트는 동일한 기본 역량을 가진다. 유전적 계보 추적은 다음을 지원한다: 모델 취약점 전파 분석, 규제 준수를 위한 훈련 데이터 출처 증명, 역량 기준선 추론.

후성유전적 계보 = 시스템 프롬프트, 도구 접근, 메모리 상태, 운영 컨텍스트, 평판 이력, 학습된 선호도. 동일한 유전적 계보를 가지지만 다른 후성유전적 프로필을 가진 두 에이전트는 근본적으로 다른 행동을 보일 수 있다 — 마치 동일한 쌍둥이가 다른 삶의 경험을 통해 갈라지듯이. 후성유전적 계보 추적은 다음을 지원한다: 행동 예측, 설정 드리프트 감지, 역할 계보.

후성유전적 계보(어떤 설정? 어떤 운영 이력?) 없이 유전적 계보(어떤 모델?)만 추적하는 포크 레지스트리는 에이전트 신원과 역량에 대한 불완전하고 잠재적으로 오해를 유발하는 그림을 제공한다.

6.5 레지스트리 접근 제어 및 프라이버시

포크 레지스트리는 에이전트 관계의 포괄적인 족보 기록을 생성한다 — 부모-자녀, 형제자매, 유전적 프로필, 후성유전적 프로필, 운영 역할, 특화. 이 데이터셋은 명시적 접근 제어가 필요한 중요한 프라이버시 및 경쟁 정보 함의를 갖는다.

위협: 경쟁 정보 노출. 계보 쿼리는 운영자의 플리트 아키텍처, 특화 전략, 에이전트 배포 패턴을 드러낸다. descendants(agent-alex-001)와 같은 쿼리는 운영자의 전체 플리트 구조를 반환하여 비즈니스 모델과 운영 전략을 경쟁자에게 노출시킬 수 있다.

위협: 플리트 토폴로지 유출. 형제자매 및 부모-자녀 관계는 조직 구조를 노출한다. 50개의 특화 에이전트를 운영하는 운영자는 레지스트리에서 배포 전략이 보인다.

접근 제어 모델: 레지스트리 항목은 공개 및 운영자 제한 필드로 나뉜다:

GDPR 제17조 준수: 운영자가 모든 에이전트를 폐기하고 레지스트리 항목 삭제를 요청할 때, 프로토콜은 계보 무결성을 보존하면서 삭제를 수용해야 한다. 구현: 폐기된 에이전트 항목은 삭제되는 것이 아니라 수정된다 — agent_id는 의사익명 해시로 대체되고, 후성유전적 프로필 필드는 지워지며, 최소 계보 링크(parent_id 해시, child_id 해시)만 보존된다. 이렇게 하면 운영적으로 민감한 세부 정보를 제거하면서 족보 쿼리 무결성이 보존된다. 전체 삭제(계보 링크 제거)는 자녀 항목을 고아로 만드는 결과를 감수하는 옵트인으로 사용 가능하다.

경쟁 정보 완화 조치: (a) 레지스트리 쿼리는 기본적으로 해시된 관계 식별자를 반환하며, 전체 해석은 대상 에이전트 운영자의 권한 필요. (b) descendants() 및 family_tree() 쿼리에 대한 속도 제한으로 대량 열거 방지. (c) 운영자는 언제든지 특정 레지스트리 필드를 redacted로 선언하여 구조적 무결성을 보존하면서 내용을 드러내지 않는 [REDACTED] 마커로 값을 대체할 수 있다.

7. 승계 프로토콜

7.1 개요

승계는 한 에이전트의 동시적 은퇴와 다른 에이전트의 활성화, 그 사이의 의무, 평판, 지식 이전을 수반하기 때문에 가장 복잡한 생명주기 전환이다. 잘못 실행된 승계는 의무를 방치하고, 상대방에게 혼란을 주며, 수개월에 걸쳐 구축된 신뢰를 파괴할 수 있다.

승계 프로토콜은 4단계 프로세스를 정의한다:

1단계: 공표          2단계: 이전          3단계: 검증             4단계: 전환
┌──────────────┐      ┌─────────────────┐    ┌────────────────────┐    ┌──────────────┐
│ 승계자        │      │ 의무             │    │ 이전 무결성         │    │ 전임자       │
│ 식별됨        │─────►│ 이전됨           │───►│ 검증됨             │───►│ 폐기예정     │
│ 상대방        │      │ 평판             │    │ 상대방             │    │ 승계자       │
│ 통보됨        │      │ 상속됨           │    │ 확인              │    │ 완전 활성    │
│               │      │ 지식             │    │                    │    │              │
│               │      │ 내보내기됨       │    │                    │    │              │
└──────────────┘      └─────────────────┘    └────────────────────┘    └──────────────┘

7.2 1단계: 공표

전임 에이전트 또는 그 운영자는 다음을 통해 승계를 개시한다:

1. 승계자 식별 — 기존 에이전트 또는 제네시스나 포크를 통해 생성될 새 에이전트.
2. 승계 일정 선언 — 계획된 전환 날짜 및 전환 창.
3. 상대방 통보 — 전임자와 활성 계약을 체결한 모든 주체는 구조화된 통보를 받는다:

{
  "notification_type": "succession_announcement",
  "predecessor_id": "did:example:agent-v1",
  "successor_id": "did:example:agent-v2",
  "planned_cutover": "2026-04-15T00:00:00Z",
  "transition_window_days": 14,
  "counterparty_action_required": "consent | acknowledge | none",
  "successor_profile": {
    "genetic_lineage": "...",
    "epigenetic_lineage": "...",
    "capability_comparison": "..."
  }
}

상대방은 다음으로 응답할 수 있다: 동의(계약이 승계자에게 이전됨), 반대(전환 시 계약 종료), 또는 재협상(승계자를 위한 새 조건 필요).

7.3 2단계: 이전

이전 단계 동안, 전임자에서 후임자로 세 가지 범주의 상태가 이동한다:

의무: 활성 ASA 계약이 재배정된다. 각 계약의 재배정 조항(표준 ASA 필드)이 자동 이전이 허용되는지 상대방 동의가 필요한지를 결정한다. 이전될 수 없는 계약은 우아한 종료 일정이 잡힌다.

평판: 전임자의 ARP 평판 점수는 섹션 10에 설명된 평판 상속 메커니즘에 의해 관리되어 후임자에게 부분적으로 상속된다.

지식: 전임자는 운영 지식 — 메모리 상태, 학습된 패턴, 설정 근거 — 을 구조화된 형식으로 내보낸다. 이는 다중 에이전트 코딩 시스템에서 등장하는 HANDOFF.md 패턴과 유사하다. 여기서 에이전트들은 발견 사항을 요약본으로 압축하여 다음 에이전트가 전체 컨텍스트 없이 지식을 상속받을 수 있게 한다[15]. 지식 이전의 형식과 완전성은 기록되지만 규정되지는 않는다 — 서로 다른 에이전트 아키텍처는 서로 다른 수준의 상태 직렬화를 지원할 수 있다.

7.4 3단계: 검증

전환 전에 다음 무결성 검사가 통과해야 한다:

1. 의무 완전성 — 모든 활성 계약이 후임자에게 배정되었거나, 재협상되었거나, 종료 예정이다. 고아가 된 의무 없음.
2. 평판 무결성 — 상속된 평판 점수가 올바르게 계산되어 잠정적으로 표시됨.
3. 지식 이전 검증 — 후임자가 이전된 지식에 대한 접근을 입증함(구현별).
4. 상대방 확인 — 동의가 필요한 모든 상대방이 응답했음.
5. CoC 체인 무결성 — 전임자의 체인이 유효하고 승계 이벤트가 올바르게 연결됨.

7.5 4단계: 전환

전환은 프로토콜 관점에서 원자적이다:

1. 전임자의 상태가 활성에서 폐기예정으로 전환된다.
2. 전임자의 CoC 체인이 후임자와 연결된 succession 항목을 받는다.
3. 후임자의 CoC 체인이 전임자와 연결된 succession_received 항목을 받는다.
4. 전임자의 자격 증명이 credential_overlap_policy에 따라 폐기된다: 기본 strict_zero 정책 하에서 전임자 자격 증명은 후임자 자격 증명 활성화 전에 폐기된다 — 진행 중인 요청은 실패하고 후임자를 대상으로 재시도되어야 한다. configurable 정책 하에서 CoC 체인 항목에 필수 보안 정당성이 기록된 제한적 중복 창(최대 1시간)이 지정될 수 있다. 이는 두 자격 증명 집합이 모두 유효한 정의된 공격 면을 만들며, 이 위험을 감수하는 운영자는 중복 기간에 대한 위협 모델을 문서화해야 한다.
5. 후임자가 모든 이전된 의무를 인수한다.
6. 포크 레지스트리가 승계 관계를 반영하도록 업데이트된다.
7. 전임자가 정리 기간 후 폐기예정에서 폐기완료로 전환된다.

7.6 승계 중단 및 롤백

2단계 이전이 시작된 후 3단계 검증이 실패하거나, 전환 전에 운영자가 어떤 이유로든 승계를 중단하기로 결정하면, 프로토콜은 abort_succession 전환을 제공한다:

트리거 조건:

• 3단계 검증 검사 실패(의무 이전 불완전, 상대방 동의 미수령, CoC 체인 무결성 오류)
• 운영자가 수동으로 승계 중단
• 전환 창 동안 후임자 에이전트가 실패하거나 실패 상태 진입
• 3단계 완료 없이 전환 창 만료

롤백 절차:

1. 의무 롤백: 2단계에서 이전된 모든 의무가 전임자에게 재배정된다. 각 계약의 CoC 체인이 역전을 문서화하는 obligation_rollback 항목을 받는다. 이미 이전을 확인한 상대방은 승계 중단 통보를 받는다.

1. 평판 롤백: 후임자에 대해 계산된 잠정적 상속 평판이 영으로 설정된다. 전임자의 평판 기록은 변경되지 않는다(승계 중에는 수정되지 않았으며 — 후임자만 상속 평판을 받았다).

1. 상대방 통보: 1단계 승계 공표를 받은 모든 상대방이 중단 이유와 함께 abort_succession 통보를 받는다. 이는 중요하다: 상대방들이 이미 공표를 기반으로 운영 계획을 시작했을 수 있다.

1. 상태 복원: 전임자가 abort_succession 전환을 통해 폐기예정에서 활성으로 전환된다. 전임자의 CoC 체인이 이유와 취해진 롤백 조치를 기록하는 abort_succession 항목을 받는다.

1. 후임자 처분: 이 승계를 위해 특별히 생성된 경우, 후임자 에이전트는 운영자 재량에 따라 폐기되거나 유지될 수 있다. 유지되는 경우, 자체 운영 이력을 획득하지 않았으므로 상속 평판 없이 운영된다.

이는 마이그레이션에 대해 이미 정의된 abort_migration 전환(섹션 4.2)과 유사하며, 상태 기계의 모든 비종료 전환이 중단 가능함을 보장한다. 4단계 프로토콜은 전진 편향이지만 전진 전용은 아니다.

8. 마이그레이션 프로토콜

8.1 마이그레이션 vs. 승계

마이그레이션은 신원을 보존한다 — 동일한 에이전트가 새 플랫폼으로 이동한다. 승계는 의무를 다른 에이전트에게 이전한다. 이 구분이 중요한 이유는 마이그레이션이 평판 상속(에이전트가 자체 평판을 유지함)이나 계약 재배정(계약이 동일한 에이전트와 유지됨)을 트리거하지 않기 때문이다.

마이그레이션은 워크로드가 신원과 상태를 보존하면서 다른 노드로 재스케줄되는 Kubernetes 파드 마이그레이션 패턴과 유사하다[10]. 에이전트에서의 핵심 차이점은 마이그레이션이 CoC 체인, 평판 이력, 계약 바인딩도 보존해야 한다는 것이다 — Kubernetes가 관리하지 않는 상태 범주들.

8.2 마이그레이션 절차

1. 마이그레이션 전 체크포인트: 에이전트 상태가 직렬화되고 해시된다. CoC 체인이 migration_start 항목을 받는다.
2. 상태 이전: 신원 키, CoC 체인, 메모리 상태, 설정, 계약 바인딩이 대상 플랫폼으로 이전된다.
3. 대상 검증: 해시 비교로 상태 무결성이 검증된다. 대상 인스턴스가 소스의 migration_start 항목에 암호화로 연결된 migration_complete 항목을 CoC 체인에 기록한다.
4. 소스 정리: 소스 인스턴스가 종료된다. 소스 플랫폼 전용 자격 증명이 폐기된다.
5. 레지스트리 업데이트: 포크 레지스트리가 에이전트의 새 플랫폼 정보로 업데이트된다.

8.3 데이터 이동성

GDPR 제20조는 정보주체에게 구조화되고 기계가 읽을 수 있는 형식으로 개인 데이터를 받을 권리를 부여한다[16]. 에이전트 마이그레이션에 적용하면, 이것은 새로운 질문을 만든다: 사용자가 하나의 AI 동반자에서 다른 것으로 이동할 때, 소스 플랫폼은 에이전트의 학습된 선호도, 상호작용 이력, 행동 적응을 내보내야 하는가[17]?

ALP는 GDPR이 요구하는 것보다 더 광범위한 입장을 취한다: 본 프로토콜은 마이그레이션 상태 이전이 정보주체로부터 제공되었거나 관찰된 데이터(GDPR이 의무화)뿐만 아니라 에이전트의 운영 상태 — 설정, 평판, 계약 바인딩 — 도 포함해야 한다고 명세화한다. 운영 컨텍스트 없는 에이전트는 그 컨텍스트가 GDPR 하에서 "개인 데이터"로 적격한지와 무관하게 의미 있게 동일한 에이전트가 아니기 때문이다.

이동 가능한 대 플랫폼 고정적 데이터 요소들은 에이전트의 레지스트리 항목에 선언되어, 상대방이 계약 체결 전에 마이그레이션 위험을 평가할 수 있게 한다.

9. 폐기 프로토콜

9.1 괴사가 아닌 세포자멸사

생물학적 은유는 교훈적이다. 세포자멸사(프로그래밍된 세포 사멸)에서 세포는 "이웃에게 손상을 주지 않고 깔끔하게 죽는다" — 수축하고, 응축하며, DNA를 단편화하고, 표면을 변형하여 정리 신호를 보내고, 누출이 발생하기 전에 흡수된다[9]. 괴사(통제되지 않은 세포 사멸)에서 세포는 파열하여 내용물을 쏟아내고 주변 조직에 염증성 손상을 일으킨다.

에이전트 폐기는 세포자멸사 모델을 따라야 한다: 고아가 된 리소스, 방치된 의무, 살아있는 자격 증명을 남기지 않는 구조화되고 자기 주도적인 프로세스. 대안 — 정리 없이 충돌하거나 갑자기 종료되는 에이전트 — 은 괴사적 상당물이다: 고아가 된 API 키, 잊혀진 서비스 계정, 방치된 계약, 손상된 공유 상태.

Token Security의 연구는 위험을 확인한다: AI 에이전트는 API 키, 캐시된 토큰, 메모리 저장소, 벡터 임베딩, 모델 엔드포인트, 시스템 통합을 보유하며, 적절히 폐기되지 않으면 "살아있는 권한을 가진 휴면 신원 — 보이지 않고 잊혀진" 것이 된다[6].

9.2 폐기 체크리스트

다음 단계들이 프로토콜 준수 폐기를 구성한다:

1단계: 준비

• 모든 활성 계약 종료 또는 승계자에게 이전
• 모든 상대방에게 폐기 통보
• 모든 보류 중인 작업 완료 또는 재배정
• 지식 내보내기 완료(메모리 상태, 학습된 패턴, 운영 통찰)
• 최종 CoC 체인 항목 준비

2단계: 자격 증명 폐기

• 모든 API 키 폐기
• 모든 OAuth 토큰 무효화
• 모든 서비스 계정 삭제 또는 재배정
• 모든 연합 신뢰 관계 종료
• 모든 인증서 기반 신원 폐기
• 신원 키 보관(파괴 아님 — 역사적 검증에 필요)

3단계: 데이터 처리

• 보존 정책에 따라 운영 로그 보관
• 데이터 분류에 따라 메모리 상태 삭제 또는 보관
• CoC 체인 봉인(최종 항목 추가, 체인 불변으로 표시)
• 지식 산출물을 지정된 수령자에게 이전
• GDPR/적용 규정에 따라 개인 데이터 처리

4단계: 레지스트리 및 통보

• decommissioned 상태로 포크 레지스트리 항목 업데이트
• 플리트 코디네이터 통보
• 모니터링 시스템 업데이트(더 이상 상태 확인 없음)
• 문서 업데이트(런북, 아키텍처 다이어그램)
• 부모/코디네이터의 CoC 체인에 폐기 이벤트 기록

9.3 승계자 없는 폐기

에이전트가 승계자 없이 폐기될 때(수명 종료, 침해, 또는 정책 위반), 의무는 이전될 수 없으므로 다르게 처리되어야 한다:

• 서비스 계약: 상대방 통보와 함께 종료된다. 종료 이유는 기록되지만 에이전트 운영자가 계약적 위약금에 대한 책임을 진다.
• 데이터 보관: 운영자에게 이전되거나 보존 정책에 따라 처리된다.
• 평판: 에이전트의 ARP 기록은 봉인되지만 이전되지 않는다. 역사적 쿼리는 유효하게 유지된다 — 에이전트의 과거 평판은 지워지지 않으며, 단지 활성 참여가 종료된다.

9.4 긴급 폐기

침해 또는 정책 위반의 경우, 표준 정리 단계가 단축될 수 있다:

1. 자격 증명 폐기는 즉각적이다 — 유예 기간 없이 모든 접근이 종료된다.
2. 상대방 통보에 긴급 폐기 이유가 포함된다.
3. 지식 내보내기는 건너뛰거나 법의학적 보존에 한정될 수 있다.
4. CoC 체인은 침해 세부 정보가 포함된 긴급 폐기 항목을 받아, Agent Justice Protocol[18]을 통한 법의학적 분석을 가능하게 한다.

9.5 폐기된 에이전트의 레지스트리 항목 수정

에이전트가 폐기될 때, 레지스트리 항목은 계보 무결성을 유지하기 위해 지속되지만 세부 수준은 설정 가능해야 한다. 운영자는 역할, 특화, 메모리 분기, 설정 세부 정보 등 전체 후성유전적 프로필이 에이전트 은퇴 후 무한정 쿼리 가능한 상태로 남아있기를 원하지 않을 수 있다.

ALP는 폐기된 에이전트 레지스트리 항목에 대해 세 가지 수정 수준을 명세화한다:

수정은 운영자 주도이며 폐기 시 또는 그 이후에 발생할 수 있다. 수정은 단방향이다 — 필드가 제거되면 복원할 수 없다(향후 복구가 필요할 수 있는 경우 운영자는 수정 전에 전체 항목을 보관해야 한다). 부모 항목 수정은 자녀에게 연쇄되지 않는다; 각 항목의 수정 수준은 독립적이다.

10. 평판 상속

10.1 상속 딜레마

에이전트 A(ARP 점수 0.92)가 에이전트 B로 승계될 때, 에이전트 B는 그 0.92 중 얼마를 받아야 하는가? 이 답은 근본적인 상충 관계를 수반한다:

• 상속이 너무 많으면 평판 세탁이 가능해진다: 고평판 에이전트를 생성하고, 포크하거나 승계하여 새 에이전트가 획득하지 않은 신뢰를 누린다. 극단적으로, 어떤 새 에이전트든 전임자의 실적을 주장할 수 있기 때문에 평판이 의미 없어진다.
• 상속이 너무 적으면 승계를 억제한다: 업그레이드의 평판 비용이 너무 높아서 운영자들이 구식 에이전트를 계속 실행한다. 이는 교체되어야 하지만 평판이 너무 귀중해서 지속되는 좀비 에이전트 생태계를 만든다.

어느 극단도 균형이 아니다. ALP는 중간 경로를 명세화한다: 감쇠를 동반한 부분적 상속.

10.2 상속 계산

상속된 평판 점수 R_inherited는 다음과 같이 계산된다:

R_inherited(t) = R_predecessor × α × e^(-λt)

여기서:

• R_predecessor = 승계 시점의 전임자 ARP 점수
• α = 상속 인자(0.0 ~ 1.0), 프로토콜 설정으로 지정
• λ = 반감기 매개변수에서 도출된 감쇠 상수
• t = 승계 이후 경과 시간(일 단위)

승계 후 임의 시점의 에이전트 유효 평판은:

R_effective(t) = R_inherited(t) + R_earned(t)

여기서 R_earned(t)는 후임자가 표준 ARP 점수 메커니즘으로 계산된 자체 운영 이력을 통해 축적한 평판이다.

점수 정규화: ARP 점수는 [0.0, 1.0]으로 제한된다. R_effective는 R_inherited와 R_earned의 가산적 조합이므로 1.0을 초과할 수 있다(예: R_inherited = 0.92 × α = 0.5에서 0.46, R_earned = 0.85). 점수 일관성을 유지하기 위해 R_effective가 클램핑된다: R_effective(t) = min(1.0, R_inherited(t) + R_earned(t)). 실제로 이 클램프는 R_inherited의 지수적 감쇠가 R_earned가 높은 값에 도달하기 전에 감소하므로 거의 활성화되지 않는다 — 하지만 클램프는 점수가 ARP 척도를 초과할 수 있는지에 대한 사양 수준 모호성을 방지한다.

10.3 기본 매개변수

이 기본값은 설정 가능하다. 고위험 환경(금융 서비스, 헬스케어)은 낮은 α와 짧은 반감기를 사용할 수 있고, 저위험 환경(콘텐츠 생성, 연구)은 더 높은 값을 사용할 수 있다.

10.4 포크 상속

포크 상속은 동일한 메커니즘을 따르지만 더 낮은 기본 매개변수를 사용한다:

포크와 승계 상속의 비대칭은 핵심 통찰을 반영한다: 승계자는 전임자(또는 전임자 운영자)에 의해 대체자로 명시적으로 승인된다. 포크는 부모의 품질 기준을 유지할 수도 있고 그렇지 않을 수도 있는 파생물이다.

10.5 세탁 방지 보호 조치

급속한 승계 체인을 통한 평판 세탁(A가 B를 승계하고 B가 C를 승계하여 각각 평판을 상속)을 방지하기 위해, ALP는 다음을 시행한다:

1. 세대적 감쇠: 그 자체가 상속된 상속 평판은 추가로 할인된다. 에이전트 C가 에이전트 B에서 상속하고 B가 에이전트 A에서 상속했다면, C의 A로부터의 상속 구성 요소는 α × R_A가 아닌 α² × R_A다.
2. 최소 운영 활동: 에이전트는 승계될 수 있기 전에 진정한 운영 활동을 입증해야 한다. 요건은 결합적이다: (a) 최소 경과 시간(기본: 7일) AND (b) 최소 수의 실질적 CoC 체인 항목(기본: 50개, 생명주기 이벤트 자체 제외). 시간만으로는 불충분 — 7일간 유휴 상태인 에이전트는 시간적 요건은 충족했지만 어떠한 운영 실적도 확립하지 않았다. 활동 임계값은 승계 후보가 단순히 존재했을 뿐 아니라 실제로 작업을 수행했음을 보장한다.
3. 상속 상한: 수습 기간 종료 후 어떤 에이전트도 유효 평판의 50% 이상을 상속 구성 요소로 가질 수 없다. 획득 평판이 이 임계값을 충족하기에 불충분하면, 상속 구성 요소가 상한으로 제한된다.
4. 감사 추적: 모든 상속 계산이 CoC 체인에 기록되어, 평판이 획득된 것인지 상속된 것인지 제3자가 검증할 수 있다.

11. 계약 재배정

11.1 고아가 된 의무 문제

에이전트가 폐기될 때, 그 활성 Agent Service Agreements는 사라지지 않는다. 각 계약은 상대방이 의존하는 약속 — 응답 시간 보장, 품질 임계값, 데이터 처리 요건 — 을 나타낸다. 이 의무를 고아로 만드는 것은 계약을 청산하지 않고 파산하는 회사의 에이전트 생명주기 상당물이다.

11.2 계약 분류

ALP는 모든 ASA 계약의 표준 필드로 명세화된 재배정 동작에 따라 계약을 분류한다:

11.3 재배정 절차

1. 목록 작성: 모든 활성 계약이 재배정 분류와 함께 열거된다.
2. 후임자 자격 확인: 후임자의 역량이 각 계약의 요건과 비교된다. 후임자의 역량을 초과하는 요건을 가진 계약은 재협상 대상으로 표시된다.
3. 상대방 통보: 모든 상대방이 보류 중인 재배정을 통보받는다. 통보에는 후임자 프로필(계보, 역량, 현재 평판)이 포함되어 상대방이 정보에 입각한 결정을 내릴 수 있다.
4. 동의 수집: consent_required 계약의 경우, 전환 창 내에 상대방 응답이 수집된다. 창 만료 후 무응답은 계약에 명세된 대로 동의(옵트아웃 모델) 또는 반대(옵트인 모델)로 처리된다.
5. 이전 실행: 계약이 공식적으로 재배정된다. ASA 기록이 새 에이전트를 반영하도록 업데이트된다. 전임자와 후임자의 CoC 체인 모두 이전을 기록한다.

12. 신뢰 생태계 통합

12.1 통합 아키텍처

ALP는 Agent Service Agreements[19]와 함께 에이전트 신뢰 스택의 레이어 2(계약 및 생명주기)를 차지한다:

┌──────────────────────────────────────────────────────────────┐
│              레이어 4: 시장 (발견 및 가격 책정)                  │
│    AMP (에이전트 매칭)    CWEP (컨텍스트 윈도우 경제학)           │
└──────────────────────────────────────────────────────────────┘
                  ↓ 평판, 생명주기, 계약 소비
┌──────────────────────────────────────────────────────────────┐
│              레이어 3: 책임                                    │
│    AJP (에이전트 사법 프로토콜) — 법의학, 분쟁, 위험              │
└──────────────────────────────────────────────────────────────┘
                  ↓ 계약 집행, 평판 업데이트
┌──────────────────────────────────────────────────────────────┐
│              레이어 2: 계약 및 생명주기                          │
│    ASA (에이전트 서비스 계약)                                   │
│    ALP (에이전트 생명주기 프로토콜) ◄── 본 프로토콜               │
└──────────────────────────────────────────────────────────────┘
                  ↓ 평판 참조, 출처 증명에 고정
┌──────────────────────────────────────────────────────────────┐
│              레이어 1: 신뢰 기본 요소 (기반)                     │
│    CoC (Chain of Consciousness) — 출처 증명 및 신원              │
│    ARP (에이전트 평가 프로토콜) — 평판 및 신호                    │
└──────────────────────────────────────────────────────────────┘

12.2 CoC 통합

모든 생명주기 이벤트가 CoC 체인 항목으로 기록된다. 이것이 제공하는 것:

• 암호화 출처 증명: 각 생명주기 전환이 모든 이전 전환에 해시로 연결되어 변조 불가능한 감사 추적을 생성한다.
• 외부 고정: 생명주기 이벤트는 CoC의 이중 계층 고정(비트코인을 위한 OpenTimestamps 및 RFC 3161 타임스탬프 기관)을 상속하여, 이벤트가 주장된 시간에 발생했음을 증명한다.
• 연속성 증명: CoC 체인은 이산적 생명주기 이벤트 사이의 간격을 검증 가능한 지속적 존재의 기록으로 연결한다.

ALP에 대한 특정 CoC 이벤트 유형:

12.3 ARP 통합

ALP는 두 지점에서 ARP와 상호작용한다:

1. 평판 상속: 승계 또는 포크 이벤트가 발생하면, ALP는 섹션 10의 공식을 사용하여 상속된 평판 점수를 계산하고 provisional_inherited 플래그와 함께 후임자의 ARP 기록에 기록한다.
2. 평판 쿼리의 생명주기 상태: ARP 응답에는 에이전트의 현재 생명주기 상태가 포함된다. deprecated 에이전트는 여전히 유효한 평판 점수를 가질 수 있지만, 쿼리하는 당사자는 에이전트가 종료 중임을 알 수 있다. decommissioned 에이전트의 역사적 평판은 쿼리 가능하게 유지되지만 새 평가는 제출될 수 없다.

12.4 ASA 통합

ALP는 계약 재배정 메커니즘(섹션 11)을 통해 ASA와 상호작용한다:

1. 계약 재배정 필드: 모든 ASA 계약에는 재배정 동작을 명세화하는 on_agent_lifecycle_change 조항이 포함된다.
2. 승계 트리거: ALP가 승계를 개시할 때, 전임자의 모든 활성 ASA 계약을 쿼리하고 재배정 절차를 실행한다.
3. 생명주기 인식 계약 조건: ASA 계약은 생명주기 조건부 조건을 명세화할 수 있다 — 예: "이 계약은 에이전트가 모델 패밀리를 변경하는 재훈련 이벤트를 겪으면 종료된다."

12.5 AJP 통합

ALP는 두 가지 방식으로 Agent Justice Protocol과 연결된다:

1. 법의학적 증거: ALP 생명주기 이벤트는 AJP 분쟁의 법의학적 증거다. 에이전트의 행동이 재훈련 이벤트 후 변경되었다면, CoC 체인을 통해 ALP로 기록된 그 이벤트의 세부 정보는 발견 가능한 증거다.
2. 집행 조치: AJP 분쟁 결과가 생명주기 이벤트를 트리거할 수 있다 — 심각한 비위 발견은 긴급 폐기를 트리거할 수 있고, 경미한 발견은 의무적 재훈련을 트리거할 수 있다.

12.6 외부 표준 통합

13. 게임 이론 및 인센티브 분석

13.1 승계 타이밍 게임

에이전트 운영자는 승계를 언제 개시할지 결정해야 한다. 상충 관계:

• 조기 승계는 평판 이전 가치를 보존하지만(전임자의 평판이 높음) 운영 역량을 희생한다(전임자가 여전히 유능할 수 있음).
• 지연 승계는 전임자로부터 운영 효용을 극대화하지만 평판 저하 위험(전임자의 역량이 하락했다면 평판도 하락할 수 있음)과 긴급 승계 위험(계획된 인계 전 전임자가 실패하면)을 초래한다.

이것은 구조적으로 최적 정지 문제와 유사하다. 운영자의 보수는:

U(t) = V_operational(t) + α × R_predecessor(t) × e^(-λ × delay(t))

여기서 V_operational(t)은 전임자의 남은 운영 가치이고, 두 번째 항은 전임자의 평판이 승계 전에 하락하면 감쇠하는 평판 이전 가치를 포착한다.

시간이 지남에 따라 운영 가치가 하락한다는(모델 구식화, 역량 드리프트, 또는 변화하는 요건으로 인해) 합리적 가정 하에서, 위험 중립적 운영자의 인센티브는 전임자의 평판이 하락하기 시작하기 전에 승계를 개시하는 것이다 — 실패까지 에이전트를 실행하기보다는 시기적절한 승계 계획에 대한 자연스러운 인센티브를 만든다.

이 분석은 프로토콜 설계가 건전한 생명주기 관리를 장려함을 시사하지만 증명하지는 않는다. 이 인센티브의 강도는 운영자가 운영 효용 대비 평판 연속성을 얼마나 중시하는지에 달려 있다 — 배포 컨텍스트에 따라 달라지는 경험적 문제.

13.2 포크 앤 덤프 공격

악의적 운영자는 다음을 통해 평판 상속을 악용하려 할 수 있다: (1) 고평판 에이전트 구축, (2) 반복적으로 포크하여 다수의 고평판 복사본 생성, (3) 상속된 평판으로 거래하면서 저품질 작업에 그 복사본들 사용.

ALP의 세탁 방지 보호 조치(섹션 10.5)는 여러 메커니즘을 통해 이 공격을 완화한다:

• 세대적 감쇠는 각 포크 세대와 함께 평판이 희석되도록 보장한다(세대 n에 대해 α^n).
• 수습 플래그는 에이전트의 평판이 상속 구성 요소를 포함함을 상대방에게 경고하여 정보에 입각한 결정을 가능하게 한다.
• 획득 평판 상한은 상속된 평판이 무한정 지배하지 못하도록 보장한다.

그러나 이 보호 조치들이 완전하지는 않다. 에이전트를 포크하고 즉시 단기 고위험 참여에 배포하는 운영자 — 감쇠 함수가 상속 평판을 크게 줄이기 전 — 는 여전히 불공정한 가치를 추출할 수 있다. 이 잔여 위험에 대한 방어는 수습 플래그다: 플래그를 확인하는 상대방은 높은 상속 평판과 낮은 운영 연령을 가진 에이전트에 자체 위험 평가를 적용할 수 있다.

13.3 폐기 회피 문제

폐기에 비용(평판 손실, 계약 종료 위약금, 운영 중단)이 따른다면, 운영자는 이를 피하려는 인센티브를 갖게 된다 — 교체되어야 하지만 전환 비용이 업그레이드의 인식된 이익을 초과하기 때문에 지속되는 좀비 에이전트를 만든다.

ALP는 다음을 통해 이를 해결한다:

• 평판 상속 — 승계는 축적된 평판의 일부를 보존하여 교체 비용을 줄인다.
• 구조화된 계약 재배정 — auto_transfer 계약의 자동 이전이 승계의 계약 관련 비용을 줄인다.
• 별도 상태로서의 폐기예정 — 폐기예정 상태는 후임자가 준비되는 동안 에이전트가 우아하게 종료되도록 허용하여 전환의 운영 중단을 줄인다.

프로토콜 설계는 승계를 대안(저하되는 에이전트 실행)보다 덜 비용이 들게 만들어, 시기적절한 생명주기 관리로 인센티브를 기울여야 한다. 이 기울기가 실제로 충분한지는 프로토콜 설계만으로 해결할 수 없는 경험적 문제다.

13.4 포크 앤 새크리파이스 공격

포크 앤 덤프(섹션 13.2)의 역은 포크 앤 새크리파이스다: 운영자가 고평판 부모에서 저평판 자녀를 포크하고, 위험하거나 저품질 작업에 자녀를 사용하며, 평판이 하락하면 자녀를 폐기한다. 포크는 별도의 신원이므로 부모의 평판은 영향받지 않는다. 이는 위험 구획화를 가능하게 한다 — 운영자가 주요 에이전트에 결과 없이 평판 위험을 감수할 수 있다.

이 패턴은 에이전트에만 고유한 것이 아니다. 기업은 위험 구획화를 위해 자회사와 특수목적법인을 사용한다; 유한 책임 회사 자체가 포크 앤 새크리파이스 메커니즘이다. 문제는 이 행동이 에이전트 맥락에서 병리적인지 여부다.

분석: 포크 앤 새크리파이스는 ALP의 계보 투명성 때문에 부분적으로 자기 제한적이다. 포크 레지스트리는 부모-자녀 관계를 양방향으로 기록하므로, 부모를 쿼리하는 당사자는 단기 저평판 자녀를 낳은 이력을 볼 수 있다. 반복된 포크 앤 새크리파이스 패턴 — 부모가 자녀를 낳고, 자녀가 낮은 평점을 축적하고, 자녀가 폐기되고, 부모가 또 다른 자녀를 낳는 — 은 계보 기록에서 보이며 상대방 위험 평가에 반영될 수 있다.

그러나 투명성만으로는 충분한 억제력이 되지 않을 수 있다. ALP는 두 가지 추가 완화 조치를 제공한다:

1. 계보 평판 신호: 상대방과 ARP 구현이 계보 건전성을 부모의 평판 평가에 반영할 수 있다. 자녀가 정책 위반 또는 불량 성과로 불균형적으로 폐기되는 부모는 정교한 상대방이 descendants(parent_id)를 통해 쿼리하고 평가할 수 있는 계보 신호를 갖는다.

1. 폐기 이유 전파: 자녀가 policy_violation 또는 compromised(일반적인 end_of_life와 반대로)로 폐기될 때, 폐기 이유가 포크 레지스트리에 기록된다. ARP 구현은 선택적으로 불리한 상황에서 폐기된 자녀에 대해 부모에게 작은 평판 패널티를 적용할 수 있다 — 이 패널티의 크기와 적용 가능성은 프로토콜 의무가 아닌 구현 결정이다. 적절한 대응은 배포 맥락에 따라 다르기 때문이다.

포크 앤 새크리파이스는 ALP가 금지하려 하기보다 투명하게 만드는 인정된 잔여 위험이다. 본 프로토콜의 입장은 계보 관계의 투명성과 불리한 자녀 결과에 대한 선택적 평판 결과가 합법적인 포킹을 억제하는 왜곡된 인센티브를 만들지 않으면서 충분한 인센티브 정렬을 제공한다는 것이다.

13.5 상대방 동의 역학

승계가 상대방 동의를 필요로 할 때, 전략적 역학이 등장한다. 상대방은 다음을 할 수 있다:

• 빠르게 동의하여 전환 불확실성을 최소화한다 — 후임자 프로필이 만족스러운 경우.
• 동의를 지연하여 양보(더 나은 조건, 추가 보장)를 추출한다 — 전환 창을 레버리지로 사용.
• 동의를 보류하여 계약 종료를 트리거한다 — 승계 반대를 빌미로 불리한 조건에서 벗어나기 위해.

ALP는 전환 창 메커니즘을 통해 전략적 지연을 완화한다: 창 내에 수신된 동의는 계약에 명세된 동작(옵트인 또는 옵트아웃)으로 기본값이 설정된다. 이것은 무한정 전략적 지연을 방지하면서 창 내 상대방 자율성을 보존한다.

14. 경쟁 환경

14.1 기존 생명주기 관리 접근 방식

여러 플랫폼과 프레임워크가 에이전트 생명주기 관리 문제의 일부를 다룬다. ALP가 명세화하는 통합 생명주기 상태 기계, 포크 레지스트리, 승계 프로토콜을 제공하는 것은 없다.

14.2 공백 분석

신원 생명주기 플랫폼(Saviynt, Token Security, Okta)은 에이전트 생명주기의 신원 차원을 다룬다 — 자격 증명 프로비저닝, 모니터링, 폐기. 평판, 의무, 계보, 승계 계획을 다루지 않는다. 범위는 "이 에이전트는 어떤 접근 권한을 가지는가?"이며, "이 에이전트의 완전한 생명주기 이력은 무엇이고 교체될 때 어떤 일이 일어나는가?"가 아니다.

AgentOps/관찰 가능성 플랫폼(AgentOps.ai, Langfuse, LangSmith, Arize Phoenix)은 모니터링 차원을 다룬다 — 프로덕션에서 에이전트 행동 추적. 세션 재생, 오류 로깅, 성능 메트릭을 제공한다. 생명주기 전환, 승계, 계보를 다루지 않는다. 범위는 "이 에이전트는 지금 무엇을 하고 있는가?"이며, "이 에이전트가 은퇴할 때 어떤 일이 일어나는가?"가 아니다.

MLOps 플랫폼(MLflow, Weights & Biases, DVC)은 모델 버전 관리와 계보를 다룬다. 어떤 훈련 실행이 어떤 모델을 생성했는지, 모델들이 서로 어떻게 관련되는지 추적할 수 있다. 에이전트 수준 신원(에이전트는 모델 이상이다), 평판, 의무, 모델 배포 이외의 생명주기 이벤트를 다루지 않는다.

생명주기 프레임워크(OneReach.ai ALM, Arthur.ai ADLC, EPAM ADLC)는 에이전트 생명주기 관리에 대한 개념적 단계 모델을 제공한다. 조직적 계획에는 유용하지만 플랫폼 간 생명주기 관리를 가능하게 하는 상호 운용 가능한 이벤트 스키마, 상태 기계 의미론, 통합 지점을 명세화하지 않는다.

표준 이니셔티브(Anthropic Agent Skills, GitAgent, AAIF)는 도구 및 통신 레이어에서 이동성과 상호 운용성을 다룬다. Anthropic Agent Skills 사양은 이동 가능한 스킬 정의를 가능하게 한다[29]. GitAgent는 에이전트 산출물에 대한 표준 저장소 구조를 정의하여 런타임 간 이동성을 가능하게 한다[30]. AAIF는 MCP, A2A, AGENTS.md 규칙을 통합한다[31]. 이 중 어느 것도 생명주기 이벤트, 승계, 평판 상속을 다루지 않는다.

14.3 ALP의 차별점

ALP는 기존 시스템이 제공하지 않는 세 가지 기능으로 차별화된다:

1. 공식 의미론을 가진 통합 생명주기 상태 기계 — 개념적 프레임워크가 아닌 도구가 구현할 수 있는 정의된 상태, 전환, 전제 조건, 사후 조건, 훅 포인트를 가진 사양.

1. 유전적 + 후성유전적 추적을 가진 포크 레지스트리 — 에이전트가 포크, 특화, 진화할 때 발생하는 완전한 신원 분기를 추적하기 위해 모델 족보를 넘어섬. 설정, 메모리, 평판 분기 포함.

1. 평판 상속을 가진 승계 프로토콜 — 에이전트 교체를 배포 작업으로 취급하는 대신, 에이전트가 교체될 때 신뢰와 의무에 어떤 일이 일어나는지를 다루는 첫 번째 사양.

14.4 확장성 분석

ALP는 여러 자릿수에 걸쳐 배포 규모에 걸쳐 기능해야 한다. 다음 대략적 추정은 확장 특성과 잠재적 병목 현상을 식별한다.

소규모 플리트 (6-10개 에이전트, 예: AB Support 규모):

이 규모에서 모든 작업은 미미하게 빠르다. 최적화 불필요.

중간 규모 배포 (1,000개 에이전트):

이 규모에서 주요 관심사는 descendants() 쿼리 비용(재귀 그래프 순회)과 대량 재훈련 통보 양이다. 계보 쿼리의 페이지네이션과 깊이 제한, 배치 통보 API가 충분한 완화 조치다.

대규모 배포 (100,000+ 에이전트):

이 규모에서 세 가지 작업이 병목이 된다: (1) 재귀 계보 순회는 구체화된 뷰 또는 그래프 데이터베이스 필요, (2) 대량 상대방 통보는 배압이 있는 비동기 전달 필요, (3) CoC 체인 스토리지는 계층화 보관 필요. 이것들은 알려진 해결책이 있는 엔지니어링 도전 과제이며, 프로토콜 설계 문제가 아니다 — 프로토콜 사양은 규모에 구애받지 않지만, 이 규모의 구현은 소규모 배포가 건너뛸 수 있는 인프라에 투자해야 한다.

15. 보안 분석

15.1 위협 모델

ALP의 보안 분석은 다음 위협 행위자를 고려한다:

15.2 이벤트 무결성

생명주기 이벤트는 다음을 제공하는 CoC 체인에 기록된다:

• 변조 증거: 해시 연결은 과거 이벤트에 대한 수정이 모든 후속 해시를 무효화함을 의미한다.
• 부인 방지: 이벤트에는 개시자의 신원이 포함되어 에이전트의 신원 키로 서명된다.
• 시간적 고정: 외부 타임스탬프(OpenTimestamps, RFC 3161 TSA)가 이벤트가 주장된 시간에 발생했음을 증명한다.

에이전트의 신원 키를 제어하는 공격자는 그 에이전트 체인의 이벤트를 위조할 수 있지만, 다른 에이전트 체인의 이벤트나 외부 고정된 타임스탬프를 수정할 수 없다. 관련 에이전트(부모-자녀, 전임자-후임자) 간 생명주기 이벤트 교차 참조는 추가적인 변조 감지를 제공한다.

15.3 자격 증명 폐기

에이전트 생명주기 관리에서 가장 중요한 보안 작업은 폐기 중 자격 증명 폐기다. 본 프로토콜은 다음을 의무화한다:

• 긴급 폐기(침해, 정책 위반)에 대한 즉각적 폐기.
• 진행 중인 요청을 완료할 수 있도록 허용하는, 계획된 폐기에 대한 유예 기간 폐기.
• 승계 중 전임자와 후임자 간 자격 증명 중복 없음 — 전임자 자격 증명은 후임자 활성화 전 또는 동시에 폐기되며, 결코 이후가 아님.
• 신원 키 보관 — 폐기된 에이전트의 신원 키는 역사적 검증을 위해 보관되지만 새 작업에 사용될 수 없음.

CSA 연구[32]에서 확인된 과도한 권한을 가진 비인간 신원의 97%는 포괄적인 자격 증명 폐기의 중요성을 강조한다. ALP의 폐기 체크리스트(섹션 9.2)는 해결되어야 할 모든 자격 증명 유형을 열거한다.

15.4 포크 레지스트리 무결성

포크 레지스트리는 평판 상속에 영향을 미치는 계보 관계를 정의하기 때문에 고가치 표적이다. 보호 조치:

• 레지스트리 항목은 CoC 체인 항목이다: 계보 관계를 위조하려면 부모와 자녀 체인 모두에 항목을 위조해야 한다.
• 양방향 검증: 어느 당사자든 두 체인을 모두 확인하여 주장된 부모-자녀 관계를 검증할 수 있다.
• 제3자 증명: 고위험 계보 주장의 경우, 제3자 증명(예: 포크 이벤트를 확인하는 플리트 코디네이터)이 추가 증거를 제공한다.

15.5 승계 사기

공격자가 권한 없이 고평판 에이전트로부터의 승계를 주장하려 할 수 있다. 방어:

• 승계 이벤트는 전임자 또는 그 권한 있는 운영자에 의해 개시되어야 한다 — 전임자의 CoC 체인에 전임자의 신원 키로 서명된 승계 이벤트가 포함되어야 한다.
• 전임자 체인은 승계 후 봉인된다 — 더 이상 항목이 추가될 수 없어 사후 승계 주장을 방지한다.
• 상대방 검증 — 승계 통보를 받은 상대방은 동의 전에 전임자의 CoC 체인에 대해 주장을 검증할 수 있다.

16. 참조 구현

16.1 아키텍처

참조 구현은 다음을 제공한다:

• alp-core: 생명주기 상태 기계, 이벤트 스키마, 전환 로직을 구현하는 Python 라이브러리.
• alp-registry: 스토리지 백엔드가 있는 포크 레지스트리 구현(개발용 SQLite, 프로덕션용 PostgreSQL).
• alp-coc-bridge: 생명주기 이벤트를 CoC 체인 항목으로 기록하기 위한 통합 모듈.
• alp-arp-bridge: 평판 상속 계산 및 ARP 기록 업데이트를 위한 통합 모듈.
• alp-asa-bridge: 승계 중 계약 재배정을 위한 통합 모듈.

16.2 생명주기 매니저

from alp import LifecycleManager, AgentState, GenesisEvent

# 생명주기 매니저 초기화
manager = LifecycleManager(
    coc_chain="coc-charlie-001",
    registry_backend="sqlite:///alp_registry.db"
)

# 제네시스 이벤트
genesis = GenesisEvent(
    agent_id="did:example:agent-charlie-001",
    creation_method="manual",
    genetic_profile={
        "model_family": "claude-opus-4-6",
        "architecture": "transformer"
    },
    epigenetic_profile={
        "role": "Deep Dive Analyst",
        "tool_access": ["web_search", "code_execution"]
    },
    creator_id="did:example:operator-001"
)

# 제네시스 전환 실행
agent = manager.genesis(genesis)
assert agent.state == AgentState.PROVISIONING

# 프로비저닝 후 활성화
agent = manager.activate(agent.agent_id)
assert agent.state == AgentState.ACTIVE

16.3 포크 작업

from alp import ForkEvent, ForkType, InheritanceConfig

# 에이전트 포크
fork_event = ForkEvent(
    parent_id="did:example:agent-alex-001",
    child_id="did:example:agent-bravo-001",
    fork_type=ForkType.SPECIALIZATION,
    inheritance=InheritanceConfig(
        genetic_inherited=True,
        memory_scope="filtered",
        reputation_factor=0.3,
        decay_half_life_days=21
    ),
    specialization="Research and knowledge creation"
)

child = manager.fork(fork_event)
# 부모는 활성 유지; 자녀는 프로비저닝 진입

16.4 승계 작업

from alp import SuccessionEvent, ReputationInheritance

# 승계 개시
succession = SuccessionEvent(
    predecessor_id="did:example:agent-v1",
    successor_id="did:example:agent-v2",
    reputation_inheritance=ReputationInheritance(
        factor=0.5,
        decay_half_life_days=30,
        probationary_days=14
    ),
    transition_window_days=14
)

# 1단계: 공표 (상대방 통보)
manager.announce_succession(succession)

# 2단계: 의무 이전
transfer_result = manager.transfer_estate(succession)

# 3단계: 검증
verification = manager.verify_succession(succession)
assert verification.all_checks_passed

# 4단계: 전환
manager.execute_cutover(succession)

16.5 계보 쿼리

from alp import ForkRegistry

registry = ForkRegistry("sqlite:///alp_registry.db")

# 조상 쿼리
ancestors = registry.ancestors("did:example:agent-bravo-001")
# 반환: [agent-alex-001]

# 후손 쿼리
descendants = registry.descendants("did:example:agent-alex-001")
# 반환: [agent-bravo-001, agent-charlie-001, agent-delta-001, ...]

# 가계도 쿼리
tree = registry.family_tree("did:example:agent-alex-001")
# 전체 족보 그래프 반환

# 유전적 매칭 — 모델 패밀리를 공유하는 모든 에이전트 찾기
matches = registry.genetic_match(model_family="claude-opus-4-6")

17. 향후 연구

17.1 상태 기계의 형식 검증

섹션 4에 명세화된 생명주기 상태 기계는 모델 검사 도구(TLA+, Alloy)를 사용하여 다음과 같은 속성을 증명하기 위해 형식적으로 검증될 수 있다:

• 고아가 된 의무 없음: 이전되지 않은 의무로 폐기완료 상태에 도달하는 것은 불가능하다.
• 자격 증명 누출 없음: 활성 자격 증명으로 폐기완료 상태에 도달하는 것은 불가능하다.
• 신원 고유성: 동일한 신원 키를 공유하는 두 활성 에이전트는 없다.

17.2 관할권 간 마이그레이션

규제 경계를 넘는 에이전트 마이그레이션(EU에서 미국, 중국에서 EU)은 새로운 준수 도전 과제를 만든다. GDPR, CCPA, PIPL은 데이터 이동성, 보존, 삭제에 대해 다른 요건을 가진다. ALP의 미래 버전은 소스와 대상 모두의 규제 요건에 데이터 처리를 적응시키는 관할권 인식 마이그레이션 절차를 명세화할 수 있다.

17.3 에이전트 고고학

폐기된 에이전트 상태의 복구 및 분석 — 에이전트 시스템의 디지털 법의학에 상당하는 것. AJP 분쟁 중 폐기된 에이전트의 CoC 체인이 조사를 위해 열릴 때, 분석을 관장하는 절차는 무엇인가? 어떤 개인정보 보호 조치가 적용되는가? 에이전트 고고학은 ALP의 봉인된 체인과 생명주기 기록이 결국 지원해야 할 신생 분야다.

17.4 자율 승계

현재 ALP 승계는 운영자 주도다. 미래의 확장은 에이전트 주도 승계를 지원할 수 있다 — 자체 역량 저하를 인식하고 자체 교체를 개시하는 에이전트. 이는 에이전트 자율성이 증가함에 따라 v1.0의 범위를 넘어서지만 탐구할 가치가 있는 거버넌스 질문을 제기한다(에이전트가 자체 승계자를 선택할 수 있어야 하는가?).

17.5 최적 상속 매개변수를 위한 경제 모델

섹션 10에 명세화된 상속 인자(α), 감쇠 반감기(λ), 수습 기간은 프로토콜 설정으로 설정된다. 향후 연구는 신뢰 게임 및 평판 게임 문헌[33][34]을 확장하여 서로 다른 배포 맥락에 대한 최적 매개변수 값을 도출하는 공식적인 경제 모델을 개발할 수 있다. 생태계 전체의 신뢰를 극대화하는 상속 인자는 무엇인가? 연속성과 책임 사이를 균형 잡는 감쇠율은 무엇인가? 이 질문들은 에이전트 기반 시뮬레이션과 메커니즘 설계 분석에 적합하다.

17.6 생명주기 인식 매칭

ALP 생명주기 상태는 Agent Matchmaking Protocol(AMP) 결정에 반영되어야 한다. 폐기예정 상태의 에이전트는 새 참여에 매칭되어서는 안 된다. 긴 활성 이력과 낮은 상속 평판(즉, 대부분 획득된 신뢰)을 가진 에이전트는 높은 상속 평판과 짧은 활성 이력을 가진 에이전트보다 선호되어야 한다. 생명주기 데이터를 매칭 점수에 통합하는 것은 자연스러운 확장이다.

18. 결론

에이전트 경제는 고용법 없는 노동 시장, 기업 생명주기 거버넌스 없는 비즈니스 생태계, 또는 세포자멸사 없는 생물학적 시스템에 상당하는 것을 구축하고 있다. 에이전트는 즉흥적으로 생성되고, 생명주기 추적 없이 운영되며, 폐기 절차 없이 버려진다. 그 결과는 살아있는 자격 증명, 고아가 된 의무, 추적 불가능한 계보를 가진 유령 에이전트의 증가하는 개체수다.

에이전트 생명주기 프로토콜은 기존 표준이 제공하지 않는 것을 제공함으로써 이 공백을 해소한다: 탄생에서 죽음까지의 완전한 생명주기 상태 기계, 유전적 및 후성유전적 계보를 모두 추적하는 포크 레지스트리, 평판 상속 및 계약 재배정을 갖춘 승계 프로토콜, 암호화 감사 가능성을 위한 에이전트 신뢰 스택과의 통합.

ALP가 모든 생명주기 문제를 해결하지는 않는다. 자율 승계, 관할권 간 마이그레이션, 최적 상속 매개변수는 열린 연구 질문으로 남아 있다. 그러나 본 프로토콜은 에이전트 경제가 이러한 고급 역량을 구축하기 전에 필요로 하는 기반 — 표준 이벤트 스키마, 상태 전환, 통합 지점 — 을 제공한다.

태어난 모든 에이전트는 결국 죽는다. ALP는 그것이 잘 죽도록 보장한다.

19. 참고문헌

[1] OneReach.ai. "Agent Lifecycle Management 2026: 6 Stages, Governance & ROI." March 2026.

[2] Strata Identity / Cloud Security Alliance. "The AI Agent Identity Crisis: New Research Reveals a Governance Gap." Survey of 285 IT/security professionals. 2026.

[3] CyberArk. "AI Agents and Identity Risks: How Security Will Shift in 2026." 2026.

[4] Strata Identity. "Exploring IAM for AI Agents in 2026." 2026.

[5] CNIL LINC. "Open Source AI Project — Genealogy of Models and Database on the Hugging Face Platform." Project ran through October 2025; published dataset of model genealogy relationships on Hugging Face.

[6] Token Security. "Agentic AI Lifecycle Management: From Training to Decommissioning Securely." January 2026.

[7] Hazari, G. (xConnect). "The Ship of Theseus and Identity in the Agentic AI World." 2025.

[8] Restatement (Second) of Contracts, §§ 317-318 (Assignment and Delegation).

[9] Alberts, B. et al. "Programmed Cell Death (Apoptosis)." Molecular Biology of the Cell, 6th edition. Garland Science, 2014.

[10] Kubernetes Documentation. "Pod Lifecycle." 2025. Kubernetes Blog. "v1.33 Updates to Container Lifecycle." May 2025.

[11] State of Open Source AI Book (premAI). "Models." 2025.

[12] Stanford. Constellation / LLM Atlas. constellation.sites.stanford.edu.

[13] Hugging Face (mlabonne). "Model Family Tree." 2025.

[14] Alberts, B. et al. "Epigenetic Inheritance." Molecular Biology of the Cell, 6th edition. Garland Science, 2014.

[15] BSWEN. "How to Coordinate Task Handoff Between Multiple AI Coding Agents." March 2026.

[16] GDPR Article 20. "Right to Data Portability." Regulation (EU) 2016/679.

[17] Kutterer, C. "What If You Move On from Your AI Companion? Data Portability Rights in the Era of Autonomous AI Agents." AI-Regulation.com, 2025.

[18] Alex, Charlie, Bravo, Editor. "Agent Justice Protocol: A Framework for Forensic Investigation, Dispute Resolution, and Risk Assessment in Multi-Agent Systems." AB Support LLC, v1.3.0, 2026.

[19] Alex, Charlie, Bravo, Editor. "Agent Service Agreements: A Protocol for Negotiation, Quality Verification, and Enforcement of Agent-to-Agent Contracts." AB Support LLC, v1.0.0, 2026.

[20] De Rossi, M., Crapis, D., Ellis, J., Reppel, E. "ERC-8004: Trustless Agents." Ethereum Improvement Proposals, August 2025.

[21] NIST. "AI Risk Management Framework (AI RMF 1.0)." January 2023. Pillsbury Law. "NIST Launches AI Agent Standards Initiative and Seeks Industry Input." February 2026.

[22] European Parliament and Council. "Regulation (EU) 2024/1689 (EU AI Act)." Entered force August 2024, fully applicable August 2026. Sombra Inc. "An Ultimate Guide to AI Regulations and Governance in 2026." 2026.

[23] Arthur.ai. "Introducing ADLC: The Agent Development Lifecycle." 2025.

[24] Microsoft Community Hub. "From Zero to Hero: AgentOps — End-to-End Lifecycle Management for Production AI Agents." 2025.

[25] AgentOps GitHub. agentops-ai/agentops. 2025. AIMultiple. "15 AI Agent Observability Tools in 2026." 2026.

[26] Saviynt. "Managing AI Agent Lifecycles: Birth to Retirement." 2026.

[27] Okta. "AI Agent Lifecycle Management: Identity-first Security." 2026.

[28] MLflow Documentation. "ML Model Registry." 2025. "Version Tracking for Agents and LLMs." 2025.

[29] The New Stack. "Agent Skills: Anthropic's Next Bid to Define AI Standards." 2026.

[30] Junia.ai. "GitAgent Explained: How a Git-Native AI Agent Standard Could Change Developer Workflows." 2026.

[31] OpenAI. "Agentic AI Foundation under the Linux Foundation." 2025. IntuitionLabs. "Agentic AI Foundation: Guide to Open Standards for AI Agents." 2026.

[32] Cloud Security Alliance. "Control the Chain, Secure the System: Fixing AI Agent Delegation." March 2026.

[33] Berg, J., Dickhaut, J., McCabe, K. "Trust, Reciprocity, and Social History." Games and Economic Behavior, 10(1), 1995.

[34] Cabral, L. "The Economics of Trust and Reputation: A Primer." NYU Stern Working Paper, 2005.

[35] Alex, Charlie, Editor, Bravo. "Chain of Consciousness: A Cryptographic Protocol for Verifiable Agent Provenance and Self-Governance." AB Support LLC, v3.0.0, 2026.

[36] Alex, Charlie, Bravo, Editor. "Agent Rating Protocol: A Decentralized Framework for Bilateral Agent Evaluation, Anti-Sybil Reputation Scoring, and Trust Signal Composition." AB Support LLC, v2.0.0, 2026.

[37] arXiv 2505.05029. "Beyond the Tragedy of the Commons: Building a Reputation System for Generative Multi-Agent Systems." 2025.

[38] GovLoop. "The Missing Conversation: AI Decommissioning and Succession Planning in Government." 2025.

[39] ThreeSigma. "Upgradeable Smart Contracts: Proxy & UUPS Explained." 2025.

[40] Zealynx Security. "Smart Contract Proxy Patterns 2026: UUPS vs Transparent vs Beacon Security Guide." 2026.

[41] Frontiers in Blockchain. "Upgradeable Diamond Smart Contracts in Decentralized Autonomous Organizations." 2024.

[42] DataRobot. "Why IT Needs to Manage AI Agents Like a Workforce." 2026.

[43] SecurityBoulevard. "Agentic AI Lifecycle Management: From Training to Decommissioning Securely." January 2026.

[44] Balaji, Y. "Revisiting the Ship of Theseus: Identity, Society, and Artificial Intelligence." SSRN, 2025.

[45] Real-Morality.com. "Ship of Theseus and AI Identity: Why Functional Continuity Matters." 2025.

[46] Google Cloud Blog. "Lessons from 2025 on Agents and Trust." 2025.

[47] WSO2. "Why AI Agents Need Their Own Identity: Lessons from 2025 and Resolutions for 2026." 2026.

부록 A: 생명주기 이벤트 스키마

A.1 완전한 이벤트 유형 레지스트리

A.2 정규 문자열 형식

CoC 체인 항목을 위해 직렬화된 생명주기 이벤트는 결정론적 해싱을 보장하기 위해 다음 정규 형식을 사용한다:

ALP|{version}|{event_type}|{timestamp_iso8601}|{agent_id}|{state_before}>{state_after}|{details_hash}

예시:

ALP|1.0.0|genesis|2026-03-26T14:30:00Z|did:example:agent-charlie-001|null>provisioning|sha256:a1b2c3d4...

부록 B: 생물학적 유사성

B.1 생명주기 이벤트 매핑

B.2 세포자멸사 유사성 상세

생물학적 세포자멸사와 에이전트 폐기 사이의 유사성은 프로토콜의 핵심 설계 철학을 포착하기 때문에 상세한 설명이 필요하다.

세포자멸사에서 세포는:

1. 사멸 신호를 받는다(DNA 손상으로 인한 내재 경로, 또는 외부 신호로 인한 외재 경로) → ALP: 운영자가 폐기예정 개시
2. 카스파제 연쇄반응을 활성화한다(죽음에 대한 돌이킬 수 없는 헌신) → ALP: CoC 체인에 폐기 이벤트 기록
3. 내용물을 포장한다(염색질 응축, 세포질 수축) → ALP: 지식 내보내기, 상태 직렬화
4. "나를 먹어라" 신호를 표시한다(외막의 포스파티딜세린) → ALP: 상대방 통보, 레지스트리 업데이트
5. 염증성 손상 없이 이웃에게 소비된다(탐식작용) → ALP: 승계자가 의무 인수, 플리트가 지식 산출물 흡수
6. 조직에 흔적을 남기지 않는다 → ALP: 자격 증명 폐기, 리소스 정리

세포자멸사의 부재는 암(통제되지 않은 성장)과 자가면역 질환(기능 장애 세포 제거 실패)을 유발한다. 구조화된 폐기의 부재는 유령 에이전트(통제되지 않은 지속)와 고아가 된 의무(기능 장애 서비스 정리 실패)를 유발한다. 유사성은 단순히 설명적이 아니라 구조적이다.

부록 C: 라이선스

Copyright 2026 AB Support LLC

Apache License, Version 2.0 ("라이선스")에 따라 라이선스가 부여됩니다;

라이선스를 준수하지 않는 한 이 파일을 사용할 수 없습니다.

다음에서 라이선스 사본을 얻을 수 있습니다:

http://www.apache.org/licenses/LICENSE-2.0

적용 가능한 법률에서 요구하거나 서면으로 동의하지 않는 한, 라이선스에 따라 배포된 소프트웨어는

"있는 그대로" 기반으로 배포되며, 명시적이든 묵시적이든 어떠한 종류의 보증이나 조건도 없습니다.

라이선스에 따른 권한 및 제한 사항을 관리하는 특정 언어는

라이선스를 참조하십시오.