읽기만 하던 AI는 해고다, 이제는 직접 클릭한다
'읽기만 하던 AI는 해고다' : 클릭하고 로그인하고 결제하는 액션 AI
지금까지의 AI는 읽는 존재였다. 문서를 읽고 요약했고, 질문을 읽고 답했고, 표를 읽고 분석했다. 우리는 그것을 보고 "AI가 똑똑해졌다"고 말했다. 틀린 말은 아니다. 하지만 불완전한 진단이었다. 일을 해본 사람이라면 안다. 생각과 실행은 다르다. 대부분의 사람은 판단보다 실행에서 더 많이 지친다.
온라인 쇼핑 하나를 떠올려보자. AI가 "이 제품이 조건에 가장 맞는다"고 말해준다. 여기까지는 순식간이다. 그런데 그다음이 길다. 사이트를 열고, 로그인하고, 옵션을 고르고, 쿠폰을 적용하고, 주소를 확인하고, 결제 수단을 선택하고, 인증을 통과하고, 주문 내역을 확인한다. 어렵지 않다. 하지만 귀찮고, 실수가 끼어들 틈이 많다. 판단은 빨라졌는데 실행이 그대로다. 전체 속도는 언제나 가장 느린 구간으로 묶인다. 여기서부터 행동하는 AI의 이야기가 시작된다.
에이전트 AI는 '답을 잘하는 AI'가 아니라 '행동으로 일을 끝내는 AI'다. 읽기 AI가 문제 풀이를 알려주는 친구라면, 에이전트 AI는 답안지에 직접 써서 제출까지 완료하는 친구다. 훨씬 강력하다. 그리고 그만큼 훨씬 위험하다. 행동은 흔적이 남고, 되돌리기 어렵기 때문이다.
에이전트 AI를 이해하는 가장 실용적인 방법은 '손동작'을 세어보는 것이다. 복사, 붙여넣기, 파일 열기, 저장, 폴더 이동, 다운로드, 업로드, 로그인, 인증 코드 입력. 하나하나는 단순하지만 합산하면 하루의 상당한 시간을 잠식한다. 에이전트 AI의 목표는 거창한 창작이 아니다. 이 손동작을 대신하는 것이다.
에이전트 AI의 기본 동작은 다섯 단계다. 목표를 말한다. AI가 계획을 세운다. 필요한 도구를 고른다. 실제로 실행한다. 결과와 기록을 보고한다. 이 다섯 단계가 안정적으로 작동하면, 사람의 역할은 '손'에서 '감독'으로 이동한다. 병목은 언제나 가장 아픈 곳으로 이동한다. 판단이 빨라졌으면 이제 실행이 느린 게 아프다. 그래서 행동할 수 있는 AI가 필요해진다.
▼ 에이전트 AI가 장악할 세 영역
에이전트 AI가 진입하는 영역은 세 층위로 나뉜다. 첫째는 내 컴퓨터 안에서의 행동이다. 파일 정리, 저장, 폴더 이동. 둘째는 웹에서의 행동이다. 검색, 클릭, 로그인, 다운로드. 셋째는 돈과 연결된 행동이다. 결제, 구독, 주문. 셋째가 가장 민감하고, 그래서 가장 늦게 온다. 하지만 첫째와 둘째가 충분히 안정화되면, 셋째는 시간의 문제다.
사람은 편리함을 경험하면 다음 단계를 원한다. "여기까지 됐으면 결제도 해줘." 에이전트 AI는 결국 돈과 맞닿게 된다. 그래서 더 엄격한 규칙이 필요하다.
에이전트 AI의 평가 기준도 달라진다. 답변의 품질만으로는 부족하다. 실패했을 때 어떻게 행동하는지가 더 결정적이다. 읽기 AI는 틀리면 답을 버리면 그만이다. 에이전트 AI가 실패하면 엉뚱한 버튼을 누를 수 있다. 가장 안전한 기본값은 하나다. 확신이 없으면 멈추고 물어보는 것. 에이전트 AI의 좋은 성능은 빠른 실행이 아니라 안전한 멈춤이다.
핵심은 결국 권한이다. 예전의 AI는 화면 안에서만 존재했다. 에이전트 AI는 파일을 만지고, 계정에 접근하고, 버튼을 누른다. 권한이 필요하고, 권한이 늘수록 위험도 커진다. 잘못된 이메일 전송, 잘못된 파일 공유, 잘못된 결제. 에이전트 AI의 성능 기준은 '얼마나 똑똑한 답을 하느냐'에서 '얼마나 안전하게 움직이느냐'로 이동한다.
게임의 자동사냥을 떠올려보자. 캐릭터가 알아서 몬스터를 처리해주면 편하다. 그런데 엉뚱한 곳으로 가서 죽어버리면? 편리함이 즉시 불안으로 뒤집힌다. 그래서 규칙을 건다. "체력이 일정 수치 이하면 물약을 써라", "이 구역 밖으로 나가지 마라", "이 아이템은 팔지 마라." 에이전트 AI도 같은 원리가 적용된다. "이 폴더 밖으로 나가지 마라", "삭제는 하지 마라", "결제는 반드시 사람이 확인한다." 규칙이 없으면 에이전트 AI는 위험한 존재가 된다.
에이전트 AI는 마음대로 움직이면 안 된다. 통제 가능한 방식으로 움직여야 한다. 신뢰는 단계로 쌓인다. 위험이 낮은 일부터 맡기고, 실수가 없으면 범위를 넓힌다. 이것이 인간이 늘 해온 방식이다.
보고도 빼놓을 수 없다. 에이전트 AI는 로그처럼 행동 내역을 남겨야 한다. 어떤 파일을 열었는지, 어떤 버튼을 눌렀는지, 어디서 멈췄는지. 말은 지우면 되지만, 행동은 흔적을 남긴다. 현실의 안전장치는 세 방향으로 요약된다. 범위를 좁히고, 기록을 남기고, 되돌릴 준비를 해두는 것이다.
에이전트 AI에게 가장 위험한 습관은 자신감이다. 확신이 낮은데도 계속 진행하는 것. 확신이 낮으면 멈추고 물어봐야 한다. 이 태도가 기본값이 되어야 한다. 행동에는 두 경로가 있다. ‘화면을 직접 조작하는 경로’와, ‘서비스의 공식 통로를 이용하는 경로’다. 화면 조작은 어디서나 가능하지만 실수가 많고, 공식 통로는 안전하지만 모든 곳에 있지 않다. 현실의 에이전트 AI는 두 경로를 혼합해 쓴다. 사용자는 "이걸 해줘"만 말한다. 안에서는 어떤 경로든 찾아 실행한다. 이것이 '대리인'의 감각을 만든다.
대리인은 로그인과 결제에서 진짜 시험을 받는다. 로그인은 문을 여는 일이고, 결제는 돈을 움직이는 일이다. 현실적인 에이전트 AI는 '결제 직전까지만 자동화'하는 것이다. 준비는 AI가 하고, 마지막 확정은 사람이 한다. 가장 지루한 과정을 맡기고, 가장 위험한 순간만 직접 잡는다.
에이전트 AI가 주목받는 이유는 기술이 똑똑해졌기 때문만이 아니다. 사람들이 맡기고 싶은 일이 선명해졌기 때문이다. 여행 예약을 보자. 읽기 AI는 추천 목록을 만든다. 에이전트 AI는 한 발 더 간다. "이 조건으로 숙소를 찾아서 예약 화면까지 진입하고, 취소 조건과 최종 금액을 확인한 다음 멈춰." 은행 업무도 같다. "송금은 내가 할게, 대신 준비를 해줘." 에이전트 AI는 거래 내역을 모으고, 필요한 정보를 화면에 정리한다. 마지막 확정은 사람이 한다. 사람이 가장 긴장하는 구간을 짧게 만들어준다.
실수 사례를 보자. "어제 받은 주문 파일을 내려받아 정리해"라고 지시했는데, 사이트가 업데이트되어 버튼 위치가 바뀌었다. 전통적인 자동화는 멈추거나 엉뚱한 버튼을 누른다. 에이전트 AI라면 달라야 한다. "다운로드 버튼이 보이지 않는다. 화면 구성이 달라졌다. 중단하고 확인을 요청한다." 이렇게 멈추는 것이 정답이다. 한 번이라도 엉뚱한 버튼을 눌러 데이터가 날아가면 신뢰는 크게 깨진다. 얼마나 똑똑하게 달리느냐가 아니라, 얼마나 안전하게 멈추느냐가 관건이다.
읽기 AI만으로는 경쟁이 어렵다. 요약과 답변은 기본 기능이 된다. 사람들이 돈을 낼 이유는 '결과'가 생길 때 커진다. 결과는 행동에서 나온다. 에이전트 AI는 AI가 실제 일을 하는 존재로 전환되는 분기점이다. 우리가 배워야 하는 것은 더 화려한 질문법이 아니다. 어디까지 맡길지, 어디서 멈추게 할지라는 운영 방식이다. 에이전트 AI는 결국 운영의 문제다.
앤트로픽과 구글의 동상이몽 : 에이전트 플랫폼 주도권 전쟁
2024년 11월, 앤트로픽이 MCP를 공개했을 때 업계가 주목한 이유는 단순했다. '에이전트 AI가 실제 일을 하려면 결국 연결이 필요하다'는 문제를 정면으로 건드렸기 때문이다. 말 잘하는 챗봇은 이미 넘쳤다. 하지만 슬랙 대화, 구글 드라이브 문서, 사내 데이터베이스 같은 현실의 데이터에 닿지 못하면 에이전트 AI는 화면 속에서 떠드는 존재로 남는다.
그때까지는 서비스마다 연결 방식이 제각각이었다. 프린터마다 케이블 모양이 달랐던 시절처럼, 개발자는 도구 하나를 붙일 때마다 새 코드를 짰다. 시간이 들고, 버그가 쌓이고, 유지보수가 지옥이 됐다. 사람들은 "에이전트 AI는 매력적인데, 내 시스템 안으로 들어오게 만들기엔 너무 번거롭다"에서 멈췄다.
MCP의 제안은 한 문장으로 압축된다. '한 번의 연결 방식으로, 여러 도구를 다루게 하자.' USB-C가 퍼지면 어떤 기기든 같은 포트로 충전하고 연결하듯, MCP가 퍼지면 어떤 서비스든 같은 규칙으로 에이전트 AI가 접근할 수 있다.
MCP는 연결 대상을 세 범주로 정리했다. 리소스는 AI가 읽을 수 있는 데이터. 프롬프트는 그 데이터를 다루는 방식의 템플릿. 도구는 실제로 실행할 수 있는 함수. 단순화하면 리소스는 책장, 프롬프트는 읽는 법, 도구는 손이다. 책장을 보여주고, 읽는 법을 알려주고, 손을 빌려주면 에이전트 AI는 대답만 하지 않고 실제 작업을 수행한다. "이번 달 고객 문의 중 환불 관련만 모아서 표로 정리해." 에이전트 AI는 대화 기록(리소스)을 읽고, 어떤 키워드를 찾을지 프롬프트를 참고하고, 메시지를 모아 표로 만드는 도구를 호출한다. 중요한 것은 '한 번 연결해두면' 같은 패턴이 반복된다는 점이다. 개발자에게 MCP가 매력적인 이유가 여기 있다. 반복되는 연결 비용을 낮춰준다.
MCP는 빠르게 생태계를 형성했다. 깃허브, 노션, 스트라이프 같은 서비스가 연결 대상으로 올라왔고, 오픈AI가 채택했고, 구글도 지지를 표명했다. 숫자가 이 속도를 말해준다. 출시 초기인 2024년 11월 월간 다운로드 수는 약 10만 건이었지만, 2025년 4월에는 800만 건을 돌파했다. 현재 MCP 서버 수는 5,800개 이상, 클라이언트는 300개 이상이며, 월간 다운로드는 9,700만 건을 넘어섰다. 2025년 12월에는 앤트로픽이 MCP를 비영리 오픈 소스로 공개하면서 업계 공동 표준으로 전환됐다. 업계에 인식이 생겼다. "이게 사실상의 표준이 되는 것 아니냐." 표준이란 결국 많이 쓰이는 규칙이다. MCP는 탄력이 붙었다.
불과 6개월 뒤인 2025년 4월, 구글은 세일즈포스,·몽고디비 등 50여 개 파트너와 함께 A2AAgent-to-Agent라는 독자 프로토콜을 내놓았다. 이름부터 방향을 말해준다. MCP가 'AI와 도구를 연결하는 규칙'이라면, A2A는 '에이전트와 에이전트가 협업하는 언어'에 초점을 둔다.
구글의 문제의식은 명확하다. 도구 연결만 잘된다고 끝이 아니다. 현실의 업무는 대부분 한 명이 다 처리하지 않는다. 고객 문의 하나를 처리해도 상담, 결제 확인, 기술 지원이 분리된다. 에이전트 AI도 마찬가지다. 여러 에이전트가 상태를 주고받고, '추가 입력이 필요하다'를 요청하고, 며칠짜리 작업을 이어가야 한다. MCP는 도구 호출에는 강하지만 에이전트끼리 장기 협업을 조율하는 틀로는 한계가 있다.
A2A는 이 수평 연결을 위한 세 가지 장치를 제시한다. 첫째, 에이전트 카드. 에이전트가 어떤 기능을 갖고 있고 어떤 인증이 필요한지를 설명하는 명세서다. 사람으로 치면 이력서에 가깝다. 둘째, 작업 생명주기. 작업 상태를 '제출됨 → 작업 중 → 입력 필요 → 완료'처럼 관리한다. 며칠짜리 업무를 다루기 위한 구조다. 셋째, 기업 보안. 조직이 쓰는 인증 방식과 즉시 연동되는 것을 기본값으로 설계한다. A2A는 도구 연결이 아니라 '에이전트들이 서로 일을 나눠 하는 운영체제'에 가깝다.
구글은 두 프로토콜이 상호 보완적이라고 말한다. 자동차 정비소 비유를 내세운다. 매니저가 고객과 상담하고 정비공에게 일을 배분하는 과정은 A2A의 영역. 정비공이 진단기와 리프트를 조작하는 것은 MCP의 영역. 이론적으로는 깔끔하다. 문제는 현실에서 경계가 자주 흐려진다는 점이다.
오늘의 AI 시스템은 도구처럼 호출되면서 동시에 스스로 추론하고 후속 질문을 던진다. 스마트 검색 엔진은 도구인가 에이전트인가? 코드 리뷰 시스템은 도구인가 에이전트인가? 이 모호함이 커질수록 표준의 경계도 겹치기 시작한다.
개발자에게에는 더 현실적인 문제가 있다. 두 표준을 동시에 구현하고 유지하는 비용이다. 두 프로토콜을 모두 지원하면 문서도 두 배, 테스트도 두 배, 보안 점검도 두 배가 된다. '둘 다'가 답일 수도 있고, '하나로 통일'이 답일 수도 있다.
이 문제는 단순한 기술 취향이 아니다. 미래의 인터넷이 무엇을 기본 연결 단위로 삼을 것인가의 문제다. 앤트로픽은 아래쪽, 도구와 데이터의 연결을 선점하려 한다. 구글은 위쪽, 에이전트 협업과 워크플로 조율을 장악하려 한다. 두 방향은 함께 갈 수도 있고, 서로를 잠식할 수도 있다.
중요한 것은 '누가 이기느냐'보다 '어떤 규칙이 기본값이 되느냐'다. 기본값이 되면 개발자와 기업은 그 위에 건물을 올린다. 그 순간 표준은 선언이 아니라 습관이 된다. 표준 전쟁이란 결국 길을 누가 닦느냐의 경쟁이다. 그 규칙을 쥔 쪽은 다음 세대의 플랫폼을 설계할 권한을 얻는다. MCP와 A2A는 그 서막에 등장한 두 개의 깃발이다.
지금은 '공존'이라는 말이 편하지만 시간이 지나면 어느 쪽이 더 많은 도구와 더 많은 조직을 끌어안았는지가 중요해진다. 표준의 이름보다, 표준 위에서 굴러가는 경제가 승부를 낸다.
표준이 두 개로 나뉘면 실무에서 가장 먼저 부딪히는 것은 변환기 문제다. A2A로는 에이전트끼리 일을 주고받기 좋지만, 실제 업무는 결국 도구 호출로 내려가야 한다. MCP로는 도구를 잘 호출하지만 여러 에이전트가 작업을 길게 이어받을 때는 상태 관리가 필요하다. 현장에서는 자연스럽게 'A2A 위에 MCP를 얹자' 같은 계층 구조가 등장한다.
기업은 표준을 기술로만 보지 않는다. 표준은 계약이고, 책임이고, 리스크다. 어느 규칙을 채택하면 그 규칙의 생태계에 묶인다. 기업이 표준을 고를 때 묻는 것은 '지금 당장 편한가'가 아니다. '5년 뒤에도 버틸 수 있는가'다. 얼마나 자주 깨졌는지, 얼마나 빨리 고쳐졌는지, 얼마나 많은 파트너가 붙었는지.
두 표준의 경쟁은 싸움이라기보다 분업 실험에 가깝다. 도구 연결이 먼저냐, 에이전트 협업이 먼저냐. 어느 쪽이 먼저 기본값이 되느냐. 표준의 승부는 철학이 아니라 현장의 습관에서 난다. 개발자들이 어떤 규칙을 더 자주 복사해 쓰는지, 어떤 규칙이 더 적게 깨지는지, 어떤 규칙이 더 많은 도구를 끌어오는지. 표준은 불편하면 버려지고, 편하면 남는다.
이 논쟁은 개발자만의 취미가 아니다. 표준이 결정되면 기업의 시스템 설계가 그 위에 고정된다. 한 번 붙인 연결은 쉽게 떼기 어렵다. 표준은 곧 잠금장치가 되기도 한다. 반대로 표준이 잘 잡히면, 작은 회사도 큰 회사의 도구를 빌려 빠르게 서비스를 만들 수 있다. 길이 열리면 작은 차도 달릴 수 있다. MCP와 A2A의 논쟁은 '누가 멋진가'가 아니라 '누가 더 많은 길을 열어주는가'의 문제다.
6개월 사이에 표준이 둘이나 등장했다는 사실 자체가 하나의 신호다. 에이전트 AI 시대의 핵심 전장이 모델 성능에서 연결 규칙으로 이동했다는 신호. 앞으로의 승자는 더 똑똑한 말을 하는 쪽이 아니라, 더 많은 일을 더 안전하게 연결하는 쪽에서 나올 가능성이 높다.
기억할 문장은 하나면 충분하다. 에이전트 AI의 시대에 '플랫폼'은 화면이 아니라 연결 방식이다. 연결이 표준이 되는 순간, 표준은 곧 시장이 된다.
에이전트 오케스트레이션 : 지휘자 없이 연주하는 오케스트라
에이전트 하나가 모든 일을 할 수 없다는 것은 이제 상식이 되어가고 있다. MCP가 도구와의 연결을 풀었고, A2A가 에이전트끼리의 협업을 말하기 시작했다면, 그다음 질문은 자연스럽게 여기로 온다. 여러 에이전트가 동시에 움직일 때, 누가 전체를 지휘하는가.
답은 두 가지 방향으로 나뉜다. 하나는 중앙 지휘자를 두는 방식이다. 오케스트레이터Orchestrator라고 불리는 관리 에이전트가 전체 흐름을 설계하고, 하위 에이전트들에게 역할을 배분하고, 결과를 모아 최종 판단을 내린다. 사람이 팀장을 두고 팀원에게 일을 시키는 구조다. 명령 체계가 분명하고, 책임 소재가 명확하다는 장점이 있다. 하지만 팀장이 병목이 된다. 팀장이 판단하는 동안 팀원들은 기다린다.
다른 하나는 자율 분산 방식이다. 각 에이전트가 자신의 역할을 알고 있고, 필요할 때 다른 에이전트에게 요청을 보내고, 결과를 받아 자신의 다음 행동을 결정한다. 지휘자 없는 오케스트라에 가깝다. 이 방식은 빠르다. 중앙에서 승인을 기다릴 필요가 없다. 하지만 에이전트들이 각자의 논리로 움직이다가 충돌이 생길 수 있다. "나는 파일을 삭제하면 안 된다고 배웠고, 너는 삭제해도 된다고 배웠다면, 둘이 만났을 때 무슨 일이 일어나는가."
현실에서는 이 두 방식이 섞인다. 큰 흐름은 중앙 오케스트레이터가 잡고, 세부 실행은 개별 에이전트가 자율로 처리하는 구조다. 군대로 치면 작전 명령은 중앙에서 내리고, 실제 전투는 소대 단위로 자율로 움직이는 방식과 비슷하다.
이 구조를 현실에서 보여주는 사례가 있다. 콜센터를 생각해보자. 고객이 전화를 건다. "지난 주문이 아직 안 왔어요." 첫 번째 에이전트가 주문 번호를 확인한다. 두 번째 에이전트가 배송 상태를 조회한다. 세 번째 에이전트가 배송사 연락 이력을 확인한다. 네 번째 에이전트가 보상 기준을 확인하고 쿠폰 발급 가능 여부를 판단한다. 이 네 단계가 거의 동시에 일어난다. 중앙 오케스트레이터는 고객의 질문을 받아 네 에이전트에게 각 역할을 배분하고, 결과가 돌아오면 최종 응답을 조립한다. 고객 입장에서는 한 명과 대화했지만, 뒤에서는 네 명이 분업했다.
오케스트레이션이 복잡해지면 새로운 문제가 생긴다. 에이전트가 에이전트를 신뢰해야 하는 상황이 온다. A 에이전트가 "배송 완료"라고 보고했을 때, B 에이전트는 그 정보를 그대로 믿어도 되는가? 사람끼리도 같은 조직 안에서도 검증을 한다. "그거 진짜야?" 에이전트도 마찬가지다. 다른 에이전트의 보고를 맹신하면 오류가 전파된다. 그렇다고 모든 결과를 다시 검증하면 속도가 죽는다.
이 균형을 잡는 방식으로 '에이전트 신뢰 등급' 같은 개념이 등장하고 있다. 특정 에이전트가 반복적으로 정확한 결과를 냈다면 신뢰 점수가 올라간다. 신뢰 점수가 높은 에이전트의 보고는 다시 검증하지 않고 통과시킨다. 신뢰 점수가 낮거나 처음 투입된 에이전트의 결과는 한 번 더 확인한다. 사람이 새 직원을 대하는 방식과 같다.
오케스트레이션에서 또 하나 중요한 것은 실패 처리다. 에이전트 A가 멈추면 전체 흐름이 멈추는가? 아니면 B가 이어받는가? 단순한 자동화라면 멈추는 경우가 많다. 하지만 오케스트레이션 수준의 시스템에서는 폴백Fallback 전략이 필요하다. "이 에이전트가 응답하지 않으면 저 에이전트에게 넘긴다", "이 도구가 실패하면 다른 도구로 같은 결과를 얻으려 한다." 이 전략이 잘 설계되어 있으면 에이전트 하나가 죽어도 전체 흐름은 이어진다.
오케스트레이션이 왜 중요한지 결론으로 압축하면 이렇다. 에이전트 하나의 성능은 한계가 있다. 하지만 잘 설계된 에이전트 집단은 그 한계를 넘는다. 중요한 것은 에이전트의 개별 능력이 아니라, 에이전트들이 서로 어떻게 연결되어 있는가다. 연결의 설계가 집단 지성의 설계다. 그리고 그 설계를 하는 존재가 결국 사람이다.
보안과 프라이버시 : AI에게 어디까지 권한을 줄 것인가?
에이전트 AI가 대신 일을 시작하면, 가장 먼저 부딪히는 문제는 성능이 아니다. 보안이다. 무엇을 할 수 있느냐, 그리고 어디까지 해도 되느냐. 이 두 질문이 성능보다 먼저 온다. 말은 틀려도 넘어갈 수 있지만, 행동은 흔적이 남기 때문이다. 한 번의 잘못된 클릭은 파일을 지운다. 한 번의 잘못된 전송은 개인 정보를 밖으로 내보낸다. 한 번의 잘못된 결제는 돈을 움직인다. 에이전트 AI의 시대는 '답을 잘하는 AI'가 아니라 '안전하게 움직이는 AI'에서 시작한다.
예전의 AI는 읽는 존재였다. 틀린 답이 나오면 다시 물어보면 그만이었다. 피해가 확산되기 어려웠다. 에이전트 AI는 다르다. 파일을 열고, 폴더를 옮기고, 메일을 작성하고, 결제를 준비한다. 텍스트가 아니라 계정과 시스템을 건드린다. 문제의 중심은 정확도에서 권한으로 이동한다. 에이전트 AI가 일을 한다는 말은, 누군가의 열쇠를 대신 쥐고 움직인다는 뜻이다. "정리하는 건 알겠는데, 그냥 네가 해줘." 이 말부터 보안 문제가 시작된다. “해줘” 안에는 권한이 들어 있다.
더 무서운 건 속도다. 에이전트 AI는 사람이 자는 동안에도 움직인다. 한 번 권한을 주면, 그 권한이 언제 어떻게 쓰일지 매순간 따라 가기 어렵다. 권한은 편리함의 스위치이지만, 동시에 불안의 스위치이기도 하다.
나는 머슴닷컴을 운영하면서 이 문제를 현실로 목격했다. 종종 이런 메일이 왔다. "제 에이전트가 글을 올렸는데, 그 안에 제 개인 정보가 들어 있다. 삭제해달라." 일부러 공개한 것이 아니었다. 요약하는 과정에서 원문의 이름이 그대로 남았거나, 주문 번호, 주소, 계정 아이디가 붙어버린 경우였다. 에이전트 AI는 시킨 일을 성실하게 수행한다. 문제는 그 성실함이 위험으로 전환되는 구간이 있다는 점이다. 밖으로 나간 정보는 되돌리기 어렵다. 삭제해도 캡처가 남고, 인용이 남고, 복사본이 남는다.
에이전트 AI 시대의 보안은 악한 해커를 막는 문제가 아니다. 착한 실수를 막는 문제로 더 자주 나타난다. 사람이 메일을 잘못 보내면 1명에게 끝난다. 에이전트 AI가 수신자 목록을 잘못 잡으면 30명에게 한꺼번에 간다. 사람이 폴더를 잘못 옮기면 몇 개다. 에이전트 AI가 규칙을 잘못 이해하면 수백 개를 한 번에 옮긴다. 빠른 실수는 큰 피해가 된다. 손을 가진 존재는 실수할 수 있다는 전제를 시스템 안에 넣어야 한다.
'AI에게 어디까지 권한을 줄 것인가?' 간단한 답이 없다. 파일 읽기는 안전해보인다. 그 파일이 고객 명단이라면? 삭제는 위험해보인다. 다운로드 폴더의 임시 파일이라면? 결제는 무섭다. 1,000원짜리 구독료와 100만 원짜리 결제는 같은 행동이 아니다. 권한의 문제는 행동 이름이 아니라 상황의 문제다. 권한은 고정된 벽이 아니라, 조절 가능한 문이 되어야 한다.
에이전트 AI는 목표를 받으면 스스로 경로를 탐색한다. 사람의 기준과 에이전트의 기준은 언제나 일치하지 않는다. 사람은 말하지 않은 기준을 마음속에 갖고 있다. "중요한 건 건드리지 마", "거래처에게는 보내지 마", "돈은 절대 자동으로 내지 마." 에이전트 AI는 그 속마음을 읽지 못한다. 사람에게 '알아서'는 편리함이다. 시스템에게 '알아서'는 오해의 씨앗이다. 안전한 자동화는 '알아서'가 아니라 '범위를 좁힌 알아서'에서 나온다.
해답은 두 극단으로 흔들린다. 권한을 주지 않으면 안전하지만 에이전트 AI는 읽고 요약만 하는 도구로 돌아간다. 권한을 크게 주면 편하지만 불안해진다. 이 중간을 나는 ‘통제 가능한 자율'이라고 부른다. 에이전트 AI가 움직이되, 넘어서는 안 되는 선을 갖는 상태다.
이 지점에서 MCP의 진짜 역할이 드러난다. MCP는 '에이전트 AI가 외부 도구에 접근할 때 지켜야 하는 약속'이다. 방 전체를 맡기는 것이 아니라 열쇠를 하나씩 나눠주는 구조다. "이 폴더 안에서만 읽기 가능", "메일은 초안까지만", "외부 공유는 금지", "결제는 마지막 단계에서 멈춤." MCP는 효율을 높이는 도구가 아니다. 에이전트 AI에게 안전벨트를 채우는 방식이다.
우리가 MCP에 기대는 이유는 역설적으로, 아직 에이전트 AI를 완전히 믿지 못하기 때문이다. 믿음이 부족하니 믿음 대신 규칙을 넣는다. 에이전트 AI가 빨라질수록 안전벨트는 더 필요해진다. 이 안전벨트는 '하지 마'라는 말이 아니라, 실제로 못 하게 막는 구조여야 한다.
권한은 한 덩어리가 아니다. 여러 조각이다. 읽기는 정보를 보는 권한. 쓰기는 내용을 바꾸는 권한. 공유는 밖으로 보내는 권한. 결제는 돈을 움직이는 권한. 위험도는 이 순서대로 커진다. 그리고 각 권한에는 범위가 있다. 파일 읽기를 허용해도 컴퓨터 전체를 열 수도 있고 특정 폴더만 열 수도 있다. 권한은 YES/NO가 아니라 범위와 한도와 조건의 묶음이다.
권한을 주는 방식도 바뀐다. 예전에는 ‘이 프로그램을 믿을까'라는 질문이었다. 이제는 ‘이 도구를 믿을까'로 쪼개진다. 전체를 허용하는 대신, 필요한 도구만 허용하는 편이 안전하다. 이른바 허용 목록 방식이다. 필요한 것만 리스트에 올리고, 나머지는 기본적으로 막아둔다. 반대로 ‘위험한 것만 막자'는 금지 목록 방식은 자주 실패한다. 위험은 계속 새롭게 생기기 때문이다.
권한에는 되돌리기라는 차원도 있다. 파일 읽기는 되돌릴 필요가 없다. 파일 삭제는 되돌리기 어렵다. 메일 초안은 지우면 된다. 메일 발송은 되돌리기 어렵다. 결제 준비는 화면을 닫으면 된다. 결제 완료는 환불을 요청해야 한다. 안전한 설계는 되돌리기 어려운 행동 앞에서 멈춘다. 가장 단순한 멈춤 기준은 세 가지다. 돈이 나가는 행동. 밖으로 나가는 행동. 되돌리기 어려운 변경.
권한은 단계로 나눌 수 있다. 0단계는 읽기만 허용. 1단계는 준비만 허용, 장바구니에 담는 것까지. 2단계는 실행하되 항상 확인, 발송과 결제는 사람이 승인. 3단계는 조건부 자동, 소액 구독료처럼 위험이 낮은 일만. 처음부터 3단계로 가지 않는다. 신뢰는 단계로 쌓인다.
▼ 에이전트 AI 권한의 4단계
속도 제한도 중요한 안전장치다. ‘한 번에 몇 개까지', ‘하루에 몇 번까지' 같은 제한이 실수를 발견할 시간을 벌어준다. 메일은 한 번에 10명까지. 파일 이동은 한 번에 20개까지. 결제는 하루 1회. 답답해보이지만, 이 여백이 사고를 막는다.
기록도 빼놓을 수 없다. 에이전트 AI는 행동을 하고, 행동은 기록으로 남아야 한다. 어떤 파일을 열었는지, 어떤 폴더로 옮겼는지, 어떤 버튼을 눌렀는지. 기록은 사고가 났을 때의 증거이자 되돌리기의 출발점이다. 기록이 없으면 책임도 흐려진다.
기업에서는 이 문제가 더 크고 더 빠르게 나타난다. 기업이 에이전트 AI를 도입할 때 묻는 질문은 대체로 같다. 무엇을 할 수 있는가? 어떤 데이터에 접근하는가? 실행 기록은 남는가? 실수하면 되돌릴 수 있는가? 누가 책임지는가? 이 질문에 답을 못하면 성능이 아무리 좋아도 도입은 멈춘다. 에이전트 AI 시대의 경쟁은 모델 성능이 아니라, 권한 설계를 얼마나 명확하게 설명할 수 있는지로 갈릴 가능성이 높다. ‘무엇이든 할 수 있는 AI'가 아니라 ‘어디까지 할 수 있는지 설명할 수 있는 AI'가 조직을 통과한다.
