
AI와 여러 번 주고받는 대화를 하다 보면, 앞에서 분명히 말해 둔 내용을 AI가 붙들지 못하는 순간이 옵니다.
문제는 거기서 끝나지 않습니다. 기억이 비었다고 말하는 대신, 빈자리를 그럴듯한 내용으로 채워서 대답합니다.
저는 이 둘을 따로 떨어진 문제로 보지 않았습니다. 제대로 기억하지 못한 상태 위에서 추론을 하니까 없는 얘기가 나온다고 봤습니다.
그래서 특허를 하나 출원했습니다. 대화 기억을 관리하는 일과 없는 얘기를 걸러내는 일을 한 줄기로 묶은 설계입니다.
2026년 3월에 출원해 7월에 공개됐고, 아직 등록 전입니다.
오늘은 그 설계가 어떻게 생겼는지 쉬운 말로 적어 두려 합니다.
기억을 관리하는 기술과 환각을 막는 기술은 따로 자랐습니다
용어를 하나 풀어 두겠습니다. 환각은 AI가 사실이 아닌 내용을 사실인 양 말하는 현상을 가리킵니다.
이 글에서 다루는 것은 그중 대화 기억에서 비롯된 환각입니다.
AI가 대화를 오래 이어가지 못하는 이유는 한 번에 볼 수 있는 글의 양에 한계가 있기 때문입니다. 그래서 앞부분의 대화는 시야 밖으로 밀려납니다.
이 한계를 풀려고 대화 내용을 바깥 저장소에 담아 두는 기술이 발전해 왔습니다. 널리 쓰이는 오픈소스 메모리 시스템들이 그 계열입니다.
한편 환각을 줄이려는 기술은 별도의 줄기로 자랐습니다. 모델이 자기 답에 대해 검증 질문을 스스로 만들어 되짚어 보는 방식이나, 미리 준비된 문서를 참조해 사실을 맞춰 보는 방식이 여기 속합니다.
두 줄기는 각자 잘 자랐는데, 제가 출원을 준비하며 살펴본 범위에서는 서로 이어지지 않았습니다. 기억을 쌓는 쪽은 쌓아 둔 기억이 정확한지를 따로 검증하지 않았고, 환각을 막는 쪽은 그 대화에서 실제로 오간 말을 검증의 기준으로 삼지 않았습니다.
제가 명세서에 적은 문제의식이 이 지점입니다. 저장에서 검증까지를 하나의 처리 흐름으로 잇는 기술이 비어 있었습니다.
그래서 다섯 단계로 나눴습니다
| 단계 | 하는 일 |
|---|---|
| 1. 가르기 | 사용자가 방금 한 말이 묻는 말인지 알려주는 말인지 판별하고, 그 말의 주제를 뽑습니다 |
| 2. 꼬리표 | 기억을 저장할 때, 그 말을 누가 했는지와 무슨 주제인지를 함께 붙입니다 |
| 3. 생애주기 | 기억을 만들고, 고치고, 지우고, 되살리는 네 가지 상태로 관리합니다 |
| 4. 쪼개서 찾기 | 질문을 갈래별로 나눠 각각 따로 찾은 뒤, 결과를 비율대로 합칩니다 |
| 5. 대조 | 답을 내보내기 전에 원래 기억과 다시 맞춰 봅니다 |
첫째, 묻는 말과 알려주는 말을 먼저 가릅니다.
같은 사람이 한 말이라도 "내 이메일 주소가 바뀌었어"와 "내 이메일 주소 뭐였지"는 시스템이 해야 할 일이 정반대입니다. 앞의 말은 저장해야 하고, 뒤의 말은 찾아와야 합니다.
그래서 이 출원은 대화가 한 차례 오갈 때마다 사용자의 말을 두 갈래로 먼저 나누고, 나뉜 결과를 뒤 단계가 이어받습니다. 이때 그 말의 주제도 함께 뽑아 둡니다. 뽑아 둔 주제는 다음 단계에서 꼬리표로 쓰입니다.
둘째, 저장할 때 누가 한 말인지를 함께 답니다.
내용만 담지 않고, 그 내용이 누구 입에서 나왔는지를 표식으로 붙입니다. 사용자가 한 말인지, AI가 스스로 만들어 낸 말인지를 구분하는 표식입니다.
이 표식이 있어야 나중에 "사용자님께서 A라고 하셨습니다"라는 답이 나왔을 때, 정말 사용자가 한 말인지 확인할 수 있습니다. 표식이 없으면 AI가 한 번 지어낸 말이 기억 속에서 사실과 같은 무게를 얻게 됩니다. 한 번 그렇게 굳으면 다음 대화에서는 그게 전제가 됩니다.
셋째, 기억에도 생애주기를 둡니다.
기억은 한 번 적고 끝나지 않습니다. 사용자가 이사했다고 하면 예전 주소 기억은 고쳐져야 하고, 앞서 한 말을 거둬들이면 지워져야 하고, 나중에 다시 언급되면 되살아나야 합니다.
이 출원은 그 네 가지를 상태로 정의하고, 상태가 바뀔 때마다 바뀌기 직전의 내용을 사본으로 남깁니다. 그리고 바뀐 정도가 정해 둔 기준선을 넘으면, 그 기억에 기대어 이미 내보냈던 답까지 다시 검토하도록 신호를 보냅니다.
변화가 사소하면 그냥 넘어갑니다. 모든 변경마다 지난 답을 되돌아보면 계산이 너무 무거워지기 때문입니다.
넷째, 질문을 쪼개서 갈래별로 찾습니다.
"지난번에 말한 그 식당 이름이랑 예약 가능한 시간 알려줘" 같은 질문은 사실 두 개의 질문입니다. 이걸 한 덩어리로 던지면 검색 결과가 한쪽 주제로 쏠립니다.
그래서 질문을 갈래로 나눠 각각 따로 찾습니다. 찾는 방식은 글자가 같은 것을 고르는 게 아니라 뜻이 가까운 기억을 골라 오는 방식입니다. 그리고 갈래마다 나온 결과의 개수에 비례해 가중치를 매기고, 그 가중치대로 점수를 합쳐 최종 순위를 냅니다.
다섯째, 답을 내보내기 전에 원본과 대조합니다.
마지막 단계는 관문입니다. AI가 만든 답에서 과거 대화를 인용한 부분을 골라내고, 저장소의 원본 기억과 맞춰 봅니다. 이때 내용만 보지 않고 둘째 단계에서 붙인 꼬리표까지 함께 봅니다.
명세서에는 판정을 셋으로 나눈 예를 들어 두었습니다. 내용과 꼬리표가 모두 맞으면 그대로 두고, 세부만 어긋나면 원본대로 바로잡고, 대응하는 기억이 아예 없거나 누가 한 말인지가 어긋나면 그 부분을 빼거나 다시 만들게 합니다.
다시 만들기를 요청하는 횟수에는 상한을 둘 수 있게 해 두었습니다. 무한정 되풀이하지 않기 위해서입니다.
명세서에서는 이렇게 걸러지는 대화 기억 환각을 네 가지로 나눠 두었습니다.
| 유형 | 어떤 상황인가 |
|---|---|
| 허위 인용 | 존재하지 않는 대화를 인용함 |
| 왜곡 인용 | 실제 오간 내용을 변형해 인용함 |
| 갱신 실패 | 이미 고쳐진 기억의 옛 버전을 인용함 |
| 과잉 추론 | 기억에 없는 내용을 추론해 놓고 기억인 양 제시함 |
명세서에는 이 다섯 단계를 외부로 보내지 않고 사용자 쪽 기기 안에서 그대로 돌리는 구성도 함께 적어 두었습니다. 여기서 기기는 스마트폰이나 태블릿뿐 아니라 임베디드 보드, 네트워크가 제한된 로컬 서버까지 포함합니다. 대화가 바깥으로 나가지 않는 환경을 염두에 둔 구성입니다.
기존 방식과 다른 지점 두 가지
먼저 밝혀 둘 것이 있습니다. 어느 쪽이 더 낫다는 이야기가 아니라, 목적이 다른 설계라는 뜻입니다.
하나, 누구 말인지를 저장 단계에서 구분합니다.
널리 쓰이는 오픈소스 메모리 시스템(Mem0)은 대화에서 정보를 뽑아 넣고 고치고 지우는 데 초점이 있습니다. 발화의 역할을 구분하는 기능 자체는 다룹니다. 다만 각 기억 항목의 출처를, 뒤에서 답을 검증할 때 쓸 근거로 계속 추적하지는 않습니다.
이 판단은 2026년 3월 출원 당시 제가 명세서 배경기술에 적어 둔 것이고, 그 뒤로 각 프로젝트의 기능은 계속 바뀌고 있습니다.
이 출원은 저장하는 그 순간에 꼬리표를 답니다. 뒤에서 대조하려면 앞에서 표식이 있어야 하기 때문입니다.
둘, 검증의 기준을 그 대화 자체에 둡니다.
환각을 줄이는 기법 가운데는 모델이 검증 질문을 스스로 만들어 자기 답을 되짚는 방식(Chain-of-Verification)이 있고, 미리 마련해 둔 문서와 맞춰 보는 방식도 있습니다. 제가 확인한 범위에서 이 계열의 기법들은 "이 대화에서 실제로 오간 말"을 대조의 기준으로 삼지는 않습니다.
이것 역시 2026년 3월 출원 당시 제가 명세서 배경기술에 종래 기술로 적어 둔 내용입니다.
이 출원은 저장해 둔 원본 기억을 기준으로 삼습니다. 어느 쪽이 낫다는 이야기가 아니라 목적이 다른 설계입니다.
제가 이 설계를 택한 이유
여기가 이 글에서 가장 개인적인 대목입니다.
출원 계기는 거창하지 않습니다. 제가 AI와 일하면서 계속 겪던 일이 그대로 출발점이었습니다.
지금도 AI는 제가 얘기한 것들을 기억하지 못합니다. 그래서 만들게 됐습니다.
했던 얘기를 제대로 기억하지 못하고, 그걸 토대로 없는 얘기를 지어내고 있었으니까요.
이 두 문장이 설계의 전부입니다.
이 글을 준비하는 동안에도 같은 일이 있었습니다. 전날 AI와 이야기하며 다른 글의 소재를 정리해 뒀는데, 다음 날 이어서 작업하려니 AI가 그 대화를 기억하지 못했습니다. 남아 있는 것은 그때 적어 둔 기록뿐이었습니다.
AI는 그 기록만 보고, 글 안의 몇 대목을 제가 하지 않은 말이라고 판정해 지우려 했습니다. 제가 그거 나랑 얘기하면서 작성한 건데, 하고 짚고 나서야 확인이 됐습니다.
실제로 제가 겪고 말한 내용이었고, 기록에만 남지 않았을 뿐입니다. 그대로 뒀으면 사실인 서술 네 대목이 지워질 뻔했습니다.
기록이 있었는데도, 그 기록에 없는 것은 없던 일이 됐습니다.
그래서 기억 관리와 환각 방지를 따로 두지 않았습니다. 순서를 붙여 하나로 이었습니다. 앞 단계에서 무엇을 어떻게 저장했느냐가, 마지막 단계에서 무엇을 대조할 수 있느냐를 결정하기 때문입니다.
꼬리표를 붙이는 둘째 단계가 없으면, 맞춰 볼 기준이 없어 다섯째 단계의 대조가 헐거워집니다. 반대로 대조하는 단계가 없으면, 잘 정리해 둔 기억이 답에 제대로 반영됐는지 아무도 확인하지 않습니다.
제가 겪은 것은 기억이 새는 문제였고, 동시에 없는 말을 지어내는 문제였습니다. 저는 이걸 원인 하나에서 나온 증상 둘로 봤습니다. 그래서 처방도 한 벌이어야 한다고 판단했습니다.
지금 어디까지 왔는지도 적어 두겠습니다
솔직하게 쓰겠습니다.
위의 다섯 단계는 로지컬랩스 백엔드에 실제로 구현돼 있고, 동작을 확인하는 테스트도 붙어 있습니다. 여기까지는 왔습니다.
다만 아직 사용자가 쓰는 서비스 경로에는 연결하지 않았습니다. 운영에 붙이는 일은 다음 과제로 남아 있습니다.
명세서에 적어 둔 효과를 정량으로 검증하는 실험은 아직 진행 전입니다. 그래서 이 글에도 숫자는 한 개도 넣지 않았습니다. 숫자를 말할 수 있게 되면 그때 다시 적겠습니다.
설계를 마치고 분명해진 것 하나만 남겨 둡니다. 무엇을 어떻게 저장해 두느냐가, 나중에 무엇을 검증할 수 있는지를 미리 정해 버린다는 점입니다.
덧붙임. 이 글에서 언급한 외부 프로젝트와 기법에 관한 서술은, 2026년 3월 출원 당시 명세서 배경기술에 적어 둔 내용과 그때 확인한 공개 자료를 기준으로 한 것입니다. 각 프로젝트의 기능은 그 뒤로 계속 바뀌고 있습니다. 어느 쪽이 더 낫다는 이야기가 아니라, 목적이 다른 설계라는 뜻으로 적었습니다. 이 글에서 다룬 발명은 2026년 3월에 출원해 7월에 공개된 것으로, 이 글을 쓰는 시점에 아직 등록 전입니다.
'특허 노트' 카테고리의 다른 글
| 하네스 성능 13.7p, 흔히 뭉뚱그리는 두 숫자를 해부했습니다 (0) | 2026.07.28 |
|---|---|
| 변리사 실무수습, 시험 합격 뒤에 남은 250시간과 6개월 (0) | 2026.07.17 |
| 특허청 AI 발명 설문조사: 전문가 66%가 'AI는 도구'라고 답한 이유 (0) | 2026.07.17 |
| 변리사 비밀유지권과 변호사 ACP, 동시에 밀려오는 두 제도가 변리사의 AI 사용을 바꾼다 (0) | 2026.07.16 |
| 메타하네스란 무엇인가: AI 에이전트도 OS처럼 계층이 있습니다 (0) | 2026.07.16 |