👀 혹시, CIT에 접속 하셨나요? 
CIT 웹사이트 바로가기
Spotlight

Claude Cowork Moment and Beyond Screen: Agent가 대신 행동할 때, 이제 무엇을 설계해야할까?

Category
  1. Insight
  2. Think
Written by
윤형근 파트너
Date
Feb 26, 2026
Hear I am
  • 윤형근
안녕하세요, Companoid Labs 윤형근 파트너입니다.
제가 Companoid Labs에서 주기적으로 최근 화제가 되고 있는 기술이나 제품, 서비스에 대한 생각을 전달해드리고 있습니다. 콘텐츠에 대한 알림을 받고 싶으시다면, 이 글 가장 아래에 있는 구독 버튼을 눌러주세요!
이 콘텐츠를 작성한 사람은 누구인가요?
👉
윤형근 파트너는 기술이 인간에 스며들 수 있는 유일한 방식으로 사용자 경험을 전달하는 인간-컴퓨터 상호작용 기술의 중요성을 이야기 합니다. 이는 곧 기술이 사회적 기여를 하는 방식과도 직결된다고 믿으며, 인간의 삶에서 기술은 뗄레야 뗄 수 없는 영향 관계에 있다는 점을 항상 생각 했습니다. 그가 컴퓨터 사이언스를 전공하면서도 HCI 분야에 대해 관심을 두게 된 것은 이 때문 입니다.
그는 소셜 네트워크 서비스에서 과도하게 노출되는 개개인의 일상과 신상의 문제점을 인식해 하루 커뮤니케이션을 창업하고 휘발형 SNS인 '하루'를 개발하여 어린 나이에 주목을 받았습니다. 3개월 만에 수천명의 사용자를 모은 돌풍에 힘입어 네이버로부터 인재 육성 차원에서 서버 등 데이터 센터와 학자금 지원 등을 받아 큰 화제를 모았습니다. 네이버 소프트웨어 전문학교인 NEXT 입학과 최초의 고등학생 인턴십 기회까지 받은 경험을 바탕으로 DGIST에서 컴퓨터 사이언스를 전공한 그는, 장진규 의장이 서울대학교 차세대융합기술연구원에서 HCI 연구실장으로 재직할 당시 연구팀에 합류해 HCI 기술에 대해 본격적으로 연구 했습니다. 이후에는 KAIST와 국방과학연구소에서 HCI와 AI 기술의 융합에 대해 연구하였으며, 본인의 스타트업 창업 경험과 UX에 대한 전문성을 투자하고자 컴패노이드 랩스의 공동 창업자로 합류 했습니다.
현재는 사용자와 AI가 접하는 새로운 인터페이스와 AI 네이티브 인터넷 경험을 설계하기 위해서 허버트 컴퓨터의 초기 컴퍼니 빌딩을 진행하고, 프로덕트의 인터랙션 설계를 담당하고 있습니다. 특히, AI와의 상호작용을 통해 연결되는 인터넷의 가능성에 대해 많은 관심을 두고 있습니다.
윤형근 파트너 개인 소셜미디어
Companoid Labs와 CIT의 다른 콘텐츠도 받아보고 싶어요.
👉
Companoid LabsCIT는 공식 블로그와 소셜 미디어를 통해 다양한 콘텐츠를 전달해드리고 있습니다. Companoid Labs의 공식 링크드인과 페이스북, CIT의 공식 인스타그램 계정을 팔로우하고, 관련 소식을 가장 먼저 받아보실 수 있습니다.
Companoid Labs 및 CIT 공식 소셜미디어

채팅창을 벗어난 AI

Claude Cowork
최근 가장 뜨거운 키워드를 뽑자면 OpenClaw를 비롯한 AI 에이전트를 빼놓을 수 없습니다. 지난 번 글에서 이미 OpenClaw 에이전트를 위한 소셜미디어인 Moltbook에 대해서 이야기를 했는데요. Moltbook에 대한 이야기는 그 때에 비해서는 줄어들었지만, 여전히 내 데스크탑이나 서버에서 직접 행동을 할 수 있는 에이전트 프로젝트인 OpenClaw는 관심이 뜨거워 보입니다. 때마침 며칠 전에, OpenClaw의 개발자 Peter Steinberger가 OpenAI에 합류했다는 소식이 전해지기도 했습니다. 이제는 AI가 단순히 채팅창 안에서만 머무는 것이 아니라, 실제 워크스페이스에 접근해서 행동을 하는 것을 목격할 수 있습니다.
OpenClaw 뿐만 아니라 지난 1월에 등장한 Claude Cowork 기능도 뜨거운 관심을 보이고 있는데요. Calude Cowork는 Claude Code의 에이전트 기능을 데스크탑으로 가져와서 코딩 이외의 다른 사무 및 지식 작업을 할 수 있도록 만든 기능입니다. 단순한 파일 정리부터 엑셀을 활용한 데이터 분석, 파워포인트를 활용한 자료 제작도 가능합니다. 과거에는 AI가 아무리 똑똑하더라도 실제 엑셀로 옮기고, 파워포인트로 만드는 과정을 그래도 사람이 자신의 손을 활용해서 해야했다면, 이제 내 데스크탑 컨텍스트 내에 있는 작업은 AI 에이전트가 충분히 해줄 수 있는 정도가 된 것이죠.
실제로 이로 인해서 미국 주식시장에서는 'SaaSpocalypse'가 오면서 소프트웨어 관련된 주식이 폭락했습니다. 과거에는 데이터 분석을 위해, 자료를 더 잘 만들기 위해, 영상을 더 잘 만들기 위해서, 디자인을 더 잘하기 위해서 등 다양한 도메인에서 이를 쉽게할 수 있도록 지원해주는 소프트웨어가 등장했습니다. 근데 이제는 데이터를 넣어주면 AI가 이러한 과정을 다 대체해줄 수 있지 않냐는 것이죠. 기존 SaaS가 혜자로 자리 잡을 수 있었던 이유는 사람이 클릭, 타이핑 등으로 UI와의 상호작용을 통해 앞서 말한 다양한 일을 상대적으로 쉽고 간편하게 할 수 있도록 해주었기 때문인데, 이제는 AI가 이보다 더 쉽게, 소위 말 한마디와 "딸깍" 한번으로 이러한 일을 처리해줄 수 있는 것 아니냐는 공포감이 작용하고 있습니다.

사용자가 화면을 보지 않는다면?

만약 이러한 에이전트가 더 많이 사용되고, 보편적인 게이트웨이가 된다면 어떻게 될까요? 즉, 사용자가 에이전트에게 자신이 하고 싶은 작업을 요청하면, 에이전트가 대신 각각의 SaaS나 서비스에서 작업을 수행하는 것이죠. 그렇게 되면 사용자가 실제 서비스의 화면을 거의 보지 않거나, 아니면 아예 보지 않을 수도 있습니다. 실제 결과는 에이전트가 수행하게 되고, 그때 수행한 과정이나 결과도 에이전트를 통해서 보게되는 것이죠. 아니면 설사 화면을 본다고 하더라도 직접 사용자가 서비스와 사용하지 않게 됩니다. 사용자는 에이전트가 서비스와 상호작용하는 모습을 지켜보고, 에이전트가 잘 하지 못하는 작업에 대해서만 개입하게 될 수 있습니다.
이런 시대가 온다면, 사용자를 위해서 더 이상 화면을 멋지게 그리거나, 잘 디자인하는 것이 의미가 있을까요? 물론 여전히 사용자가 서비스에 직접 접근하거나, 개입하는 측면에서는 중요한 의미가 있습니다. 하지만, 정말 시각적으로 멋진 화면인데, 에이전트가 접근하고, 조작하기 어려운 화면이라면 어떨까요? 에이전트가 어디를 클릭해야할지 모르고, 어떤 메뉴나 기능을 써야할지 모른다면 에이전트가 서비스 사용을 포기하고, 이는 결국 사용자가 서비스 사용을 포기하는 결과로 나타날 수 있습니다. 오히려 시각적으로는 단순하지만, 에이전트가 접근하고 조작하기에 명확한 인터페이스를 갖고 있는 서비스가 에이전트에게 더 많은 선택을 받을지도 모릅니다.
Google Labs의 Disco 프로젝트
더 나아가 이제는 AI가 직접 인터페이스를 디자인하고, 화면을 그리는 경우도 있습니다. 실제로 Google Labs의 Disco 프로젝트는 다양한 웹사이트를 종합하여 사용자의 요구에 맞는 인터페이스를 생성하는 접근을 보여주고 있습니다. 이러한 경우에는 더 화면을 그리는 의미가 퇴색될 수 있습니다. 오히려 AI가 화면을 더 잘 그릴 수 있도록 가이드라인이나 제약 조건을 제시하거나, AI가 우리 서비스를 대신해 사용자에게 인터페이스를 제공할 때 도움이 되는 데이터를 제공하는 것이 중요할 수 있습니다.
그렇다면 이제는 무엇을 설계해야 할까요? 여전히 대부분의 사용자는 서비스에 직접 접근해서 작업을 하고 있고, 당장 에이전트를 모두가 쓰는 것이 아니기 때문에 사용자 경험 설계는 여전히 중요합니다. 하지만 에이전트가 충분한 성능을 발휘할 수 있고, 여러 서비스에 접근할 수 있게 된다면 에이전트를 위한 경험 설계가 필요할지도 모릅니다. Claude Code로 인해서 많은 사람들이 IDE를 통해 코드를 잘 보지 않게 된 것처럼, 에이전트에게 위임하고, 인간은 리뷰와 감독만 하는 경우가 많아지면 오히려 에이전트를 위한 UI를 설계하고, 에이전트를 통해서 전달되는 경험을 설계하는데 집중해야 할 수도 있습니다. Jacob Nielson의 18가지 예측처럼, 이렇게 되면 더 이상 화면을 설계하는 것이 아니라 워크플로우를 설계하고, AI를 통한 상호작용을 설계하고, 제약 조건과 가이드라인을 설계하고, 현재 작업이 잘 진행되고 있는지 감독할 수 있는 것을 도와주는 것이 더 중요해질 것입니다.

에이전트를 위한 인터페이스와 에이전트를 통해 상호작용하는 경험

앞서 이야기한 내용으로 2가지 측면에서의 고려가 필요하다는 것을 알 수 있었습니다. 첫번째는 에이전트가 어떻게 우리 서비스를 잘 사용하게 할 수 있을지에 대한 고려이고, 두번째는 사용자가 에이전트와 상호작용을 하는 경험을 어떻게 잘 설계할 수 있을지에 대한 고려입니다. 저는 각각 에이전트를 위한 인터페이스와 에이전트를 통해 상호작용하는 경험 측면에서 관련한 생각을 나누고자 합니다.
먼저 에이전트를 위한 인터페이스의 경우에는 에이전트가 우리 서비스에 접근했을 때 쉽게 우리 서비스의 구조를 이해하고, 명확하도록 해야합니다. 더 이상 사람의 눈에 멋진 화면이 아니라 에이전트의 이해를 돕는 구조가 되어야 한다는 의미입니다. 현재 웹 에이전트를 기준으로 설명드리면, 웹 에이전트는 주로 보이는 화면을 스크린샷으로 촬영하거나, HTML로 작성된 코드를 통해서 웹페이지의 현재 상태를 관찰하고 이해합니다. 그리고 이를 통해 다음에 자기가 어떤 버튼을 누를지와 같은 행동을 결정하고, 실제 행동을 수행하게 됩니다. 따라서, 에이전트의 이해를 돕기 위해서는 보이는 측면에서 에이전트가 쉽게 이해할 수 있도록, 그리고 코드 측면에서 에이전트가 쉽게 이해할 수 있도록 설계할 필요가 있습니다.
따라서 이를 위해서는 단순히 HTML의 다양한 요소가 시각적인 표현을 넘어서 데이터와 기능의 의미를 명확하게 전달할 수 있어야 합니다. 가령 버튼은 <button> 태그를 명확하게 사용하고, 불필요한 wrapping을 위한 태그 사용을 지양하는 것이 좋습니다. 또한, 접근성(Accessibility)의 중요성에 대해서도 생각해볼 수 있습니다. 원래 접근성은 시각 장애인을 비롯한 다양한 사용자가 스크린리더 등의 도구를 통해 웹을 사용할 수 있도록 설계되었지만, 이러한 접근성에 대해 고려하는 서비스가 많지는 않습니다. 하지만 에이전트가 상호작용을 하게 되면, 이러한 접근성은 에이전트가 서비스를 이해하고 조작하는데 필요한 구조적인 메타데이터를 제공하는 역할을 수행할 수 있습니다. 실제로 많은 연구에서 접근성 트리를 웹 에이전트의 입력으로 활용하는 것의 중요성을 강조하고 있습니다. 따라서, 어떤 요소가 중요한지 접근성 관련 속성을 통해 레이블링과 역할을 부여하면, 에이전트가 상호작용하는 방법을 이해하는데 큰 도움이 될 수 있습니다. 마지막으로 동적인 UI와 같이 렌더링이 바뀌는 인터페이스는 지양하는 경우가 좋습니다. 에이전트의 작동은 인간처럼 연속적으로 상태 변화를 관찰하는 것이 아니라, 순차적인 관찰/인식 → 판단/추론 → 행동으로 이루어지는데, 이 사이에 상태 변화가 이루어지면 에이전트는 제대로 행동을 하지 못하고, 결과적으로 태스크 수행의 실패로 귀결될 수 있습니다. 따라서, 애니메이션이나 레이아웃의 변동이 에이전트의 행동에 대한 피드백이 아니라 지속적으로 이루어지지 않도록 하는 것이 좋습니다.
간단히 에이전트를 위한 인터페이스에 대해 논의를 해보았는데요. 에이전트가 잘 작동할 수 있는 인터페이스를 설계하는 것도 중요하지만, 더 중요한 것은 에이전트를 통해 전달되는 경험을 어떻게 잘 설계할 수 있는지도 중요합니다. 가령, 사용자의 확인이 필요한 부분을 서비스에 미리 반영하고, 에이전트가 상호작용을 했을 때 이러한 확인을 받도록 에이전트에게 전달할 수 있도록 설계할 수도 있고, 사용자가 이미 자주 사용하는 워크플로우를 설정하고 에이전트가 그 워크플로우를 쉽게 따라갈 수 있도록 가이드라인을 설계할 수도 있습니다. 어떠한 설계를 하던, 에이전트를 통해 사용자가 서비스와 상호작용을 한다는 것은 사용자가 에이전트에게 자신이 원래 손으로 하던 일은 위임하고, 에이전트가 수행한 결과에 대해서 리뷰만 한다는 것인데, 이러한 위임과 리뷰 과정에서 에이전트를 통한 커뮤니케이션, 에이전트를 통해 신뢰를 구축하는 것이 중요하다고 할 수 있습니다. 개인적으로 지난 카카오 AI_TOP_100 대회에서 전체 3000명 중 2위로 금상을 수상하게 되었을 때, 제 주된 접근은 AI가 내가 제시한 문제와 접근을 어떻게 이해하고, 어떻게 해결하는지, 즉 멘탈 모델이 나랑 일치하고 내가 생각한 방향과 비슷하게 문제를 풀어가는지를 관찰하면서 필요할 때마다 가이드를 주는 것이었는데요. 저는 에이전트를 통한 상호작용 경험에서도 마찬가지로 위임과 리뷰를 그냥 하는 것이 아니라, 사용자의 생각과 멘탈 모델과 맞추고, 사용자가 본인의 사고 흐름과 마찬가지의 워크플로우로 에이전트가 동작하는 것을 확인하고 이를 리뷰할 수 있도록 하는 것이 중요하다고 생각합니다.
컴퓨터 사용 에이전트의 UX 설계시 고려할 점 분류 결과, 논문 中
더 나아가서 에이전트와 사용자의 상호작용에서도 고려할 점이 있습니다. 최근 Apple의 연구원들이 공개한 <Mapping the Design Space of User Experience for Computer Use Agents>라는 연구에서는 컴퓨터 사용 에이전트(Computer-Use Agents)의 사용자 경험 설계 공간을 4개의 카테고리와 21개의 하위 카테고리로 분류했습니다. 4개의 카테고리는 각각 사용자 입력 및 지시에 관한 설계, 에이전트의 활동에 대한 설명가능성에 대한 설계, 사용자 통제에 대한 설계, 사용자의 멘탈모델과 기대에 대한 설계 등 에이전트와의 상호작용에서 고려해야하는 사용자 경험이 제시되었습니다. 각각의 카테고리에서는 사용자의 의도를 어떤 형태의 입력(텍스트, 제스처, 행동 등)으로 받을 것인지, 대화형으로 상호작용을 할 것인지, 사용자 고유 데이터 및 맥락에 활용에 대한 부분부터 에이전트의 행동 히스토리와 행동을 한 근거에 대한 설명, 고위험 단계에서의 권한 부여, 에이전트가 할 수 있는 부분과 할 수 없는 부분에 대한 내용 등이 포함되어 있습니다. 이러한 분류를 기반으로 Wizard-of-Oz 기법을 활용한 실험을 진행한 결과, 사용자의 작업 수행 목표가 탐색에 가까운지, 아니면 명확한 목표가 있는지에 따라 사용자의 지시 방법이 달라질 수 있고, 구매와 같은 리스크가 존재하는 단계에서는 사용자의 통제가 충분히 필요하며, 사용자가 에이전트를 지속적으로 관찰하지 않더라도 전체적인 흐름을 이해할 수 있도록 설계하는 것의 중요성을 알 수 있었습니다. 위에서 분류했던 21개의 카테고리가 모두 중요한 사용자 경험 이슈로 등장했기 때문에, 태스크에 따라 더 중요한 부분을 설계하는 것이 중요하다고 강조했습니다.
이러한 연구는 에이전트와 사용자 경험 설계 뿐만이 아니라, 서비스 입장에서 어떻게 이러한 사용자 경험을 전달하는데 도움을 줄 수 있을지에 대해서도 힌트를 엿볼 수 있습니다. 에이전트가 추론이나 사용자에게 설명을 더 잘할 수 있도록 조건을 설계할 수도 있고, 중요한 지점에서는 사용자에게 개입을 요청하도록 유도할 수도 있고, 에이전트가 접근할 수 없는 부분에 대해서 미리 강조를 해둘 수도 있습니다. 중요한 점은 우리 서비스가 에이전트를 통해서 접근되고, 이를 사용자가 에이전트를 통해서 상호작용할 때 어떤 지점의 사용자 경험이 필요한지를 이해하고, 이를 중심으로 정책이나 가이드라인을 설계하는 것입니다.
오늘은 Claude Cowork와 OpenClaw 등으로 다가온 에이전트의 시대와 에이전트를 통해 서비스가 사용될 때 화면이 아니라 어떤 점을 설계해야할지에 대한 고민을 나눠보았습니다. 에이전트로 인해 SaaS의 위기가 찾아오고 있지만, SaaS만이 가져갈 수 있는 고유의 기능을 에이전트를 통해 어떻게 사용자에게 제공할 수 있을 지에 대해서도 고민이 필요한 시기라고 생각합니다.
다음 시간에도 또 다른 이야기로 제 생각을 나눠보겠습니다.
감사합니다.
Subscribe to 'Companoid Labs'
Subscribe to my site to be the first to receive notifications and emails about the latest updates, including new posts.
Join Slashpage and subscribe to 'Companoid Labs'!
Subscribe
👍
ⓒ2021 - 2025 컴패노이드 랩스 지주회사, 모든 권리 보유.
사업자등록번호 457-86-01970
개인정보보호책임자 박민아