7월 14일 박민재 멘토님 정리본

문서 정보

• 원본 메모: [[7월 14일 박민재 멘토님]]
• 정리본 작성일: 2026-07-15
• 멘토링 일자: 2026-07-14
• 멘토: 박민재 멘토님
• 참석자: 원본에 미기록
• 관련 프로젝트/주제: SLM 메모리 구현, rule-based 처리, fallback UX, 경진대회 루프 엔지니어링, 클라우드/IaC 관점
• 관련 문서: [[6월 23일 박민재 멘토님 정리본]], [[7월 14일 박재선 멘토님 정리본]]
• 상태: 초안

한 줄 결론

SLM 기반 메모리 구현은 처음부터 거대한 자연어 그래프를 만들기보다, 범위를 좁힌 정형 테이블과 rule-based 전처리/후처리를 중심으로 시작해야 한다. LLM은 애매한 감성 표현, 키워드 추출, memory parser/resolver 같은 비결정적 영역에 제한적으로 쓰고, 제품 품질은 모델의 똑똑함보다 방어적 fallback과 루프 설계로 보완해야 한다.

회의 맥락

• 이번 멘토링은 메모리 구조를 실제로 어떻게 구현할지, SLM의 한계를 제품 UX에서 어떻게 다룰지, 그리고 경진대회/연구 루프를 어떻게 설계할지에 초점이 있었다.
• 멘토링 전 기준 가설은 SLM memory layer를 episode, semantic, pattern 등으로 나누고, 압축/리트리벌/프루닝 방법을 설계하는 것이었다.
• 멘토링 후 바뀐 관점은 메모리 문제를 곧바로 GraphRAG나 거대한 자연어 구조로 확장하기보다, 먼저 정형 DB, regex, rule-based gate, fallback 문구, local validator 같은 결정론적 장치를 강하게 두는 쪽이다.
• 원본은 빠른 대화 메모이므로 일부 표현은 개념 단서로만 취급하고, 확정 설계는 별도 메모리 문서에서 다시 검증해야 한다.

핵심 피드백

영역	멘토 피드백	해석	우선순위
메모리	범위와 dimension을 좁혀서 table memory부터 생각한다.	MVP에서는 취향, 이벤트, 패턴을 무리하게 하나의 자연어 그래프로 묶기보다 typed table/schema로 관리한다.	High
메모리	취미/선호 같은 정보는 표 형태와 hybrid 접근이 가능하다.	정형 정보는 DB에 넣고, 감성적 표현이나 애매한 문장은 LLM이 보조하는 구조가 적합하다.	High
모델	결정론적인 tool과 rule-based 처리를 최대한 활용하는 것이 유리하다.	SLM은 작은 모델이므로 모든 판단을 모델에 맡기지 않고 regex, keyword, parser, validator를 앞뒤에 둔다.	High
메모리 파이프라인	memory parser와 memory resolver를 거쳐 JSON 답을 만드는 구조를 고려한다.	대화 원문을 바로 저장하지 않고, 후보 추출과 충돌 해결 단계를 분리한다.	High
Fallback	폴백 설계를 잘해야 하고 방어적인 로직이 제품 품질에 중요하다.	기억 실패, 확신 부족, 가이드북 밖 질문을 캐릭터 UX로 자연스럽게 처리해야 한다.	High
UX	"잠깐만 생각해볼게" 같은 반응은 메모리 압축/검색 시간을 벌 수 있다.	시스템 지연을 숨기기보다 캐릭터의 사고/회상 행동으로 표현하면 자연스럽다.	Medium
비용/리밋	실제 과금이 없더라도 context와 사용량에는 리밋이 필요하다.	무제한 대화·무제한 retrieval은 품질과 성능을 해치므로 quota와 회수 제한을 설계한다.	Medium
평가/실험	논리 전개, 실험, 로컬 검증기, 미리 cut-off를 둬야 한다.	실험을 무작정 돌리지 말고 baseline, local validator, 중단 기준, 다음 리서치 경로를 명확히 둔다.	High
경진대회	AI는 정석과 생산성에는 강하지만, 비대칭적 선택과 과감한 steering은 사람이 해야 한다.	자동화 에이전트에게 탐색을 맡기더라도 방향 설정, 희생할 것과 얻을 것을 정하는 판단은 사람이 잡는다.	Medium
하네스	전체 지도, 시작점, 목적지를 주고 루프를 설계해야 한다.	agent loop는 brute-force가 아니라 관찰, 검증, 방향 수정이 가능한 harness로 설계해야 한다.	High
클라우드	콘솔 수작업보다 MCP/agent call, IaC, config 중심 패러다임을 이해해야 한다.	AWS 상품명보다 네트워크, DB, 메시지 큐, S3, 거버넌스, IaC 같은 기본 개념을 잡는 것이 장기적으로 남는다.	Medium

결정 사항

• 메모리 구현은 typed table/schema 중심으로 시작한다.

  • 근거: 원본에서 "범위 디멘션을 좁혀서 테이블 메모리", "정형화 데이터베이스에 때려박아도 구현은 가능"하다는 방향이 반복됐다.
  • 영향: Memory Layer 문서에서는 GraphRAG보다 SQLite/CoreData 기반 typed memory, FTS/vector 보조 index, rule-based gate를 우선 설계한다.

• LLM은 애매한 감성·의도·키워드 추출에 제한적으로 사용한다.

  • 근거: "맛이 안사는데? <- 이런걸 LLM", "SLM을 먼저 찔러 -> 키워드 추출"이라는 단서가 있다.
  • 영향: preference, event, pattern처럼 명확한 입력은 규칙으로 처리하고, 애매한 표현만 LLM 후보 추출에 맡긴다.

• memory parser와 memory resolver 단계를 분리한다.

  • 근거: 원본에 "memory parser -> memory resolver -> json답"이 구조 단서로 남아 있다.
  • 영향: parser는 대화에서 후보를 추출하고, resolver는 기존 memory와 충돌/중복/확신도를 판단하는 역할로 나눈다.

• fallback UX를 제품 기능으로 다룬다.

  • 근거: "폴백 설계를 잘해야한다", "방어적인 로직도 잘 짜야한다", "프로덕트 퀄리티에 더 중요함"이라는 피드백이 있었다.
  • 영향: "기억이 안 난다"를 단순 오류로 내보내지 않고, 캐릭터 말투와 회상 지연, 가이드북 밖 응답으로 처리한다.

• 경진대회/실험 루프는 local validator와 cut-off를 먼저 둔다.

  • 근거: "논리전개 -> 실험 -> 로컬 검증기 평가기 -> 미리컷"이라는 흐름이 원문에 있다.
  • 영향: 모델/엔진 최적화 실험은 실험 전 평가기, 종료 기준, 실패 시 다음 리서치 경로를 정의한다.

보류 사항

• 자연어 GraphRAG 기반 메모리

  • 이유: 구현 가능성은 있지만, MVP에서는 메모리 volume과 retrieval 비용이 커질 수 있다.
  • 다시 판단할 조건: typed memory와 rule-based retrieval로 부족한 사례가 쌓이고, 관계 추론이 실제 기능 요구사항으로 확인된 뒤.

• SLM 기반 전체 메모리 판단 자동화

  • 이유: SLM은 작고 확률적이므로 모든 분류·충돌 해결·검색 판단을 맡기면 품질이 흔들릴 수 있다.
  • 다시 판단할 조건: rule-based baseline을 만든 뒤, LLM을 넣었을 때 precision/latency/UX가 개선되는지 비교한 뒤.

• GPU cloud와 agentic infra 운영 방식

  • 이유: 최신 트렌드로는 중요하지만, 현재 앱 MVP의 직접 구현 과제는 아니다.
  • 다시 판단할 조건: 서버 학습/평가 자동화, 모델 변환/배포 pipeline이 실제 병목이 된 뒤.

• vLLM 이슈 기반 엔진 패치 탐색

  • 이유: 경진대회나 성능 최적화에는 유효할 수 있으나, 현재 프로젝트의 앱 MVP와는 우선순위가 다를 수 있다.
  • 다시 판단할 조건: 특정 inference bottleneck이 재현되고, upstream issue/patch에서 유사 사례를 찾을 수 있을 때.

액션 아이템

작업	담당	산출물	기한	상태
메모리 typed schema 재정리	모델/메모리 담당	episodic, semantic, pattern, working memory별 table/schema 초안	미정	Todo
rule-based memory gate 설계	모델/메모리 담당	일정/선호/패턴/일반대화 분류 regex·keyword·classifier 우선순위	미정	Todo
memory parser/resolver 인터페이스 작성	모델/메모리 담당	parser output JSON, resolver conflict policy, confidence 필드	미정	Todo
fallback UX 문구 작성	기획/앱 담당	기억 실패, 애매한 질문, 가이드북 밖 질문, 검색 지연 상황별 캐릭터 응답	미정	Todo
retrieval/압축 지연 UX 설계	앱/모델 담당	"잠깐만 생각해볼게" 등 회상 연출과 실제 처리 타이밍 매핑	미정	Todo
context/retrieval 리밋 정의	모델/앱 담당	turn limit, retrieval top-k, LLM call budget, fallback 기준	미정	Todo
실험 루프 하네스 설계	모델/평가 담당	baseline, local validator, cut-off, 다음 리서치 경로를 포함한 실험 템플릿	미정	Todo
클라우드 기본 개념 정리	인프라 담당	IaC, 네트워크, DB, 메시지 큐, S3, GPU cloud/MCP 관점 요약	미정	Todo

후속 질문

• Memory Layer MVP에서 table로 관리할 최소 필드는 무엇인가?
• semantic preference와 episodic event를 rule-based로 즉시 감지할 때 false positive를 어디까지 허용할 것인가?
• memory parser는 LLM이 담당하고 resolver는 rule/SQL이 담당하는 구조가 적합한가?
• 사용자가 "전에 말했는데 기억 안 나?"라고 했을 때 몇 초까지 회상 지연 UX가 자연스러운가?
• fallback 문구는 캐릭터의 귀여움으로 처리할 것인가, 기능적 안내로 처리할 것인가?
• 실험 루프에서 사람이 반드시 steering해야 하는 지점은 어디인가?
• cloud/IaC 학습은 현재 서버 구현과 어떻게 연결할 것인가?

원문 근거

• "범위 디멘션을 좁혀서 테이블 메모리"

  • 정리 해석: 메모리 설계는 처음부터 거대한 구조보다 좁은 typed table에서 시작한다.
  • 확실성: 높음

• "표 테이블 형태 - 취미 무엇, Hybrid 접근. 감성의 영역. 정보 - 정형 구조 작성. Regex. 전처리, 후처리."

  • 정리 해석: 정형 정보는 DB/regex로 처리하고 감성적 영역은 LLM 보조를 붙이는 hybrid 접근이 적합하다.
  • 확실성: 높음

• "결정론적인 툴을 최대한 활용하는게 무조건 유리하다"

  • 정리 해석: SLM 환경에서는 rule-based, SQL, regex, validator 같은 결정론적 도구를 최대한 활용해야 한다.
  • 확실성: 높음

• "memory parser -> memory resolver -> json답"

  • 정리 해석: memory candidate extraction과 conflict/merge resolution을 분리하는 파이프라인이 필요하다.
  • 확실성: 중간

• "폴백 설계를 잘해야한다. 방어적인 로직도 잘 짜야한다. 프로덕트 퀄리티에 더 중요함."

  • 정리 해석: fallback은 예외 처리가 아니라 제품 품질의 핵심이다.
  • 확실성: 높음

• "나 저번에 말했는데 기억안나? 어 잠깐만 생각해볼게"

  • 정리 해석: 메모리 검색/압축 지연을 캐릭터 회상 행동으로 자연스럽게 처리할 수 있다.
  • 확실성: 중간

• "논리전개 -> 실험 -> 로컬 검증기 평가기 -> 미리컷 -> 다른 리서치"

  • 정리 해석: 실험 루프는 평가기와 중단 기준을 먼저 포함해야 한다.
  • 확실성: 높음

• "전체 지도를 알고 시작점과 목적지를 알면 좋다"

  • 정리 해석: agent/harness loop에는 목표, 경로, 검증 기준이 필요하다.
  • 확실성: 높음

• "IaC. (코드형인프라)"

  • 정리 해석: 콘솔 수작업보다 인프라를 코드/config로 관리하는 관점이 필요하다.
  • 확실성: 중간

정리에서 제외한 내용

• 원문의 강한 표현과 농담성 문장은 프로젝트 의사결정에 필요한 의미만 남기고 그대로 옮기지 않았다.
• "멍청하니까 재밌죠?", "난 바보야 응애" 등은 캐릭터 fallback 아이디어의 분위기 단서로만 보고 본문에는 직접 반영하지 않았다.
• GPU cloud 업체명과 최신 트렌드 단서는 아직 비교 근거가 부족해 액션 아이템의 조사 후보로만 남겼다.
• SageMaker 관련 언급은 "managed service는 결국 config와 자동화 생산성을 제공한다"는 큰 의미만 남기고 세부 평가는 제외했다.
• 회사 보안/거버넌스 관련 언급은 일반적인 클라우드 운영 제약으로 해석하되, 현재 프로젝트의 확정 정책으로 옮기지 않았다.

최종 반영 위치

• 기획 문서: fallback UX, 캐릭터식 기억 실패/회상 연출, 사용량 리밋에 대한 사용자-facing 표현
• 모델 레이어: SLM을 보조 판단기로 제한하는 memory parser, keyword extraction, confidence handling
• 메모리 레이어: typed table schema, rule-based gate, parser/resolver, pruning/retrieval 리밋
• 앱 레이어: "잠깐만 생각해볼게" 같은 회상 지연 UI/UX, fallback state
• 평가/실험: local validator, cut-off, harness 기반 실험 루프
• Linear 이슈: 메모리 구현법 고도화, fallback UX 설계, 실험 루프 하네스 설계에 연결 가능

다음 업데이트

• Memory Layer 문서에 typed schema와 rule-based gate가 반영되면 이 정리본의 결정 사항과 연결한다.
• fallback UX 문구가 캐릭터 컨셉과 맞춰지면 기획 문서에 반영한다.
• 실험 루프 하네스가 만들어지면 원문의 "루프 엔지니어링" 관점을 평가/실험 문서로 분리한다.