지난주 에이전트 시장에 두 개의 신호가 동시에 터졌다. AWS는 뉴욕 서밋에서 에이전트 개발·운영 플랫폼 베드록 AgentCore를 정식 출시했고, 마이크로소프트는 포춘 500대 기업 절반 이상이 이미 쓰고 있다는 코파일럿 코워크를 전 세계에 공개했다. 둘 다 '초안을 뽑아주는 AI'가 아니다. 장시간 실행되는 복잡한 업무를 완성된 결과물로 처리하는 '운영급 에이전트'다.
테크 리드 입장에서 이 두 출시가 흥미로운 이유는 성능 경쟁이 아니라 통제 설계 경쟁으로 프레임이 바뀌었다는 점이다. AWS는 수백 개 세션의 실패·의도·경로를 분석하는 최적화 기능, 데이터 관계를 지식그래프로 엮는 '컨텍스트(Context)', 저장 객체마다 에이전트용 컨텍스트를 1GB까지 붙이는 'S3 주석'을 함께 내놨다. MS 코파일럿 코워크는 기본 비활성화 상태로 제공되며, 관리자가 테넌트·그룹·사용자 수준의 지출 한도와 사용량 알림을 설정한 뒤에야 활성화할 수 있다. 두 플랫폼 모두 에이전트에게 더 많은 자율을 주되, 무엇을 했는지 추적하고 권한을 제어하는 거버넌스를 함께 제공하겠다는 방향이다.
이 흐름은 기업이 에이전트 도입을 망설인 이유가 성능이 아니라 통제 가능성과 데이터 보안이었다는 사실을 플랫폼들이 정면으로 인정한 것이다. 즉, 플랫폼 레이어는 이제 그 빈틈을 상당 부분 메우고 있다. 남은 질문은 하나다. "그럼 팀은 에이전트를 붙이기 전에 무엇을 설계해야 하는가?"
첫째, 거버넌스 구조를 플랫폼에 맡기지 말고 팀이 직접 정의해야 한다.
AWS AgentCore와 MS 코파일럿 코워크가 제공하는 권한 제어·비용 한도·감사 로그는 인프라 레이어의 안전망이다. 하지만 '이 에이전트가 어떤 데이터에 접근할 수 있는가', '어떤 결과물을 사람이 검토해야 하는가', '에이전트가 실패했을 때 누가 책임지는가'는 플랫폼이 대신 결정해주지 않는다. 팀이 에이전트를 워크플로우에 붙이기 전에 접근 범위·승인 임계값·책임 소재를 문서로 박아두지 않으면, 플랫폼의 거버넌스 기능은 켜져 있어도 팀 안에서는 작동하지 않는다.
둘째, 에이전트가 참조할 지식 구조를 먼저 정리해야 한다.
AWS가 이번에 매니지드 지식베이스(RAG 연결)와 컨텍스트(지식그래프) 두 갈래로 지식 도구를 나눈 것은 의미심장하다. 단순 문서 검색으로 처리되는 업무와, 데이터 사이의 관계를 따라가야 하는 업무는 요구하는 지식 구조가 다르다. 팀이 에이전트에게 어떤 업무를 맡길지 결정하기 전에, 그 업무에 필요한 지식이 어디에 있고 어떤 형태로 연결되어야 하는지를 먼저 설계해야 한다. 지식 구조가 엉망인 상태에서 에이전트를 붙이면 RAG 환각이 아니라 RAG 오작동이 난다.
셋째, 현업 조직의 역할을 재설계해야 한다.
GS건설의 'AX 레시피' 사례는 이 지점에서 참고할 만한 실행 패턴을 보여준다. AI·IT 전문 인력이 아닌 일반 현업 조직이 과제 발굴과 실행을 주도하고, AI 전문 조직이 기술적 완성도를 코칭하는 구조다. 올해는 개인 참여에서 팀 단위 방식으로 전환하면서 'AI 에이전트 구조 설계'를 핵심 과제로 명시했다. 임원 110명 이상이 피지컬 AI 도입을 논의했고, 직무별 특화 AI 아카데미를 매월 운영 중이다. 건설업이 이렇게 움직인다면, 소프트웨어 팀은 더 빠르게 이 구조를 내재화해야 한다.
운영급 에이전트를 팀 워크플로우에 붙이는 것은 도구를 켜는 결정이 아니다. 거버넌스 정책, 지식 구조, 현업 역할 재설계—세 가지가 먼저 완성되어야 에이전트는 팀의 속도를 끌어올린다. 그 전에 켜면, 플랫폼이 아무리 운영급이어도 팀 안에서는 실험급으로 작동한다.
마이크로소프트·AWS·구글·세일즈포스가 클라우드 인프라 단에서 에이전트 운영 환경을 선점하려는 경쟁은 이미 본격화됐다. 플랫폼 레이어는 빠르게 수렴할 것이다. 차별점은 결국 팀이 그 위에 어떤 설계를 올리느냐에서 갈린다. 내일 AgentCore나 코파일럿 코워크 도입을 검토하는 팀이라면, 먼저 세 가지 질문에 답을 가져와야 한다. 에이전트가 무엇에 접근하고 무엇을 결정하면 안 되는가. 에이전트가 참조할 지식은 어디에 어떤 형태로 있는가. 에이전트가 업무를 가져갔을 때 사람은 무엇을 하는가.