인공지능 기반 시선 추적을 위한 웹브라우저 확장 프로그램 연구

과거에는 안경이나 헤드마운트 형식의 전용 하드웨어 장비를 사용해서 안구 주변에 적외선 카메라를 배치하고 사용자의안구에 대한 해부학적, 기하학적 모델을 기반으로 한model-based 시선 추적 기술이 주로 사용되었으나 Gaze Capture[1]의 등장으로 딥러닝 기술을 활용하여 모바일 기기 사용자의 얼굴 이미지를 실시간으로 포착해서 시선을 추적하는 appearance-based 방식이 시작되었다. DVGaze[4]는 RGB 카메라 2대를 이용하여 추가적인 정보를 확보하고 Transformer 구조[5]를 활용하여 시선 추적 정확성을 향상시켰다. 이렇게 카메라를 2대 이상 사용하면 epipolar geometry를 이용하여 이미지의 중요 영역에 대한 3차원 정보를 복원[6]할 수 있다. 시선 추적에서 3차원 정보의 복원이 중요한 이유는 카메라와 눈까지의 거리 계산이 최종적인 예측 정확성에 큰 영향을 주기 때문이다. 따라서 깊이 카메라(depth camera)를 추가적으로 활용하여 직접적으로 눈과 카메라의 거리를 측정하는 기법[7]도 제안되었다. 이러한Appearance-based 시선 추적 방식에서는 대량의 학습 데이터가 필요한데 GazeNeRF[8]는 NeRF[9]를 시선 추적 학습 데이터 생성에 활용하기도 하였다. 또한 시선 추적의 전처리 단계로 눈깜박임 여부를 판단하는 과정도 매우 중요한데 역광, 조명 부족 등으로 인해 사용자의 얼굴이 거의 보이지 않는 환경에서도 눈깜박임을 효과적으로 인식하는 기술이 연구된 바 있다[10]. 최근에는 사용자마다 다른 해부학적 구조의 차이점을 극복하기 위한 개인화 연구[11]도 수행되고 있다.

시선 추적 기술은 차량 내 운전자 안전을 위한 시선 추적 연구[12]-[14], 모바일 상품 주문 사이트에서의 사용자 시선 추적[2], 영상 콘텐츠 분석[3] 등 다양한 분야에서 활용되고 있다.

본격적인 인공지능 기반 시선 추적 기술에서는 시선 추적의 정확성을 증가시키는 측면에 주력하는 것이 일반적이지만 제한적인 시선 추적 기술의 정확도를 보다 잘 활용하기 위한 연구들도 진행된다. DynamicRead[15]에서는 시선 제스처, 시선 고정 시간, 시선 추적, 텍스트 화면 전환 등 모바일 환경에서 빈번하게 수행되는 사용자 인터렉션을 최적화하는 방안을 연구하였다.

또한 사우디아라비아의 음식 배달 앱인 HungerStation은 시선 추적 기술을 활용한 캠페인으로 2023년 Canne 영화제 Create Commerce 수상작[16]으로 선정된 바 있다. 방송에도 활용되는 사례가 등장하고 있는데 2024년 글로벌 OTT(Over-the-top media service) 기업에서 방송한 예능 서바이벌 프로그램[17]에서 시선 추적 기술이 활용된 사례도 있다.

본 프로그램은 Google의 확장 프로그램 사양인 Manifest V3[18]를 기반으로 개발되었다. Manifest란 확장 프로그램의 메타 정보와 실행 방식, 보안 정책, 필요한 권한 등이 정의되어 있으며, 이는 확장 기능의 전체 동작을 제어하는 핵심 설정 파일이다. 표 2와 그림 1[19]에서는 크롬 확장 프로그램의 기본적인 구성요소와 각 기능을 제시하고 있다. 예를 들어 현재 접근한 웹페이지의 주소를 저장하고, 그 주소를 페이지 상단에 텍스트박스로 표시하는 확장 프로그램을 실행한다고 해보자. 실행 과정에서의 Popup.js, Background.js,Content.js의 동작 예시는 다음과 같다.

Table 2.

Chrome extension component configuration

Fig. 1.

Fig architecture of a Chrome extension

• Popup.js

크롬 확장 프로그램 아이콘을 누르면 열리는 팝업창에 해당한다. 팝업에 있는 ‘링크 저장 및 표시’ 버튼을 누르면, 현재 보고 있는 웹사이트 주소를 저장하고 그 주소를 화면에 표시하라는 명령이 전달된다.

• Background.js

사용자의 직접적인 상호작용 없이 백그라운드에서 실행되는 작업을 담당한다. 네트워크 요청, 데이터 저장, 탭의 상태 관리 등을 처리하며, 웹 어플리케이션의 서버 역할과 유사하다. 따라서 popup에서 메시지로 전달받은 주소를 저장하고, content에게 이 주소를 페이지에 띄워달라고 전달하는 과정을 거치게 된다.

• Content.js

웹 페이지의 DOM에 직접 접근하여 페이지에서 발생하는 이벤트를 처리한다. background에서 전달된 요청에 따라 현제 웹페이지 상단에 텍스트박스를 만들어 해당 주소를 표시한다.

본 연구를 위해 구현된 크롬 확장 프로그램을 EyeTrackerExtension이라고 칭하겠다. EyeTracker Extension은 AI 기반의 Appearance-based 방식으로 사용자의 PC·노트북에 내장된 RGB 카메라를 자동 인식하여 시선 추적을 수행한다. 전체적인 시스템 구조는 그림 2와 같다. 사용자가 임의의 탭을 열고, 해당 탭의 팝업창에서 시선 추적 시작 버튼을 누른다, Background scipt에서 EyeTracker가 적용된 Iframe을 생성하여 사용자가 상호작용한 탭에 부착한다. 즉 시선 모듈은 popup.js의 작용에 따라 background에서 시선 추적 모듈이 포함된 iframe을 생성해 현재 탭에 부착하는 식으로 구성된다.

Fig. 2.

Fig architecture of a EyeTracker Extension

• Popup.js

사용자가 시선 추적 시작 버튼을 누르면, 입력된 정보에 따라 해당 모듈을 초기화하고, 실행하라는 메시지를 Background.js에 보내게 된다. 시선 모듈 초기화 시 연산의 정확성을 위해 사용자와 모니터와의 거리, 모니터 사이즈에 대한 정보가 필요하다. 따라서 해당 정보도 시선 추적 시작을 지시하는 메시지와 함께 Background.js에 넘겨주게 되어 초기화에 이용된다.

• Background.js

시선 추적 모듈을 백그라운드에서 관리하는 데 사용하였다. 백그라운드 스크립트는 탭 상태를 관리하고, 추적 상태를 유지하며, 데이터와 설정을 저장하는 역할을 한다. 시선 추적 모듈이 포함된 iframe을 각 탭에 부착하는 환경 설정을 실행하고, iframe 생성 명령을 Content.js 에게 보낸다.

• Content.js

해당 프로그램에서는 시선 추적 데이터를 웹 페이지에 실시간으로 표시하고, 사용자의 데이터에 반응하여 페이지를 동적으로 수정하도록 구현하였다. 이와 같이, content script는 다른 트리거 없이 모든 탭에 계속 실행되기 때문에, static하게 유지되도록 background에서 시선 추적 모듈과 데이터를 관리하도록 설계되었다.

3) Manifest 설정

위에서 언급한 내용은 기본적인 동작을 위한 시스템 설계이고, 시선 모듈의 원활한 동작을 위해 manifest.json 파일 내부에 추가로 설정해야 할 요소들은 다음과 같다.

• Content_security_policy

COEP(Cross Origin Embedder Policy)와 COOP(Cross Origin Opener Policy)는 시선 모듈 실행 시 후술할 SharedArrayBuffer 이용을 위해 Cross-Origin-Isolation 환경 설정이 필수적이다. 보안 설정을 만족하기 위해 적용한 설정 목록은 표 3을 참고하면 된다.

Table 3.

Key attributes and values in manifest file

• Permissions

Chrome Extensions에 내장되어 있지 않은 API 기능을 이용할 때 허용해야 한다. 본 연구에서 사용한 주요 API는 “tabs”, “scripting”, “storage”, “alarms”, “declarativeNetRequest”이다.

• Web_accessible_resources

Chrome Extensions를 실행하기 위해 manifest에서 등록해놓은 파일 이외에 실행할 파일을 등록한다. 본 프로그램에서는 seeso module 내부의 파일이 여기에 해당한다.

그림 3은 VisualCamp사에서 Chrome Extensions 용도로제공받은 Seeso 모듈의 구조도이다. Seeso module은WASM(WebAssembly) 기반으로 동작하며 실제 시선 연산을 처리하는 부분과, 해당 내용을 실제 적용 코드에 활용하기 편하게 설계된 부분이 존재한다. ‘import’ 및 ‘export’ 키워드를 사용해 시선 추적 모듈을 외부에 제공하고, 실제 적용 환경의 코드에서 import 문으로 활용할 수 있도록 구성되어 있다.

Fig. 3.

Structure of the Seeso Module

Seeso-web-sample[20]에서도 확인할 수 있다시피, HTML 문서에서 easy-seeso.js를 이용하기 위해서는 반드시 <script type=“module”>을 사용하여 모듈을 로드해야 한다. 이는 자바스크립트 사양 중 ES(ECMAScript)모듈의 구조를 따르기 때문이다. 이는 외부 스크립트 로딩 시 CORS 정책의 영향을 받기 때문에[21] 따라서 적용할 HTML 문서에 앞서 서술했던 Cross-Origin-Isolation 보안 헤더를 설정해야 프로그램이 제대로 동작할 수 있다.

기존 Seeso 모듈은 WASM 연산을 외부 CDN 링크를 통해 로드하는 방식이었다. Seeso 객체를 생성하는 데 사용되는 워커는 Blob[22] 객체를 통해 WASM 파일을 참조했으나, createObjectURL()[23]은 확장 프로그램 보안 정책에 따라 차단된다. 따라서 chrome.runtime.getURL()을 사용하여 확장 프로그램 내부 자원으로 직접 접근하도록 수정하였다[24].

각 탭에서 동작하는 시선 추적 모듈은 iframe 내부에 시선 추적을 연산하는 스크립트를 포함한 형태로 대상 페이지에 적용된다. 이렇게 iframe 형태로 불러온 시선 추적 모듈을 SeesoIframe이라고 부르겠다.

Seeso 모듈은 iframe 기반으로 구성되며, iframe은 부모 문서인 확장 프로그램의 content script의 CSP 및 보안 정책을 따르게 된다. 원본 모듈은 Webpack 빌드 시 ‘devtool: “none”’ 설정 없이 eval() 함수를 포함하고 있어 Manifest V3 환경에서는 로드 자체가 불가능하다[25]. eval 사용은 sandbox iframe을 통해 우회 가능하지만[26], sandbox 속성이 적용된 iframe은 Cross-Origin-Isolation 설정이 불가능하며[27], 이에 따라 SharedArrayBuffer를 사용하는 WebAssembly 연산이 제한된다[28],[29].

따라서 background.js에서 확장 프로그램 설치 시‘chrome.runtime.onInstalled’ 이벤트를 활용해 ‘chrome.declarativeNetRequest’ API로 보안 헤더를 동적으로 설정해야 한다[30]. 여기서 updateDynamicRules 메서드를 사용해 보안 헤더를 설정하는데, responseHeaders 인자에 적용한 각 헤더는 표 4와 같다.

Table 4.

HTTP header configuration for cross-origin security

4) SeesoIframe 실행

시선 추적 기능을 탭에 삽입하기 위해, chrome.tabs.query ({ active: true, currentWindow: true }, callback)을 이용해 사용자가 현재 보고 있는 활성 탭을 확인한 후, chrome.scripting.executeScript를 통해 해당 탭의 DOM에 SeesoIframe을 생성한다. 시선 추적 모듈은 iframe을 통해 활성 탭와만 적용되며, iframe 생성 시 필요한 속성은 표 5에 정리하였다.

Table 5.

Attribute values set when creating an iframe

시선 추적 기능만 수행할 것이므로 해당 iframe은 display: none 속성으로 설정하며, Cross-Origin-Isolation 보안 환경과 카메라 접근이 가능하도록 관련 속성들을 함께 적용해야 한다.

iframe의 src는 seeso.html로 지정되며, 해당 HTML은 ES6 모듈로 작성된 시선 추적 코드를 불러오므로 import가가능한 구조이다. 이때 경로 설정은 chrome.runtime.getURL()을 이용하여 확장 프로그램 내부 리소스를 참조하고, 해당HTML 파일은 manifest.json의 web_accessible_resources항목에 등록되어야 모든 탭에 서 접근 가능하다.

이렇게 생성된 iframe 객체는 전역 변수인 window.seesoIframe에 저장되며, 추후 시선 추적 종료 시 해당 객체를 참조하여 제거할 수 있도록 설계되었다. 이를 통해 iframe의 상태를 통합적으로 관리할 수 있다.

설정을 모두 마친 후에는 Seeso API의 인증 키 설정이 필요하다. Seeso API는 URL 주소 기반 인증 방식을 사용하므로, 키 고정 과정이 요구된다. 이를 위해서는 먼저[31] Chrome Web Store에 개발자로 등록한 뒤, 새로운 확장 프로그램을생성해야 한다. 프로그램이 생성되면 해당 URL에 대해 고정된 API 키가 발급되며, 이 키를 manifest.json에 적용하여 테스트 환경에서도 정상적으로 시선 추적 기능을 사용할 수 있다.

단, 해당 확장 프로그램을 Chrome Web Store에 공식적으로 배포하는 경우에는 manifest.json에서 별도의 키 설정 없이도 정상적으로 작동하며, JSON 내에 키를 명시할 필요는 없다.

크롬 확장 프로그램은 Background, Popup, Content Script의 서로 다른 실행 환경간 직접적으로 같은 메모리 공간을 공유하지 않는다. 따라서 데이터를 주고받기 위해 표 6에서 제시하고 있는 통신 방법을 사용해야 한다[32]. 그림 4에서는 구성 요소간 데이터 통신 방법을 도식화하여 제시하였다.

Table 6.

Communication methods in Chrome extensions

Fig. 4.

Communication architecture applied to the EyeTrackerExtension

비유하자면 content script는 현재 탭을 자기 자신처럼 다루기 때문에 DOM 접근이 자유로운 상태라고 할 수 있다. 그리고 시선 모듈이 포함된 iframe은 현재 탭 DOM 내부에 존재하는 요소이다. 그러므로 content scripr와 iframe 사이에는 자식 관계가 설립한다고 볼 수 있다. 이 경우 표준 웹 API인 window.postMessage()를 통해 직접 양방향 통신이 가능하다.

iframe에서 부모 창인 content script로 메시지를 보내기 위해서는 window.parent.postMessage()를 사용하면 된다.

content script와의 통신은 편리하지만, 페이지 수명에 종속적인 특성 때문에 데이터 손실 위험이 크다. 유지보수와 안정적인 데이터 저장을 위해서는 background script에서 데이터 저장을 처리하는 것이 유리하다.

iframe에서 background로 데이터를 전송하기 위해 chrome.runtime.sendMessage를 사용한다.

chrome.storage.local[33]은 웹 페이지의 로컬 저장소인 localStorage[34]와는 다르다. 표 7에 관련 내용이 제시되어 있다. localStorage는 background, popup, content script 각 도메인마다 별도의 저장소를 가지고 있어 데이터 공유가 불가능하고, chrome.storage.local은 확장 프로그램의 모든 요소가 데이터를 공유할 수 있도록 설계되었다. 즉 확장 프로그램 전체에서 5MB의 공유 메모리를 가지는 게 된다.

Table 7.

Storage types and capacity limits in Chrome extensions

시선 데이터 특성상 IndexedDB[35]를 이용해 저장하는 것이 적합하다고 판단된다. 키-값 쌍으로 데이터를 저장하며, 데이터의 효율적 관리 및 저장에 특화되어 있다. iframe 내부의 시선 콜백 함수에 indexedDB 저장 로직을 추가하여 구현해본 결과, 시선 추적이 중지되어 iframe이 제거되었을 때는 content script에서 indexedDB를 감지할 수 없게 된다. 시선 추적이 활성화되어 iframe이 부착되었을 때만 indexedDB를 확인할 수 있다. 중지와 시작을 반복해도 이전의 데이터가 손실되지 않고 누적되어 집계되는 것을 확인하였다.

시선 데이터 저장을 위한 통신 구조로 두 가지 방법을 비교하였다. 그림 5를 보면, A 방법은 iframe 내부에서 indexedDB를 직접 열어 저장하는 방식이고, B 방법은 시선 데이터가 연산 될 때마다 Iframe에서 background로 sendMessage를 통해 전송 후 처리하는 방식이다. 이 두 방식에 대한 실제 실험 데이터를 그림 6에서 제시하고 있다. A 데이터는 초반에는 10~20회 정도가 측정되다가, 시간이 경과하면 초당 1초 정도의 데이터를 전달하는 것을 볼 수 있다. B 데이터는 꾸준하게 20~30회 정도가 측정되는 것을 볼 수 있다. 이는 시선 추적 모듈의 성능 저하가 아닌, 콜백 함수의 실행에서 병목 현상이 발생한 것으로 볼 수 있다.

Fig. 5.

Experimental procedure architecture

Fig. 6.

Graph of measured gaze data in counts per second

시선 좌표가 연산될 때마다 사용자가 등록한 콜백 함수가 실행되며, 이 함수가 초당 처리 가능한 횟수를 초과할 경우, 실행 명령이 누적되어 메모리 병목 현상이 발생할 수 있다. 따라서 콜백 함수는 최대한 간단한 저장 전용 함수로 구성하며, 실행 효율을 높이는 최적화가 필요하다.

시선 좌표를 indexedDB에 저장하는 과정에서도 일정 수준의 지연이 발생한다. 연산 시점과 저장 시점의 timestamp 차이를 측정한 결과, 1888개의 데이터에서의 평균 저장 지연 시간은 약 34.64ms정도로 측정되었다. 그림 7은 이 지연시간을 시각화한 것이다.

Fig. 7.

Graph of delay time for storing data in IndexedDB

Content에서 접근하며, 본 실험에서는 대부분의 브라우저에서 사용 가능한 elementFromPoint()[36] 메서드를 사용하여 DOM 요소를 계산하였다. 해당 메서드는 document object에서 사용 가능하고, 그림 8의 C 예시처럼 지정된 좌표 점에 의거해 가장 위에 있는 Element를 반환한다. Content에서 대상 웹사이트의 DOM 트리를 받아오고 필터링 해 background에서 localStorage에 저장한 뒤, Content에서 현재 시선 좌표와 연산하는 과정을 직접 구현할 수도 있으나, localStorage의 용량이 5MB 정도라는 점과 이 연산 과정에서 속도 저하가 심하게 일어났기 때문에 DOM의 추출과 저장은 IndexedDB를 이용하고, 현재 시선과 일치하는지의 연산은 elementFromPoint()를 사용해 필요한 정보만 수집하는 것이 바람직하다.

하지만 이 elementFromPoint()의 호출 트리거 주기는 고려해야 할 사항이다. 앞서 그림 6에서 보였던 것처럼 callback 함수에 데이터 저장, 메시지 송신 등의 과정을 추가하면 속도 저하가 일어나게 된다. 그림 9는 각각 시행한 TPS 결과를 시각화 한 것 이다. 동일한 환경 안에 있는 content로의 postMessage 및 console.log로 확인했을 때의 결과는 초당 약 30회 정도가 출력되었다. content에서 elementFromPoint 연산까지 추가했을 때는 초당 1개정도로 출력된다.

Fig. 9.

Comparison of gaze data processing speed: console.log vs. DOM matching check