9월 14일 월요일

에이전트가 실제 개발 도구가 되려면 모델 성능 말고 어떤 접속면과 작업 절차가 표준화되어야 하는가?

ACP는 에이전트 하네스와 클라이언트 사이의 비어 있는 표준 면을 겨냥한다. MCP가 에이전트가 외부 도구와 데이터에 접근하는 방향을 다뤘다면, ACP는 클라이언트가 에이전트에게 작업을 주고 진행 상태와 결과를 받는 반대 방향을 JSON-RPC로 묶으려 한다. Pstack은 더 높은 운영 층에 있다. 스킬, 플레이북, Potato Mode, 병렬 에이전트, TDD, 실행 검증을 조합해 중요한 기능을 만들 때 비결정성과 환각을 줄이는 개발 절차로 제시된다. 둘의 공통점은 “좋은 모델 하나”보다 에이전트가 놓이는 표면과 검증 루프가 병목이라는 점이다. 실제 도입 관점에서는 두 층을 섞지 않는 것이 중요하다. ACP 같은 프로토콜이 클라이언트, 권한, 상태 전파를 안정화하지 못하면 어떤 하네스도 특정 앱 안에서만 빛난다. 반대로 프로토콜만 있고 테스트와 실행 검증이 약하면 에이전트가 그럴듯한 변경을 만들었는지 실제로 동작하는 변경을 만들었는지 구분하기 어렵다.

1. 01

   프로토콜 층

   ACP의 핵심은 특정 앱에 갇힌 에이전트 UI가 아니라 여러 클라이언트가 같은 하네스를 다룰 수 있는 표준 명령·상태·결과 채널이다. JSON-RPC를 쓰면 로컬과 원격 환경을 넘나드는 요청/응답 구조를 만들 수 있지만, 실제 가치는 진행 상태, 취소, 권한, 산출물 참조 같은 UX 계약이 얼마나 일관되게 잡히느냐에 있다.

2. 02

   하네스 층

   Pstack은 에이전트 여러 개를 무작정 병렬 실행하는 방식이 아니라, 어떤 스킬을 먼저 쓸지 고르고 플레이북으로 사용 사례를 좁힌 뒤 Arena, Swarm, TDD, 다중 모델 심문, 실제 실행 검증을 붙이는 구조다. 비용과 시간이 커서 모든 변경에 쓰기보다 중요한 기능과 위험 높은 수정에 선별 적용하는 쪽이 원문이 말하는 합리적 경계다.

3. 03

   트레이드오프

   프로토콜은 상호운용성을 만들지만 추상화가 과하면 각 도구의 강점을 평평하게 만들 수 있다. 작업 스택은 품질을 올리지만 토큰, 대기 시간, 검증 비용을 키운다. 따라서 설계자는 에이전트 작업을 “빠른 초안”, “검토 가능한 패치”, “실행까지 증명해야 하는 변경”으로 나누고, 각 단계에 맞는 접속면과 검증 강도를 달리해야 한다.

4. 04

   검증 루프

   Pstack의 TDD와 실제 실행 검증은 에이전트 산출물을 문장 평가가 아니라 동작 증거로 판단하려는 장치다. ACP가 작업을 넘겨받고 상태를 돌려주는 통신 경로라면, Pstack의 검증 루프는 그 결과가 요구사항을 만족했는지 확인하는 폐쇄 회로다. 중요한 기능일수록 이 두 회로가 함께 있어야 재현 가능한 개발 흐름이 된다.

에이전트 도구의 다음 차별점은 모델 이름보다 작업을 넘기고, 중단하고, 검증하고, 재현하는 경계에 있다. ACP는 그 경계를 프로토콜로, Pstack은 개발 운영 절차로 풀려는 시도다. 한쪽은 접속면을 안정화하고 다른 한쪽은 산출물의 참거짓을 좁히므로, 실제 제품에서는 둘을 별도 계층으로 설계해야 한다.