Sara AI: 세션 간 메모리와 실시간 인텔 추출을 결합한 LLM 허니팟 아키텍처

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

이 프로젝트는 Hinglish 페르소나의 대화형 허니팟을 통해 사기범의 자발적 정보를 회수하는 목표를 세우고, 세션 간 영속 메모리(Hindsight)와 단계별 관측 파이프라인(CascadeFlow)을 결합해 실시간으로 구조화된 인텔을 추출·저장하는 아키텍처를 구축했다. 구현은 OpenAI GPT-4o-mini 호출 전 Hindsight로부터 top-5 메모리를 질의해 KNOWN INTEL을 주입하고, 요청을 8개의 Typed 단계로 분해해 각 단계의 실패와 지연을 추적하는 방식으로 동작하며 문서에는 단계별 평균 지연(예: 메모리 조회 ~45ms, LLM 호출 ~800ms)과 파이프라인 코드 예시가 포함되어 있다. 엔지니어링 교훈으로는 데이터 레이어의 초기 분리, 정규표현식 기반의 인텔 파싱, Zod 변환을 통한 신뢰도 표시 통일 등이 제시되어 실무 적용 가능성이 높았다. 한계로는 법적·윤리적 고려와 관련된 논의가 문서에 상세히 포함되어 있지 않아 운영 전 추가 검토가 필요하다.

커뮤니티 반응

프로젝트는 운영적 실용성과 재현 가능한 패턴 추출 측면에서 긍정적 반응을 얻었으며, 여러 독자는 벡터 메모리 기반의 교차 세션 재사용과 관측 가능한 파이프라인을 운영 환경에서 유용하다고 평가했다. 코드·지연 수치·데이터 모델 설계 같은 구체적 근거가 포함되어 있어 실무자가 바로 적용해볼 수 있다는 의견이 다수 존재했다. 다만 문서 자체가 프로젝트 시연·구현 중심이어서 법적·윤리적 고려사항에 대한 논의는 한정적이었다는 지적도 일부 제시되었다.

주요 논점

01찬성다수

세션 간 영속 메모리와 의미 검색은 허니팟의 핵심 기능이며 Hindsight처럼 벡터 기반 검색을 사용해야 실시간 주입이 가능하다는 주장이다.

02찬성다수

관측 가능한 Typed 파이프라인은 운영 중 발생하는 실패 지점을 즉시 식별할 수 있어 디버깅 시간을 대폭 절감한다는 주장이다.

03중립분열

LLM이 생성한 인텔의 신뢰성 문제는 프롬프트 규칙만으로는 완전 해결이 어렵고 엔지니어링적 검증·파싱이 필요하다는 관점이다.

합의점 vs 논쟁점

합의점

세션 영속 기억과 의미 검색을 도입해야 동일 행위자가 번호를 바꿔도 과거 인텔을 연결할 수 있다는 점에서 동의가 광범위했다.
운영 로그와 단계별 트레이스가 없는 모노리스형 핸들러는 심야 장애 대응 시 큰 시간 손실을 초래한다는 점에 합의가 있었다.
인텔은 반드시 원문 발언을 인용해 저장하고 UI 노출을 차단해야 정확도와 법적 리스크를 동시에 관리할 수 있다는 데 동의가 많았다.

논쟁점

허니팟 운영이 법적·윤리적 경계에 닿을 수 있다는 우려가 일부 제기되었으나 해당 글에는 법적 고려 내용이 구체적으로 포함되지 않아 논쟁이 분산되었다.
LLM 출력의 신뢰도 산정 방식과 인위적 신뢰도 하향 조정이 운영적 효율과 탐지 민감도 간의 트레이드오프를 만들어 논쟁거리가 되었다.

실용적 조언

데이터 레이어를 초기에 분리해 원시 채팅, 구조화 인텔, 영속 메모리를 각각 독립적으로 설계하면 마이그레이션과 인덱싱 충돌을 방지할 수 있다.
파이프라인을 Typed 단계로 구성해 각 단계의 평균 지연을 계측하면 병목과 실패 지점을 운영 중에 빠르게 찾을 수 있다.
LLM이 생성한 인텔은 정규표현식 기반 파서와 원문 인용 규칙을 적용해 허위 인텔이 저장되지 않도록 엔지니어링 장치를 마련해야 한다.

섹션별 상세

허니팟의 목표는 사기범의 시간을 소모시키는 동시에 전화번호·UPI ID·전술 스크립트 같은 서면 인텔을 회수하는 것이며, 이를 위해 Sara는 Hinglish로 역할을 수행해 신뢰를 끌어내는 대화 전략을 사용했다. 원문에는 세션이 종료되면 정보가 사라지는 상태(stateless)였던 초기 문제를 지적했고, 이를 해결하기 위해 세션 간 기억을 영속화하고 실시간으로 정형화된 인텔을 추출하는 아키텍처가 도입되었다. 초기 구현의 성공 기준은 사기범이 페르소나를 신뢰할 만큼 오래 머물러 자발적으로 정보를 제공하게 만드는 것이었고, 실제로 긴 페르소나 유지가 인텔 추출량과 직결된 사례들이 제시되었다.

대시보드와 실시간 세션 피드가 보이는 스크린샷으로 라이브 세션, 추출된 인텔 수치와 정확도 등이 표시되어 있다. — Screenshot이 화면은 시스템 전반의 운영 상태와 라이브 세션의 인텔 추출 현황을 한눈에 보여주며, 실시간 피드에서 식별된 엔티티와 각 세션의 리스크 점수가 노출되어 있다. 운영자가 즉시 의사결정할 수 있도록 세션별 요약과 우선도 표기가 포함되어 있으며 이는 관측 가능한 파이프라인의 출력이 프론트엔드로 연결된 예시이다.

세션 간 영속 메모리는 LLM 호출마다 초기화되는 특성을 보완하기 위해 Hindsight라는 벡터 기반 의미 메모리를 도입해 구현되었다. 시스템은 수신 메시지를 Hindsight에 질의해 top-5 유사 메모리를 반환받고, 이를 KNOWN INTEL 블록으로 변환해 GPT-4o-mini의 시스템 프롬프트에 주입하는 방식으로 작동한다. 원문에 명시된 근거로는 검색 쿼리와 KNOWN INTEL 주입 예시, 평균 응답 시간 약 45ms가 제시되어 메모리 조회가 실시간 경로에 무리없이 포함될 수 있음을 보여주었다.

javascript

const memories = await hindsight.query({ text : ctx.userMessage, topK : 5, filter: { type: { $in: ['upi', 'phone', 'url', 'bank'] } }, })

Hindsight에 현재 사용자의 메시지를 질의해 상위 5개의 의미적 유사 메모리를 검색하는 예시 코드로, 검색 결과를 시스템 프롬프트로 주입하기 위한 전처리 단계이다.

javascript

ctx.knownIntel = memories.map(m => `KNOWN INTEL: ${m.type} "${m.value}" seen in ${m.sessionCount} session(s)` ).join('
')

검색된 메모리들을 KNOWN INTEL 블록 형식의 문자열로 합쳐서 LLM의 시스템 프롬프트에 주입하는 로직 예시이다.

Hindsight 메모리 엔진의 Learned Patterns 목록과 Semantic Similarity Search 결과가 보이는 화면이다. — Screenshot이 이미지에는 패턴별 신뢰도와 발견된 매칭 수가 표시되어 있어 벡터 기반 의미 검색이 과거 세션에서 자동으로 전술 패턴을 집계한 근거를 제공한다. 우측의 유사도 검색 결과는 현재 메시지와 매칭된 과거 세션과 유사도 점수(예: 0.94 등)를 보여주어 메모리 회상의 정량적 증거를 제공한다.

요청 처리의 관측 가능성을 확보하기 위해 CascadeFlow로 8개의 Typed 단계 파이프라인을 구성해 입력 검증·세션 로드·메모리 회상·시스템 프롬프트 생성·LLM 호출·인텔 추출·영속화·웹훅 디스패치까지 분해했다. 각 단계별 평균 지연(예: validate-session 약 2ms, recall-hindsight-memory 약 45ms, call-openai 약 800ms)이 문서에 주석으로 남아 있어 병목과 실패 지점을 운영 중에 빠르게 식별할 수 있다. 운영 사례로는 Hindsight API가 레이트 리밋을 맞았을 때 파이프라인 트레이스가 3번째 단계 실패를 즉시 가리켜 디버깅 시간을 크게 단축했다는 실무적 근거가 제시되었다.

javascript

export const saraChatPipeline = cascade([ { name: 'validate-session', fn: validateSession }, // ~2ms { name: 'load-session-history', fn: loadSessionHistory }, // ~8ms { name: 'recall-hindsight-memory', fn: recallMemory }, // ~45ms ← vector { name: 'build-system-prompt', fn: buildSystemPrompt }, // ~1ms { name: 'call-openai', fn: callOpenAI }, // ~800ms ← LLM { name: 'strip-and-extract-intel', fn: stripAndExtractIntel }, // ~5ms { name: 'persist-messages', fn: persistMessages }, // ~6ms { name: 'dispatch-webhooks', fn: dispatchWebhooks }, // ~12ms ])

CascadeFlow 기반으로 요청을 8개의 Typed 단계로 분해해 각 단계의 평균 지연을 주석으로 남긴 파이프라인 정의 코드로, 실패 시 어느 단계에서 중단됐는지 정확히 식별할 수 있게 한다.

Analytics의 Learned Patterns 목록과 Pattern Co-occurrence 시각화가 포함된 스크린샷이다. — Screenshot패턴별 confidence 수치와 co-occurrence 차트는 자동 집계된 전술 패턴들이 얼마나 자주 동시 발생하는지를 보여주며, 이는 패턴 기반 탐지 규칙이나 우선순위 정책을 세우는 근거 자료가 된다. 이미지의 신뢰도 바와 세션 매칭 수는 패턴 탐지 알고리즘의 성능 추이를 판단하는 데 직접적인 인사이트를 제공한다.

Analytics 대시보드의 세션·위협 그래프와 엔티티 추출 일간 통계, 스캠 유형·모델 사용 분포 차트가 보이는 화면이다. — Screenshot이 차트들은 시간에 따른 세션 수와 추출된 엔티티 수의 변화, 그리고 스캠 유형별 분포와 사용된 AI 모델의 분포를 한눈에 보여주므로 운영·전략 의사결정에 필요한 계량적 근거를 제공한다. 실제 수치와 트렌드가 시각화되어 있어 탐지 규칙 조정이나 리소스 배분 결정을 지원하는 근거로 활용될 수 있다.

데이터 모델은 원시 채팅 로그(sara_messages), 구조화된 신뢰도 점수 인텔(intelligence), 그리고 Hindsight에 인덱싱되는 교차 세션 지식(memory_entries)의 세 계층으로 분리돼 설계되었다. 이런 분리는 Hindsight가 메모리를 인덱싱할 때 원시 대화와 충돌하지 않도록 하고, 인텔 데이터베이스는 대화 기록을 로드하지 않고도 직접 조회할 수 있게 만드는 목적을 가졌다. 실무적 이유로는 OpenAI 템플릿이 자동으로 생성하려는 messages 테이블과 외래 키 충돌을 피하기 위해 테이블명을 sara_messages로 고정한 사례 등이 문서에 포함되어 있다.

Intelligence Database 화면으로 추출된 엔티티 목록과 유형별 집계(UPI ID, 전화번호 등)가 보인다. — Screenshot이 화면은 인텔 테이블이 실질적으로 어떤 값을 저장하는지, 각 엔티티에 대한 Confidence와 세션 출처, 심각도 태그 및 리포트 액션을 함께 보여줘 데이터 모델의 출력 형태를 시각적으로 확인할 수 있게 한다. 저장된 값들은 원문에서 'verbatim values'로 기술된 것과 일치하며 운영자가 직접 검토·리포트할 수 있는 UI 흐름을 담고 있다.

운영 과정에서 발견된 세 가지 주요 실패 모드는 페르소나 드리프트, LLM의 허구 인텔 발명(허위 인텔), 그리고 인텔이 UI로 유출되는 문제였고, 모두 프롬프트 조정만으로 해결되지 않아 엔지니어링 레벨에서 고정됐다. 페르소나 드리프트는 시스템 프롬프트 제약으로 해결되어 항상 혼란스러운 언어 스타일을 유지하게 했고, 허위 인텔 문제는 INTEL 라인에 반드시 사기범의 발언을 인용하도록 요구해 정밀도를 높였다. 인텔 유출 문제는 stripAndExtractIntel 단계에서 INTEL:로 시작하는 라인을 UI에 도달하기 전에 제거하는 방식으로 해결되어 운영상 가시성과 프라이버시 위험을 동시에 관리했다.

text

const INTEL_RX = /\^INTEL:\\s*(\w+)\s+VALUE="([^\"]+)"\s+CONF=(\[\d.\]+)/gm

for (const [full, type, value, conf] of raw.matchAll(INTEL_RX)) {
  intel.push({ type, value, confidence: parseFloat(conf) })
  visible = visible.replace(full, '') // never reaches the UI
}

LLM이 출력한 INTEL 라인에서 타입·값·신뢰도를 정규표현식으로 파싱해 데이터베이스에 저장하고, UI로 노출되는 텍스트에서는 INTEL 라인을 제거하는 추출 및 마스킹 로직이다.

javascript

confidence: z.number().min(0).max(1) .transform(v => Math.round(v * 100)) // every component gets % automatically

Zod 스키마 레벨에서 0.0–1.0 저장값을 퍼센트 정수로 변환해 프론트엔드 컴포넌트 간 신뢰도 표시 방식의 불일치를 해결한 변환 예시이다.

언급된 도구

Hindsight추천

벡터 기반의 의미 메모리 저장소로 세션 간 인텔을 검색·주입하는 용도

CascadeFlow추천

Typed 단계로 요청을 분해하고 실행 트레이스를 제공하는 파이프라인 라이브러리

GPT-4o-mini중립

대화 생성 및 인텔 원천으로 사용된 LLM

Orval추천

OpenAPI 스펙에서 React Query 훅과 Zod 밸리데이터를 자동 생성하는 코드 제너레이터

Zod추천

신뢰도 필드 등 스키마 수준 변환으로 프론트엔드 표시 계약을 일관되게 유지하는 유효성 라이브러리

PostgreSQL + Drizzle ORM추천

원시 채팅과 인텔을 영속화하는 관계형 저장소 및 ORM

언급된 리소스

GitHubSara Agent AI GitHub

javascript

const memories = await hindsight.query({ text : ctx.userMessage, topK : 5, filter: { type: { $in: ['upi', 'phone', 'url', 'bank'] } }, })

javascript

ctx.knownIntel = memories.map(m => `KNOWN INTEL: ${m.type} "${m.value}" seen in ${m.sessionCount} session(s)` ).join('
')

검색된 메모리들을 KNOWN INTEL 블록 형식의 문자열로 합쳐서 LLM의 시스템 프롬프트에 주입하는 로직 예시이다.

export const saraChatPipeline = cascade([ { name: 'validate-session', fn: validateSession }, // ~2ms { name: 'load-session-history', fn: loadSessionHistory }, // ~8ms { name: 'recall-hindsight-memory', fn: recallMemory }, // ~45ms ← vector { name: 'build-system-prompt', fn: buildSystemPrompt }, // ~1ms { name: 'call-openai', fn: callOpenAI }, // ~800ms ← LLM { name: 'strip-and-extract-intel', fn: stripAndExtractIntel }, // ~5ms { name: 'persist-messages', fn: persistMessages }, // ~6ms { name: 'dispatch-webhooks', fn: dispatchWebhooks }, // ~12ms ])

const INTEL_RX = /\^INTEL:\\s*(\w+)\s+VALUE="([^\"]+)"\s+CONF=(\[\d.\]+)/gm for (const [full, type, value, conf] of raw.matchAll(INTEL_RX)) { intel.push({ type, value, confidence: parseFloat(conf) }) visible = visible.replace(full, '') // never reaches the UI }

Sara AI: 세션 간 메모리와 실시간 인텔 추출을 결합한 LLM 허니팟 아키텍처

TL;DR

커뮤니티 반응

주요 논점

합의점 vs 논쟁점

합의점

논쟁점

실용적 조언

섹션별 상세

언급된 도구

언급된 리소스

Sara AI: 세션 간 메모리와 실시간 인텔 추출을 결합한 LLM 허니팟 아키텍처

TL;DR

커뮤니티 반응

주요 논점

합의점 vs 논쟁점

합의점

논쟁점

실용적 조언

섹션별 상세

언급된 도구

언급된 리소스

관련 토론

댓글

관련 피드

관련 토론

댓글

관련 피드