01 / KEY DECISIONS
제가 내린 핵심 결정
- 01
어떤 앱 위에서도 바로 열리는 오버레이
- 문제
- 화면을 캡처하고 파일을 옮기기 위해 작업 중인 앱과 브라우저의 챗봇을 오가는 과정이 반복됐습니다.
- 선택
- 작은 알약형 창으로 대기하다가 누르면 대화 패널로 확장되고, 드래그로 원하는 위치에 둘 수 있는 상시 오버레이를 만들었습니다.
- 구현
- Tauri 창을 pill과 panel 두 크기로 전환하고 항상 위·작업 표시줄 제외 상태를 유지했습니다. 클릭과 드래그를 구분하고 마지막 위치를 로컬에 저장해 다음 실행 때 복원했습니다.
- 확인된 영향
- Windows 설치본에서 다른 작업 화면 위에 Clarity를 두고, 필요할 때 확장하거나 위치를 바꾸는 흐름이 작동했습니다.
- 02
자동 기록보다 요청형 맥락과 전송 전 통제
- 문제
- 초기에는 최근 1분의 화면을 자동으로 구성했지만, 여러 이미지가 세부 텍스트와 작업 흐름을 충분히 전달하지 못했고 화면 기록을 일시 정지하는 통제도 없었습니다.
- 선택
- 현재 공개본에서는 카메라 버튼을 눌렀을 때만 현재 화면을 첨부하고, 준비 상태를 확인하거나 제외한 뒤 질문을 보내도록 바꿨습니다.
- 구현
- 캡처 순간에는 오버레이를 잠시 숨긴 뒤 연결된 화면을 이미지로 만들고, 화면·이미지·문서를 reading·ready·error 상태로 정규화했습니다. ready 상태의 항목만 요청에 포함했습니다.
- 확인된 영향
- 공개본에서는 백그라운드 화면 기록을 제거하고, 질문에 포함될 항목과 처리 상태를 전송 전에 드러냈습니다.
- 03
서로 다른 AI 제공자를 하나의 대화 상태로 통합
- 문제
- OpenAI·Anthropic·Gemini·OpenRouter는 요청 본문, 이미지 전달 방식, 스트리밍 이벤트와 종료 사유가 서로 달랐습니다.
- 선택
- 제공자별 요청과 응답 처리를 어댑터로 분리하고, 대화 UI에는 공통 상태만 전달했습니다.
- 구현
- 허용된 제공자 URL만 통과하는 네이티브 HTTP 경계를 두고, 제공자별 스트림을 응답 조각·완료·오류로 정규화해 공통 reducer에 연결했습니다.
- 확인된 영향
- 같은 인터페이스에서 제공자를 바꿀 수 있게 했고, 현재 통과하는 39개 단위 테스트 중 19개가 제공자 연동 경계를 확인합니다.
IMPLEMENTATION SCOPE
오버레이부터 제공자 연동까지 혼자 구현한 범위
- 항상 위에 머무는 알약형 오버레이와 확장형 대화 패널, 드래그 이동과 위치 복원을 구현했습니다.
- 여러 모니터의 현재 화면 캡처와 이미지·텍스트·PDF·DOCX 첨부, 준비 상태와 제거 흐름을 연결했습니다.
- OpenAI·Anthropic·Gemini·OpenRouter 요청과 스트리밍 응답을 하나의 대화 상태로 정규화했습니다.
- Windows 설치형·포터블 패키징과 상태·첨부·제공자 경계의 자동화 테스트를 구성했습니다.
02 / VERIFIED OUTCOME
확인된 결과와 검증 경계
초기 Windows 설치본을 약 1주일간 직접 사용하며 핵심 흐름의 작동을 확인했습니다. 다만 최근 화면만으로는 세부적인 작업 맥락을 충분히 재구성하지 못했고, 현재 공개본은 필요한 순간의 화면만 직접 첨부하도록 단순화했습니다.
- 약 1주일간의 개인 사용
다른 Windows 기기에 설치한 초기 로컬 버전에서 오버레이·캡처·첨부·질문·응답 흐름이 작동하는 것을 확인했습니다.
- 맥락 인식의 한계
첨부 자체는 작동했지만 세부 텍스트와 작업 의도를 충분히 파악하지 못해, 상황을 직접 설명하는 편이 더 빨랐습니다.
- 현재 공개 코드의 자동화 테스트
상태 전이, 첨부 파싱, 프로필, SSE와 네 제공자 요청·응답을 다루는 39개 단위 테스트가 통과합니다.
- 제품 흐름을 설명하는 가상 시나리오
Excel에서 예상과 다른 계산 결과를 발견한 뒤 오버레이에서 현재 화면을 첨부하고 수식의 문제를 질문하는 흐름으로 검토했습니다. 실제 사용 성과를 뜻하지 않습니다.
구현으로 확인한 범위
- 알약형 오버레이와 확장형 패널, 드래그 이동과 위치 복원
- 요청형 멀티 모니터 캡처와 이미지·PDF·DOCX·텍스트 첨부
- reading·ready·error 상태와 ready 항목만 전송하는 경계
- OpenAI·Anthropic·Gemini·OpenRouter 네이티브 스트리밍 정규화
- Windows 설치형·포터블 패키징과 39개 단위 테스트
FULL PRODUCT REVIEW전체 제품 개발 회고 보기
03 / ORIGIN & PROBLEM
발단과 문제 발견
AI에게 조언을 구할 때마다 현재 화면을 캡처해 첨부하고 상황을 다시 설명해야 했습니다. AI가 이전 맥락을 놓치면 같은 설명을 반복해야 했고, 이러한 맥락 재구성의 부담을 줄이기 위해 Clarity를 만들기 시작했습니다.
브라우저뿐 아니라 게임, 계산기, Excel 등 컴퓨터에서 하는 어떤 작업 위에서도 바로 질문할 수 있어야 했습니다. 그래서 작은 알약형 오버레이로 대기하다가 누르면 대화 패널로 확장되고, 원하는 위치로 옮길 수 있는 데스크톱 앱으로 설계했습니다.
초기 로컬 버전은 화면을 일정 간격으로 임시 저장하고 1분이 지나면 자동 삭제했습니다. 질문할 때만 최근 화면을 첨부했지만, 약 1주일간 사용한 결과 세부 텍스트와 작업의 흐름을 충분히 전달하지 못했습니다. 현재 공개본은 필요한 순간의 현재 화면만 직접 첨부하는 방식으로 단순화했습니다.
확인한 문제점
- 반복되는 맥락 재구성
화면을 캡처하고 저장·첨부한 뒤, AI가 놓친 상황을 글로 다시 설명하는 과정이 반복됐습니다.
- 더 많은 이미지가 충분한 맥락은 아니었음
최근 화면과 화질이 좋은 이미지를 전달해도 몇 장의 화면만으로는 작업 순서와 질문 의도를 충분히 파악하지 못했습니다.
- 상시 캡처의 통제 부족
초기 버전은 임시 이미지를 1분 후 삭제하고 요청할 때만 전송했지만, 앱 실행 중 캡처를 일시 정지하는 기능은 없었습니다.
설계 제약
- 앱에 제한되지 않는 접근
브라우저뿐 아니라 게임, 계산기, Excel 등 어떤 데스크톱 작업 위에서도 바로 열 수 있어야 했습니다.
- 자원 사용과 맥락 품질
연속 화면 기록은 메모리 부담이 컸고, 일정 간격의 이미지만으로는 세부 텍스트와 작업 흐름을 충분히 전달하지 못했습니다.
- 1인 제작과 개인 API 키
기획, UI·UX, React/Tauri 구현, 테스트와 패키징을 혼자 맡았고 사용자가 자신의 AI 제공자 API 키를 입력하는 구조로 만들었습니다.
PRODUCT QUESTION작업 중인 앱을 벗어나지 않고 화면 맥락을 빠르게 질문에 연결하되, 전송할 정보는 직접 통제할 수 있게 하려면?
맥락 구성 흐름의 변화
화면을 직접 저장하고 챗봇에 다시 설명하던 기존 흐름, 최근 1분 화면을 자동 구성한 초기 실험, 요청할 때 현재 화면만 첨부하는 공개본 흐름의 비교
04 / ALTERNATIVES
검토한 대안과 판단
직접 캡처하고 챗봇에 설명
현재 화면을 저장해 별도의 챗봇에 첨부하고 상황을 직접 설명합니다.
- TRADE-OFF
- 필요한 내용을 명시적으로 전달할 수 있지만 캡처·이동·첨부·설명을 매번 반복해야 했습니다.
최근 1분 화면을 자동 구성
화면을 일정 간격으로 임시 저장하고, 요청할 때 최근 기록을 질문에 포함합니다.
- TRADE-OFF
- 질문 이전의 상황을 전달할 수 있지만 자원 사용과 상시 기록 부담이 있고, 세부 맥락을 충분히 전달하지 못했습니다.
요청형 현재 화면 첨부
카메라 버튼을 누른 순간의 화면만 첨부하고 전송 전에 상태를 확인합니다.
- TRADE-OFF
- 이전 작업 흐름은 직접 보완해야 하지만 질문과 관련된 순간과 전송 범위를 명확히 선택할 수 있어 공개본에 적용했습니다.
05 / DESIGN RATIONALE
설계 판단의 근거와 흐름
- 어떤 앱 위에서도 바로 열리는 오버레이작업 전환 부담 · 직접 조작
별도 화면으로 이동하는 단계를 줄이고, 오버레이의 위치와 열림 상태를 직접 조절할 수 있게 했습니다.
- 자동 기록보다 요청형 맥락과 전송 전 통제자동화와 통제 · 상태 가시성
자동으로 더 많이 수집하는 대신 필요한 순간과 전송 범위를 직접 선택하고, 첨부 준비 여부를 확인할 수 있게 했습니다.
- 서로 다른 AI 제공자를 하나의 대화 상태로 통합일관된 피드백 · 오류 회복
제공자가 달라도 응답 진행, 완료, 길이 제한과 오류를 같은 화면 언어로 보여 주도록 구성했습니다.
첨부 준비 상태와 전송 통제
화면 또는 파일을 추가하면 reading 상태를 거쳐 ready 또는 error가 표시되고, 확인과 제외 이후 ready 항목만 전송되는 흐름
로컬 앱과 외부 AI 제공자 경계
로컬 앱에서 화면 캡처와 문서 읽기, 첨부 확인을 거친 질문이 허용된 외부 제공자로 전달되고 정규화된 응답이 다시 대화 UI에 표시되는 흐름
06 / REFLECTION
배운 점과 다음 검증
더 많은 화면을 전달한다고 해서 작업 맥락이 자연스럽게 만들어지는 것은 아니었습니다. 화면 사이에서 무엇이 달라졌는지, 어떤 순서로 작업했는지, 지금 무엇을 해결하려는지가 함께 구조화되어야 했습니다. 자동 수집의 양보다 맥락의 관련성과 전송 전 통제가 중요했습니다.
아직 모르는 것
- 세부 맥락 인식 실패가 이미지 품질, 캡처 간격, 화면 수 또는 기본 프롬프트 중 무엇의 영향을 가장 크게 받았는지 분리해 확인하지 못했습니다.
- 다른 사람이 같은 흐름에서 상황 설명의 분량이나 질문 준비 시간을 줄일 수 있는지는 확인하지 않았습니다.
- API 키의 OS 보안 저장소 이전과 제공자·네트워크 오류를 포함한 장시간 운영 검증이 필요합니다.
다음에 검증할 시나리오
- 동일한 작업에서 현재 화면만 전달
- 동일한 작업에서 최근 화면을 시간순으로 전달
- 최근 화면에 변화 요약과 구조화된 기본 프롬프트를 더해 맥락 파악 정확도와 직접 설명해야 하는 분량을 비교
07 / DESIGN REFERENCES
설계 관점과 참고자료
아래 개념은 프로젝트 성과를 검증하는 근거가 아니라, 구현 이후 제가 내린 설계 판단을 설명하기 위해 참고한 관점입니다.
- 맥락과 상황Understanding and Using ContextAnind K. Dey · 2001
화면 이미지 자체와 실제 작업 상황을 구분하고, 다음 검증에서 시간 순서·변화·질문 의도를 함께 구조화해야 한다는 해석에 참고했습니다.
- 자동화와 직접 통제Principles of Mixed-Initiative User InterfacesEric Horvitz · CHI · 1999
상시 자동 수집에서 요청형 캡처로 전환하고, 전송 전에 첨부 상태를 확인·제외하도록 만든 결정을 설명하는 관점으로 사용했습니다.

