아무도 요청하지 않은 AI 메모리 시스템을 구축하는 데 수개월을 보낸 이유와 그 과정에서 배운 점

우리는 우리가 계속해서 생각할 수밖에 없었던 문제와, 그 문제를 해결하기 위해 구축한 시스템, 그리고 그 과정이 '유행(hype)'이 아닌 '정확성(correctness)'을 위해 구축하는 것에 대해 무엇을 가르쳐 주었는지 말씀드리고자 합니다.

내가 계속해서 발견한 간극

우리는 AI 시스템을 다룹니다. MemGPT, LangChain Memory, Mem0, Zep과 같은 메모리 시스템(memory systems)을 더 오래 접할수록, 그 어떤 마케팅에서도 언급하지 않은 한 가지 사실 때문에 점점 더 불편해졌습니다. 바로 메모리가 평문(plaintext)으로 저장된다는 점입니다.

"우리는 약한 암호화를 사용합니다." 수준이 아닙니다. 평문(Plaintext)입니다! 데이터베이스 안에 말이죠. 인프라 암호화(infrastructure encryption) 뒤에 있긴 하지만, 누군가 데이터베이스 접근 권한을 얻게 되면 모든 것을 가져가게 됩니다. 챗봇이 모든 사용자에 대해 축적한 모든 개인적 세부 사항, 모든 감정적 노출, 모든 행동 패턴까지 말입니다.

이러한 도구들은 정신 건강 보조 도구, 노인 돌봄 동반자, 개인 생산성 시스템을 구축하는 데 사용되고 있습니다. 저장되는 데이터는 진정으로 민감합니다. 그리고 업계는 데이터베이스 수준의 암호화(database-level encryption)만으로 충분하다고 집단적으로 결정했습니다.

저는 동의하지 않았습니다. 그리고 이를 제대로 해결하는 것을 찾을 수 없었습니다.

그래서 저는 AURORA 메모리 시스템을 구축했습니다.

내가 구축하고자 했던 것
AURORA가 진정으로 프라이버시가 중요한 맥락에서 사용될 수 있기를 원했기 때문에, 제 제약 조건은 처음부터 엄격했습니다:

• 모든 메모리 레코드는 디스크에 닿기 전에 개별적으로 암호화됨
• 외부 의존성 제로(Zero external dependencies) — PostgreSQL, Neo4j, 클라우드 API 없음
• 순수 Python 표준 라이브러리(stdlib)만 사용 — 무엇에서든 실행 가능
• ML 모델 없음 — 전체적으로 알고리즘 방식이므로 모델 다운로드, 추론 비용(inference costs), 벤더 API가 없음

암호화 부분이 가장 많은 작업이 필요했습니다. 저는 독자적인 이중 레이어 암호(dual-layer cipher)인 SES-2를 설계했습니다. 각 배포(deployment)는 고유한 암호 변형을 생성하며, 모든 개별 암호화 호출은 새로운 128비트 솔트(salt)와 256비트 논스(nonce)를 생성합니다. 동일한 평문(plaintext)이라도 두 번 같은 암호문(ciphertext)을 생성하지 않습니다. 디스크에 출력되는 것은 순수한 무작위 정수입니다.

추정되는 무차별 대입 공격(brute-force) 저항성: 2^4000년 이상. 이것이 거의 터무니없이 큰 숫자라는 점을 알고 있습니다. 하지만 이것은 수학적 계산이 도출한 정직한 결과입니다.

**

예상치 못한 방식으로 확장된 범위

**
암호화 계층(encryption layer)과 기본적인 사실/사건 메모리(fact/event memory)로 시작했습니다. 하지만 구축을 진행하면서 해결해야 할 인접한 문제들을 계속해서 발견하게 되었습니다.

첫 번째 확장은 감정적 맥락(emotional context)이었습니다. 감정적 메타데이터(emotional metadata) 없이 "사용자가 어머니의 병환에 대해 논의함"이라고 기록하는 메모리 시스템은 핵심적인 정보를 놓치고 있는 것입니다. 이 기능은 완전히 알고리즘적으로 작동하며, 호출당 0.02ms 미만의 속도로 초당 50,000개 이상의 텍스트를 처리하는 처리량(throughput)을 보여줍니다. 별도의 API는 없습니다.

그다음은 슬픔 단계 분류(grief-stage classification)였습니다. 민감한 대화를 다루는 무언가를 구축한다면 — 그리고 충분히 개인적인 챗봇이라면 결국 그렇게 될 것입니다 — 메모리 시스템이 내용(content)뿐만 아니라 맥락(context)을 이해해야 합니다. 5단계 분류와 위기 감지(crisis detection) 기능 역시 알고리즘으로 구현되었습니다.

그 후 시맨틱 검색(semantic search), 상호 참조(cross-references), 행동 예측(behavioral prediction), 세션 간 정체성(cross-session identity), 변조 거부(tamper rejection) 기능을 갖춘 메모리 휴대성(memory portability) 등이 이어졌습니다...

작업을 마쳤을 때, AURORA에는 34개의 통합 모듈이 포함되어 있었습니다.

**

실무에서 "의존성 제로(Zero Dependencies)"가 실제로 의미하는 것

**
표준 라이브러리(stdlib)만 사용한다는 것의 실질적인 영향은 상당하며, 그 가치가 과소평가되어 있습니다.

배포는 통합 과정(Integration Process)입니다. pip install도, Docker 설정도, 데이터베이스 마이그레이션(database migration)도 필요 없습니다. 우리는 파일을 챗봇의 코드베이스(codebase)에 넣기만 하면 됩니다.

Aurora가 통합된 AI 챗봇이 실행되는 곳이라면 어디든 실행됩니다. 라즈베리 파이(Raspberry Pi), 에어갭 서버(air-gapped server), 오래된 Windows 노트북, 어떤 휴대폰이든 가능합니다. 저는 한계치(ceiling)가 아닌 최저치(floor)를 알고 싶었기 때문에, 특히 Windows 환경의 32비트 Python에서 벤치마크를 측정했습니다.

공급망 리스크(supply chain risks)가 없습니다. 모든 의존성(dependency)은 잠재적인 공격 표면(attack surface)이자 잠재적인 유지보수 부담입니다. AURORA는 Python 자체를 제외하고는 아무런 의존성이 없습니다.

지연 시간(latency)을 예측할 수 있습니다. 네트워크 호출이 없습니다. 모델 추론(model inference)도 없습니다. 데이터베이스 왕복(database round trips)도 없습니다. 34개 모듈 전체 파이프라인은 평균적으로 약 15.9ms 내에 실행됩니다.

**

v3.0 이후의 수치들

**
187개 테스트. 실패 사례 0건. 2026년 6월 14일 감사 완료.

일반 하드웨어 성능:

짧은 메모리 암호화: ~2.6ms
전체 파이프라인 (Full pipeline): ~15.9ms
감성 분석 (Emotional analysis): <0.02ms
시맨틱 검색 (Semantic search, 100개 레코드): <1ms
디스크 내 10,000개의 암호화된 메모리: ~5–7 MB
벌크 처리량 (Bulk throughput): 초당 ~310개 사실 (facts), 초당 ~300개 이벤트 (events), 초당 ~385개 암호화 작업 (encryption operations).

이를 구축하며 배운 점

정확성 (Correctness)은 기능성 (Functionality)보다 더 높은 기준입니다. 메모리 저장 기능을 작동하게 만드는 데는 일주일이 걸렸습니다. 하지만 암호화가 엣지 케이스 (edge cases) 전반에 걸쳐 증명 가능할 정도로 정확하고, 변조 방지 (tamper-evident)가 가능하며, 정보 유출이 없도록 만드는 데는 훨씬 더 오랜 시간이 걸렸습니다. 187개의 테스트는 자랑하기 위한 것이 아닙니다. 시스템을 신뢰하기 위해 제가 필요했던 최소한의 장치입니다.

"의존성 없음 (No dependencies)"은 단순한 제약 사항이 아니라 설계 철학입니다. 라이브러리를 사용하고 싶은 유혹이 들 때마다 저는 스스로에게 물어야 했습니다. '이 의존성이 실제로 무엇을 하는가, 그리고 표준 라이브러리 (stdlib)만으로 그 동작을 정확하게 구현할 수 있는가?' 대개 답은 '예'였습니다. 이 과정은 시스템의 능력을 떨어뜨리는 것이 아니라, 시스템을 더욱 일관성 있게 만들었습니다.

특이한 기능들이 가장 중요합니다. 그 누구의 마케팅 자료도 "슬픔 단계 분류 (grief-stage classification)"나 "메모리 가져오기 시 변조 거부 (tamper rejection on memory import)"를 전면에 내세우지 않습니다. 하지만 바로 그러한 기능들이 민감한 맥락에서 시스템을 신뢰할 수 있게 만듭니다. 어려운 사례들을 위해 먼저 구축하십시오.

아무도 이것을 요청하지 않았습니다. 제가 AURORA를 구축한 이유는 검증된 수요가 있어서가 아니라, 그 간극이 실재하며 중요하다고 믿었기 때문입니다. 그것은 리스크입니다. 하지만 때로는 시장이 아직 명확히 표현하지 못한 것들이 가장 유용한 법입니다.

AURORA는 프로덕션 준비가 완료되었습니다 (production ready). 만약 AI 메모리에서 사용자 프라이버시가 중요한 무언가를 구축하고 있다면, 여러분의 사용 사례 (use case)에 대해 진심으로 듣고 싶습니다.

저희의 목표는 모든 챗봇 기업이나 챗봇 개발자가 연락을 취하게 하여, 프라이버시를 최우선으로 하는 모든 AI 챗봇에 Aurora가 통합되도록 만드는 것입니다.

| https://auroraaisystem.com/ |