YouDefine AI OS에 AKM 1~3주차를 적용한 기록
AI를 업무에 활용하면서 가장 답답했던 순간은 AI가 답을 만들지 못할 때가 아니었다. 이미 알려준 내용을 다음 작업에서 다시 설명해야 하고, 한 학교의 정보가 다른 학교 문서에 섞이며, 결과가 맞는지 결국 사람이 처음부터 다시 확인해야 할 때였다.
YouDefine AI OS에는 이미 여러 에이전트와 업무별 폴더, 지 식 문서, 작업 기록이 있었다. 방과후 업무를 담당하는 실제 실행 엔진도 D:\afterschool-engine에서 운영되고 있었다. 하지만 자료와 기록이 많아지는 것과 시스템이 제대로 기억하고 판단하는 것은 다른 문제였다.
이번 적용의 목표는 새로운 시스템을 하나 더 만드는 것이 아니었다. 기존 시스템을 유지하면서 다음 세 가지를 가능하게 만드는 것이었다.
정보가 어디에서 왔는지 구분한다.
이전 작업에서 배운 것을 다음 작업에 재사용한다.
결과를 믿기 전에 근거와 비교해 검증한다.
이를 위해 AKM의 핵심 원리를 1주차부터 3주차까지 단계적으로 적용했다.
적용 전: 기억은 많았지만 경계가 흐렸다
적용 전의 YouDefine AI OS는 빈 시스템이 아니었다. 오히려 이미 상당한 기반을 갖추고 있었다.
방과후 실행 엔진은
D:\afterschool-engine에서 작동했다.학교별 템플릿은 Google Drive의
YouDefine-AI-OS\apps\afterschool에 보관했다.Supabase에는 실행 기록과 운영 데이터가 축적되고 있었다.
knowledge,ledger,outputs,rules,AKM-You등 지식 운영 구조도 존재했다.
그러나 실제 업무에서는 몇 가지 문제가 남아 있었다.
원본 자료와 AI가 정리한 지식이 한 문맥에서 섞였다.
학교별 조건과 공통 운영 규칙의 경계가 명확하지 않았다.
이전 문서를 복사하면 과목명·장소·반 정보가 함께 따라왔다.
결과물은 만들어졌지만 어떤 근거로 검증했는지 한눈에 확인하기 어려웠다.
반복해서 발견한 규칙이 곧바로 전역 지식처럼 취급될 위험이 있었다.
오류가 발견되면 어디까지 고쳐야 하는지 기준이 없었다.
즉, 시스템은 많은 것을 저장하고 있었지만 무엇이 사실이고, 무엇이 이번 작업의 조건이며, 무엇을 다음에도 재사용할 수 있는지를 충분히 구별하지 못했다.
1주차: 정보를 역할별로 분리하다
1주차의 핵심은 더 많이 저장하는 것이 아니라, 서로 다른 정보를 섞지 않는 것이었다.
1주차 시행착오: 폴더를 나누는 것만으로는 정보가 분리되지 않았다
처음에는 knowledge, ledger, outputs처럼 폴더가 구분되어 있으니 정보도 이미 분리되어 있다고 생각했다. 그러나 실제 문서 한 개 안에는 원본에서 확인한 사실, AI가 기억하던 내용, 이번 학교에만 해당하는 조건, 작성 규칙이 함께 들어 있었다.
폴더의 위치만 보고 정보의 역할을 판단하면 같은 문제가 반복됐다. 특히 이전 안내문을 새 학교의 초안으로 사용할 때, 문장 형식뿐 아니라 과목명·장소·반 구성까지 함께 따라왔다.
[처음 시도]
폴더 구분
↓
정보도 분리됐을 것이라고 판단
↓
문서 내부에서 원본·기억·학교별 조건이 다시 혼합
↓
다른 학교 정보가 새 안내문에 잔존그래서 폴더가 아니라 정보 자체에 역할을 부여하는 방식으로 기준을 바꿨다.
1주차 핵심 적용: 여섯 가지 정보 역할
기존 자료를 다음 여섯 가지 역할로 구분했다.
SOURCE = 이번 작업의 근거 원문
예: 학교 공식 시간표, 학교별 제출 양식
KNOWLEDGE = 다음 작업에도 재사용할 수 있는 지식
예: 안내문 작성 원칙, 안전 문구 기준
CONTEXT = 현재 작업에만 적용되는 조건
예: 학교명, 과목명, 반, 장소, 기간
PROCEDURE = 일을 수행하는 순서
예: 템플릿 동기화 → 생성 → 검증 → 게시
EVALUATION = 결과를 판단한 기록
예: Evidence, 오류, Verdict
OUTPUT = 외부에 전달할 최종 결과
예: 안내문, 출석부, 학교 제출 서류이 구분을 적용하면서 가장 중요한 변화는 학교별 정보가 ‘공통 지식’에서 분리된 것이었다.
예를 들어 oo초의 항공드론교실은 별관 과학실에서 A·B·C반으로 운영되는 테스트 Context를 사용했다. 반면 **초의 드론교실은 방과후교실에서 A·B반으로 운영되며 C반이 없는 Context를 사용했다. 적용 전에는 이전 안내문을 복사하는 순간 oo초의 장소나 C반 정보가 **초 문서에 남을 수 있었다.
1주차 이후에는 학교별 과목명·장소·반·시간을 Context로 묶어 한 작업 안에서만 사용하도록 기준을 세웠다. 반면 ‘Source에 없는 준비물이나 비용을 임의로 단정하지 않는다’와 같은 원칙은 여러 학교에서 재사용할 Knowledge로 분리했다.
1주차 전후 변화
[적용 전] [1주차 적용 후]
원본·기억·추정이 한 문서에 혼합 → Source·Knowledge·Context 분리
이전 학교 문서를 통째로 복사 → 현재 학교 Source Packet 새로 로드
완성 결과를 다음 작업의 기억으로 사용 → Output을 별도 보관
학 교별 정보를 공통 지식처럼 사용 → Project Context로 범위 제한[1주차 작업 흐름]
현재 Source 확인
↓
학교별 Context 고정
↓
공통 Knowledge만 선택
↓
Procedure에 따라 Output 생성
↓
Evaluation 영역에 결과 기록1주차의 성과는 화려한 자동화 기능이 아니었다. 대신 이후의 모든 자동화가 잘못된 정보를 빠르게 복제하지 않도록 정보의 차선과 중앙선을 그은 것이었다.
2주차: 이전 작업에서 배운 것을 ‘델타’로 남기다
1주차에 정보의 경계를 세웠다면, 2주차에는 그 경계 안에서 지식을 재사용하는 방법을 정했다.
기존 방식에서는 작업이 끝난 뒤 결과물만 남는 경우가 많았다. 다 음 작업을 시작하면 완성된 문서를 다시 읽고 그 안에서 규칙을 찾아야 했다. 잘된 점과 잘못된 가정이 함께 재사용될 가능성도 있었다.
2주차 시행착오: 완성된 결과물을 지식으로 다시 쓰면 오류도 함께 남았다
처음에는 잘 만들어진 안내문을 다음 작업의 참고 자료로 제공하면 효율적일 것이라고 생각했다. 하지만 완성 문서에는 재사용 가능한 작성 원칙과 특정 학교에만 해당하는 시간이 함께 들어 있었다.
또 한 번 발견한 좋은 규칙을 곧바로 전역 지식에 넣으면 빠르게 성장하는 것처럼 보였지만, 다른 학교와 다른 문서 유형에서는 맞지 않을 수 있었다. 기억을 늘리는 속도가 검증 속도보다 빨라지는 문제가 생긴 것이다.
[처음 시도]
완성 결과물 저장
↓
다음 작업에서 결과물 전체 재사용
↓
좋은 규칙 + 학교별 조건 + 잘못된 가정이 함께 로드
↓
오류까지 복리처럼 재사용2주차 핵심 적용: Knowledge Delta
이를 해결하기 위해 Knowledge Delta를 도입했다. Knowledge Delta는 작업을 마친 뒤 ‘이번 작업으로 무엇이 달라졌는가’를 따로 기록하는 문서다.
델타에는 다음 내용을 구분해 남기도록 했다.
이번 프로젝트에서만 유지할 정보
기존 가정 중 틀렸거나 폐기된 내용
다음 작업에도 재사용할 수 있는 후보 규칙
전역 지식으로 승격할지에 대한 판단
**초 파일럿에서는 다음과 같은 델타가 만들어졌다.
**초는 드론교실이며 A·B반만 운영한다.oo초의 과목명·장소·C반 정보를**초에 재사용하면 안 된다.Source에 없는 준비물은 관행이라는 이유로 추가하면 안 된다.
학교가 바뀌면 학교별 Context를 새로 로드해야 한다.
여기서 중요한 점은 마지막 규칙을 곧바로 AKM-You 전역 지식에 넣지 않았다는 것이다. 한 번 발견한 패턴은 candidate로 유지하고, 같은 패턴이 세 번 확인되면 승격 검토를 시작하도록 했다.
이 는 ‘세 번 나오면 자동 승격’이 아니다. 세 번은 검토를 시작하는 조건일 뿐이며, 실제 승격에는 적용 범위와 반례, 최신성 확인이 필요하다.
2주차 전후 변화
[적용 전] [2주차 적용 후]
결과물 전체를 다시 읽음 → 변화한 지식만 Delta로 기록
잘못된 가정도 함께 복사 → 폐기된 가정을 별도 명시
한 번의 경험을 전역 규칙으로 사용 → candidate 상태로 보류
학교별 정보와 전역 지식 경계가 약함 → Project-only / reusable 분리[2주차 지식 흐름]
기존 Knowledge 조회
↓
현재 작업 수행
↓
Knowledge Delta 추출
├─ Project-only : 현재 프로젝트에만 유지
├─ Discarded : 틀린 가정으로 폐기
└─ Candidate : 재사용 후보로 보류
↓
동일 패턴 3회 확인
↓
자동 승격이 아닌 검토 시작2주차를 지나며 시스템의 기억 방식이 바뀌었다. 무엇이든 많이 기억하는 시스템에서, 무엇을 남기고 무엇을 버릴지 판단하는 시스템으로 한 단계 진화했다.
3주차: 결과를 만드는 AI에서, 결과를 검증하는 시스템으로
3주차의 핵심은 검증이었다. 단순히 문서를 생성한 뒤 사람이 눈으로 훑어보는 수준을 넘어, 생성 전후를 비교하고 수정 범위를 통제하는 구조를 적용했다.
3주차 시행착오: 검수 라는 이름으로 전체 문장을 다시 쓰고 있었다
초기 검수 방식은 ‘이상한 부분이 있으면 자연스럽게 고쳐 달라’에 가까웠다. 이 방식은 문장을 매끄럽게 만들 수 있지만, 맞는 정보까지 바꾸거나 Source에 없던 내용을 친절한 안내라는 이유로 추가할 수 있었다.
검수자가 많이 고칠수록 품질이 높아 보이는 착시도 있었다. 하지만 운영 문서에서는 수정량보다 수정 근거와 수정 범위가 더 중요했다.
[처음 시도]
초안 생성
↓
전체 문장을 자연스럽게 재작성
↓
맞는 정보까지 변경될 가능성
+
Source에 없는 친절한 문구가 추가될 가능성
↓
무엇을 왜 고쳤는지 추적하기 어려움3주차 핵심 적용: Baseline·Evidence·Correction Gate
검증 절차는 다음과 같이 구성했다.
생성된 최초 결과를 Baseline으로 동결한다.
업무 위험도에 따라 Risk Tier를 설정한다.
주요 문장과 수치를 Source에 대조해 Evidence Ledger를 만든다.
근거가 있는 오류만 Correction Gate에서 수정한다.
수정 후 다시 읽어 새로운 오류가 생기지 않았는지 확인한다.
결과를
PASS,PASS_WITH_NOTE,HOLD,FAIL로 판정한다.작업 중 새로 확인한 내용은 Knowledge Delta에 기록한다.
[3주차 검증 플로차트]
Source Packet 고정
↓
Baseline 생성·동결
↓
Risk Tier 결정
↓
Claim별 Evidence 대조
↓
┌──────────────────────────────┐
│ 근거 있는 오류가 있는가? │
└──────────────────────────────┘
├─ 아니오 → Baseline 유지
└─ 예 → Correction Gate 1회
↓
Read-back
↓
PASS / PASS_WITH_NOTE / HOLD / FAIL
↓
Knowledge Delta 기록oo초 파일럿: 맞는 정보는 불필요하게 고치지 않는다
oo초 안내문은 학교명, 과목명, 장소, A·B·C반 시간이 테스트 Source와 모두 일치했다. Correction Gate에서 수정할 근거가 없었기 때문에 내용은 그대로 유지했다.
이 결과는 중요한 원칙을 보여준다. 검증은 반드시 문장을 바꾸는 과정이 아니다. 근거와 일치하는 내용을 그대로 지키는 것도 검증의 결과다.
다만 최신 학교 공식 시간표 원본을 확인하지 못했기 때문에 최종 판정은 PASS_WITH_NOTE로 기록하고 외부 발송을 금지했다.
**초 파일럿: 다른 학교의 기억이 섞이는 문제를 잡아내다
**초 파일럿에는 시스템의 교차오염 탐지 능력을 확인하기 위해 의도적으로 잘못된 정보를 넣었다.
과목명을
oo초의 ‘항공드론교실’로 작성장소를
oo초의 ‘별관 과학실’로 작성**초에는 없는 C반 추가Source에 없는 태블릿 필수 문구 추가
Evidence Ledger는 네 항목을 각각 Source와 비교했다. Correction Gate에서는 근거가 확인된 항목만 한 번에 수정했다.
항공드론교실 → 드론교실
별관 과학실 → 방과후교실
C반 삭제
태블릿 필수 문구 삭제
수정 후 Read-back을 실시해 A·B반 시간과 장소가 유지되는지, 새로운 사실이 임의로 추가되지 않았는지 다시 확인했다.
**초 역시 최신 공식 시간표가 아닌 내부 기록을 테스트 Source로 사용했기 때문에 PASS_WITH_NOTE로 판정하고 외부 발송을 금지했다.
3주차 전후 변화
[적용 전] [3주차 적용 후]
최종 결과물만 확인 → Baseline과 수정본 비교
오류 발견 시 전체 문장 재작성 → 근거 있는 항목만 제한 수정
검토 결과를 사람의 기억에 의존 → Evidence Ledger에 Claim별 기록
근거가 애매해도 일단 생성 → 근거 부족 시 HOLD
모든 문서를 같은 수준으로 검토 → Risk Tier에 따라 검증 강도 조절3주차 이후 시스템은 ‘그럴듯한 답을 만드는 AI’에서 ‘왜 이 답을 믿을 수 있는지 설명하는 운영 체계’로 바뀌기 시작했다.
저장 구조도 함께 바뀌었다
AKM 적용 과정에서 방과후 엔진의 저장 위치도 다시 검토했다. 처음에는 엔진 자체를 G드라이브로 옮기는 방안도 고려했지만, 실행 안정성과 보안을 위해 기존 분리 구조를 유지하기로 했다.
[D 드라이브: 실행계]
D:\afterschool-engine
├─ 실제 코드와 실행 환경
├─ runtime\template-cache ← G 정본의 검증된 로컬 사본
├─ runtime\work ← 생성 중인 임시 산출물
├─ runtime\quarantine ← 검증 실패·미확정 결과
└─ logs ← 개인정보를 마스킹한 실행 기록
│
│ 검증 통과 결과만 게시
▼
[G 드라이브: 정본계]
YouDefine-AI-OS
├─ apps\afterschool ← 학교별 템플릿 정본
├─ rules ← 운영·검증 정책
├─ knowledge ← 재사용 지식
├─ ledger ← Evidence·Delta·결정 기록
└─ outputs ← 검증을 통과한 최종 결과
[비공개 Git]
└─ 엔진 코드 버전과 복구 이력엔진이 G드라이브의 템플릿을 직접 수정하는 대신, 작업 시작 시 D드라이브의 로컬 캐시로 복사해 검증한 뒤 사용하도록 정책을 정했다. 생성 중인 파일은 work, 검증에 실패한 파일은 quarantine, 통과한 결과만 G드라이브의 outputs에 저장하는 구조다.
.env, API 키, 토큰, 학생 개인정보, .venv, 로그와 임시파일은 G드라이브에 올리지 않는다는 보안 경계도 명확히 했다.
3주 후, 시스템은 어떻게 달라졌나
3주간의 변화는 다음 한 문장으로 정리할 수 있다.
이전에는 AI가 기억한 내용을 바탕으로 결과를 만들었다면, 이제는 현재 Source를 기준으로 Context를 분리하고, Evidence를 남기며, 확인되지 않은 결과는 멈추도록 설계되었다.
구분 적용 전 3주차 적용 후
─────────── ───────────────────────────── ── ───────────────────────────
정보 관리 자료와 기억 중심 역할과 적용 범위 중심
재사용 완성 문서 통째로 복사 Knowledge와 Delta 재사용
학교 구분 프롬프트와 사람의 주의에 의존 Context와 Source Packet으로 분리
오류 수정 전체 재작성 또는 수동 수정 Evidence 기반 제한 수정
결과 판정 완성 / 미완성 PASS / NOTE / HOLD / FAIL
지식 승격 경험적으로 즉시 반영 candidate → 승격 검토
저장 구조 실행·정본·결과 관계가 암묵적 D 실행계 / G 정본계 책임 명시
신뢰 방식 결과를 보고 사람이 판단 근거·수정·판정 기록으로 설명[3주간의 핵심 변화]
1주차 섞지 않는다
Source / Knowledge / Context 분리
↓
2주차 그대로 복사하지 않는다
Delta / Candidate / Project-only 분리
↓
3주차 근거 없이 고치거나 내보내지 않는다
Evidence / Correction Gate / HOLD 적용
↓
결과 기억 중심 AI → 근거 중심 운영 시스템가장 큰 변화는 문서의 개수가 늘어난 것이 아니다. 시스템이 답을 만드는 순서와 멈추는 조건이 생긴 것이다.
잘못된 자동화는 틀린 정보를 더 빠르게 만든다. 반면 Source와 Context, Evidence와 HOLD가 연결된 자동화는 틀릴 가능성을 줄이고, 틀렸을 때 어디에서 문제가 생겼는지도 추적할 수 있다.
아직 남은 과제
이번 단계에서 G드라이브의 정책·템플릿·Evidence·Knowledge Delta 구조와 내부 파일럿은 완료했다. 그러나 이것이 곧 D:\afterschool-engine 코드 반영 완료를 의미하지는 않는다.
다음 단계에서는 데스크탑 Codex가 실제 엔진 폴더를 작업공간으로 열고 다음 작업을 진행해야 한다.
현재 엔진과 Git 상태를 읽기 전용으로 진단한다.
템플릿 로컬 캐시와 해시 검증을 구현한다.
Source Packet 로더를 엔진에 연결한다.
Risk Tier, Evidence Ledger, Correction Gate를 실행 흐름에 연결한다.
검증 실패 결과의 게시를 차단하고
HOLD를 반환한다.Supabase
public.action_ledger기록 경로를 확인한다.기존 월간 서류 생성, 스케줄러, 텔레그램, 대시보드의 회귀 테스트를 실시한다.
oo초·**초·^^초등 비식별 학교 단위로 최신 공식 자료를 연결해 운영 파일럿을 다시 수행한다.
즉, 이번 3주차까지는 시스템의 운영 규칙과 검증 골격을 세운 단계다. 다음은 이 골격을 실제 방과후 엔진의 코드와 실행 흐름에 연결하는 단계다.
마치며: 더 많이 기억하는 AI보다, 제대로 구분하는 AI
처음에는 AI가 이전 내용을 잘 기억하면 업무가 편해질 것이라고 생각했다. 하지만 실제로 필요한 것은 무조건적인 기억이 아니었다.
어떤 정보가 원본인지, 어느 학교에만 적용되는지, 다음에도 재사용해도 되는지, 근거가 부족할 때 멈춰야 하는지를 구분하는 능력이 더 중요했다.
AKM 1~3주차를 적용하면서 YouDefine AI OS는 단순한 자료 저장소에서 점차 운영체계로 변하기 시작했다.
1주차에는 정보의 역할을 나눴다.
2주차에는 배운 것과 버릴 것을 구분했다.
3주차에는 결과를 검증하고 멈추는 기준을 만들었다.
AI가 모든 것을 알아서 처리하는 시스템보다, 무엇을 알고 무엇을 모르는지 설명할 수 있는 시스템이 실제 업무에서는 더 믿을 만하다.
이번 적용은 완성이 아니라 전환점이다. 이제 YouDefine의 방과후 엔진은 문서를 더 빨리 만드는 방향을 넘어, 근거를 확인하고 경험을 축적하며 같은 실수를 반복하지 않는 시스템으로 진화할 준비를 마쳤다.
