Holo4, 컴퓨터를 직접 쓰는 에이전트를 받치는 법

이번에 살펴볼 글은 Hcompany가 Hugging Face 블로그에 올린 Holo4: powering generalist computer-use agents입니다. 이 글은 그래픽 인터페이스를 직접 보고 조작하는 범용 컴퓨터 사용 에이전트를 위한 기반으로서 Holo4를 소개합니다. 제가 보기에 이 글의 주장은 한 문장으로 정리됩니다. 화면 이해와 요소 위치 지정, 계획과 실행을 따로 떼어 보지 않고 함께 묶어야 긴 컴퓨터 작업이 실제로 돌아간다는 것입니다. 원문 링크는 제목 아래에 걸어 두었으니 필요하시면 그곳에서 확인할 수 있습니다. 이 글에서는 그 주장을 따라가며 왜 화면을 보는 일이 어려운지, 왜 긴 작업이 데모를 넘어서지 못하는지, 무엇을 배우고 무엇을 재고 어떻게 지켜야 하는지를 차례로 풀어보겠습니다.

마우스를 든 모델을 보면 왜 마음이 바빠질까

안녕하세요, 패트릭입니다. 저는 한동안 브라우저를 켜두고 에이전트가 뭔가를 대신 클릭해 주기를 바라는 장면을 자주 떠올렸는데요. 아침에 출근해서 노트북을 열면 어제 못 끝낸 정산 화면이 그대로 있고, 누군가 대신 로그인해서 숫자를 옮겨 적어주면 좋겠다는 생각을 하곤 했습니다. 그래서 컴퓨터를 직접 쓰는 에이전트 이야기가 나오면 반갑다가도 곧 조심스러워집니다. 말로는 쉬워 보이는데, 막상 시켜보면 중간에 멈추는 경우가 너무 많았기 때문입니다.

제가 이 글에서 가장 흥미롭게 본 부분은 거창한 약속이 아니라 문제 설정 방식이었습니다. Hcompany는 컴퓨터 사용을 언어 문제 하나로 보지 않고, 스크린샷을 읽는 지각과 화면 속 요소를 찝어내는 위치 지정, 순서를 정하는 계획, 실제로 움직이는 실행이 함께 돌아가야 하는 일로 그립니다. 이렇게 나누면 각 부분이 왜 따로 놀기 쉬운지도 잘 보입니다. 화면은 잘 읽는데 클릭을 못 하거나, 클릭은 정확한데 순서를 틀리거나, 순서는 맞는데 팝업 하나에 무너지는 식이죠. 여러분도 비슷한 경험이 있으실 겁니다. 데모 영상에서는 매끈하게 돌아가던 에이전트가 막상 내 노트북에서는 로그인 버튼 앞에서 한참을 헤매는 장면 말입니다.

그렇다면 왜 이런 일이 반복될까요. 저는 화면이라는 매체 자체가 언어 모델에게는 낯설기 때문이라고 봅니다. 글자는 순서대로 읽히지만 화면은 위아래 좌우가 한꺼번에 의미를 만들며, 같은 버튼도 창 크기와 스크롤 위치에 따라 다른 곳에 나타나니까요. 여기서부터 Holo4가 겨냥하는 지점이 분명해집니다. 특정 사이트 전용 자동화가 아니라, 그래픽 인터페이스라는 공통 언어로 여러 컴퓨터 일을 해내는 범용 에이전트의 토대를 만들겠다는 것이죠. 이 글에서는 그 토대가 어떤 조각들로 이루어져 있는지 하나씩 짚어보겠습니다.

화면을 본다는 것은 무엇을 뜻할까

사람에게 화면 보기는 너무 쉬워서 설명하기조차 어렵습니다. 그런데 모델에게 스크린샷 한 장은 픽셀의 바다에 가깝습니다. 어디가 버튼이고 어디가 그냥 장식인지, 어떤 글자가 지금 해야 할 일과 연결되는지를 스스로 가려내야 하니까요. 특히 웹과 운영체제 화면은 개발자가 보기 좋게 정리한 문서가 아니라, 광고와 팝업과 알림이 수시로 끼어드는 생활 공간에 가깝습니다. 저는 그래서 화면 이해를 텍스트 읽기 문제로만 보면 길을 잃기 쉽다고 봅니다.

이 글에서 말하는 스크린샷 지각은 단순히 글자를 읽어내는 수준을 넘어섭니다. 지금 화면이 어떤 상태인지, 무엇을 할 수 있는 상태인지, 무엇을 하면 안 되는 상태인지를 함께 읽어야 합니다. 예를 들어 월요일 아침에 경비 정산 페이지를 열었다고 해보죠. 잔뜩 쌓인 영수증 목록 위에 저장 버튼이 회색으로 비활성화돼 있고, 오른쪽 아래에는 동기화 중이라는 작은 표시가 깜빡이고 있습니다. 사람은 이 장면을 보자마자 아직 누를 때가 아니라는 것을 압니다. 하지만 글자만 읽는 모델은 저장이라는 단어가 보인다는 이유로 덜컥 클릭을 시도할 수 있습니다. 화면을 본다는 것은 결국 상태와 affordance를 함께 읽는 일인데, 이 부분이 빠지면 에이전트는 눈을 뜨고도 앞이 안 보이는 셈입니다.

여기서 재미있는 질문이 생깁니다. 해상도가 높아지면 문제가 풀릴까요. 저는 그렇지 않다고 봅니다. 더 선명한 이미지가 도움이 되는 경우는 분명히 있지만, 진짜 어려움은 선명함이 아니라 해석에 있기 때문입니다. 같은 체크박스라도 결제 화면에서는 동의를 뜻하고, 설정 화면에서는 알림 허용을 뜻하는데, 그 차이는 픽셀만 봐서는 알 수 없고 맥락을 알아야 비로소 보입니다. 그래서 화면 이해는 눈의 문제가 아니라 상황 읽기의 문제로 바뀌고, 이 해석이 뒤에 이어질 모든 클릭의 출발점이 됩니다.

좌표를 찍는 일이 왜 따로 떨어져 있을까

화면을 이해했다고 해서 손이 따라가는 것은 아닙니다. 컴퓨터 사용 에이전트에게는 이해와 클릭 사이에 좌표라는 다리가 놓여 있는데, 이 다리가 생각보다 자주 흔들립니다. UI 요소 grounding이라고 부르는 이 과정은 말하자면 지금 눌러야 하는 저 파란 버튼이 정확히 몇 번째 픽셀에 있는지를 알아맞히는 일입니다. 사람은 손가락으로 대충 가리켜도 되지만 에이전트는 숫자를 찍어야 해서, 한두 픽셀 차이로 옆 메뉴가 눌리는 일도 생기죠.

문제는 그다음입니다. 요즘 인터페이스는 가만히 있지 않습니다. 스크롤하면 버튼이 위로 올라가고, 창을 넓히면 메뉴가 펼쳐지고, 반응형 레이아웃에서는 어제 있던 버튼이 오늘 다른 줄에 있습니다. 같은 저장 버튼이라도 노트북 화면과 외부 모니터에서는 위치가 완전히 달라지죠. 그래서 좌표 지정은 한 번 맞히고 끝나는 문제가 아니라, 매 순간 다시 확인해야 하는 추적 문제에 가깝습니다. 저는 이 지점에서 많은 데모가 미끄러진다고 봅니다. 녹화된 화면에서는 잘 맞던 좌표가 실제 내 화면에서는 어긋나기 때문입니다.

그렇다면 왜 지각과 위치 지정을 함께 묶어야 할까요. 이유는 화면을 잘못 읽으면 좌표도 함께 틀어지기 때문입니다. 예를 들어 비슷한 버튼이 두 개 있는 화면을 생각해 보죠. 위에는 임시 저장, 아래에는 최종 제출이 있습니다. 글자 모양은 비슷하고 색도 비슷합니다. 화면 맥락을 모르면 둘 중 어느 것을 눌러야 할지 알 수 없고, 좌표만 정확하다고 해결될 일도 아닙니다. 반대로 맥락은 알지만 좌표가 흔들리면, 알면서도 못 누르는 답답한 상태가 됩니다. 그래서 이 두 능력은 따로 평가받는 별개의 시험이 아니라, 서로를 받쳐주는 한 쌍으로 길러져야 합니다. Holo4가 기반을 자처하는 이유도 여기에 있다고 저는 읽었습니다. 어느 한쪽의 정확도가 아니라 두 능력이 맞물리는 방식을 다루겠다는 것이죠.

계획과 클릭 사이에서 길을 잃지 않으려면

컴퓨터 일은 대부분 순서가 있는 일입니다. 로그인하고, 메뉴를 찾아 들어가고, 조건을 고르고, 확인을 누르는 식이죠. 그런데 순서가 있다는 것은 중간에 하나라도 어긋나면 뒤가 전부 흔들린다는 뜻이기도 합니다. 저는 에이전트의 계획을 거대한 설계도가 아니라, 걸어가며 계속 고쳐 쓰는 메모에 가깝게 봅니다. 처음부터 완벽한 순서를 짜는 것보다, 화면이 바뀌면 계획을 함께 고치는 능력이 더 중요하기 때문입니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 계획은 어디까지 세우고, 실행은 언제 시작할까요. 너무 미리 세우면 화면이 바뀌었을 때 처음부터 다시 해야 하고, 너무 짧게 끊으면 매번 우왕좌왕하게 됩니다. 예를 들어 항공권을 바꾸는 일을 맡겼다고 해보죠. 예약 번호를 입력하고, 변경 가능한 표를 고르고, 수수료를 확인하고, 결제를 눌러야 합니다. 그런데 두 번째 단계에서 갑자기 추가 인증 창이 뜨면 어떻게 할까요. 좋은 에이전트는 전체 목표를 기억한 채로 인증부터 처리하고 다시 돌아옵니다. 반면 계획과 실행이 따로 노는 에이전트는 인증 창을 무시하고 다음 버튼을 누르려다 같은 자리에서 맴돕니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 계획을 잘 짠다는 말이 곧 추론을 길게 한다는 뜻은 아니기 때문입니다. 오히려 화면 앞에서는 짧게 생각하고 자주 확인하는 쪽이 유리할 때가 많습니다. 사람이 처음 가본 관공서에서 표지판을 보며 한 걸음씩 움직이는 것과 비슷합니다. 큰 그림을 머릿속에 품되, 눈은 바로 앞 표지판에 두는 식이죠. 그래서 계획과 실행은 위아래 관계가 아니라 옆에서 손을 잡는 관계에 가깝습니다. 계획이 실행을 이끌다가도, 실행이 본 화면이 계획을 고치는 식으로 계속 주고받아야 합니다.

데모에서는 되는데 아침 업무에서는 멈추는 이유

긴 작업의 신뢰성은 이 글에서 반복해서 강조되는 대목인데, 저는 이 대목이 가장 현실적이라고 느꼈습니다. 짧은 작업 десять 개를 잘하는 것과 긴 작업 하나를 끝내는 것은 전혀 다른 문제이기 때문입니다. 각 단계가 95퍼센트씩 맞는다고 해도, 그 단계가 스무 개 이어지면 전체 성공률은 눈에 띄게 떨어집니다. 게다가 컴퓨터 작업에서는 한 번의 실수가 다음 화면 자체를 바꿔버려서, 실수한 줄도 모르고 엉뚱한 길로 들어서는 경우도 많습니다.

운영 측면에서 보면 이 차이는 상당히 큽니다. 데모에서는 네트워크가 빠르고, 팝업도 없고, 로그인은 미리 돼 있습니다. 하지만 월요일 아침의 실제 노트북은 다릅니다. 업데이트 알림이 화면 한가운데 떠 있고, 로그인은 풀려 있고, 어제와 메뉴 순서가 살짝 바뀌어 있습니다. 이런 사소한 어긋남 하나가 에이전트를 멈추게 합니다. 제가 앞으로 보고 싶은 것도 바로 이 지점입니다. 깨끗한 화면에서의 성공률이 아니라, 지저분한 화면에서도 스스로 복구하는 모습 말입니다.

그렇다면 신뢰성은 어떻게 길러질까요. 저는 크게 두 갈래라고 봅니다. 하나는 실수를 줄이는 것이고, 다른 하나는 실수에서 돌아오는 법을 배우는 것입니다. 전자는 화면 이해와 좌표 정확도를 높이는 일이고, 후자는 지금 뭔가 잘못됐다는 것을 알아차리고 한 단계 물러나는 일입니다. 예를 들어 결제 버튼을 눌렀는데 화면이 그대로라면, 같은 버튼을 열 번 더 누르는 대신 방금 입력한 카드 번호 화면으로 돌아가 뭐가 빠졌는지 살펴봐야 합니다. 사람에게는 당연한 이 되돌아가기가 에이전트에게는 꽤 어려운 기술인데, 긴 작업을 끝내는 열쇠는 대체로 여기에 있습니다. Holo4가 긴 수평선 위의 작업을 전면에 내세운 것도 그래서 반가웠습니다. 어려운 문제를 어렵다고 말하는 글이 대체로 정직하기 때문입니다.

화면과 흔적과 시연으로 배우는 법

이런 에이전트는 대체 무엇으로 배울까요. 이 글에서 그리는 학습 재료는 크게 GUI 스크린샷과 상호작용 흔적, 사람의 시연, 그리고 합성 작업으로 이어집니다. 각각의 역할이 달라서 함께 봐야 합니다. 스크린샷은 눈을 만들고, 흔적은 손의 순서를 가르치고, 시연은 사람이 실제로 어떻게 헤매고 복구하는지를 보여주며, 합성 작업은 부족한 장면을 메워줍니다.

생각해보면 사람도 비슷하게 배웁니다. 처음 엑셀 정산을 배울 때 옆자리 동료가 클릭하는 순서를 어깨너머로 보고, 그다음에는 스스로 해보며 틀리고, 나중에는 비슷한 표를 여러 번 만지며 익숙해지죠. 에이전트의 학습도 이와 비슷합니다. 상호작용 trace는 클릭과 입력과 화면 변화가 시간 순서대로 남은 기록이라서, 여기서 에이전트는 무엇을 누른 다음에 화면이 어떻게 바뀌는지를 배웁니다. 사람의 시연은 특히 귀한데, 정답 순서뿐 아니라 헤맸던 구간과 되돌아간 구간까지 담겨 있기 때문입니다. 잘한 것만 보여주는 교본보다, 실수하고 고친 기록이 실전에는 더 도움이 되는 일종의 오답 노트처럼요.

합성 작업에 대해서는 기대와 걱정이 함께 듭니다. 한편으로는 사람이 다 해보기 어려운 다양한 화면을 값싸게 만들어낼 수 있어서 도움이 됩니다. 다른 한편으로는 합성 화면이 너무 깨끗하면 실제의 지저분함을 못 배우게 될 위험도 있습니다. 팝업도 없고 로딩도 없고 로그인이 풀리는 일도 없는 연습장만 수천 장 보여주면, 시험장에서 당황하는 모범생이 되기 쉽죠. 그래서 저는 재료의 종류보다 배합이 중요하다고 봅니다. 실제 화면의 어수선함과 합성 화면의 다양함이 어떻게 섞였는지, 짧은 작업과 긴 작업의 비중이 어떻게 잡혔는지가 결국 에이전트의 성격을 정합니다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 학습 재료도 마찬가지라서, 무엇을 얼마나 섞었는지가 성능 숫자보다 먼저 눈에 들어옵니다.

무엇을 재야 진짜 실력이 보일까

에이전트를 평가한다는 것은 결국 무엇을 잴 것인가를 정하는 일입니다. 이 글에서 제시되는 축은 작업 성공률과 위치 지정 정확도, 그리고 역동적인 웹과 운영체제 인터페이스 앞에서의 강건함입니다. 저는 이 세 축의 조합이 꽤 솔직하다고 느꼈습니다. 하나만 올리는 숫자보다야 세 가지를 함께 보는 쪽이 속이기 어렵기 때문입니다.

각 축이 따로 말하는 바가 있습니다. 작업 성공률은 끝까지 해냈는지를 묻습니다. 위치 지정 정확도는 손이 정확한지를 묻습니다. 강건함은 화면이 바뀌어도 같은 실력을 내는지를 묻습니다. 그런데 이 셋을 따로 떼어 읽으면 오해가 생깁니다. 예를 들어 위치 지정 점수가 높다고 해서 일이 끝나는 것은 아닙니다. 버튼을 정확히 눌렀는데 순서가 틀렸으면 실패니까요. 반대로 작업 성공률이 높다고 해서 눈이 좋은 것도 아닙니다. 특정 사이트에만 익숙해져서 외운 길로 간 것일 수도 있죠. 그래서 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 어떤 화면에서, 얼마나 긴 순서로, 얼마나 낯선 변화 앞에서 재었는지가 빠지면 숫자는 반쪽짜리가 됩니다.

실제 평가를 설계해 본 분이라면 공감이 가실 텐데요. 동적 인터페이스 앞에서의 평가는 특히 까다롭습니다. 오늘 뜬 배너와 내일 바뀔 메뉴, 가끔씩 느려지는 로딩, 사용자마다 다른 창 크기가 전부 변수이기 때문입니다. 같은 일을 시켰는데 월요일과 금요일 결과가 다르면, 그 차이는 모델 때문일까요 환경 때문일까요. 그래서 좋은 평가는 한 번의 성공이 아니라 여러 조건에서의 반복된 성공을 봅니다. 저는 이 글을 읽으며 평가 문항이 아니라 평가 환경을 먼저 상상했습니다. 어수선한 바탕화면, 로그인 풀림, 중간 팝업 같은 생활 속 방해물이 들어 있는 시험장 말입니다. 그런 시험장에서 살아남는 에이전트라면 숫자가 조금 낮아도 믿음이 갑니다.

클릭 하나가 권한 하나인 세계에서

컴퓨터를 대신 쓴다는 말은 바꿔 말하면 내 권한을 대신 쓴다는 뜻입니다. 클릭 하나가 파일 하나를 지울 수도 있고, 결제 하나가 돈을 움직일 수도 있습니다. 그래서 이 글에서 안전과 개인정보, 권한과 사람의 감독을 따로 떼어 다룬 것은 당연하면서도 반가운 선택이었습니다. 에이전트가 일을 잘하는 것만으로는 부족하고, 어디까지 해도 되는지를 아는 것이 함께 가야 하니까요.

구체적인 장면을 떠올려 보죠. 에이전트에게 영수증을 정리해 달라고 했는데, 화면에 같이 뜬 개인 메신저 알림을 읽고 요약해 버리면 어떻게 될까요. 일을 열심히 한 것은 맞지만 해서는 안 될 일을 한 셈입니다. 또 다른 장면도 있습니다. 자료를 옮기다가 삭제 버튼이 눈에 띄었는데, 확인 창을 제대로 읽지 않고 넘어가 버리는 경우죠. 사람은 대개 중요한 버튼 앞에서는 한 번 멈칫합니다. 이 멈칫을 에이전트에게 가르치는 것이 권한 설계입니다. 무엇을 볼 수 있고, 무엇을 누를 수 있고, 어디서는 반드시 사람에게 물어야 하는지를 미리 정해두는 것이죠.

그렇다면 사람의 감독은 어느 지점에 두어야 할까요. 매번 물어보면 에이전트를 쓰는 의미가 없고, 한 번도 안 물어보면 사고가 났을 때 늦습니다. 저는 돈과 삭제와 전송처럼 되돌리기 어려운 행동 앞에서 감독을 두는 방식이 현실적이라고 봅니다. 평소에는 에이전트가 화면을 읽고 움직이되, 경계선을 넘을 때만 사람을 부르는 식이죠. 물론 이 경계선을 정하는 일 자체가 어렵습니다. 사이트마다 중요한 버튼이 다르고, 같은 버튼도 사람마다 의미가 다르니까요. 그럼에도 불구하고 권한과 감독을 처음부터 설계에 넣는 쪽이 나중에 덧붙이는 쪽보다 훨씬 낫습니다. 브라우저를 대신 열어주는 편리함 뒤에는 언제나 누군가의 파일과 계정이 있다는 것을 잊지 말아야 합니다.

그래서 범용이라는 말은 어디까지 믿을 수 있을까

이제 처음의 단어로 돌아올 차례입니다. 범용이라는 말은 어디까지 믿을 수 있을까요. 저는 이 단어를 모든 사이트에서 완벽하다는 뜻으로 읽으면 실망하기 쉽다고 봅니다. 차라리 특정 사이트에 묶이지 않고 그래픽 인터페이스라는 공통 통로로 여러 일을 배워나가는 방향으로 읽는 편이 정확합니다. 같은 눈과 같은 손으로 메일도 정리하고 표도 만들고 예약도 바꾸는 식이죠. 그렇게 보면 범용은 완성 상태가 아니라 연습 방식에 대한 약속에 가깝습니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 화면을 보고 클릭한다는 설명만 들으면 마치 사람이 하는 일을 그대로 옮긴 것처럼 느껴지지만, 실제로는 화면이라는 좁은 창을 통해 컴퓨터를 쓰는 하나의 방식일 뿐이기 때문입니다. 뒤쪽에 깔린 파일과 프로그램 연결, 키보드 단축키, 복사해서 붙여넣는 지름길 같은 것들은 화면만 봐서는 다 보이지 않습니다. 그래서 화면 조작이 만능이라는 식의 한 줄 요약은 매력이 있지만 정확하지 않습니다. 진짜 의미는 다른 데 있습니다. 각 사이트마다 따로 자동화 코드를 짜지 않아도 되는 세상을 향한 첫걸음이라는 점이죠. 예전에는 사이트가 바뀌면 코드도 바꿔야 했는데, 화면을 읽는 에이전트라면 같은 방식으로 새 화면에 적응할 여지가 생깁니다.

저는 이 지점에서 시스템 이야기로 넘어가고 싶습니다. 범용 에이전트가 실제로 도움이 되려면 똑똑한 것을 넘어 자주 쓸 수 있어야 합니다. 화면을 계속 읽고 좌표를 계속 찍는 일은 계산도 많이 들고 시간도 걸립니다. 매 클릭마다 화면 전체를 다시 보고 생각하면, 사람은 답답해서 중간에 마우스를 빼앗게 되죠. 그래서 속도와 비용, 캐시와 중단, 실수했을 때 빨리 멈추는 장치가 함께 와야 합니다. 저희 팀 관점에서 보면 늘 같은 질문이 따라옵니다. 좋은 점은 알겠는데, 이걸 실제로 어떻게 서빙할까요. 아침마다 수십 명이 동시에 정산 화면을 맡기면 어디가 먼저 막힐까요. 이런 질문에 답하지 못하면 범용이라는 말은 연구실 안에서만 빛나는 말이 됩니다.

제가 다음 버전에서 보고 싶은 장면

마지막으로 제가 이 흐름에서 보고 싶은 것을 정리해 보겠습니다. 첫째는 지저분한 화면에서의 복구입니다. 로그인이 풀리고 팝업이 뜨고 메뉴가 바뀌는 아침의 노트북에서도, 한 걸음 물러나 다시 로그인하고 이어가는 모습 말입니다. 짧은 성공이 아니라 긴 연속성에서 나오는 신뢰가 보고 싶습니다. 둘째는 권한을 아는 손입니다. 민감한 알림은 스쳐 지나가고, 되돌리기 어려운 버튼 앞에서는 스스로 멈춰 사람을 부르는 에이전트 말입니다. 잘하는 것만큼 안 하는 것을 아는 것이 성숙함이니까요.

셋째는 평가의 솔직함입니다. 깨끗한 시험장에서 올린 숫자보다, 낯선 사이트와 바뀐 화면에서도 무너지지 않는 모습을 보여주면 좋겠습니다. 같은 일을 여러 번 시켰을 때 얼마나 비슷한 결과를 내는지, 화면이 조금 달라졌을 때 어디까지 버티는지가 궁금합니다. (참고로 요즘 웹은 일주일만 지나도 버튼 위치가 바뀌는 경우가 많은데요. 이런 생활 속 변화가 에이전트에게는 꽤 큰 시험이 됩니다.)

이 글을 덮으며 남는 질문은 결국 하나로 모입니다. 컴퓨터를 대신 쓴다는 것은 무엇을 대신한다는 뜻일까요. 클릭을 대신한다는 뜻일까요, 아니면 화면 앞에서 헤매는 시간을 대신한다는 뜻일까요. 저는 후자에 가깝다고 봅니다. Holo4가 가리키는 방향도 숫자를 올리는 경쟁이 아니라, 사람이 화면 앞에서 쓰는 시간과 신경을 줄여주는 쪽이라고 읽었습니다. 다음 버전에서는 그 시간이 정말 줄었는지를 보여주는 장면을 보고 싶습니다. 정산 화면 앞에서 커피가 식기 전에 일이 끝나는 장면 같은 것 말입니다. 그 장면이 쌓일 때 범용이라는 말도 조금씩 믿을 만해질 것입니다.