Phase 3: iFay 의 소프트웨어 애플리케이션 파생 접수

Phase 3 은 확장 방향을 단말 하드웨어에서 소프트웨어 애플리케이션으로 옮깁니다——로컬 애플리케이션、클라우드 서비스、In-APP 임베디드 시나리오.

소프트웨어 애플리케이션과 하드웨어 단말 사이에는 한 가지 핵심 차이가 있습니다: 하드웨어 단말의 상태는 상대적으로 집중되어 있어, 한 대의 드론、한 대의 로봇이 곧 하나의 감호 대상입니다; 그러나 소프트웨어 애플리케이션의 경계는 종종 프로세스화、모듈화、네트워크 횡단적입니다. iFay 에 의해 접수된 전자상거래 클라이언트는 동시에 여러 도메인、여러 API、여러 제3자 서비스를 가로질러 협업할 수 있습니다. Phase 3 의 난점은 "접수"에 있지 않고, 접수의 경계가 명확히 묘사되었는가에 있습니다.

Phase 2 와 동근원의 파생 구조

Phase 3 은 Phase 2 와 구조적으로 대칭이며, 여전히 "Human Prime ↔ 소프트웨어 애플리케이션"이라는 직접 관계를 도입하지 않습니다:

그 소프트웨어 애플리케이션은 대응하는 Human Prime 의 iFay 를 통해 Faying State 에 진입합니다.

책임 측은 여전히 Human Prime 입니다. iFay 는 Faying State 를 통해 파생적으로 소프트웨어 애플리케이션을 접수하며, 메커니즘은 Phase 2 에서 단말을 접수하는 것과 동근원입니다. 소프트웨어 애플리케이션 자체는 Faying State 안에 독립적으로 존재하지 않습니다.

세 가지 핵심 차이점

Phase 3 은 Phase 2 의 구조적 기반 위에 특별히 처리되어야 할 세 가지 복잡성이 더 있습니다.

접수 입도가 더 세밀합니다. iFay 는 소프트웨어 안의 일부 기능만 접수할 수 있습니다——예를 들어 대신 주문은 허용하되, 계정 보안 정책 수정은 허용하지 않습니다. 따라서 Phase 3 은 프로토콜 차원에서 "접수 범위"의 정밀화를 표현해야 하며, 이는 제 12 장의 "Faying Action 은 반드시 유한 범위여야 한다"는 원칙과 동근원입니다.

경계 횡단 협업이 더 밀집됩니다. 접수된 소프트웨어는 내부에서 여러 외부 서비스、제3자 API、원격 클라우드 함수를 호출할 수 있습니다. Phase 3 은 다음을 보장해야 합니다: iFay 가 접수된 소프트웨어를 통해 외부로 발기하는 모든 호출은, 귀책이 여전히 원래 Human Prime 에게 떨어지며, 책임이 서비스 횡단 호출 사슬에서 슬며시 사라지는 것이 허용되지 않습니다. 이 요구사항은 제 1 장에서 묘사한 "호출 사슬에서 데이터가 어느 주체를 거쳤는지 누구도 명확히 말할 수 없다"는 현실의 통점과 직접 호응합니다.

부작용이 더 은밀합니다. 물리 동작에 비해, 소프트웨어 부작용（데이터 쓰기、구독 변경、제3자 계정 연동）은 Human Prime 이 직관적으로 알아채기가 더 어렵습니다. Phase 3 은 제 11 장 Human View 의 "정보 도달 가능" 요구를 더 명시적으로 떨어뜨려야 합니다——부작용은 Human Prime 이 합리적인 비용 안에서 알 수 있는 방식으로 공개되어야 하며, 호출 사슬 깊숙이 묻혀서는 안 됩니다.

본기 범위와의 관계

Phase 3 은 본기 프로토콜 설계 범위에 포함되지 않습니다. 본 장에서 Phase 3 의 존재를 그리는 것은 Faying Protocol 의 진화 방향을 설명하기 위함이지, 본기 배포를 약속하기 위함이 아닙니다. Phase 3 의 구체적 프로토콜 형태는 후속 독립 spec 이 담당합니다.

Phase 3 이 완료되면, Faying Protocol 은 이미 Fay 와 하드웨어、소프트웨어 두 부류 집행 측의 관계를 커버하지만, 모든 논의는 여전히 "한 명의 Human Prime + 한 개의 iFay"를 중심으로 펼쳐집니다. 다음 단계 Phase 4 는 시야를 조직으로 확장합니다: Fay 가 하나가 아니고、책임 측이 더 이상 단일 자연인이 아닐 때, Faying 관계가 어떻게 일관된 귀책을 유지할 것인가.