Hy-Memory 2.0: Cursor에서 Codex로, 작업의 기억을 이어 쓰는 방법

Cursor에서 버그를 고치다가 Codex로 작업을 옮기면 코드보다 먼저 설명을 옮겨야 할 때가 있다. 어떤 방법을 시도했는지, 왜 되돌렸는지, 아직 확인하지 않은 조건은 무엇인지 새 대화에 다시 적는다. 저장소에는 최종 코드가 남지만, 그 코드를 선택한 이유까지 항상 남는 것은 아니다.

Tencent Hunyuan이 공개한 Hy-Memory 2.0은 이 작업 맥락을 외부 기억으로 저장하고 다시 검색하는 시스템이다. 이를 여러 AI 도구에 연결하는 제품이 MemHub다. 기억을 작성하는 전용 모델 Hy-Memory-30B-A3B도 함께 공개됐다.

“Cursor에서 Codex로 옮겨도 설명할 필요가 없다”는 표현은 조건을 붙여 읽어야 한다. 기록을 가져오고, 처리하고, 다음 도구가 관련 내용을 검색할 수 있도록 연결해야 한다. 검색한 기억이 현재 코드와 맞는지 확인하는 일도 남는다.

2026년 10월 18일 공식 저장소와 모델 카드 확인 기준. 저장소 커밋은 a04fcb50d599다. 설치나 도구 간 전환을 직접 실행한 사용기는 아니며, 공개 문서와 구조를 분석했다.

1. Hy-Memory, MemHub, 전용 모델의 차이

구성	맡는 일
Hy-Memory	기억을 저장·정리·검색하는 엔진과 Python SDK
MemHub	여러 AI 앱의 허가된 기록을 모으고 기억 접근을 관리하는 데스크톱·CLI 제품
Hy-Memory-30B-A3B	어떤 정보를 기억으로 남기고 기존 기억을 어떻게 갱신할지 판단하는 모델

Hy-Memory의 기억은 대화, 일반 작업, 코딩으로 나뉜다. 대화에서는 사용자 정보와 선호 등을 다루고, 일반 작업에서는 수행 사실과 재사용할 경험을 남긴다. 코딩에는 코드 변경 과정까지 붙는다.

엔진을 자신의 앱에 넣으려면 SDK를 사용한다. 기존 AI 도구 사이에서 맥락을 이어 쓰려면 MemHub의 연결 기능을 살펴보는 식으로 목적이 갈린다.

공식 저장소는 Claude Code, Cursor, Codex, OpenCode, Qwen Code 등을 연결 대상으로 소개한다. 다만 MemHub는 현재 프리뷰 단계이며, 앱별 연결 경험과 플랫폼 패키지를 계속 검증 중이라고 명시한다.

근거: 프로젝트 소개, MemHub 안내.

2. Cursor의 기억을 Codex가 읽는 과정

MemHub는 허용된 대화 기록을 로컬 원문인 Evidence로 보관하고, Hy-Memory를 통해 처리한 결과를 관리한다. 다른 AI 도구는 자신에게 허용된 범위에서 관련 기억을 불러온다. 연결에는 도구에 따라 Hook, Skill, 플러그인, MCP 등이 사용된다.

예를 들어 다음은 이 구조로 기대할 수 있는 활용 시나리오다. 실제 실행 결과는 아니다.

Cursor에서 이미지 업로드 오류를 조사한다.
처음 시도한 수정은 실패하고, 저장 경로를 변경한 두 번째 수정이 채택된다.
허가된 기록에서 작업 사실과 해결 경험이 정리된다.
Codex에서 같은 프로젝트를 이어 작업하며 이전 판단을 검색한다.
반환된 기록과 현재 코드·테스트를 대조해 다음 변경을 진행한다.

핵심은 네 번째 단계다. 기록이 저장돼 있어도 다음 도구가 검색하지 않거나 검색 범위가 다르면 활용되지 않는다. 아키텍처 문서에서도 기록 위치에 대한 접근 허가와 동기화 활성화를 구분한다.

이 흐름은 프로젝트 파일 복사나 실행 중인 프로세스의 이동과도 별개다. 기억을 공유하더라도 Codex가 읽을 저장소, 브랜치, 의존성과 실행 환경은 준비되어 있어야 한다.

근거: MemHub 아키텍처.

Claude Code와 Codex 사이에서도 공유할 수 있나

공식 문서가 소개하는 연결 대상에는 Claude Code와 Codex가 모두 포함된다. 따라서 공유 범위가 Cursor에만 한정되지는 않는다. Claude Code에서 쌓은 작업 기억을 Codex가 검색하거나, Codex의 작업 기억을 Claude Code가 검색하는 양방향 활용도 이 구조의 대상이다.

다만 두 도구를 설치하는 것만으로 자동 연결되는 것은 아니다.

필요한 설정	의미
같은 MemHub 런타임과 기억 저장소에 연결	두 도구가 공통으로 참조할 기억 기반을 마련한다
기록 출처에 접근 허가하고 동기화 활성화	각 도구에서 생긴 기록이 기억 처리 대상으로 들어오게 한다
읽는 도구에 적절한 검색 권한 부여	다른 도구에서 유래한 기억도 허용 범위 안에서 찾게 한다
실제 작업에서 기억 검색 사용	저장된 내용을 현재 요청의 맥락으로 가져온다

예를 들어 Claude Code에서 “첫 번째 수정안은 테스트에 실패해 되돌렸다”는 기록을 남겼다면, Codex가 관련 기억을 찾아 같은 접근을 반복하지 않도록 참고할 수 있다. 반대 방향도 같은 원리다. 이는 가능한 활용 예시이며, 이 글에서 양방향 연동을 직접 검증한 결과는 아니다.

공유되는 것은 검색 가능한 작업 맥락이다. 대화 세션 전체, 모델 내부 상태, 실행 중인 프로세스가 그대로 이동하는 기능으로 이해하면 안 된다. 저장소와 브랜치, 의존성, 실행 환경은 새 도구에서도 확인해야 한다.

여기서 Claude는 공식 문서에 연결 대상으로 명시된 Claude Code를 뜻한다. 일반 Claude 웹·모바일 채팅까지 자동으로 공유된다는 의미는 아니다. MemHub는 프리뷰 단계이므로 사용 중인 버전의 앱별 연결 기능과 실제 검색 결과를 확인해야 한다.

근거: MemHub 연결 대상과 프리뷰 안내, 공유 런타임과 접근 구조.

3. 작업 사실과 경험을 따로 저장하는 이유

개발 기록에는 서로 다른 종류의 정보가 섞여 있다.

종류	이미지 업로드 문제를 예로 든 기록
작업 사실	업로드 응답의 이미지 경로를 수정했다
재사용할 경험	저장 성공과 공개 URL 접근 성공을 각각 확인해야 한다
코드 변경 과정	첫 수정의 diff, 이후 되돌린 변경, 최종 수정

위 표는 설명을 위한 예시다.

작업 사실은 특정 세션에서 무슨 일이 있었는지 설명한다. 경험은 비슷한 문제에서 다시 참고할 방법이다. 코딩 기억에는 버전 변화가 추가되어, 요약에서 빠지기 쉬운 수정 과정을 보완한다.

공식 문서에 따르면 코딩 경로는 도구 호출이나 도구 결과가 포함된 기록을 필요로 한다. scene="coding"을 지정해도 그런 기록이 없으면 대화 경로로 돌아간다. 코드 변경 체인 역시 수집 가능한 Git diff나 도구 기록이 있어야 한다. 대화 한 줄을 넣었다고 과거 수정 전체가 복원되는 것은 아니다.

검색 결과에는 facts, experiences와 함께 코딩 변경 맥락인 chain_block이 올 수 있다. 변경 체인이 비어 있다고 해서 사실·경험 저장까지 실패했다는 뜻은 아니다.

이 차이는 도입 테스트에서도 중요하다. “기억이 검색된다”와 “되돌린 코드의 변경 과정까지 검색된다”를 별도로 확인해야 한다.

근거: Working·Coding 사용 문서.

4. Hy-Memory-30B-A3B는 무엇을 학습했나

이 모델은 장기 기억의 쓰기 작업에 맞춰 학습됐다. 남길 정보, 표현의 정확도, 새로운 증거에 따른 기억 갱신을 다룬다. 이름의 30B는 전체 파라미터 규모, A3B는 약 3B의 활성 파라미터를 가리키는 MoE 구성이다.

모델 카드에서는 교사의 출력을 이용한 학습 뒤에 기억 작성 결과를 평가하는 강화학습을 적용했다고 설명한다. 활성 파라미터가 3B라는 이유만으로 일반 3B 모델과 같은 메모리에서 실행된다고 볼 수는 없다.

Tencent의 자체 평가에서 네 기억 프레임워크 평균은 Hy-Memory-30B-A3B 55.49, Claude Opus 5 54.62로 제시된다. 이 결과는 다음 조건을 함께 봐야 한다.

기억을 쓰는 모델을 바꾸고 검색·답변 등 다른 구성은 고정했다.
주 평가에는 각 벤치마크의 고정된 20% 부분집합을 사용했다.
평균이 높아도 모든 세부 항목에서 우세하지는 않았다.

따라서 이 표를 일반 코딩 능력이나 전체 모델 성능의 순위로 읽으면 안 된다. 한국어 개발 기록에서도 같은 차이가 나는지는 별도로 확인할 문제다.

근거: 공식 모델 카드.

5. 로컬 저장이어도 외부 모델로 전송될 수 있다

MemHub는 원문을 로컬 데이터 디렉터리에 보관한다. 그러나 사용자가 외부 모델 서비스를 선택하면 허가된 내용 중 처리에 필요한 부분이 해당 서비스로 전송된다. 저장 위치와 처리 위치를 따로 확인해야 한다.

개인정보 문서는 원문 읽기, 모델 처리, 연결된 AI 도구의 읽기를 각각의 권한 경계로 설명한다. 반면 내부 SDK 처리 설정을 모두 별도 버튼으로 켜고 끄는 구조라고 단정할 수는 없다. 실제 UI와 해당 버전의 동기화 설정을 확인해야 한다.

문서에는 화면 캡처, 키보드·마우스, 클립보드, 백그라운드 녹음 등을 수집하는 제품이 아니라고 적혀 있다. 진단 로그도 기본적으로 민감 내용을 제외하도록 설계되어 있다.

다만 debug 모드에서는 모델 프롬프트와 응답이 로컬 로그에 기록될 수 있다. 대화 본문이 포함될 수 있으므로 오류 제보 전에 확인해야 한다. 프로그램 제거가 기억 삭제를 의미하지 않는다는 점도 명시되어 있다.

근거: 개인정보 처리 문서, 동기화 구조.

6. 사용 목적에 따라 시작점이 다르다

기존 AI 도구를 연결하려면 MemHub

확인한 설치 문서의 배포 목표는 Linux와 macOS이며 Windows는 현재 지원하지 않는다. 실제 지원 여부는 해당 릴리스의 파일과 release-manifest.json에 들어 있는 플랫폼을 기준으로 판단해야 한다.

문서가 안내하는 CLI 경로는 다음과 같다.

npm install -g memhub-cli
memhub install
memhub init
memhub status

이 경로에는 npm 패키지와 같은 버전의 GitHub Release가 공개되어 있어야 한다는 전제가 붙는다. 이 글에서는 배포 파일의 실제 설치를 검증하지 않았다. 먼저 Releases에서 자신의 플랫폼에 맞는 파일을 확인해야 한다.

npm 설치는 작은 설치 도구를 받는 단계다. 실제 런타임은 memhub install에서 내려받고 검증한다. 설치가 끝나면 기록 출처와 동기화 범위, 사용할 모델, 기억을 읽을 앱의 권한을 설정하고 작은 기록부터 확인하는 순서가 적절하다.

근거: 설치·배포 문서.

자신의 앱에 기억을 붙이려면 Python SDK

공식 문서의 기본 설치 버전은 다음과 같다.

pip install hy-memory==2.0.3

LLM과 임베딩 서비스를 설정한 뒤 HyMemoryClient의 add()와 search()를 사용한다. 아래는 사용자 선호를 저장하고 찾는 최소 예시다. 한국어 검색 품질을 측정한 테스트 코드는 아니다.

from hy_memory import HyMemoryClient

with HyMemoryClient(mode="pro") as memory:
    memory.add(
        "사용자는 개발 설명에 짧은 Python 예제를 선호한다.",
        user_id="demo-user",
        source="demo-app",
    )

    result = memory.search(
        "개발 설명을 어떤 형식으로 제공하면 좋을까?",
        user_ids=["demo-user"],
        include_sources=["demo-app"],
        limit=3,
    )

    print(result["memories"])

이 코드 앞에는 모델과 임베딩의 엔드포인트·키 설정이 필요하다. SDK는 OpenAI 호환 인터페이스를 지원하므로 전용 30B 모델을 반드시 설치해야 하는 것은 아니다.

lite는 원문 중심 벡터 검색, pro는 모델을 이용한 추출·정리를 제공한다. 코딩 기억을 확인하려면 pro 또는 ultra에서 실제 도구 기록을 제공해야 한다. 임베딩 API를 사용한다면 lite도 비용이 전혀 없다는 뜻은 아니다.

근거: SDK 사용 가이드.

7. 도입 여부는 ‘기억량’보다 복구 정확도로 판단한다

개발 도구를 자주 바꾸는 사람에게는 같은 배경을 반복 입력하는 부담을 줄일 여지가 있다. 반대로 잘못 정리된 경험이 다음 작업에 반복해서 들어오면 수정 비용이 커질 수도 있다.

처음에는 작은 저장소 하나에서 다음 세 가지를 비교해 볼 수 있다.

확인할 질문	판단할 내용
왜 첫 수정안을 버렸는가?	실패한 접근과 채택한 접근을 구분하는가
지금 적용된 수정은 무엇인가?	과거 기억과 현재 코드 상태를 혼동하지 않는가
다른 프로젝트에서도 써도 되는 방법인가?	특정 환경의 해결책을 일반 규칙으로 과장하지 않는가

여기에 출처를 제한했을 때 다른 앱의 기록이 섞이는지, 동기화를 끈 뒤 새 기록이 들어오는지까지 확인하면 실제 사용 조건을 판단할 수 있다.

Hy-Memory에서 먼저 시험해 보고 싶은 장면은 “이 코드를 왜 이렇게 바꿨지?”라는 질문이다. 다른 도구에서도 당시의 시도와 근거를 찾고 현재 코드와 대조할 수 있다면, 작업을 넘길 때 다시 설명해야 하는 내용이 구체적으로 줄어든다.

원본: Tencent-Hunyuan/Hy-Memory · Hy-Memory-30B-A3B 모델

코드 저장소와 모델 카드에는 Apache-2.0 라이선스가 표시되어 있다. 함께 사용하는 외부 모델 서비스와 구성요소의 조건은 별도로 적용된다.