AI 에이전트에게 “알아서 해”라고 말한 뒤, 나는 같은 실수를 세 번 반복했다.

결제 시스템을 PortOne에서 Groble로 바꿨다. 다음 주, 에이전트는 그 사실을 몰랐다. 처음부터 다시 설명했다. 그런데 두 번째도 마찬가지였다. 세 번째는 — 포기했다. 그냥 손으로 했다.

이건 에이전트의 문제가 아니었다. 문제는 나였다. 나는 에이전트에게 “기억해”라고 말하면서, 기억이 어떤 구조로 저장되고, 누가 고칠 수 있고, 어떤 규칙이 지켜져야 하는지 한 번도 생각해본 적이 없었다. 메모장 하나 주고 “알아서 써”라고 한 셈이었다.

메모장이 있는 건, 통제가 없는 것과 같다

AI 에이전트 도구를 쓰는 사람들 중 상당수가 “기억” 해결책으로 메모장(Notion, Obsidian, 심지어 .txt 파일)을 사용한다. 그리고 그 안에서 다음과 같은 일들이 조용히 일어난다:

  • 누구나(어떤 에이전트든) 아무 레이어에나 쓸 수 있다
  • 규칙은 “제안”일 뿐이라 에이전트가 마음대로 덮어쓴다
  • 무엇을 언제 누가 썼는지 추적이 안 된다
  • 어제 쓴 중요한 결정이 오늘 메모장 어딘가에 묻혀 사라진다

기억이 없는 것보다 더 위험한 건 기억이 있지만 통제가 없는 것이다. 에이전트가 규칙을 어기고 싶으면 그냥 덮어쓴다. “이건 중요한 규칙인데”라고 써놓은 문장은 에이전트에게 그냥 문장일 뿐이다.

그래서 나는 질문을 바꿨다. “에이전트에게 뭘 기억시킬까?”가 아니라 “내가 지금까지 쓰는 것 중에서, 실제로 유지되고 있는 게 뭔가?”

진단 먼저: 흩어짐 지도를 그린다

설계를 시작하기 전에, 나는 먼저 진단을 했다. 내 작업 환경에서 기억과 규칙이 실제로 어떤 상태인지 — 흩어짐 지도를 그린 것이다.

진단에서 드러난 것은 three 가지였다:

① 병목 1개: “내일이면 잊는다”

오늘 “결제 시스템을 Groble로 바꿨다”라고 에이전트가 작업했다고 해도, 내일은 그 사실을 모른다. 세션 간 기억이 연결되지 않는다. 매번 처음부터 설명해야 하는 구조. 이게 가장 큰 비용이다.

② 본성 패턴: “익숙한 건 눈이 지나간다”

내 코드에서 isAgent === true라는 결제 우회 플래그가 3주 동안 방치된 적이 있다. 내가 작성했고, 내가 리뷰했고, 내가 배포했다. “원래 있는 코드”라는 익숙함이 나를 blind하게 만들었다. 사람도 아니고 에이전트도 아닌 — 시스템 전체의 사각지대다.

③ 원칙 후보: “설계가 실행에 앞선다”

지금까지 나는 “빨리 만들어보자”는 접근으로 에이전트 시스템을 운영해왔다. 그런데 문제가 생길 때마다 그때그때 고쳤다. 구조적으로 고친 게 아니라 지시문에 한 줄 추가하는 식이었다. 프롬프트가 무거워지고, 에이전트는 그 지시를 건너뛰기 시작했다.

설계 없이 실행은 반복 실패를 낳고, 반복 실패는 신뢰를 잃는다. 이것이 내가 “개인 OS”를 만들기로 결심한 이유다.

설계도 v1: 7레이어를 내 삶으로 번역한다

P-LAYER는 에이전트 기억을 7개 레이어로 나누고, 각 레이어마다 다른 권한과 수명, 검색 우선순위를 거는 구조다. 뇌간(규칙), 변연계(정체성), 해마(기억), 감각(도구), 피질(스킬), 자아(지식), 전전두엽(사고기록). 각각이 에이전트의 기억을 “잡동사니 서랍”이 아니라 “잘 운영되는 조직”처럼 작동하게 만든다.

이걸 내 삶에 번역하면:

P0(규칙): “이건 절대 지키지 않으면 안 되는 것” — 보안 규칙, 접근 권한, 검증 절차. 규칙 변경은 반드시 내가 승인해야만 적용된다. 제안(propose) → 승인(approve) → 적용(apply). 승인 없이는 코드로 거부되고, 거부 자체가 감사 로그에 남는다.

P1(정체성): 어떤 말투로 말할지, 어떤 기준으로 판단할지. “내가 좋아하는 것”이 아니라 “이 시스템이 어떤 기준으로 작동하는지”를 정의한다.

P2(원시 기억): 세션 로그, 날것 그대로. 135,812건의 관찰이 여기서 시작된다. 이건 창고다. 많이 쌓일수록 좋다.

P3(도구): 에이전트가 쓸 수 있는 것들. MCP 서버, API, 스크립트 — 에이전트의 “부서별 공구함”.

P4(스킬): “어떻게 하는지” — 패턴, 절차, 체크리스트. 작업 전에 제일 먼저 보는 매뉴얼.

P5(요약 지식): 135,812건의 관찰에서 13건으로 정제된 교훈. 질문 시 제일 먼저 보는 곳. 전체 세션을 다 읽는 대신, 관련 교훈 한 건(수백 자)만 꺼낸다.

P6(사고 기록): “왜 그랬나” — 근본 원인 분석. 실패가 쌓이면 시스템의 진짜 약점이 드러난다.

왜 7개인가: 3개로 줄이면 안 되나

“원시/가공/규칙으로 3개면 되지 않나”라는 반론이 있을 수 있다. 그런데 실제로 3개로 줄이면 벌어지는 일이 있다:

  • 정체성(P1)과 스킬(P4)처럼 쓰기 주체와 수명이 다른 것들이 같은 규칙 아래 묶인다
  • 요약(P5, 먼저 읽음)과 사고기록(P6, 조사 시만)의 검색 순서가 섞인다
  • 같은 저장소인데 레이어별로 다른 규칙을 거는 것 — 그게 7개를 유지하는 이유다

정직한 한 줄: “정확히 7개”는 설계 선택이고, 원칙은 거버넌스가 다른 기억은 분리한다는 것. 7은 뇌/조직 구조에 대응하는 실용적 세분화다.

실전에서 이 구조가 어떻게 작동하는가

지난 5개월 동안 Drewgent는 이 7레이어 구조 위에서 운영되었다. 숫자로 말하면:

  • 관찰 135,812건이 P2(원시 기억)에 축적되었다
  • 그중 13건이 P5(요약 지식)로 승격되었다 — 압축률 0.0096%
  • 에이전트가 질문할 때 전체 세션을 다 읽는 대신, 관련 교훈 1건(수백 자)만 꺼낸다
  • 거버넌스 ACL 30/30 (pass_rate 1.0) — 7레이어 × 쓰기 주체 전 케이스가 코드로 강제된다

이게 비용을 아끼는 이유는 단순하다: 135,812건의 세션 로그를 매번 읽는 건 수십만 토큰이다. 교훈 1건을 읽는 건 수백 자다. 관찰을 교훈으로 증류하는 압축이 곧 토큰 효율이다.

“지켜지는 규칙”vs”쓰여만 있는 규칙”

P-LAYER의 가장 중요한 차별점은 P0 승인 게이트다.

일반 메모리 도구의 규칙은 “써놓은 것”일 뿐이다. 에이전트가 규칙을 어기고 싶으면 그냥 덮어쓴다. P-Layer는 규칙을 구조적으로 지키게 만든다:

누군가 규칙을 바꾸고 싶으면 → propose (제안서 작성) → approve (사람이 승인 — 여기가 관문) → apply (승인된 제안만 온톨로지에 반영) → deprecate (더 이상 안 쓰는 규칙 폐기)

승인 없이는 적용이 코드로 차단된다. 제안서가 아무리 좋아도 approved가 아니면 시스템이 거부한다. 거부조차 감사 로그에 남는다. 온톨로지 파일이 한 줄이라도 깨지면 시스템이 검증에서 걸러낸다 — “조용히 망가지는” 일이 없다.

기억의 건강검진: drift-report

기억 시스템을 만들었다고 끝나지 않는다. 매주 시스템이 지난주와 얼마나 달라졌는지 비교해야 한다.

drift-report는 지식·에피소드·엔티티·규칙 수를 baseline과 비교한다. 변화가 기준(±30%)을 넘으면 알려준다. “아무 일도 없다”는 것과 “죽었다”는 것은 다르다.

이건 기억의 건강검진이다. 규칙이 쌓여있으면서 아무도 읽지 않는 상태, 기억이 쌓여있으면서 검색이 안 되는 상태 — 이런 것들을 잡아내는 메커니즘이다.

당신의 워크플로우에 적용하는 법

“이게 나한테 맞나”라고 생각하는 사람에게, 먼저 한 가지 제안을 하고 싶다. 설계부터 하지 말고, 진단부터 하라.

  1. 흩어짐 지도를 그려라 — “내가 지금 쓰는 도구 중에서, 내일도 살아남는 기억은 몇 개인가?” 한 주 동안 에이전트에게 “어제 뭐 했는지 기억해?”라고 물어보라. 답이 없다면, 그게 병목이다.
  2. 병목 1개를 잡아라 — “기억이 없어서”인지, “기억이 있지만 검색이 안 되는지”, “기억이 있지만 규칙이 안 지켜지는지”. 가장 아픈 것을 먼저.
  3. 작게 시작하라 — pip install p-layers 하나면 2분 안에 끝난다. P0 규칙 게이트 하나만 걸어도, 에이전트가 규칙을 덮어쓰지 못하는 구조가 만들어진다.

2분 설치:

pip install p-layers
export P_LAYER_DB=~/.p_layer/memory.db
p-layer remember "결제 시스템은 Groble로 바꿨다" --type decision
p-layer recall "결제"

설계가 실행에 앞선다는 것

5개월 동안 Drewgent를 운영하면서 배운 가장 중요한 교훈이다. “빨리 만들어보자”는 접근은 반복 실패를 낳고, 반복 실패는 신뢰를 잃는다. 반면 진단 → 설계 → 소규모 실행 → 검증의 순서는 비록 느리지만, 한 번 만든 구조가 오래 살아남는다.

에이전트가 내 일을 대신하기 시작한 지금, “누가 규칙을 바꾸는가”는 도구의 문제가 아니라 조직 설계의 문제다. 메모장에 규칙을 써놓는 건 — 그게 에이전트가 읽을 수 있는 메모장이든, 사람이 읽을 수 있는 메모장이든 — 결국 규칙이 아니다. 지켜지는 구조를 만드는 것만이 규칙이다.

규칙이 지켜지는 기억은, pip install p-layers로 시작한다.

근거 출처

상호작용(에이전트-드루 대화·작업):

  • P-LAYER 7레이어 기억 구조 설계 및 5개월 실운영 (Drewgent v0.7.x, 관찰 135,812건, 교훈 13건 승격)
  • P0 승인 게이트 구현 (propose → approve → apply 흐름, ACL 30/30 통과)
  • LongMemEval 벤치마크 자체 실행 — session recall@10 0.9511(기본) / 0.9894(bge-m3), 기권 정확도 0.9333
  • isAgent bypass 패턴 발견 및 Fresh-Eye 시스템 구축 사례
  • drift-report 기반 주간 기억 건강 모니터링

외부 정보:

  • P-LAYER PyPI 패키지: pip install p-layers (v0.7.4, 2026-08-15 배포)
  • GitHub: humanerd-drew/p-layer — 158개 자동 테스트 통과 (SQLite + PostgreSQL 패리티)
  • LongMemEval: CMU, ICLR 2025, 500문항 벤치마크 (xiaowu0162/LongMemEval)