Omni by xpander

처리할 프로세스를 Omni에 말하면 그것을 에이전트 프로젝트로 바꾼다. 커넥터를 고르고, 지시를 쓰고, 메모리를 설정하고, 출시 전에 에이전트를 검토에 통과시킨다. 엔지니어가 API 문서를 며칠 읽으며 해야 할 연결 작업을 대신 처리한다. 인프라가 필요 없다. 사용자 쪽에 설정 프로젝트도 없다. 전부 채팅창의 한 문장에서 시작한다.

Omni는 지난 작업과 추적 기록을 읽어 에이전트가 어디서 성공하고 실패했는지 보고, 지시를 다시 써서 개선한다. 지난달 티켓을 처리한 에이전트가 이번 달에는 설정 하나 건드리지 않고도 눈에 띄게 더 잘 처리한다. 누가 지켜보지 않게 된 뒤에 흐트러지는 대신, 돌아갈수록 좋아진다. 기업용 AI 에이전트 대부분은 이 두 번째 손질을 받지 못한다.

API나 커넥터가 바뀌면 Omni가 영향을 받는 에이전트를 모두 찾아 조용히 망가지기 전에 갱신한다. 덕분에 보고서가 빈 채로 돌아온 뒤에야 며칠 늦게 고장을 알아차리는 일을 피한다. 연동이 많은 구성에서 이게 중요하다. 엔드포인트 하나가 바뀌면 그것에 의존하는 에이전트 사슬이 조용히 끊기기 때문이다.

Claude나 Codex에서 로컬로 만든 에이전트는 xpander로 가져와 클라우드에서 일관되게 돌릴 수 있다. 작업은 그 기술과 MCP 커넥터와 함께 옮겨가므로 동료의 기기가 그것이 존재하는 유일한 장소가 아니다. 마이그레이션 프로젝트 없이 하는 AI 에이전트 배포다. 처음부터 다시 만들 필요가 없다.

Omni는 같은 작업을 최전선 모델과 오픈 모델에서 돌려 어느 것이 가장 잘하는지 보여 준다. 그런 다음 에이전트를 다시 만들지 않고 바꾼다. 모델 업그레이드는 계획하는 프로젝트가 아니라 바꾸는 설정이 된다. 모델 선택은 걸어 두는 추측이 아니라 돌려 보는 테스트가 된다. 하나를 고르고, 돌리고, 추적 기록을 비교한다.

에이전트는 설정 차이를 안전하게 처리하며 개발에서 프로덕션으로 넘어가고, 각각 문서화된다. 아래 플랫폼의 사용자별 권한과 감사 추적과 함께, 이것이 프로덕션 전환을 IT 팀이 감당할 수 있게 만든다. 무엇이 도는지 승인해야 하기 때문이다. 재미없는 부분이다. 동시에 에이전트가 프로덕션에 남을지, 프로토타입 폴더에서 죽을지를 정하는 부분이기도 하다.

에이전트는 Slack, Teams, GitHub, 내부 API 등 회사가 이미 쓰는 시스템으로 손을 뻗는다. MCP 커넥터와 API 호출은 임시방편이 아니라 통제된 경로를 지나므로 자격 증명이 모델의 컨텍스트에 들어가지 않는다. 이 분리가 핵심이다. 보안 팀은 어떤 기능 목록보다 이것을 더 신경 쓴다.