검증된 경험을
다음 행동으로.
AEM은 과거 작업의 결과와 사용자 교정을 기억하고, 다음 작업에서 쓸 근거와 절차를 연결하는 로컬 에이전트 보조 엔진.
바꾸는 대상은 모델의 가중치가 아니라,
모델이 참고하는 기억과 작업 방식.
현재 코드·문서 확인 기준: 2026.09.19
실시간 운영 감사나 새로운 성능시험과는 구분.
완성된 범용 자기개선 모델이라는 의미는 아님.
- 경험을 남기기
성공·실패·사용자 교정과 당시 조건의 기록.
- 맞는 근거를 찾기
현재 프로젝트·요구조건에 맞는 기억의 선택.
- 적용 결과를 확인하기
실제 사용한 버전과 객관적 검사 결과의 연결.
보여 준 기억, 사용한 기억, 효과가 입증된 기억의 구분.
입력에서 다음 행동까지,
검증으로 이어지는 연결.
실행하는 AI 옆에 놓인 검증 기록부. 어떤 기억을 봤는지뿐 아니라, 실제로 적용했는지와 결과까지 남기는 구조.
채택·버전·증거가
결속된 적용 경험
문제·미확인 상태 기록
수정 시 새 버전 검증
작업 범위와 프로젝트 확인
사용자 요청, 정규화된 작업 폴더 신원, 요구조건으로 작업 경계 설정. 대화·도구 관찰은 정제 후 기록.
유효한 기억과 과거 사례 조회
현재 범위에 맞는 지시·검증 경험·허용된 교정 후보 검색. 관련성이 부족하면 기억 없이 진행하는 판단도 가능.
작업 전략·채택·검증 방법 고정
빠른 처리·점검·계획·질문 중 전략 제안. 호스트가 실제 채택한 기억 버전과 검사 명령을 기록. 변경 작업의 검증은 첫 변경 전에 선언.
허용된 실제 작업 수행
AI와 도구를 실행하는 호스트가 권한을 유지. 작업 단위인 Episode에 행동·변경·상태 버전을 연결.
별도 검사로 결과 확인
모델의 성공 주장 대신 선언된 검증 명령의 실행 결과 사용. 검사기·산출물·작업 버전이 달라졌다면 이전 성공의 재사용 거부.
성공·실패를 다음 판단에 반영
검증된 경험 축적, 실패한 교정 버전 제외, 더 신중한 전략으로 후퇴. 수정 후보는 새로운 버전으로 재검증.
이 흐름을 받치는 저장층
- 쓰기 창구 · broker
- 허용된 쓰기를 공통 검증 경계로 모으는 전용 프로세스.
- 기준 원장 · SQLite canonical v2
- 사건·출처·버전·검증 결과의 원본. 학습 판단의 기준 장부.
- 조회용 사본 · snapshot / index
- 빠르게 읽기 위한 파생 자료. 원장을 대신하는 별도 진실이 아닌 구조.
- 감사 기록 · outbox → JSONL
- 원장에 확정된 사건을 나중에 내보내는 감사용 사본.
검증된 다음 경험도 같은 쓰기 경계로 환류. 검색 순위가 높아졌다는 이유만으로 권위 상승 불가.
위 순서도는 공통 원리. 일반 대화 훅과 개인 SDK의 기능 범위는 아래처럼 구분. 모든 입력에서 전체 학습 순환이 자동 완성되는 구조는 아님.
같은 기반 위의
세 가지 연결 경로.
코드에 존재하는 기능과 기본으로 켜진 기능의 구분. 특히 개인 SDK의 확장 기능을 일반 대화 전체의 동작으로 해석하지 않을 것.
기억 훅
관찰·정제 → v2 우선 검색 → 작업 전략 자문 → 적용·검증 연결
대화와 작업 도구의 접점에서 기억을 제공하고 작업 기록을 연결. 검색 신뢰도가 낮으면 억지로 후보를 채우지 않는 방식.
설치형 훅의 현재 v2 우선 경로 기준. 오래된 v1은 명시적 조회의 참고 후보이며 자동 문맥 주입에서 제외. 일반 대화에 추가 사례 검색·조건 질문 루프가 자동 설치된 상태는 아님.
개인 SDK / CLI
작업 시작 → 근거 조회 → 실제 응답 → 독립 검사 → 결과 기록
프로젝트별 빈 기억에서 시작하는 독립 실행 경로. 모델·도구·검사기를 제공하는 프로그램이 호스트 역할 담당.
CLI 기본: one-call + evidence-guided.
SDK 기본: compatible. SDK에서 근거 중심 프로필은 명시적 선택 필요.
개선 정책 후보
검증 사례 → 절차·검색 후보 → 별도 비교 → 호스트가 선택
기존 SDK 경로에 learningPolicy를 전달해 사용하는 실험 확장. 검색 방식·처음 보여 줄 사례 수·추가 검색 묶음의 조절.
후보를 빼면 기존 경로로 복귀. 자동 후보 생성부터 운영 승격까지의 무인 순환은 미구현. 기존 기본 프로필의 일괄 전환도 없음.
기술 구분 · 일반 도구 작업과 JSON 결과 작업
도구를 쓰는 일반 작업은 begin → apply → action → verify → close 경로. 되돌릴 수 있는 JSON 결과 작업은 runTask 경로. 조건 확인 기능은 호스트가 연결한 one-call runTask에서 제공하며, 낮은 수준의 begin 호출에 자동 부착되지 않는 구조.
one-call은 선택과 답안 초안을 함께 받는 프로토콜의 이름. 추가 검색·조건 질문이 발생하면 모델 호출 수는 증가 가능. 항상 한 번의 호출로 끝난다는 보장은 아님.
정보가 부족할 때,
더 찾을지 물을지의 구분.
기억 속에 있는 정보라면
- 현재 조건과 가까운 사례부터
관련 사례, 최근 성공, 대조할 실패를 출발점으로 선택. 일부 사례만 보여 주는 것과 원본 기록을 지우는 것은 별개.
- 구분에 필요한 근거를 추가 조회
근거 중심 프로필에서 부족한 조건과 검색 이유를 요청. 기본 추가 검색은 최대 3회, 3·6·12개 묶음. 한도는 충분성 보증이 아닌 비용·범위 제한.
- 옛 조건은 참고로만
허용된 과거 요구조건의 사례는 미확인 참고로 구분. 과거 성공을 현재 요구사항으로 강제하지 않는 방식.
기억 자체에 없는 정보라면
설명용 가상 예
금액을 반올림할지 버릴지에 대한 사용자 조건이 없는 상황. 비슷한 작업을 더 찾는 것과 현재 사용자의 선택을 확인하는 것은 다른 문제.
호스트가 conditionAccess를 연결한 경우에만, 미리 허용한 항목을 실제 사용자에게 확인. 작업당 최대 2개의 질문.
확인 값은 같은 프로젝트·작업군·문맥·조건 버전에서, 유효기간과 검증 결과를 확인한 뒤 재사용. 거절·오류·시간 초과라면 확인 필요 상태로 종료.
사용자의 답도 틀릴 수 있는 관찰값. 통과한 작업에 쓰였다는 사실이 그 답의 진실성까지 보증하지는 않음.
기술 구분 · 일반 기억 검색과 사례 검색
기억 검색은 단어·문장·학습 내용의 다중 단서 인덱스가 기본. 희소 검색이 불확실할 때 버전 고정 의미 인덱스 사용. 명시적 문맥이 있을 때만 파생 그래프의 한 단계 연결로 후보 보충.
개인 SDK의 사례 검색은 기존 작업·검증 사건을 재사용. 현재 구현의 후보 풀은 작업군별 최근 512개로 제한. 선택형 문맥 검색은 허용된 prompt·feedback·context의 희소 단어를 활용하며, 저장하지 않은 원문을 복원하거나 다른 프로젝트의 자료를 가져오는 기능은 아님.
저장량보다 중요한,
출처·상태·범위의 구분.
관찰과 분류
입력·도구 결과·사용자 교정을 관찰. 훅의 수집·분류·체크·보존 상태를 하나의 사건에 결속.
원장에 확정
프로젝트 신원과 상태 전이를 검사한 쓰기만 SQLite 트랜잭션으로 확정. 같은 사건의 중복 학습 방지.
조회와 감사로 분리
검색용 snapshot·index는 다시 만들 수 있는 파생 자료. JSONL은 outbox를 통해 내보낸 감사 사본.
설치형 훅의 관찰 기록
원문 대화 전체 대신 민감정보를 제거한 압축 요약과 메타데이터 보존. 민감 입력은 내용 없는 메타데이터만 유지.
이미 Episode에 결속된 도구 행동은 해당 행동 사건으로 대표. 별도의 관찰 사건을 복제하지 않는 방식.
개인 SDK의 작업 사례
호스트가 제공한 제한된 작업 입력·결과·검증 피드백 보존. 허용 범위 안에서 성공한 출력도 다시 참고할 수 있는 구조.
훅의 대화 요약 정책과 동일하지 않은 저장 경로. 민감자료를 입력하지 않는 호스트 설계 필요.
표를 좌우로 밀어 전체 내용을 확인.
| 상태 축 | 확인할 질문 | 의미 |
|---|---|---|
| 출처 | 어디에서 왔을까? | 사용자 지시·자체 기록·레거시 가져오기 등 기원 보존 |
| 증거 수준 | 무엇이 확인됐을까? | 지시 존재의 확인과 실행 효과 검증의 분리 |
| 생애 상태 | 지금 참고해도 될까? | 후보·재검증·활성·격리·폐기 상태 구분 |
| 적용 범위 | 어디까지 쓸 수 있을까? | 프로젝트 또는 명시적으로 승인한 신뢰 도메인 |
기술 구분 · writer, 프로젝트 저장소, 기록 끄기
전용 writer는 항상 켜진 서버 하나가 아니라 쓰기 요청마다 실행하는 broker 하위 프로세스와 SQLite 트랜잭션의 조합. 같은 OS 사용자 권한을 가진 악성 프로세스까지 막는 보안 격리라는 의미는 아님.
설치형 훅의 원장은 프로젝트 신원으로 기록을 구분. 개인 SDK는 기본적으로 각 프로젝트의 로컬 저장소에서 시작. 서로 다른 사람·조직·신뢰 도메인에는 별도 저장소와 실제 접근권한 경계 필요.
memory:false는 기억 참고를 끄는 설정이며 저장 중단과는 구분. learn:false는 새 학습 credit·승격·후속 학습 이용을 막지만 작업·검증 사건 자체는 남기는 방식. 저장이 필요 없는 제품은 호스트의 연결·보존 정책에서 별도 제어 필요.
스스로 바꾸는 범위는
기억과 절차, 그리고 전략.
성공한 결과와 실패한 결과를 모두 비교 재료로 사용. 검증된 사례를 다시 찾는 것, 절차 후보를 만드는 것, 후보를 운영에 채택하는 것은 서로 다른 단계.
기존 행동교정 경로
- 구체적인 교정 후보
사용자 교정·실패·복구 기록에서 조건, 수행 절차, 확인 방법을 가진 후보 생성.
- 적용한 버전에만 결과 연결
노출만으로 효과를 인정하지 않으며, 서로 다른 작업에서 적용·검증을 거친 버전만 상태 조정.
- 실패 후 격리와 새 검증
실패·출처 철회·검증 후 변경 시 해당 교정 버전 제외. 수정 버전이 과거 성공을 자동 상속하지 않는 구조.
근거 중심 evidence-guided 프로필은 자동 생성 절차와 자동 복기를 기본적으로 끔. 실제 사용자 지시와 검증 사례는 유지. 훅과 호환 프로필의 교정 경로가 삭제된 것은 아님.
선택형 통합 개선 정책
- R · 문맥 검색
허용된 사례의 입력·피드백·문맥으로 더 적절한 근거 선택.
- P · 경험 기반 후보
출처가 결속된 검증 사례를 재료로, 새로운 절차 후보를 만들고 별도 작업에서 시험.
- D · 검색 정책 비교
처음 보여 줄 사례 수와 추가 검색량을 유한 후보로 비교. 평가 전에 선택 고정.
새 엔진·새 원장 없이 기존 SDK와 검증 경계 재사용. 모델 가중치 훈련, 무제한 코드 자기수정, 관측하지 않은 대안의 정답 추정은 제외.
후보 생성과 운영 승격 사이에 남아 있는 사람·호스트의 선택.
명시적 learningPolicy 전달로만 사용. 후보 ID별 성과 이력 분리, 출처 철회 시 사용 중단. 평가에서는 학습을 끄고 기준 시점을 고정.
기술 구분 · 성공 횟수와 학습 권위
행동교정의 서로 다른 두 작업 성공은 active/observe 자문 상태의 조건. 일반화 제어 정책은 완전히 결속된 독립 작업·변경의 성공 4건을 요구. 서로 다른 규칙이며, 어느 쪽도 인과적 개선의 통계적 증명이나 실행 권한 발급이 아님.
통합 후보의 policyCredit:false는 후보 노출에 lesson 채택 credit을 주지 않는다는 뜻. 학습이 켜졌다면 검증된 작업 결과는 해당 후보 버전의 제어 이력에 반영 가능. 후보를 봤다는 사실과 그 후보 때문에 좋아졌다는 주장의 구분.
기억은 행동을 제안할 뿐,
권한을 만들지 않는 구조.
표를 좌우로 밀어 전체 내용을 확인.
| 경계 | 현재 방식 | 남는 한계 |
|---|---|---|
| 실행 권한 | 사용자 요청과 호스트 권한 안에서 전략 제안 | 기억·모델이 승인이나 실행 범위를 새로 만들 수 없음 |
| 검증 증거 | 사전 선언한 명령·검사 파일·변경·작업 버전 결속 | 잘못된 검사기·미선언 의존성·침해된 호스트는 별도 대책 필요 |
| 출처와 철회 | 출처·버전·범위 유지, 무효화된 근거 사용 중단 | 그럴듯한 기록과 사실의 진실성은 같은 개념이 아님 |
| 원장·snapshot | 게시 ID·sequence·내용 해시의 일치 확인 | 원장·게시 근거 확인 불가 시 쓰기·학습 중단, 권위 없는 참고 읽기만 허용 |
| 사용자 간 격리 | 프로젝트 신원과 적용 범위 검사 | 같은 OS 사용자의 폴더 분리만으로 보안 격리 보장 불가 |
검사 통과는 해당 작업의 결과 증거.
기억의 추가 효과, 장기적 개선, 모든 사용자에게의 이득은 별도의 비교 대상.
현재 확인된 이득은
조건부 속도 개선.
최신 통합 비교에서는 같은 정답 수를 유지하면서 처리시간 감소. 다만 토큰 사용량 증가와 준비 비용이 함께 남은 결과.
표를 좌우로 밀어 전체 내용을 확인.
| 평가 항목 | 기존안 | 전체 통합 R/P/D |
|---|---|---|
| 최초 시도 통과 | 50 / 50 | 50 / 50 |
| 처리시간 합계 | 680.15초 | 554.97초 |
| 보고 토큰 합계 | 549,734 | 706,613 |
| 변화 | 기준 | 시간 −18.4% · 토큰 +28.5% |
표는 전체 통합과 기존안의 비교에 한정. 같은 평가에는 문맥 검색 단독 조건도 포함됐으며, 해당 조건은 실질적 이득 미확인. 통합안의 결과를 기본 동작 전체의 성능으로 해석하지 않을 것.
이 결과가 보여 주는 것
두 합성 작업 흐름의 제한된 표본에서 관측한 속도·토큰 교환관계. 최신 구조의 선택형 후보가 빠르게 풀 수 있었던 조건의 확인.
이 결과가 증명하지 못한 것
기존안도 전부 맞힌 표본이므로 추가 정확도 향상은 미관측. 장기 개인화, 다양한 실제 업무, 모든 사용자에게의 효과, 범용 자기개선은 미입증.
50개 입력은 50회의 독립 연구가 아닌 두 합성 흐름의 작업 묶음. 조건 응답은 즉시 정확히 답하는 모의 사용자. 후보 생성·개발 비교 비용까지 포함하면 이 한 묶음으로 준비 비용 회수에 미달. 실제 사용자 지연·오답·질문 피로는 별도 검증 필요.
현재 AEM은 개선을 시험하고,
검증된 경험을 재사용하는 기반.
누구에게나 효과적인 자기개선은
앞으로 증명할 과제.