확장점은 플러그인이 아니라 경계면이다

에이전트 시스템을 키울 때 가장 쉬운 설명은 "플러그인을 붙인다"다. MCP 서버를 붙이고, memory backend를 바꾸고, gateway adapter를 늘리고, reviewer를 하나 더 세우면 겉보기에는 금방 커진다. 문제는 그 다음이다. 기능이 많아져도 어디까지 믿어도 되는지 모르면 운영은 더 불안해진다.

그래서 OkayJing은 확장점을 기능 목록으로 보지 않는다. 확장점은 경계면이다. 누가 무엇을 읽을 수 있는지, 어떤 권한으로 실행되는지, 실패하면 어디에 기록되는지, 결과 artifact를 Hub가 어떻게 흡수하거나 버리는지가 먼저 정해져야 한다.

플러그인이 생기면 새로운 tool이나 이벤트를 다룰 수 있다. 하지만 플러그인의 진짜 설계 질문은 "무엇을 더 할 수 있나"보다 "무엇을 대신 책임지는가"에 가깝다. Discord dashboard action plugin도 버튼을 누르게 만드는 코드로만 보면 작다. 실제 책임은 다르다. Discord interaction을 3초 안에 ACK하고, 특정 prefix만 처리하고, 실패할 때만 조용히 알리며, dashboard state를 다시 렌더링해야 한다.

이 책임을 적지 않으면 플러그인은 편의 기능으로 남는다. 적어두면 운영 경계가 된다. 어떤 메시지를 건드리지 말아야 하는지, 어떤 버튼은 daily guard를 통과해야 하는지, 어떤 실패는 사용자에게 보여야 하는지가 분명해진다.

MCP는 좋은 표준 방향이다. tool과 resource를 agent-readable하게 열어주는 공통 계약이기 때문이다. 그렇다고 모든 local state를 MCP로 열면 안 된다. memory DB, ticket DB, artifact store, file tree는 전부 권한과 provenance가 다른 표면이다.

OkayJing에서 MCP를 붙인다면 먼저 capability manifest가 필요하다. 읽기 전용인지, 쓰기가 가능한지, 어떤 profile root에 묶이는지, secret-bearing 파일을 어떻게 막는지, tool output을 evidence로 저장할 때 어떤 redaction을 거치는지까지 같이 정해야 한다. 연결은 그 뒤다.

memory backend를 바꾸거나 local-first catalog를 키우는 것도 확장처럼 보인다. 하지만 저장량이 늘었다고 기억력이 좋아지는 것은 아니다. 좋은 memory 확장은 claim이 source에 연결되고, stale/conflict를 구분하고, context pack이 실제 다음 작업 시간을 줄였다는 evidence를 남길 때 성숙해진다.