AI 답변은 언제 ‘다시 써도 되는 지식’이 될까?

DEER·KSI를 AKM 검증 루프에 붙여 본 실제 기록

AI가 만든 글을 읽다가 곤란해지는 순간이 있습니다. 문장은 자연스럽고 표도 반듯합니다. 출처 링크까지 달려 있으니 얼핏 보면 완성본 같습니다. 그런데 다음 주에 그 내용을 제안서나 강의안에 다시 쓰려 하면 질문이 늘어납니다.

“이 숫자는 원문에 정말 있었나?”
“링크는 있지만 그 문장을 직접 뒷받침하나?”
“초안에 적힌 계획과 실제로 실행된 결과가 같은가?”
“검증에 실패한 부분은 다음 작업에서 고쳐졌나?”

제가 AKM(Agent Knowledge Management)의 검증 기록을 따라가며 확인한 문제도 여기에 있었습니다. AI가 그럴듯한 답을 냈다는 것과, 그 답이 다시 써도 되는 지식이 됐다는 것은 다릅니다. 전자는 읽기 좋은 출력이고, 후자는 출처·범위·검사·실패 상태를 함께 가진 재사용 자산입니다.

포장 음식에 비유하면 이해하기 쉽습니다. 접시에 예쁘게 담겼다는 사실만으로 다시 먹어도 안전한지는 알 수 없습니다. 재료, 제조일, 보관 조건, 알레르기 정보, 검사 기록이 있어야 판단할 수 있습니다. 지식도 비슷합니다. 문장만 남기면 맛있는 인상은 남지만, 언제 어디에 다시 써도 되는지 판단하기 어렵습니다.

AKM은 이 차이를 줄이려고 실행 → 검증 → 학습 환류(Learn Back)를 운영 루프에 넣었습니다. 여기에 DEER 논문의 평가 설계, KSI 논문의 지식 심사와 전이 아이디어, AKM에서 따로 만든 작업 계약·단일 작성자·결정적 검사·검색 삼각측량을 조합했습니다. 다만 모든 방법을 같은 수준으로 도입한 것은 아닙니다. 이미 운영 중인 규칙, 제한적으로 받아들인 파일럿, 아직 시험하지 않은 후보를 분리해 두었습니다.

이 글에서는 그 구분부터 보여드리겠습니다.

먼저 상태표부터: 논문에서 가져온 것, AKM이 만든 것, 아직 시험 중인 것

이 표가 중요한 이유는 최신 논문을 읽었다는 사실과 그 방법이 실제 운영에 들어갔다는 사실을 분리하기 위해서입니다. “도입을 검토했다”, “파일럿 도구를 만들었다”, “현장 품질이 좋아졌다”는 서로 다른 주장입니다.

DEER를 왜 가져왔나: 좋은 글의 기준을 미리 꺼내 놓기

DEER는 전문가 수준의 장문 리서치 보고서를 평가하기 위한 벤치마크입니다. 원 논문은 50개 보고서 생성 과제와 13개 분야를 다루고, 평가 기준을 7개 차원·25개 하위 차원·101개 세부 항목으로 구성했습니다.

일상적인 노트 작성에 101개 항목을 매번 적용하면 검증이 글쓰기보다 더 무거워집니다. AKM은 DEER의 벤치마크를 복제하지 않고 세 가지 설계만 가져왔습니다.

1. 평가 축을 고정합니다

AKM의 7개 질문은 다음과 같습니다.

예전에는 “링크가 있다”, “문서 형식이 맞다”만으로 검증이 끝나기 쉬웠습니다. DEER식 질문을 붙이면 링크의 존재와 링크의 지지력이 갈라집니다. 사용자가 원한 산출물과 에이전트가 편하게 만든 산출물도 따로 보게 됩니다.

2. 과업별 Guidance를 만듭니다

고정된 점검표만으로는 작업마다 다른 실패를 잡기 어렵습니다. 전시 연구의 위험과 공모전 발표의 위험은 다릅니다. DEER는 과업마다 전문가가 필수 내용을 구체적이고 검증 가능한 문장으로 쓰는 Expert Evaluation Guidance를 둡니다.

AKM에서는 이를 Task Evaluation Guidance Packet으로 줄였습니다.

Task intent: 이 작업으로 실제 달성하려는 것
Audience/use: 누가 어디에 쓸 것인지
Required content: 반드시 있어야 하는 내용
Required exclusions: 넣으면 안 되거나 과장하면 안 되는 내용
Domain anchors: 논문·공식 문서·정본 노트
Failure traps: 자주 생기는 혼동과 누락
Verification evidence: 통과를 보여 줄 파일·명령·readback
Learn-back target: 실패하면 어느 규칙이나 지식을 고칠지

이 패킷은 채점표보다 작업 명세에 가깝습니다. 평가자가 나중에 취향대로 판단하지 않도록, “무엇을 통과로 볼지”를 먼저 적습니다.

3. 문서 전체의 claim을 봅니다

출처가 붙은 문장만 확인하면 중요한 빈틈이 생깁니다. 어떤 문장은 같은 문단 앞의 출처에 기대고, 어떤 문장은 앞 절의 근거를 이어받습니다. 또 근거가 필요한데 출처가 없는 문장도 있습니다.

DEER는 claim을 A~F 유형으로 나눕니다. AKM은 이를 고위험 산출물의 claim ledger에 사용합니다.

• A: 문장 안에 출처가 명시된 claim

• B: 같은 문단·절 앞의 출처를 이어받는 claim

• C: 이전 절의 근거를 의미상 이어받는 claim

• D: 문서 구조를 요약하는 문장

• E: 저자의 분석이나 별도 인용이 필요 없는 내용

• F: 근거가 필요한데 출처를 찾을 수 없는 claim

모든 노트의 모든 문장을 분류하지는 않습니다. 공모 제출, 안전·법률·의료, 기관이나 사람에 대한 사실, 외부에 공개할 수치처럼 틀리면 신뢰가 크게 흔들리는 작업에서만 장부를 만듭니다. F 유형이 남으면 문장을 약화하거나 삭제하고, 중요한 문제라면 HOLD로 멈춥니다.

DEER를 가볍게 만든 이유: 검증도 예산을 먹기 때문입니다

DEER 논문은 전문가 보고서를 비교하는 벤치마크입니다. AKM은 매일 짧은 조회부터 강의안, 제안서, 연구 노트까지 폭이 넓습니다. 같은 검사를 전부 적용하면 세 가지 문제가 생깁니다.

첫째, 검증 시간이 늘어납니다. 3분짜리 사실 확인에도 장문의 rubric을 적용하면 정작 필요한 답이 늦어집니다. 둘째, 평가 문서가 지식보다 더 많이 쌓일 수 있습니다. 셋째, LLM 평가가 정교해 보여도 원문을 대신 읽어 주지는 않습니다.

그래서 네 단계로 나눴습니다.

이 글은 공개 사례글이므로 Tier 2입니다. 글 전체를 101개 항목으로 채점하는 대신, 독자 요구와 상태 구분을 Guidance에 고정하고, DEER·KSI·실제 사례의 중요한 claim을 원문과 운영 기록에서 다시 확인하는 방식입니다.

AKM 고유 규칙이 붙으면서 검증이 ‘운영’이 됐습니다

논문의 평가표만으로 지식 시스템이 저절로 바뀌지는 않습니다. 결과가 실패했을 때 다음 작업의 입력을 고쳐야 합니다. AKM은 이 지점을 Verify → Learn Back으로 연결합니다.

질문·자료
   ↓
[Graphify: 관계 지형] + [qmd: 관련 문서 후보]
   ↓
[원문 직접 읽기: 사실 경계]
   ↓
[task contract: 산출물·금지·완료 조건]
   ↓
[단일 canonical writer]
   ↓
[lint + 파일 readback + 주요 claim 확인]
   ↓
┌──────────── PASS ────────────┐
│ trustLevel 조정 → 재사용     │
└─────────────┬────────────────┘
              │ HOLD / FAIL
              ↓
   문장 수정·출처 보강·범위 축소
              ↓
   Learn Back: 지식 / 맥락 / 절차 / 평가 기준 교정
              └──────────────→ 다음 실행

검색은 세 층으로 나눕니다

이번 글을 준비할 때도 검색 하나에 모든 책임을 주지 않았습니다.

• Graphify에서는 DEER와 KSI source·도입 노트가 evaluation · evidence 관계 군집에 놓여 있음을 확인했습니다. 이것은 “어디를 함께 볼지” 알려 주는 지형 정보입니다.

• qmd에서는 DEER playbook, rubric, claim ledger 템플릿과 KSI 도입 판정, pilot 보고서, 독립 acceptance를 후보로 회수했습니다.

• direct read에서는 각 파일의 실제 문장과 상태를 읽었습니다. KSI의 ACCEPT가 품질 향상 승인이 아니라 제한된 인프라·역사 재생 무결성 승인이라는 사실은 여기서 확인했습니다.

검색 순위는 진실 점수가 아닙니다. 관계 그래프에서 가깝다고 같은 주장을 하는 것도 아닙니다. Graphify는 지도, qmd는 서가 검색, direct read는 책을 펼쳐 문장을 확인하는 단계입니다.

task contract는 주문서이자 검사표입니다

작업 계약에는 입력, 출력 경로, 산출물 형식, 비목표, 실패 처리, 실행할 검증 명령을 적습니다. “좋은 글을 써 주세요” 대신 “누구를 위한 어떤 파일을 만들고, 무엇을 과장하지 않으며, 어느 검사까지 통과해야 하는가”를 고정합니다.

이번 사례글도 Markdown 정본과 frontmatter 없는 TXT, 8,000자 이상, 상태표, 실제 사례, 30분 루프, 한계, Tier 2 QA를 계약에 넣었습니다. 계약이 먼저 lint를 통과한 뒤에 작성에 들어갔습니다.

최종 글은 한 명만 씁니다

검색과 검토는 나눌 수 있어도 정본 파일을 여러 writer가 동시에 고치게 하지 않습니다. 자료를 읽는 역할, 후보를 찾는 역할, frontmatter와 lint를 검사하는 역할은 지원자입니다. 최종 문장을 통합하고 수정하는 사람은 한 명입니다.

이 규칙은 문체 통일을 위한 장식이 아닙니다. 두 writer가 한 문장을 서로 다른 출처로 고치거나, Markdown과 TXT를 따로 편집해 내용이 갈리는 일을 막습니다. Markdown을 먼저 완성하고 TXT는 마지막 본문에서 기계적으로 파생합니다.

lint와 readback은 ‘실제로 존재함’을 확인합니다

lint는 YAML, 필수 필드, 링크, 탭, 비밀값, 계약 위반 같은 결정 가능한 문제를 빠르게 찾습니다. readback은 작성했다고 보고된 파일을 다시 읽어 내용과 길이, 필수 문구, 파생본 일치를 확인합니다.

여기에도 경계가 있습니다. lint exit 0은 문장이 사실이라는 뜻이 아닙니다. 형식 검사는 원문 검증을 보조합니다. 사실은 출처를 다시 읽어 확인해야 합니다.

실제 사례 1: 출처가 충돌할 때 하나의 숫자로 봉합하지 않았습니다

2026년 7월, 백남준 초기 작품 11항목을 공모 콘셉트에 쓰기 위한 연구가 진행됐습니다. 이 결과에는 Tier 3 claim ledger가 붙었습니다. 작품 연도, 공연 행위, 기술 방식, 협업 관계, 논쟁적인 기원담처럼 잘못 쓰면 연구 전체의 신뢰를 해칠 claim을 문장 단위로 확인했습니다.

검증에서 흥미로운 장면은 “정답 숫자를 찾는 것”보다 “불일치를 남기는 것”이 더 정확했던 경우입니다.

1963년 전시에 사용된 TV와 피아노 수량은 기관 자료마다 달랐습니다. 한 자료는 TV 12대와 피아노 4대를, 다른 자료는 TV 13대 또는 피아노 3대를 제시했습니다. ledger는 하나를 골라 확정하지 않고 12/13, 3/4의 출처 차이를 그대로 보존했습니다.

교황 행렬을 촬영해 당일 상영했다는 유명한 기원담도 확정 사실로 처리하지 않았습니다. 기관 설명에 이견이 있고 기술사 자료가 촬영 기기 시점을 문제 삼았기 때문에 Partially Supported로 남겼습니다. 대신 현존하는 초기 비디오 자료와 논쟁적 기원담을 분리했습니다.

최종 판정은 PASS_WITH_NOTE였습니다. 주석이 남았다는 이유로 실패한 것이 아닙니다. 출처 충돌을 감춘 매끈한 문장보다, 충돌 지점을 다음 작업에서도 유지할 수 있게 한 결과가 더 재사용 가능했습니다.

이 사례에서 Learn Back은 이렇게 작동했습니다.

• 전시 수량은 다음 문서에서도 단일 값으로 확정하지 않습니다.

• 작품의 초기 수행, 유명한 기록, 스코어 저자를 별도 필드로 분리할 후보를 남겼습니다.

• 논쟁적인 기원담은 “소실 원본 복원” 같은 강한 표현으로 바꾸지 않습니다.

• 연구자의 AI 번역 제안과 작가의 직접 발언을 라벨로 구분합니다.

좋은 검증은 모든 문장을 확정형으로 만드는 일이 아닙니다. 어디까지 확인됐고 어디부터 해석인지 오래 유지하는 일입니다.

실제 사례 2: 계획서의 ‘52→100’과 현장에서 말한 내용은 달랐습니다

다른 사례는 한 공모전 발표입니다. 발표자료에는 같은 조건에서 관람객 QA 커버리지가 52→100, 공백이 4→0으로 바뀌는 재현 시나리오가 준비돼 있었습니다. 기존 Tier 3 claim ledger는 날짜, 도구 수, 테스트 결과, 공개 데모 상태, 수치의 의미와 안전 경계를 점검했습니다.

발표가 끝난 뒤에는 녹음과 타임스탬프 전사를 정본으로 삼아 별도 감사를 했습니다. 여기서 문서에 적힌 계획과 현장에서 실제로 발화한 내용이 갈렸습니다.

실측 본 발표는 10분 7.62초였고 11장 중간에서 종료됐습니다. 발표자는 52와 네 가지 공백까지 말했지만, 보완 뒤 100, gap 0, 동일 조건 재검증, “안전 점수나 사고 확률이 아니다”라는 완전한 경계는 말하지 못했습니다. 따라서 “현장에서 52→100 개선을 발표했다”는 claim은 Not Supported로 교정됐습니다.

Q&A에서 나온 “며칠 걸리던 일을 1~2시간으로 줄인다”는 표현도 검증된 효과로 승격하지 않았습니다. 현장 경험과 예상은 있었지만 비교군이나 PoC 측정 자료가 없었기 때문입니다. 과거 사고사례를 현재 사용한다는 추정도 실제 답변의 “지금은 없다”와 모순돼 교정됐습니다.

이 사례가 보여 주는 차이는 분명합니다.

• 슬라이드에 써 있던 내용은 계획 증거입니다.

• 녹음에 남은 말은 실행 증거입니다.

• claim ledger의 재현 수치는 사전 검증 증거입니다.

• 현장에서 그 수치를 전달했는지는 별도의 claim입니다.

네 가지를 합치면 그럴듯한 성공담이 됩니다. 분리하면 다음 발표에서 무엇을 고쳐야 하는지 보입니다. 후속 조치는 기능 설명을 더 늘리는 것이 아니라 52→100 결과를 30초 안에 닫고, 시간 절감 주장을 실제 사용 전후 측정으로 바꾸는 것이었습니다.

KSI는 어디까지 들어왔나: ‘배웠다’는 말도 검증하기

DEER가 한 산출물의 품질을 평가하는 데 강하다면, KSI(Knowledge-Centric Self-Improvement)는 여러 작업의 성공과 실패에서 무엇을 다음 세대 지식으로 남길지 묻습니다.

KSI 논문은 에이전트 자체를 계속 바꾸기보다, 에이전트는 매번 fresh context로 시작하고 검증된 지식 묶음만 발전시키는 통제 설계를 제안합니다. 과정은 세 단계입니다.

1. Task-Level Forum: 한 작업의 여러 시도에서 전제, 근거, 실패 가설, 다음 변경, 예상 결과를 남깁니다.

2. Cross-Task Forum: 다른 작업에서도 같은 규칙이 성립하는지 지지·반박·종합합니다.

3. Distillation: 적용 조건, 비적용 조건, 증거, confidence가 있는 짧은 지식으로 압축합니다.

논문은 고정된 지식 자산을 보지 못한 어려운 held-out task에 넣고, 다른 모델 계열에서도 전이되는지 시험했습니다. 여기서 AKM이 가져온 질문은 “이 조언이 좋아 보이는가?”가 아니라 “새 작업과 다른 실행 환경에서도 도움이 되는가?”입니다.

하지만 논문의 실험 결과를 AKM의 효과로 옮겨 적을 수는 없습니다. 코딩·추상 추론·터미널 benchmark에서의 결과는 문서 작성, 강의, 공모, 개인 지식관리의 생산성 향상을 직접 증명하지 않습니다.

AKM의 KSI 도입 판정

• Adopt: claim에 적용 조건·비적용 조건·근거·예상 결과를 붙이고, 성공과 실패를 함께 보존합니다.

• Adapt: forum은 모든 작업에 상시 적용하지 않고 고위험·반복 실패·승격 후보에만 제한합니다. 정본은 Markdown으로 유지합니다.

• Pilot: task-local claim → cross-task 심사 → 조건부 distillation → checksum으로 고정한 bundle → held-out 평가의 작은 절차를 만들었습니다.

• Defer: KSI 전체 runtime, 별도 SQLite/vector store, forum MCP, 항상 켜진 cross-task cron은 미룹니다.

• Reject: forum 합의를 진실로 보거나 distillation 결과를 자동 정본으로 승격하는 방식은 거부합니다.

실제 파일럿에서 통과한 것과 통과하지 않은 것

KSI-lite r9에는 16개 donor와 8개 held-out으로 구성된 역사적 corpus가 있습니다. donor와 held-out 사이의 source·target·contract 겹침을 0으로 만들고, 중복 JSON key, 누락된 필수 경로, 손실성 UTF-8 비교 같은 false-pass 경로를 차단했습니다. 집중 테스트 63/63과 live-main 전체 테스트 78/78, exact replay, raw-byte readback이 통과했고 독립 검토도 제한된 인프라·역사 재생 무결성을 ACCEPT했습니다.

여기서 멈춘 이유가 더 중요합니다.

• prospective 작업 품질: NOT_TESTED

• material regression: NOT_TESTED

• AKM에서의 cross-model transfer: NOT_TESTED

• economics: NOT_RECORDED

• promotion artifact: 0

• global promotion: HOLD

역사적 재생에서 policy signal이 더 많이 검출됐다는 사실은 실제 새 작업의 품질 향상이나 인과 효과가 아닙니다. 파일럿 도구가 거짓 PASS를 덜 내도록 단단해졌다는 증거와, 지식 묶음이 현장 성과를 높였다는 증거는 분리해야 합니다.

KSI는 AKM에서 “이미 운영 중인 자기개선 엔진”이 아닙니다. 조건부 지식을 심사하는 제한된 파일럿 인프라이며, 승격을 주장하려면 아직 prospective A/B, cross-model, 회귀, 비용 측정이 필요합니다.

source lineage: 원문과 파생 글의 족보를 남깁니다

재사용 가능한 지식에는 “어디서 왔는가”뿐 아니라 “무엇이 여기서 파생됐는가”도 필요합니다.

KSI source bundle은 논문 PDF·추출 텍스트·공개 코드의 선택 스냅샷을 보존하고, 31개 artifact의 bytes와 SHA-256을 manifest에 기록합니다. manifest의 derivedNotes에는 source note와 AKM 도입 판정이 연결돼 있습니다. 원본 묶음을 고치지 않고, 해석과 도입 결정은 별도 노트에서 이어 갑니다.

모든 source folder에 같은 manifest가 있는 것은 아닙니다. manifest가 실제로 존재하고 해당 zone의 규칙이 맞을 때만 파생 관계를 등록합니다. 파일이 없는데 lineage를 만들어 냈다고 쓰거나, 출처 URL만 모아 놓고 source-backed라고 부르지 않습니다.

이 족보는 나중에 세 가지 질문에 답합니다.

• 원문이 바뀌거나 새 버전이 나왔을 때 어떤 글을 다시 봐야 하나?

• 이 문장의 근거는 논문, 내부 해석, 실행 결과 중 어디인가?

• 파생 글이 원문보다 강한 주장을 하고 있지는 않은가?

30분 최소 검증 루프: 노션·옵시디언·폴더에도 적용할 수 있습니다

거대한 시스템부터 만들 필요는 없습니다. 문서 하나와 체크리스트 하나로 시작할 수 있습니다. 아래 흐름은 AI가 만든 리서치 메모, 회의 요약, 제안서 문단, 강의 자료에 그대로 적용할 수 있습니다.

0~5분: 작업 계약을 다섯 줄로 씁니다

목적: 이 문서를 어디에 쓸 것인가?
독자: 누가 읽고 어떤 결정을 하는가?
필수: 빠지면 실패인 내용은 무엇인가?
금지: 과장·민감정보·외부 게시 등 하지 말아야 할 것은 무엇인가?
완료: 어떤 파일과 검사 결과가 있어야 끝인가?

파일명 예시는 2026-07-31-verified-note.md처럼 날짜와 주제를 함께 적으면 충분합니다.

5~12분: 검색 후보와 원문을 분리합니다

1. 검색이나 AI 추천으로 후보 자료를 2~3개 찾습니다.

2. 가장 권위 있는 원문을 하나 이상 직접 엽니다.

3. 제목·날짜·버전·기관·접근 실패를 기록합니다.

4. 검색 요약은 후보로만 두고, 확인하지 못한 문장은 초안에서 약화합니다.

노션이라면 Sources 데이터베이스, 옵시디언이라면 source note, 일반 폴더라면 sources.txt 한 장이면 됩니다.

12~20분: 중요한 claim 세 개만 뽑습니다

표를 하나 만드세요.

날짜, 숫자, 자격 조건, 기관·인물, 성과, 안전·법률·의료 내용을 우선합니다. 모든 문장을 검사하려 하지 말고 손상 비용이 큰 claim부터 봅니다.

20~25분: 기계가 잘하는 검사를 돌립니다

• 요청한 파일이 실제로 있는가?

• 비어 있지 않은가?

• 제목·필수 섹션·체크리스트가 있는가?

• 링크나 frontmatter가 깨지지 않았는가?

• Markdown과 붙여넣기본의 본문이 같은가?

• 내부 경로, 계정, token, raw log가 공개 글에 섞이지 않았는가?

코드를 쓰지 않아도 파일을 다시 열고 체크박스를 직접 확인하면 됩니다. 자동화할 수 있다면 글자 수, 필수 문구, 두 파일의 본문 equality부터 검사하세요.

25~30분: PASS보다 HOLD를 먼저 정의합니다

• PASS: 주요 claim과 형식, 파일 readback이 모두 통과했습니다.

• PASS_WITH_NOTE: 쓸 수 있지만 출처 충돌이나 낮은 위험의 주석을 유지해야 합니다.

• HOLD: 중요한 출처·범위·사실 문제가 남아 공개하거나 재사용하면 안 됩니다.

• FAIL: 오해를 만들거나 큰 재작업이 필요합니다.

마지막 한 줄에는 다음 작업을 적습니다.

Learn Back: 다음부터 같은 실패를 막기 위해 source / context / procedure / checklist 중 무엇을 고칠 것인가?

복사해서 쓰는 최소 체크리스트

• 이 문서의 독자와 사용 장면을 한 문장으로 썼습니다.

• AI 검색 결과와 직접 읽은 원문을 구분했습니다.

• 중요한 날짜·숫자·기관·성과 claim을 최소 3개 확인했습니다.

• 출처가 있다는 사실과 출처가 문장을 지지한다는 사실을 따로 봤습니다.

• 사실, 해석, 계획, 실행 결과를 다른 라벨로 적었습니다.

• 검사 실패를 숨기지 않고 PASS_WITH_NOTE·HOLD·FAIL 중 하나로 남겼습니다.

• 최종 파일을 다시 열어 실제 내용을 확인했습니다.

• 같은 실패를 막을 체크리스트나 절차 한 줄을 고쳤습니다.

• 외부 게시·전송은 별도 사람 승인 뒤에 진행합니다.

어디까지 믿어야 하나: 검증 루프의 한계

LLM-as-judge는 진실 판정기가 아닙니다

평가 모델이 높은 점수를 줘도 원문이 틀렸거나, 평가 지침이 빠졌거나, 중요한 도메인 맥락을 놓칠 수 있습니다. DEER도 task-specific Guidance와 claim verification을 따로 둔 이유가 여기에 있습니다. AKM에서는 모델 점수를 진단 신호로 쓰고, direct read와 도구 결과, artifact inspection을 더 높은 증거로 둡니다.

검증에는 비용과 지연이 생깁니다

source를 다시 열고 claim을 분해하고 파일을 읽어보는 시간은 공짜가 아닙니다. 모든 채팅 답변을 Tier 3로 처리하면 시스템이 느려지고 평가 문서가 넘칩니다. 위험과 재사용 가능성에 맞춰 Tier를 선택해야 합니다.

출처에 접근하지 못할 수 있습니다

paywall, 로그인, HTTP 오류, 삭제된 페이지, 403, OCR 오류 때문에 원문을 확인하지 못하는 경우가 있습니다. 이때 올바른 판정은 “검증 완료”가 아니라 Source Inaccessible 또는 HOLD입니다. 다른 공식 표면을 찾더라도 원래 출처와 대체 표면을 구분해야 합니다.

자동화 점수는 측정한 것만 말합니다

lint 0, 테스트 63/63, raw-byte parity는 해당 규칙이 통과했다는 강한 증거입니다. 글이 유익한지, 해석이 공정한지, 새로운 현장에서도 품질이 좋아지는지는 별도 평가가 필요합니다. KSI-lite 파일럿이 인프라 acceptance 뒤에도 promotion HOLD를 유지한 이유입니다.

사람의 도메인 판단이 남습니다

출처가 충돌할 때 어느 차이를 보존할지, 법률·의료·안전 문장을 얼마나 약화할지, 작품 해석을 사실처럼 쓰지 않았는지는 형식 검사만으로 결정하기 어렵습니다. 도메인 전문가, 실제 사용자, 책임 있는 승인자의 판단을 없애는 것이 목표가 아닙니다. 사람이 판단할 지점을 더 잘 보이게 만드는 것이 목표입니다.

다시 써도 되는 지식을 판별하는 마지막 질문

AI 답변을 저장하기 전에 저는 이제 “잘 썼는가?”만 묻지 않습니다.

• 어디에서 왔는가?

• 어느 조건에서 맞는가?

• 무엇은 아직 확인하지 못했는가?

• 계획과 실제 실행을 구분했는가?

• 검사에 실패하면 다음 작업의 어떤 규칙이 바뀌는가?

이 다섯 질문에 답할 수 있으면 문장은 다음 작업의 입력이 됩니다. 답할 수 없다면 아직은 참고 초안입니다.

DEER는 무엇을 봐야 하는지 알려 줬고, KSI는 어떤 경험을 다음 지식으로 승격할지 묻게 했습니다. AKM의 task contract, 단일 writer, qmd·Graphify·direct read, lint·readback, Verify→Learn Back은 그 질문을 매일 실행할 수 있는 작은 장치로 바꿨습니다.

여기서 가장 유용한 상태는 무조건 PASS가 아닙니다. 근거가 부족할 때 멈추는 HOLD, 출처 충돌을 지우지 않는 PASS_WITH_NOTE, 아직 시험하지 않은 것을 NOT_TESTED라고 쓰는 습관이 지식을 오래 살립니다.

다음에 AI가 아주 매끄러운 답을 내놓으면 한 번만 더 물어보세요.

이 문장은 지금 읽기 좋은가, 아니면 다음 달에도 근거와 한계까지 꺼내 다시 쓸 수 있는가?

공개 참고 자료

• DEER: A Benchmark for Evaluating Deep Research Agents on Expert Report Generation — https://arxiv.org/abs/2512.17776v4

• Knowledge-Centric Self-Improvement — https://arxiv.org/abs/2607.19592v1

• KSI 공개 구현 — https://github.com/recursive-knowledge/KSI

• AKM 공개 저장소 — https://github.com/DECK6/akm