DEV Community: 이종현

업무 생산성 도구 보안 검증: 로컬 처리 아키텍처가 기준이 되는 이유

이종현 — Tue, 11 Aug 2026 04:53:35 +0000

스크린샷이 서버로 나가는 순간, 그 파일은 통제 범위 밖이다. Manual Maker는 녹화 중 캡처한 스크린샷을 외부 서버로 전송하지 않고 로컬 기기 내에서만 처리해 매뉴얼 초안을 생성한다. 이 글은 그 메커니즘이 어떻게 작동하는지, 그리고 보안성 높은 업무 생산성 도구를 고를 때 어떤 기준으로 판단해야 하는지를 다룬다.

TL;DR

업무 생산성 도구 도입 전 스크린샷·입력값·행동 로그 각각의 전송 경로를 반드시 확인한다.
로컬 처리 방식과 마스킹 기반 클라우드 처리 방식은 설계 철학이 다르며, 어느 쪽이 조직 보안 정책에 맞는지 먼저 판단해야 한다.
Manual Maker는 스크린샷을 서버로 보내지 않고, 행동 로그와 Document Parse 맥락만 생성 시점에 전송한다.
비밀번호·주민번호형 입력값은 자동으로 마스킹·블러 처리된다.

업무 생산성 도구 도입 시 보안 담당자가 필수로 검증해야 할 항목

업무 생산성 도구를 도입할 때 보안 담당자가 가장 먼저 확인해야 할 것은 "데이터가 어디에 머무는가"다. 도구 카테고리를 불문하고 아래 세 가지 경로를 명확히 파악해야 한다.

스크린샷 또는 화면 이미지
- 로컬 기기에만 저장되는지, 외부 서버로 업로드되는지 구분한다.
- 업로드된다면 저장 기간, 암호화 방식, 제3자 공유 여부를 서비스 약관과 개인정보처리방침에서 직접 확인해야 한다.
입력값 및 텍스트 로그
- 사용자가 화면에 입력하는 텍스트가 어느 시점에 어느 서버로 전달되는지 확인한다.
- 비밀번호 필드, 주민등록번호형 입력, 신용카드 번호 등 민감 정보가 로그에 포함될 가능성이 있다.
행동 로그(클릭·스크롤·네비게이션 이벤트)
- 행동 로그 자체가 업무 흐름의 상세 기록이다. 실시간 스트리밍인지 배치 전송인지, 그리고 생성 완료 후 삭제 정책이 있는지 확인한다.

조직의 보안 정책이 강할수록 이 세 경로 중 하나라도 불명확하면 도입을 보류하는 게 맞다. 도구 공급사가 위 세 항목을 아키텍처 문서나 공개 FAQ에서 명시하지 않는다면, 별도 요청 없이는 알기 어렵다.

로컬 기반 데이터 처리와 마스킹 텍스트 전송 방식의 차이는 무엇인가?

두 접근법 모두 "민감 정보를 보호한다"는 목표를 공유하지만, 메커니즘이 다르다.

로컬 처리 방식

스크린샷을 포함한 이미지 파일이 기기 밖으로 나가지 않는다.
초안 생성에 필요한 맥락은 DOM 구조, 클릭 좌표, 요소 레이블 같은 구조화된 텍스트 형태로만 서버에 전달된다.
스크린샷은 로컬 스토리지(IndexedDB 등)에 저장되고, 사용자가 직접 열람하거나 ZIP으로 내보낼 때만 외부로 이동한다.

마스킹 기반 클라우드 처리 방식

화면 이미지 자체는 서버로 전송하되, 민감 필드(비밀번호, 주민번호 등)는 캡처 전 블러 또는 마스킹 처리한다.
처리 정확도가 높지만, 이미지가 외부 인프라를 경유한다는 사실 자체가 특정 규제 환경(금융, 의료, 공공)에서 허용되지 않을 수 있다.
서버 측 OCR이나 AI 처리가 마스킹 이후에도 잔여 데이터를 분석할 가능성을 배제할 수 없다.

어느 방식이 "더 낫다"는 절대 기준은 없다. 조직의 데이터 분류 정책과 규제 요건에 따라 선택이 달라진다. 다만 로컬 처리 방식은 "이미지 자체가 이동하지 않는다"는 구조적 보장을 제공하고, 마스킹 방식은 "이미지는 이동하지만 민감값을 제거한다"는 절차적 보장에 의존한다.

Manual Maker가 스크린샷 전송 없이 Document Parse 맥락을 처리하는 방식

Manual Maker의 핵심 구조는 세 단계로 나뉜다.

1단계: 로컬 캡처 및 저장

사용자가 녹화를 시작하면 확장 프로그램이 클릭 직전 스크린샷을 캡처하고 IndexedDB에 저장한다. 이 시점에서 이미지는 브라우저 로컬 스토리지 안에만 존재한다. 비밀번호 필드와 주민번호형 입력값은 캡처 전 자동으로 마스킹 또는 블러 처리된다.

2단계: 맥락 추출 및 서버 전송

초안 생성을 요청하면, 서버로 전송되는 것은 스크린샷이 아니라 행동 로그다. 행동 로그에는 클릭한 요소의 레이블, URL 변경, 입력 필드 타입, DOM 맥락 등이 구조화된 텍스트 형태로 담긴다. 이 행동 로그는 생성 시점에만 전송되고, 스크린샷 이미지 파일은 전송 대상이 아니다.

서버 측에서는 Upstage Document Parse가 이 구조화된 맥락을 분석해 화면 흐름을 파악한다. Upstage Document Parse는 문서 레이아웃 및 텍스트 구조 분석에 특화된 API로, 스크린샷 없이도 DOM 기반 텍스트 맥락을 처리할 수 있다.

3단계: 초안 생성 및 자기검증

Solar Pro 3 모델이 행동 로그와 Document Parse 결과를 바탕으로 단계별 매뉴얼 초안을 작성한다. 이후 에이전트는 자기검증 루프를 거쳐 약한 단계를 식별하고 재작성한다. 검증 기준은 단계 누락 여부, 레이블 정확도, 절차 순서의 일관성이다.

생성된 초안은 사용자가 편집기에서 직접 수정할 수 있으며, 수동 수정 내용은 이후 자기검증 루프에서 덮어쓰지 않도록 보호된다. 최종 결과물은 Markdown, Word, PDF, 또는 스크린샷이 포함된 ZIP 형태로 내보낼 수 있다.

로컬 기반 처리 아키텍처에 관한 추가 기술 설명은 로컬 데이터 처리 보안 페이지에서 확인할 수 있다.

데이터 프라이버시가 담보되는 업무 설명서 자동화 도구 선택 기준은?

도구를 선택하기 전, 아래 항목을 체크리스트로 쓸 수 있다.

스크린샷 처리 경로

이미지가 외부 서버로 전송되는지 여부를 공식 문서에서 확인한다.
"암호화 전송"이라는 표현만으로는 이미지가 이동하지 않는다는 의미가 아님에 주의한다.

민감 입력값 처리 방식

비밀번호, 주민번호, 금융 정보 등이 캡처 및 로그에서 자동 제외되는지 확인한다.
마스킹 처리가 클라이언트 측(브라우저)에서 이루어지는지, 서버 수신 후에 이루어지는지 구분이 중요하다.

행동 로그 보존 정책

로그가 생성 완료 후에도 서버에 남아 있는지, 삭제 정책이 명시되어 있는지 확인한다.
장기 보존되는 행동 로그는 개인정보처리방침 상 별도 고지 의무가 발생할 수 있다.

녹화 시작 및 종료 제어권

사용자가 직접 시작하고 끝내는 구조인지, 백그라운드에서 상시 동작하는 구조인지 확인한다.
상시 녹화 방식은 규제 환경에서 동의 범위 문제를 일으킬 가능성이 있다.

무료 vs 유료 티어 데이터 처리 차이

Manual Maker 기준으로 보면:
- 무료 티어: 매뉴얼 10페이지까지 생성 가능, 로컬 처리 아키텍처 동일하게 적용
- Pro 티어: 10페이지 초과 시 필요, 일회성 평생 라이선스 방식, 처리 메커니즘은 동일

무료와 유료 모두 스크린샷 미전송 원칙은 동일하게 유지된다. 페이지 수 제한만 다르다.

자주 묻는 질문

스크린샷이 서버로 전송되지 않으면 초안 품질이 낮아지지 않나요?

그렇지 않다. Manual Maker는 스크린샷 대신 DOM 맥락과 행동 로그를 Upstage Document Parse로 분석해 절차를 재구성한다. 화면 이미지 없이도 클릭 요소의 레이블, 순서, URL 변경 등 구조 정보는 충분히 추출된다. 내보낼 때 스크린샷을 포함하고 싶다면 로컬에서 ZIP에 함께 패키징할 수 있다.

비밀번호가 입력된 화면도 녹화하면 로그에 남나요?

비밀번호 필드와 주민번호형 입력값은 캡처 전 자동으로 마스킹·블러 처리된다. 행동 로그에도 해당 필드의 값이 아닌 필드 타입 정보만 기록된다. 민감 값 자체는 로컬 스토리지와 서버 전송 행동 로그 어느 쪽에도 포함되지 않는다.

IndexedDB에 저장된 데이터는 브라우저를 닫으면 어떻게 되나요?

IndexedDB는 브라우저가 닫혀도 데이터가 유지된다. 명시적으로 삭제하거나 브라우저 데이터를 초기화하지 않는 한 로컬에 남는다. 사용자가 언제든 확장 프로그램 내에서 개별 세션 데이터를 삭제할 수 있다.

금융·의료 등 규제 산업에서도 사용할 수 있나요?

로컬 처리 아키텍처 자체는 이미지가 외부 인프라를 경유하지 않는다는 구조적 조건을 충족한다. 다만 조직별 규제 요건과 데이터 분류 정책은 각 담당자가 직접 검토해야 한다. 도구 공급사의 처리 구조를 법무·보안팀에 공유해 적합성을 판단하는 절차를 권장한다.

무료 티어와 Pro 티어의 보안 처리 방식이 다른가요?

다르지 않다. 스크린샷 미전송, 행동 로그 생성 시점에만 전송, 민감 입력값 마스킹 처리는 무료와 Pro 모두 동일하게 적용된다. 차이는 생성 가능한 매뉴얼 페이지 수뿐이다.

업무 매뉴얼 자동화 도구를 고를 때 "얼마나 빨리 문서가 만들어지는가"보다 먼저 "데이터가 어디에서 처리되는가"를 확인하는 것이 맞다. Manual Maker는 스크린샷을 서버로 보내지 않고 행동 로그와 Document Parse 맥락만으로 Solar Pro 3를 통해 초안을 생성하는 로컬 우선 아키텍처를 취한다. 조직 보안 정책과 맞는 도구인지 직접 확인해보려면 보안이 확보된 로컬 업무 생산성 도구 알아보기에서 시작할 수 있다.

브라우저 화면을 드래그 캡처해 LLM에 이미지로 코딩 질문하는 법

이종현 — Tue, 11 Aug 2026 04:43:27 +0000

UI 버그를 텍스트로 설명하다 보면 반드시 막히는 순간이 있다. "헤더 오른쪽 버튼이 모바일에서 잘려요"라고 써도, LLM은 실제 레이아웃을 볼 수 없어 엉뚱한 CSS를 제안한다. PromptShot으로 해당 영역을 드래그 캡처하면 PNG 이미지와 LLM용 프롬프트가 클립보드에 동시에 복사된다. 그 상태로 Cursor나 ChatGPT에 붙여넣으면 된다.

UI 수정과 버그 리포트에서 스크린샷 질문이 필요한 이유

텍스트만으로 UI 문제를 설명하는 방식에는 구조적인 한계가 있다. 레이아웃 깨짐, 색상 불일치, 특정 컴포넌트의 겹침 같은 시각적 버그는 아무리 글로 정확히 써도 LLM이 재현하기 어렵다. 결국 LLM은 문제를 추측하고, 개발자는 그 추측을 바탕으로 수정을 시도하고, 맞지 않으면 다시 설명하는 루프를 반복하게 된다.

이미지를 함께 넘기면 그 루프가 짧아진다. 실제 화면이 컨텍스트가 되므로, LLM은 문제를 추측하는 대신 보이는 것에 집중해 답한다. 특히 다음 상황에서 효과가 두드러진다.

특정 뷰포트에서만 재현되는 레이아웃 버그
디자인 파일과 실제 구현 사이의 간격·색상 차이
서드파티 컴포넌트를 커스터마이징할 때 어느 클래스가 적용됐는지 확인
버그 리포트를 작성할 때 재현 화면을 첨부하면서 동시에 수정 방향을 묻는 경우

전체 화면을 캡처해서 붙이면 LLM에 불필요한 정보가 너무 많이 들어간다. 수정이 필요한 컴포넌트만 잘라서 넘기는 편이 답변 품질이 높다. 그게 영역 드래그 캡처를 쓰는 이유다.

PromptShot으로 영역을 드래그해 이미지와 프롬프트를 동시에 복사하는 과정

PromptShot은 Chrome 확장 프로그램으로, 설치 후 브라우저 위에서 직접 동작한다. 외부 앱 전환 없이 캡처부터 LLM 붙여넣기까지 한 흐름으로 이어진다.

1단계: 확장 프로그램 설치

Chrome 웹 스토어에서 PromptShot을 설치한다. 설치가 완료되면 주소창 오른쪽 퍼즐 아이콘 영역에 PromptShot 아이콘이 생긴다.

2단계: 영역 캡처 시작 (Alt+Shift+S)

캡처하고 싶은 페이지에서 Alt+Shift+S를 누른다. 커서가 십자선으로 바뀌고 드래그 모드가 활성화된다. 마우스를 드래그해 캡처할 영역을 선택하면 된다. 버튼 하나, 카드 컴포넌트 하나처럼 정확히 문제가 있는 부분만 잡는 것이 핵심이다.

3단계: 캡처 형식 선택 (Alt+1 또는 Alt+2)

영역을 드래그한 뒤 두 가지 형식 중 하나를 고른다.

단축키	복사 내용	적합한 상황
`Alt+1`	PNG 이미지만 클립보드에 복사	이미지를 별도 파일로 저장하거나 GitHub 이슈에 첨부할 때
`Alt+2`	LLM용 프롬프트 텍스트 + PNG 이미지를 함께 복사	Cursor, ChatGPT, Claude에 바로 붙여넣을 때

AI 코딩 질문 목적이라면 Alt+2가 기본이다. 화면에 보이는 영역 이미지와 함께 "이 화면의 UI를 분석해 주세요"처럼 미리 구성된 프롬프트 텍스트가 클립보드에 올라간다. LLM 창을 열고 Ctrl+V만 누르면 이미지와 질문이 동시에 붙여넣어진다.

4단계: LLM에 붙여넣고 추가 질문 작성

Cursor의 채팅 패널, ChatGPT 입력창, Claude 대화창 어디든 Ctrl+V로 붙여넣은 다음 구체적인 질문을 이어 쓴다. 예를 들어 이런 식이다.

[붙여넣은 이미지]
[자동 생성된 프롬프트]

추가 질문: 이 버튼이 모바일 375px 뷰포트에서 오른쪽으로 잘리는 이유와
수정 방법을 알려줘. 현재 Tailwind CSS를 쓰고 있어.

이미지가 컨텍스트를 담당하므로 "왼쪽 위에 있는 파란 버튼"처럼 위치를 글로 설명할 필요가 없다. LLM이 직접 본다.

효율적인 이미지 기반 코딩 질문 흐름에 대한 추가 가이드는 AI 코딩 프롬프트 작성법 에서 확인할 수 있다.

브라우저 로컬에서 처리가 완결되는 이유가 중요한가?

캡처된 이미지와 생성된 프롬프트는 PromptShot 서버로 전송되지 않는다. 모든 처리는 브라우저 내부에서 로컬로 이뤄진다. 페이지 콘텐츠, DOM 구조, 입력한 텍스트 중 어느 것도 외부로 나가지 않는다.

이 구조가 특히 중요한 경우가 있다.

사내 관리 페이지나 스테이징 환경처럼 외부에 공개되면 안 되는 화면을 캡처할 때
고객 데이터가 일부 보이는 대시보드에서 레이아웃 버그를 수정할 때
회사 정책상 화면 내용을 외부 서비스에 전송하기 어려운 환경

클립보드에 올라간 이미지는 사용자가 직접 LLM에 붙여넣는 순간에만 이동한다. 어디에 붙여넣을지는 사용자가 결정한다.

도구가 중간에서 데이터를 가져가지 않는다는 점은, 사내 보안 정책이 엄격한 팀에서도 부담 없이 쓸 수 있는 조건이 된다. 이 부분은 확장 프로그램을 선택할 때 꽤 현실적인 기준이다.

화면 어노테이션을 추가해 질문 정밀도를 높이는 방법

캡처한 이미지 위에 화살표, 형광펜, 텍스트를 얹어 문제 지점을 직접 표시할 수 있다. 별도 이미지 편집기 없이 캡처 직후 PromptShot 내 편집 화면에서 처리한다.

어노테이션이 유용한 시나리오는 분명하다. 여러 컴포넌트가 겹쳐 있거나, 스크롤 위치에 따라 요소가 달라지는 페이지라면 "여기"가 어디인지 이미지만으로 불분명할 수 있다. 화살표 하나로 그 애매함이 사라진다.

버그 리포트 용도라면 형광펜으로 문제 영역을 칠하고 LLM에 넘기면, 수정 제안을 받은 뒤 같은 이미지를 GitHub 이슈에 그대로 첨부할 수 있다. 캡처와 리포팅이 한 흐름에서 해결된다.

자주 묻는 질문

PromptShot이 캡처한 이미지는 어디에 저장되나요?

이미지는 서버에 업로드되지 않는다. 캡처 즉시 브라우저 클립보드에만 올라가고, 이후에는 사용자가 붙여넣는 위치로 이동한다. PromptShot 측에는 어떤 데이터도 전달되지 않는다.

전체 페이지 캡처와 영역 캡처 중 어느 쪽이 LLM 답변 품질에 유리한가요?

UI 수정 목적이라면 영역 캡처가 낫다. LLM에 넘어가는 이미지가 작고 명확할수록 관련 없는 요소에서 오는 노이즈가 줄어 답변이 집중된다. 전체 화면은 페이지 전체 구조를 파악해야 할 때 유효하다.

Cursor, ChatGPT, Claude 중 어떤 LLM과 함께 써야 하나요?

이미지를 지원하는 LLM이라면 어디든 동작한다. Cursor 채팅, ChatGPT-4o, Claude 3.5 Sonnet 이상에서 이미지 붙여넣기가 가능하다. 클립보드에서 Ctrl+V로 붙여넣으면 이미지와 프롬프트 텍스트가 함께 입력된다.

단축키를 커스터마이징할 수 있나요?

현재 기본 단축키는 Alt+Shift+S로 캡처 시작, Alt+1은 이미지만, Alt+2는 이미지와 프롬프트 동시 복사다. Chrome 확장 프로그램 단축키 설정 페이지(chrome://extensions/shortcuts)에서 변경할 수 있다.

사내 스테이징 환경처럼 인트라넷 페이지에서도 동작하나요?

동작한다. PromptShot은 브라우저에서 렌더링된 화면을 캡처하는 방식이므로, 공개 URL 여부와 관계없이 현재 탭에 로드된 페이지라면 어느 환경에서든 쓸 수 있다.

영역 드래그로 문제 컴포넌트만 잘라 LLM에 넘기는 방식은, 텍스트로 설명하는 루프를 줄이는 가장 직접적인 방법이다. 캡처부터 붙여넣기까지 모든 처리가 브라우저 로컬에서 완결되므로 민감한 화면도 부담 없이 쓸 수 있다. Chrome에 추가하고 다음 UI 버그 리포트에 바로 적용해 보자.

네이버 지도 무한 스크롤, 그리드 전체화면 전환으로 완전히 없애는 법

이종현 — Wed, 05 Aug 2026 01:00:29 +0000

네이버 지도 사진 탭을 열 때마다 작은 썸네일을 계속 내리는 일이 번거롭다면, 그 구조 자체를 바꿀 수 있다. 와이드 갤러리 확장 프로그램을 설치하면 무한 스크롤 대신 전체화면 그리드로 전환되어, 한 화면에서 여러 사진을 한눈에 비교할 수 있다.

네이버 지도 사진 탐색 시 무한 스크롤이 주는 피로도 분석

네이버 지도의 기본 사진 탭은 무한 스크롤 구조다. 사진을 내릴수록 새로운 이미지가 로드되지만, 이미 지나친 사진으로 돌아가려면 다시 위로 올려야 한다. 특히 맛집이나 카페처럼 사진이 수십 장 이상인 장소에서는 비교 자체가 어려워진다.

문제는 두 가지 지점에서 발생한다.

썸네일 크기: 기본 그리드의 썸네일은 작아서 분위기나 좌석 배치를 한눈에 파악하기 어렵다.
위치 기억 비용: 스크롤을 내리다 특정 사진을 다시 찾으려면 대략적인 위치를 기억해야 한다. 이 인지 부담이 쌓이면 탐색 효율이 떨어진다.

여러 장소를 순서대로 비교하는 여행 계획 상황이라면 이 비용은 배가된다. 장소 A의 사진을 보다가 장소 B로 넘어갔을 때, 각 장소의 사진 구성을 기억에 의존해야 하기 때문이다.

전체화면 레이아웃 전환을 통한 무한 스크롤 병목 현상 해소 방법

와이드 갤러리는 사진 탭의 인터페이스 자체를 전환하는 방식으로 작동한다. 무한 스크롤 레이아웃을 덮어쓰는 것이 아니라, 확장 프로그램이 네이버 지도의 사진 탭 위에 전체화면 그리드 뷰를 오버레이한다.

작동 순서는 간단하다.

네이버 지도에서 장소를 검색한다.
장소 상세 페이지에서 사진 탭을 클릭한다.
화면 상단에 나타나는 초록색 버튼을 누른다. 또는 단축키 Alt+Shift+F를 사용한다.
전체화면 그리드 갤러리가 열린다.

그리드 뷰에서는 스크롤 없이 화면 전체에 여러 사진이 동시에 표시된다. 사진 개수와 그리드 크기 설정에 따라 한 화면에 표시되는 이미지 수가 달라진다. 기본 설정에서도 기존 무한 스크롤 대비 훨씬 많은 사진을 한 번에 확인할 수 있다.

아래는 기본 무한 스크롤 탐색과 전체화면 그리드 탐색의 방식을 정리한 비교표다.

탐색 방식	화면당 사진 수	이전 사진 접근	키보드 탐색 지원	사진 상세 보기
기본 무한 스크롤	소수(썸네일)	위로 스크롤 필요	미지원	개별 클릭
와이드 갤러리 그리드	다수(그리드 크기 조절 가능)	방향키로 즉시 이동	지원(← → ↑ ↓)	Enter로 상세, Esc로 닫기

Alt+Shift+F 단축키 및 그리드 크기 조절 기능의 상세 작동 메커니즘은?

핵심 단축키는 Alt+Shift+F다. 사진 탭이 열려 있는 상태에서 이 키 조합을 누르면 즉시 전체화면 갤러리로 전환된다. 마우스로 초록 버튼을 찾을 필요 없이 키보드만으로 뷰를 바꿀 수 있다.

갤러리 진입 후 키보드 탐색은 다음 키로 동작한다.

← → ↑ ↓: 그리드 내 사진 포커스 이동
Enter: 포커스된 사진의 상세 뷰 열기
Esc: 상세 뷰 닫기 또는 갤러리 종료

그리드 크기 조절은 갤러리 내 설정 패널에서 가능하다. 화면 해상도나 개인 선호에 따라 한 행의 사진 수를 늘리거나 줄일 수 있다. 사진이 많은 장소에서는 그리드를 크게 설정해 전체를 빠르게 훑고, 분위기를 자세히 보고 싶을 때는 그리드를 줄여 개별 사진 크기를 키우는 방식으로 쓰면 된다.

7가지 테마를 제공하므로 배경 색상과 UI 명도를 조절할 수 있다. 야간에 밝은 배경이 불편하다면 어두운 테마로 전환하면 된다. 동영상도 지원하여, 사진과 동영상이 섞인 경우에도 같은 갤러리 뷰에서 재생할 수 있다.

안전한 브라우저 도구의 프라이버시 표준, 다른 사이트 접근 없음

브라우저 확장 프로그램을 설치할 때 가장 먼저 확인해야 할 것은 권한 범위다. 와이드 갤러리는 네이버 지도 페이지에만 작동한다. 다른 사이트에 대한 접근 권한을 요청하지 않는다.

데이터 수집도 없다. 탐색한 장소, 클릭한 사진, 사용 패턴 등 어떤 정보도 외부 서버로 전송되지 않는다. 확장 프로그램이 수집하는 데이터 항목 자체가 없다.

정리하면 이렇다.

접근 허용 범위: 네이버 지도 도메인 한정
데이터 수집: 없음
외부 서버 전송: 없음
다른 사이트 동작: 없음

브라우저 확장 프로그램 중 광고 삽입이나 사용 데이터 수집을 목적으로 하는 사례가 있다는 점을 감안하면, 권한 최소화는 평가 기준으로 볼 만한 요소다. 와이드 갤러리는 기능 범위와 권한 범위를 일치시키는 방향으로 설계되었다.

와이드 갤러리 설치 방법은?

Chrome 웹 스토어 또는 mungtotext.com에서 설치할 수 있다. 설치 후 별도 설정 없이 네이버 지도 사진 탭을 열면 초록 버튼이 표시된다.

설치 순서는 다음과 같다.

Chrome 웹 스토어에서 '네이버 지도 와이드 갤러리'를 검색하거나 mungtotext.com 링크를 클릭한다.
'크롬에 추가' 버튼을 누른다.
권한 확인 팝업이 뜨면 내용을 확인하고 추가한다.
네이버 지도에서 장소를 검색한 뒤 사진 탭을 연다.
초록 버튼 또는 Alt+Shift+F로 갤러리를 시작한다.

설치 이후 추가 작업은 없다. 자동 업데이트되며, 네이버 지도 이외의 사이트에서는 비활성 상태로 유지된다.

자주 묻는 질문

와이드 갤러리는 어떤 브라우저에서 동작하나요?

Chrome 기반 브라우저에서 동작한다. Chrome, Whale, Edge(크롬 엔진 기반) 등 크롬 웹 스토어 확장 프로그램을 지원하는 브라우저라면 설치할 수 있다. Firefox는 현재 지원하지 않는다.

설치 후 네이버 지도 외 사이트에도 영향을 주나요?

영향을 주지 않는다. 확장 프로그램의 작동 범위는 네이버 지도 도메인으로 한정되어 있다. 다른 탭이나 사이트에서는 비활성 상태로 유지된다.

그리드 크기 설정은 저장되나요?

저장된다. 한 번 설정한 그리드 크기와 테마는 브라우저를 닫고 다시 열어도 유지된다. 매번 다시 설정할 필요가 없다.

동영상이 포함된 장소도 갤러리에서 볼 수 있나요?

볼 수 있다. 사진과 동영상이 혼합된 경우에도 같은 그리드 뷰에서 표시되며, 동영상은 클릭하거나 Enter 키로 상세 뷰를 열어 재생할 수 있다.

Alt+Shift+F 단축키가 다른 프로그램과 충돌하면 어떻게 하나요?

단축키가 충돌하는 경우, 확장 프로그램 설정 페이지에서 사용자 지정 단축키로 변경할 수 있다. Chrome 설정의 확장 프로그램 단축키 관리 메뉴(chrome://extensions/shortcuts)에서 재설정하면 된다.

네이버 지도에서 장소 사진을 확인할 때 무한 스크롤이 주는 불편함은 인터페이스 구조의 문제다. 와이드 갤러리는 그 구조를 전체화면 그리드로 대체한다. 설치 한 번으로 사진 탐색 방식이 바뀌고, 키보드 탐색과 그리드 크기 조절로 탐색 속도를 직접 제어할 수 있다. 권한은 최소화되어 있고, 데이터는 수집하지 않는다. 도구가 해야 할 일만 한다.

행렬 연산이 딥러닝 신경망 계산을 처리하는 방식

이종현 — Wed, 05 Aug 2026 00:57:01 +0000

딥러닝 코드를 처음 열어보면 numpy.dot() 또는 torch.matmul() 같은 함수가 곳곳에 등장한다. 이 함수들이 무슨 일을 하는지 모른 채 넘어가면 모델이 왜 그런 형태인지 감이 잡히지 않는다. 이 글은 행렬 곱셈이 신경망 내부에서 어떤 역할을 맡는지, 그 메커니즘을 정확히 짚어준다. 수식을 두려워할 필요 없다. 도구의 작동 원리를 이해하면, 딥러닝 학습이 훨씬 빠르게 자리를 잡는다.

가중치 행렬과 입력 벡터의 선형 변환 메커니즘

신경망의 각 층(layer)에서 일어나는 일을 한 문장으로 정리하면 이렇다. 입력 벡터에 가중치 행렬을 곱해 새로운 벡터를 만든다. 이것이 선형 변환(linear transformation)이다.

구체적으로 살펴보자. 이미지 픽셀 784개를 나열한 열벡터 x (크기 784×1)가 있다고 하자. 첫 번째 은닉층의 가중치 행렬 W는 크기 128×784다. 행렬 곱 Wx를 계산하면 결과는 128×1 벡터, 즉 128개의 새로운 숫자가 된다. 각 숫자는 784개 입력값의 가중합(weighted sum)이다.

왜 이 구조를 쓰는가? 행렬 곱은 모든 입력 특성(feature)이 모든 출력 뉴런에 동시에 영향을 줄 수 있는 가장 효율적인 방법이다. 각 뉴런에 대해 루프를 돌리는 대신, 행렬 하나로 전체 연산을 한 번에 처리한다. 실제 GPU 가속의 핵심도 여기에 있다. 병렬 처리에 최적화된 행렬 연산 덕분에 수백만 파라미터를 동시에 계산할 수 있다.

편향(bias) 항까지 더하면 전체 변환은 Wx + b 형태가 된다. 행렬 곱이 선형 변환을 담당하고, 벡터 b가 평행 이동을 담당한다. 그 뒤에 ReLU나 시그모이드 같은 활성화 함수(activation function)가 비선형성을 추가해야 층을 여러 개 쌓는 것이 의미를 갖는다. 선형 변환만 여러 번 연속으로 적용하면 수학적으로 하나의 선형 변환과 동일하기 때문이다.

선형 변환을 벡터 공간 관점에서 이해하는 방법은?

기하학적으로 보면 행렬 곱은 공간을 늘리고, 회전하고, 압축하는 작업이다. 784차원 공간에 흩어진 점들(이미지 데이터)을 128차원 공간으로 옮기는 일이 첫 번째 층에서 벌어진다.

이때 핵심 개념 두 가지가 등장한다.

행렬의 열공간(column space): 변환 후 데이터가 실제로 존재할 수 있는 공간의 범위. 784차원 입력이 128차원으로 줄어드는 과정에서 일부 정보는 필연적으로 사라진다.
행렬의 영공간(null space): 변환했을 때 영벡터(0, 0, …)가 되는 입력들의 집합. 이 방향의 정보는 학습 과정에서 "버려진다."

신경망이 학습을 거치면서 가중치 행렬 W의 값이 조정된다는 뜻은, 공간 자체의 기하학적 성질이 바뀐다는 뜻이다. 고양이 사진과 강아지 사진이 변환 후 128차원 공간에서 서로 멀리 떨어지도록 공간을 "비틀어가는" 것이 학습의 실체다.

특이값 분해(SVD, Singular Value Decomposition)는 이 관점을 수치적으로 분석하는 도구다. 행렬을 세 개의 단순한 변환(회전, 축 방향 늘이기, 다시 회전)으로 분해한다. 딥러닝을 깊이 공부할수록 SVD가 계속 등장하는데, 가중치 행렬이 공간을 어떻게 변형하는지 파악하는 언어가 바로 SVD이기 때문이다.

신경망 층 구조와 행렬 연산 방식 비교

층이 깊어질수록 행렬 크기와 역할이 어떻게 달라지는지 정리하면 다음과 같다.

층 위치	입력 크기	가중치 행렬 크기	출력 크기	주요 역할
입력층 → 은닉층 1	784×1	128×784	128×1	특성 추출 시작, 고차원 압축
은닉층 1 → 은닉층 2	128×1	64×128	64×1	패턴 조합, 추상화 증가
은닉층 2 → 출력층	64×1	10×64	10×1	클래스 분류 점수 계산

각 층을 거칠 때마다 행렬 곱이 한 번씩 실행된다. 세 층짜리 네트워크라도 순전파(forward pass) 한 번에 행렬 곱이 세 번 연속으로 일어난다는 뜻이다. 역전파(backpropagation)에서는 기울기(gradient)를 계산하기 위해 전치 행렬(Wᵀ)을 사용한다. 선형대수가 단순히 "입력을 처리하는 곳"에만 쓰이는 게 아니라, 학습 자체가 행렬 연산 위에서 돌아가는 구조다.

배치 학습에서 행렬 연산이 작동하는 방식은?

실제 학습에서는 데이터를 하나씩 넣지 않는다. 32개, 64개, 128개씩 묶어서 한꺼번에 처리하는 미니배치(mini-batch) 방식을 쓴다. 이때 입력이 열벡터 x (784×1)가 아니라 행렬 X (784×32)가 된다. 가중치 행렬은 변하지 않는다. WX를 계산하면 출력은 128×32 행렬, 즉 32개 데이터의 결과가 동시에 나온다.

이 구조가 학습 속도를 결정한다. 데이터 32개를 루프로 하나씩 처리하면 행렬 곱이 32번 일어나지만, 배치 행렬 연산으로는 한 번에 끝난다. GPU는 이 "큰 행렬 곱 하나"에 매우 최적화되어 있다. 배치 크기를 조정하는 이유도, 모델 학습이 느린 이유도 결국 이 행렬 연산의 효율성 문제로 귀결된다.

초심자가 여기서 자주 막히는 부분이 있다. 행렬 곱의 차원 규칙이다. A(m×k) × B(k×n) = C(m×n). 앞 행렬의 열 수와 뒤 행렬의 행 수가 같아야 한다. 이 규칙을 머릿속에 새겨두면 "shape mismatch" 오류가 왜 나는지 바로 파악할 수 있다.

기하학적으로 해석하는 신경망의 고차원 선형 사상

고차원에서 선형 사상(linear map)이 어떤 역할을 하는지는 2차원이나 3차원 예시로 감을 잡고, 거기서 차원만 확장하는 방식으로 접근하는 것이 현실적이다.

2×2 행렬을 평면 위의 화살표(벡터)에 곱하면 그 화살표가 늘어나거나, 방향이 바뀌거나, 뒤집힌다. 이때 크기만 바뀌고 방향이 보존되는 특별한 벡터를 고유벡터(eigenvector)라 하고, 그 변화 비율을 고유값(eigenvalue)이라 부른다. 784차원 가중치 행렬에도 같은 원리가 적용된다. 주의할 점은, 고차원에서는 이 기하학적 직관이 시각적으로 보이지 않는다는 것이다. 수치 계산이 직관을 대신한다.

딥러닝 학습에서 고유값과 관련된 실용적인 개념 하나를 짚어두면 좋다. 헤시안 행렬(Hessian matrix)의 고유값은 손실 함수(loss function)의 곡률을 나타낸다. 고유값이 크면 그 방향으로 경사가 급하고, 작으면 완만하다. 경사 하강법(gradient descent)이 수렴하기 어려운 이유 중 하나가 이 고유값 분포의 불균형이다. 선형대수를 "계산 도구"로만 보지 않고 기하학적으로 해석하면, 왜 학습률(learning rate) 조정이 중요한지까지 연결된다.

모두의AI 인터랙티브 연습문제로 익히는 선형대수 기초

개념을 읽는 것과 직접 계산해보는 것 사이의 거리가 생각보다 크다. 행렬 곱의 차원 규칙을 알아도, 실제로 3×3 행렬과 3×2 행렬을 손으로 곱해보기 전까지는 잘 굳지 않는다. 틀렸을 때 즉각적인 피드백이 없으면 오개념이 그대로 쌓인다.

모두의AI의 선형대수 인터랙티브 연습문제는 이 간극을 메우기 위해 설계되었다. 개념 설명 직후 손으로 풀어볼 문제가 이어지고, 답을 입력하면 바로 피드백이 돌아온다. 특히 "행렬 곱의 가능 여부 판단 → 직접 계산 → 딥러닝 맥락 적용"의 세 단계로 연결되어, 추상적인 선형대수가 실제 신경망 코드에 어떻게 닿는지 감각적으로 익힐 수 있다.

수학이 어렵게 느껴지는 이유 중 하나는 "계산 맞혔는지 모르고 넘어가는" 경험이 반복되기 때문이다. 피드백 없는 독학은 자신감이 쌓이지 않는다. 개념 정립 후 즉각 피드백으로 이어지는 구조가 학습 속도를 실질적으로 바꾼다.

모두의AI 행렬 연습문제 바로가기 →

자주 묻는 질문

선형대수를 모르면 딥러닝 코드를 실행할 수 없나요?

코드 실행 자체는 가능하다. 하지만 모델 구조를 설계하거나, 오류를 디버깅하거나, 결과를 해석할 때 벽에 부딪힌다. "shape mismatch" 오류 하나를 고치는 데 걸리는 시간이 확연히 달라진다. 도구를 쓰려면 도구의 작동 원리를 알아야 한다.

행렬 곱과 원소별 곱셈(element-wise multiplication)은 어떻게 다른가요?

행렬 곱은 행과 열 간의 내적(dot product)을 계산해 구조를 완전히 바꾼다. 원소별 곱셈은 같은 위치의 숫자끼리만 곱하므로 행렬 크기가 그대로 유지된다. 신경망에서 두 방식 모두 등장하지만 역할이 전혀 다르다. 가중치 계산에는 행렬 곱, 어텐션 마스킹 같은 연산에는 원소별 곱셈이 쓰인다.

벡터와 행렬의 차이를 모르는 수준에서 시작해도 괜찮나요?

충분히 괜찮다. 벡터는 숫자를 일렬로 나열한 것, 행렬은 그 벡터들을 행이나 열로 쌓아 놓은 것이라고 이해하면 출발점으로 충분하다. 이 글에서 다룬 내용은 그 위에서 한 걸음씩 쌓이는 구조다.

전치 행렬(transpose)이 역전파에서 왜 필요한가요?

역전파에서는 출력 쪽의 기울기를 입력 쪽으로 "거꾸로" 전달해야 한다. 순전파 때 W (m×n)를 곱했다면, 역방향에서는 Wᵀ (n×m)를 곱해야 차원이 맞는다. 전치 행렬은 선형 변환의 "역방향 통로"를 여는 수학적 장치다.

고유값 분해와 SVD 중 먼저 공부해야 하는 것은?

고유값 분해를 먼저 익히는 것이 순서상 자연스럽다. 정방 행렬에서 방향과 크기를 분리하는 개념을 잡은 뒤, 직사각형 행렬로 확장한 것이 SVD다. 딥러닝의 가중치 행렬은 대부분 직사각형이므로 실용적으로는 SVD가 더 자주 쓰이지만, 고유값 분해의 직관 없이 SVD를 배우면 공식만 외우게 된다.

행렬 곱은 딥러닝의 연산 기반이다. 입력을 새로운 공간으로 옮기고, 패턴을 추출하고, 기울기를 역방향으로 전달하는 모든 과정이 가중치 행렬과의 곱셈으로 이루어진다. 이 메커니즘을 손으로 한 번 계산해본 사람과 그렇지 않은 사람은 모델 구조를 읽는 방식이 다르다. 모두의AI의 연습문제는 그 "한 번"을 피드백과 함께 경험할 수 있도록 만들어졌다. 개념을 읽었다면, 이제 계산해볼 차례다.

더 보기: mdooai.com

클라우드 vs 로컬 데이터 처리: 민감 정보가 서버에 닿지 않는 구조

이종현 — Sat, 01 Aug 2026 00:37:28 +0000

화면 녹화 도구로 업무 매뉴얼을 만들 때, 스크린샷 속에는 생각보다 많은 민감 정보가 담겨 있다. 사내 시스템 URL, 고객 이름, 계정 정보까지 녹화 범위에 들어온다. 이 데이터를 클라우드로 올리는 도구와 로컬에 먼저 저장하는 도구 사이의 차이는 단순한 설계 선택이 아니라 보안 위험 수준의 차이다.

Manual Maker는 서버로 전송하지 않는 로컬 우선 방식을 채택해, 스크린샷은 기기를 벗어나지 않고 문서 생성에 필요한 텍스트 데이터만 암호화해 전송한다. 이 글은 클라우드 처리 방식이 어디서 위험을 만드는지, 로컬 우선 구조가 그 경로를 어떻게 차단하는지를 구체적으로 설명한다.

클라우드 기반 화면 녹화의 보안상 한계와 데이터 유출 경로

클라우드 처리 방식에서 데이터는 서버로 먼저 올라간다. 처리 로직이 서버에 있기 때문이다. 이때 만들어지는 유출 경로는 크게 세 가지다.

전송 구간: HTTPS를 써도 TLS 종단점은 서버다. 서버 측에서 복호화된 데이터를 로깅하거나 분석하는 정책이 있다면 사용자는 알 방법이 없다.
저장 구간: 많은 클라우드 SaaS가 처리 후에도 원본 스크린샷이나 행동 로그를 일정 기간 보관한다. 이 데이터가 침해 사고의 대상이 된다.
서드파티 연동: 분석·광고·에러 추적 SDK가 포함된 클라우드 서비스는, 원치 않는 데이터가 제3자 서버로 흘러갈 수 있다.

화면 녹화 도구 특성상 스크린샷에는 비밀번호 입력 필드, 주민번호 형식 텍스트, 내부 시스템 대시보드가 프레임 안에 들어오기 쉽다. 클라우드 우선 구조에서 이 프레임이 통째로 서버로 올라가면, 전송 자체가 잠재적 유출이다.

로컬 우선(Local-First) 데이터 처리 메커니즘은 어떻게 작동할까?

로컬 우선(Local-First)이란 데이터의 원본을 사용자 기기에 두고, 외부로는 필요한 최소 정보만 내보내는 설계 원칙이다. 애플리케이션 상태가 먼저 로컬에 기록되고, 네트워크는 보조 수단으로만 쓰인다.

브라우저 확장에서 이 원칙을 구현하는 핵심 저장소가 IndexedDB다. IndexedDB는 브라우저 샌드박스 안에서 동작하는 키-값 기반 비관계형 데이터베이스로, 도메인별로 격리되어 있고 확장 외부에서 접근할 수 없다. 세션스토리지나 쿠키와 달리 대용량 바이너리(스크린샷 포함)를 저장할 수 있고, 탭을 닫아도 데이터가 유지된다.

로컬 우선 구조에서 데이터 흐름은 다음 순서를 따른다.

사용자가 녹화를 시작한다.
클릭 직전 스크린샷과 DOM 기반 행동 로그가 IndexedDB에 즉시 저장된다.
사용자가 녹화를 종료하고 문서 생성을 요청한다.
이 시점에, 서버 API가 필요한 데이터(행동 로그 텍스트)만 추출해 전송한다.
스크린샷 바이너리는 전송되지 않는다.

이 흐름에서 스크린샷은 단 한 번도 기기를 떠나지 않는다. AI 모델이 화면을 분석하는 게 아니라, 텍스트화된 행동 로그를 받아 문서를 생성하는 구조이기 때문에 가능하다.

Manual Maker의 IndexedDB 활용과 마스킹 처리 후 텍스트 전송 프로세스

Manual Maker의 데이터 처리 과정을 구체적으로 보면, 보안 설계가 어디에 집중되어 있는지 알 수 있다.

저장 단계: 녹화 중 발생하는 모든 캡처와 로그는 IndexedDB에 먼저 쓰인다. 브라우저가 닫혀도 데이터는 유지되고, 사용자가 명시적으로 삭제하지 않는 한 기기에 남는다.

마스킹 단계: 문서 생성 요청이 발생하기 전, 행동 로그에서 민감 패턴을 검출해 마스킹한다. 비밀번호 입력 필드(<input type="password">)에서 감지된 값은 블러 처리되고, 주민번호 형식(6자리-7자리 패턴)이나 카드번호 패턴이 포함된 텍스트는 [REDACTED]로 치환된다.

전송 단계: 마스킹이 완료된 텍스트 행동 로그만 서버로 전송된다. 여기서 Upstage Document Parse API가 UI 요소의 구조를 해석한다. 스크린샷이 아닌 텍스트 기반 컨텍스트를 받아 UI 계층 구조, 버튼 레이블, 입력 필드명을 정확히 읽어낸다. 이후 Solar Pro 3 모델이 이 컨텍스트를 기반으로 단계별 매뉴얼 초안을 생성하고, 에이전트가 생성 결과를 자기검증한다. 약한 단계로 판단된 부분만 재작성한다.

결과 저장: 생성된 초안은 다시 IndexedDB에 저장된다. 사용자가 편집하고 내보내기(MD, Word, PDF, ZIP) 전까지 서버에 결과물이 남지 않는다.

아래 표는 클라우드 우선 방식과 Manual Maker의 로컬 우선 방식을 처리 단계별로 정리한 것이다.

처리 단계	클라우드 우선 방식	Manual Maker 로컬 우선 방식
스크린샷 저장 위치	서버 업로드 후 처리	IndexedDB(기기 내)
행동 로그 전송 시점	녹화 중 실시간	생성 요청 시 1회
민감 패턴 마스킹	서버 측 처리	전송 전 로컬 처리
스크린샷 서버 전달 여부	전달됨	전달 안 됨
생성 결과 저장 위치	클라우드 저장소	IndexedDB(기기 내)
수동 편집 데이터 보호	서버 동기화	로컬 우선, 동기화 없음

로컬 데이터 처리 방식이 기업 보안 거버넌스에 기여하는 방식

기업 보안 거버넌스 맥락에서 "데이터 주권"은 조직이 데이터의 저장 위치와 접근 권한을 직접 통제할 수 있는 상태를 뜻한다. 클라우드 SaaS를 도입할 때 이 주권이 외부로 넘어가는 경우가 많다.

로컬 우선 구조는 몇 가지 거버넌스 요건을 충족하는 데 구조적으로 유리하다.

데이터 최소화 원칙: 개인정보보호법과 GDPR 공통 요건이다. 필요 이상의 데이터를 수집·전송하지 말아야 한다. 스크린샷 미전송, 마스킹 후 텍스트만 전달하는 방식은 이 원칙에 맞는다.
처리 목적 한정: 행동 로그가 문서 생성 시에만 전송되고 이후 서버에 보관되지 않으면, 목적 외 처리 위험이 줄어든다.
감사 용이성: 어떤 데이터가 언제 전송되었는지를 사용자 기기의 IndexedDB 기록으로 추적할 수 있다. 클라우드 서버 로그에 의존할 필요가 없다.

IT 부서가 새 도구를 도입할 때 가장 먼저 묻는 건 "이 도구가 우리 데이터를 어디에 보내는가"다. 로컬 우선 구조는 이 질문에 구체적으로 답할 수 있다. 전송하는 데이터 범위가 명확하고, 스크린샷은 기기 밖으로 나가지 않는다고 말할 수 있다.

로컬 데이터 처리 보안 구조에 대한 상세 설명을 참고하면 IndexedDB 격리 정책과 마스킹 패턴 목록을 더 자세히 확인할 수 있다.

자주 묻는 질문

로컬 우선 방식에서도 AI 모델이 화면을 분석하는 건가요?

아니다. Manual Maker에서 AI 모델(Solar Pro 3)은 스크린샷을 받지 않는다. 마스킹된 텍스트 행동 로그와 Upstage Document Parse가 해석한 UI 구조 정보만 입력으로 받는다. 화면 이미지 자체는 서버로 전달되지 않는다.

IndexedDB에 저장된 데이터는 다른 확장이나 웹사이트에서 접근할 수 있나요?

접근할 수 없다. IndexedDB는 브라우저가 출처(origin)별로 격리한다. Manual Maker 확장의 IndexedDB는 해당 확장의 출처에만 귀속되며, 다른 확장이나 웹사이트는 읽거나 쓸 수 없다.

비밀번호 입력 필드를 녹화하면 어떻게 처리되나요?

<input type="password"> 필드는 행동 로그에서 자동으로 블러 처리된다. 입력값 자체는 기록되지 않고, 해당 필드의 존재와 레이블만 로그에 남는다. 전송 단계에서는 이미 값이 없는 상태다.

생성된 매뉴얼 초안은 서버에 보관되나요?

생성된 초안은 IndexedDB에 저장되고 서버에 보관되지 않는다. 사용자가 편집을 마치고 MD, Word, PDF, ZIP 형식으로 내보내기 전까지 결과물은 기기 안에 있다.

Manual Maker Free와 Pro의 데이터 처리 방식이 다른가요?

데이터 처리 구조는 동일하다. Free 플랜은 매뉴얼 10페이지까지 사용할 수 있고, 이를 초과하면 Pro(일회성 평생 라이선스)로 전환한다. 스크린샷 미전송, 마스킹 후 텍스트만 전송, IndexedDB 저장 구조는 두 플랜 모두 동일하게 적용된다.

클라우드와 로컬 처리의 차이는 결국 어느 단계에서 누가 데이터를 갖는가의 문제다. Manual Maker는 스크린샷을 기기 밖으로 내보내지 않고, 문서 생성에 필요한 텍스트 데이터만 마스킹 후 전송하며, 결과물도 기기에 먼저 저장한다. 민감 정보가 포함된 업무 화면을 다루는 팀이라면, Manual Maker 무료 플랜으로 시작해 이 구조를 직접 확인할 수 있다.

AI 코딩 프롬프트에서 텍스트 설명 대신 시각 맥락을 주입하는 법

이종현 — Sat, 01 Aug 2026 00:34:56 +0000

웹 화면 상태를 말로 설명하다 보면 어느 순간 막힌다. "왼쪽 사이드바의 세 번째 메뉴가 hover 상태일 때 배경색이 이상하게 적용됩니다"라는 문장을 읽은 AI가 정확한 컴포넌트를 파악할 확률은 낮다. PromptShot의 영역 캡처를 쓰면 그 설명 자체가 필요 없어진다. 문제가 있는 영역을 드래그해 캡처하면 PNG 이미지와 LLM용 프롬프트 텍스트가 클립보드에 담기고, 그것을 Claude나 ChatGPT에 붙여넣으면 AI가 화면을 직접 본 상태에서 응답한다.

AI 코딩에서 텍스트 프롬프트가 놓치는 것

텍스트만으로 UI 상태를 전달하는 방식에는 구조적인 한계가 있다. 개발자가 아무리 정밀하게 묘사해도 AI는 그 묘사에서 추론할 뿐이고, 묘사가 조금만 빗나가면 전혀 다른 맥락에서 답변이 나온다.

예를 들어 레이아웃 깨짐 버그를 설명한다고 치자. "flex 컨테이너 안에서 자식 요소가 줄바꿈됩니다"라는 설명은 정확해 보이지만, 실제로 어떤 요소가 어느 위치에서 깨지는지는 텍스트로 전달하기 어렵다. 중첩된 컴포넌트 구조, z-index 충돌, 조건부 렌더링 상태처럼 화면을 봐야 즉시 파악되는 정보들이 텍스트 프롬프트에서는 설명 단계에서 이미 손실된다.

이 문제는 프롬프트를 더 정교하게 쓴다고 해결되지 않는다. 텍스트 설명의 정밀도를 높이는 데 쓰는 시간이 쌓일수록, 오히려 그 시간에 다음 수정 사이클을 돌릴 수 있었다는 사실을 깨닫게 된다.

시각 정보를 프롬프트에 직접 포함하는 방식, 즉 스크린샷을 캡처해서 이미지로 붙여넣는 방식이 이 흐름을 바꾼다. AI는 텍스트 설명을 해석하는 대신 화면을 본다.

프롬프트 방식 비교: 텍스트 설명 대 시각 맥락 주입

항목	텍스트 설명 방식	시각 맥락 주입 방식
맥락 전달 방법	개발자가 직접 묘사	캡처 이미지로 직접 전달
AI 해석 정확도	묘사 품질에 의존	화면 상태 그대로 반영
준비 시간	설명 작성 시간 필요	영역 드래그 한 번
적합한 상황	로직·API 관련 질문	UI 버그, 레이아웃, 디자인 핸드오프
반복 수정 흐름	설명 수정 후 재시도	캡처 교체 후 바로 재시도

모든 프롬프트를 이미지로 대체해야 한다는 말이 아니다. 로직 문제나 API 설계처럼 코드 자체가 맥락인 경우에는 텍스트 프롬프트가 여전히 적합하다. 시각 맥락 주입이 유용한 지점은 UI 상태, 컴포넌트 배치, 렌더링 결과처럼 화면을 봐야 빠르게 파악되는 상황이다.

PromptShot으로 화면 영역을 캡처해 클립보드에 담는 법

PromptShot은 Chrome 확장 프로그램으로 설치된다. 설치 후 전체 흐름은 세 단계다.

1단계: 캡처 모드 시작

Alt+Shift+S를 누르면 현재 탭 위에 캡처 오버레이가 활성화된다. 마우스 커서가 십자선으로 바뀌면서 영역 선택 대기 상태가 된다.

2단계: 문제 영역 드래그

페이지 전체를 캡처할 필요 없다. 버그가 발생한 컴포넌트, 레이아웃이 깨진 섹션, 또는 디자인 검토가 필요한 특정 영역만 드래그해서 선택한다. 선택 영역이 확정되면 PromptShot이 해당 PNG를 생성한다.

3단계: 클립보드 복사 방식 선택

여기서 두 가지 옵션이 나뉜다.

Alt+1: PNG 이미지만 클립보드에 복사
Alt+2: PNG 이미지 + LLM용 프롬프트 텍스트를 함께 클립보드에 복사

버그 리포트나 AI 코딩 도구에 붙여넣는 경우라면 Alt+2가 더 유용하다. 이미지와 함께 "다음 스크린샷은 [현재 URL]의 특정 영역입니다. 이 화면에서 무엇이 문제인지 분석해주세요."와 같은 컨텍스트 텍스트가 자동으로 구성되어 클립보드에 담긴다.

전체 처리는 브라우저 안에서 로컬로 이루어진다. 캡처된 이미지나 페이지 내용이 외부 서버로 전송되지 않는다.

Claude와 ChatGPT에 붙여넣어 프롬프트 흐름을 완성하는 법

캡처가 클립보드에 담긴 상태에서 Claude나 ChatGPT 입력창에 Ctrl+V(Mac은 Cmd+V)로 붙여넣으면 이미지와 텍스트가 함께 입력된다. 여기서부터가 실제 AI 코딩 흐름이다.

첫 번째 프롬프트: 문제 확인

[캡처 이미지 붙여넣기]
이 화면에서 사이드바 메뉴 항목의 hover 상태가 적용되지 않는 영역을 찾아주세요.
관련 CSS 선택자 구조를 추정해서 수정 방향을 제안해주세요.

AI가 이미지를 보고 정확히 어느 요소인지 특정하면, 이후 대화는 그 맥락 위에서 이어진다. 텍스트로 설명했을 때 발생하던 "어떤 요소를 말씀하시는 건가요?" 같은 재확인 루프가 없어진다.

두 번째 프롬프트: 수정 후 재캡처

코드를 수정하고 브라우저를 새로고침한 다음, 같은 영역을 다시 Alt+Shift+S로 캡처한다. 이 새 캡처를 다음 프롬프트에 붙여넣으면 AI가 이전 상태와 현재 상태를 비교해 추가 수정 사항을 짚어줄 수 있다.

[수정 후 캡처 이미지 붙여넣기]
이전에 제안한 수정을 적용했습니다. hover 상태가 개선되었는지 확인하고,
아직 남은 문제가 있다면 지적해주세요.

이 흐름이 AI 코딩에서 시각 맥락 주입의 핵심이다. 텍스트 설명을 반복적으로 고쳐 쓰는 대신, 캡처를 교체하면서 대화가 진행된다. Cursor나 Copilot Chat처럼 인라인 채팅을 지원하는 환경에서도 동일하게 클립보드의 이미지를 붙여넣어 같은 방식으로 적용할 수 있다.

이 흐름이 잘 맞는 상황과 그렇지 않은 상황

UI 작업 전반에 쓸 수 있지만, 특히 효과적인 상황이 있다.

레이아웃 버그 디버깅: 어느 요소가 어떤 상태인지 화면으로 보여주는 것이 설명보다 빠르다.
디자인 핸드오프: 특정 컴포넌트 영역만 캡처해서 "이 컴포넌트를 React로 구현해주세요"라고 요청하면 AI가 시각 구조를 기반으로 코드를 생성한다.
버그 리포트 작성: 캡처에 펜이나 화살표로 표시하는 어노테이션 기능과 함께 쓰면 팀 내 버그 리포트 맥락도 이미지 한 장에 담긴다.

반면 로직 오류, 비동기 처리 문제, 백엔드 API 설계처럼 코드 자체가 맥락인 경우에는 이미지가 큰 역할을 하지 못한다. 이 경우에는 코드 스니펫을 직접 붙여넣는 텍스트 프롬프트가 더 적합하다.

두 방식을 상황에 따라 구분해서 쓰는 것이 실용적인 접근이다. 프롬프트 엔지니어링의 목표는 AI에게 가장 정확한 맥락을 가장 빠르게 전달하는 것이고, UI 관련 문제에서는 이미지가 그 역할을 한다.

자주 묻는 질문

PromptShot은 어떤 브라우저에서 동작하나요?

Chrome 및 Chromium 기반 브라우저(Edge, Brave 등)에서 설치해 사용할 수 있다. 캡처한 이미지와 프롬프트는 브라우저 로컬에서만 처리되며 외부로 전송되지 않는다.

전체 페이지를 캡처하지 않고 특정 영역만 캡처할 수 있나요?

Alt+Shift+S로 캡처 모드를 시작한 뒤 원하는 영역만 드래그해서 선택하면 된다. 페이지 전체 캡처가 아닌 컴포넌트 단위 영역 선택이 기본 동작이다.

Claude와 ChatGPT 외 다른 AI 도구에도 붙여넣을 수 있나요?

클립보드에 PNG로 담기기 때문에 이미지 첨부를 지원하는 AI 도구라면 어디서든 동일하게 붙여넣을 수 있다. Cursor의 인라인 채팅, Copilot Chat 등에서도 같은 방식으로 작동한다.

이미지와 함께 자동으로 생성되는 프롬프트 텍스트는 수정할 수 있나요?

Alt+2로 복사된 텍스트는 클립보드에서 바로 편집 가능하다. AI 입력창에 붙여넣은 뒤 전송 전에 텍스트 부분을 수정하거나 추가 지시를 덧붙이면 된다.

캡처 이미지에 화살표나 강조 표시를 추가할 수 있나요?

캡처 후 어노테이션 기능으로 펜, 형광펜, 화살표를 추가할 수 있다. 버그 리포트에서 특정 위치를 명확히 지정해야 할 때 유용하다.

텍스트 설명으로 UI 문제를 전달하는 데 쓰는 시간은 실제로 꽤 많다. PromptShot의 영역 캡처는 그 설명 단계를 드래그 한 번으로 대체하고, 이미지를 AI에게 직접 건네는 흐름을 만든다. AI 코딩 프롬프트 워크플로우에 대한 추가 내용도 참고할 수 있다. 실제로 써보려면 PromptShot을 방문해서 확장 프로그램을 설치하는 것이 가장 빠르다.

Google API 없이 브라우저 로컬에서 캘린더 일정을 분석하는 Chrome 확장 구조

이종현 — Sat, 01 Aug 2026 00:25:31 +0000

https://chromewebstore.google.com/detail/ngfbdomnejfkgmlkfcmlgmcddalalnfe?utm_source=item-share-cb

OAuth 토큰도, 백엔드 서버도, LLM API 호출도 없다. chrome.runtime.sendMessage와 IndexedDB만으로 Google Calendar 화면을 읽고, 우선순위 점수를 계산하고, 결과를 인라인 패널에 표시할 수 있다. 이 글은 그 구조가 실제로 어떻게 작동하는지 단계별로 설명한다.

content script는 어떻게 calendar.google.com 화면을 직접 읽는가?

content script는 Google Calendar 페이지가 로드될 때 자동으로 실행되는 자바스크립트 파일이다. OAuth 인증이 필요 없다. 이미 로그인된 사용자의 브라우저 탭 위에서 DOM을 직접 읽기 때문에, 구글 서버에 어떤 요청도 보내지 않는다.

구체적으로, manifest.json에 "matches": ["https://calendar.google.com/*"]를 등록하면 확장이 해당 URL에서 content script를 주입한다. 스크립트는 querySelectorAll로 이벤트 칩 요소를 순회하고, 각 칩의 텍스트 노드와 aria-label 속성에서 이벤트 제목과 시간 범위를 추출한다.

주의할 점이 하나 있다. Google Calendar의 일부 뷰는 Shadow DOM 경계 안에 이벤트 요소를 렌더링한다. 이 경우 일반 querySelector로는 접근이 안 된다. element.shadowRoot를 타고 내려가는 재귀 탐색 함수가 필요하다. 이 탐색은 단순 트리 순회이므로 성능 부담은 거의 없고, 실제로 주간 보기나 월별 보기 기준으로 DOM 노드 수는 수백 개 수준이다.

추출 대상은 다음과 같이 구분한다.

이벤트 제목 텍스트
시작/종료 시간 (문자열 파싱)
반복 여부 (aria-label 또는 특정 CSS 클래스로 판별)
색상 코드 (구글 캘린더 색상 분류와 매핑)
현재 뷰 유형 (day, week, month)

원문 텍스트를 외부로 보내지 않으므로, 이 단계에서 이미 프라이버시 경계가 결정된다.

Shadow DOM 인라인 패널과 service worker 사이의 메시지 흐름

content script가 DOM에서 이벤트 데이터를 추출하면, 그것을 service worker(백그라운드 스크립트)로 전달해야 한다. 여기서 chrome.runtime.sendMessage가 역할을 맡는다.

통신 흐름은 단방향이 아니다. content script가 메시지를 보내면 service worker가 처리 결과를 응답(response)으로 돌려주고, content script는 그 결과를 Shadow DOM으로 생성한 인라인 패널에 반영한다. 전체 흐름을 단순화하면 이렇다.

[content script]
  → DOM 파싱 → 이벤트 배열 추출
  → chrome.runtime.sendMessage({ type: 'ANALYZE', events: [...] })
  → 응답 수신 → Shadow DOM 패널 업데이트

[service worker]
  → chrome.runtime.onMessage.addListener
  → IndexedDB에서 기존 메타데이터 조회
  → Delta Attention 가중치 연산
  → sendResponse({ ranked: [...] })

비동기 처리에서 한 가지 주의할 점: chrome.runtime.onMessage의 리스너가 비동기 응답을 반환하려면 리스너 함수 내에서 return true를 명시해야 한다. 그렇지 않으면 메시지 채널이 즉시 닫히고 응답이 유실된다. 이 부분은 Chrome 확장 개발 시 자주 놓치는 지점이다.

인라인 패널은 element.attachShadow({ mode: 'open' })으로 생성한다. Shadow DOM으로 격리하면 Google Calendar 페이지의 CSS 규칙이 패널 내부에 영향을 미치지 않는다. 패널은 calendar.google.com 레이아웃 위에 float되지 않고, 특정 컨테이너 요소 하위에 삽입되어 흐름을 유지한다.

IndexedDB에 메타데이터만 저장하는 이유와 구조

일정 원문 텍스트를 저장하지 않는다. IndexedDB에 기록하는 것은 메타데이터다. 이 구분이 설계에서 가장 중요한 결정이다.

저장하는 것	저장하지 않는 것
이벤트 해시(ID)	이벤트 원문 제목
시작/종료 타임스탬프 (Unix ms)	참석자 이메일
색상 코드 인덱스	위치 텍스트
반복 여부 (boolean)	설명 본문
누적 지연 카운트
사용자 지정 우선순위 오버라이드

이렇게 하면 두 가지가 동시에 해결된다. 첫째, 개인정보 노출 위험이 없다. 누군가 IndexedDB 덤프를 확보하더라도 일정 내용을 복원할 수 없다. 둘째, 스토리지 비용이 낮다. 수백 개 이벤트의 메타데이터 합산 용량은 수십 KB 수준이다.

IndexedDB의 object store 구조는 eventId를 keyPath로 하고, 타임스탬프와 우선순위 관련 필드를 인덱스로 설정한다. service worker에서 IDBOpenDBRequest를 통해 접근하며, content script에서는 직접 IndexedDB를 건드리지 않는다. 모든 영속 데이터 접근은 service worker를 거친다. 이 레이어 분리는 이후 디버깅에서 상태 오염을 막는 데도 유리하다.

일정 우선순위 분석에 대한 전반적인 접근 방식은 구글 캘린더 우선순위 자동 정렬 원리 글에서 더 자세히 다루고 있다.

로컬 연산만으로 Delta Attention을 실행하는 방법

Delta Attention은 이 확장이 내부적으로 쓰는 가중치 연산 방식의 이름이다. LLM이 아니다. "attention"이라는 이름을 쓰는 이유는, 이벤트 집합 내에서 각 이벤트가 다른 이벤트와의 관계(시간적 근접성, 색상 동질성, 반복 패턴 차이)에 따라 가중치를 다르게 받는 구조이기 때문이다.

연산 흐름은 다음과 같다.

현재 보기에 표시된 이벤트 N개를 배열로 받는다.
각 이벤트에 대해 마감까지 남은 시간, 색상 우선순위 매핑, 반복 여부 세 개의 원시 점수를 계산한다.
인접 이벤트들과의 시간 간격 행렬을 만든다. 이것이 attention 행렬의 역할을 한다.
행렬의 각 셀 값은 두 이벤트 간 시간 gap의 역수로 정규화된다. 가까운 이벤트일수록 서로에게 큰 영향을 미친다.
원시 점수와 attention 행렬을 element-wise 곱한 뒤 행 합산을 구한다.
이 값에서 IndexedDB에 저장된 누적 지연 카운트를 반영해 최종 순위를 결정한다. Delta라는 이름은 여기서 온다. 이전 상태와의 차이(지연 누적)를 현재 연산에 반영하기 때문이다.

이 연산은 서버가 필요 없다. N이 수십 개에서 수백 개 수준이면 행렬 연산 비용은 무시할 만하다. service worker는 WebWorker API를 쓸 수 없지만, 실제 측정 없이도 수백 개 이벤트 기준으로 연산이 메인 스레드를 차단할 만큼 무겁지 않다. 단, 이벤트 수가 수천 개를 넘어가는 경우에는 청크 분할 처리가 필요하다.

이 연산 결과는 외부로 나가지 않는다. 순위 배열만 sendResponse를 통해 content script로 돌아오고, 화면에 표시된 뒤에는 메모리에서 사라진다.

자주 묻는 질문

Google Calendar 계정 로그인 정보나 OAuth 토큰이 필요한가?

필요하지 않다. content script는 이미 로그인된 브라우저 탭의 DOM을 읽을 뿐이다. Google API에 요청을 보내지 않으므로 OAuth 인증 흐름 자체가 없다. 확장이 계정 자격 증명에 접근하는 경로가 존재하지 않는다.

IndexedDB에 저장된 데이터는 언제 삭제되는가?

사용자가 확장을 제거하면 브라우저가 해당 확장의 IndexedDB 저장소를 함께 삭제한다. 확장 설정 화면에서 수동 초기화 옵션을 제공할 수도 있다. 어떤 경우에도 데이터가 외부 서버로 전송되지 않으므로, 삭제는 로컬에서 완결된다.

service worker가 비활성화(suspended)된 상태에서 메시지를 보내면 어떻게 되는가?

Chrome의 Manifest V3 service worker는 일정 시간 이후 자동으로 비활성화된다. chrome.runtime.sendMessage를 호출하면 Chrome이 service worker를 다시 깨운다. 다만, 이 재활성화에 수십 밀리초의 지연이 있을 수 있으므로, content script 측에서 타임아웃 처리를 두는 것이 안전하다.

Delta Attention 연산에 외부 모델 파일이나 wasm 바이너리가 필요한가?

필요하지 않다. 수식은 순수 자바스크립트로 구현된다. 행렬 연산 라이브러리도 없다. 이벤트 수가 수백 개 이하인 일반적인 사용 환경에서는 네이티브 배열 연산으로 충분하다.

이 구조가 Google Calendar 이외의 캘린더 서비스에도 적용되는가?

content script의 DOM 파싱 부분은 Google Calendar의 HTML 구조에 의존한다. 다른 캘린더 서비스에 적용하려면 DOM 탐색 로직을 해당 서비스 구조에 맞게 재작성해야 한다. service worker, IndexedDB, Delta Attention 연산 부분은 입력 포맷만 맞추면 그대로 재사용할 수 있다.

OAuth 없이도 캘린더 데이터를 분석할 수 있다. 필요한 것은 DOM을 읽는 content script, 메시지를 주고받는 service worker, 그리고 메타데이터를 로컬에 보관하는 IndexedDB다. 외부 서버도, LLM도, 인증 플로도 없다. WorkQueue가 이 구조로 동작한다. 소스 구조를 직접 확인하거나 확장을 설치해보고 싶다면 GitHub 리포지토리와 Chrome 웹스토어 개발자 가이드를 참고하면 된다.

더 보기: imjangnote.com

카페·공용 공간에서 노트북 화면 보안: 단축키로 즉시 UI 전환하는 방법

이종현 — Tue, 28 Jul 2026 11:57:52 +0000

TL;DR: 공공장소에서 작업 중 누군가 화면을 훔쳐볼 때, 단축키 한 번으로 브라우저 탭을 일반 문서 UI처럼 보이는 오버레이로 전환할 수 있다. 페이지 내용은 로컬 브라우저에만 머물고 외부로 전송되지 않는다.

공공장소에서 노트북 화면이 노출되는 실제 경로

카페 테이블은 대개 좁고, 옆 좌석과의 거리는 50cm 안팎이다. 그 거리면 FHD 화면의 텍스트를 읽기에 충분하다. 어깨 너머로 보이는 건 의도적인 도청보다 자연스러운 시선 이동에서 시작한다.

시각적 정보 노출(visual eavesdropping)이라는 용어는 정보보호 연구에서 오래전부터 다뤄온 개념이다. 사람이 많은 공간일수록 화면 내용이 의도치 않게 노출될 확률이 높아진다. 기밀 문서, 고객 데이터, 슬랙 DM, 업무용 대시보드 — 이 중 하나라도 화면에 열려 있다면 리스크가 생긴다.

물리적 프라이버시 필터(화면 보호 필름)는 좋은 해결책이지만 탈부착이 불편하고 비용이 든다. 더 즉각적으로 화면을 바꿀 수 있는 소프트웨어 방식이 있다.

오버레이 방식은 화면 전환을 어떻게 작동시키는가?

크롬 확장 프로그램 기반 오버레이 방식의 핵심은 단순하다. 브라우저 탭 위에 시각적 레이어를 씌워 실제 페이지 대신 다른 UI처럼 보이게 만든다. 실제 페이지 콘텐츠는 그대로 유지되고, 화면에 렌더링되는 외형만 바뀐다.

이 방식이 물리적 필터와 다른 점은 반응 속도다. 단축키 하나로 ON/OFF가 가능하고, 탭마다 독립적으로 적용된다. 누군가 가까이 다가오는 걸 인식하는 순간, 키보드에서 손을 떼지 않고도 화면을 바꿀 수 있다.

오버레이가 덮는 건 렌더링 레이어다. 스프린트 백로그가 열린 탭을 스프레드시트처럼 보이는 UI로 덮는 것이지, 해당 탭의 데이터를 삭제하거나 이동시키는 게 아니다. 오버레이를 해제하면 원래 페이지가 그대로 남아 있다.

18가지 일반 UI 테마로 화면 스타일을 어떻게 바꾸는가?

Workmask는 18가지 generic UI 테마를 제공한다. '일반적인 업무 UI 스타일'로 설계된 테마들이며, 특정 소프트웨어 브랜드와 제휴하거나 그것을 사칭하지 않는다. 테마 각각은 지식 노동자에게 익숙한 화면 구조 — 스프레드시트, 문서 편집기, 코드 편집 환경, 대시보드 레이아웃 등 — 를 시각적으로 흉내 낸 독립적 디자인이다.

테마 선택 기준은 상황에 따라 달라진다:

스프레드시트 스타일: 행·열 구조가 화면 대부분을 채운다. 수치 작업처럼 보인다. 카페처럼 개방된 공간에서 가장 무해하게 보이는 외형 중 하나다.
문서 편집기 스타일: 흰 배경에 텍스트 블록 중심 레이아웃. 리포트나 기획서 작업처럼 읽힌다.
코드 편집기 스타일: 어두운 배경과 모노스페이스 폰트 구조. 개발자가 많은 코워킹 공간에서 자연스럽다.
대시보드 스타일: 위젯과 그래프 레이아웃. 분석 작업처럼 보인다.
캘린더·플래너 스타일: 날짜 그리드와 일정 블록 형식. 회의 중이거나 일정 검토처럼 보인다.

모든 테마는 Alt+X (Windows/Linux) 또는 Option+X (Mac) 단축키로 오버레이를 켜고 끈다. 팝업 UI에서 테마를 미리 고른 뒤 단축키로 즉시 전환하는 방식이다.

테마를 고를 때 고려할 점이 하나 있다. 본인이 어떤 공간에서 주로 작업하는지 먼저 파악하는 게 낫다. 개발자 밀집 코워킹 공간이라면 코드 에디터 테마가 자연스럽고, 일반 카페라면 스프레드시트나 문서 테마가 덜 눈에 띈다.

관련 내용: 업무 화면을 상황에 따라 다르게 설정하는 방법은 업무 화면 위장 방법 에서 더 자세히 다룬다.

개인정보가 외부 서버로 가지 않는다는 게 어떤 의미인가?

브라우저 확장 프로그램은 구조적으로 두 가지 모델로 나뉜다.

서버 의존형: 사용자의 탭 정보나 페이지 데이터를 외부 서버로 전송해 처리한 뒤 결과를 반환한다. 로그인 세션이 필요하거나, 기능 작동에 네트워크 요청이 동반된다.
로컬 독립형: 모든 처리가 브라우저 내부에서 완결된다. 확장 프로그램 설정, 테마 선택, 오버레이 상태가 브라우저의 로컬 스토리지에만 저장된다. 외부 서버 통신이 없다.

Workmask는 로컬 독립형으로 작동한다. 확장 프로그램이 보는 건 탭의 시각적 렌더링 레이어뿐이다. 탭에서 열려 있는 페이지의 실제 콘텐츠 — 텍스트, 이미지, 폼 데이터 — 를 읽거나 전송하지 않는다.

Chrome 웹 스토어의 User Data Policy가 요구하는 데이터 처리 기준을 준수하며, 개인 식별 정보를 수집하지 않는다. 이 부분은 확장 프로그램 설치 전 권한 요청 화면에서 직접 확인할 수 있다. 권한 목록이 짧을수록 확장 프로그램이 접근하는 범위가 좁다.

네트워크 의존성이 없다는 건 실용적으로도 유리하다. 카페 와이파이가 불안정하거나 오프라인 상태에서도 오버레이 전환이 그대로 작동한다.

물리적 보안 필터와 소프트웨어 오버레이를 어떻게 비교해야 하는가?

두 방식은 보호하는 위협 모델이 다르다. 병행해서 쓰거나, 상황에 따라 하나를 선택하는 게 현실적이다.

물리적 프라이버시 필터(화면 필름)
- 측면 시야각 자체를 물리적으로 차단한다
- 한 번 부착하면 별도 조작이 필요 없다
- 탈부착 시 불편하고, 노트북 기종별로 크기를 맞춰야 한다
- 정면에서 보이는 화면 밝기와 색감이 떨어진다
- 소프트웨어 전환 없이 항시 보호 상태를 유지한다
소프트웨어 오버레이(확장 프로그램)
- 화면 내용을 다른 UI처럼 보이도록 바꾼다 — 시야각 제한은 아니다
- 단축키 한 번으로 즉시 전환·해제가 가능하다
- 탭별로 독립 적용되고, 테마를 상황에 맞게 선택할 수 있다
- 화면 밝기와 색감에 영향을 주지 않는다
- 네트워크나 별도 하드웨어 없이 브라우저 내에서 작동한다

어느 쪽이 더 낫다는 게 아니라, 위협 시나리오를 먼저 정의하는 게 순서다. 정면에서 가까운 거리에 타인이 앉아 있다면 물리 필터가 더 직접적이다. 갑작스러운 시선 차단이 필요하거나 화면 내용을 맥락에 맞게 바꾸고 싶다면 오버레이가 더 빠르다. 두 방식을 동시에 쓰는 것도 충분히 합리적인 선택이다.

자주 묻는 질문

오버레이를 켠 상태에서도 탭의 실제 작업이 계속되나요?

그렇다. 오버레이는 시각적 레이어만 덮는다. 탭에서 실행 중인 페이지, 입력 중인 데이터, 진행 중인 연결은 그대로 유지된다. 오버레이를 해제하면 작업하던 화면이 그대로 돌아온다.

특정 앱이나 서비스를 사칭하는 건 아닌가요?

아니다. Workmask의 테마는 특정 소프트웨어 브랜드와 무관한 일반적인 업무 UI 스타일이다. 어떤 외부 앱이나 서비스와도 제휴·승인 관계가 없으며, 실제 앱 화면을 복제하지 않는다.

단축키가 다른 앱과 충돌하면 어떻게 하나요?

확장 프로그램 설정에서 단축키를 변경할 수 있다. Chrome의 확장 프로그램 단축키 관리 페이지(chrome://extensions/shortcuts)에서 원하는 조합으로 재설정하면 된다.

오프라인 환경에서도 작동하나요?

작동한다. 오버레이 전환은 외부 서버 통신 없이 브라우저 내부에서 처리된다. 와이파이가 없거나 불안정한 환경에서도 단축키와 테마 전환이 정상 작동한다.

어떤 브라우저에서 사용할 수 있나요?

현재 Chrome 및 Chromium 기반 브라우저(예: Edge)를 지원한다. Chrome 웹 스토어를 통해 설치할 수 있다.

공공장소에서 노트북 화면 보안은 복잡한 문제가 아니다. 단축키 하나로 브라우저 탭을 일반 문서 UI처럼 보이게 전환하고, 작업이 끝나면 다시 원래 화면으로 돌아오면 된다. 페이지 데이터는 브라우저 밖으로 나가지 않는다. 카페나 코워킹 공간에서 이 정도 통제권이면 충분하다. Workmask Chrome 확장 프로그램을 설치해서 직접 확인해보자.

KNN 분류 모델 프로토타입, 알고리즘 암기 없이 내 컴퓨터에서 직접 빌드하기

이종현 — Tue, 28 Jul 2026 11:55:42 +0000

머신러닝을 시작할 때 가장 흔한 함정은 "알고리즘을 먼저 다 이해하고 코드를 짜야 한다"는 생각이다. 하지만 실제로 작동하는 KNN 기반 분류 모델 프로토타입은 수식을 전부 외우지 않아도 지금 당장 내 컴퓨터에서 돌릴 수 있다. 이 글은 그 구체적인 경로를 다룬다.

이론 암기보다 프로토타입 먼저 만들어야 하는 이유

입문 단계에서 이론을 너무 오래 붙잡으면 실제로 모델이 어떻게 작동하는지 감이 잡히지 않는다. 머신러닝은 개념을 읽는 것과 데이터를 넣고 예측 결과를 직접 보는 것 사이에 큰 간극이 있다. 프로토타입을 먼저 만들면 그 간극을 빠르게 좁힐 수 있다.

이론 학습과 실습을 병행할 때 실용적인 원칙이 있다. scikit-learn 공식 문서(scikit-learn.org)에서도 강조하듯, 라이브러리의 설계 철학 자체가 "알고리즘 내부 구현을 몰라도 일관된 인터페이스로 모델을 실험할 수 있도록" 만들어져 있다. 즉, fit → predict 두 단계로 어떤 알고리즘이든 동일한 구조로 써볼 수 있다.

주니어 개발자에게 이 순서가 중요한 건 피드백 루프 때문이다. 코드를 돌리고 예측값을 보고 "왜 이 결과가 나왔지?"라는 질문이 생길 때, 비로소 이론이 맥락을 갖게 된다. 질문이 없는 상태에서 읽는 이론은 금방 증발한다.

입문 프로젝트로 KNN과 로지스틱 회귀를 고르는 기준은?

모든 알고리즘이 입문 프로젝트에 적합한 건 아니다. 아래 기준으로 비교하면 KNN과 로지스틱 회귀가 왜 입문 단계에 어울리는지 명확해진다.

기준	KNN	로지스틱 회귀	딥러닝(신경망)
수학적 사전 지식	거리 개념만 필요	확률·로그 기초	선형대수·미적분
코드 복잡도	낮음	낮음	높음
과적합 위험	중간	낮음	높음
결과 해석 용이성	직관적	계수로 해석 가능	어려움
입문 데이터셋 적합성	매우 높음	매우 높음	낮음

KNN(K-최근접 이웃)은 "새 데이터와 가장 가까운 K개의 학습 데이터를 찾아 다수결로 분류한다"는 아이디어 하나로 작동한다. 유클리드 거리라는 개념만 알면 내부 메커니즘을 시각화할 수 있다. 이게 입문자에게 결정적인 장점이다.

로지스틱 회귀는 "이 데이터가 클래스 A에 속할 확률이 얼마인가?"를 직접 출력한다. 예측 결과가 확률값으로 나오기 때문에 "왜 이 예측이 나왔는지"를 학습 초반부터 해석하는 연습을 할 수 있다.

두 모델 모두 scikit-learn에서 동일한 fit/predict 인터페이스를 쓴다. KNN으로 시작해서 로지스틱 회귀로 교체하는 데 코드 한 줄 수준의 차이밖에 없다. 이 교체 실험 자체가 "알고리즘 선택이 성능에 어떤 영향을 미치는지" 체감하는 최초의 설계 결정이 된다.

첫 KNN 프로젝트의 데이터와 목표를 어떻게 정의할까?

프로젝트 정의는 데이터셋 선택에서 시작한다. 입문 단계에서 좋은 데이터셋의 조건은 단순하다.

클래스가 명확히 구분된 분류 문제여야 한다. 꽃 품종(Iris), 유방암 진단(Breast Cancer), 손글씨 숫자(MNIST 서브셋) 등이 대표적이다.
결측값이 없거나 거의 없는 데이터로 시작해야 전처리 부담 없이 모델 자체에 집중할 수 있다.
피처(특성)가 4~10개 수준이면 이상적이다. 너무 적으면 의미 있는 패턴을 배우기 어렵고, 너무 많으면 KNN에서 차원의 저주 문제가 생긴다.

scikit-learn에는 이 조건을 모두 만족하는 데이터셋이 datasets 모듈에 내장돼 있다. 별도 파일 다운로드 없이 바로 불러올 수 있어서 환경 셋업 문제로 시간을 낭비하지 않는다.

목표는 명확하게 정한다. "붓꽃 데이터에서 꽃잎 길이·너비 정보를 기반으로 3가지 품종을 분류하는 KNN 모델 프로토타입을 만든다." 이 한 문장이 프로젝트 범위를 정의한다. 정확도를 높이는 것은 그 다음 단계다.

모두의AI 플레이그라운드로 피드백 루프를 어떻게 짧게 만들까?

코드를 로컬에 처음 세팅하는 과정은 생각보다 막히는 지점이 많다. Python 버전 충돌, 가상환경 설정, 패키지 설치 오류 — 이 장벽들이 실제 학습 시작 전에 의욕을 꺾는다.

모두의AI 머신러닝 기초 플레이그라운드는 이 셋업 문제를 건너뛰게 해준다. 브라우저에서 바로 코드를 실행하고, 모델 파라미터를 바꿔가며 결과를 즉시 확인할 수 있는 환경이다. K값을 3으로 설정했을 때와 7로 설정했을 때 결정 경계가 어떻게 달라지는지, 시각화와 함께 보면서 개념을 체화하는 방식이다.

로컬 환경이 완성된 이후에도 플레이그라운드를 병행하는 게 유용하다. 빠른 실험이 필요할 때 환경 걱정 없이 아이디어를 바로 테스트할 수 있기 때문이다.

첫 KNN 코드를 실행하고 예측을 도출하는 단계별 과정

아래는 실제로 로컬 Python 환경(Python 3.8 이상, scikit-learn 설치 완료 기준)에서 실행 가능한 전체 흐름이다.

1단계 — 데이터 불러오기와 분할

from sklearn.datasets import load_iris
from sklearn.model_selection import train_test_split

data = load_iris()
X, y = data.data, data.target

X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, random_state=42
)

train_test_split은 전체 데이터를 학습용과 테스트용으로 나눈다. test_size=0.2는 20%를 테스트에 쓰겠다는 의미다. random_state=42는 매번 같은 방식으로 나뉘도록 고정하는 시드값이다.

2단계 — KNN 모델 학습

from sklearn.neighbors import KNeighborsClassifier

model = KNeighborsClassifier(n_neighbors=5)
model.fit(X_train, y_train)

n_neighbors=5는 K값, 즉 새 데이터를 분류할 때 참고할 이웃 데이터의 수다. 이 숫자를 바꾸는 것만으로 모델 동작이 달라진다.

3단계 — 예측 결과 확인

predictions = model.predict(X_test)
print(predictions)
print(y_test)

출력된 두 배열을 나란히 보면 어디서 맞고 어디서 틀렸는지 직접 확인할 수 있다. 정확도 수치보다 이 비교가 먼저다.

4단계 — 정확도 측정과 파라미터 비교

from sklearn.metrics import accuracy_score

acc = accuracy_score(y_test, predictions)
print(f"KNN (K=5) 정확도: {acc:.2f}")

K값을 1, 3, 5, 7, 11로 바꿔가며 같은 코드를 돌려본다. K가 작을수록 학습 데이터에 민감하게 반응하고, K가 커질수록 결정 경계가 부드러워진다. 이 변화를 직접 숫자로 보는 것이 KNN의 bias-variance 트레이드오프를 체감하는 가장 빠른 방법이다.

5단계 — 로지스틱 회귀로 교체해보기

from sklearn.linear_model import LogisticRegression

lr_model = LogisticRegression(max_iter=200)
lr_model.fit(X_train, y_train)
lr_acc = accuracy_score(y_test, lr_model.predict(X_test))
print(f"로지스틱 회귀 정확도: {lr_acc:.2f}")

모델 클래스 이름 하나만 바꿨다. fit과 predict 인터페이스는 동일하다. 두 모델의 결과를 나란히 놓고 비교하는 것 자체가 "알고리즘 선택 실험"이라는 머신러닝의 핵심 사고방식을 익히는 과정이다.

자주 묻는 질문

Python과 scikit-learn을 처음 설치할 때 어떤 순서로 진행해야 할까?

Anaconda 배포판을 설치하면 Python, scikit-learn, numpy, pandas가 한 번에 세팅된다. 개별 패키지 설치 충돌을 피하는 가장 안정적인 방법이다. 설치 후 conda create -n ml_env python=3.10 명령으로 독립된 가상환경을 만들고 그 안에서 작업하면 패키지 간 충돌을 원천 차단할 수 있다.

KNN에서 K값을 얼마로 설정하는 것이 좋은 시작점일까?

정답은 없지만, K=5가 일반적인 출발점이다. K가 너무 작으면(K=1) 노이즈 데이터 하나에도 결과가 흔들리고, 너무 크면 서로 다른 클래스가 뒤섞인다. 홀수를 쓰면 동점 상황을 피할 수 있다는 실용적인 이유도 있다. 데이터 크기의 제곱근 근처 값을 K 탐색 범위의 기준으로 삼는 경험칙도 있다.

입문 프로젝트에서 정확도 외에 어떤 지표를 봐야 할까?

정확도는 클래스가 균등하게 분포된 데이터에서는 유효하지만, 불균형 데이터에서는 오해를 준다. confusion matrix(혼동 행렬)를 먼저 보는 습관을 들이는 게 좋다. 어떤 클래스를 어떤 클래스로 착각하는지 패턴이 보이면, 그 다음 개선 방향이 잡힌다.

로컬 환경 없이도 머신러닝 프로젝트를 실습할 수 있을까?

가능하다. Google Colab은 브라우저에서 Python과 scikit-learn을 바로 실행할 수 있는 환경을 무료로 제공한다. 모두의AI 플레이그라운드도 셋업 없이 핵심 개념을 실험하는 데 적합하다. 로컬 환경은 실습이 어느 정도 익숙해진 뒤에 세팅해도 늦지 않다.

KNN 프로토타입이 완성된 다음 어떤 방향으로 심화해야 할까?

전처리 파이프라인(특성 정규화, 결측값 처리)과 교차 검증(cross-validation)이 다음 단계다. KNN은 피처 스케일에 민감해서, StandardScaler로 정규화하기 전과 후를 비교하는 실험이 자연스러운 심화 과제가 된다. 그 다음에 Random Forest나 SVM으로 넘어가면 알고리즘 비교 실험 능력이 생긴다.

모든 알고리즘을 이해하고 나서 시작하겠다는 생각은 실제로는 시작을 미루는 것과 같다. KNN 분류 모델 프로토타입 하나를 내 컴퓨터에서 직접 돌려보고, K값을 바꾸고, 다른 알고리즘으로 교체해보는 경험이 쌓이면 — 이론은 그 경험 위에서 훨씬 빠르게 자리를 잡는다. 모두의AI 머신러닝 기초 플레이그라운드에서 셋업 없이 이 과정을 먼저 체험해보고, 로컬 환경으로 확장하는 순서를 권한다.

더 보기: mdooai.com

맥북 브라우저에서 Option+X로 현재 탭을 업무 UI로 즉각 전환하는 작동 프로토타입

이종현 — Mon, 27 Jul 2026 00:15:43 +0000

https://chromewebstore.google.com/detail/ipjhcdakgdfajpoegjeebpkklflppdol?utm_source=item-share-cb

맥북 화면을 빠르게 전환해야 할 때, macOS 기본 분할 보기만으로는 브라우저 탭 단위의 세밀한 제어가 어렵습니다. Workmask 크롬 확장 프로그램은 Option+X 한 번으로 현재 탭 위에 generic 업무용 UI 스타일을 즉각 오버레이합니다 — 외부 서버 전송 없이, 로컬에서만.

macOS 기본 화면 분할 및 단축키 제어의 한계

macOS의 Split View(화면 분할 보기)는 앱 창 두 개를 나란히 배치하는 데는 충분합니다. Control+↑로 Mission Control을 열고, 상단 영역에 창을 끌어다 놓거나, 창 최대화 버튼을 길게 눌러 분할을 시작할 수 있습니다.

그런데 이 방식에는 분명한 구조적 제약이 있습니다.

탭 단위 전환 불가: Split View는 창(window) 레벨에서 작동합니다. 크롬 브라우저 안의 특정 탭만 골라 화면 모양을 바꾸는 기능은 없습니다.
전환 속도 문제: 드래그·클릭 조작이 필요해, 빠른 맥락 전환에는 키보드 단축키만큼 즉각적이지 않습니다.
오버레이 없음: 탭 URL이나 페이지 내용이 그대로 노출됩니다. 공유 공간에서 화면을 정리하고 싶을 때 macOS 자체 기능으로는 대응하기 어렵습니다.

크롬 자체 단축키(⌘+숫자, ⌘+T, ⌘+W)는 탭 이동과 개폐를 지원하지만, 탭 화면 위에 다른 UI를 덮는 기능은 브라우저 확장 프로그램 영역입니다.

Option+X가 특정 탭만 업무 화면으로 바꾸는 원리는?

Option+X를 누르면 Workmask 확장 프로그램이 현재 활성 탭의 DOM 최상단에 풀스크린 오버레이 레이어를 삽입합니다. 페이지 콘텐츠는 그 아래에 그대로 있고, 화면에 보이는 것은 선택된 generic 업무 UI 테마입니다.

작동 순서를 단계별로 정리하면 다음과 같습니다.

1단계 — 확장 설치 및 단축키 등록
크롬 웹 스토어에서 Workmask를 설치하면 Option+X(Mac) 단축키가 자동으로 등록됩니다. 크롬 설정 → 확장 프로그램 → 키보드 단축키에서 직접 확인하거나 변경할 수 있습니다.

2단계 — 팝업에서 테마 선택
확장 아이콘을 클릭하면 팝업이 열립니다. 여기서 18가지 generic 업무 UI 스타일 중 하나를 선택합니다. 선택은 해당 탭에 로컬로 저장됩니다.

3단계 — Option+X로 오버레이 ON/OFF
같은 단축키를 다시 누르면 오버레이가 해제됩니다. 토글 방식이므로 별도의 해제 버튼이 필요 없습니다.

4단계 — 탭 아이콘과 제목 변경
오버레이가 활성화된 동안 탭의 파비콘(아이콘)과 제목도 선택한 테마에 맞게 바뀝니다. 탭 목록만 훑어봐도 어떤 테마가 적용됐는지 한눈에 구분됩니다.

핵심은 확장 프로그램이 페이지 내용을 읽거나 수정하지 않는다는 점입니다. 오버레이는 페이지 위에 올려지는 별도 레이어이며, 원래 탭은 백그라운드에서 정상 작동합니다.

18가지 업무 UI 테마의 디자인 방향

Workmask 테마는 특정 앱을 복제하거나 공식 UI를 사칭하지 않습니다. 어떤 소프트웨어 브랜드와도 제휴·승인 관계가 없으며, 모든 테마는 "이런 종류의 업무 도구처럼 보이는 generic 스타일"입니다.

테마 카테고리	스타일 특징	대표 UI 요소
스프레드시트형	격자 레이아웃, 상단 메뉴바	행·열 헤더, 셀 하이라이트
문서 편집기형	여백 중심, 단색 배경	루비 텍스트 영역, 툴바
대시보드형	카드 분할, 수치 표시 영역	위젯 박스, 차트 영역 틀
코드 편집기형	다크 배경, 사이드바	파일 트리 패널, 줄 번호 영역
이메일 클라이언트형	3단 패널, 리스트 뷰	받은 편지함 목록, 미리보기 창
프로젝트 보드형	컬럼 카드 배열	상태 레인, 카드 썸네일

18개 테마 전체가 위의 6가지 카테고리 안에서 색상 팔레트, 폰트 굵기, 패널 배치를 달리해 변주됩니다. 실제 앱 로고나 등록 상표 요소는 포함되지 않습니다.

테마 디자인의 기본 원칙은 하나입니다: 보는 사람이 "업무용 화면이구나"라고 인식할 수 있어야 하지만, 특정 앱을 확정적으로 떠올리게 해서는 안 됩니다. 이 선이 generic과 사칭의 경계입니다.

브라우저에서 화면을 전환할 때 프라이버시는 어떻게 보호되나?

Workmask는 Chrome Extension User Data Policy를 준수하며, 데이터 처리 방식은 다음과 같습니다.

저장 위치: 테마 선택, 단축키 설정 등 모든 사용자 설정은 브라우저 로컬 스토리지에만 저장됩니다. 외부 서버로 전송되지 않습니다.
페이지 내용 미전송: 확장 프로그램은 현재 탭의 URL과 DOM 구조를 읽어 오버레이를 삽입하지만, 그 내용을 외부로 내보내지 않습니다.
세션 간 유지: 브라우저를 닫았다 다시 열어도 테마 설정은 로컬에 남아 있습니다. 단, 브라우저 데이터를 직접 삭제하면 설정도 함께 지워집니다.
외부 요청 없음: 오버레이 렌더링은 크롬 확장 자체 리소스만 사용하며, 설정 저장을 위해 외부 API를 호출하지 않습니다.

이 구조는 원격 근무 환경이나 공용 네트워크에서도 화면 전환 도구를 사용할 때 데이터 유출 경로를 원천 차단합니다. 클라우드 동기화 기능은 현재 없으며, 의도적으로 설계된 선택입니다.

macOS 화면 전환 방법 비교

맥북에서 화면을 빠르게 전환하는 방법은 여러 가지입니다. 어떤 목적에 맞는지 아래 표로 정리했습니다.

방법	탭 단위 제어	단축키 속도	오버레이	프라이버시
macOS Split View	✗ (창 단위)	중간	✗	해당 없음
Mission Control (Control+↑)	✗	중간	✗	해당 없음
크롬 탭 단축키 (⌘+숫자)	△ (탭 이동만)	빠름	✗	해당 없음
Workmask (Option+X)	✓ (탭 단위)	즉각	✓	로컬 저장

화면 분할 자체가 목적이라면 Split View나 Mission Control로 충분합니다. 하지만 특정 탭의 화면을 업무 UI처럼 보이게 바꾸고 싶다면, 브라우저 확장 프로그램 레벨의 접근이 필요합니다.

자주 묻는 질문

Option+X 단축키가 다른 앱과 충돌하면 어떻게 하나?

크롬 설정 → 확장 프로그램 → 키보드 단축키 메뉴에서 Workmask의 단축키를 원하는 조합으로 변경할 수 있습니다. macOS 시스템 단축키와 겹치지 않는 조합을 직접 지정하면 충돌을 피할 수 있습니다.

오버레이가 적용된 탭에서 원래 페이지를 계속 사용할 수 있나?

오버레이는 시각적 레이어입니다. 아래의 원래 탭은 그대로 작동하며 데이터가 손실되지 않습니다. Option+X를 다시 누르면 즉시 원래 화면으로 돌아옵니다.

18가지 테마가 특정 앱의 공식 UI인가?

아닙니다. 모든 테마는 generic 업무용 스타일이며, 어떤 소프트웨어 브랜드와도 제휴·승인 관계가 없습니다. 스프레드시트나 대시보드처럼 "보이는" 일반 UI 패턴을 사용하지만, 실제 앱 로고나 등록 상표 요소는 포함하지 않습니다.

브라우저 데이터를 삭제하면 설정이 사라지나?

맞습니다. 테마 선택과 단축키 설정은 브라우저 로컬 스토리지에 저장되므로, 브라우저 데이터 전체 삭제 시 함께 지워집니다. 반대로, 크롬 계정 동기화를 통해 다른 기기로 이전되지는 않습니다.

맥북이 아닌 윈도우 환경에서도 사용할 수 있나?

크롬 확장 프로그램이므로 Windows의 크롬에서도 설치됩니다. 단, Windows에서는 단축키가 Alt+X입니다. macOS에서는 Option+X입니다.

맥북 화면 전환 문제의 핵심은 어느 레벨에서 제어할 것인지입니다. macOS 기본 도구는 창 레벨까지만 다루고, 탭 단위의 시각적 제어는 브라우저 확장 프로그램의 영역입니다. Workmask 크롬 확장 프로그램을 설치하고 Option+X의 오버레이 작동을 직접 테스트해 보십시오 — 설치 후 단축키 한 번이면 어떤 탭이든 generic 업무 UI 스타일로 즉각 전환됩니다.

네이버 지도 사진, 키보드만으로 즉시 확대하고 탐색하는 단축키 완전 정리

이종현 — Mon, 27 Jul 2026 00:09:48 +0000

https://chromewebstore.google.com/detail/igegecemmlclhfnjfcdofpbklonikjka?utm_source=item-share-cb

Alt+Shift+F 하나로 사진 탭을 전체화면 갤러리로 열고, 방향키로 사진을 넘기고, Esc로 닫는다. 마우스 없이 네이버 지도 사진을 탐색하는 방법은 생각보다 단순하다 — 단, 올바른 도구가 설치되어 있어야 한다.

무한 스크롤 썸네일이 번거로운 이유

네이버 지도에서 카페 분위기를 사전에 확인하거나 식당 내부 사진을 빠르게 훑으려면, 기본 UI는 작은 썸네일 목록을 끝없이 스크롤하는 방식을 요구한다. 클릭 → 확대 → 닫기 → 다시 클릭. 사진을 다섯 장만 봐도 손목이 지친다.

사진을 실제로 비교할 때 필요한 건 전체화면 그리드와 키보드 탐색이다. 썸네일 무한 스크롤은 장소 분위기를 파악하는 워크플로에 맞지 않는다. 특히 여러 후보 장소를 연속으로 검토할 때 — 마우스를 쓰면 동선이 분산되고 집중이 끊긴다.

이 단축키 가이드가 다루는 것은 바로 그 간격을 채우는 도구다. 네이버 지도 와이드 갤러리 확장 프로그램이 제공하는 키보드 단축키 전체를 정리한다.

Alt+Shift+F 키로 즉시 사진 탭을 전체화면으로 여는 방법은?

핵심 단축키는 Alt+Shift+F다. 네이버 지도에서 특정 장소 페이지를 열고 있다면, 사진 탭을 직접 클릭하지 않아도 된다. Alt+Shift+F를 누르는 순간 사진 탭이 활성화되면서 전체화면 갤러리 뷰가 즉시 열린다.

작동 원리를 단계별로 풀면 이렇다:

네이버 지도에서 장소 페이지 진입 — 검색 결과에서 원하는 카페나 식당을 클릭해 상세 패널을 연다.
Alt+Shift+F 입력 — 확장 프로그램이 현재 페이지의 사진 탭을 감지하고 전체화면 갤러리 모드를 실행한다.
전체화면 그리드 진입 — 작은 썸네일 대신 큰 이미지 그리드가 펼쳐진다. 여기서부터는 키보드만으로 이동한다.

이 단축키가 유효한 조건: 네이버 지도(map.naver.com) 도메인이어야 하고, 장소 상세 페이지가 열려 있어야 한다. 다른 탭이나 검색 결과 목록 페이지에서는 동작하지 않는다.

Alt+Shift+F는 기존 브라우저 단축키와 충돌하지 않도록 설계된 조합이다. 크롬 기본 단축키와 겹치지 않으므로 별도 설정 없이 바로 쓸 수 있다.

방향키·Enter·Esc로 사진을 탐색하고 닫는 방법은?

전체화면 갤러리에 진입한 뒤부터는 손이 키보드를 떠날 필요가 없다.

키	동작
`→` (오른쪽 방향키)	다음 사진으로 이동
`←` (왼쪽 방향키)	이전 사진으로 이동
`↓` (아래쪽 방향키)	다음 행의 사진으로 이동 (그리드 탐색)
`↑` (위쪽 방향키)	이전 행의 사진으로 이동 (그리드 탐색)
`Enter`	현재 선택 사진 상세 확대 보기
`Esc`	상세 보기 닫기 또는 갤러리 종료

그리드 탐색이라는 표현이 중요하다. 단순히 사진을 하나씩 넘기는 게 아니라, 격자 구조를 ↑↓로도 이동할 수 있다는 의미다. 한 행에 사진 세 장이 있다면, ↓를 누르면 그 아래 행의 같은 위치 사진으로 바로 건너간다. 큰 그리드에서 빠르게 원하는 사진을 찾을 때 유용하다.

Enter로 상세 확대를 열면 원본에 가까운 크기로 사진을 볼 수 있다. 여기서 다시 ← →로 사진을 넘길 수 있고, Esc를 누르면 그리드 뷰로 돌아온다. Esc를 한 번 더 누르면 갤러리 전체가 닫힌다.

이 구조는 Lightbox 인터페이스 — 웹에서 오랫동안 표준으로 쓰여온 이미지 확대 레이어 패턴 — 와 같은 개념이다. 이미 익숙한 패턴이라 별도 학습 없이 바로 적응된다.

동영상 재생과 테마 전환은 어떻게 작동하는가

네이버 지도 사진 탭에는 사진뿐 아니라 영상이 섞여 있는 경우가 많다. 확장 프로그램은 동영상도 갤러리 안에서 그대로 재생 지원한다. 별도 플레이어로 이동하거나 새 탭을 열지 않아도 된다. 방향키로 탐색하다 동영상 항목에 진입하면 Enter로 재생 시작, Esc로 그리드로 복귀하는 흐름이 그대로 유지된다.

테마 전환은 시각적 환경을 취향에 맞게 조정하는 기능이다. 7가지 테마를 제공한다:

다크 (기본)
라이트
세피아
슬레이트
로즈
인디고
포레스트

테마 전환은 갤러리 내 설정 버튼에서 선택하거나, 단축키로 순환할 수 있다. 사진 색감을 실제와 가깝게 보고 싶다면 라이트, 오래 보는 야간 작업이라면 다크가 눈에 덜 부담스럽다. 이 선택은 개인 취향이라 '정답'이 없다 — 다만 7가지 옵션이 있다는 사실을 아는 것과 모르는 것은 차이가 난다.

그리드 크기도 조절 가능하다. 사진을 크게 보며 느리게 탐색할 수도 있고, 작은 그리드로 많은 장수를 한눈에 볼 수도 있다. 이 조합 — 그리드 크기 + 테마 + 키보드 탐색 — 이 기본 네이버 지도 UI와 실제로 다른 점이다.

개인정보를 전송하지 않는 단축키 도구를 고르는 기준은?

브라우저 확장 프로그램은 설치 시 권한을 요청한다. 어떤 확장은 방문한 모든 사이트의 데이터를 읽는 권한을 요구하고, 일부는 이를 외부 서버로 전송한다. 단축키 도구 하나를 쓰기 위해 그 정도 권한을 허용하는 건 과한 비용이다.

네이버 지도 와이드 갤러리는 map.naver.com 도메인에서만 동작하도록 권한이 제한되어 있다. 다른 사이트에는 접근하지 않는다. 수집하는 데이터가 없고, 외부 서버로 전송하는 정보도 없다. 단축키 설정이나 테마 선택처럼 저장이 필요한 설정은 브라우저 로컬 스토리지에 보관된다 — 서버가 아니라 사용자 기기 안에서만 머문다.

확장 프로그램을 선택할 때 확인해야 할 항목을 정리하면:

확인 항목	좋은 기준	주의 신호
권한 범위	특정 도메인만 접근	"모든 사이트" 접근 요청
데이터 수집	수집 없음	사용 통계, 행동 데이터 수집
외부 전송	없음	서버 전송 명시
소스 공개 여부	오픈소스	소스 비공개
업데이트 주체	명시된 개발자/레포	불명확

오픈소스 도구는 코드를 직접 확인할 수 있다는 점에서 근거 있는 신뢰가 가능하다. '믿어달라'는 말이 아니라, 코드를 보여주는 방식이다.

자주 묻는 질문

Alt+Shift+F가 동작하지 않을 때 어떻게 확인해야 하나?

확장 프로그램이 해당 탭에서 활성화되어 있는지 먼저 확인한다. 크롬 주소창 오른쪽 확장 아이콘을 클릭해 네이버 지도 와이드 갤러리가 켜진 상태인지 본다. 장소 상세 페이지가 열려 있지 않거나, 다른 도메인에서 시도하면 단축키는 반응하지 않는다.

방향키 탐색이 스크롤과 겹치지 않나?

갤러리 오버레이가 열린 상태에서는 방향키 입력이 갤러리 내부 탐색으로만 전달된다. 페이지 스크롤은 비활성화된다. 갤러리를 Esc로 닫으면 방향키가 다시 페이지 스크롤로 돌아온다.

동영상 항목에서 Enter를 누르면 자동 재생되나?

동영상 항목에서 Enter를 누르면 상세 보기가 열리면서 재생이 시작된다. 브라우저의 자동 재생 정책(소리 없는 영상은 허용, 소리 있는 영상은 사용자 상호작용 후 허용)을 따르기 때문에 음소거 상태로 시작될 수 있다.

7가지 테마 중 어떤 걸 기본으로 쓰는 게 좋은가?

기본값은 다크다. 사진 색감을 실제와 가장 가깝게 확인하려면 라이트 테마가 낫다. 실내 조명이 어두운 환경에서 장시간 탐색할 때는 다크가 눈에 덜 자극적이다. 취향 문제이므로 테마를 순환하며 고르면 된다.

map.naver.com 외의 다른 사이트에서도 단축키가 작동하나?

작동하지 않는다. 확장 프로그램의 권한 범위가 map.naver.com으로 한정되어 있다. 다른 사이트에는 스크립트 자체가 주입되지 않으므로 단축키도, 데이터 접근도 발생하지 않는다.

네이버 지도 사진 탐색에서 마우스 반복 클릭이 번거롭다면, 문제는 사진이 많아서가 아니라 UI 구조가 키보드 탐색을 지원하지 않기 때문이다. `Alt+Shift+F`로 갤러리를 열고, 방향키로 사진을 건너고, `Enter`로 확대하고, `Esc`로 닫는 흐름 — 이것만 익히면 마우스 없이도 장소 사진을 처음부터 끝까지 훑을 수 있다.

화면 녹화에서 마크다운 업무 설명서 자동 생성까지: 변환 메커니즘 해설

이종현 — Sun, 26 Jul 2026 01:13:50 +0000

화면 녹화 데이터를 행동 로그와 DOM 컨텍스트로 분해하고, Solar Pro 3 모델이 그 데이터를 마크다운 포맷의 업무 설명서 초안으로 변환한다. 녹화를 끝내는 즉시 .md 파일을 다운로드할 수 있다.

TL;DR — 브라우저 확장이 클릭·입력 직전의 스크린샷과 DOM 메타데이터를 수집한다. Upstage Document Parse가 이미지를 구조화 텍스트로 변환하고, Solar Pro 3가 그 텍스트를 마크다운 절차서로 재구성한다. 에이전트가 초안을 자기검증한 뒤 약한 단계를 재작성한다. 결과물은 MD · Word · PDF · ZIP 중 선택해 즉시 내려받는다.

마크다운 포맷이 협업과 문서화에 최적인 이유

마크다운은 렌더링 환경을 가리지 않는다. GitHub, Notion, Confluence, VS Code 모두 .md 파일을 그대로 받아 표시한다. 별도 변환 없이 Word 또는 PDF로 내보내는 파이프라인도 표준화돼 있다. 문서 포맷 자체가 평문(plain text)이라 Git으로 버전 관리할 수 있고, diff를 줄 단위로 추적한다.

업무 설명서 관점에서는 구조가 강제된다는 점이 핵심이다. # 헤더 계층이 절차 단계를 자연스럽게 구획하고, 숫자 목록은 순서를 고정한다. 작성자가 의식적으로 구조를 설계하지 않아도, 마크다운 문법을 지키는 것만으로 가독성 있는 SOP가 나온다.

자동화 도구 입장에서도 마크다운은 파싱 비용이 낮다. LLM이 출력 포맷으로 마크다운을 생성할 때 hallucination을 줄이는 구조적 앵커 역할을 한다는 점도 실용적이다 — 모델이 ## 3단계: 저장 버튼 클릭 같은 헤더 패턴을 따라가는 동안 내용이 흐트러질 여지가 줄어든다.

브라우저 녹화에서 행동 로그와 DOM 데이터를 어떻게 추출할까?

녹화 시작은 사용자가 직접 트리거한다. 확장 아이콘을 클릭하거나 단축키를 눌러 녹화를 켜고, 같은 방식으로 끈다. 그 사이에 일어난 행동만 기록된다.

수집 레이어는 두 가지다.

행동 로그 — 클릭, 키 입력, 스크롤, 폼 제출 등의 이벤트를 타임스탬프와 함께 순서대로 쌓는다. 비밀번호 필드(type="password")와 주민번호 형식의 입력값은 마스킹 처리되어 로그에 남지 않는다.
클릭 직전 캡처 — 각 클릭 이벤트가 발생하기 직전 시점의 스크린샷을 찍는다. "버튼을 눌렀다"는 로그만 있을 때 버튼이 실제로 어디에 있었는지, 주변 UI가 어떤 상태였는지를 이미지로 남기기 위해서다.

DOM 메타데이터는 행동 로그를 보완한다. 클릭된 요소의 aria-label, data-testid, 텍스트 콘텐츠 같은 속성을 함께 수집해 "저장 버튼"인지 "삭제 버튼"인지 모델이 식별할 수 있게 한다. 스크린샷 자체는 생성 파이프라인에서만 쓰이고, 외부 서버로 전송되지 않는다. 행동 로그는 문서 생성 요청 시점에만 전달된다.

모든 중간 데이터는 IndexedDB에 먼저 저장된다. 생성이 끝나거나 사용자가 삭제하면 로컬에서 지워진다.

Solar Pro 3 모델을 통한 마크다운 문법 자동 변환의 기술적 메커니즘

행동 로그와 DOM 메타데이터가 준비되면, Upstage Document Parse가 먼저 개입한다. 클릭 직전 캡처 이미지들을 받아 화면 내 텍스트·버튼 레이블·입력 필드명을 구조화된 텍스트 블록으로 변환한다. 이미지에서 직접 글자를 읽어내는 OCR 레이어라고 보면 되지만, 레이아웃 컨텍스트(어느 섹션에 속하는 요소인지)를 함께 보존한다는 점이 단순 OCR과 다르다.

Solar Pro 3는 그 구조화 텍스트와 행동 로그를 입력으로 받아 마크다운 초안을 생성한다. 모델에 전달되는 프롬프트는 크게 세 부분이다.

행동 시퀀스(이벤트 타임라인)
Document Parse가 추출한 UI 텍스트와 레이아웃 정보
출력 포맷 지시 — 헤더 계층(#, ##, ###), 번호 목록, 스크린샷 자리 표시자, 주의 사항 블록(> ⚠️) 등을 명시한 마크다운 스키마

모델은 이 입력을 바탕으로 "1단계 → 2단계 →…" 형태의 절차서를 마크다운으로 출력한다. 각 단계에는 해당 클릭 직전 캡처 이미지의 참조가 삽입되어, 최종 문서에서 스크린샷과 설명이 나란히 놓인다.

한국어·영어 혼용 UI도 처리한다. Solar Pro 3는 Document Parse가 넘긴 UI 레이블을 그대로 쓰거나, 문맥상 자연스러운 한국어 표현으로 정리한다. 번역이 필요하면 번역하고, 고유 명사나 버튼 레이블처럼 원문을 유지해야 할 때는 원문을 남긴다.

에이전트 자기검증 루프를 통한 오류 보정과 정교한 결과물 생성

초안이 나오면 파이프라인이 멈추지 않는다. 자기검증 에이전트가 초안을 받아 다음 기준으로 각 단계를 채점한다.

행동 로그에 기록된 이벤트 수와 초안에 서술된 단계 수가 일치하는가
각 단계 설명이 DOM 메타데이터(버튼 레이블, 입력 필드명)와 충돌하지 않는가
스크린샷 참조가 해당 단계에 올바르게 연결되어 있는가
절차 흐름에 논리적 단절(예: 저장 전에 완료 확인이 나오는 경우)이 있는가

채점에서 기준 미달로 표시된 단계만 재작성 요청을 받는다. 전체를 다시 생성하지 않기 때문에 이미 적절하게 서술된 단계는 그대로 유지된다. 재작성 후 동일 기준으로 다시 채점하고, 통과하면 최종 초안으로 확정한다.

이 루프는 한 번 더 작동하지는 않는다. 두 번째 채점에서도 미달인 단계가 있으면 해당 단계에 검토 플래그를 남기고 편집기로 넘긴다. 과도하게 반복해 생성 시간을 늘리는 대신, 사용자가 직접 수정할 수 있게 판단 근거를 함께 표시한다.

수동으로 편집한 내용은 다음 재생성 시 덮어쓰지 않는다. 편집 보호 플래그가 해당 단계에 설정되어, 자동 파이프라인이 그 구간을 건드리지 않는다.

변환된 MD 파일을 즉시 다운로드하여 문서 시스템에 배포하는 법

자기검증이 끝나면 편집기 화면에 초안이 열린다. 여기서 추가 수정을 하거나 그대로 내보낼 수 있다. 출력 형식은 네 가지다.

MD — 마크다운 원본. Git 기반 문서 시스템, Notion, Obsidian에 바로 붙여넣거나 커밋한다.
Word(.docx) — 사내 템플릿을 쓰는 팀이나 Word 기반 SOP 시스템에 맞다.
PDF — 인쇄나 배포용 고정 포맷.
ZIP — MD 파일과 스크린샷 이미지를 묶어 내려받는다. 이미지가 포함된 문서를 다른 시스템으로 통째로 옮길 때 쓴다.

MD 파일 내부에는 스크린샷이 상대 경로로 참조되어 있다(![3단계](./screenshots/step_03.png)). ZIP으로 받으면 경로 구조가 그대로 유지되기 때문에 압축 해제 후 바로 렌더링된다.

Notion이나 Confluence에 붙여넣을 때는 MD를 직접 임포트하거나 클립보드 붙여넣기로 처리한다. 두 플랫폼 모두 마크다운 임포트를 지원하므로 헤더 계층과 목록 구조가 그대로 이어진다.

문서 버전 관리를 Git으로 하는 팀이라면 .md 파일을 저장소에 커밋하면 된다. 자기검증 단계를 지나 완성된 초안이므로, 커밋 메시지에 녹화 날짜와 대상 워크플로 이름을 적는 것으로 버전 이력이 남는다.

Manual Maker를 쓴다면 이 파이프라인 전체 — 녹화 → 행동 로그 + 스크린샷 → Document Parse → Solar Pro 3 → 자기검증 → 출력 — 가 브라우저 확장 하나로 묶여 있다. 업무 매뉴얼 자동 생성에 대한 전체 가이드에서 각 단계의 설정 방법을 더 자세히 볼 수 있다.

자주 묻는 질문

스크린샷이 서버에 저장되지 않는다면 이미지가 어떻게 문서에 포함되나?

스크린샷은 IndexedDB에 로컬 저장된다. Document Parse 처리 시 이미지 데이터를 API로 전달해 텍스트 추출에 쓰지만, 추출 후 서버에 보관되지 않는다. 최종 MD 파일과 ZIP에 포함되는 이미지는 로컬에서 직접 패키징된다.

Solar Pro 3가 생성한 초안을 수동으로 수정하면 다음 재실행 시 덮어써지나?

수동 편집 구간에는 편집 보호 플래그가 자동 설정된다. 재실행이나 자기검증 루프가 해당 단계를 건드리지 않는다. 보호를 해제하려면 편집기에서 직접 플래그를 제거하면 된다.

비밀번호 입력이나 민감한 정보가 포함된 화면도 녹화할 수 있나?

녹화는 가능하지만, type="password" 필드의 입력값은 행동 로그에 기록되지 않고 마스킹된다. 주민번호 형식의 숫자 패턴이 감지된 입력 필드도 같은 방식으로 처리된다. 클릭 직전 캡처에서 해당 영역은 블러 처리된다.

마크다운 외에 다른 포맷으로 처음부터 생성할 수 있나?

파이프라인은 마크다운을 중간 포맷으로 생성한 뒤 Word·PDF로 변환하는 구조다. 마크다운을 거치지 않고 바로 Word나 PDF를 생성하는 경로는 없다. 마크다운이 구조적 앵커 역할을 하기 때문에 자기검증 루프도 MD 기준으로 동작한다.

무료 버전과 Pro의 차이는 무엇인가?

무료 플랜은 매뉴얼 10페이지까지 생성할 수 있다. 10페이지를 초과하면 Pro 라이선스가 필요하다. Pro는 일회성 결제 영구 라이선스로, 구독 없이 페이지 수 제한 없이 사용한다.

화면 녹화 데이터를 마크다운 매뉴얼로 바꾸는 파이프라인의 핵심은 세 개의 레이어다 — 행동 로그 + DOM 컨텍스트로 이벤트를 정밀하게 잡고, Document Parse + Solar Pro 3로 마크다운 구조로 재구성하고, 자기검증 루프가 논리적 단절과 레이블 오류를 걸러낸다. 무료로 10페이지까지 파이프라인 전체를 써보고, 제약 없이 쓰려면 Pro 영구 라이선스로 전환하면 된다.