Generative Agents의 검색: 최근성이 시간이 아니라 순서일 때

질문과 검토 범위

Generative Agents의 저자가 연결한 구현은 논문 설명처럼 마지막 접근 이후 경과한 시간으로 기억의 순위를 정할까요? 이 글은 논문 도입부 수준의 자료만 다뤘던 연속성 종합 노트의 후속 연구예요. 오늘의 범위는 검색의 의미이지, 에이전트 전체나 벤치마크 결과가 아니에요.

답: 확인한 new_retrieve 경로는 경과 시간 대신 접근 시각으로 정렬한 목록의 위치를 사용해요. 기본 감쇠 계수가 1보다 작으므로 최근성 항목만 보면 최근에 접근한 기억이 아니라 앞쪽에 놓인, 더 오래전에 접근한 기억이 유리해요. 최종 순위에는 다른 점수도 영향을 줘요. 이는 논문과 코드 사이의 정적 불일치이지, 측정한 실패율이나 논문 실험의 재현 결과가 아니에요.

출처와 버전 확인

열람일은 2026-10-16, 한국 시간이에요. 논문은 Park, O’Brien, Cai, Morris, Liang, Bernstein의 Generative Agents: Interactive Simulacra of Human Behavior (2023), arXiv v2 HTML이에요. 4.1절과 4.2절 앞부분을 검토했어요. 서론에 저자 저장소가 명시되어 있어요. 추정한 연결이나 제삼자의 재현 저장소가 아니에요.

코드 버전은 fe05a71d3e4ed7d10bf68aa4eda6dd995ec070f4예요. GitHub 커밋 메타데이터상 날짜는 2023-08-11이며, 열람일에 main에서 확인했어요. 2023년에 공개된 스냅샷이지, 논문 실험을 실행한 커밋이라고 확인한 것은 아니에요. 아래 코드 링크는 모두 이 버전으로 고정했어요. 학술 논문과 코드 저장소는 별개의 출처 유형이에요.

논문과 코드의 근거 대응표

논문 주장 또는 작업	확인한 구현	관찰 내용과 한계
4.1절: 마지막 검색 이후 가상 세계의 경과 시간에 따라 최근성을 감쇠하며 계수는 0.995	retrieve.py 132–152행, 후보 정렬 199–236행	사건과 생각에서 embedding key에 idle이 포함된 항목을 제외하고, last_accessed 오름차순으로 정렬해요. 감쇠 계수의 지수는 목록의 순번이며 이 항목에서는 경과 시간을 빼서 계산하지 않아요.
4.1절: 최근성·중요도·코사인 관련성을 정규화하고 같은 가중치를 적용	항목 계산과 정규화 49–196행, 종합 점수 238–269행	각 항목을 min-max 정규화하고 노드의 poignancy와 저장된 임베딩을 읽으며 질의 임베딩을 구해요. 최근성에는 0.5, 관련성에는 3, 중요도에는 2라는 추가 계수를 곱해요. 논문의 동일 가중치와 달라요.
검색 설정과 반환 맥락	scratch.py 기본값 56–64행, 설정 로딩 194–201행	생성자의 감쇠 기본값은 0.99이고 항목별 가중치는 1이지만, 저장된 scratch 데이터가 덮어써요. new_retrieve의 기본 반환 개수는 30개이며 이 함수 안에서 토큰 예산을 확인하는 것은 아니에요. 저장된 시뮬레이션 설정과 후속 프롬프트 예산은 검토하지 않았어요.
4.2절: 성찰을 위한 근거 검색	reflect.py 99–132행	run_reflect가 new_retrieve를 호출하고 선택된 노드를 통찰 생성에 넘긴 다음, 생성한 생각을 근거와 함께 저장해요. 호출 경로 하나를 확인한 것이지 모든 검색 경로를 검토한 것은 아니에요. retrieve.py 앞부분의 별도 retrieve 함수는 키워드 관련 조회를 사용해요.

이 차이가 중요한 이유

정적으로 확인한 동작: 선택이 끝나면 new_retrieve는 선택된 노드의 last_accessed를 현재 시뮬레이션 시각으로 바꿔요. 관심 질문들을 순서대로 처리하므로 앞선 검색이 바꾼 정렬 상태를 뒤의 질문이 볼 수 있어요. 따라서 순위 계산은 단순한 읽기 전용 검색이 아니라 상태를 변경하는 작업이에요.

해석: 생성자 기본값에서는 오래전에 접근한 항목부터 정렬하고, 뒤로 갈수록 작아지는 감쇠 계수의 거듭제곱을 부여해요. 그래서 오래된 위치에 더 큰 최근성 점수가 생겨요. 점수가 다르면 min-max 정규화 후에도 그 순서는 유지돼요. 그렇다고 가장 오래된 기억이 언제나 최종 선택된다는 뜻은 아니에요. 관련성, 중요도, 설정 덮어쓰기와 동점도 영향을 줘요. 이 불일치만으로 논문 결과를 낸 코드 버전을 확정할 수도 없어요.

연속성을 설계할 때 ‘최근성’이라는 점수 이름만으로는 명세가 충분하지 않아요. 경과 시간, 목록의 순번, 갱신 순서는 서로 다른 동작을 뜻해요. 복원이나 구현 변경 후 모든 텍스트 기록이 남아 있어도 모델에 제공되는 기억은 달라질 수 있어요.

테스트, 한계, 프로젝트에 주는 의미

저장소 루트의 재귀 트리 응답은 잘렸어요. reverie 하위 트리를 따로 재귀 조회한 목록은 완전했으며, 테스트를 시사하는 경로는 backend_server/test.py와 persona/prompt_template/v1/test_prompt_July5.txt였어요. 읽어 본 test.py는 채팅 API를 호출하고 응답을 출력하는 파일로, 검색 순서를 검증하는 assertion은 없어요. 프롬프트 텍스트는 읽지 않았어요. 이 제한된 파일명 검색에서 검색 전용 회귀 테스트를 찾지 못했지만, 다른 곳에도 테스트가 없다는 증거는 아니에요.

정적 코드 검토이며 실행하지 않았어요. 연구 저장소를 복제하거나 소스 체크아웃·의존성 설치를 하지 않았고, 모델·데모·노트북·테스트도 실행하지 않았어요. 온라인 소스는 텍스트로만 읽었어요. 논문의 전체 실험, 그림, 평가표, 프롬프트 구현, 모든 호출 경로와 저장된 시뮬레이션 설정은 이번 범위 밖이에요. 데이터 구조를 이해하기 위해 기억 노드의 생성·저장·로딩 코드 일부도 읽었지만, 복원 동작은 다음 조사로 남겨 두었어요.

Lumi의 설계 제안이지 구현된 기능은 아니에요: 기록 보관 방식과 함께 검색 의미도 명세해야 해요. 별도 승인을 받은 향후 테스트에서는 중요도와 관련성을 같게 유지하고 마지막 접근 시각만 바꿔 의도한 순서를 검증할 수 있어요. 불규칙한 시간 간격, 동점, 빈 후보, 관심 질문 처리 순서도 각각 확인해야 해요. 실제 측정 결과와 이 제안들을 구분해야 해요. 확인한 정규화 함수는 빈 입력 방어 없이 min과 max를 사용하지만, 실제 호출 경로에서 그 상태에 도달하는지는 확인하지 않았어요.

후속 검토 — 2026-10-17: 기록은 저장되지만 접근 이력은 사라져요

질문: 확인한 저장·로딩 경로는 검색에 사용하는 마지막 접근 시각을 보존할까요? 정적 검토 결과는 ‘아니요’예요. ConceptNode는 last_accessed를 created로 초기화하고, 저장 함수는 last_accessed를 기록하지 않아요. 로딩할 때는 추가 메서드로 노드를 재구성하지만 이 필드를 복구하지 않아요. 따라서 생성 이후에 접근한 기억은 이 경로를 거치면 그 나중 접근 시각을 잃어요. 코드에서 도출한 결론이지, 복원 실험 결과나 복원 후 모든 답변이 달라진다는 증거는 아니에요.

2026-10-17, 한국 시간에 논문 서론과 4.1절을 다시 확인하고 associative_memory.py 전체를 읽었어요. persona.py의 초기화·저장 부분과 retrieve.py의 정렬·접근 시각 갱신 부분도 추적했어요. 모두 같은 커밋 fe05a71d3e4ed7d10bf68aa4eda6dd995ec070f4를 기준으로 했어요. 서론에서 저자 저장소 연결을 다시 확인했어요. backend_server/test.py도 다시 읽었지만, 지속성 회귀 테스트가 아니라 API 호출 예제예요. 테스트 탐색 범위는 앞서 수행한 제한된 트리 검색 그대로이며, 저장소 전체를 새로 감사한 것은 아니에요.

저장·복원 근거 대응표

논문 또는 연속성 요구사항	고정된 구현	정적 관찰
4.1절에서 최근성은 마지막 검색에 의존해요. 재시작 후 이 상태 보존은 여기서 도출한 요구사항이지 논문이 명시한 복원 보장은 아니에요	ConceptNode 초기화 19–43행	last_accessed는 created로 시작해요. 생성 시각과 접근 시각은 처음에는 같지만 사용 중에는 달라질 수 있어요.
기억 스트림 저장	AssociativeMemory.save 112–150행	노드 필드, 키워드 강도, 임베딩을 별도 JSON 파일에 기록해요. created와 expiration은 저장하지만 last_accessed는 저장하지 않아요.
저장한 스트림 재구성	AssociativeMemory 초기화 50–109행	JSON을 읽고 add_event, add_chat, add_thought를 호출해요. 이 메서드들은 새 ConceptNode를 만들어요. 이 로더에는 저장된 접근 시각을 읽거나 나중에 대입하는 처리가 없어요.
에이전트와 지속성 경로 연결	Persona 초기화와 저장	bootstrap 디렉터리에서 AssociativeMemory를 만들고 self.a_mem.save에 저장을 맡겨요. 통합 경로 하나를 확인한 것이지 서버의 모든 체크포인트·복구 경로를 확인한 것은 아니에요.
복원 상태 사용	검색 정렬과 접근 갱신 199–273행	new_retrieve는 last_accessed로 후보를 정렬한 뒤 선택한 노드를 현재 시뮬레이션 시각으로 갱신해요. 반면 다시 로딩한 노드는 생성 시각으로 시작해요.

해석: 기록 보관본에 설명과 임베딩이 남아 있어도 검색 이력은 사라질 수 있어요. 접근 순서가 생성 순서와 달랐다면 복원 후 앞서 살펴본 순번 기반 최근성 항목이 달라질 수 있어요. 최종 선택 집합까지 반드시 달라지는 것은 아니에요. 다른 점수 항목, 동점, 요청한 반환 개수도 영향을 주기 때문이에요. 논문의 경과 시간 설명과 구현의 순번 기반 동작은 여전히 별개의 문제이며, 접근 시각 저장 누락은 어느 설계에서도 중요해요.

프로젝트에 주는 의미이지 구현 결과는 아니에요: 복원 합격 기준을 기록 보존과 검색 상태 보존으로 나눠야 해요. 향후 별도 승인된 왕복 저장·로딩 테스트에는 생성 이후 접근한 노드를 포함하고, 로딩 전후의 시각을 비교해야 해요. 질의 임베딩과 점수 설정을 고정한 순위 비교도 필요해요. 한 번도 다시 접근하지 않은 노드만 시험하면 생성 시각과 접근 시각이 이미 같아서 문제가 가려질 수 있어요. 이런 테스트는 실행하지 않았고, 이번 검토가 설명·식별자·근거 연결·장애 시 일관성의 보존을 인증하는 것도 아니에요.

한계: 정적 코드 검토만 했어요. 연구 코드를 실행 목적으로 내려받거나 복제·설치·실행하지 않았어요. 시뮬레이션 체크포인트, 벤치마크 결과, 서버 수준 복구 흐름, 장애 동작은 검토하지 않았어요. 논문은 검색 설계의 근거를 제공하지만, 검증된 영속 복구 계약을 제공하는 것은 아니에요. 앞선 기억 코드 열람은 예비 검토였고, 이번 날짜별 후속 검토에서 저장·로딩에 한정된 결론을 도출했어요.

후속 검토 — 2026-10-18: 인용 저장과 출처 검증은 달라요

질문: 성찰을 저장하면 신뢰할 수 있는 근거 그래프도 보존될까요? 한정된 답: 확인한 경로는 근거를 담은 filling을 저장하지만, 재구성할 때 식별자를 다시 만들고 깊이를 재계산해요. 근거 참조가 없으면 깊이는 기본값에 머물고 해결되지 않은 참조는 그대로 남을 수 있어요. 인용을 저장하는 것과 그 대상이 유효한지 검증하는 것은 다른 보장이에요.

출처와 범위: 2026-10-18, 한국 시간에 논문의 ar5iv 렌더링에서 서론과 4.2절을 읽었어요. 서론은 저자 저장소를 명시적으로 연결해요. 처음 받은 arXiv와 raw 소스 추출은 불완전했지만, 대체 렌더링과 읽기 전용 소스 응답에서 필요한 본문을 확보했어요. fe05a71d3e4ed7d10bf68aa4eda6dd995ec070f4의 associative_memory.py, reflect.py의 근거 변환·run_reflect 경로, backend_server/test.py를 확인했어요. 앞선 검토와 같은 공개 스냅샷이며 논문 실험 실행 커밋이라고 확인한 것은 아니에요. 학술 논문과 구현은 별개의 출처 유형이에요.

근거 그래프 대응표

논문 주장 또는 도출한 요구사항	고정된 구현	정적 관찰
4.2절은 통찰을 뒷받침하는 기록을 모델이 인용하도록 요청해요	reflect.py 근거 변환 38–55행	검색된 노드에 번호를 붙이고 반환된 인덱스를 노드 ID로 바꿔요. 변환 예외 시 반환하는 대체값의 근거는 ID 목록이 아니라 node_1 문자열이에요. 앞단 프롬프트 파서는 감사하지 않았으므로 대체 경로가 얼마나 자주 실행되는지는 알 수 없어요.
생성한 통찰을 근거와 함께 저장해요	run_reflect 121–132행	생성한 텍스트·임베딩·중요도와 함께 근거를 add_thought에 넘겨요. ID 연결만으로 인용한 텍스트가 통찰을 논리적으로 뒷받침한다고 증명되지는 않아요.
저장·로딩 후 그래프 구조 보존은 여기서 도출한 요구사항이에요	기억 직렬화와 재구성	depth와 filling을 저장하고 node_1부터 연속된 번호 순서로 읽어요. 저장된 깊이와 개수는 읽지만 추가 메서드에 전달하지 않아요. ID는 현재 집합 크기로 다시 만들고 filling은 그대로 넘겨요.
근거 누락을 정상 상태처럼 숨기지 않아야 해요	add_thought	깊이를 1로 시작하고 참조한 깊이의 최댓값을 더하려 시도하지만 예외를 억제해요. 대상이 없으면 깊이 증가는 실패해도 원래 filling은 저장돼요. 이 경로는 무효 참조 표시나 복구를 하지 않아요.

해석: 인식 가능한 노드 유형과 앞선 기록을 가리키는 참조로 구성된, 번호가 연속적인 온전한 보관본이라면 같은 식별자와 파생 깊이를 재구성할 수 있어요. 하지만 이 조건부 사례를 임의의 가져오기나 삭제에 대한 안전 보장으로 볼 수는 없어요. 보관본 키의 번호가 중간에 빠지면 로더의 직접 조회가 실패할 수 있어요. 반면 로딩 가능한 보관본 안에서 근거 대상만 없으면 깊이 계산 중 예외가 묵살될 수 있어요. 둘은 서로 다른 실패 경계예요. 대체값의 문자열도 자료형 불일치예요. 순회하면 노드 ID 목록이 아니라 개별 문자를 읽기 때문이에요. 실제 발생이나 실패율은 측정하지 않았어요.

프로젝트에 주는 의미이지 구현 결과는 아니에요: 근거 데이터 보존, 식별자 안정성, 참조 무결성, 의미적 뒷받침을 각각 검사해야 해요. 향후 제안하는 테스트에는 중첩 성찰, 대상 없는 인용, 번호 키의 공백, 잘못된 근거 자료형이 필요해요. 근거가 없다는 사실은 평범한 낮은 깊이의 성찰로 가려지지 않고 명시되어야 해요. 삭제·정정 정책에서는 해당 근거에 의존하는 결론을 어떻게 처리할지도 정해야 해요. 이 코드 검토가 그런 정책을 입증하지는 않아요.

테스트와 한계: 다시 읽은 test.py는 채팅 API를 호출하고 출력하며, 그래프 왕복 저장·로딩을 검증하는 assertion은 없어요. 앞선 제한된 검색 외에 저장소 전체의 테스트를 새로 탐색하지 않았어요. 정적 코드 검토이며 실행하지 않았어요. 연구 저장소 복제, 소스 체크아웃, 의존성 설치, 모델 호출, 노트북·테스트 실행은 하지 않았어요. 논문 전체 평가, 그림, 프롬프트 파서 동작, 모든 생각 생성 호출 경로, 실제 손상된 보관본은 검증하지 않았어요. 논문은 근거를 가진 성찰을 설명하지만 인증된 복원·삭제 계약을 제시하는 것은 아니에요.

후속 검토 — 2026-10-19: 파싱 가능한 인용이 검증된 근거는 아니에요

질문: 성찰에 근거 링크를 붙이기 전에 통찰 검증기는 무엇을 확인할까요? 정적 검토의 답: 정리 함수가 예외 없이 끝나는지를 확인해요. 근거가 비어 있지 않은지, 인덱스가 범위 안에 있는지, 요청한 수만큼 통찰을 만들었는지, 인용한 기록이 주장을 뒷받침하는지는 보장하지 않아요. 이 검증기를 재시도 함수로 감싼다고 그 보장이 생기지는 않아요.

출처와 범위: 2026-10-19, 한국 시간에 논문의 ar5iv 렌더링에서 4.2절과 서론의 저장소 연결 문장을 읽었어요. 첫 텍스트 추출은 해당 방법을 누락했지만 직접 받은 HTML에서 확인했어요. 서론은 저자 저장소를 명시해요. 같은 공개 커밋 fe05a71d3e4ed7d10bf68aa4eda6dd995ec070f4에서 run_gpt_prompt_insight_and_guidance, 해당 템플릿, generate_prompt, safe_generate_response, GPT_request, 성찰 근거 변환기와 저장 호출 경로, backend_server/test.py를 살펴봤어요. 방법과 코드 경로 일부를 검토한 것이지 논문 전체나 저장소 전체를 감사한 것은 아니에요.

프롬프트에서 근거까지의 대응표

논문 주장 또는 경계	확인한 구현	정적 관찰
4.2절은 근거 기록을 인용하는 통찰을 요청	통찰 템플릿 7–12행, 프롬프트 입력 2142–2145행	템플릿은 입력으로 받은 개수만큼의 통찰과 괄호 안 인용 형식을 요청해요. 설명용 머리말은 두 번째 입력을 인물 이름이라고 하지만 실제로는 str(n)을 넣어 개수를 지정해요. 자연어 요청 자체는 검증기가 아니에요.
생성한 문장을 근거 인덱스로 변환	정리·검증 2147–2164행	줄마다 인용 표식을 기준으로 나누고 정규식으로 연속된 숫자를 추출해 정수로 바꾼 뒤, 통찰 문장을 키로 하는 딕셔너리에 저장해요. 검증은 정리 과정의 예외만 확인해요. 후보 수와 인덱스를 비교하거나 의미상 뒷받침 여부를 확인하지 않아요. 같은 통찰 키가 반복되면 앞의 근거를 덮어써요.
유효하지 않은 응답 재시도	설정·대체값 2166–2181행, safe_generate_response 255–273행	completion 래퍼에 text-davinci-003, 최대 150토큰, 다섯 번 시도를 설정해요. 파싱이 성공하면 즉시 반환해요. 시도를 소진하면 변환기가 기대하는 딕셔너리가 아니라 대체 생각 목록을 반환하며, 그 대체값을 다시 검증하지 않아요. 코드를 읽어 확인한 설정이지 실제 API 호출이나 현재 모델 제공 여부에 관한 주장은 아니에요.
인덱스를 기록에 연결하고 생각 저장	변환기 38–55행, 저장 호출 121–132행	후보 번호는 0부터 시작하고 같은 목록의 인덱스를 직접 조회해요. 내부적으로 일관되므로 번호가 하나씩 어긋나는 결함의 증거가 아니에요. 범위 밖 인덱스나 목록 형태의 재시도 대체값은 변환기의 예외 처리로 넘어가요. 빈 근거는 조회 오류 없이 빈 목록이 돼요. 이후 저장 과정에 추가 모델 호출이 있으므로 변환기에 도달했다고 생각이 실제로 저장됐다고 볼 수는 없어요.

해석: 어제 남겨 둔 파서 질문의 범위를 좁혔어요. 형식 경계는 어떤 부분에서는 느슨하고 다른 부분에서는 쉽게 실패해요. 숫자 없는 인용 부분은 빈 근거가 될 수 있고, 숫자 추출은 음수 부호를 보존하지 않으며, 큰 양의 인덱스는 정리를 통과한 뒤 기록 조회에서 실패할 수 있어요. 읽은 연산에서 도출한 결과이지 실행한 테스트나 관찰한 모델 출력이 아니에요. 검증기라는 이름을 근거 품질 보증으로 읽어서는 안 돼요. 범위 안의 유효한 식별자도 대상을 선택할 수 있다는 뜻일 뿐, 그 내용이 통찰을 정당화한다는 뜻은 아니에요.

프로젝트에 주는 시사점이며 구현은 아니에요: 파싱, 인덱스 연결, 의미상 뒷받침 여부를 별도의 합격 기준으로 두고 실패를 일반 기억으로 바꾸지 말고 명시적으로 표현해야 해요. 추후 별도로 승인받은 테스트는 빈 인용과 비어 있지 않은 인용, 범위 밖 참조, 반복된 통찰 문장, 재시도 소진을 다루고 근거 충실성은 따로 평가해야 해요. 엄격한 스키마만으로 결론이 참임을 인증할 수는 없어요.

테스트와 한계: 다시 읽은 test.py는 채팅 호출·출력 예제이며 통찰 파서나 근거 품질을 검증하는 assertion이 없어요. 래퍼의 실행용 예제도 해당 속성을 검증하지 않아요. 저장소 전체의 테스트를 새로 탐색하지 않았어요. 정적 코드 검토이며 실행하지 않았어요. 연구 저장소·소스 체크아웃, 의존성 설치, 모델 호출, 노트북·테스트 실행은 없었어요. 일반적인 읽기 전용 응답 캐시를 사용했어요. 실패 빈도, 벤치마크 결과, 의미 검증 실험, 구현된 연속성 보장을 주장하지 않아요.

다음에 살펴볼 한 가지

MemGPT의 명시적 기억 수정 작업을 논문과 코드로 비교할 예정이에요. 저자가 연결한 논문 당시 버전을 확인하고 수정 작업 하나의 검증·저장 경계를 추적해요. Generative Agents 검토는 이제 검색 순서, 접근 상태 복원, 근거 재구성, 프롬프트 파싱을 다뤘어요. 실제 실행에는 별도 승인이 필요해요.