세미나 · 데이터 저장 방식 검토
성능 시뮬레이션 산출물,
어떻게 저장하고 관리할 것인가
RAG · LLM-wiki · 표/DB를 나란히 놓고 비교한 뒤 우리 경우의 답을 정하기까지의 기록 — 그리고 그 과정에서 얻은, 개발자가 저장 방식을 고르는 일반 기준.
예시 값은 전부 자리표시자
요약 1 / 3 · 1부의 윤곽
구도 — AI에게 무엇을 읽힐 것인가
LLM은 우리 데이터를 모르고, 안다 해도 한 번에 다 읽지 못한다. 그래서 모든 방식은 결국 하나의 질문을 푼다 — 필요한 것만 골라 모델 앞에 놓는 방법.
요약 2 / 3 · 2부의 윤곽
기준 — 질문이 저장을 정한다
이 구도는 우리 사례를 넘어 일반화된다. 저장 방식 선택은 제품 고르기가 아니라 데이터와 질문의 성격을 적는 일이다.
질문의 모양
비용의 시점
실패의 가시성
요약 3 / 3 · 3부의 윤곽
우리 답 — 저장 문제가 아니라 지식 문제였다
이 기준을 우리 데이터에 적용하자 필요한 장치가 계속 줄었고, 문제 자체가 다시 정의됐다.
산출물은 수치라 표에 쌓으면 되고, 결론은 LLM-wiki에 모으면 된다. RAG는 빠졌다 — 인사이트에 필요한 것은 몇 조각의 표본이 아니라 전체의 모집단이기 때문이다. 남은 진짜 문제는 해석하는 지식이 사람 머릿속에만 있다는 것이었다.
LLM-wiki + α —
스스로 채점하고, 모르는 곳을 드러내고, 실패에서 자라는 wiki다.
수치는 저절로 쌓이고(α①), 지식은 절차로 적히고(α②), 적중률이 낡음을 드러낸다(α③).
답의 전체 윤곽 — α 세 장치가 wiki의 약점 셋에 하나씩 대응한다.
1부
배경과 개념
RAG와 LLM-wiki가 각각 무엇이고, 무엇을 잘하고 못하는지를 먼저 정확히 잡는다. 여기까지는 우리 사례와 무관한 일반 개념이다.
1부 · 여는 관점
이해는 예측이다 — 새 동료와 일을 시작하는 법
기술 이야기 전에, 이 세미나가 서 있는 관점 하나를 먼저 놓는다.
새 동료가 왔다
평판이 아주 좋다 — "정말 똑똑한 사람이 온대." 그 소문만 믿고 아무 일이나 맡기면 어떻게 될까. 어떤 일은 기대 이상으로 해 오고, 어떤 일은 엉뚱하게 해 온다. 그리고 어느 쪽도 미리 알 수 없었다.
협업이 굴러가기 시작하는 것은 그다음부터다 — 무엇을 알고 있는지(도메인 지식), 무엇을 해 왔는지(커리어)를 파악하고, 작은 일을 시켜 결과물을 직접 본 뒤에야 예측이 서고, 맡길 일과 맡기지 않을 일이 갈린다.
LLM도 새 동료다
"아주 똑똑하다"는 소문(벤치마크 점수)만 믿고 아무 일이나 맡기면, 사람 동료 때와 정확히 같은 일이 벌어진다. 그러니 같은 관점으로 파악하면 된다.
| 사람 동료라면 | LLM이라면 |
|---|---|
| 무엇을 알고 있나 — 전공 · 도메인 지식 | 무엇을 학습했나 — 공개 지식은 안다. 우리 데이터는 모르고, 앞으로도 저절로 알게 되지 않는다 |
| 어떻게 일하나 — 습관 · 처리량 | 어떻게 읽나 — 한 번에 읽을 수 있는 양이 정해져 있고, 무엇을 건네주느냐가 결과를 좌우한다 |
| 작은 일을 시켜 보고 결과물을 본다 | 여기도 똑같다 — 맡겨 보고, 결과를 확인하고, 예측 범위를 좁혀 간다 |
이해했다면, 그다음은
사람 동료를 파악한 다음에 우리가 하는 일이 무엇인가 — 일을 잘할 수 있게 자료를 준비해 주는 것이다. 온보딩 문서를 만들고, 흩어진 자료를 정리해 인수인계한다. 준비가 좋을수록 결과가 예측 범위에 빨리 들어온다.
이 세미나 전체가 그 질문에 대한 답이다.
1부 · 왜 이 주제인가
저장이 설계를 정한다 — 자료구조의 교훈
알고리즘이 중요하다는 것은 모두가 안다. 그런데 소프트웨어의 모양을 먼저 정하는 쪽은 대개 자료구조 — 무엇을 어떻게 저장하고, 관리하고, 꺼내 오는가 — 쪽이다.
"순서도(코드)를 보여 주고 표(데이터)를 감추면 나는 계속 어리둥절할 것이다. 표를 보여 주면 순서도는 대개 필요 없다." — 프레드 브룩스, 맨먼스 미신
"나쁜 프로그래머는 코드를 걱정하고, 좋은 프로그래머는 자료구조와 그 관계를 걱정한다." — 리누스 토르발스
구조를 정하는 순간, 할 수 있는 일이 정해진다
같은 데이터라도 어디에 담느냐에 따라 싸게 던질 수 있는 질문이 달라진다. 개발자라면 매일 하는 선택이다.
배열에 담으면
"특정 값 찾기"는 전체 스캔이 된다
해시에 담으면
대신 범위·순서 질문을 잃는다
정렬 트리에 담으면
대신 넣을 때마다 정렬 비용을 낸다
게다가 가장 되돌리기 어려운 결정이다
그리고 읽는 주체가 하나 늘었다
1부 · 기존 지형
익숙한 저장 방식들 — 어디에 강하고, 어디서 무너지나
새것을 보기 전에 이미 손에 있는 도구부터. 각 방식이 어떤 질문에 최적화된 자료구조인지, 그리고 자리를 잘못 잡으면 시스템이 어떻게 앓는지.
| 방식 | 이런 질문에 강하다 | 자리를 잘못 잡으면 — 실제로 벌어지는 일 |
|---|---|---|
| 파일 · 폴더 | "그 파일 그대로 줘." 형식 자유, 도구 없이 시작 | 수만 건에서 "조건에 맞는 것만"을 묻는 순간 — "지난달 평균" 하나 내려고 전부 열어 파싱하는 스크립트부터 짠다. 파일명 규칙이 사실상의 스키마가 되는데, 아무도 강제하지 않아 곧 깨진다 |
| 관계형 DB | 집계 · 조건 일치 · 조인. 트랜잭션 정합성 | 자유 텍스트를 넣고 본문 검색을 시키면 —
LIKE '%지연%'은 색인을 못 타 전체 스캔이 되고,
데이터가 늘면 그 질의 하나가 서비스 전체를 끌어내린다.
모양이 자주 바뀌는 데이터면 마이그레이션이 꼬리를 문다 |
| 키-값 · 캐시 | "이 키의 값." 초고속 단건 조회, 세션 · 캐시 | 관계를 묻기 시작하면 — "값이 X인 키 전부"는 전 키 순회다. "이 사용자의 주문 전부" 같은 역방향 질의가 필요해지는 순간, 애플리케이션 코드가 DB 흉내를 내기 시작한다 |
| 문서형 DB | 건마다 모양이 조금씩 다른 JSON. 스키마 진화가 잦은 초기 제품 | 규율 없이 쌓으면 — 같은 필드가 세 가지 이름과 두 가지 타입으로 존재하게 되고, 집계를 하려는 순간 분석보다 데이터 정제 프로젝트가 먼저 생긴다 |
| 검색엔진 (역색인) |
"이 단어가 들어간 문서 전부." 대량 문서에서 즉답, 랭킹 | 정합성이 필요한 원장으로 쓰면 — 결과는 근사이고 재색인은 늦는다. 그리고 단어가 다르면 뜻이 같아도 못 찾는다 — "느려짐"으로 물으면 "지연 증가"라 적힌 문서는 조용히 빠진다 |
| wiki · 지식베이스 |
"그래서 뭘 알아냈나?" — 정리된 결론, 링크로 이어진 맥락 | 쓰는 품이 끊기는 순간 낡기 시작하는데 낡아도 겉이 멀쩡하다. 몇 년 뒤 절반이 틀렸는데 어느 절반인지 몰라, 결국 다들 문서 대신 옆자리에 묻게 된다 |
1부 · 전환점
새로운 독자 — LLM이 오면서 달라진 것
코드와 사람만 읽던 데이터를 이제 LLM도 읽는다. 그런데 이 셋째 독자에게는 두 가지 타고난 제약이 있다.
㉮ 모르는 것은 모른다
㉯ 한 번에 읽을 수 있는 양이 정해져 있다
갈림길 — 모델을 바꾸나, 읽힐 것을 바꾸나
① 모델 자체를 바꾼다
비싸고, 느리고, 데이터가 바뀔 때마다 다시 해야 한다.
② 모델은 그대로 두고, 읽힐 것을 바꾼다
★ RAG와 LLM-wiki가 모두 여기에 속한다.
더 보기 — "학습이 가능하다면 그쪽이 정답 아닌가?"
질문을 정확히 하면 "무엇을 학습 대상으로 삼을 것인가"다. "성능 분석 지식"은 한 덩어리가 아니라 네 층이고, 층마다 답이 다르다.
| 층 | 구체 예 | 어디에 사는가 | 이유 |
|---|---|---|---|
| A. 사고 방식 | 가설을 세우고 검증, 변인 통제, 상관≠인과 | base 모델 — 이미 학습됨 | 범용, 거의 불변 |
| B. 도메인 일반론 | "버퍼 포화 → 지연 증가", 큐잉 · 캐시 동작 | base 모델 — 이미 학습됨 | 공개 지식, 훈련 데이터에 이미 있음 |
| C. 우리 판단 규칙 | "우리 장비에서 지연 이상이면 점유율부터 (12번 중 9번 적중)" | 진단 순서도 — 외부 | 채점되고 고쳐지는 살아 있는 지식 |
| D. 결과 · 기록 | run 수치, 진단 로그, 적중률 | 표 · 로그 — 외부 | 매일 갱신, 근거 추적 |
A · B는 이미 학습돼 있다. 갈림길에서 ①(모델을 바꾼다)을 안 고른 것은 학습의 거부가 아니라 — base 모델에 학습할 것이 남아 있지 않아서다. 논쟁 지점은 C 하나다.
C를 학습하지 않고 순서도로 두는 이유 — C는 살아 있는 지식이다. 적중률로 채점되고(9/12 → 10/13), 틀리면 그 갈림길만 고치고, 결론마다 근거 실행 번호가 달린다. 가중치에 넣는 순간 셋 다 불가능해진다 — 채점할 수 없고, 하나만 고칠 수 없고, 근거를 못 댄다. C를 학습하면 α(자기 채점)가 통째로 죽는다. C가 굳어 "상식"이 된 먼 시점에야 학습 후보가 되고, 그때의 학습 데이터도 순서도와 로그에서 나온다 — 외부화가 학습의 전제 조건이다.
그래서 실제 동작은 이렇다 — 이슈(증상) + 판단 규칙(C) + 관련 기록(D)을 컨텍스트로 건네고, 사고와 일반론(A · B)은 모델이 담당한다. 학습이 아무리 좋아져도 D의 갱신 속도 · 근거 추적 · 개별 수정 때문에 외부 저장은 남는다 — 학습은 저장의 대체재가 아니라 저장된 것을 더 잘 읽는 독자를 만드는 일이다.
1부 · 빈자리와 새 후보
빈자리 둘, 새 해법 둘 — RAG와 LLM-wiki는 무엇이 다른가
기존 방식에 LLM을 붙이면 수치·조건 질문은 이미 풀린다 — 스키마를 읽고 SQL을 쓰면 된다. 끝내 안 풀리는 질문이 둘 남고, 해법 둘이 각각 하나씩을 맡는다 — 하나는 새 기술(RAG)이고, 하나는 옛 도구를 LLM에 맞게 고친 변종(LLM-wiki)이다.
빈자리 ① — "이런 현상 있었나?"
기존 — 검색엔진 · DB
RAG — 찾는 기준을 바꾼다
빈자리 ② — "그래서 뭘 알아냈나?"
기존 — wiki가 이미 맡아 온 자리다
LLM-wiki — LLM에 맞게 고친 변종
각각이 정확히 무엇이고 어떻게 동작하는지, 그리고 이 교환의 대가로 무엇을 잃는지는 다음 두 절에서 하나씩 본다.
1부 · 후보 1
RAG — 찾아서 건네주는 방식
검색 증강 생성 · Retrieval-Augmented Generation
비유 — 노트를 전부 읽어 본 조수
연구실에 실험 노트가 5,000권 쌓여 있다. 여기에 노트를 전부 읽어 본 조수가 한 명 있다고 하자.
"확산 조건에서 뭔가 이상했던 기록 있었나?" 하고 물으면, 조수는 서고로 가서 관련될 만한 몇 쪽만 복사해서 가져온다. 5,000권을 다 들고 오지 않는다. 그렇다고 요약해 주지도 않는다. 판단은 여전히 묻는 사람의 몫이다.
| 조수의 특징 | 뜻 |
|---|---|
| 말이 정확히 일치하지 않아도 찾는다 | "느려짐"이라고 물어도 "지연 증가"라고 적힌 쪽을 가져온다 — 의미 검색 |
| 항상 정해진 수만큼 가져온다 | 맞는 기록이 없어도 5쪽을 가져온다 — 상위 k개 · top-k |
| 판단은 하지 않는다 | 가져온 조각을 해석하는 것은 LLM과 사람의 몫이다 |
동작 — 준비 한 번, 질문마다 세 단계
위 줄은 미리 하는 준비, 아래 줄은 질문마다 도는 경로. 주황 번호가 실패가 스며드는 세 지점이다.
"의미 좌표" 하나만 이해하면 된다
임베딩은 글을 숫자 묶음(벡터)으로 바꾸는 장치다. 뜻이 가까운 글은 가까운 숫자가 되도록 바꾼다. 그래서 단어가 달라도 검색된다 — 이것이 RAG가 단어 일치 검색보다 나은 유일한 지점이다.
"느려짐"과 "지연 증가"는 단어가 다르지만 좌표가 가깝다. 질문(주황)은 자기 주변의 점들을 끌어온다.
잘하는 것 / 못하는 것
잘하는 것
- 표현이 달라도 찾는다 — 정확한 용어를 몰라도 질문할 수 있다
- 원본을 손대지 않는다 — 있는 그대로 넣으면 된다
- 새 문서 반영이 빠르다 — 색인만 추가하면 끝
- 양에 눌리지 않는다 — 꺼내 오는 것은 어차피 N개뿐
- 어느 문서에서 왔는지 출처가 남는다
못하는 것
- 셈을 못 한다 — 유사도는 비슷하다는 뜻이지 크다·많다가 아니다
- 집계를 못 한다 — 평균·분포는 검색이 아니라 계산의 일이다
- 정확한 조건 조회에 약하다 — "일치"는 유사도의 일이 아니다
- 맥락이 잘린다 — 조각으로 쪼개서 저장하므로
- ★ 조용히 틀린다 — 아래 참조
- 정리는 해 주지 않는다 — 물을 때마다 처음부터
더 보기 — 질문 한 번마다 실제로 일어나는 일
검색(기계)이 끝난 뒤에도 일이 끝난 것이 아니다. 조각을 받아 든 LLM과 질문자에게 다섯 가지가 남는다.
- 읽기 — N개 조각을 처음부터 읽는다. 지난 질문 때 같은 조각을 읽었어도, 그때의 이해는 어디에도 저장되지 않았다
- 거르기 — top-k는 맞는 것이 없어도 개수를 채워 오므로, 어느 조각이 진짜 관련 있는지 판별해야 한다
- 맥락 복원 — 청킹으로 잘린 발췌들을 이어 붙여 전체 그림을 재구성한다
- 조정 — 조각끼리 시점이나 조건이 어긋나면(옛 실험 vs 새 실험) 어느 쪽이 유효한지 판단한다
- 결론 만들기 — 조각은 "이 부분에 있다"는 발췌지 "이렇더라"는 결론이 아니다. "그래서 무엇인가"를 매번 새로 만든다
그리고 이 작업의 결과는 버려진다. 다음 질문이 오면 ①~⑤를 처음부터 반복한다 — §11에서 "읽을 때 낸다"고 부르는 비용의 실체가 바로 이 반복이다.
1부 · 후보 2
wiki — 정리해 두는 방식
지식베이스 · knowledge base
비유 — 선배가 써 둔 정리 노트
같은 연구실이다. 이번에는 조수 대신 선배가 써 둔 정리 노트가 있다. 노트에는 실험 원본이 아니라 이렇게 적혀 있다.
실험 #142, #187, #203에서 반복 확인. 원인은 → [버퍼 포화] 항목 참조."
이것은 발췌가 아니라 결론이다. 그리고 링크가 달려 있다. 누군가 이미 5,000권을 읽고 판단까지 끝낸 결과를 적어 둔 것이다.
구조 — 항목 · 링크 · 인덱스
[ 목차 / 인덱스 ]
│
┌────────┼────────┐
▼ ▼ ▼
[항목 A] [항목 B] [항목 C]
│ ↕ │
└────► 서로 링크 ◄──┘
| 장치 | 역할 |
|---|---|
| 항목 page / node | 한 항목 = 한 주제. 결론이 적히는 자리 |
| 링크 link / backlink | 관련 항목을 이어 준다. AI가 타고 이동하는 길 |
| 인덱스 index | 위에서 아래로 좁혀 들어가는 진입점 |
찾아내는 것이 아니라 걸어 들어간다.
잘하는 것 / 못하는 것
잘하는 것
- 결론이 남는다 — 실행 500번의 교훈이 한 페이지로
- 매번 다시 읽을 필요가 없다 — 판단이 이미 문서 안에 있다
- 관계를 표현한다 — 검색으로는 안 되는 일
- 사람도 그대로 읽을 수 있다
- 없는 것이 보인다 — 빈 항목이 눈에 띈다
- 어떤 경로로 결론에 닿았는지 추적된다
못하는 것 — 앞의 셋이 α의 이유가 된다
| ① 누군가 써야 한다 | 자동 생성물이 저절로 wiki가 되지는 않는다 |
| ② 낡는다 | 내용이 틀려져도 겉으로는 드러나지 않는다 |
| ③ 안 쓴 것은 못 찾는다 | 정리하지 않은 방향의 질문에는 무력하다 |
| 개별 수치 조회에 약하다 | 원본 수치는 wiki가 답할 일이 아니다 |
| 주관이 들어간다 | 틀린 판단도 문서가 되면 그대로 유통된다 |
wiki에서 LLM-wiki로 — 무엇이 달라지나
여기까지는 수십 년 된 wiki 일반의 이야기다. §8에서 말한 변종 — LLM-wiki — 는 같은 wiki 엔진 위에서 쓰는 규율을 바꾼 것이다. 독자가 사람에서 LLM으로 바뀌면 다음이 달라진다.
| wiki (사람용) | LLM-wiki | |
|---|---|---|
| 독자 | 사람 | LLM — 사람도 그대로 읽을 수 있다 |
| 항목의 크기 | 자유 — 주제가 섞인 긴 문서도 흔하다 | 한 항목 = 한 주제. 필요한 항목만 골라 컨텍스트 윈도에 올리는 단위가 되기 때문이다 |
| 링크 | 있으면 편리한 정도 | 필수. AI가 타고 이동하는 길이라, 링크가 없는 지식은 사실상 못 찾는 지식이다 |
| 메타데이터 | 선택 | 기계가 읽는 정보표(frontmatter) — 작성일 · 조건 · 태그 |
| 출처 | 관행에 맡긴다 | 결론마다 근거를 단다. 측정 · 사람 판단 · AI 추론을 구분해서 — 안 그러면 AI가 자기 추측을 사실로 다시 읽는다 |
| 문체 | 독자가 맥락을 알아서 채운다 | 항목 하나만 읽어도 뜻이 서야 한다 — 암묵적 맥락 금지, 용어는 한 가지로 |
1부 · 핵심
핵심 차이 — 찾기 vs 정리하기
하나는 검색 문제를 풀고, 다른 하나는 이해 문제를 푼다.
푸는 문제가 다르므로 — 경쟁 관계가 아니다.
| RAG | LLM-wiki | |
|---|---|---|
| 다루는 것 | 원본 뭉치 그대로 | 정리된 지식 |
| 일하는 시점 | 질문받는 순간 | 미리 — 쓰는 시점 |
| 누가 정리하나 | 아무도. 기계는 찾기만 한다 | 사람 또는 AI가 쓴다 |
| 결과물의 성격 | 발췌 — "이 부분에 있다" | 결론 — "이렇더라" |
| 초기 / 지속 비용 | 중간 / 낮음 | 낮음 / 높음 |
| 답이 없을 때 | 그럴듯한 발췌를 준다 | 항목이 비어 있는 것이 보인다 |
| 실패가 보이나 | ✗ 안 보인다 | ✓ 보인다 |
비용 총량이 아니라 내는 시점이 다르다. 무엇을 고르든 이 곡선 중 하나를 사는 것이다.
더 보기 — 조수 비유로 다시 보면
조수는 복사만 해 온다. 복사본 몇 쪽을 읽고 "그래서 확산 조건에서 무엇이 문제였는지" 알아내는 것은 매번 묻는 사람의 몫이다. 알아낸 것을 적어 두지 않는 한, 다음 질문자도 같은 쪽을 받아 같은 일을 반복한다.
알아낸 것을 적어 두기 시작하는 순간 — 그것이 wiki고, LLM이 읽도록 다듬으면 LLM-wiki다. 두 방식의 관계는 대립이 아니라, 반복되는 읽기 노동을 한 번의 쓰기로 굳히는 이행이다.
결국, 답하는 질문이 다르다
연구실 서고로 다시 보면
| 방식 | 서고에서는 |
|---|---|
| 문서를 그냥 쌓아 둠 | 실험 노트가 서랍마다 쌓여 있다 |
| 표 · DB | 실험 대장 — 날짜·조건·결과 수치가 표로 적혀 있다 |
| RAG | 노트를 다 읽어 본 조수 — 물으면 해당 쪽을 복사해 온다 |
| LLM-wiki | 선배의 정리 노트 — "이 조건에선 이렇더라"가 문장으로 남아 있다 |
1부 · 정리
흔한 오해 네 가지
RAG와 wiki가 화제에 오르는 자리에서 자주 듣게 되는 말들이다.
더 보기 — "임베딩도 벡터를 만드는데, RAG는 작은 학습 아닌가?"
①을 한 겹 더 파면 나오는 질문이고, 직관 자체는 맞다 — 임베딩 모델도 신경망이고 LLM과 같은 기술 계열이며, 둘 다 "글 → 벡터"를 한다. 결정적 차이는 텍스트가 어디로 가는가다.
- 학습 — 텍스트가 모델의 가중치 속으로 녹아들어 사라진다. 어느 문장이 어디 저장됐는지 지목할 수 없으므로 출처를 못 대고, 한 문서만 지우거나 고칠 수 없고, 갱신은 재학습이다. 여기서 벡터(가중치)는 지식 그 자체다
- RAG 색인 — 텍스트는 밖에 원문 그대로 남는다. 임베딩은 문서를 바꾸지 않고 각 조각에 "의미 주소"를 붙일 뿐이며, 검색은 그 주소로 원문을 찾아오는 것이다. 여기서 벡터(임베딩)는 지식이 아니라 색인 키다
그래서 RAG는 "작게 학습한 것"이 아니라 아무것도 배우지 않는다. 학습이 사서의 뇌를 훈련시키는 것이라면, 색인은 서가에 카드 목록을 만드는 것이다 — 카드 목록을 아무리 만들어도 사서가 똑똑해지지는 않는다.
"합쳐서 답을 만든다"는 절반만 맞다. 최종 답은 LLM이 파라미터 지식과 건네받은 조각을 함께 보고 생성하지만, 결합은 비대칭이다 — 조각은 프롬프트에 텍스트로 끼워 넣어질 뿐이고(문맥 주입), 대화가 끝나면 모델은 그 조각을 본 적 없는 상태로 돌아간다.
2부
개발자의 선택 기준
1부의 네 방식을 개발자가 일상적으로 만나는 저장소 전체로 넓힌다. 무언가를 만들 때 "데이터를 어디에 담을까"를 정하는 일반 기준이다.
2부 · 지형도
저장 방식의 지형도
RAG와 wiki는 갑자기 나타난 별종이 아니다. 개발자가 늘 쓰던 저장소 계보의 연장선에 있다.
| 방식 | 데이터의 단위 | 잘 답하는 질문 | 대표 예 |
|---|---|---|---|
| 파일 · 오브젝트 저장 | 파일 통째 | "그 파일 그대로 줘" | 파일시스템, S3 계열 |
| 관계형 DB | 스키마가 정해진 레코드 | 집계 · 조건 일치 · 조인 — "조건별 평균은?" | SQLite, PostgreSQL |
| 키-값 저장소 | 키 하나에 값 하나 | "이 키의 값" — 아주 빠른 단건 조회 | Redis 계열 |
| 문서형 DB | 스키마가 느슨한 JSON | 레코드마다 형태가 조금씩 다른 데이터 | MongoDB 계열 |
| 시계열 DB | 시간축 위의 수치 | 구간 집계 · 추세 — "지난주 p99는?" | 모니터링 지표 저장소 |
| 검색엔진 (역색인) | 문서 속의 단어들 | "이 단어가 들어간 문서 전부" | Elasticsearch 계열 |
| 벡터 저장소 | 의미 좌표 (임베딩) | "뜻이 비슷한 조각" — RAG의 기반 | 벡터 DB, pgvector |
| 그래프 DB | 노드와 간선 | 관계를 따라가는 질문 — "A에 의존하는 것 전부" | 의존 관계 추적 |
| wiki · 지식베이스 | 정리된 결론 문서 | "그래서 뭘 알아냈나" | 사내 wiki, Obsidian 계열 |
가로축 — 정리하는 품을 읽을 때 내는가, 쓸 때 내는가. 세로축 — 다루는 단위가 값·레코드인가, 글·의미인가. RAG(좌하)와 wiki(우하)는 같은 "의미" 줄의 양 끝이다.
2부 · 기준
고르기 전에 던질 다섯 질문
제품 이름부터 고르면 실패한다. 데이터와 질문의 성격을 먼저 적어 보면 답이 거의 정해진다.
2부 · 순서도
선택 순서도
다섯 질문을 실제 결정 순서로 늘어놓으면 이렇게 된다. 위에서부터 처음 "예"가 나오는 곳이 출발점이다.
각 질문에 "예"면 오른쪽 답으로, "아니오"면 아래로. 마지막 줄 — 확신이 없으면 일단 파일이 정직한 기본값이다.
2부 · 원칙
원칙 — 하나로 다 풀지 않는다
데이터의 성격이 다르면 담는 곳도 다른 것이 정상이다.
익숙한 예로, 평범한 웹 서비스 하나도 이미 그렇게 만들어져 있다.
| 데이터 | 담는 곳 | 이유 |
|---|---|---|
| 주문 · 회원 | 관계형 DB | 정확한 집계와 트랜잭션 |
| 세션 · 캐시 | 키-값 저장소 | 빠른 단건 조회, 날아가도 됨 |
| 상품 검색 | 검색엔진 | 단어·오타·랭킹 |
| 이미지 · 첨부 | 오브젝트 저장 | 통째로 넣고 통째로 꺼냄 |
| 운영 노하우 | 사내 wiki | 판단과 맥락이 담김 |
누구도 이것을 이상하게 여기지 않는다. 그런데 AI가 읽을 데이터가 되면 갑자기 "RAG 하나로", "wiki 하나로" 전부 담으려는 유혹이 생긴다. 같은 실수를 이름만 바꿔 반복하는 것이다.
3부
우리 경우 — 성능 시뮬레이션 산출물
2부의 기준을 실제로 적용한 기록이다. 데이터의 성격을 적고, 질문의 모양을 적고,
그 결과로 RAG가 빠지고 LLM-wiki + α가 남기까지.
3부 · 요구사항
어떤 데이터가 나오고, 무엇을 얻으려 하나
Q1(데이터의 단위)부터 적어 본다. 시뮬레이션 한 번이 남기는 것은 셋이다.
| 핵심 성질 | 따라오는 결론 |
|---|---|
| 실행 1건 = 수치 약 20개 | 문서 한 편이 아니라 표의 한 줄에 가깝다 |
| 결과 항목은 고정, 조건만 바꿔 가며 비교 | 비교가 일어나는 곳은 표다 |
| 해석은 나중에 덧붙는다 | 한 번 쓰고 끝나는 구조로는 안 된다 |
그다음 Q2 — 어떤 질문을 던지게 되나
| 질문 종류 | 예 | 누가 주로 | 맞는 방식 |
|---|---|---|---|
| 계산 (집계) | "가장 느린 10건", "조건별 평균" | — | 표 · DB |
| 조회 (정확 일치) | "이 파라미터 조합의 결과" | — | 표 · DB |
| 탐색 (의미 검색) | "이런 현상 기록된 적 있나" | 사람 | RAG |
| 이해 (누적 결론) | "이 조건에서 왜 이렇게 되나" | AI | wiki |
3부 · 검토 결과
RAG는 왜 빠졌나
세 가지 이유가 겹쳤고, 마지막 것이 결정적이었다.
압축하는 방식이 다르다
RAG — 골라서 압축
→ 손에 남는 것은 표본
표 · wiki — 증류해서 압축
→ 손에 남는 것은 모집단의 상(像)
3부 · 되짚기
진짜 문제는 저장이 아니었다
처음의 질문
저장하고 검색할까"
검토가 진행될수록
벡터 검색이 빠지고, 사전 집계 계층이 빠졌다
이유
아니었기 때문이다
결과가 수만 건 쌓여도, 그것을 해석하는 지식이 밖으로 나와 있지 않으면 조직이 아는 것은 늘지 않는다.
3부 · 답 (1)
무엇을 어디에 — 네 개의 층
2부의 원칙("성격이 다르면 담는 곳도 다르다")을 그대로 적용하면 넷으로 갈라진다.
오른쪽으로 갈수록 양은 줄고 가치는 오른다. 주황 점선 — 모든 결론은 자기 근거 실행으로 되짚어 갈 수 있다.
왜 수치를 문서로 만들지 않나
왜 결론을 따로 모으나
measured(측정) · human(사람의 판단) · llm(AI 추론).
구분하지 않으면 AI가 자신의 과거 추측을 사실로 다시 읽어 강화한다.
근거는 늘지 않았는데 확신만 커지는, 가장 위험한 상태다.3부 · 답 (2)
지식을 절차로 적는다 — 진단 순서도
LLM-wiki 층에 담는 지식의 형태가 이 설계의 중심이다. 설명이 아니라 절차로 적는다.
설명형
절차형
지연이 기대보다 낮다 ├─ 1. 버퍼 점유율을 본다 │ 임계 근처? ── 예 ──▶ 버퍼 포화 의심 (12번 중 9번 적중) │ └─ 아니오 ─▶ 2로 ├─ 2. 클럭을 본다 │ 기준 이하? ── 예 ──▶ ... │ └─ 아니오 ─▶ 3으로 └─ 3. 아는 것으로는 안 잡힘 ← ★ 여기가 중요하다
갈림길마다 "무엇을 보는지 · 무엇을 의심하는지 · 지금까지 몇 번 맞았는지"가 함께 붙는다.
3부 · 핵심
모르는 곳이 드러난다 — 그리고 실패에서 자란다
RAG였다면
→ 모른다는 사실 자체를 모른다
순서도는
→ ★ 모른다는 사실이 기록으로 드러난다
보이는 결손은 채우면 된다. 모르는 줄도 모르는 것과는 완전히 다른 처지다.
어떻게 자라는가
위 경로(잡힘)는 신뢰도를 올리고, 아래 경로(안 잡힘)는 새 갈림길이 되어 돌아온다. 아래쪽이 성장 경로다.
3부 · 지금 할 일
지식은 일하면서 꺼낸다
"아는 것을 다 적어 주세요"는 통하지 않는다. 사람은 자기 지식을 그런 식으로 꺼내지 못한다.
그래서 AI의 역할이 시기마다 다르다
| 시기 | 지식의 상태 | AI가 하는 일 | 기대치 |
|---|---|---|---|
| 초기 ← 지금 | 대부분 사람 머릿속 | 물어보는 사람 | 분석은 못 한다. 그것이 정상이다 |
| 중기 | 순서도 골격이 생김 | 순서도에 태워 보고 빈 곳을 짚는 사람 | 일부 자동 판정 |
| 후기 | 지식 문서가 쌓임 | 분석하는 사람 | 후보 대부분을 자동 제시 |
3부 · 사례 (1)
무엇을 만드는가 — 시뮬레이션 작업 저장소
결론(LLM-wiki + α)을 우리 업무에 그대로 옮긴 도구다. 화면은 §26에서 본다.
LLM-wiki와 데이터가 만나는 두 방향
① 축적 — 아래에서 위로
② 적용 — 위에서 아래로
3부 · 사례 (2)
어떻게 돌아가나 — 결과 하나의 일생
사람이 등장하는 곳은 두 군데뿐이다. 이상 건의 판단, 그리고 검증 방향의 결정.
3부 · 사례 (3)
화면 세 장
만들고 있는 도구를 세 화면으로 본다 — 쌓이는 곳, 진단의 기록, 스스로 매기는 점수.
① 쌓이는 것 — 실행 표
② AI가 순서도를 탄 기록 — 진단 재생
③ 스스로 매기는 점수 — 진단 현황
3부 · 경계
이 구조가 못 하는 것
할 수 있는 것만 말하는 설계는 신뢰할 수 없다. 경계를 분명히 긋는다.
| 못 하는 것 | 이유 | 대신 하는 것 |
|---|---|---|
| 원인을 확정한다 | 상관은 계산되지만 인과는 아니다 | 가설 목록을 순위와 함께 제시 |
| 모르는 원인을 찾아낸다 | 순서도에 없는 것은 잡을 수 없다 | "안 잡힘"으로 드러낸다 |
| 비슷한 과거가 없을 때 좁힌다 | 새 영역에는 비교 대상이 없다 | 검증 실험 제안으로 전환 |
| 얽힌 여러 원인을 분해한다 | 개별 효과의 합이 전체와 맞지 않는다 | 어긋남 자체를 신호로 보고 |
| 처음부터 잘 작동한다 | 축적이 없으면 판단 근거도 없다 | 초기에는 지식 꺼내기(§23)에 집중 |
3부 · 맺음말
맺음말 — 가져갈 것 세 가지
우리 사례를 걷어 내고 남는, 어디에나 적용되는 세 문장.
도구는 바뀌어도 이 세 기준은 남는다.
부록
용어 대응표
본문이 쉬운 말로 풀어 쓴 개념들의 정식 명칭. 더 찾아볼 때 검색어로 쓴다.
부록
쉬운 말 ↔ 전문 용어
공통
| 쉬운 말 | 전문 용어 | 설명 |
|---|---|---|
| 한 번에 볼 수 있는 분량 | 컨텍스트 윈도 (context window) | 여기 안 들어가면 없는 것과 같다 |
| 아는 시점의 한계 | 지식 컷오프 (knowledge cutoff) | 학습 이후의 일은 모른다 |
| 질문할 때 자료를 같이 건넴 | 문맥 주입 (context injection) | RAG·wiki가 공통으로 하는 일 |
| 모델 자체를 다시 훈련 | 파인튜닝 (fine-tuning) | RAG와는 다른 길 |
| 문서 맨 위의 정보표 | 프론트매터 (frontmatter) | 작성일·조건·태그 등 기계가 읽는 부분 |
| 그럴듯하게 지어냄 | 환각 (hallucination) | 근거가 없거나 엉뚱할 때 발생 |
RAG 쪽
| 쉬운 말 | 전문 용어 | 설명 |
|---|---|---|
| 검색해서 붙여 주기 | RAG (Retrieval-Augmented Generation) | 검색 + 생성 |
| 잘게 쪼개기 | 청킹 (chunking) | 조각 크기가 검색 품질을 좌우한다 |
| 의미 좌표 | 임베딩 (embedding) | 글을 숫자 묶음으로. 뜻이 가까우면 숫자도 가깝다 |
| 좌표 보관소 | 벡터 저장소 (vector store / DB) | 조각과 좌표를 담아 두는 곳 |
| 뜻으로 찾기 | 의미 검색 (semantic search) | 단어가 달라도 찾는다 |
| 단어로 찾기 | 키워드 검색 (keyword search, BM25) | 정확한 말이 있어야 찾는다 |
| 둘을 섞기 | 하이브리드 검색 (hybrid search) | 의미 + 단어. 조용한 실패를 줄인다 |
| 가져올 개수 | 상위 k개 (top-k) | 맞는 것이 없어도 이 개수만큼 가져온다 |
| 꺼낸 것을 다시 거르기 | 재순위 (re-ranking) | 정확도가 오르는 대신 비용이 는다 |
| 미리 등록해 두기 | 색인 (indexing) | 등록해야 검색된다 |
| 출처를 밝힘 | 근거 제시 (citation / grounding) | 어느 문서에서 왔는지 |
wiki 쪽
| 쉬운 말 | 전문 용어 | 설명 |
|---|---|---|
| 정리해 둔 지식 저장소 | 지식베이스 (knowledge base) | 원본이 아니라 결론이 담긴다 |
| 항목 | 페이지 / 노드 (page, entry, node) | 한 항목 = 한 주제 |
| 링크 | 연결 / 역링크 (link, backlink) | 관계를 표현하는 수단 |
| 항목과 링크의 관계망 | 지식 그래프 (knowledge graph) | 링크가 쌓이면 그래프가 된다 |
| 링크를 타고 이동 | 그래프 탐색 (graph traversal) | 찾는 것이 아니라 걸어 들어간다 |
| 비어 있는 항목 | 빈 링크 / 스텁 (broken link, stub) | 모른다는 사실이 드러나는 지점 |
| 낡아서 틀려짐 | 정합성 붕괴 (staleness) | 원본이 바뀌면 wiki가 틀려진다 |
| 쓰고 고치는 품 | 관리 비용 (curation cost) | wiki의 최대 비용 |
| 검색과 wiki를 합친 방식 | 그래프 RAG (GraphRAG) | 관계망 위에서 검색 |
| LLM용으로 고쳐 쓴 wiki | LLM-wiki | 이 자료의 용어 — 한 항목=한 주제 · 필수 링크 · frontmatter · 출처 구분 (§10) |
진단 순서도 쪽
| 쉬운 말 | 전문 용어 | 설명 |
|---|---|---|
| 진단 순서도 | 결정 트리 / 진단 절차 (decision tree) | 증상에서 갈라져 내려가는 확인 순서 |
| 갈림길 | 노드 · 분기 (node, branch) | 무엇을 확인하고 어디로 가는지 |
| 안 잡힘 | 미분류 · 폴백 (unclassified, fallback) | ★ 모른다는 것이 드러나는 자리 |
| 몇 번 맞았나 | 적중률 (hit rate) | 도달 횟수 대비 검증 확인 횟수 |
| 모르는 영역의 지도 | 지식 결손 (knowledge gap) | 안 잡힌 사례가 쌓인 자리 |
| 미리 계산해 붙여 둠 | 사전 계산 (precomputation) | 질문받고 찾는 대신 등록 시점에 계산 |
| 아는 것을 밖으로 꺼냄 | 암묵지 외부화 (tacit knowledge externalization) | 이 구조의 최종 목적 |
| 근거를 되짚을 수 있음 | 추적 가능성 (traceability) | 신뢰성의 실체 |