남의 지식 운영체계(AKM)를 내 프로젝트에 이식해 봤더니, 없는 건 자료가 아니라 "분류 기준"이었다

소개

시도하고자 했던 것

지피터스에 올라온 AKM(Agent Knowledge Management) 사례글을 읽고, 그 7레이어 구조를 제 프로젝트에 그대로 적용해 봤습니다. 결과물은 「韓바둑 AKM 적용 설계서 v1.0」(15장·표 15개)입니다.

왜 했는가

저는 전통 명리학 4관법(탈XX 계통)을 AI 컨설팅 시스템으로 구현하는 프로젝트를 2년째 하고 있습니다. 규모는 이렇습니다.

자료는 넘치는데 매 세션 같은 설명을 반복하고 있었습니다. AKM 글의 첫 문장 — "지식이 없는 것은 아니었습니다. 오히려 지식이 여러 장소에 너무 많이 있었습니다" — 가 제 상황 그대로였습니다.

특히 뜨끔했던 대목이 "문서가 늘어날수록 메모리는 오히려 줄였다" 입니다. 저는 반대로 하고 있었습니다. DB 접속 명령, 워드 행간값(276 DXA), PDF 색상 감지 범위, scp 경로까지 전부 AI 메모리에 넣어 두고 있었습니다.

진행 방법

3-1. 사용한 프롬프트 전문

이번에도 프롬프트는 두 줄입니다. 원문을 첨부하고 이렇게만 물었습니다.

[1단계 — 진단 요청]
첨부자료 내용을 내 프로젝트에 적용하는 방법은?

[2단계 — 문서화 요청]
「韓바둑 AKM 적용 설계서 v1.0」 문서로 만들어 줘.

짧은 프롬프트가 통한 이유는 프로젝트 지식에 이미 다음이 상주해 있었기 때문입니다.

• 통변 고급화 전략(스키마·계통 결합 원칙·금기어 정책)

• AI 실수 기록 34건과 재발 방지 체크리스트

• 진행 중 작업 현황과 slide 대역표

즉 AI가 "내 프로젝트가 어떻게 생겼는지"를 이미 알고 있어서, 원문 하나만 던져도 대조가 됐습니다.

3-2. 1단계 — 레이어 귀속 진단

먼저 한 일은 새 폴더를 만드는 게 아니라, 기존 자산이 어느 레이어에 속하는지 표로 만드는 것이었습니다.

7개 중 6개를 이미 갖고 있었습니다. 없던 건 자료가 아니라 "이걸 어디에 둘지 판단하는 기준" 이었습니다.

3-3. 가장 뚜렷했던 사례 — 같은 강의, 다른 레이어

제 DB에는 같은 강의에서 나온 두 산출물이 나란히 들어 있습니다.

둘 다 필요해서 각각 유지하고 있었는데, 레이어 개념이 없으니 "왜 둘 다 있지?"를 매번 설명해야 했습니다. 이름에 _통합 접미사를 붙여 구분해 둔 것이 사실 절반의 해결책이었고, 이제 이걸 질의 조건으로 쓸 수 있게만 하면 됩니다.

3-4. 스키마 — 기존 테이블은 건드리지 않는다

처음엔 기존 테이블에 컬럼을 추가하려 했다가 철회했습니다(사유는 4장에). 사이드카 방식으로 바꿨습니다.

sql

-- AKM 레이어 매핑 (기존 gwanbeop_ppt는 불가침)
CREATE SCHEMA IF NOT EXISTS akm;

CREATE TABLE akm.layer_map (
  source        text    NOT NULL,
  slide_from    integer NOT NULL,
  slide_to      integer NOT NULL,
  layer         text    NOT NULL CHECK (layer IN
                ('source','knowledge','context','procedure','action','evaluation')),
  origin_source text,              -- knowledge인 경우 파생 원본
  note          text,
  decided_by    text CHECK (decided_by IN ('rule','llm','human')),
  decided_at    timestamptz DEFAULT now(),
  PRIMARY KEY (source, slide_from, slide_to)
);

-- 근거 상태 (원문 글의 Candidate~Stale 5단계)
CREATE TABLE akm.evidence_state (
  run_id      text NOT NULL,        -- 산출 1회
  claim_id    text NOT NULL,        -- 문장 단위
  source      text NOT NULL,
  slide       integer NOT NULL,
  state       text NOT NULL CHECK (state IN
              ('candidate','direct_read','claim_supported','conflicted','stale')),
  created_at  timestamptz DEFAULT now(),
  PRIMARY KEY (run_id, claim_id, source, slide)
);
CREATE INDEX ON akm.evidence_state (state);

3-5. 근거 상태 5단계를 품질 지표에 연결

원문 글의 "검색 결과를 바로 근거로 사용하지 않았다"가 제 프로젝트의 근거 회수율(RS) 문제와 정확히 같은 얘기였습니다.

RS(근거 회수율) = claim_supported 수 / 산출된 문장 수
EU(근거 활용률) = 고유 근거 수(claim_supported) / direct_read 수

  candidate        = 검색이 반환한 것 (아직 근거 아님)
  direct_read      = 실제로 읽은 것
  claim_supported  = 문장에 출처가 병기된 것   ← RS 분자
  conflicted       = 계통 간 결론 충돌 → 보류
  stale            = 후기 자료로 대체된 것

측정해 보려다 알았습니다. 지금은 분자가 0입니다. 산출된 통변 문장에 출처가 아예 안 붙어 있어서, RS를 계산할 방법이 없었습니다. 유사도 점수(현재 0.5395)를 올리는 것보다 이게 먼저입니다.

3-6. 메모리 다이어트 — 4개만 남기기

원문 글의 "8,591개 문서를 운영하면서 메모리는 4개"를 그대로 따랐습니다.

M1. 계통·표기·금기어 정책
    · 3대 계통 구분 / 문장 내 혼재 금지, 단계 간 결합 허용
    · 금기어는 처방형 단정만 차단, 설명·비교 맥락은 허용
    · 상세 → 전략 문서 §3~§4

M2. 현재 국면
    · 진행 중 작업 3건 + 다음 확인 사항
    · 상세 → 로드맵 누적통합본

M3. 검증 3종 + 세션 개시 규칙
    · 세션 시작 시 과거 실수 기록부터 검색
    · 글자수 대조 / 구조 비교 / 리소스 유지
    · 3회 실패 시 중단하고 보고

M4. 자산 지도
    · 규모 수치 + slide 대역표 위치 + 검증용 명식 4건
    · 접속 정보·경로 → Procedure 문서 참조

메모리에 있던 워드 행간값·PDF 색상값·scp 명령은 전부 Procedure로 내리고, M4가 위치만 가리키게 했습니다.

3-7. Learn Back — 실수 기록에 "수정 레이어" 칸 추가

제 반성문은 "무엇을 잘못했는가"까지는 잘 적혀 있었는데, 원문 글이 지적한 "실패를 어느 레이어로 되돌렸는가" 가 없었습니다. 칸 하나를 추가했습니다.

📸 이미지 삽입 위치 ① 7레이어 ↔ 자산 매핑표 화면 ② 메모리 M1~M4 축약 전/후 비교 ③ 반성문에 "수정 레이어" 칸이 추가된 표 ④ slide 대역표에서 중복 구간을 발견한 화면

결과와 배운 점

4-1. 결과

4-2. 시행착오

① 내가 세운 원칙을 내가 어겼다

처음엔 기존 테이블에 akm_layer 컬럼을 추가하자고 제안했습니다. 그런데 제 프로젝트 전략 문서에는 "기존 파이프라인 불가침, 신규는 별도 스키마" 라는 사이드카 원칙이 이미 있었습니다. AI가 아니라 제가 제 원칙을 잊고 있었던 겁니다. 별도 akm 스키마로 바꾸고, 철회 사실을 설계서에 명기했습니다.

② 정리하다가 데이터 충돌을 발견했다

레이어 매핑표를 만들며 slide 대역표를 훑다가, 두 강의 시리즈의 slide 번호 구간이 88번지 겹치는 것을 발견했습니다. 각각 다른 시점에 배정한 대역인데 서로 모르고 있었습니다. 이건 레이어 적재 전에 서버 실측으로 확인해야 합니다.

③ 측정하려다 분모가 없다는 걸 알았다

근거 회수율을 재보려 했는데, 출처가 붙은 문장이 0개였습니다. 지표를 정의하는 것만으로도 "지금 못 재는 상태"라는 사실이 드러났습니다.

④ 메모리를 줄이는 게 제일 어려웠다

"이건 매번 필요한데" 싶은 게 계속 나왔습니다. 기준을 이렇게 잡으니 정리됐습니다. "전문을 읽어야 하면 Procedure, 어디 있는지만 알면 되면 Memory."

4-3. 꿀팁

① 새 구조를 도입할 땐 폴더보다 "귀속표"를 먼저 만든다 기존 자산을 새 레이어에 배치하는 표 하나를 만들면, 뭐가 없고 뭐가 겹치는지가 한눈에 보입니다. 제 경우 7개 중 6개는 이미 갖고 있었고, 문제는 분류 기준이었습니다.

② 남의 프레임워크는 "내 원칙과 충돌하는 지점"부터 확인한다 좋아 보인다고 그대로 넣으면 기존 원칙을 깹니다. 저는 스키마 변경 제안에서 그럴 뻔했습니다.

③ 지표는 못 재도 일단 정의한다 RS 정의를 적어 본 것만으로 "출처 병기가 없어서 못 잰다"는 진단이 나왔습니다. 정의가 곧 진단입니다.

④ 실수 기록에는 "고칠 곳"까지 적는다 "~하지 말자"는 다음에 또 어깁니다. "이건 Procedure 3번 단계를 고친다"까지 적어야 실제로 달라집니다.

4-4. 도움이 필요한 부분

• 레이어 자동 분류: 지금은 source명 규칙(_통합 접미사)으로 수동 분류합니다. 문서 내용만 보고 Source/Knowledge를 판별하는 방법이 있을까요?

• 감사 패킷과 압축 패킷의 경계: 원문 글에서 근거를 상세히 실었더니 컨텍스트가 887 → 10,172 토큰으로 늘었다는 대목이 있었습니다. 어디까지 모델 입력에 넣고 어디부터 감사용으로 뺄지 기준이 궁금합니다.

• 메모리 4개의 적정 길이: 포인터라도 너무 짧으면 AI가 못 찾아갑니다. 적정선을 잡은 사례가 있으면 배우고 싶습니다.

5. 앞으로의 계획

1. 1주 — akm 스키마 생성, 기존 자산을 Source/Knowledge로 분류. slide 대역 중복 구간 실측 확인.

2. 2주 — 메모리 4개 포인터로 축약, 나머지는 Procedure 문서 10건으로 이관.

3. 3주 — 실수 기록 34건 전부에 "수정 레이어" 칸 채우기 + 신규 6건 등록.

4. 4주 — 검증용 명식 4건에 근거 상태 5단계 적용해 최초 RS 수치 산출.

5. 이후 — 규칙 본문을 한 곳으로 모으고, 각 에이전트에는 포인터만 두는 어댑터 구성.

장기적으로는 이 구조가 디지털 문화유산 등재 서류와 직결됩니다. 등재 심사가 요구하는 건 자료의 양이 아니라 출처 추적 가능성인데, AKM의 Source/Knowledge 분리와 근거 5단계가 정확히 그 요건입니다.

도움 받은 글 (옵션)

• 지피터스 「AI가 매번 처음부터 다시 시작해서 만들었다 — 에이전트 지식 운영체계 AKM」 : 본 사례의 원본 프레임워크입니다. 7레이어 구분, 메모리 4개 제한, Learn Back, 근거 상태 5단계, 어댑터 개념을 그대로 가져왔습니다.

• 지피터스 헤르메스 에이전트 스터디 : 영구 기억·Cron·Skill 구조를 Procedure 레이어 설계에 참고했습니다.