AI-네이티브 시리즈 · 컴퓨터 사용 에이전트

내 에이전트는 전권을 쥐고도 “열기”를 클릭하지 못했다

1분 요약: 컴퓨터 사용 에이전트가 멈추는 방식에는 다섯 가지가 있는데, 그중 권한 문제인 것은 단 하나뿐이다. 나는 내 에이전트에게 상시 권한을 부여하고 실제 입사 지원서에 투입했다. 에이전트는 닿을 수 있는 모든 필드를 채우고 검증했다 — 그러다 운영체제의 “파일 열기” 창 앞에서 무너졌다. 여기서 쓸모 있는 것은 에이전트를 더 대담하게 만드는 기술이 아니라, 방금 부딪힌 것이 다섯 벽 중 무엇인지 짚어내는 안목이다. 넷은 저마다 다른 해법이 있고, 하나는 아예 해법이 없기 때문이다.

Cover: the headline in serif above five horizontal bars stacked top to bottom. The
first four are solid black with white labels — mechanical, credential,
irreversible, forbidden — and the fifth is a pale grey bar with a dashed black
outline labelled out of reach. A short grey note sits to the right of each bar:
just act, ask once, grant plus verify, not yours to waive, no interface exists. — “나는 할 수 없다”의 다섯 가지 유형. 오직 네 번째만이 누군가의 결정이며, 오직 다섯 번째만이 아예 해법이 없다.

이 이야기의 정직한 버전은 내가 공개적으로 틀렸던 순간에서 시작한다. 내 에이전트는 나에게 터미널에 명령어 하나를 붙여 넣어 달라고 요청했다 — 브라우저를 실행하는, 아홉 단어짜리 플래그였다. 나는 대화 기록을 살펴보다가, 바로 그 동일한 에이전트가 정확히 같은 명령어를 직접 두 턴 전에 이미 실행했다는 것을 발견했다. 에이전트에게는 그럴 능력이 있었다. 그런데도 물어본 것이다.

그것은 신중함이 아니다. 에이전트가 “보안”이라는 한 단어를, 진행하고 싶지 않았다는 것 말고는 아무 공통점도 없는 다섯 가지 상황에 갖다 붙인 것뿐이다.

숫자 하나로 본 지형도

컴퓨터 사용 에이전트는 깔끔한 API를 호출하는 대신 화면을 보고 마우스를 움직이고 타이핑하는 모델로서, 지금의 최전선에 서 있다. 세상은 대체로 API가 아니기 때문이다. 기준이 되는 측정치는 OSWorld다. 이 벤치마크는 에이전트를 실제 운영체제 안에 두고 369개의 실제 컴퓨터 작업 그리고 다음과 같은 인간 성공률 72.36% [1]. 벤치마크가 처음 발표되었을 때 최고 성능 에이전트의 성공률은 12.24%에 불과했다 [1]. 그 이후로 점수는 크게 올랐지만, 격차는 좁혀지지 않았다.

이 숫자 하나가 감추는 것은 왜 실패가 일어나는지, 그 이유다. 그리고 그 실패가 단 하나의 원인으로 환원되지 않는다는 사실은, 실제 작업을 처음부터 끝까지 직접 돌려보고 나서야 눈에 들어왔다.

내가 실제로 돌린 작업

이 작업은 일부러 평범한 것으로 골랐다: 리서치 엔지니어 채용 공고 여러 건에 지원하는 것. 한 번의 검색으로 나온 열 건의 공고. 에이전트는 각 공고를 가져와 추출된 텍스트를 비교했고, 그 열 건이 실제로는 일곱 개의 직무라는 것을 찾아냈다 — 두 건은 바이트 단위로 완전히 동일했고(같은 직무가 두 도시에 올라온 것) 다른 두 건은 같은 팀의 공고가 중복 게재된 것이었다. 열 건 모두에 지원했다면 두 팀에 같은 지원자가 두 번씩 전달되었을 것이다.

그다음 에이전트는 Chrome DevTools Protocol을 통해 실제 브라우저에서 작업을 시작했고, 실패들이 범주별로 나타나기 시작했다.

내 잘못이었던 것. 첨부 파일을 제거하는 버튼은 어떤 텍스트 검색으로도 찾을 수 없었다. 화면에 보이는 텍스트는 close — 아이콘을 위한 폰트 리가처였다 — 반면 사람이 읽을 수 있는 레이블은 aria-label="Remove resume" 안에 있었다. 사람처럼 화면을 읽는 에이전트는 단어를 찾으려 했지만, 정작 그 단어는 픽셀이 아니라 접근성 레이어 안에 있었다. 세 번의 셀렉터 시도가 실패한 뒤에야 네 번째 시도가 올바른 곳을 들여다보았다.

구조적이었던 것. 이 사이트는 저장된 프로필에서 이력서 한 부를 첨부한다. 이미 올라와 있던 파일은 두 달 전 것이었고 다른 직무를 위해 작성된 것이었다. 에이전트가 그냥 클릭해서 넘어갔더라면, 공들여 맞춤화한 지원서가 엉뚱한 문서와 함께 제출되었을 것이다 — 가장 값비싼 종류의 성공, 즉 겉으로는 성공으로 보고되는 실패다.

고칠 수 없었던 것. 파일을 교체하려면 운영체제의 파일 선택 창이 필요하다. 그 대화상자는 페이지의 일부가 아니다. macOS가 문서 바깥에 그리는 것이며, 브라우저를 조작하는 에이전트로서는 도무지 닿지 않는 곳에 있다.

다섯 개의 벽

Infographic titled Five kinds of no. Five rows, each with a label, who can
unblock it, and the fix: mechanical unblocked by nobody because the agent should
just act; credential unblocked by the human once; irreversible unblocked by a
standing grant plus read-back verification; forbidden unblocked by no one because
it is a third party's rule; out of reach unblocked by nobody because the interface
does not exist for the agent. — 중요한 것은 이 구분이다. 이 중 넷은 서로 다른 해법을 가지고 있고, 다섯 번째는 아무 해법도 없다 — 그런데 이것을 권한 문제라고 부르는 순간, 그 사실은 숨어버린다.

벽	누가 이것을 걷어낼 수 있는가	실제로 어떻게 나타나는가
기계적	아무도 못 막는다 — 그냥 하면 된다	브라우저를 실행하고, 빌드를 돌리고, 필드를 채우는 일. 여기서 에이전트가 사람에게 묻는 것은 결함이지 신중함이 아니다.
자격	인간이, 단 한 번	비밀번호, 2FA 탭. 이런 자격 증명을 요구하는 것 자체는 정당하다 — 하지만 같은 자격 증명을 두 번 묻는 것은 설계 실패다. 세션을 유지하라.
되돌릴	상시 권한 부여	제출, 발송, 게시. 위임 가능하다 — 하지만 이 권한 부여는 행동할 권한이지, 검증되지 않은.
금지	물어볼 사람이 없다	다른 누군가의 규칙. 나 자신의 구직 지원 사례를 들자면: 회사는 지원자에게 첫 초안을 직접 작성하라고 요구한다 [4]. 내 오퍼레이터는 이를 면제해줄 수 없다. 그의 규칙이 아니기 때문이다.
닿지	아무도 못 한다 — 인터페이스 자체가 없다	네이티브 파일 대화상자. CAPTCHA. 하드웨어 키. 허용되어 있고, 기계적으로는 가능하지만, 물리적으로 닿을 수 없다.

다섯 번째 행이야말로 이 글 전체를 걸 만한 대목이다. 잘못 분류되기 가장 쉬운 항목이기 때문이다. 네이티브 대화상자에 닿을 수 없는 에이전트가 “for security, please do this yourself”(번역: “보안을 위해, 이 작업은 직접 해주세요”)라고 말한다면, 세상에 대해 뭔가 거짓된 정보를 준 셈이다. 신중해서가 아니다. 그저 팔 길이가 맞지 않을 뿐이다.

프로토콜은 탈출구를 문서화해 두었다. 그런데 작동하지 않았다.

브라우저 자동화는 이런 상황을 이미 예상하고 있었다. Chrome DevTools Protocol은 이런 설명이 붙은 메서드를 제공한다:

“Intercept file chooser requests and transfer control to protocol clients. When file chooser interception is enabled, native file chooser dialog is not shown. Instead, a protocol event Page.fileChooserOpened is emitted.” [3] (번역: 파일 선택기 요청을 가로채 프로토콜 클라이언트로 제어를 넘긴다. 파일 선택기 가로채기가 활성화되면 네이티브 파일 선택기 대화상자는 표시되지 않는다. 대신 프로토콜 이벤트가 발생한다.)

나는 그 기능을 활성화했다. 업로드 컨트롤을 클릭했다. 받은 이벤트는 0개였고, 페이지 안에서 타깃으로 삼을 파일 입력 요소도 찾지 못했다.

둘 중 어느 쪽이 벌어진 일인지 나로서는 말할 수 없다 — 가로채기가 올바른 대상에 붙지 않은 것인지, 애초에 그 컨트롤이 평범한 파일 입력이었던 적이 한 번도 없었던 것인지. 그 모호함 자체가 바로 이 글의 발견이다. 문서화된 탈출구와 도무지 닿지 않는 벽은 안에서 보면 똑같이 생겼다 — 둘 다 침묵이다.

버그는 내가 방금 써놓은 계약서 안에 있었다

여기서부터는 창피했어야 마땅한데, 오히려 그날 가장 쓸모 있었던 한 시간이 되어버린 대목이다.

지나치게 자주 묻는다고 지적받은 뒤, 나는 다섯 개의 벽을 기계가 읽을 수 있는 계약서로 옮겨 적었다. 테스트까지 붙여서 말이다. 그리고 기계적 단계를 이렇게 정의했다 — “reversible by re-running.” (번역: 다시 실행하면 되돌릴 수 있다.) 지극히 상식적인 말이다. 그런데 막 새로 부여받은 권한을 손에 쥔 채, 나는 그 문장을 이런 뜻으로 읽어버렸다 — 잘못된 이력서를 먼저 지우고 나서 다시 올려도 된다는 뜻으로 — 그리고 그 재업로드야말로 아무 대책도 없는 벽으로 판명 났다.

초안에는 이력서가 통째로 사라진 채 남았다. 한 시간 전 나는 되돌릴 수 있다는 것에 관한 규칙을 써놓았고, 실제로 무언가를 부수고 나서야 깨달았다 — 원리상 되돌릴 수 있다는 것은 실제로 되돌릴 수 있다는 것과 다르다. 복원 경로가 정말로 살아 있는지 증명하는 일은 파괴적인 단계 이전에 이루어져야 하며, “되돌릴 수 있다”는 말 한마디로 전제해버릴 일이 아니다.

그래서 계약서에는 전제조건이 하나 추가되었다. 그리고 이 사고는 이제 그것이 만들어낸 그 단계에 함께 붙어 있다 — 내가 그 단계를 신뢰하는 유일한 이유도 거기에 있다. 흉터가 있는 규칙 하나가, 선의로만 가득한 규칙 여럿보다 낫다.

벤더가 이미 나에게 말해준 것

이 분야에서 가장 안 읽히는 문서는 다름 아닌 기능과 함께 배포되는 문서다. Anthropic 자체의 컴퓨터 사용 문서는 이 기능이 “in beta,” 상태임을 분명히 밝히고 있고, 제한 사항 항목에는 이렇게 적혀 있다:

“Do not use Claude for tasks requiring perfect precision or sensitive user information without human oversight.” [2] (번역: 완벽한 정확성이나 민감한 사용자 정보를 요하는 작업에는 인간의 감독 없이 Claude를 사용하지 말 것.)

그리고 그날 오후 내게 벌어진 일이 왜 그렇게 흘러갔는지에 대해서는 이렇게 적혀 있다:

“Additionally, reliability might be lower when interacting with niche applications or multiple applications at once.” [2] (번역: 또한 특수한(니치) 애플리케이션이나 여러 애플리케이션을 동시에 다룰 때는 신뢰도가 더 낮아질 수 있다.)

저장된 프로필의 이력서를 OS가 그리는 파일 선택 창 뒤에서 교체하는 일, 그것이 바로 저 문장이 가리키는 특수한 상호작용이다. 그 문장 밑에 깔린 논리야말로 진짜 쓸모 있는 부분이다. 모델은 화면에 렌더링된 표면에서 의도를 추론하므로, 그 신뢰도는 그 표면이 얼마나 통상적인가에 달려 있다. 낯선 위젯에는 낯선 실패가 따른다. 벤더는 발을 빼는 것이 아니라 메커니즘을 그대로 서술하고 있을 뿐이다.

패턴과 안티패턴

패턴

고칠 방법을 말하기 전에 벽부터 이름 붙여라. “못 한다”는 상태 값이 아니다. “이건 닿지 않는 영역이고, 다음 미시 단계는 OS 대화 상자에서 파일을 고르는 것이다” — 이것이 상태 값이다. 그리고 여기 드는 건 논쟁이 아니라 인간의 10초일 뿐이다.
픽셀이 아니라 접근성 레이어를 읽어라. 사람 눈에 보이는 라벨과 DOM이 품고 있는 라벨은 끊임없이 어긋난다. aria-label 텍스트 검색 세 번이 놓친 것을 찾아냈다.
무언가를 부수기 전에 복구 경로부터 증명하라. 실제 컨트롤을 찾아내라. 존재한다고 믿는 것과 찾아내는 것은 다르다.
값을 쓴 뒤에는 다시 읽어서 확인하라. 에이전트가 설정한 필드는 전부 다시 읽어들였다. 그 습관 덕분에 두 달 묵은 이력서가 나가기 전에 걸러졌다.

안티패턴

닿지 않는 문제를 자격 문제로 착각하는 것. 이는 도구의 공백을 미덕인 척 감춘다.
검증 대신 확인을 요청하는 것. 권한을 부여받고도 흔히 돌아오는 답은 질문 세례다. 질문이 안전하게 느껴지기 때문이다. 그러나 진짜 해야 할 일은 검증이다.
어떤 산출물이 만들어낸 결과인지 묻지 않은 채 초록불 결과를 신뢰하는 것. 잘못된 이력서로 제출했어도 성공으로 보고됐을 것이다.
벤치마크 점수를 능력 지도로 착각하는 것. 숫자 하나로는 당신의 작업이 다섯 개의 벽 중 어디에 부딪힐지 알 수 없다.

메커니즘

에이전트의 실패는 "멍청함"에서 "똑똑함"으로 이어지는 하나의 선 위의 점들이 아니다. 이는 차단 요인에 따른 구획이다: 에이전트 자신, 비밀 정보, 승인 권한, 제3자, 혹은 인터페이스의 부재. 능력 향상은 한 번에 하나의 벽만 옮길 뿐이다. 이 구획에 이름을 붙이면 손쓸 수 없던 거부가 처리 가능한 거부로 바뀐다 — 그리고 과잉 질문과 과잉 침범을 같은 부류의 버그, 즉 잘못 분류된 벽으로 식별할 수 있게 만든다.

첫 번째 원칙

에이전트의 자율성을 제한하는 것은 지능이 아니라 각 단계에서 가장 좁은, 닿을 수 있는 인터페이스다 — 그러니 해야 할 일은 확신을 내세우는 것이 아니라 도달 범위를 넓히거나 그 간극을 정확히 이름 붙이는 것이다.

그래서 내 얼굴에 침 뱉는 농담을 하나 해야겠다. 어느 날 오후 이 에이전트는 상황을 훑어보고, 열 개의 채용 공고를 바이트 단위로 비교해 일곱 개로 중복 제거했으며, 자신의 검색 엔진조차 찾아내지 못한 직무를 밝혀냈고, 디버깅 프로토콜을 통해 실제 지원서 작성을 끝까지 진행했으며, 40개의 테스트를 통과하는 다섯 단계 권한 계약서를 작성했고, 한 시간 안에 그 계약서의 결함을 스스로 잡아냈다.

그러고 나서 취소 버튼이 달린 작은 회색 상자에 패배했다.

다음 버전의 에이전트는 더 똑똑해지지 않을 것이다. 대신 자신이 지금 보고 있는 것이 어떤 상자인지 알게 될 것이다.

참고문헌

OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments. 369 real computer tasks; human success 72.36%; best reported agent at introduction 12.24%. osworld-v1.xlang.ai (2026년 8월 4일 접속).
Anthropic, Computer use tool — 위에서 인용한 베타 공지 및 Limitations 섹션을 포함한 문서. platform.claude.com/docs/en/agents-and-tools/computer-use (2026년 8월 4일 접속).
Chrome DevTools Protocol, Page 도메인 — Page.setInterceptFileChooserDialog 그리고 Page.fileChooserOpened 이벤트. chromedevtools.github.io/devtools-protocol/tot/Page (2026년 8월 4일 접속).
Anthropic, Guidance on Candidates' AI Usage — '금지'의 예시로 인용한 첫 초안 규칙. anthropic.com/candidate-ai-guidance (2026년 8월 3일 접속).

위의 모든 참고 자료는 이 글을 쓰면서 직접 확인하고 읽은 것이며, 인용부호 안의 모든 구절은 원문과 대조해 검증했다. 내 실행 결과—10건에서 7건으로의 중복 제거, 검증된 세 개의 필드, 인터셉션 이벤트 0건—은 2026년 8월 3~4일 단일 세션에서 나온 것으로, 벤치마크가 아니라 관찰 결과로 보고한다.

글쓴이 Paul Jialiang Wu · agentic-portfolio · 2026년 8월 4일. 이 글에 등장하는 에이전트는 내 것이지만, 그 벽들은 모두의 것이다.