
Claude Code와 Codex를 넘나드는 에이전트 메모리 제작
요약
사용자의 PC 작업 정보(스크린샷, 브라우저 기록, 앱 사용 기록 등)를 수집하여 AI 에이전트의 '기억'으로 활용할 수 있게 해주는 Windows 네이티브 앱 Contextberg를 소개합니다. MCP(Model Context Protocol)를 통해 Claude Code, Cursor, GitHub Copilot 등 다양한 AI 에이전트와 문맥을 공유함으로써, 에이전트를 전환할 때 발생하는 정보 누락 문제를 해결합니다.
핵심 포인트
- 다양한 AI 에이전트(Claude Code, Codex, Cursor 등) 간의 작업 문맥 단절 문제 해결
- 스크린샷, 브라우저 기록, 키보드 입력 등 5가지 유형의 작업 신호 수집
- MCP(Model Context Protocol)를 지원하여 수집된 정보를 에이전트에게 즉시 전달 가능
- Windows 네이티브 설계로 저사양 메모리 점유 및 높은 퍼포먼스 유지
- 사용자 프라이버시를 위해 클라우드에 데이터를 저장하지 않는 설계 채택
PC 상에서의 작업 정보를 다방면에서 수집하여 로컬에 저장하고, 이를 AI 에이전트를 위한 「기억」으로서 MCP (Model Context Protocol)를 통해 전달하는 Windows 네이티브 앱 Contextberg를 제작하여 Microsoft Store에 공개했습니다.
수집하는 정보는 스크린샷, 브라우저 방문 기록, 키보드 입력, 앱 사용 기록, 에이전트 대화 기록의 5가지 종류입니다 (상세 내용은 후술). Claude Code / Codex / Cursor / GitHub Copilot / OpenClaw / LM Studio 등 MCP 호환 클라이언트에서 동작합니다.
최근의 개발 스타일로서, Claude Code와 Codex를 중심으로 여러 AI 에이전트를 넘나들며 구분해서 사용하는 것이 당연해졌습니다. 설계 논의는 Claude Code, 별도의 리뷰나 차이 검증은 Codex, 보조적인 편집은 Cursor, 터미널에서는 GitHub Copilot — 하는 식입니다.
하지만 각 에이전트는 서로의 대화를 보고 있지 않습니다. 게다가 작업의 의사결정은 대화에 도달하기 전 단계(브라우저 열람, 별도 앱에서의 시행착오)에서 대부분 끝납니다. 결과적으로, 매 세션마다 스스로 자신의 상황을 다시 말해줘야 하는 시간이 어떻게든 사라지지 않았습니다.
구체적으로는, 이런 누락이 매일 쌓여갑니다.
- 월요일 밤, Stack Overflow와 GitHub Issue를 30분 동안 읽고 특정 구현 방침을 채택했다
→ 어느 에이전트의 대화 기록에도 남지 않음 (에이전트를 열어두지 않았기 때문) - 화요일 아침, Claude Code로 이어서 하려고 상담한다
→ 월요일의 브라우저 열람 내용도, 다른 에이전트에서 결정한 방침도 전달할 수 없다. 처음부터 다시 논의해야 한다
「금요일의 작업부터 이어서」를 진정한 의미로 에이전트가 재개하게 하려면, 작업의 문맥(Context) 그 자체 — 화면에 무엇이 비치고 있었는지, 브라우저에서 무엇을 읽었는지, 어떤 앱에서 몇 분간 작업했는지, 각 에이전트와 무엇을 이야기했는지 — 를 하나로 묶어 기록해 두는 장소가 필요합니다.
비슷해 보이는 도구들은 이미 몇 가지 써보았습니다. 하지만 어느 것도 한 단계씩 부족했습니다.
- OSS (Open Source Software)는 직접 빌드해야 함. .NET / Node 환경을 갖추고 수동으로 빌드하지 않으면 사용할 수 없는 도구가 많아, 개발자 이외에게는 추천할 수 없음
- 「설정 불필요」를 요구하면 유료. 상용 SaaS는 편리한 반면, 첫 경험을 시도하기도 전에 결제 화면에서 멈춤
- 백그라운드에서 필요 이상의 처리가 돌아 메모리를 점유함. 상주 앱으로서 500MB~1GB를 차지하는 것도 흔하며, 회사 PC에서는 생사 문제임 (후술)
- AI Native 설계가 아님. 대화 기록 뷰어에 불과하며, 「에이전트가 context로서 가져다 쓴다」는 전제로 만들어지지 않음
- MCP / Export 경로가 없음. 어렵게 기억을 저장해도 에이전트에 전달하는 동선이 앱 내 채팅으로 한정되어 외부로 내보낼 수 없음
- macOS 전용. 이것이 가장 뼈아픔. Windows 개발자는 소외됨
개발자 이외의 분들에게도 닿을 수 있는 형태로 「에이전트의 기억」 문제를 해결하려면, 빌드 불필요·가입만으로 사용 가능·상주해도 방해하지 않음·처음부터 MCP로 외부로 내보낼 수 있는 앱이 필요하다고 판단했습니다.
- 제작 동기
- Contextberg의 기능 — 4가지 기둥
- 5분 만에 체험하기
- 무엇을 기록하는가 — 5가지 신호
- Record 탭과 Memory 탭 — 취득한 신호를 사용자가 다룰 수 있는 UI
- 3층 구조의 기억 파이프라인
- 프라이버시 설계 — 클라우드 측에서는 일절 보유하지 않는다는 방침
- 퍼포먼스 설계 — 왜 Windows-native를 고집했는가
- MCP로 에이전트에 전달하기
- 플랜 — Free와 Lite의 경계
- 이런 분들에게 추천
- 로드맵
- 마치며
기술적인 상세 내용에 들어가기 전에, 사용자 관점에서의 앱 전체상을 4가지 기둥으로 정리합니다.
-
모든 창의 스크린샷을 MCP를 통해 에이전트에 직접 제공
-
브라우저 방문 기록 자동 수집 (Chrome / Edge의
HistorySQLite에서 URL과 타이틀 추출) -
Claude Code / Codex / Cursor / 터미널의 대화 기록 수집
-
MCP 서버 내장 — 대응 에이전트를 클릭 한 번으로 연결
-
단기 메모리 (Short-Term Memory, Hourly Report): 시간별·액티비티별로 수행한 작업을 자동 기록
-
장기 메모리 (LTM, Long-Term Memory): 자주 사용하는 도구·습관·작업 패턴을 축적 - 모두 자동 생성되어 에이전트가 언제든 추론에 활용 가능
-
액티비티·스크린샷·브라우저 기록은 모두 로컬에 저장 - AI 처리는 기본적으로 클라우드 모델 (Google Gemini 경유, BFF가 API 키를 보유)
-
LM Studio로 전환하면 완전 오프라인으로 동작
1. Microsoft Store에서 「Contextberg」를 검색하여 설치
또는 https://apps.microsoft.com/detail/9nhpvl6s5dw9 를 열기
2. 앱 실행 → Google 로그인 (무료 플랜으로 가능)
...
Contextberg의 설계상의 출발점은 **「에이전트의 대화 기록만으로는 기억으로서 불충분하다」**는 판단이었습니다.
에이전트 대화 기록을 가져오는 도구는 이미 몇 가지 있지만, 개발 의사결정은 대화에 도달하기 전 단계에서 대부분 끝납니다. Stack Overflow의 토론을 읽고, GitHub Issue를 살펴보고, VS Code에서 30분 동안 고민하다 결국 건드리지 않는 것 ―― 이러한 종류의 리서치·열람·시행착오는 대화 기록에 남지 않습니다. 남는 것은 「방침이 확정된 후 에이전트에게 던진 마지막 한 수」뿐입니다.
그래서 Contextberg는 PC 상에서 일어나고 있는 일을 통째로 5가지 신호로서 기록합니다.
| 신호 | 기록 내용 | 목적 |
|---|---|---|
| 앱 / 윈도우 사용 | 포그라운드(Foreground) 프로세스명·윈도우 타이틀·체류 시간 | 「VS Code에서 1시간 동안 Auth 관련 작업」과 같은 시간 배분을 복원 |
| 브라우저 기록 | Chrome / Edge의 History SQLite로부터 URL·타이틀·최종 방문 시각 | 「Stack Overflow의 이 토론을 읽었다」를 복원 |
| 스크린샷 | 활성 윈도우의 캡처 이미지 (PNG) | 「화면에 무엇이 찍혀 있었는지」를 나중에 인간과 AI 모두 다시 읽을 수 있음 |
| 키보드 입력 | 입력 로그 (앱별 타건 기록) | 「무엇을 쓰고 있었는지」, 「어디에서 막혔는지」에 대한 단서 |
| 에이전트 대화 기록 | Claude Code / Cursor / Codex / 터미널 등의 대화 턴 (Turn) | 각 에이전트와의 상호작용을 횡단적으로 재구성 |
핵심은 이 5가지를 하나의 타임라인으로 통합하는 것입니다. 대화 기록 단독으로는 「무엇을 결정했는가」만 알 수 있지만, 브라우저·화면·키보드·앱 사용과 결합하면 「왜 그런 판단에 이르렀는가」까지 에이전트가 추적할 수 있게 됩니다.
「전부 기록한다고? 프라이버시는?」이라는 의문이 당연히 들 것입니다. 모든 데이터는 PC의 로컬에만 저장되며, 외부로 나가는 것은 AI 요약을 위한 정제된 텍스트뿐입니다. 또한 LM Studio로 전환하면 일절 나가지 않도록 설계되었습니다. 자세한 내용은 후술할 「프라이버시 설계」 장에서 다룹니다.
「백그라운드에서 수집하여 MCP로 전달한다」라고만 하면 사용자는 무엇이 쌓이고 있는지 불안해할 수 있습니다. Contextberg는 앱 내에 2개의 탭을 마련하여, 수집된 신호와 생성된 기억을 사용자 스스로 직접 볼 수 있도록 했습니다.
「현재 무엇이 기록되고 있는지」를 시각화하는 탭입니다.
- 포그라운드 앱 전환이 실시간으로 흐름
- 최근 스크린샷이 썸네일로 나열됨
- 브라우저 기록의 가져오기 상황이 실시간으로 반영됨
- 하루 사용 시간의 원형 그래프·스택 바(Stack bar)
이 탭을 열면 「감시당하고 있다」는 추상적인 불안이, 실제로 무엇이 기록되었는지 눈으로 확인할 수 있는 안심으로 바뀌도록 설계했습니다. 또한 단순히 자리를 비운 후나 과거를 회상할 수 있는 기능으로도 활용됩니다.
「쌓인 기억을 사용자 스스로 읽는」 탭입니다. 단기 메모리와 장기 메모리를 각각 관리할 수 있습니다.
- LTM은 사용자가 수동으로 편집 가능합니다. AI가 실수로 기록한 사실을 지우거나, 스스로 「나는 X를 좋아함」과 같은 내용을 추가할 수 있습니다.
- 각 Hourly Report로부터 곧바로 Chat 탭에서 심층 탐구가 가능합니다 (예: "이때의 판단을 자세히 알려줘" 등)
Contextberg에서는 용도가 다른 3가지 종류의 메모리를 구분하여 사용하고 있습니다. 각각 업데이트 빈도와 참조 상황이 다를 뿐, "하위 계층을 압축하여 상위 계층에 쌓는" 식의 직선적인 파이프라인은 아닙니다.
| 메모리 | 업데이트 빈도 | 주요 용도 |
|---|---|---|
| Activity | 15분마다 | "최근 세션에서 무엇을 했는지"를 그대로 참조 |
| Hourly Report | 1시간마다 | 데일리 회고 · "오전에 뭐 했었지"에 대한 즉각적인 답변 |
| Long-Term Memory (LTM) | 1일마다 | 항구적인 사실(역할 · 취향 · 진행 중인 프로젝트)의 사전 주입 |
각 메모리는 앱 사용 시의 스크린샷 · 키보드 입력 · 에이전트 대화 이력 · 브라우징 이력을 하나로 묶어서 입력하여 생성합니다. 가공되지 않은 시그널 (Raw Signal)을 직접 전달하여 모델 측에서 요약하도록 하는 흐름입니다.
[14:00-14:18] VS Code (Contextberg.sln)
- Views/MemoryView.xaml.cs 편집
- 스크린샷 4장
...
대화의 전후로 브라우저 열람과 화면 · 키보드 움직임이 일치함으로써, "왜 그런 구현이 되었는지"까지 에이전트가 추측할 수 있게 됩니다.
Activity (15분): 최근의 시그널을 거의 그대로 읽을 수 있는 형태로 정리하는 계층. "방금 전까지 뭐 하고 있었어?"에 즉답하는 용도 -
Hourly Report (1시간): 1시간 분량의 Activity를 자연어 요약 (Natural Language Summary)으로 정리하는 계층. 일간 · 주간 회고 시 가장 많이 사용함 -
LTM (1일): 1일 분량의 Hourly로부터 항구적으로 기억해야 할 사실(역할 · 취향 · 진행 중인 프로젝트 등)을 추출하여 병합(Merge)하는 계층. 에이전트에 대한 "사전 주입 (Pre-injection)"으로서 기능함
Contextberg는 화면 · 브라우저 이력 · 키보드 입력 · 앱 사용 · 대화 이력을 폭넓게 기록합니다. "기억"이라는 기능의 본질상, 이 부분을 줄일수록 성능이 저하되기 때문입니다.
솔직히 말하면, 개인 개발 규모에서 로컬 측의 프라이버시 대응에는 한계가 있습니다. OS 후킹(Hook)이나 SQLite를 구사하더라도, 화면 녹화 · 키 입력의 모든 것에서 "위험한 것만 자동으로 제외하는 것"은 현재 제 실력으로는 불가능합니다.
그래서 방침으로서, 로컬에서는 폭넓게 기록하되, 클라우드 측에는 아무것도 남기지 않는다는 선을 그었습니다.
Microsoft Store에서는 화면 녹화 · 키보드 입력 모니터링을 수행하는 앱의 심사가 다른 카테고리보다 엄격하며, 데이터 취급 · 암호화 · 제3자 전송 여부까지 신고와 리뷰가 필요합니다. Contextberg는 이 심사를 통과했습니다. Store의 앱 페이지에 기재된 개인정보 처리방침 (Privacy Statement)과 고객 지원 연락처가 사용자가 딛을 수 있는 첫 번째 안전망이 됩니다.
스크린샷 이미지 본체 (%LOCALAPPDATA%\Contextberg\screenshots\)
키보드 입력 로그 (앱별로 SQLite에 기록, 내용 포함)
브라우저 이력 캐시 (Chrome / Edge의 History SQLite에서 URL, 제목, 최종 방문 시각 추출)
앱 사용 로그 (프로세스명 · 윈도우 타이틀 · 체류 시간)
에이전트 대화 이력 가져오기 복사본
인증 토큰 (DPAPI로 암호화, ProtectedData.Protect(bytes, null, DataProtectionScope.CurrentUser), 로그인 중인 Windows 사용자에게만 복호화 가능)
브라우저의 폼 입력 (Form Input) / Cookie / 탭의 본문은 읽기 대상에서 제외됩니다.
AI 분석 (Hourly Report / LTM 생성)을 위해, 위의 로컬 기록으로부터 **요약용으로 정제된 프롬프트 (Prompt)**를 클라우드로 보냅니다. 정제된 프롬프트에는 스크린샷 이미지 · 키보드 입력 로그 내용 · 브라우저 열람 이력 · 앱 사용 이력 · 대화 이력이 포함됩니다 (Gemini는 멀티모달 (Multimodal)이므로, 스크린샷은 이미지 상태 그대로 전달하여 모델이 읽도록 합니다).
단, 클라우드 측(BFF/ Vertex AI Gemini)에서 이를 영속화(Persistence)하지 않습니다. 요청은 스테이트리스(Stateless)하게 처리되며, AI 생성 후의 응답 텍스트만이 WPF로 반환되어 다시 로컬로 다시 쓰여집니다.
이 부분이 Contextberg 현재 프라이버시 설계의 핵심입니다. "로컬에서 전부 기록하지만, 내보낸 곳에는 남기지 않는다". 완벽하지는 않지만, 개인 개발자로서 타협할 수 있는 가장 납득 가능한 지점이었습니다.
"LLM에 보내고 싶지 않은 정보", "애초에 기록되기를 원치 않는 정보"는 Settings에서 제외 설정이 가능합니다. 구체적으로는 다음 단위로 제외할 수 있습니다.
- 앱 단위 제외: 비밀번호 관리자, 은행 앱, 특정 메시징 앱 등, 실행 중에는 Record를 일시 중지
- 윈도우 타이틀·URL 패턴 제외:
*.bank.*를 포함하는 윈도우나 특정 도메인을 무시 - 시간대 제외: 업무 시간 외·특정 시간대에는 Record 하지 않음
- 신호 단위 Off: 스크린샷만 Off, 키보드 입력만 Off와 같은 입도(Granularity)로 무효화
- Record 탭의 정지 버튼: 그 자리에서 모든 기록을 일시 중지 (재개도 클릭 한 번으로 가능)
제외 설정한 앱·윈도우는 애초에 Activity 계층에 기록되지 않으므로, Hourly Report, LTM, MCP 그 어디에서도 유출되지 않습니다.
현재의 제외 방식은 사용자가 사전에 설정해야 하며, 설정되지 않은 앱에서 비밀 정보를 다루면 평소처럼 기록됩니다. 향후 강화하고 싶은 부분은 기록 단계에서의 자동 제외입니다.
- 비밀번호 관리자, 은행 앱 등의 자동 감지 및 Record 일시 중지
- 스크린샷 내 텍스트에 대한 PII(개인 식별 정보) 탐지 및 자동 마스킹
- 인카메라(In-camera) 방식의 "지금 기록 중입니다" 알림 배너 강화
완벽하지는 않더라도, 개인 개발이라도 이 정도까지 구현하면 실용적인 안전 마진(Safety Margin)을 확보할 수 있는 라인을 목표로 하고 있습니다.
클라우드를 전혀 거치고 싶지 않다면, LM Studio로 전환하여 Hourly Report / LTM 생성도 로컬 LLM으로 완결할 수 있습니다. Settings에서 OpenAI 호환 API 엔드포인트를 지정하기만 하면 외부 통신은 제로가 됩니다. 업무용 머신이나 회사 지급 PC에서 사용하고 싶은 분들을 위해 처음부터 상정하고 만들었습니다.
사용자가 언제든 자신의 데이터를 보고, 지울 수 있음을 필수 요건으로 삼았습니다.
- Record 탭에서 기록된 건별로 육안 확인 가능
- 우클릭으로 불필요한 기록을 그 자리에서 삭제 가능 (민망한 윈도우가 찍혔을 때의 구제책)
- Settings에서 ZIP 내보내기/전체 데이터 삭제를 언제든 실행 가능
"화면·브라우저·키 입력을 상시 모니터링"한다는 말을 들으면 많은 사람이 다음에 신경 쓰는 것이 메모리와 CPU입니다. 실측 기반으로 답변하겠습니다.
| 지표 | 값 |
|---|---|
| 유휴(Idle) 시 메모리 | 120~180 MB |
| ... |
메모리·CPU·배포 크기를 억제하는 것을 하나의 설계 라인으로 두고 있습니다. 상시 구동되는 앱이기에, 이를 초과하면 "Slack이나 Chrome과 나란히 메모리를 잡아먹는 방해꾼"이 되어 사용자는 조용히 언인스톨(Uninstall)할 것입니다.
크로스 플랫폼을 포기한다는 판단은 초기 설계 시점에 내렸습니다. 이유는 다음 세 가지입니다.
- 상주 앱인 Electron은 실행 5초 만에 300~500 MB를 차지하는 경우가 많음. Chromium 프로세스를 하나 보유하는 시점에서 < 200MB 라인은 현실적으로 지킬 수 없습니다.
- Win32 API에 대한 직접 접근이 빈번하게 필요함. 키보드 후킹(Keyboard Hook), 포그라운드 윈도우의 프로세스 특정, 화면 캡처, DPAPI, MSIX 패키지 식별 ―― 이 모든 것이 .NET이라면 1~수 줄이면 되지만, Tauri / Electron이라면 FFI 레이어를 거쳐야 합니다.
- MS Store 배포가 전제됨. MSIX에 깔끔하게 올리려면 WPF + .NET 8 + Windows App SDK의 조합이 가장 마찰이 적습니다.
대가로 macOS / Linux 버전은 별도로 다시 작성해야 하며, 로드맵에 올려두었습니다. "모든 OS를 지원하지만 400MB를 먹는 앱"보다 "Windows에서만 동작하는 250MB 앱"이 초기 사용자층에게 더 매력적이다라는 판단입니다.
중장기적으로는 사내 PC에도 설치할 수 있는 툴로 만들고 싶습니다. 에이전트(Agent)를 사용하는 개발자일수록 메인 작업 환경이 회사에서 지급한 노트북인 경우가 많기 때문입니다.
하지만 기업용 PC는 메모리가 8GB 또는 16GB인 구성이 압도적으로 많습니다. Slack, Teams, Edge, VS Code, Docker Desktop을 띄워놓은 상태에서 Contextberg가 500MB를 점유하면 순식간에 생존 문제가 됩니다. 실제로 제 직장에서도 Slack 알림조차 오지 않는 빈사 상태의 노트북으로 고통받는 동료들을 자주 보곤 합니다 (웃음).
"설치하더라도 다른 업무 툴의 방해가 되지 않는" 크기로 맞추는 것이, 기업 도입을 염두에 두었을 때의 절대 요건이라고 생각합니다. 앞으로도 300MB 미만을 상한선으로 지키는 방침입니다.
Contextberg는 WPF 프로세스 내에서 **로컬 HTTP 서버 (http://127.0.0.1:18080)**를 구축하고, 얇은 MCP 프록시(Proxy)를 통해 MCP 클라이언트(Client)에 접속합니다. Claude Desktop 등 MCP 클라이언트 설정에 다음 한 블록을 추가하는 것만으로 사용할 수 있습니다 (Settings의 "Connect Claude Desktop" 버튼이 이 JSON을 자동으로 작성합니다).
{
"mcpServers": {
"contextberg": {
...
제공하는 툴:
| 툴 | 반환 내용 |
|---|---|
get_activity | 최근 N시간의 Activity (앱, 윈도우 타이틀, 스크린샷, 브라우저 히스토리) |
get_daily_memory | 지정된 날의 Daily 리포트 |
get_weekly_memory | 지정된 주의 Weekly 리포트 |
get_agent_history | Claude Code / Cursor / Codex를 가로지르는(Cross-cutting) 대화 턴(Turn) |
read_ltm | LTM(Long-Term Memory) 전체를 Markdown으로 가져오기 |
update_ltm | LTM 섹션에 차분(Diff) 추가 |
사용자 (Claude Desktop에서)
"금요일에 하던 인증 리팩토링(Refactoring) 작업, 어디까지 진행됐지?"
Claude Desktop (백그라운드에서)
...
Stack Overflow를 읽고 있었다는 사실은 대화 이력에는 남지 않지만, 브라우저 히스토리와 Hourly Report를 통해 에이전트에게 보입니다. 이것이 "대화 이력만으로는 부족했다"는 점을 보완하는 효과입니다.
| 플랜 | 포함 사항 |
|---|---|
| Free | 모든 핵심 기능 — 캡처, MCP, 로컬 LLM (LM Studio), 3층 메모리 |
| Lite | 클라우드 Gemini의 쿼터(Quota) 확장, 프리미엄 모델, 데이터 보관 기간 연장 |
Free 플랜에서도 MCP, 3층 메모리, LM Studio를 이용한 풀 로컬(Full Local) 운용까지 전부 사용할 수 있습니다. 이는 설계 의도인데, "돈을 내지 않으면 에이전트에게 기억을 전달할 수 없다"는 구조로 만들면, 본래 가장 큰 혜점을 입어야 할 개인 개발자나 학생이 시도조차 할 수 없게 되기 때문입니다.
Lite는 어디까지나 "클라우드 AI의 쿼터와 장기 보관이 필요한 사람, MCP와 Local LLM으로 커스텀하려는 사람을 위한 것"으로 현재 설계하고 있습니다. 우선 무료로 가치를 느낄 수 있도록 경계를 나누어 두었습니다.
Claude Code / Codex / Cursor / GitHub Copilot을 매일 사용하는 개발자
―― 여러 에이전트를 넘나들며 작업하는 사람일수록 기억의 단절로 인한 스트레스가 큼 - "어디까지 했었지"를 에이전트에게 다시 설명하는 것이 번거로운 사람
―― 아침 첫 15분이 무조건 사라지는 문제에 대한 해답 - 작업의 이어하기를 빠르게 재개하고 싶은 사람
―― 세션의 경계를 없애고 싶은 사람 - 데이터를 클라우드로 보내지 않고 AI의 혜택을 받고 싶은 사람
―― LM Studio 풀 로컬 운용을 통해, 사내 PC에서도 실행 가능한 수준까지 설계하고 있습니다.
반대로, 화면·브라우저 히스토리·키보드 입력을 기록하는 것 자체에 거부감이 있는 분들에게는 맞지 않습니다. 로컬 저장 방식이라 하더라도, 수집하는 신호(Signal)의 폭은 의도적으로 넓게 설정되어 있습니다.
macOS / Linux 지원
Hermes 모델 통합
Skill 명령어 자동 생성
Skills 관리 뷰
아이디어를 모집 중입니다. 댓글창에 남겨주시는 피드백을 참고하도록 하겠습니다!
개인적인 문제의식에서 시작되었지만, 많은 분이 겪고 있는 문제라고 생각하여 제품화했습니다. 제가 하루 종일 실행해도 스트레스가 쌓이지 않는다는 첫 번째 목표는 달성했으므로, 다음으로는 여러분이 직접 사용해 보시고 브러시업 (Brush-up)을 위한 다양한 제안을 주셨으면 합니다.
Product Hunt에도 동시 공개하고 있습니다. 관심이 있으시다면 upvote와 댓글로 응원해 주시면 큰 힘이 됩니다.
- Product Hunt:
https://www.producthunt.com/posts/contextberg - Microsoft Store:
https://apps.microsoft.com/detail/9nhpvl6s5dw9 - 공식 사이트: https://contextberg.com
질문이나 비판은 본 기사의 댓글창 또는 X (@screenest_ai)에서 기다리고 있겠습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기