MyContext: 흩어진 업무 기록을 내 컴퓨터 안의 개인 컨텍스트로 모으는 로컬 우선 데스크톱 앱

9bow · 8월 28, 2026, 6:30오전

MyContext 소개

업무에 쓰는 기록은 이미 충분히 많지만 대부분 서로 다른 앱에 갇혀 있습니다. 지난달 결정의 근거는 메신저 대화에, 그 결정을 정리한 문서는 문서 도구에, 누가 무엇을 승인했는지는 결재 시스템에 남아 있습니다. 그래서 AI 도구에 업무 관련 질문을 던질 때마다 사람이 먼저 배경을 설명해야 하고, 새 세션을 열면 그 설명을 처음부터 다시 해야 합니다. 각 앱이 자체 AI 기능을 붙이는 방향은 이 문제를 해결하지 못합니다. 앱마다 자기 안에 있는 데이터만 보기 때문에, 개인이 실제로 일하는 맥락은 여전히 어디에도 모이지 않습니다.

이번에 소개할 MyContext는 그 맥락을 개인 단위로 한곳에 모으는 데스크톱 애플리케이션입니다. 메신저 대화와 문서, 일정, 회의록, 승인 기록, 로컬 활동처럼 흩어져 있는 신호를 받아들여, 내가 아는 것과 함께 일하는 사람, 지금 진행 중인 일을 담은 개인 컨텍스트로 계속 정리합니다. 그 결과물은 애플리케이션 안에만 갇히지 않고 대형 언어 모델과 로컬 에이전트, 사용자가 허가한 외부 AI 앱이 조회해 쓰는 자료가 됩니다. 데이터와 권한의 소유자는 사용자이며, 메시지 전송처럼 결과가 되돌려지지 않는 작업에는 매번 명시적인 승인이 필요합니다.

위 그림은 저장소가 README에 실은 구조도이고, MyContext가 데이터 소스와 AI 사용처 사이에서 개인 컨텍스트를 보관하는 계층으로 놓인다는 점을 보여줍니다. 이 프로젝트는 openTrinity가 공개했고 Electron과 React 기반의 데스크톱 앱으로 만들어져 있으며, 개인 데이터는 디스크의 SQLite 보관소(Vault)에 버전 관리되는 마이그레이션과 함께 저장됩니다. 다만 현재 단계는 개발자 프리뷰(Developer Preview)이고, MyContext는 호환성을 깨는 변경이 있을 것이며 마이그레이션 때문에 수집을 다시 돌려야 할 수 있고 일부 변경은 되돌릴 수 없다고 명시하고 있습니다.

기존 AI 메모리 도구와 MyContext의 차이

에이전트에 기억을 붙이는 프로젝트는 이미 여러 갈래로 나와 있습니다. 무엇을 기억의 단위로 삼는지에 따라 정리하면 다음과 같습니다:

접근	기억의 단위	대표 프로젝트
대화 세션 메모리	에이전트와 주고받은 대화에서 추출한 사실	Supermemory, OpenChronicle
문서 기반 검색	사용자가 넣어 둔 문서 모음	AnythingLLM
근거 보존형 메모리 서버	출처와 모순 관계를 함께 남긴 사실	Dense-Mem
개인 업무 컨텍스트 계층	여러 업무 시스템에서 수집한 한 사람의 업무 기록 전체	MyContext

위 표에서 MyContext 행의 단위가 다른 세 행과 다르다는 점이 눈에 띕니다. 앞의 세 접근은 AI 도구를 쓰는 과정에서 생긴 자료를 기억으로 남기지만, MyContext는 AI와 무관하게 이미 쌓여 있던 업무 기록을 출발점으로 삼습니다. 그래서 MyContext는 소스에 접근하는 일과 컨텍스트를 사용하는 일을 서로 다른 계층으로 갈라 두었습니다. 소스 커넥터가 인증받은 시스템에서 데이터를 가져오고, 증분 수집이 로컬 사본을 갱신하면서 누락된 구간을 메우고, 컨텍스트 처리 계층이 원본 기록을 구조화된 사실과 선호, 관계 정보로 바꿉니다. MyContext는 스스로가 또 하나의 정보 사일로가 되지 않는 것을 목표로 한다고 밝히면서, 개인 업무 데이터를 한 번 연결해 두고 그 컨텍스트를 사용자가 고른 AI 도구에 제공하는 역할을 자기 몫으로 정의합니다.

MyContext의 세 가지 핵심 기능

첫째는 개인 컨텍스트 그래프입니다. 사람과 프로젝트, 주제, 이벤트, 대화, 그리고 이를 뒷받침하는 사실을 연결해 나 자신의 관점에서 관계를 탐색할 수 있게 만듭니다. 여러 소스를 넘나들며 연결을 따라가다가 요약이 아닌 원본 근거로 되돌아갈 수 있다는 점이 이 그래프의 설계 목적입니다.

둘째는 디지털 분신(Persona)입니다. 개인 컨텍스트와 평소의 소통 방식, 상대별 대화 이력을 사용해 일상적인 업무 대화를 처리하도록 돕습니다. 들어온 메시지를 이해하고 관련 배경을 떠올려 사용자의 말투로 답장 초안을 준비하는 데까지가 이 기능의 범위이고, 실제 전송과 그 밖의 결과가 남는 작업은 사용자의 명시적 승인이 있어야 진행됩니다.

셋째는 검색과 답변입니다. 자기 업무 이력을 자연어로 질문하면 로컬 전문 검색과 의미 검색, 그래프 질의를 함께 사용해 결과를 모으고, 에이전트가 출처를 추적할 수 있는 형태로 답을 구성합니다. 여기서 눈여겨볼 동작은 실패 시의 처리입니다. 에이전트 런타임(Agent Runtime)을 쓸 수 없으면 근거 없는 답을 조용히 만들어 내지 않고 순위를 매긴 로컬 검색 결과로 명시적으로 내려앉습니다. 원칙 목록에 적힌 "Evidence before answers"와 "AI is a consumer, not the owner"가 이 동작으로 드러나는 셈입니다.

MyContext의 아홉 개 계층 구조

MyContext는 코드를 서로 독립적인 아홉 개 계층으로 나눠 두었고, 각 계층은 packages/ 아래의 별도 패키지에 대응합니다. 데이터가 위에서 아래로 흐르는 순서로 배치하면 다음과 같습니다:

이 가운데 지식 그래프(Knowledge Graph)는 kl-graph/ 디렉토리의 별도 Python 구성 요소로 분리되어 있어서, kl_cli.py와 kl_server.py를 통해 엔티티와 사실, 관계 추출을 담당합니다. 나머지 계층은 packages/ 아래에 channels, ingest, store, retrieval, persona, agent-runtime 같은 이름으로 들어 있습니다. 계층을 이렇게 쪼개 둔 이유는 원칙 목록에서 읽을 수 있습니다. 소스 경계는 보존하면서 소스 사이의 관련 정보만 연결하고, 되돌릴 수 없거나 외부에 드러나는 작업은 확인을 거치게 하려면 수집과 저장, 사용을 각각 다른 자리에서 통제해야 합니다.

MyContext를 직접 빌드해 실행하기

주의할 점을 먼저 적자면, 현재 저장소에는 미리 빌드된 배포본이 없습니다. GitHub 릴리스가 아직 하나도 올라와 있지 않아서, 써 보려면 소스를 받아 직접 빌드해야 합니다. 요구 버전은 package.json의 engines에 못 박혀 있고 Node는 22.17.0 이상 23 미만, pnpm은 10.13.0 이상입니다. 개발 모드로 실행하는 명령은 다음과 같습니다:

pnpm install
pnpm dev          # 툴체인 검증, 네이티브 모듈 재빌드, 데스크톱 앱 실행
pnpm build        # 타입 검사 후 데스크톱 앱 빌드
pnpm dist:mac:dmg # macOS용 dmg 패키징

한편 패키징 스크립트는 electron-builder --mac 계열만 정의되어 있어서, 지금 시점에 설치 파일을 만들 수 있는 대상은 macOS입니다. 실행에 필요한 설정은 .env.example이 보여 줍니다. 데이터 디렉토리를 개발 중에만 다른 위치로 바꾸는 MYCONTEXT_DATA_DIR, 렌더러 개발 서버 포트인 MYCONTEXT_DEV_PORT(기본값 5273)처럼 개발 편의를 위한 항목이 앞쪽에 있습니다. 포트를 Vite 기본값인 5173으로 두지 않은 이유까지 주석에 적혀 있는데, 여러 Vite 프로젝트를 동시에 돌리면 충돌하기 때문이며 포트가 점유되면 조용히 다른 포트로 옮기지 않고 오류를 냅니다.

다만 여기서 가장 중요한 항목은 모델 설정입니다. MyContext는 OpenAI 호환 모델 게이트웨이를 MYCONTEXT_LLM_BASE_URL과 MYCONTEXT_LLM_API_KEY로 지정받고, 주 모델의 기본값은 glm-5.2, 임베딩 모델의 기본값은 text-embedding-v4입니다. 지식 그래프 색인에는 별도 게이트웨이를 지정하는 항목(MYCONTEXT_KL_LLM_BASE_URL 등)이 따로 열려 있는데, 주 모델을 바꿀 때 중국어 추출이 함께 망가진 이력이 있어 독립 경로를 남겼다고 적혀 있습니다. 정리하면 개인 데이터와 색인은 사용자 장비에 남지만, 모델 호출 자체는 사용자가 지정한 게이트웨이로 나갑니다. 로컬 우선(Local-first)이라는 표현이 데이터 보관 위치를 가리킨다는 점을 도입 전에 확인해야 합니다.

MyContext를 지금 도입할 만한가

판단의 근거는 저장소가 직접 밝힌 세 가지입니다. 데스크톱 핵심 흐름과 로컬 데이터 계층, 검색과 답변, 컨텍스트 그래프, 디지털 분신 작업 흐름이 구현되어 있다는 점, 현재 수집 경로가 확보된 소스는 메신저 대화와 문서, 회의 기록 세 종류라는 점, 그리고 개발자 프리뷰 단계라 호환성을 깨는 변경과 되돌릴 수 없는 마이그레이션이 예고되어 있다는 점입니다.

업무 기록을 AI에 연결하는 구조를 직접 만들어 보려는 개발자, 그리고 개인 컨텍스트 계층을 어떻게 설계하는지 코드로 확인하고 싶은 사람에게는 지금 상태에서도 읽을 값어치가 있습니다. 아홉 개 계층이 패키지 단위로 갈라져 있고 실패 시의 동작까지 원칙으로 정리되어 있어서, 같은 문제를 다루는 프로젝트를 만들 때 참고할 지점이 많습니다. 반대로 매일 쓰는 업무 도구로 삼거나 되살릴 수 없는 기록을 여기에만 보관하려는 경우에는 MyContext가 아직 적절한 선택이 아닙니다. 저장소 스스로 다시 만들어 낼 수 없는 자료의 유일한 보관 장소로 쓰지 말라고 적어 두었고, 설치 파일도 아직 제공되지 않습니다. Windows나 Linux를 쓰면서 바로 실행해 보려는 경우에도 패키징 대상이 macOS뿐이라 준비 과정이 하나 더 필요합니다.

MyContext의 라이선스

MyContext는 Elastic License 2.0으로 공개되어 있습니다. 저장소는 이 라이선스를 소스 사용 가능(Source-available) 라이선스로 소개하면서, 사용과 수정, 회사 내부를 포함한 자체 호스팅은 허용되지만 이 소프트웨어를 제3자에게 호스팅 서비스나 관리형 서비스로 제공하는 것은 허용되지 않는다고 정리해 두었습니다.

단, kl-graph/와 vendor/ 아래의 서드파티 구성 요소는 각자의 라이선스를 따릅니다. 이 프로젝트를 회사 제품에 넣거나 사내에 배포할 계획이라면, 본체 라이선스와 별개로 두 디렉토리의 구성 요소를 먼저 확인해야 합니다.

MyContext 공식 소개 페이지

MyContext 프로젝트 GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

이 도구를 직접 설치해 사용해보셨다면, 파이토치 한국 사용자 모임 회원들을 위해 경험이나 팁을 댓글로 남겨주세요!