오늘의 AI 글: AI 에이전트의 다음 병목은 실행 거버넌스다

왜 이 글인가

AI 에이전트 논의는 한동안 “얼마나 자율적으로 일할 수 있는가”에 집중했다. 문서를 읽고, 코드를 고치고, 도구를 호출하고, 여러 단계를 이어가는 능력은 확실히 매력적이다. 하지만 실제 업무 시스템에 붙이는 순간 질문은 달라진다. 이제 중요한 것은 “무엇을 할 수 있는가”가 아니라 “어떤 권한으로, 어떤 조건에서, 어떤 기록을 남기며 실행되는가”다.

Microsoft가 Build 2026에서 공개한 에이전트 보안 관련 발표는 이 변화를 잘 보여준다. 발표의 중심에는 코드, 모델, 에이전트를 개발 생애주기 전체에서 보호해야 한다는 문제의식이 있다. 특히 Agent 365, MCP 서버 등록, 로컬 에이전트와 원격 MCP 서버의 관리, 정책 기반 실행 제어, 관찰 가능성 같은 키워드가 함께 등장한다. 이는 에이전트가 실험실 데모를 넘어 실제 조직의 업무 환경으로 들어가고 있다는 신호다.

이 글이 오늘의 AI 글로 중요한 이유는 에이전트의 위험을 추상적인 공포가 아니라 운영 설계의 문제로 다룬다는 점이다. AI가 사내 문서를 읽고, 코드 저장소를 분석하고, 고객 데이터에 접근하고, 로컬 앱을 제어하고, 외부 MCP 서버와 연결된다면 단순한 프롬프트 정책만으로는 부족하다. 어떤 에이전트가 등록되어 있는지, 어떤 도구를 호출했는지, 누가 승인했는지, 어떤 데이터가 오갔는지를 볼 수 있어야 한다.

특히 MCP가 널리 쓰일수록 이 문제는 더 커진다. MCP는 모델이 외부 도구와 맥락을 일관된 방식으로 사용할 수 있게 해주는 유용한 연결 계층이다. 하지만 연결 표준은 동시에 공격 표면의 표준화이기도 하다. 서버가 늘어나고, 도구가 많아지고, 에이전트가 여러 시스템을 오가면 “편리한 연결”과 “통제 불가능한 실행” 사이의 간격이 빠르게 좁아진다.

핵심 요약

• Microsoft의 발표는 에이전트를 별도 장난감이 아니라 개발·보안·운영 생애주기 안에서 관리해야 할 실행 주체로 본다. 코드 보안, 모델 보안, 에이전트 런타임 통제가 따로 떨어진 문제가 아니라 하나의 흐름이라는 관점이다.

• Agent 365와 MCP 관련 흐름은 조직이 로컬 에이전트, 데스크톱 AI 앱, 원격 MCP 서버를 한곳에서 등록하고 관리하려는 방향을 보여준다. 이는 “각 사용자가 마음대로 연결한 도구”에서 “조직이 볼 수 있고 제어할 수 있는 에이전트 인벤토리”로 이동하는 변화다.

• 중요한 키워드는 관찰 가능성이다. 에이전트가 어떤 도구를 호출했고, 어떤 정책에 의해 허용되거나 차단되었고, 어떤 데이터에 접근했는지 추적할 수 있어야 한다. 결과만 보는 방식으로는 사고가 난 뒤 원인을 찾기 어렵다.

• 보안의 초점도 바뀐다. 전통적인 애플리케이션 보안은 주로 코드 취약점, 인증, 권한, 네트워크 경계를 다뤘다. 에이전트 시대에는 여기에 목표 탈취, 도구 오용, 메모리 오염, 잘못된 MCP 서버 연결, 과도한 권한 부여 같은 문제가 더해진다.

• MCP는 편리하지만 모든 문제를 해결하지 않는다. 서버 목록이 늘어나면 어떤 서버를 신뢰할지, 어떤 도구를 읽기 전용으로 둘지, 어떤 실행은 승인 후 허용할지, 민감 데이터가 도구 호출에 섞이지 않게 할지를 별도로 설계해야 한다.

• 개발자에게도 이 변화는 직접적이다. 앞으로 코딩 에이전트는 로컬 파일을 읽고, 터미널을 실행하고, PR을 만들고, 클라우드 리소스를 조작할 수 있다. 생산성이 커지는 만큼, 작업 단위와 권한 경계를 좁게 설계하는 능력이 개발자의 기본 역량이 된다.

• 최종적으로 에이전트 운영은 “모델 선택”보다 “실행 정책”의 문제가 된다. 같은 모델을 쓰더라도 어떤 도구를 연결하고, 어떤 로그를 남기고, 어떤 액션을 승인제로 두느냐에 따라 위험과 효용이 크게 달라진다.

일반 독자에게 중요한 포인트

AI 에이전트를 사람처럼 생각하면 과도한 기대와 과도한 공포가 번갈아 온다. 더 현실적인 비유는 권한이 있는 자동화 시스템이다. 자동화 시스템은 일을 빠르게 처리하지만, 권한이 넓고 검증이 약하면 사고도 빠르게 만든다. 그래서 좋은 에이전트 설계는 더 많은 자유를 주는 것이 아니라, 맡길 수 있는 범위를 정확히 정하는 일이다.

일반 사용자 입장에서는 “AI가 내 대신 해준다”는 문구를 볼 때 두 가지를 물어볼 필요가 있다. 첫째, 이 AI가 어떤 데이터에 접근하는가. 둘째, 이 AI가 실제로 무엇을 실행할 수 있는가. 문서를 요약하는 것과 고객에게 메일을 보내는 것은 완전히 다른 위험을 가진다. 추천을 만드는 것과 결제를 실행하는 것도 다르다.

기업 입장에서는 에이전트 수가 늘어날수록 관리되지 않는 연결이 문제가 된다. 직원 개인이 편의상 붙인 도구, 실험용 MCP 서버, 권한이 넓은 로컬 자동화가 쌓이면 어느 순간 누가 무엇을 할 수 있는지 파악하기 어려워진다. 이때 필요한 것은 금지가 아니라 인벤토리, 정책, 로그, 승인 흐름이다.

이 흐름은 AI 도입을 느리게 만들기 위한 것이 아니다. 오히려 반대다. 조직이 에이전트를 믿고 더 넓게 쓰려면, 실패했을 때 멈출 수 있고, 문제가 생겼을 때 추적할 수 있고, 위험한 실행을 미리 막을 수 있어야 한다. 안전장치가 있어야 자동화도 커진다.

적용 아이디어

• 에이전트가 접근하는 도구를 “읽기 전용 / 초안 작성 / 내부 수정 / 외부 실행”으로 나눠보라. 같은 에이전트라도 단계별 위험은 다르다.

• MCP 서버나 플러그인을 연결할 때 기능 목록만 보지 말고, 인증 방식, 권한 범위, 로그 제공 여부, 민감 데이터 처리 방식을 함께 확인하라.

• 외부 발송, 결제, 삭제, 고객 데이터 변경, 배포 같은 되돌리기 어려운 작업은 기본적으로 사람 승인 단계를 둬라.

• 에이전트 실행 로그에는 프롬프트 전문보다 “어떤 도구를 어떤 입력으로 호출했는가”가 더 중요할 수 있다. 감사와 디버깅에 필요한 로그 구조를 따로 설계하라.

• 개인 워크플로에서도 에이전트에게 홈 디렉터리 전체 권한을 주기보다 작업 폴더, 임시 브랜치, 읽기 전용 토큰처럼 좁은 경계를 먼저 사용하라.

• 에이전트가 실패했을 때 사람에게 넘겨줄 상태 파일이나 요약을 남기게 하라. 자동화는 성공할 때보다 실패할 때 설계 품질이 드러난다.

읽기 우선순위

AI 에이전트를 업무 도구로 연결하고 있다면 원문을 먼저 읽을 만하다. 특히 MCP 서버를 붙이거나, 코딩 에이전트에 로컬 실행 권한을 주거나, 사내 문서와 고객 데이터에 AI를 연결하려는 팀에는 “보안팀의 잔소리”가 아니라 제품 설계 체크리스트에 가깝다.

일반 독자라면 세부 제품명보다 방향을 보면 된다. 2026년의 AI 경쟁력은 더 유창한 답변만이 아니라, 에이전트가 실제 시스템 안에서 안전하게 움직이도록 만드는 운영 계층에서 갈린다. AI가 일을 많이 할수록, 그 일을 누가 보고 멈출 수 있는지가 더 중요해진다.