EyeDropper API로 화면의 모든 픽셀 색상 추출하기

피칭을 위해 경쟁사의 대시보드를 다시 만드는 상황입니다. 참고 자료는 그들의 런칭 영상에서 캡처한 4K 스크린샷과 Dribbble에서 받은 Figma 익스포트 두어 개입니다. 화면 전체에 서른 가지 색상이 흩어져 있죠 — 사이드바 배경, 버튼 세 가지 상태, 두 단계의 흐린 텍스트, 6단계 차트 팔레트. 기존 방식: 영역을 잘라 Photoshop에 붙여 넣고, 스포이트로 찍어 hex 값을 복사한 뒤 Tailwind 설정에 붙여 넣기. 이걸 반복합니다. 서른 번 왕복하고 나면 팔레트는 완성되지만 손목은 시큰거립니다.

화면 단위 색상 추출은 수년간 유료 도구의 영역이었습니다 — ColorSnapper, Sip, Just Color Picker, 그리고 자체 권한을 요구하는 수많은 Chrome 확장 프로그램이 있죠. Chromium 95부터는 일반적인 경우 이들 중 어느 것도 필요하지 않습니다. 브라우저가 EyeDropper API를 기본 탑재하기 때문입니다. 동작은 정확히 그것입니다: 시스템 확대경을 열고, 한 픽셀을 샘플링하고, sRGB hex 문자열을 돌려줍니다. ZeroTool의 Eyedropper Color Picker는 이 API를 얇게 감싸 포맷 변환과 최근 색상 스트립을 더한 도구입니다. 직접 만들었다면 다시 짜야 할 부분이죠.

60초 만에 보는 EyeDropper API

EyeDropper는 Chromium에서 시작되어 현재 WICG가 관리하는 웹 API입니다. 표면적은 매우 작습니다:

const eyeDropper = new EyeDropper();
const result = await eyeDropper.open();
console.log(result.sRGBHex); // "#3a7bd5"

open()은 Promise를 반환합니다. 브라우저는 시스템 수준의 확대경으로 커서를 전환하고, 사용자는 물리 화면의 아무 픽셀이나 — 브라우저 창 밖, 다른 앱 위에서도 — 클릭합니다. Promise는 sRGBHex 속성에 7자리 hex 문자열을 담은 객체로 resolve됩니다. 사용자가 Escape를 누르면 Promise는 AbortError로 reject됩니다.

이 API 위에 뭔가 만들기 전에 머릿속에 새겨야 할 제약이 셋 있습니다:

사용자 제스처 필수. open()은 클릭 또는 키 입력 핸들러 안에서만 호출할 수 있습니다. setTimeout 꼼수도, 페이지 로드 시 자동 호출도, 헤드리스 샘플링도 불가능합니다. 설계상 의도된 동작입니다 — 다른 앱의 픽셀을 조용히 읽는다면 그 자체가 스크린 캡처 익스플로잇이 됩니다.
호출당 한 번의 추출. 호출 한 번에 정확히 한 픽셀만 샘플링하고 확대경은 닫힙니다. 두 번째 색상을 잡으려면 사용자가 버튼을 다시 클릭해야 합니다. “계속 열어 두고 연속 샘플링”하는 모드는 없습니다.
sRGB 출력 한정. 반환되는 hex는 항상 sRGB 색 공간입니다. 사용자가 P3 디스플레이에서 광색역 이미지를 추출하면, 값은 sRGB로 색역 매핑된 뒤에야 코드에 도달합니다. 디스플레이 원본 색을 그대로 읽을 방법은 API가 제공하지 않습니다.

2026년 기준 브라우저 지원: Chrome, Edge, Opera (Chromium 95+) 모두 탑재합니다. Safari와 Firefox는 지원하지 않습니다. 기능 감지는 한 줄이면 충분합니다:

if ('EyeDropper' in window) {
  // EyeDropper 사용 가능 — 화면 추출 버튼을 연결
} else {
  // <input type="color">로 폴백하거나 안내 메시지 표시
}

도구 사용법

Eyedropper Color Picker를 열면 세 가지 입력 방식이 보입니다:

화면에서 추출. 버튼을 누르고, 화면의 아무 픽셀이나 클릭하세요. HEX, RGB, HSL 필드가 동시에 채워집니다. 이게 EyeDropper API 경로입니다 — Chromium 전용.
네이티브 피커. 표준 input type="color" 다이얼로그를 엽니다. Safari와 Firefox를 포함한 모든 브라우저에서 작동합니다. HSV 휠이 필요하거나 처음부터 새 색을 만들 때 유용합니다.
필드에 직접 입력. 알고 있는 hex, RGB, HSL 값을 붙여 넣으면 나머지 둘이 자동 계산됩니다. DevTools를 열지 않고 포맷 간 변환할 때 유용합니다.

마지막 여덟 개의 샘플은 localStorage로 유지되는 최근 색상 스트립에 남습니다. 스와치를 클릭하면 다시 불러올 수 있고, “Clear recent” 버튼으로 비울 수 있습니다. 어느 추출 경로에서도 네트워크 호출은 없으며, 데이터는 브라우저 밖으로 나가지 않습니다.

네 가지 구체적인 활용 사례

디자인 역공학

스크린샷이나 Figma 익스포트가 있고, 그 안의 팔레트를 Tailwind, CSS 변수, Sketch 스와치로 옮겨야 한다고 가정해 봅시다. 프리뷰 앱, Figma 데스크톱, 브라우저 탭 등 아무 창에서 참고 자료를 열고, “화면에서 추출”을 클릭한 다음 원하는 색을 탭하세요. 확대경은 1x 디스플레이에서도 정확히 한 픽셀을 짚을 수 있을 만큼 확대됩니다.

이 흐름은 대부분(80%)의 경우에 ColorSnapper / Sip 워크플로를 대체합니다. 전용 앱은 고정 플로팅 팔레트, 단축키 기반 빠른 샘플링, 이름이 붙은 라이브러리에서 여전히 유리합니다. 한 프로젝트에 색이 여섯 개뿐이라면 브라우저 API로 충분합니다.

브랜드 가이드 추적

마케팅에서 흔히 들어오는 요청: “예전 사이트는 정확히 이 파란색이었는데, 원본 파일을 잃어버렸어요. 오래된 PDF / 스크린샷 / Wayback Machine 캡처에서 색을 맞출 수 있나요?” 원본 토큰이 없으면 렌더링된 이미지에서 색을 읽어야 합니다. 이미지를 브라우저 탭에 띄우고, 다른 탭에서 도구를 열고, 다시 전환해 추출하세요. 확대경은 활성 탭이 아니라 화면 전체를 덮으므로, 이미지가 굳이 도구 내부에 들어 있을 필요가 없습니다.

비디오와 스트림 UI 검사

Twitch 오버레이, YouTube 썸네일, 작업 중인 AI 에이전트의 화면 녹화, 컨퍼런스 슬라이드 — 화면에서 재생되는 모든 것이 대상입니다. 프레임을 일시정지하고, “화면에서 추출”을 클릭하고, 픽셀을 클릭하세요. 보통 정적 파일을 요구하는 기존 디자인 도구로는 어려운 작업입니다.

한 가지 함정: 확대경은 디스플레이에 실제로 렌더링된 픽셀을 샘플링합니다. 즉 OS가 적용한 GPU 컴포지팅, 컬러 프로파일, HDR-to-SDR 톤 매핑이 모두 반영된 결과입니다. 추출한 색은 “원본 에셋이 지정한 값”이 아니라 “사용자가 보는 값”입니다.

접근성 점검

색을 추출하고 나면 보통 다른 색과의 대비를 검사하고 싶어집니다. 전경색을 추출하고, 배경색을 추출한 다음, 둘을 Color Contrast Checker에 붙여 넣어 WCAG AA/AAA 판정을 받으세요. 색각 이상 점검을 위해서는, 추출한 색을 Color Blindness Simulator에 통과시켜 deuteranopia(적록색맹)나 protanopia(적색맹) 사용자가 팔레트를 어떻게 인식하는지 확인할 수 있습니다.

한계와 우회 방법

Safari와 Firefox 사용자. EyeDropper 기능 감지는 false를 반환합니다. 도구는 “화면에서 추출” 버튼을 숨기고 네이티브 피커로 폴백합니다. 그 브라우저들에서 화면을 샘플링하려면 임시로 Chrome에서 참고 자료를 열거나, 시스템 유틸리티(macOS는 OS에 Digital Color Meter가 포함되어 있고, Windows는 PowerToys의 Color Picker가 있습니다)를 사용하거나, 검증된 확장 프로그램을 설치하세요.

DevTools에도 스포이트가 있습니다. Chrome과 Firefox DevTools의 Styles 패널에는 작은 피커가 들어 있습니다 — 규칙 창에서 색상 스와치를 클릭하면 현재 문서용 스포이트가 열립니다. 그 피커는 검사 중인 페이지로 범위가 한정됩니다: 뷰포트 픽셀만, 다른 탭이나 앱은 안 됩니다. 독립형 EyeDropper API는 물리 화면 전체를 다룹니다.

연속 샘플링 불가. 추출할 때마다 버튼을 새로 클릭해야 합니다. 50개의 색은 100번의 클릭을 의미합니다. 도구의 제약이 아니라 사용자 제스처 요구사항입니다.

P3와 HDR 클램핑. P3 이미지를 표시하는 광색역 디스플레이에서, 추출된 색은 코드에 도달하기 전에 sRGB로 색역 매핑됩니다. 같은 픽셀에서 Photoshop이 읽는 값과 hex가 몇 퍼센트 다를 수 있습니다 — Photoshop은 원본 에셋의 색 공간에서 읽고, 브라우저는 컴포지팅 이후의 sRGB 출력을 읽기 때문입니다. 컬러 매니지먼트가 중요한 작업이라면 컬러 매니지먼트 도구에서 검증하세요.

최근 색상은 localStorage에 저장됩니다. 브라우저 사이트 데이터를 지우면 스트립도 사라집니다. 사용자의 기기에만 남고 동기화되지 않습니다.

FAQ

Chrome DevTools에 내장된 스포이트와는 어떻게 다른가요?

DevTools의 피커는 검사 중인 문서에 종속됩니다 — 뷰포트 픽셀만, 다른 탭이나 앱은 닿지 않습니다. EyeDropper 웹 API는 브라우저가 OS에 시스템 수준 샘플링을 요청하기 때문에 물리 화면 전체에 닿습니다. 현재 페이지의 요소를 검사할 때는 DevTools를 쓰고, 그 외 모든 경우에는 독립형 도구를 쓰세요.

왜 여러 픽셀을 동시에 샘플링하거나 영역을 읽을 수 없나요?

단일 픽셀, 추출당 사용자 제스처는 API의 프라이버시 모델입니다. 영역을 읽거나 명시적 클릭 없이 페이지가 샘플링하도록 허용하면, 악의적인 페이지가 사용자가 열어 둔 다른 앱의 스크린샷을 찍을 수 있게 됩니다. WICG의 위협 모델은 제스처당 한 픽셀을 방어 가능한 최대 노출로 봅니다.

Safari와 Firefox 사용자는 어떻게 해야 하나요?

두 가지 경로가 있습니다. 같은 도구가 네이티브 input type="color" 피커를 노출하므로, 모든 브라우저에서 새 색상을 만드는 작업은 커버됩니다. 실제 화면 샘플링이 필요하다면 플랫폼 유틸리티를 쓰세요 — macOS Digital Color Meter(기본 탑재), Windows PowerToys Color Picker, 또는 신뢰할 만한 확장 프로그램. 그 엔진들에는 화면 샘플링을 위한 웹 표준 폴백이 없습니다.

왜 P3 디스플레이에서 Photoshop과 값이 다른가요?

Photoshop은 문서의 ICC 프로파일을 사용해 컬러 매니지먼트 파이프라인을 통과시켜 원본 에셋의 값을 읽습니다. 브라우저 스포이트는 OS가 디스플레이로 보낸 컴포지팅 이후의 sRGB 픽셀을 읽습니다. P3 에셋을 표시하는 P3 모니터에서 두 숫자는 일치하지 않습니다 — Photoshop은 광색역 원본을 보고, 브라우저는 sRGB 매핑된 출력을 봅니다. 각각 자신의 워크플로에서 정확합니다. 컬러 매니지먼트가 필요한 작업은 컬러 매니지먼트 에디터에서, sRGB 타깃으로 출시되는 UI 작업은 브라우저 값으로 충분합니다.

두 번째 모니터에서도 작동하나요?

네. 시스템 확대경은 연결된 모든 디스플레이에서 커서를 따라갑니다. 각 디스플레이의 컬러 프로파일과 감마가 샘플링 전에 적용되므로, 두 모니터에서 같은 논리적 색을 추출해도 디스플레이 캘리브레이션이 다르면 hex 값이 미세하게 달라질 수 있습니다.

최근 색상이 브라우저나 기기 간에 동기화되나요?

아니요. 스트립은 현재 origin의 localStorage에 저장됩니다 — 브라우저별, 프로파일별, 기기별. 사이트 데이터를 지우면 사라집니다. 계정도, 업로드도, 기기 간 동기화도 없습니다.

iframe이나 Chrome 확장 프로그램에서 이 API를 쓸 수 있나요?

동일 출처 iframe에서는, 클릭 핸들러가 iframe 안에 있고 부모가 허용하면 가능합니다. 교차 출처 iframe은 부모로부터 Permissions Policy 지시문을 받아야 합니다. Chrome 확장 프로그램의 콘텐츠 스크립트에서도 API를 사용할 수 있지만, 화면 샘플링을 수행하는 대부분의 확장 프로그램은 영역 읽기에 여전히 chrome.tabs.captureVisibleTab을 씁니다.