인사이트 / 블로그

AI 에이전트 시리즈 · 5/6

AI가 실행을 맡기 시작하면, 인터페이스의 기준도 달라집니다

지난 글에서는 AI 에이전트의 메모리를 다뤘습니다.

좋은 메모리는 과거 대화를 오래 저장하는 기능이 아니라, 무엇을 남기고 무엇을 갱신하고 무엇을 더 이상 쓰지 않을지 정하는 운영 기준에 가깝다고 정리했습니다.

Agent가 기억한 맥락은 실제로 어디에서 쓰일까요?

결국 앱, 문서, 브라우저, 사내 시스템, 결제 화면, 승인 절차 같은 실제 업무 환경 위에서 쓰입니다. 어떤 정보는 화면을 보고 확인해야 하고, 어떤 정보는 도구로 바로 호출할 수 있어야 하며, 어떤 순간에는 사람이 멈춰서 검증해야 합니다.

AI가 실행을 맡으면, 화면은 사라질까요?

화면이 곧 사라진다는 뜻은 아닙니다.

하지만 질문을 여기서 멈추면 중요한 지점을 놓칩니다. 핵심은 화면의 생존 여부가 아니라, 실행 주체가 사람에서 Agent로 이동할 때 업무 시스템을 어떤 구조로 다시 설계해야 하는가입니다.

우리는 왜 아직도 클릭하고 있는가

"가장 빠른 경로를 알려줘"라고 요청했는데, 사용자가 여전히 앱을 열고, 검색창을 클릭하고, 출발지와 목적지를 입력하고, 결과를 비교하고, 마지막 경로를 직접 선택해야 한다고 해 보겠습니다.

답변은 도와줬지만, 실행은 여전히 사람이 맡았습니다.

이런 장면은 길 찾기에만 있는 것이 아닙니다. 승인 요청, 예약 변경, 비용 정산, 문서 업로드에서도 비슷한 절차가 반복됩니다. 사람은 화면을 열고, 항목을 찾고, 값을 입력하고, 결과를 비교하고, 마지막 버튼을 누릅니다.

그동안 우리는 이 절차를 너무 자연스럽게 받아들였습니다. 컴퓨터를 쓴다는 것은 곧 화면을 보고 조작하는 일이라고 생각했기 때문입니다.

Agent가 실행을 맡기 시작하면 기준이 달라집니다.

정말 모든 실행이 사람용 화면을 거쳐야 할까요?

사람에게 편한 화면이 Agent에게도 좋은 실행 접점일까요?

화면은 사람에게 맞춰진 인터페이스였습니다

인터페이스의 역사는 사람의 부담을 줄이는 방향으로 움직여 왔습니다.

명령어를 정확히 입력해야 하던 시기에는 사람이 컴퓨터의 언어에 맞춰야 했습니다. 그래픽 화면은 사람의 시각과 움직임에 맞춰졌고, 터치와 음성은 더 자연스러운 행동을 받아들였습니다. 언어 기반 인터페이스는 사용자의 의도 자체를 입력으로 받기 시작했습니다.

"이제 Agent가 화면을 보고 클릭하면 되는 것 아닌가?"

어느 정도는 맞습니다. Agent가 사람처럼 화면을 보고 버튼을 찾는 방식은 기존 소프트웨어를 그대로 활용할 수 있다는 장점이 있습니다.

하지만 이것은 본질적으로 사람용 인터페이스를 우회해서 쓰는 방식입니다.

사람은 버튼의 위치나 화면의 의미를 대략적으로 이해할 수 있습니다. 반면 Agent는 화면을 이미지나 구조 정보로 읽고, 좌표나 요소를 추정하고, 다음 행동을 계산해야 합니다. 화면이 조금 바뀌거나 비슷한 버튼이 여러 개 있으면 실행은 쉽게 흔들릴 수 있습니다.

사람에게 자연스러운 화면이 Agent에게도 가장 효율적인 인터페이스라고 말하기는 어렵습니다.

Agent는 화면을 볼 수도 있고, 도구를 호출할 수도 있습니다

Agent의 실행 방식은 크게 두 갈래입니다.

하나는 GUI Agent 방식입니다.

GUI Agent는 사람용 화면을 봅니다. 화면을 캡처하거나 구조를 읽고, 어느 버튼을 눌러야 하는지 판단한 뒤 클릭하거나 입력합니다. 사람이 하던 절차를 Agent가 따라 하는 방식에 가깝습니다.

이 방식의 장점은 호환성입니다. 화면만 있으면 기존 업무 환경을 크게 바꾸지 않고도 접근할 수 있습니다. 하지만 화면 인식에는 비용과 시간이 들고, 클릭 위치가 어긋나거나 화면 구성이 바뀌면 실패할 수 있습니다. 결제, 삭제, 승인처럼 되돌리기 어려운 행동에서는 작은 오해도 큰 문제가 됩니다.

반대로 API Agent는 화면보다 도구의 형식을 봅니다.

도구의 이름과 입력값, 결과 형식을 보고 호출합니다. 사람이 "검색창을 클릭하고 값을 넣는" 대신, Agent가 "이 도구에 이 값을 넣어 호출한다"는 식으로 실행합니다.

이 방식은 화면을 흉내 내지 않습니다. 실행에 필요한 기능이 구조화되어 있고, Agent가 그 기능을 호출할 수 있을 때 힘을 발휘합니다.

그래서 GUI Agent와 API Agent의 차이는 단순한 구현 방식의 차이가 아닙니다. Agent가 세상을 무엇으로 인식하느냐의 차이입니다.

하나는 화면을 봅니다. 다른 하나는 호출 가능한 도구를 봅니다. 하나는 사람의 행동을 따라 하고, 다른 하나는 실행 기능을 직접 부릅니다.

중요한 것은 어느 쪽이 무조건 낫다는 결론이 아닙니다. 업무마다 일이 처리되는 경로가 다릅니다.

모호한 결과를 둘러봐야 하거나, 사용자가 직접 확인해야 하는 화면이라면 GUI가 필요합니다. 반대로 입력값과 결과가 명확한 반복 업무라면 구조화된 도구 호출이 더 적합할 수 있습니다.

도식 1. 같은 요청, 두 가지 실행 경로

도구를 호출하려면 표준이 필요합니다

AI가 실행을 맡는다는 말은 "사람의 클릭 절차를 Agent가 그대로 따라 한다"로 끝나지 않습니다.

여기서부터 질문이 조금 달라집니다.

Agent가 호출할 수 있도록 업무 도구가 정리되어 있는가?

예를 들어 비용 정산에서 영수증 조회, 계정 분류, 승인 요청, 처리 결과 확인이 각각 호출 가능한 도구로 열려 있다면 실행 방식이 달라집니다. Agent는 화면을 순서대로 클릭하는 대신, 필요한 도구를 고르고 결과를 받아 다음 단계를 판단할 수 있습니다.

이때 MCP(Model Context Protocol) 같은 도구 연결 표준이 의미를 가집니다.

MCP는 모델과 외부 도구를 연결하는 표준 방식 중 하나입니다. 비개발자 관점에서는 "Agent가 어떤 도구를 어떤 형식으로 볼 수 있고, 어떻게 호출할 수 있는지 정리해 주는 연결 규칙" 정도로 이해하면 충분합니다.

물론 연결 표준을 도입하는 것만으로 모든 문제가 해결되는 것은 아닙니다.

도구가 무엇을 할 수 있는지 설명되어 있어야 합니다. 입력값과 결과 형식이 안정적이어야 합니다. 잘못된 호출을 막는 권한도 필요합니다. 실행 결과를 사람이 확인할 방법도 있어야 합니다.

화면을 덜 보게 된다는 말은, 그만큼 화면 뒤의 도구가 호출 가능한 구조로 정리되어야 한다는 뜻입니다.

연결만으로는 부족합니다

도구를 연결했다고 해서 곧바로 업무용 Agent가 되는 것은 아닙니다.

Agent가 메일, 파일, 일정, 결제, 고객 정보, 내부 시스템에 접근할 수 있다고 생각해 보겠습니다. 이때 필요한 것은 단순한 연결 목록이 아닙니다.

누가 어떤 권한으로 무엇을 실행했는지 남아야 합니다. 실수했을 때 멈추거나 되돌릴 수 있어야 합니다. 여러 Agent가 동시에 움직일 때 서로의 맥락과 자원을 침범하지 않아야 합니다.

이 지점에서 AIOS라는 개념이 등장합니다.

AIOS를 당장 기존 운영체제를 대체할 무언가로 볼 필요는 없습니다. 대외적으로는 "Agent 실행을 관리하기 위한 운영 계층" 정도로 보는 편이 정확합니다.

사람이 컴퓨터를 쓸 때 운영체제는 앱 실행, 권한, 파일 접근, 기록 같은 일을 맡습니다. Agent가 여러 도구를 호출하고 여러 작업을 동시에 처리하려면 비슷한 운영 문제가 생깁니다.

어떤 Agent가 어떤 도구를 쓸 수 있는지, 어떤 데이터에 접근할 수 있는지, 실행 과정은 어디까지 기록되는지, 위험한 행동 앞에서는 누가 멈추는지 정해야 합니다.

이 질문을 다루지 않고 "도구를 연결했다"에서 멈추면, Agent는 편리한 자동화가 아니라 통제하기 어려운 실행 주체가 될 수 있습니다.

Agent에게 권한이 생길수록 기록, 검증, 되돌리기 구조가 중요해집니다.

도식 2. Agent 실행 구조와 사람 검증 접점

그래서 화면은 어디에 남는가

이제 처음 질문으로 돌아와 보겠습니다.

AI가 실행을 맡으면, 화면은 사라질까요?

아닙니다.

다만 화면의 역할은 바뀝니다.

지금까지 화면은 사람이 항상 조작하는 주연에 가까웠습니다. 사용자는 화면을 열고, 찾고, 누르고, 입력하고, 비교하고, 선택했습니다.

Agent 시대의 화면은 사라지기보다, 쓰임이 달라집니다.

먼저 검증입니다. Agent가 처리한 결과가 맞는지, 중요한 조건이 빠지지 않았는지 확인해야 하는 순간이 있습니다.

그 다음은 탐색입니다. 사용자가 무엇을 원하는지 아직 모호하거나, 여러 대안을 둘러봐야 하는 경우에는 화면이 필요합니다.

마지막으로 조정입니다. 디자인, 문서 편집, 보고서 구성처럼 결과물을 미세하게 다듬는 일은 화면 위에서 이루어집니다.

따라서 화면은 없어지는 것이 아닙니다.

항상 조작하는 장소에서, 필요할 때 호출되는 검증·탐색·조정의 접점으로 이동합니다.

이제 화면을 먼저 만들고 사람이 클릭하게 할 것인지, 도구를 먼저 정리하고 Agent가 호출하게 할 것인지, 어떤 순간에 사람에게 화면을 보여 줄 것인지 결정해야 합니다.

도입 전에 물어봐야 할 질문

업무용 Agent를 도입할 때 "AI가 이 일을 대신할 수 있는가"라고만 물으면 부족합니다.

첫째, 이 업무는 화면 조작이 필요한가, 구조화된 도구 호출로 충분한가?

둘째, 호출 가능한 도구가 있다면 입력값과 결과 형식이 정리되어 있는가?

셋째, 모델과 도구를 잇는 연결 규칙이 있는가?

넷째, Agent가 볼 수 있는 것과 볼 수 없는 것이 구분되어 있는가?

다섯째, 비가역 행동 앞에서 사람이 확인하는 절차가 있는가?

여섯째, 실행 결과를 사람이 검증할 수 있는 화면과 기록, 되돌리기 절차가 있는가?

도식 3. 업무별 실행 접점 결정 매트릭스

이 질문들에 답해야 화면 설계도 달라집니다. 모든 과정을 보여 줄 필요는 없지만, 사람이 봐야 할 순간은 더 정확히 설계해야 합니다.

실행 구조가 바뀌면 사람의 역할도 바뀝니다

Agent가 실행을 맡는다는 말은 사람이 빠진다는 뜻이 아닙니다.

사람의 역할이 바뀐다는 뜻에 가깝습니다. 사람은 모든 클릭을 직접 수행하는 조작자에서, 의도를 정하고, 권한을 부여하고, 결과를 검증하는 역할로 이동합니다.

그래서 좋은 Agent 인터페이스는 화면을 없애는 인터페이스가 아닙니다.

사람이 매번 클릭하지 않아도 되게 하면서, 중요한 순간에는 사람이 정확히 볼 수 있게 만드는 인터페이스입니다.

도구는 Agent가 호출할 수 있어야 하지만, 권한은 좁고 명확해야 합니다. 실행 기록과 복구 절차도 함께 남아야 하고, 화면은 사람이 확인해야 할 순간에 나타나야 합니다.

결국 화면의 미래를 묻는 질문은 Agent 실행 구조의 질문입니다.

AI가 실행을 맡으려면 GUI, 도구 호출 표준, 운영 계층, 사람 검증 접점이 함께 설계되어야 합니다.

다음 질문은 여기서 이어집니다.

Agent가 화면과 도구를 통해 실행을 맡기 시작하면, 이제 문제는 실행 방식에서 행동 방식으로 옮겨갑니다.

AI는 언제 말하고, 언제 기다리고, 언제 사람에게 넘겨야 할까요?

다음 글에서는 사람과 Agent가 함께 대화하고 협업할 때 필요한 행동 기준을 살펴보겠습니다.

AI 에이전트 시리즈