8월 24일 월요일

장시간 실행 에이전트에서 플랫폼에 맡길 복잡성과 팀이 직접 소유할 실행 핵심은 어디에서 나뉘는가?

Oz 플랫폼은 로컬 작업을 클라우드로 옮길 때 생기는 샌드박스, 호스팅, 하네스, 멀티에이전트 조합을 하나의 경험으로 감싸려 합니다. 관리형 환경으로 빠르게 시작하되 실제 팀은 자신의 인프라와 보안 관행에서 실행할 선택권이 필요합니다. 플랫폼의 가치는 복잡성을 없애는 것이 아니라 사용자가 인프라 누수를 직접 처리하지 않게 하는 데 있습니다.

반대로 작은 이벤트 기반 런타임을 직접 만든 사례는 프레임워크가 실행 원리를 숨기면 재현과 디버깅이 어려워진다고 경고합니다. 에이전트를 이벤트를 구독하고 발행하는 프로세스로 보고, append-only 로그와 콘텐츠 주소, 타입 경계를 두면 실제 입력을 재생하고 중복과 누락을 조사할 수 있습니다. 두 관점은 충돌하지 않습니다. 샌드박스와 확장, 호스팅은 플랫폼에 맡길 수 있지만 이벤트 스키마, 실행 기록, 품질 기준은 제품 팀이 소유해야 합니다.

임상 AI 사례는 이 경계가 왜 중요한지 보여줍니다. 고정된 평가표가 조용한 누락의 임상적 중요성을 놓치면 실제 전문가의 수정과 이유를 다시 기준으로 흡수해야 합니다. 실행 플랫폼이 안정적이어도 도메인 실패를 발견하고 보정하는 학습 루프는 별도 책임입니다.

1. 01

   플랫폼은 실행 장소와 조합을 표준화한다

   관리형·자체 호스팅 샌드박스와 다양한 에이전트 하네스를 같은 인터페이스로 제공하면 팀은 장시간 작업을 빠르게 시작할 수 있습니다. 보안과 배포 관행을 유지할 선택권이 핵심입니다. 사용자는 내부 인프라 차이를 매번 학습하지 않으면서도 실행 위치와 권한은 통제할 수 있어야 합니다.

2. 02

   커널은 이벤트와 재생 규칙을 소유한다

   append-only 로그, 콘텐츠 주소와 타입 경계는 어떤 맥락으로 실행됐는지 증명합니다. 고정 그래프보다 이벤트 구독 관계를 명시하면 구성 요소를 바꾸면서도 실행을 비교할 수 있습니다.

3. 03

   평가는 실제 실패와 함께 변한다

   임상 노트의 중요한 누락처럼 자동 검사에 잘 잡히지 않는 오류는 전문가가 실제 출력에서 발견해야 합니다. 수정 이유를 캡처하고 관련 과거 판단을 다음 출력에 적용하는 반복 루프가 필요합니다.

구매할 것과 직접 만들 것을 기능 목록으로 나누지 마십시오. 규모와 격리 같은 공통 인프라는 플랫폼에 맡기고, 실행의 의미를 결정하는 이벤트 계약과 데이터 계보, 도메인 평가 기준은 팀의 이동 가능한 자산으로 남겨야 합니다.