-
사용자가 AI라면, 가위 손잡이부터 다시 깎는다IT 2026. 7. 23. 21:00
오른손잡이 가위의 손잡이는 사람 손가락 모양을 따라 깎여 있다. 엄지와 검지가 들어갈 구멍, 손바닥에 닿는 곡선까지 전부 "사람이 쥔다"는 전제로 만들어진 것이다. 그런데 같은 가위를 로봇 팔이 쥔다면 이야기가 달라진다. 손가락 구멍은 쓸모가 없어지고, 오히려 평평한 면에 표준 그립 규격이 박혀 있는 편이 훨씬 낫다. 도구를 쥐는 손이 바뀌면, 손잡이부터 다시 깎아야 한다.
우리가 매일 쓰는 업무 시스템과 문서 도구, 관리 화면도 사정이 똑같다. 거의 전부 "사람이 본다, 사람이 클릭한다"는 전제 위에 설계됐다. 그런데 이제 그 도구를 쥐는 손이 바뀌고 있다. 24시간 쉬지 않고 일하는 AI가 사용자로 들어온다. 손잡이를 그대로 둔 채 AI에게 쥐여 주는 게 과연 맞을까.
사람용 화면을 AI에게 클릭시키면 오히려 못한다
직관적으로는 "잘 만든 화면일수록 AI도 잘 다루겠지" 싶다. 실제로는 반대 결과가 나온다. 2024년 한 연구진은 언어 모델 에이전트(스스로 판단해 도구를 부르는 AI 프로그램)를 "고유한 필요와 능력을 가진 새로운 부류의 최종 사용자"로 보자고 제안했다. 사람을 위해 다듬은 화면을 그대로 주는 대신, 에이전트를 위해 따로 설계한 도구 표면을 쥐여 줬더니 성능이 크게 뛰었다. 실제 GitHub 이슈를 풀게 하는 벤치마크에서 한 번에 맞히는 비율이 12.5%까지 올라, 그전까지의 비대화형 모델 최고 기록을 크게 앞질렀다(발표 당시 기준).
왜 그럴까. 사람용 화면은 눈으로 보고 마우스로 짚는 데 최적화돼 있다. 버튼의 위치, 색, 애니메이션은 사람의 시지각을 돕는 장치다. AI에게는 이 모든 게 잡음이다. 버튼이 화면 어디에 찍혔는지, 렌더링이 한 픽셀 밀렸는지에 동작이 휘청인다. 사람 손가락 구멍에 로봇 팔을 억지로 끼우는 셈이다. 그러니 화면을 더 예쁘게 다듬는 일이 AI 사용성을 높여 주지는 않는다.
AI에게 가장 자연스러운 인터페이스는 무엇인가
질문 하나로 좁혀 보자. 사용자가 AI일 때 가장 자연스러운 인터페이스는 무엇인가? 답은 한 청중만 보지 않는다. 24시간 일하는 AI에게는 접근과 조작이 쉬워야 하고, 그 결과를 받아 드는 사람에게는 검증이 쉬워야 한다. 두 청중을 동시에 만족시키도록 모든 구성 요소를 다시 정의해야 한다.
핵심은 발상의 전환이다. 사람용 화면(GUI, 사람이 보고 클릭하도록 만든 그래픽 인터페이스)을 AI에게 대신 클릭시키는 게 아니라, AI가 직접 다룰 수 있는 표면을 따로 설계한다. 연구자들은 이 표면을 에이전트-컴퓨터 인터페이스(agent-computer interface, AI 에이전트가 컴퓨터를 다루도록 별도로 설계한 도구와 상호작용 규칙의 묶음)라고 부른다.
다이어그램 설명. 이 그림은 같은 작업을 AI에게 맡길 때 갈리는 두 갈래를 보여준다. "AI가 직접 다룰 표면이 있는가?"라는 물음에서 시작한다. 그런 표면이 없으면 AI는 사람용 화면을 대신 클릭하는 처지가 되고, 버튼 좌표나 화면 렌더링이 조금만 바뀌어도 동작이 어긋난다. 반대로 AI가 호출할 구조화된 도구가 마련돼 있으면, 결과가 정해진 형식으로 돌아와 사람이 그대로 검증한다. 놓치기 쉬운 지점은 이것이다. 갈림을 만드는 건 "AI를 더 똑똑하게 만들었는가"가 아니라 "AI가 쥘 손잡이를 따로 깎았는가"라는 점이다.
'AI 전용 표면'은 어떻게 생겼나
추상적인 이야기 같지만 설계 원칙은 꽤 구체적이다. 앞의 코딩 에이전트가 쓴 표면을 뜯어보면 세 가지가 눈에 띈다. 첫째, 출력에 경계가 있다. 파일을 보여줄 때 한 번에 약 100줄 윈도우만 띄우고, 검색 결과도 최대 50건처럼 상한을 둔다. 사람이라면 길게 스크롤하면 그만이지만, AI에게는 긴 출력이 곧 컨텍스트(LLM이 한 번에 들고 있을 수 있는 입력 분량) 낭비이자 혼란이다. 둘째, 가드레일을 박는다. 사람이라면 linter(코드의 문법·스타일 오류를 자동으로 잡는 검사 도구)가 띄운 오류를 보고 커밋할지 스스로 판단하지만, 감독 없이 자율로 움직이는 AI에게는 그 판단이 없다. 그래서 표면이 대신 막는다. 편집한 코드가 linter를 통과하지 못하면 변경을 자동으로 되돌리고, 오류 위치를 사람이 볼 알림이 아니라 AI가 다음에 먹을 신호로 돌려준다. 셋째, 결과를 구조화한다. 줄 번호를 붙이고 형식을 고정해, AI가 다음 행동을 정할 좌표를 함께 준다.
# AI 전용 표면 — 사람 화면을 흉내 내지 않고, 도구 하나로 노출한다 def search_file(query: str, path: str) -> str: hits = grep(query, path) # 1단: 출력을 반드시 잘라 낸다 — 결과가 넘치면 AI가 길을 잃는다 hits = hits[:50] # 결과 상한 50건으로 고정 # 2단: 줄 번호를 붙여 구조화한다 — 다음 행동을 정할 좌표를 함께 준다 return render_with_line_numbers(hits) # 가드레일 — 편집이 문법 검사를 통과 못 하면 자동으로 되돌린다 def apply_edit(path: str, patch: str) -> str: backup = read(path) write(path, patch) if lint(path).failed: # linter가 오류를 잡으면 write(path, backup) # 변경을 폐기하고 원상복구한다 return "거부됨 — 오류 위치와 함께 다시 시도하라" return "적용됨"코드 설명. 두 함수는 "AI가 다루기 쉽게, 사람이 검증하기 쉽게"라는 원칙을 코드로 옮긴 모습이다. 검색 함수는 결과를 무한정 쏟지 않고 50건에서 자른 뒤 줄 번호를 붙여 돌려준다. 편집 함수는 변경을 바로 확정하지 않고, 검사를 통과할 때만 남기고 실패하면 원래 상태로 되돌린다. 이렇게 하면 AI는 짧고 정해진 형식의 응답만 받아 다음 수를 두기 쉬워지고, 사람은 "무엇이 적용됐고 무엇이 거부됐다"를 한눈에 검증한다. 사람용 화면이라면 굳이 필요 없었을 출력 상한과 자동 되돌리기가, AI라는 사용자를 위해 손잡이를 다시 깎은 흔적이다.
표준으로 굳어 가는 방향 — MCP
표면을 도구마다 따로 깎으면, 도구가 늘어날수록 손이 많이 간다. AI 애플리케이션 10개가 외부 도구 100개와 이어지려면 최악의 경우 1,000가지 연동을 일일이 만들어야 한다. 이 조합 폭발을 하나의 규약으로 접으려는 시도가 MCP(Model Context Protocol, AI 모델과 외부 도구·데이터를 잇는 개방형 표준)다. 2024년 11월 한 AI 기업이 공개했고, 이후 다른 주요 AI 제공사들도 채택했다. 2025년 12월에는 리눅스 재단 산하 재단으로 기증돼 특정 회사 소유에서 공용 표준으로 넘어갔다.
MCP가 정의하는 표면은 세 갈래다. 도구(tools, AI가 호출해 동작을 일으키는 함수 — 타입이 정해진 인자를 받고 구조화된 결과를 돌려준다), 리소스(resources, AI가 읽기만 하는 맥락 데이터 — 파일 내용이나 데이터베이스 구조 같은 것), 프롬프트(prompts, 반복 쓰는 지시 템플릿)다. 셋 다 사람 화면을 흉내 내지 않는다. 처음부터 AI가 읽고 부르도록 설계된 표면이라는 점이 핵심이다. 가위로 치면, 손가락 구멍을 없애고 모든 로봇 팔이 같은 규격으로 쥘 수 있는 표준 그립을 못 박은 셈이다.
손잡이를 다시 깎는 일은 누구의 몫인가
개인이 AI를 부리는 입장에서 보면 이 관점은 더 또렷해진다. 집의 작은 서버 한 대에 여러 AI를 24시간 돌려 두고 일을 맡기다 보면, "사람이 쓰던 화면을 AI에게 클릭시키는" 방식이 얼마나 깨지기 쉬운지 금방 체감한다. 화면 한 군데가 바뀌면 그날 자동화가 통째로 멈춘다. 반면 AI가 부를 도구를 하나 정의해 두면, 그 도구는 화면이 어떻게 바뀌든 흔들리지 않는다.
그래서 AX(AI Experience, AI가 도구를 다루는 경험)는 UX의 곁가지가 아니라 별도의 설계 축으로 다뤄야 한다. 같은 기능에 손잡이를 두 개 깎는 일이다. 하나는 사람이 보고 검증하기 좋은 화면, 다른 하나는 AI가 직접 쥐고 다루기 좋은 도구 표면이다. 사용자가 사람에서 AI로 넓어진 지금, 가장 먼저 다시 깎아야 할 것은 똑똑한 모델이 아니라 그 모델이 쥘 손잡이다.
참고한 공개 자료:
- SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering — https://arxiv.org/abs/2405.15793
- Agent-Computer Interface 문서 — https://github.com/SWE-agent/SWE-agent/blob/main/docs/background/aci.md
- Introducing the Model Context Protocol — https://www.anthropic.com/news/model-context-protocol
- Model Context Protocol — Wikipedia — https://en.wikipedia.org/wiki/Model_Context_Protocol
- Specification — Model Context Protocol — https://modelcontextprotocol.io/specification/2025-11-25
이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.
'IT' 카테고리의 다른 글
AI에게 파일 수정을 맡길 때 — OpenClaw는 어긋나면 멈추고, Hermes는 어긋나도 고친다 (0) 2026.07.25 봇의 두뇌를 어디에 둘 것인가, 두 갈래 — OpenClaw는 봇 성격에 붙박고, Hermes는 화면에서 갈아끼운다 (0) 2026.07.24 봇은 대화를 어떻게 기억하나 — OpenClaw는 격리로, Hermes는 통합검색으로 (0) 2026.07.24 봇을 안 죽게 만드는 두 갈래 — OpenClaw는 프로세스 하나로, Hermes는 감독관을 세워 (0) 2026.07.24 '관리만 하던 시니어'의 종말 — 다시 실무로 내려온 그의 팀원은 에이전트다 (0) 2026.07.23 AI를 깔아도 AI-native가 아닌 이유 — 회사를 'AI가 읽고 쓸 수 있는' 형태로 다시 세우기 (1) 2026.07.22 AI의 ROI 역설 — 더 빨리 만드는 게 매출의 병목은 아니었다 (0) 2026.07.22 전기 모터가 공장에 들어왔을 때 — AI는 도구가 아니라 일하는 방식을 바꿀 때 효과가 난다 (0) 2026.07.22 검증은 작업한 본인이 아니라 맥락을 모르는 새 비판자에게 맡겨라 (0) 2026.07.21 AI가 다 만들면 나는 뭘 하나 — 좋은 검증 레이어를 만드는 사람 (0) 2026.07.21