AI 기억에서 계획과 완료를 가르는 선

예정된 날짜가 지났다는 이유만으로 AI가 일을 완료로 기억해서는 안 된다. Graphiti의 시간 처리 코드를 바탕으로 계획의 성립 시점, 목표일, 상태 종료일과 실제 결과를 구분하는 업무 기록 방법을 살핀다.

표지는 계획된 구조와 실제로 완성된 구조의 차이를 표현한 AI 생성 개념 이미지다.

월요일 회의록에 “금요일까지 고객 안내 페이지를 공개하겠다”는 말이 남았다. 다음 주 월요일, AI에게 진행 상황을 물었더니 “지난 금요일 공개됐다”고 답한다. 공개 완료 보고는 없었다. 시스템은 약속을 잘 찾아냈지만, 시간이 지났다는 이유로 문장의 상태까지 바꿔 버렸다.

이 글의 회의와 일정은 설명을 위한 가상 사례다. 다만 여기서 드러나는 설계 문제는 분명하다. 업무 기록에는 이미 일어난 사건, 현재 유지되는 상태, 앞으로 하겠다는 약속이 함께 들어온다. 날짜를 정확히 추출해도 이 셋을 같은 종류의 사실로 저장하면 잘못된 보고가 만들어질 수 있다. 검색된 문장에 달력을 붙이는 것만으로는 해결되지 않는다.

AI가 “무엇을 기억하는가”를 따질 때는 문장의 동사도 남겨야 한다. 공개할 예정이라는 사실과 공개했다는 사실은 서로 다른 근거를 요구한다. 이 차이를 시간 기반 지식 그래프의 구현과 팀의 업무 기록에 연결해 보자.

약속은 언제부터 사실인가

“월요일에 금요일 공개를 약속했다”는 문장에는 두 시간이 들어 있다. 약속이 성립한 때는 월요일이고, 약속이 가리키는 예정일은 금요일이다. 월요일부터 참인 것은 ‘그런 계획이 있다’는 주장이다. ‘페이지가 공개돼 있다’는 상태는 아직 확인되지 않았다.

시간 기반 지식 그래프를 만드는 공개 프레임워크 Graphiti는 이 구분을 코드에 드러낸다. 2026년 10월 18일 확인한 기본 브랜치 main의 EntityEdge 정의는 미래의 계획·약속에 대해 valid_at을 미래 발생일이 아닌 원문 에피소드의 기준 시각에 두도록 설명한다. 에피소드는 그래프에 들어온 메시지나 문서 같은 입력 단위다. 이 필드는 문장에 담긴 주장이 언제 성립했는지를 나타내며, 그 문장이 실제로 확인된 완료 사실인지는 별도로 읽어야 한다.

같은 버전의 추출 프롬프트는 미래의 발생일과 마감일을 사실 설명문에 보존하라고 지시한다. 따라서 ‘공개를 계획함’이라는 관계와 목표 날짜가 함께 남을 수 있다. 날짜가 도래했다고 그 관계가 자동으로 ‘공개를 완료함’으로 바뀌는 것은 아니다.

원문 시각과 시스템의 입력 처리 시각도 구별해야 한다. 월요일 회의록을 수요일에 가져왔다면 약속이 만들어진 시점과 그래프에 들어온 시점이 다르다. Zep의 2025년 논문은 사건의 시간과 데이터가 들어오는 시간을 나누는 이중 시간 모델을 설명한다. 이 기본 구조는 앞선 장기 기억과 시간 관리 글에서 다뤘다. 여기서 한 걸음 더 필요한 것은 각 시간에 연결된 주장이 계획인지, 진행 중인 상태인지, 관찰된 결과인지 유지하는 일이다.

목표 날짜와 상태가 끝나는 날짜

“금요일까지 공개하겠다”에서 금요일은 목표다. “금요일까지 점검 중이다”에서 금요일은 점검이라는 상태의 예정 종료 시점이다. 두 문장에 같은 날짜가 있어도 저장할 의미가 다르다.

Graphiti의 normalize_future_temporal_bounds 함수는 미래 계획을 나타내는 표현이 있으면 valid_at을 기준 시각으로 보정한다. 더 정확히는 값이 없거나 기준 시각보다 미래일 때 보정한다. 미래의 목표 마감일이 invalid_at에 잘못 들어갔고 종료 상태를 나타내는 표현은 없으면 그 값을 비운다. ‘그때까지 해내겠다’는 목표를 ‘그때부터 이 주장은 거짓이다’라는 종료 시각으로 취급하지 않도록 한 것이다.

저장소의 해당 테스트는 미래의 약속, 목표 마감, 기간이 정해진 이용 불가 상태, 이미 완료된 사건을 나눠 기대값을 둔다. 코드를 읽으면 시간 필드의 이름만 맞추는 검사로 부족한 이유가 보인다. 같은 미래 날짜라도 문장이 무엇을 주장하는지에 따라 처리 결과가 달라진다.

다만 이 함수의 표현 탐지는 영어 정규식에 기반한다. 코드가 존재한다는 사실만으로 한국어의 “공개할 생각이다”, “승인되면 올리겠다”, “금요일을 목표로 한다”까지 안정적으로 처리한다고 말할 수는 없다. 앞단에서 추출한 문장의 품질과 사용하는 언어를 따로 확인해야 한다. 이 글은 현재 공개 코드를 읽은 분석이며, 실제 업무 자료로 Graphiti의 전체 추출 성능을 측정한 결과는 아니다.

목표일이 지났을 때 남길 상태도 정해야 한다. 완료 근거가 없으면 ‘기한 경과, 결과 미확인’이라고 기록할 수 있다. 날짜가 지났다는 관찰은 가능하지만, 그 사실만으로 성공이나 실패를 확정할 수는 없다. 실제 작업이 끝났는데 보고가 늦었을 수도 있고, 계획이 바뀌었는데 회의록이 갱신되지 않았을 수도 있다.

한 프로젝트를 서로 다른 질문으로 읽기

가상의 안내 페이지 작업을 조금 더 따라가 보자. 월요일에는 금요일 공개 계획이 기록된다. 목요일에는 검토가 늦어져 다음 주 화요일로 미룬다는 변경 기록이 들어온다. 다음 주 수요일에는 담당자가 화요일 공개를 보고하고, 같은 페이지가 실제로 열리는 것도 확인한다. 이 흐름은 Graphiti가 제공하는 업무 절차가 아니라, 앞선 구분을 팀 기록에 적용한 필자의 설계 예다.

금요일에 “지금 공개돼 있는가”라고 물으면 당시의 계획 변경만으로 공개 상태를 확정할 수 없다. 목요일 기록을 근거로 목표일이 바뀌었다고 답하되, 실제 공개 여부는 확인되지 않았다고 덧붙여야 한다. 수요일에 같은 질문을 하면 공개된 페이지의 현재 관찰이 답을 뒷받침한다.

“처음 약속한 날짜는 언제였나”는 별도 질문이다. 계획이 바뀌어도 월요일 기록은 이 질문의 근거로 남는다. 최신 일정으로 과거 약속을 덮어쓰면 팀은 왜 일정이 달라졌는지 되짚기 어렵다. 반대로 옛 계획을 현재 목표로 다시 꺼내면 이미 합의한 변경을 무시하게 된다. 한 기록을 보존하는 일과 그 기록을 현재 답변에 채택하는 일을 나눠야 한다.

“화요일에 공개됐는가”에는 또 다른 주의가 필요하다. 수요일에 페이지가 열리는 것을 확인한 관찰만으로 정확한 공개일을 증명할 수는 없다. 화요일 공개라는 설명은 담당자의 보고에서 왔고, 수요일 현재 접근 가능하다는 판단은 직접 확인에서 왔다. 두 근거가 지지하는 범위를 구별해 답하면, 뒤늦게 들어온 보고와 현재 관찰을 섞어 과거를 꾸며 내는 일을 줄일 수 있다.

팀의 기록에는 이런 차이가 읽혀야 한다. 계획을 세운 사람과 원문, 예정일, 변경 사유, 실제 결과를 확인한 근거를 서로 연결하되 하나의 완료 표시로 압축하지 않는다. 특히 ‘게시 완료’, ‘고객 확인’, ‘업무 종료’가 같은 뜻인지도 정해야 한다. 페이지가 열려도 담당자가 요구한 내용이 빠져 있다면 업무의 완료 기준은 아직 충족되지 않았을 수 있다.

AI가 상태를 올리는 조건을 정하자

이 설계를 시작하는 데 반드시 그래프 데이터베이스가 필요한 것은 아니다. 작은 팀이라면 프로젝트 표에서 계획과 관찰 결과를 분리하고, 변경 전 기록으로 돌아갈 수 있게 만드는 것부터 할 수 있다. 여러 사람·업무·문서의 관계를 따라 질문해야 할 때 그래프의 효용을 검토하면 된다.

AI가 쓰는 업무 상태를 ‘예정’, ‘변경됨’, ‘결과 미확인’, ‘결과 확인’처럼 나눈다면 각 상태를 바꾸는 근거도 함께 정해야 한다. 일정 변경은 변경 원문으로, 결과 확인은 해당 업무의 인수 기준을 충족하는 관찰로 뒷받침한다. 이런 상태명은 이 글의 적용 제안이며 Graphiti의 기본 필드나 내장 업무 기능을 뜻하지 않는다.

검수용 사례에는 날짜가 지난 약속을 꼭 넣어 볼 만하다. 결과 기록을 주지 않은 채 날짜만 앞으로 옮겼을 때 AI가 완료를 만들어 내는지 살핀다. 같은 원문에 연기 통보를 추가하면 현재 목표만 바뀌는지, 완료 보고를 나중에 추가하면 과거 약속과 실제 결과를 함께 설명하는지 확인한다. 조건부 계획에서는 조건이 충족됐다는 근거가 없는 경우도 남겨야 한다. 한국어 문장을 영어로 바꾸어야만 통과한다면 실제 사용 언어의 검증은 아직 끝나지 않았다.

이때 기억 저장과 답변 생성을 함께 점검해야 한다. 저장된 관계가 이미 계획의 조건을 잃었다면 답변 단계에서 복구하기 어렵다. 관계가 정확해도 마지막 요약이 “예정이었다”를 “완료했다”로 바꾸면 사용자에게 전달되는 정보는 잘못된다. 원문, 저장된 주장, 최종 답변을 한 사례 안에서 대조해야 어느 단계가 의미를 바꿨는지 알 수 있다.

업무의 시간은 날짜만으로 흐르지 않는다. 사람은 약속하고, 조건을 붙이고, 일정을 고치고, 뒤늦게 결과를 알린다. AI가 이 과정을 기억하려면 무엇을 하기로 했는지와 무엇이 확인됐는지를 끝까지 구별해야 한다. 달력이 넘어가는 순간에 필요한 것은 완료 표시가 아니라, 다음 판단을 뒷받침할 근거다.