데이터 관리 방식 검토
성능 시뮬레이션 산출물을
어떻게 저장하고 관리할 것인가
RAG · wiki · 표/DB를 비교하고, 우리 경우의 답을 정한 기록
이 자료는 초안이다. 도식 다섯 점은 완성되었고, 나머지 그림 계획은
취소했다 — 슬라이드 안의 박스·표로 이미 같은 것을 말하고 있어서다.
예시의 파라미터·메트릭 이름은 전부 자리표시자이며, 사내에서 실제 값으로 교체한다.
← → 이동 · O 목차 · P 인쇄
요약 1 / 2
무엇을 비교했고, 각각이 무엇인가
AI가 우리 데이터를 쓰게 하는 방법으로 네 가지를 놓고 봤다.
| 후보 | 한마디로 | 잘하는 것 | 못하는 것 |
|---|---|---|---|
| 기준선 | 문서를 그냥 쌓아두고 AI가 뒤져서 찾게 한다 | 규격 자유, 준비 비용 0 | 건수가 늘면 감당 안 됨 |
| RAG | 뜻이 비슷한 문서 조각을 골라 건네준다 | 말이 달라도 찾음 | 세기·평균·정확 조회. 틀려도 티가 안 남 |
| wiki | 알아낸 것을 정리해 두고 링크로 잇는다 | 결론이 남음, 관계 표현 | 누가 써야 함. 낡아도 티가 안 남 |
| 표 · DB | 수치를 레코드로 쌓아 계산한다 | 계산·비교가 정확 | 맥락과 이유가 안 담김 |
셋 다 서로 다른 문제를 푼다. 경쟁 관계가 아니다.
요약 2 / 2 · 결론
결론 — LLM-wiki + α
RAG는 빠졌고 wiki가 남았다. 다만 일반 wiki 그대로는 부족했다.
LLM-wiki
정리된 지식을 문서와 링크로 쌓는다
+
α — 피드백 장치 셋
| ① 자동 축적층 | 수치는 표로, 진단 기록은 로그로 쌓인다 |
| ② 진단 순서도 | 설명이 아니라 “무엇부터 보는가”라는 절차 |
| ③ 자기 채점 | 적중률로 스스로 점수를 매기고, 모르는 곳을 드러낸다 |
무엇을 제공하나
- 새 결과에 관련 과거 자동 첨부
- 원인 후보를 순위와 함께 좁혀 제시
- 알던 효과인가 새 현상인가 판별
- 증상별 진단 절차 제시
- 새 결과가 흔드는 기존 결론 탐지
- 모르는 영역 표시 · 지식 성숙도 측정
특징
- 검색 장치를 만들지 않는다 — 파일과 AI뿐
- 성격에 따라 넷으로 나눠 담는다
- 실패에서 자란다
- 진짜 목적은 결과 보관이 아니라 머릿속 판단 기준의 외부화
α가 없으면 wiki는 낡아서 죽는다.
쓰고 나면 맞는지 아무도 모르기 때문이다. α는 그 약점에 대한 대응이다.
설명은 본문. 석을 한 장으로 보면 위와 같다.
1부 · 배경
문제 — LLM에는 두 가지 한계가 있다
RAG도 wiki도, 같은 하나의 문제를 서로 다르게 푼 답이다.
(가) 모르는 건 모른다
LLM은 학습 시점까지의 공개 자료로 만들어졌다.
어제 돌린 시뮬레이션 결과는 그 안에 없다. 앞으로도 없다.
지식 컷오프 · knowledge cutoff
(나) 한 번에 읽을 수 있는 양이 정해져 있다
한 번에 볼 수 있는 분량에 상한이 있다.
문서가 수만 건이면 “전부 읽고 답해”는 성립하지 않는다.
컨텍스트 윈도 · context window
남는 질문은 하나다. 필요한 것만 골라서 앞에 놓는 방법은 무엇인가.
1부 · 배경
갈림길 — 모델을 바꾸나, 읽힐 것을 바꾸나
① 모델 자체를 바꾼다
우리 데이터로 다시 훈련한다.
비싸고, 느리고, 갱신이 어렵다.
비싸고, 느리고, 갱신이 어렵다.
추가 학습 · 파인튜닝 / fine-tuning
vs
② 모델은 그대로, “무엇을 읽히느냐”를 바꾼다
질문할 때 자료를 같이 건넨다.
★ 여기에 RAG와 wiki가 있다.
★ 여기에 RAG와 wiki가 있다.
문맥 주입 · context injection
RAG와 wiki는 모델을 건드리지 않는다.
둘 다 “질문받는 순간 모델 앞에 무엇을 놓아줄 것인가”에 대한 답이다.
둘 다 “질문받는 순간 모델 앞에 무엇을 놓아줄 것인가”에 대한 답이다.
1부 · 전체 조망
네 가지 방식 — 먼저 전체를 놓고 본다
새 방식만 놓고 보면, 기존 방식이 무엇을 이미 해결하고 있었는지 안 보인다.
| 문서 관리 | DB · 표 | RAG | wiki | |
|---|---|---|---|---|
| 무엇을 저장하나 | 문서를 그대로 | 수치를 레코드로 | 문서 + 의미 좌표 | 정리된 결론 |
| 어떻게 찾나 | 폴더 · 파일명 · 본문 검색 | 조건 질의 | 뜻이 가까운 조각 | 목차 · 링크를 타고 |
| 누가 정리하나 | 아무도 | 스키마 설계자 (처음 한 번) | 아무도 | 사람 또는 AI (계속) |
| 잘 답하는 질문 | “그 파일 어디 있지” | “몇 건이고 얼마인가” | “이런 얘기 있었나” | “그래서 뭘 알아냈나” |
| 무너지는 지점 | 건수가 늘면 감당 불가 | 맥락과 이유가 안 담김 | 셈 · 정확 조회. 조용히 틀림 | 쓰는 비용. 낡아도 티가 안 남 |
| 준비 / 유지 비용 | 없음 / 없음 | 스키마 설계 / 낮음 | 색인 구축 / 낮음 | 없음 / 높음 |
이미 쓰고 있는 방식
문서 관리 · DB · 표
무엇을 하는지 안다. 설명이 필요 없다
무엇을 하는지 안다. 설명이 필요 없다
이번 검토 대상
RAG · wiki
무엇을 더 해주는지가 이 검토의 질문이다 — 다음 두 장
무엇을 더 해주는지가 이 검토의 질문이다 — 다음 두 장
표를 가로로 읽으면 이미 한 가지가 드러난다.
네 방식이 서로 다른 칸에서 무너진다.
같은 문제를 놓고 경쟁하는 관계가 아니라는 뜻이다.
1부 · 후보 1
RAG — 노트를 전부 읽어본 조수
검색 증강 생성 · Retrieval-Augmented Generation
질문이 들어오면 관련 있는 문서 조각을 찾아내,
질문과 함께 LLM에게 건네주는 방식.
연구실에 실험 노트가 5,000권 쌓여 있다. 여기에 노트를 전부 읽어본 조수가 한 명 있다고 하자.
“확산 조건에서 뭔가 이상했던 기록 있었나?” 하고 물으면, 조수는 서고로 가서 관련될 만한 몇 쪽을 복사해서 가져온다. 5,000권을 다 가져오지 않는다. 요약해 주지도 않는다.
| 조수의 특징 | 뜻 |
|---|---|
| 말이 정확히 일치하지 않아도 찾는다 | “느려짐”이라 물어도 “지연 증가”라 적힌 쪽을 찾아온다 — 의미 검색 |
| 항상 정해진 수만큼 가져온다 | 없어도 5쪽을 가져온다 — 상위 k개 · top-k |
| 판단은 하지 않는다 | 해석은 LLM과 사람의 몫이다 |
1부 · 후보 1
RAG 동작 — 세 단계
사전 준비 · 딱 한 번, 그리고 새 문서마다
문서를 잘게 쪼갠다
청킹 · chunking
→
각 조각에 “의미 좌표”를 매겨 보관
뜻이 비슷하면 가까운 자리에 놓인다
임베딩 · embedding / 벡터 저장소
질문이 들어올 때마다
질문도 좌표로
→
가까운 조각 N개를 꺼냄
벡터 · 유사도 검색
→
질문 + 조각을 LLM에 전달
→ 답
“의미 좌표” 하나만 이해하면 된다. 글을 숫자 묶음으로 바꿔서,
뜻이 가까운 글은 가까운 숫자가 되게 만드는 장치다.
그래서 단어가 달라도 찾힌다 — 이것이 RAG가 단어 일치 검색보다 나은 유일한 지점이다.
1부 · 후보 1
RAG가 잘하는 것 / 못하는 것
이 슬라이드의 오른쪽이 이 발표에서 가장 중요하다.
잘하는 것
- 표현이 달라도 찾는다 — 용어를 몰라도 질문 가능
- 원본을 안 건드린다 — 있는 그대로 넣으면 됨
- 새 문서 반영이 빠르다 — 색인만 추가
- 양에 눌리지 않는다 — 꺼내는 건 N개뿐
- 출처가 남는다
못하는 것
- 셈을 못 한다 — 유사도는 비슷함이지 큼이 아니다
- 집계를 못 한다 — 평균·분포는 검색이 아니라 계산
- 정확 조회가 약하다 — 조건 일치는 유사도의 일이 아니다
- 맥락이 잘린다 — 조각으로 쪼개므로
- ★ 조용히 틀린다
- 정리는 안 해준다 — 매번 처음부터
조용한 실패 — 답이 없어도 가장 덜 관련 없는 조각을 가져온다.
사람은 “이건 관련 없네” 하고 넘기지만, AI는 받은 조각을 근거로 답을 만든다.
근거가 엉뚱해도 답은 그럴듯하게 나온다.
완화 수단은 있다 — 단어 검색을 섞거나(하이브리드 검색),
꺼낸 것을 다시 걸러낸다(재순위). 다만 비용이 늘고, 없앨 수는 없다.
1부 · 후보 2
wiki — 선배가 써둔 정리 노트
지식베이스 · knowledge base
알아낸 것을 주제별 문서로 정리하고, 문서끼리 링크로 이어 둔 저장소.
같은 연구실. 이번엔 조수가 아니라 선배가 써 둔 정리 노트가 있다. 노트에는 실험 원본이 아니라 이렇게 적혀 있다.
“확산 조건에서는 B가 임계값을 넘으면 지연이 급증한다.
실험 #142, #187, #203에서 반복 확인. 원인은 → [버퍼 포화] 항목 참조.”
실험 #142, #187, #203에서 반복 확인. 원인은 → [버퍼 포화] 항목 참조.”
이건 발췌가 아니라 결론이다. 그리고 링크가 달려 있다.
누군가 이미 5,000권을 읽고 판단까지 해서 적어둔 것이다.
누군가 이미 5,000권을 읽고 판단까지 해서 적어둔 것이다.
1부 · 후보 2
wiki 구조 — 항목 · 링크 · 인덱스
[ 목차 / 인덱스 ]
│
┌────────┼────────┐
▼ ▼ ▼
[항목 A] [항목 B] [항목 C]
│ ↕ │
└────► 서로 링크 ◄──┘
| 장치 | 역할 |
|---|---|
| 항목 page / node | 한 항목 = 한 주제. 여기에 결론이 적힌다 |
| 링크 link / backlink | 관련 항목을 이어 준다. AI가 타고 이동하는 길 |
| 인덱스 index | 위에서 아래로 좁혀 들어가는 진입점 |
RAG가 “질문 → 조각”이라면, wiki는 “입구 → 항목 → 링크 → 항목”이다.
찾는 게 아니라 걸어 들어간다.
찾는 게 아니라 걸어 들어간다.
1부 · 후보 2
wiki가 잘하는 것 / 못하는 것
오른쪽 위 셋이 나중에 α가 필요한 이유가 된다.
잘하는 것
- 결론이 남는다 — 500번의 교훈이 한 페이지로
- 매번 다시 읽지 않는다 — 판단이 문서 안에
- 관계를 표현한다 — 검색으로는 못 하는 것
- 사람도 그대로 읽는다
- 없는 게 보인다 — 빈 항목이 눈에 띈다
- 경로가 추적된다
못하는 것
| ① 누군가 써야 한다 | 자동 생성물이 저절로 위키가 되지 않는다 |
| ② 낡는다 | 틀려도 티가 안 난다 |
| ③ 안 쓴 건 못 찾는다 | 정리 안 한 축의 질문에 무력 |
| 개별 조회에 약하다 | 원본 수치는 위키가 답할 일이 아니다 |
| 주관이 들어간다 | 틀린 판단이 그대로 유통된다 |
비용의 성격이 RAG와 다르다.
RAG의 비용은 처음에 든다(색인 구축). wiki의 비용은 계속 든다(쓰고 고치기).
1부 · 핵심
핵심 차이 — 찾기 vs 정리하기
RAG는 “찾아주는” 기술이고, wiki는 “정리해 두는” 방식이다.
하나는 검색 문제를 풀고, 다른 하나는 이해 문제를 푼다.
서로 다른 문제를 풀기 때문에 — 경쟁 관계가 아니다.
하나는 검색 문제를 풀고, 다른 하나는 이해 문제를 푼다.
서로 다른 문제를 풀기 때문에 — 경쟁 관계가 아니다.
| RAG | wiki | |
|---|---|---|
| 다루는 것 | 원본 뭉치 그대로 | 정리된 지식 |
| 일하는 시점 | 질문받는 순간 | 미리 (쓰는 시점) |
| 누가 정리하나 | 아무도. 기계가 찾기만 | 사람 또는 AI가 씀 |
| 결과물의 성격 | 발췌 — “이 부분에 있다” | 결론 — “이렇더라” |
| 초기 / 지속 비용 | 중간 / 낮음 | 낮음 / 높음 |
| 답이 없을 때 | 그럴듯한 발췌를 준다 | 항목이 비어 있다 |
| 실패가 보이나 | ✗ 안 보임 | ✓ 보임 |
1부 · 정리
네 가지 질문, 네 가지 답
“그 얘기 어디 있더라?”
찾기
RAG
“그래서 뭘 알아냈지?”
이해
wiki
“몇 건이고 얼마인가?”
계산
표 · DB
“일단 다 뒤져봐”
탐색
기준선
연구실 서고로 다시 보면
| 방식 | 서고에서는 |
|---|---|
| 개별 문서를 그냥 쌓아둠 | 실험 노트가 서랍에 쌓여 있음 |
| 표 · DB | 실험 대장 — 날짜·조건·결과 수치가 표로 |
| RAG | 노트를 다 읽어본 조수 — 물으면 해당 쪽을 복사해 옴 |
| wiki | 선배의 정리 노트 — “이 조건에선 이렇더라”가 문장으로 |
다른 질문이다. 하나로 다 풀려고 하면 어느 하나도 잘 안 된다.
셋 다 있는 연구실이 제일 좋다는 점도 이 비유가 자연스럽게 보여준다.
1부 · 정리
흔한 오해 네 가지
① “우리 데이터를 AI에게 학습시키는 것”
아니다. RAG도 wiki도 모델을 바꾸지 않는다.
질문할 때 자료를 같이 건네주는 것뿐이다.
모델을 실제로 바꾸는 것은 추가 학습이고, 다른 길이다.
② “RAG를 붙이면 다 해결된다”
RAG는 검색이다. 세기·평균·정렬·조건 일치는 검색으로 풀리지 않는다.
수치를 다루는 질문이 많다면 RAG는 오히려 표·DB보다 못하다.
③ “wiki는 사람 보는 문서니까 AI와 무관”
읽는 주체가 LLM이면 쓰는 방식이 달라진다.
한 항목 = 한 주제, 명시적 링크, 일관된 구조, 기계가 읽는 정보표가 중요해진다.
④ “둘 중 뭘 고를까”
배타적이지 않다. 고를 것은 방식이 아니라
어디에 비용을 쓸 것인가다.
2부 · 요구사항
어떤 데이터가 나오고, 무엇을 얻으려 하나
설정
파라미터 값들. 전체는 아주 많지만 실험에서 변하는 것은 10개 이내
고정 + 변동
결과
성능 수치. 주요 항목 10개 이내. 나중에 늘어날 수 있음
스키마 고정
해석 (선택)
사용자 리뷰 의견 · AI 분석. 모든 실행에 붙지는 않음
사후 추가
| 핵심 성질 | 따라오는 결과 |
|---|---|
| 실행 1건 = 수치 약 20개 | 문서 한 편이 아니라 표의 한 줄에 가깝다 |
| 결과 항목은 고정, 조건만 바꿔 비교 | 비교의 대상이 표다 |
| 해석은 나중에 덧붙는다 | 한 번 쓰고 끝나는 구조가 아니다 |
얻으려는 것은 개별 실험 수치가 아니다.
여러 실행을 가로지르는 인사이트이며, AI는 조회 도구가 아니라 함께 분석하는 상대로 쓴다.
여러 실행을 가로지르는 인사이트이며, AI는 조회 도구가 아니라 함께 분석하는 상대로 쓴다.
2부 · 검토 결과
RAG는 왜 빠졌나
세 가지 이유가 겹쳤다.
① 데이터의 성격
산출물이 설정 + 결과 수치였다. 표에 가까워 의미 검색의 대상이 아니다
§6.1
② 필요한 연산
“관련 있는 과거 실행 찾기”는 수치 비교다.
글을 숫자로 바꾸는 단계가 애초에 불필요하다
§6.3
③ 목표의 성격
얻으려는 것이 인사이트인데, RAG는 표본을 주고
비교·추론에는 모집단이 필요하다
결정적
압축 방식이 다르다
RAG — 선택해서 압축
관련된 N조각을 고른다
→ 표본이 남는다
→ 표본이 남는다
표 · wiki — 증류해서 압축
전부를 요약한다
→ 모집단이 남는다
→ 모집단이 남는다
경향에서 벗어난 지점을 보려면 전체가 필요하다.
RAG는 그것을 보여주지 못한다.
2부 · 되짚기
되짚어 보니 — 문제를 잘못 잡고 있었다
처음 질문
“수만 건을 어떻게
저장하고 검색할까”
저장하고 검색할까”
→
검토를 진행할수록
필요한 장치가 계속 줄었다.
벡터 검색도, 사전 집계 계층도 빠졌다
벡터 검색도, 사전 집계 계층도 빠졌다
→
이유
저장·검색이 문제가
아니었기 때문이다
아니었기 때문이다
실제 문제는 판단 지식이 사람 머릿속에만 있다는 것이었다.
결과가 수만 건 쌓여도, 해석하는 지식이 밖에 나와 있지 않으면 아는 건 늘지 않는다.
결과가 수만 건 쌓여도, 해석하는 지식이 밖에 나와 있지 않으면 아는 건 늘지 않는다.
2부 · 답 (1)
무엇을 어디에 저장하나 — 성격에 따라 넷으로
구체 · 대량 · 자동으로 쌓임추상 · 소량 · 사람이 씀
실행 레코드
설정 + 결과 수치 → 표 한 줄. 문서로 만들지 않는다
수만 건
해석
리뷰 · AI 분석 → 실행에 귀속된 문서. 선별 작성
수백 건
인사이트
횡단 결론 → 별도 층 + 근거 실행 번호
수십~수백
진단 순서도
어디부터 보나 / 왜 그런가 → 나무 구조 + 지식 문서
트리 1개
왜 수치를 문서로 만들지 않나
실행 1건이 수치 20개다. 문서로 만들면
제목·머리말·표 골격이 내용보다 크다.
수만 개 파일이 생기는데 담긴 것은 한 줄 분량이고,
비교하려면 어차피 표로 다시 모아야 한다.
왜 결론을 따로 모으나
“실행 #142, #187, #203에서 반복 확인”이라는 결론은
어느 한 실행에 속하지 않는다.
개별 문서에 흩으면 세 군데에 중복되거나 어디에도 남지 않는다.
이것이 wiki가 필요한 이유다.
★ 출처를 반드시 구분한다 —
measured(측정) ·
human(사람) ·
llm(AI 추론).
구분하지 않으면 AI가 자기 과거 추측을 사실로 받아 강화한다.
근거는 늘지 않았는데 확신만 느는 상태가 된다.2부 · 답 (2)
답 — 진단 순서도
wiki에 담을 것은 설명이 아니라 절차다.
설명형
“버퍼가 포화되면 지연이 늘어난다”
→ 맞는 말이지만, 지금 무엇을 해야 할지는 안 알려준다
절차형
“지연이 이상하면 → 먼저 버퍼 점유율을 본다
→ 임계 근처면 버퍼 포화 의심 (12번 중 9번 맞았다)
→ 아니면 다음으로 클럭을 본다”
→ ★ 바로 쓸 수 있다
지연이 기대보다 낮다 ├─ 1. 버퍼 점유율을 본다 │ 임계 근처? ── 예 ──▶ 버퍼 포화 의심 (12번 중 9번 적중) │ └─ 아니오 ─▶ 2로 ├─ 2. 클럭을 본다 │ 기준 이하? ── 예 ──▶ ... │ └─ 아니오 ─▶ 3으로 └─ 3. 아는 것으로는 안 잡힘 ← ★ 여기가 중요하다
절차형이 실제 지식의 형태다.
숙련자의 머릿속에 있는 것도 설명 목록이 아니라 “이럴 땐 여기부터”라는 순서다.
각 갈림길에는 “왜 그 조건인가”를 설명하는 문서가 딸린다.
2부 · 핵심
모르는 곳이 드러난다 — 그리고 실패에서 자란다
RAG
답이 없어도 그럴듯한 발췌를 준다
→ 모른다는 것을 모른다
→ 모른다는 것을 모른다
순서도
답이 없으면 “안 잡힘”으로 떨어진다
→ ★ 모른다는 것이 드러난다
→ ★ 모른다는 것이 드러난다
안 잡힌 사례가 쌓인 자리가 곧 우리가 모르는 영역의 지도다.
인지된 결손은 채워 넣으면 된다. 모르는 줄 모르는 것과는 처지가 다르다.
인지된 결손은 채워 넣으면 된다. 모르는 줄 모르는 것과는 처지가 다르다.
어떻게 자라는가
새 결과 도착
│
▼
순서도를 태운다
│
├── 잡힘 ──▶ 확인한다 ──▶ 적중 기록 ──▶ 그 길의 신뢰도 상승
│
└── 안 잡힘 ─▶ 따로 조사 ──▶ 원인 찾으면 ──▶ ★ 새 갈림길 추가
│
◀────────────────────────────────────────────────────────┘
다음엔 이 증상을 잡을 수 있다
아래쪽 가지가 성장 경로다.
안 잡힌 사례를 버리면 순서도는 처음 만든 상태에서 멈춘다.
2부 · 지금 할 일
지식은 일하면서 나오게 한다
“아는 걸 다 적어보세요”는 되지 않는다. 사람은 자기 지식을 그런 식으로 꺼내지 못한다.
사람이 판단한다
“이건 버퍼 쪽 같은데”
1
AI가 되묻는다
“왜 그렇게 보셨습니까?”
2
사람이 답한다
“그 값이 임계 근처면 보통 거기부터 봅니다”
3
그것이 갈림길이 된다
순서도에 노드 추가
4
적어야 할 것은 결론이 아니라 판단의 이유다.
결론만 적으면 다음에 재사용할 수 없다.
그래서 AI의 역할이 단계마다 다르다
| 시기 | 지식 상태 | AI가 하는 일 | 기대치 |
|---|---|---|---|
| 초기 ← 지금 | 대부분 사람 머릿속 | 물어보는 사람 | 분석 못 함. 정상 |
| 중기 | 순서도 골격이 생김 | 태워보고 빈 곳을 짚어줌 | 일부 자동 판정 |
| 후기 | 지식 문서가 쌓임 | 분석하는 사람 | 대부분 자동 후보 제시 |
지금은 초기다. AI에게 분석을 기대할 때가 아니라
지식을 꺼내게 할 때다. 이걸 모르고 시작하면 “왜 분석을 못 하지”에서 멈춘다.
2부 · 사례 (1)
무엇을 만드는가 — 시뮬레이션 작업 저장소
결론(LLM-wiki + α)을 우리 업무에 그대로 옮긴 도구다.
결과가 쌓이는 저장소에 AI를 붙여,
등록 → 진단 → 지식화가 일하는 흐름 속에서 저절로 일어나게 한다.
wiki를 “따로 쓰는” 시간은 없다.
축적층
실행 결과는 표 한 줄, 진단 기록은 로그 한 줄. 아무도 손으로 쓰지 않는다
α①
지식층 = wiki
인사이트 문서 · 진단 순서도 · 지식 문서 — 링크로 잇고,
결론마다 근거 실행 번호가 붙는다
본체 + α②
AI (agent)
두 층을 오가는 주체 — 파일을 직접 읽고, 스크립트로 계산하고,
순서도를 타고, 문서 초안을 쓴다
검색 장치 없음
wiki와 데이터가 연계되는 두 방향
① 축적 — 아래에서 위로
실행 → (이상하면) 해석 → (반복 확인되면) 인사이트 → (일반화되면)
순서도의 분기. wiki의 문장은 전부 아래 데이터에서 올라온다.
② 적용 — 위에서 아래로
새 실행 → AI가 순서도를 타고 → 노드가 지목한 수치만 확인 →
필요하면 근거 실행·해석을 연다. wiki가 “무엇을 볼지”를 정한다.
①로 자라고 ②로 쓴다. 같은 자료를 두 방향이 반대로 통과한다.
결론은 근거 실행을 알고 있으므로(역참조), 새 결과가 기존 결론을 흔들면 자동으로 걸린다.
2부 · 사례 (2)
어떻게 돌아가나 — 결과 하나의 일생
사람이 등장하는 곳은 두 군데뿐이다 — 이상 건의 판단, 그리고 검증 방향 결정.
1 · 등록
시뮬레이션이 끝나면 표에 한 줄 + 유사 실행 자동 첨부 + 기존 결론 영향 검사 + 이상 판정.
정상이면 사람을 부르지 않는다
자동
2 · 진단
AI가 순서도를 탄다 → “버퍼 포화 유력 — 12건 중 9번 적중” + 근거 실행 · 지식 문서 링크.
못 잡으면 미분류로 남기고, 관련 축만 비교해 원인 후보를 순위로 제시
AI
3 · 검증
사람이 가설을 고르면 → 가장 가까운 과거 실행에서 그 축 하나만 바꿔 재현 →
재현되면 적중 기록, 아니면 기각
사람 + 자동
4 · 지식 갱신
적중이면 노드 신뢰도 상승. 미분류에서 원인을 찾으면 순서도에 새 분기 —
wiki가 자라는 순간이다
AI 초안
이 도구가 주는 것은 답이 아니라 순위 있는 가설 목록이다.
역할은 어떤 실험부터 돌릴지 정하는 것 —
그리고 그 과정의 부산물로 wiki가 쓰인다.
진단하면서 지식이 나온다. 사람이 “이건 버퍼 쪽 같다”고 하면
AI가 “왜 그렇게 보셨는지”를 되물어 조건·분기·결론으로 구조화한다 —
앞 장 “지식은 일하면서 나오게 한다”가 이 흐름의 2 ↔ 4 사이에서 일어난다.
2부 · 사례 (3)
화면 ① — 쌓이는 것: 실행 표
축적층. 한 실행 = 한 줄, 변한 파라미터만 표시. 화면 속 값은 전부 자리표시자다.
나머지 설정은 스냅샷으로 접혀 있고, 실행을 클릭하면 그 실행에 붙은
해석 · 진단 · 인사이트가 역참조로 열린다 — 수치에서 결론까지 클릭 몇 번이다.
집계·비교는 이 표 위에서 AI가 스크립트로 한다.
2부 · 사례 (4)
화면 ② — AI가 순서도를 탄 기록: 진단 재생
진단 한 건을 되돌려 본 화면. 주황 경로가 AI가 지나간 흐름이다.
갈림길마다 무엇을 읽었고 얼마가 나왔는지가 남는다 —
“param-C / buffer-size = 0.8 → true”. 결론에는 검증 실행, 적중률(9/12),
사람이 남긴 판단 이유까지 붙는다. 이 기록이 다음 wiki 갱신의 근거가 된다.
2부 · 사례 (5)
화면 ③ — 스스로 매기는 점수: 진단 현황
홈 화면. 지표별 트리 현황과 최근 진단이 상태와 함께 보인다.
confirmed · refuted · 미분류가 진단마다 그대로 드러난다.
틀린 진단(refuted)은 순서도를 고칠 신호이고, 미분류가 쌓이는 곳이 지식 공백 지도다 —
“낡아도 티가 안 남”이라던 wiki의 약점이 여기서 채점으로 바뀐다.