Clicky는 화면에서 눌러야 할 위치를 가상 커서로 짚어 줄 수 있지만, 실제 마우스를 대신 클릭하지 않으며 화면이 외부 Vision 모델로 전송되는 구조라 민감한 업무에는 그대로 쓰기 어렵습니다. “온디바이스 튜터”라는 표현보다 로컬 오버레이와 클라우드 추론을 결합한 보조 도구로 이해하는 편이 정확합니다. 도입 여부는 데모의 신기함보다 좌표가 낡았을 때 멈추는지, 어떤 화면이 전송되는지, 사용자가 최종 제어권을 갖는지를 기준으로 판단해야 합니다.
farzaa/clicky 저장소의 원문 설명은 macOS 화면 캡처, 음성 입력, Vision LLM, TTS와 투명 오버레이를 연결합니다. 텍스트로 “Edit 메뉴를 누르라”고 답하는 대신 해당 버튼 좌표에 파란 가상 커서를 보여 줘 사용자의 탐색 부담을 줄이는 아이디어입니다.
Input Layer는 단축키 뒤의 음성을 STT로 바꾸고 ScreenCaptureKit으로 현재 화면을 캡처합니다. Reasoning Layer는 이미지와 질문을 Cloudflare Worker 프록시를 거쳐 Vision 모델에 보냅니다. Output Layer는 설명 음성과 정규화된 좌표를 받아 macOS 오버레이에 표시합니다.
프록시는 앱에 모델 API 키를 직접 넣지 않는 데 도움이 되지만 화면 내용을 숨겨 주지는 않습니다. 소스 코드, 고객 이름, 알림과 비밀번호 입력창이 캡처에 포함될 수 있습니다. 전송 전 창 선택과 마스킹, 보존 정책이 필요합니다.
투명한 NSWindow를 가장 위에 띄우고 ignoresMouseEvents를 켜면 오버레이가 아래 버튼의 클릭을 가로채지 않습니다. 모델은 위치를 제안하고 사용자가 실제 클릭을 합니다. 잘못된 좌표가 곧바로 삭제나 결제로 이어지는 RPA보다 피해를 줄이는 human-in-the-loop 설계입니다.
원문의 Swift 코드는 borderless window와 좌표 변환 원리를 보여 주는 의사 코드입니다. 앱 권한 요청, 다중 화면 선택, 좌표계 원점, 응답 파싱과 오류 처리가 빠져 있어 완전한 macOS 앱 실행법이 아닙니다.
모델이 1000×1000 같은 정규화 그리드로 준 위치를 실제 화면 크기에 맞춰 변환해야 합니다. macOS의 logical pixel과 physical pixel, Retina 배율, 외부 모니터의 다른 DPI와 좌표 원점이 섞이면 오차가 생깁니다. 메뉴바, Dock과 화면 회전도 고려해야 합니다.
더 큰 문제는 시간입니다. 캡처 뒤 2~3초 동안 사용자가 스크롤하거나 창을 옮기면 정확했던 위치도 틀립니다. 응답 시점에 화면이 같은지 비교하고, 달라졌다면 다시 캡처하거나 힌트를 무효화해야 합니다. 좌표 정확도보다 잘못된 힌트를 표시하지 않는 조건이 먼저입니다.
예를 들어 모델이 (0.8, 0.2)를 반환했다고 해도 이것이 전체 데스크톱, 현재 모니터, 선택 창 가운데 어느 영역을 기준으로 한 값인지 모르면 화면 위치를 복원할 수 없습니다. 캡처 요청마다 화면 식별자, 캡처 사각형, 배율과 당시 창 위치를 함께 저장하고 응답에도 같은 요청 식별자를 붙여야 합니다. 단순히 현재 화면 너비와 높이를 곱하는 구현은 창이 다른 모니터로 옮겨졌을 때 조용히 틀릴 수 있습니다.
| 확인 항목 | 정상 조건 | 실패했을 때의 처리 |
|---|---|---|
| 캡처 영역 | 모델 입력과 오버레이가 같은 화면, 창을 가리킴 | 힌트를 버리고 다시 캡처 |
| 픽셀 배율 | 논리 좌표와 실제 캡처 픽셀의 비율이 기록됨 | 모니터별 보정값 재계산 |
| 화면 상태 | 요청 뒤 창 위치, 스크롤, 해상도가 바뀌지 않음 | 결과 표시 중단 |
| 표시 대상 | 좌표 주변의 UI 특징이 응답 설명과 일치함 | 사용자에게 재질문 요구 |
정확도 시험도 버튼을 한 번 맞히는 데 그치면 안 됩니다. 기본 디스플레이와 외부 디스플레이, 서로 다른 배율, 창 모드와 전체 화면, 메뉴바 위치를 나눠 목표점과 표시점 사이의 픽셀 오차를 기록해야 합니다. 평균만 보면 큰 오차가 가려지므로 중앙값과 상위 오차, 힌트를 취소한 비율을 함께 봅니다.
캡처한 화면에 요청 ID와 간단한 상태 지문을 붙이고, 응답 직전에 같은 영역을 다시 확인하는 방식이 현실적입니다. 완전한 이미지 일치는 커서 깜박임이나 애니메이션에도 깨질 수 있으므로 창의 위치, 크기, 활성 앱, 스크롤처럼 좌표에 영향을 주는 상태를 우선 비교합니다. 상태가 달라졌으면 오래된 좌표를 흐리게 남겨 두지 말고 즉시 폐기해야 합니다.
가령 사용자가 “내보내기 버튼이 어디야?”라고 묻고 기다리는 사이 설정 창을 닫았다고 합시다. 이전 화면의 오른쪽 아래 좌표를 새 화면에 표시하면 전혀 다른 삭제 버튼을 가리킬 수 있습니다. 실제 클릭이 사람에게 남아 있어도 시각적 안내는 강한 확신을 주므로, 불확실한 결과를 표시하지 않는 것이 단순한 경고 문구보다 중요합니다.
Worker를 사용한다는 사실과 로컬 처리를 한다는 주장은 별개입니다. 캡처 이미지가 어떤 모델 사업자에게 전달되는지, 요청, 응답 로그가 남는지, 오류 추적 도구가 원본을 보관하는지, 삭제가 가능한지를 경로별로 확인해야 합니다. API 키를 서버에 둔 것은 키 관리 대책이지 화면 데이터 보호 대책이 아닙니다.
가장 작은 캡처 범위를 기본값으로 삼고 알림, 다른 창, 브라우저 탭 제목처럼 질문과 무관한 영역을 제외하는 편이 좋습니다. 비밀번호 필드나 고객 식별 정보처럼 규칙으로 찾을 수 있는 항목은 전송 전 가리고, 탐지에 실패했을 때는 요청 자체를 막는 방식을 고려합니다. 음성에도 이름과 계정 정보가 섞일 수 있으므로 이미지와 오디오의 보존 정책을 따로 정해야 합니다.
개인용 공개 앱 튜토리얼에서 얻은 결과를 사내 콘솔로 바로 일반화할 수 없습니다. 검증용 계정과 합성 데이터를 써서 캡처 범위, 네트워크 실패, 모델의 좌표 누락, 잘못된 응답 형식을 먼저 시험해야 합니다. 민감 화면에서는 기능을 비활성화하고 기존 문서나 사람이 검토한 안내로 돌아가는 실패 경로가 있어야 합니다.
공개 앱 튜토리얼과 개인 테스트처럼 민감 정보가 없는 화면에서 시작하고, 다중 모니터별 좌표 오차, 평균 응답 시간, 잘못 짚은 비율을 측정합니다. 운영 콘솔에서 장애 대응을 안내하는 용도는 실수와 화면 유출의 비용이 커 사람의 기존 절차를 대체하면 안 됩니다.
평가 질문도 버튼 이름을 그대로 말하는 쉬운 사례와 “글자 크기를 바꾸고 싶어”처럼 의도를 UI 요소에 매핑해야 하는 사례를 나눕니다. 각 질문에서 올바른 화면을 고른 비율, 좌표 오차, 응답 전 화면이 바뀌어 결과를 폐기한 비율, 사용자가 안내를 이해한 시간을 기록합니다. 모델이 좌표를 반환하지 않거나 JSON 형식이 깨진 경우에는 화면 중앙 같은 기본값을 표시하면 안 되며, 안내를 중단하고 텍스트 설명으로 돌아가야 합니다.
예를 들어 설정 창의 “계정 삭제”와 “로그아웃”이 가까이 있다면 평균 20픽셀 오차도 충분히 위험할 수 있습니다. 버튼 크기와 행동의 되돌릴 수 있는 정도에 따라 허용 오차를 다르게 두고, 삭제, 결제, 권한 변경 화면에서는 좌표 표시 자체를 막는 정책이 안전합니다. 잘못 짚은 뒤 사용자가 교정한 기록은 다음 요청의 좌표를 임의로 보정하는 데 쓰지 말고 캡처 영역이나 변환 공식의 결함을 찾는 검증 자료로 사용합니다.
네트워크가 느릴 때의 사용성도 따로 봐야 합니다. 응답이 늦을수록 화면 상태가 달라질 확률이 커지므로 단순 로딩 표시만으로는 부족합니다. 일정 시간이 지나면 요청을 취소하고, 새 캡처 없이 늦게 도착한 결과는 버리며, 사용자가 동일 질문을 연속으로 보냈을 때 먼저 온 응답이 최신 오버레이를 덮지 않도록 순서를 확인해야 합니다.
완전한 로컬 Vision 모델로 바꾸면 화면 반출을 줄일 수 있지만 원문은 그 구현을 제공하지 않습니다. Clicky의 가치는 AI가 직접 조작하지 않아도 시각적 지시만으로 도움을 줄 수 있다는 데 있습니다. 실제 도입은 화면 캡처 범위와 삭제 정책, 좌표가 낡았을 때의 중단 규칙을 갖춘 뒤 판단해야 합니다.
아닙니다. 모델이 반환한 위치에 가상 커서를 표시할 뿐 실제 클릭은 사용자가 하므로, 안내와 자동 실행을 구분해야 합니다.
아닙니다. 캡처 영역, 논리, 물리 픽셀, Retina 배율, 모니터별 원점과 화면 이동을 함께 보정해야 합니다.
Worker는 앱에서 모델 API 키를 감추는 데 유용하지만 화면 자체는 추론 경로를 지나므로 별도의 마스킹, 보존, 삭제 정책이 필요합니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.