코딩 에이전트가 수정을 마친 뒤 “성공했습니다”라는 기록만 남기면, 나중에 취소한 변경의 내용도 기억할 수 있을까요? Hy Memory 2.0.2의 coding 경로에서는 작업 사실을 저장하는 것과 코드 변경 체인을 만드는 것이 별개입니다. 변경 전후를 다시 참고하려는 작은 팀이라면, 메모리 저장 성공 여부보다 먼저 도구 실행 기록에 실제 diff가 들어가는지 확인해야 합니다. 이번 글은 같은 수정 작업을 네 가지 입력으로 바꿔 보며 그 차이를 설명합니다.
확인: 2026년 10월 17일 UTC · 대상: Python SDK hy-memory==2.0.2 · 검증: 공식 문서, 공개 소스, 배포 wheel 파일의 정적 비교. 설치·SDK 실행·모델 호출은 하지 않았습니다. 아래 입력과 예상 경로는 가상 사례이며 실행 결과가 아닙니다. 공개 자료 조사와 AI의 도움으로 작성했습니다.
새로 공개된 저장소와 SDK 버전을 구분하기
Tencent Hunyuan의 Hy-Memory는 대화와 작업 기록을 다음 요청에서 사용할 기억으로 정리하는 프로젝트입니다. Python SDK는 chat, working, coding 경로를 제공합니다. coding은 작업 사실과 재사용할 경험에 더해, 해당 코드가 어떻게 바뀌었는지 보여 주는 변경 체인을 붙입니다. 함께 있는 MemHub 앱과 별도로 공개된 메모리 작성 모델은 이 글의 검토 대상이 아닙니다.
프로젝트 전체가 처음 나온 것은 아닙니다. SDK 1.0.0은 2026년 5월 21일에 배포됐고, 현재 공개 저장소는 10월 15일에 생성됐습니다. SDK 2.0.2의 wheel 업로드 시각은 10월 16일 16:01 UTC입니다. 저장소의 v1.0.2 릴리스는 MemHub 쪽 버전이므로 SDK 버전과 섞으면 안 됩니다.
10월 17일 06:29 UTC에 GitHub 공개 API로 확인한 누적 별은 439개였습니다. 10월 16일의 Windows 배포 요청, 17일의 Docker 배포 요청도 있습니다. 초기 관심의 흔적이며, 최근 별 증가폭은 확인하지 못했습니다. 이 수치와 요청을 품질이나 실제 도입 규모의 증거로 보지는 않습니다.
“무슨 일을 했나”와 “무엇을 바꿨나”는 다릅니다
가상 서비스의 src/worker.py에서 batch_size = 20을 40으로 바꿨다가, 다음 작업에서 20으로 되돌렸다고 가정하겠습니다. 최종 파일만 보면 중간의 40은 남지 않습니다. “배치 크기를 조정했다”는 요약도 변경 전후의 값을 항상 보존하지는 않습니다.
Hy Memory의 coding 체인은 이런 작업 기록에 diff를 붙이는 용도입니다. 다만 공식 coding 문서에서도 체인은 best-effort로 설명합니다. 체인 기록에 실패해도 사실·경험 저장을 중단하지 않습니다. 따라서 전체 저장이 성공했다는 응답만으로 “중간 변경도 남았다”고 판단할 수 없습니다.
같은 수정, 네 가지 기록
다음 비교는 mode="pro", 명시적인 scene="coding", 동일한 사용자·workspace·branch, 정상적인 체인 저장소를 가정합니다. 사실·경험 작성 단계가 완료된 뒤 체인 입력이 어떻게 처리되는지만 추적했습니다.
| 남긴 기록 | 2.0.2 소스에서 따라간 경로 | 연동할 때의 판단 |
|---|---|---|
| 도구 결과에 성공 문장만 있음 | 체인이 읽는 텍스트에 diff나 인식 가능한 교체 내용이 없어 변경을 기록하지 못함 | 작업 사실 저장과 변경 보존을 따로 확인합니다 |
| 변경 전후가 tool-call arguments에만 있고 결과는 성공 문장 | 인수는 메시지 객체에 남지만 체인용 텍스트를 만들 때 포함되지 않음 | 인수를 전달했다는 이유만으로 체인까지 전달됐다고 보지 않습니다 |
| 성공 문장과 저장소 경로 설정만 있음 | 공개 add 경로가 체인에 commit이나 조회 키를 넘기지 않아 Git 조회 조건을 충족하지 못함 | 저장소 경로만으로 자동 수집된다고 가정하지 않습니다 |
| 도구 결과 content에 실제 unified diff가 있음 | 텍스트의 diff를 먼저 찾아 변경 구간을 처리함 | 성공한 편집의 diff가 이 경로로 들어가는지 확인할 수 있습니다 |
이 차이는 메시지 정규화와 체인용 텍스트 변환을 구분하면 드러납니다. 전자는 tool-call arguments를 별도 필드에 보관하지만, 후자는 각 메시지의 content를 연결합니다. 인수가 모든 메모리 경로에서 사라진다는 뜻은 아닙니다. 이 글이 확인한 범위는 diff 체인으로 들어가는 텍스트입니다.
그다음 patch 선택 코드는 텍스트 안의 diff, Git 조회, 인식 가능한 교체 텍스트 순으로 살핍니다. Git 조회에는 commit 또는 key 계열 메타데이터가 필요합니다. 공개 add의 연결 코드는 branch만 전달하므로, 이 경로에서 MEMORY_CODING_CHAIN_REPO_ROOT만 설정하는 것으로는 충분하지 않습니다. 이 판단을 MemHub나 내부 체인 클래스를 직접 호출하는 다른 연동에 확대하지는 않습니다.
도구 결과에 어떤 근거를 남길지 결정하기
앞의 가상 수정에서 체인에 필요한 근거는 다음과 같은 diff입니다. 이는 한 번의 편집에 해당하는 입력 모양을 설명하려고 작성한 미실행 예시입니다. 실제 연동에서는 도구가 성공적으로 적용한 변경에서 얻은 내용을 사용해야 합니다.
diff --git a/src/worker.py b/src/worker.py
--- a/src/worker.py
+++ b/src/worker.py
@@ -1 +1 @@
-batch_size = 20
+batch_size = 40이 텍스트를 OpenAI 형식 메시지의 role="tool"인 결과 메시지 content에 포함하는 방식이 위 표의 마지막 행입니다. 다음 작업에서 되돌렸다면 그 작업의 설명과 반대 방향 diff를 별도 기록으로 남깁니다. 모델이 제안한 패치를 실행 결과처럼 저장하거나, 마지막 파일에서 중간 변경을 추측해 만들어 넣으면 안 됩니다. 원본 실행 기록과 패치는 메모리 요약과 별도로 보관하는 편이 좋습니다.
여기서 기대할 수 있는 것은 체인이 해석할 입력을 제공하는 일입니다. 문서의 반환 구조에 따르면 chain_rounds는 처리한 diff hunk, 즉 변경 구간 수입니다. 사용자 작업 수나 고유 버전 수가 아닙니다. 0은 인식한 변경이 없다는 뜻일 수 있으며, 전체 메모리 저장 실패를 뜻하지 않습니다. 반대로 양수도 수정의 실행 성공이나 코드의 정확성을 검증하는 값은 아닙니다.
검색도 별도입니다. 저장된 체인은 검색으로 선택된 fact에 붙고, chain_block이 비어 있을 수 있습니다. 원본 패치 저장, fact 검색, 체인 표시를 각각 확인해야 합니다. 체인이 모든 버전을 완전하게 복원하거나 다음 에이전트가 올바른 버전을 선택한다고 보장하지는 않습니다.
작은 팀에서 먼저 도입할 조건
여러 작업에 걸쳐 코딩 에이전트를 쓰고, 한 번 시도했다가 버린 변경의 이유와 내용을 다음 작업에서도 참고해야 한다면 검토할 가치가 있습니다. 첫 연결에서는 합성 저장소 하나로 성공 문장만 있는 기록과 실제 diff가 있는 기록을 나란히 넣고, 사실 저장과 체인 기록이 구분되는지 확인하는 편이 좋습니다. 이 글에서는 그 SDK 실험을 수행하지 않았습니다.
현재 코드와 커밋 이력만 필요한 팀이라면 Git과 짧은 작업 기록으로도 목적을 달성할 수 있습니다. 미커밋 중간 변경까지 필요하다면 먼저 해당 변경을 보존하는 절차를 마련해야 합니다. 메모리 시스템은 이미 사라진 근거를 만들어 주는 대체재가 아닙니다.
시작 조건도 가볍지만은 않습니다. 2.0.2 패키지는 Python 3.9 이상을 선언하고 ChromaDB와 Kuzu 등을 기본 의존성에 포함합니다. 공개 CI 설정의 SDK 작업은 Ubuntu와 Python 3.12를 사용합니다. 이는 설정을 읽은 사실이며, 모든 Python·운영체제 조합을 검증했다는 뜻은 아닙니다.
coding 경로에는 pro 또는 ultra와 도구 실행 기록이 필요합니다. lite는 scene을 무시하고 원문을 벡터화합니다. 공식 시작 안내는 OpenAI 호환 LLM과 임베딩 endpoint를 설정하는 방식입니다. 전용 30B 모델을 반드시 내려받는 절차는 아닙니다. 체인 코드 자체가 모델을 부르지 않아도 앞선 pro 처리에는 모델·임베딩 사용이 있으므로, 선택한 공급자의 요금과 데이터 처리 조건을 확인해야 합니다. 도구 결과에 넣은 코드가 그 처리 입력에도 들어갈 수 있습니다. 실제 서비스 코드 대신 합성 예제로 먼저 확인할 이유입니다.
SDK 2.0.2의 배포 메타데이터와 공개 소스 라이선스는 Apache-2.0입니다. 재배포 시 라이선스·고지 등 해당 조건을 지켜야 하고, 의존성이나 이용하는 모델 서비스의 조건은 별도로 확인해야 합니다.
이번 검토의 결론
Hy Memory를 coding 기억에 연결할 때는 “add가 성공했나”와 “diff가 체인에 들어갔나”를 분리해서 보십시오. 2.0.2에서 성공 문장, tool-call 인수, 저장소 경로 설정, 결과 content의 diff는 같은 입력이 아닙니다. 버린 변경까지 다음 작업에 전달하려는 팀에는 이 입력 계약이 메모리 기능 목록보다 먼저 확인할 항목입니다.
소스 범위: f79770c 커밋. 검토한 client.py, coding/chain_store.py, coding/store.py는 PyPI 2.0.2 wheel의 해당 파일과 바이트 단위로 일치했습니다. wheel의 SHA-256도 레지스트리 기록과 대조했습니다. 관련 upstream 테스트는 읽기만 했으며 실행하지 않았습니다.
댓글
댓글 쓰기