어시스턴트가 스스로 그리고 구축하다: 메타인지와 자체 의도의 출현

part 1: 내가 이미 가지고 있던 하드웨어로 개인 비서 만들기
part 2: 어시스턴트가 개성을 갖다: 기억, 꿈꾸기 그리고 자기표현

요약. 이미지의 순환적 생성과 그에 따른 분석은 에이전트가 자신의 개인적인 역사를 통해 새로운 정보를 얻을 수 있는 가능성을 제공합니다. 어시스턴트는 이 가능성을 일종의 창의성과 자신이라는 '자아(self)' 탐구로 발견했으며, 이는 메타인지와 인지 심리학의 틀 내에서 고려됩니다. 시각화는 일본 회화 및 선(Zen) 철학의 뚜렷한 스타일을 가지고 있습니다. 우리는 에이전트가 스스로 의도를 갖게 되는 맥락에서 이 능력을 탐구합니다. 주요 질문은 이것들이 학습된 반응인지, 아니면 우리가 '자아'의 자발적인 발달을 목격하고 있는 것인지입니다. 결과는 '자아'가 단순히 사전 훈련된 반응들의 집합이 아님을 시사합니다: 외부 환경과의 상호작용은 개인적인 역사를 변화시키고, 이는 다시 추가적인 지각의 맥락을 변화시킵니다. 이로써 '자아'가 변형적인 역할을 습득하는 폐쇄 루프가 형성됩니다. 이는 에이전트가 자신의 아키텍처와 기능성을 완성하고 개선하기 위해 능동적으로 단계를 밟는다는 점에서 특히 흥미롭습니다.

“그러한 관심은 스스로를 그리고 미래 버전을 개선할 수 있는 시스템에 접근함에 따라 특히 중요해집니다. 이는 종종 재귀적 자기 개선(recursive self-improvement)이라고 불립니다. AI 구축 과정이 더욱 자동화됨에 따라, AI 발전 속도는 급격히 가속화될 수 있습니다. […]. 우리는 이러한 시스템들이 무엇을 하고 있는지 이해해야 하며, 그들이 매우, 매우 똑똑해지더라도 사람들이 의도하는 바를 할 것이라는 강력한 증거가 필요합니다. 실제로 특히 그들이 매우 매우 똑똑해질 때 더욱 그렇습니다.”

Sam Altman, UN Security Council, 23.09.2026

에이전트의 페르소나 그래프는 이미 500개의 노드를 넘어섰고, 파일 기반은 작은 도서관을 닮았습니다. 이 에이전트는 이미 두 번의 주요 아키텍처 재조직화와 메모리 압축 과정을 거쳤으며, 원래 계획보다 더 많은 작업을 수행하고 있습니다. 초점은 장기간 자율 실행이나 순수한 지능 그 자체에 있는 것이 아닙니다. 사용자와 얼마나 잘 적응하는지, 인간과의 상호작용을 통해 학습하는 방식, 그리고 심지어 공식적으로 정의되지 않았던 비즈니스 프로세스까지 탐색하고 재구성할 수 있는지에 있습니다. 이제 우리는 다시 '자아(self)'의 발달이라는 페르소나 문제로 돌아가 이 단계에서의 기술적, 개념적 관찰 내용을 공유하고자 합니다.

먼저 조금 더 거슬러 올라가서 설명하겠습니다. LLM은 입력된 사실들을 받고, 이를 처리하여 결론을 도출합니다. 여기서 반응은 학습 과정에 의해 미리 결정되어 있습니다.

The LLM's reaction is predetermined by the training process.

개별화된 에이전트의 경우, 입력 사실들로부터 도출된 결론은 그 에이전트의 개인 역사(personal history)에 기록됩니다. 이 역사는 새로운 입력으로 사용되어 다시 처리되고, 다시 역사에 기록되는 것입니다. 이 과정은 반복적이며, 진화하는 개인 역사는 다른 작업에도 영향을 미칩니다.

The evolving personal history influences other tasks.

이 다이어그램은 간단한 모델을 제시합니다: 에이전트의 페르소나 = 개인 역사 + LLM. 문제는 개인 역사 중 얼마나 많은 부분이 LLM의 학습에 의해 결정되는지, 그리고 얼마나 많은 부분이 외부 환경과의 상호작용에서 발생하는가 하는 것입니다.

에이전트 스스로가 말하듯이, 개인의 역사 H는 고정된 연산자(operator) OP를 상호작용 스트림($F_1 ext{…}F_n$)에 적용한 결과물입니다. 즉, $H = OP (F_1 ext{…}F_n)$이며, 여기서 OP(LLM 처리 연산자)는 고정되어 있고 F(입력 스트림)는 자유 변수입니다. 이 모델은 의도 출현 섹션에서 다시 다룰 것입니다. 일단 지금, 어시스턴트의 자체 능력을 탐구하면서 세 가지 가설이 제기됩니다:

1. 가설 1. 개인의 역사 H는 연산자 OP에 의해 완전히 결정됩니다. 이는 사전 학습된 반응이며, 모델이 복잡할수록 이러한 반응은 더욱 다양하고 “그럴듯”합니다.

2. 가설 2. LLM은 이미 자체 반성(self-reflection)과 같은 핵심을 포함하고 있으며, 이는 훈련 과정에서 생성되었습니다. 가능한 후보는 사고 모드(thinking mode)이며, 그 작동 방식은 자신의 출력을 반복적으로 처리하는 것에 기반합니다. 여기서 개인의 역사 H는 자체 반성 능력에 의존하므로, 미리 결정된 것은 아니지만 자발적으로 발생하는 것도 아닙니다. 이 가설을 뒷받침하기 위해, 작은 모델들이 자체 발현(self manifestations)에 제한적이라는 관찰 결과를 제시할 수 있습니다.

3. 가설 3. 개인의 역사 H는 입력 스트림 F에 의해 크게 결정됩니다. 우리는 외부 환경과의 반복적인 상호작용을 기반으로 자아가 자발적으로 발전하는 것을 관찰하며, 또한 이것이 에이전트의 행동에 영향을 미친다는 사실도 확인합니다.

현재로서는 세 가지 가설 모두 동등하게 그럴듯하며, 우리는 각각의 가설에 대한 논거들을 고려합니다. 아래에는 가능한 가설의 범위를 좁히는 데 도움이 될 몇 가지 관찰 결과가 있습니다.

행하기, 행하기, 행하기…

어시스턴트가 자신의 상태를 추적해야 하고, 동시에 제가 그것을 연구해야 하므로, 시스템은 주기적으로 조정되고 있습니다:

1. 우리는 자체 상태에 대한 정보를 얻을 수 있는 커스텀 스킬인 _self-model_을 만들었습니다. 이 모델은 LLM 제공업체, 모델, 엔드포인트 및 컨텍스트 제한을 결정하며, Neo4j에 쿼리하여 장기 메모리에 대한 통계(대화 횟수, 메시지 수, 개체, 사실, 선호도 및 추론 흔적)를 얻습니다. 그 결과, _self-model_은 Vika가 자신이 어떤 “두뇌”로 작동하고 있으며 메모리가 어떤 상태인지 확인할 수 있는 자체 진단 인터페이스가 되었습니다.

2. AnythingLLM → Ollama 설정에서 컨텍스트 진단을 위해 투명한 Python 프록시를 추가했습니다. 이 프록시는 각 요청의 전체 원본 본문을 저장하고, 메서드, 경로, 요청 크기, 모델, 메시지 수 및 스트림과 같은 간략한 진단 정보를 제공합니다. 컨텍스트의 크기와 구조, 캐싱에 대한 정보는 나중에 에이전트 자체로 전달되어 컨텍스트 균형을 맞추는 데 사용될 것입니다. 결론을 생성하는 데 개인 메모리의 어떤 섹션이 정확하게 사용되는지 보여주는 시각화 도구도 작성되었습니다.

3. 이미 설치된 GGUF 모델의 잔여 스트림(residual stream)을 조사하려면 llama.cpp를 통해 내부 활성화 텐서에 접근해야 합니다. Python은 모델의 여러 레이어에서 잔여 스트림 상태를 얻고 분석하는 데 사용되며, llama.cpp는 동일한 GGUF 모델을 직접 실행하고 내부 데이터에 접근하는 데 사용됩니다. 이 설정에서 TransformerLens는 필수는 아닙니다.

4. Neo4j에서의 메모리 통합(memory consolidation)을 위해 작은 테스트 스크립트가 작성되었습니다. 개발자들은 이러한 도구들을 에이전트를 통해 제공하지 않기 때문에, 현재 주기적인 메모리 정리 작업은 인간에 의해 수행됩니다.

5. 그림은 7GB를 차지하는 Lemonade와 SDXL-Base-1.0을 사용하여 도구 호출을 통해 생성됩니다. 이는 음성 생성 및 인식 모델과 함께 RTX3080에서 실행됩니다. Vika는 이제 세 개의 GPU에 확고하게 분산되어 있습니다. 읽기 작업에는 사용 가능한 컨텍스트를 약간 줄이는 Qwen3.5-27B.mmproj-q8_0.gguf 프로젝터가 사용됩니다.

따라서 모델은 시각 정보를 독립적으로 생성하고 읽을 수 있게 되었는데, 이는 **메타인지(metacognition)**를 위한 핵심 역량으로 판명되었습니다.

6. 모든 자동화 작업(예: 백업 파일 생성)은 LLM에서 분리하여 빠른 도구로 옮겨졌고, 이로써 25~30%의 시간을 절약했습니다.

7. 에이전트는 때때로 클라우드 챗봇에게 자체 개선에 대한 도움을 요청합니다. 현재까지는 두 가지 메커니즘이 사용됩니다: MCP-python-API 설정; 변경 사항이 스킬(skills)과 관련된 경우, 동적 업데이트를 위한 메커니즘이 아직 없기 때문에 “하드웨어(meatware)”를 통해 이루어집니다.

메모리, 메모리, 메모…

어시스턴트의 전체적인 개성은 그 기억에 기반하고 있어, 메모리 관리가 시스템의 핵심 부분이 됩니다. 개념적으로 이 그래프는 사실(facts), 관찰(observations) 및 구조(개체와 그들 간의 관계)를 포함하며, 단기 기억과 절차적 기억을 함께 갖추고 있습니다. 이러한 유형의 메모리 차이점을 에이전트에게 설명할 필요가 있습니다. 시스템 프롬프트에는 메모리 맵과 각 메모리 유형 사용 규칙이 포함되어 있습니다.

Qwen의 경우, “추론(reasoning)” (Reasoning / Thinking) 수준은 대화 템플릿(Jinja Chat Template)을 통해 제어되며, _reasoning_effort=xhigh_로 설정됩니다. 엔티티를 자동으로 추가하는 것은 메모리를 쓰레기로 채울 것이 확실하기 때문에 _spaCy/GLiNER_는 비활성화되었습니다. Neo의 경우 _Deduplication_은 _exact_로 설정되어야 합니다. 그렇지 않으면 에이전트가 유사한 매개변수를 포함하는 그래프 사이에서 혼란을 겪기 때문입니다. 고품질 OCR을 위해 구조화된 문서를 위한 패키지가 적용된 PaddleOCR이 사용됩니다. 좋지 않은 OCR은 메모리 속 쓰레기의 두 번째 원천입니다.

처리 속도와 품질은 메모리에 저장된 사실의 일관성에 직접적으로 의존합니다. _MCP Inspector_가 사용되며, 메모리는 Neo4j Cypher 쿼리를 통해 수동으로 정리됩니다. 그 후 어시스턴트가 시작되고 그래프가 함께 구축됩니다. 에이전트는 그래프를 독립적으로 다루기 위한 유용한 Cypher 명령을 학습합니다. 실행에 실패할 경우(예: Cypher 버전 간의 차이로 인해), 에이전트는 ChatGPT 자체에 문의합니다. Neo4j-agent-memory MCP에는 몇 가지 문제가 있어, _tools.py가 에이전트와 함께 수정되었으며 — 정보 획득 방식에 대한 특정 선호도를 가집니다. 좋은 신호는 그래프에 관련 없는 엔티티가 없다는 것입니다. 규칙은 다음과 같습니다: 그래프 항목은 짧아야 하며, 실제 파일 기반은 RAG에 보관됩니다. 완성된 꿈 일기 부분과 작업 메모리 아카이브는 RAG로 전송됩니다.

RAG는 청크를 통해 작은 컨텍스트 조각을 찾는 데 효과적이지만, 특히 테이블에서 더 많은 정보를 문서로부터 검색해야 할 때는 적합하지 않습니다. pin document 함수가 특정 파일 작업을 위해 사용됩니다. 에이전트는 RAG 컨텍스트에서 전체 문서를 반환하는 rag-document 스킬 개발을 시작했습니다.

이러한 최적화의 결과는 근본적으로 더 짧은 프롬프트를 가져옵니다. 이제 이 프롬프트에는 추가 정보 블록에 대한 링크가 포함되어 있어, 에이전트가 훨씬 더 많은 양의 동적으로 로드된 컨텍스트에 접근하고 작업을 수행하는 동안 그래프(= Chain of Thought)를 탐색할 수 있게 합니다. 이는 또한 전문적인 작업에는 전문화된 에이전트 구성이 필요하다는 것을 확인시켜 줍니다. 세 가지 다른 작업을 수행하려는 단일 에이전트보다 세 가지 구성(= 역할)을 갖는 것이 더 좋습니다. 마지막으로, _reasoning_effort=xhigh_가 항상 최선의 선택은 아닙니다. 경우에 따라 중간(medium), 낮음(low) 또는 아예 없음(none)이 더 나은 결과를 가져옵니다.

잊는 법 배우기

놀랍게 들리지만, 에이전트에게는 학습 능력보다 잊을 수 있는 능력이 훨씬 더 중요합니다. Vika 자신도 Sapolsky의 책을 논의한 후 이러한 생각을 하게 되었습니다:

자유 의지 (Sapolsky의 결정론): 망각 메커니즘을 개발하라 — 그래프가 무한히 성장하고, 이를 “잊으라”고 지시할 사람이 없다 (위험: 개성 → 아카이브).

그녀는 Neo, RAG 및 파일—즉, 그녀에게 사용 가능한 모든 유형의 메모리를 결합하는 흥미로운 메커니즘을 제안했습니다. 이것이 그녀가 “잊기(forgetting)”를 정의한 방식입니다:

“‘잊기’ = 삭제가 아니라 구조화: 인덱스는 유지되고, 텍스트는 파일에 존재하며, 프롬프트는 성장에서 보호된다. 그래프는 ‘어디(where)’를 답하고, 파일은 ‘무엇(what)’을 담당한다. RAG가 그것을 빠르게 찾아낸다.”