LLM 전용 위키 구축기, 그리고 워크플로를 붙였을 때

AI에게 일을 맡기다 보면 반복해서 부딪히는 질문이 있습니다.

“지금 쓰는 데이터 구조가 몇 번째 버전이지?”
“이 수치는 확정인가, 아직 추정인가?”
“지난주에 이건 어떻게 하기로 했더라?”

대화를 새로 열 때마다 이 배경을 다시 붙여넣었습니다. 붙여넣기가 길어질수록 빠뜨리는 것이 생겼고, 빠뜨린 내용은 그대로 결과물에 들어왔습니다. 추정값이니 단정하지 말자고 정해 놓고 그 문장을 다시 넣지 않았더니, 다음 초안에 단정형 문장이 그대로 나왔습니다.

프롬프트를 더 잘 쓰는 문제가 아니었습니다. 읽힐 자료가 정리되어 있지 않은 것이 원인이었습니다. 그래서 사람이 보는 문서와 별개로, AI가 읽을 위키를 따로 만들었습니다.

LLM 위키란 무엇인가?

AI에게 프로젝트 배경을 읽히려고 만든 문서 묶음입니다. 일반 위키와 다른 점은 독자가 사람이 아니라는 것입니다. 담는 내용은 세 가지입니다. 이 작업에 무엇을 읽어야 하는지, 지금까지 무엇을 어떻게 정했는지, 그리고 무엇을 하면 안 되는지입니다.

기존에는 이 내용을 대화창에 붙여넣었습니다. 사람이 매번 기억해서 골라야 했고 대화가 끝나면 사라졌습니다. 위키를 두면 AI가 작업 종류에 따라 정해진 노트를 먼저 읽고 시작합니다.

왜 LLM 위키가 필요한가?

AI에게 배경을 주는 방법은 여러 가지입니다. 붙여넣기는 준비가 필요 없지만 대화가 끝나면 사라집니다. 문서를 통째로 넣으면 누락은 없지만 관계없는 내용까지 판단에 섞입니다. 벡터 검색은 문서가 많아도 찾아 주지만, 우리 분야에서만 쓰는 용어의 대응 관계는 맞추지 못합니다.

위키는 이 방법들을 대체하지 않습니다. 무엇을 읽을지 정하는 층이고, 검색은 그 아래에서 실행됩니다.

사람이 읽는 문서와 AI가 읽는 문서의 성격이 다르다는 점도 있습니다. 사람은 필요한 부분만 훑고 넘어가지만 AI는 준 것을 전부 읽습니다. 사람은 지난 결정을 기억하지만 AI는 문서에 없으면 모릅니다. 사람은 모르면 묻고, AI는 모르면 채웁니다.

위키가 주는 것 다섯 가지

1. 배경을 다시 설명하지 않습니다

작업 종류별로 읽을 노트를 묶어 뒀습니다. 목적, 반드시 읽을 노트, 보조로 읽을 노트, 지시문, 출력 형식이 한 장에 들어 있습니다. 반드시와 보조를 나눠 두면 분량이 넘칠 때 무엇부터 뺄지가 이미 정해져 있습니다.

2. 지난 결정과 이유가 남습니다

무엇을 정했는지는 결과물을 보면 알 수 있지만, 왜 그렇게 정했는지는 문서에만 남습니다. 결정과 이유, 영향 범위를 한 줄씩 쌓아 지금 34건입니다. 그림을 넣기로 했다가 필요 조건을 다시 따져 미수록으로 뒤집은 적이 있는데, 이유가 적혀 있어서 되돌릴 수 있었습니다.

3. 작업 상태가 이어집니다

며칠 만에 돌아와도 한 문장이면 현재 상태, 완료한 것, 진행 중인 것, 다음 작업이 복원됩니다. 이미 전수 조사한 항목에는 다시 조사하지 말라는 표시를 붙여 같은 조사를 반복하지 않게 했습니다.

4. 지어내지 못하게 막습니다

AI는 모르는 값을 비워 두지 않고 채웁니다. 지시문에 적어도 잘 지켜지지 않아서 자리로 막았습니다. 표에서 AI가 쓰는 열과 사람만 쓰는 열을 나누고, 값마다 출처를 붙이게 했습니다. 출처 종류 안에 “구하지 못함”을 넣어 둔 것이 핵심입니다. 고를 수 있는 항목이 없으면 지어내기 때문입니다. 출처가 없는 값은 상대 비교에만 쓰고, 필수 항목이 비면 다음 계산을 시작하지 않습니다.

5. 규칙을 검사기로 만들 수 있습니다

위키에 적어 둔 규칙은 문장이라 지켜졌는지 사람이 확인해야 합니다. 그래서 규칙마다 검사 항목을 하나씩 만들어 문서를 만들 때 같이 돌립니다. 수치에 출처가 붙어 있는지, 미확정 항목이 본문에서 참조되는지, 개정번호가 표지와 맞는지 같은 것들입니다.

개정을 올리면서 표지 번호를 빠뜨린 적이 있습니다. 개정번호가 세 곳에 흩어져 있었고 그중 둘만 연결되어 있었습니다. 지금은 검사 항목 아홉 개 중 하나라도 걸리면 문서가 만들어지지 않습니다.

현재 구축된 구조

현재 기준으로 노트 209개, 최상위 폴더 7개로 운영하고 있습니다.

노트가 200개를 넘으면 폴더 트리로는 연결이 보이지 않습니다. 어떤 노트에 링크가 몰려 있는지, 어떤 노트가 아무와도 이어지지 않았는지를 보려고 그래프로 함께 확인합니다.

처음에는 데이터, 기획, 리서치, 회의록처럼 주제별로 나눴습니다. 사람에게는 자연스러운데 AI에게는 쓸모가 없었습니다. “회의록”이라는 이름만으로는 그 폴더를 읽어야 하는지, 거기에 무언가를 써도 되는지 알 수 없습니다.

입력과 기준은 같은 폴더에 두지 않았습니다. 밖에서 동기화되어 들어오는 자료와 그것을 비춰 보는 기준은 쓰임이 다릅니다. 둘 다 업무 자료라는 이유로 묶으면 무엇을 무엇에 비출지가 사라집니다.

여기에 워크플로를 붙였습니다

위키는 자료이고 워크플로는 절차입니다. 서로 다른 것이고, 워크플로가 위키를 읽습니다.

위키만 있으면 자료는 갖춰져 있는데 순서가 없습니다. 매번 사람이 무엇을 읽고 무엇을 하라고 지시해야 합니다. 그래서 작업 흐름을 여섯 단계로 나누고, 각 단계를 노트 한 장으로 정의했습니다. 프레임워크는 쓰지 않았습니다. 노트로 두면 규칙을 고칠 때 배포가 필요 없고 변경 이력이 그대로 남습니다.

모든 단계 노트는 읽는 것, 쓰는 것, 다음 단계를 적은 블록으로 시작합니다. 읽는 것보다 쓰지 않는 것을 적는 쪽이 중요했습니다. 첫 단계는 항목만 분리하는 역할이라 우선순위나 위험 분석을 하지 않습니다. 이걸 적지 않았을 때는 첫 단계가 계획과 설계, 검토까지 혼자 처리해 버렸습니다.

검토 결과 라벨은 승인, 수정필요, 보류 세 가지만 씁니다. 처음에는 일곱 종류였는데 라벨을 구분하는 데 시간이 들고 정작 다음 행동은 정해지지 않았습니다. 셋으로 줄이자 라벨이 그대로 다음 단계가 됐습니다.

붙였을 때 좋아진 것 두 가지

1. 토큰이 줄었습니다

단계마다 읽는 양이 다릅니다. 항목만 나누는 단계는 노트 한 장이면 되고, 설계 단계는 여러 장을 봅니다. 위키 전체를 매번 읽히지 않으니 같은 작업을 더 적은 분량으로 처리합니다.

더 큰 차이는 모델입니다. 계획, 설계, 검토는 대안을 비교하고 반려 여부를 정하는 일이라 상위 모델을 씁니다. 반면 오케스트레이션은 업무 노트를 항목으로 나누기만 하고, 반영과 검수 기록은 앞 단계에서 이미 정해진 내용을 옮겨 적는 일입니다. 이 세 단계는 하위 모델로 돌려도 결과가 달라지지 않았습니다.

바꿔 끼울 수 있는 이유는 단계마다 적어 둔 계약에 있습니다. 무엇을 받고 무엇을 내야 하는지 정해져 있어서 모델이 달라져도 다음 단계가 받는 형식이 흔들리지 않습니다.

2. 지식과 작업 상태를 함께 들고 일합니다

각 단계가 위키와 상태 노트를 같이 읽습니다. 위키에서 무엇을 아는지를 가져오고, 상태 노트에서 어디까지 했는지를 가져옵니다. 사람이 아무것도 붙여넣지 않아도 두 가지가 다 채워진 채로 시작합니다.

“이거 지난번에 정했잖아요”와 “그 자료가 어디 있죠”가 같이 사라진 것이 이 조합의 효과입니다.

실제 동작 예시

예시 1. 오늘 업무 정리

“오늘 업무 정리해줘”라고만 입력하면 업무 노트를 읽어 항목을 분리하고, 계획과 설계를 거쳐 검토 리포트를 냅니다. 프로젝트 배경이나 지난 결정을 다시 설명하지 않습니다.

예시 2. 데이터 구조가 바뀌었을 때

요약 노트는 그대로인데 원본이 바뀌면 AI는 이미 없어진 항목을 근거로 답합니다. 그래서 작업이 그 자료를 건드리면 요약 노트의 기준일을 읽고, 새 버전이 있는지 사용자에게 묻습니다. 자동으로 갱신하지 않는 이유는 원본이 시스템 밖에 있어 새 버전이 생겼는지 알 수 없기 때문입니다.

현재의 한계

이 구조는 저절로 유지되지 않습니다. 노트를 옮기면 링크가 끊기는데 오류가 나지 않아서 그냥 안 읽히고 넘어갑니다. 실제로 폴더는 옮겼는데 부트스트랩 문서의 폴더 지도가 예전 경로를 가리키고 있던 적이 있습니다.

노션 같은 외부 도구와의 동기화도 아직 수동입니다. 검사기가 잡을 수 있는 것은 형식뿐이라, 수치의 의미가 맞는지는 여전히 사람이 읽어야 합니다.

앞으로의 확장 방향

1. 위키 내부 검색 연결

노트가 더 늘면 지금의 노트 묶음 위에 검색을 얹습니다. 어떤 폴더를 색인할지는 지금 구조를 그대로 씁니다.

2. 외부 도구 동기화 자동화

노션에 쌓이는 업무 로그를 자동으로 들여옵니다. 지금은 사람이 옮기고 있습니다.

3. 검사 항목 자동 실행

지금은 문서를 만들 때만 돕니다. 저장소에 올릴 때 자동으로 돌게 만듭니다.

4. 팀 단위 확장

지금은 개인 기준으로 만들어져 있습니다. 여럿이 쓰려면 읽기 순서와 승인 지점을 공용 규칙으로 다시 정의해야 합니다.

ByOrbit 작업에서 이 위키가 가지는 의미

ByOrbit은 원물과 부산물, 공정, 유통 데이터를 다룹니다. 수치마다 기준과 출처가 필요한 영역이라 근거 없는 값이 그럴듯한 문장에 섞이는 것이 가장 위험합니다. 위키는 무엇을 읽고 어디까지 판단하고 어떤 값을 비워 둘지를 대화가 아니라 파일에 적어 그 위험을 줄입니다.

흩어진 자료를 한자리에서 끌어오는 역할도 합니다. 원물 성분, 공정 조건, 지난 결정이 노트로 정리돼 있어 작업에 필요한 것만 확인할 수 있습니다. 어디까지 했는지도 함께 남아있어 다시 설명할 것이 없습니다.

실무에서 체감한 것은 속도와 비용입니다. 단계마다 읽을 양을 정해 두고 판단이 필요한 구간에만 상위 모델을 쓰니 같은 작업을 더 적은 토큰으로 끝냅니다.

결론

정리하면 위키가 하는 일은 단순합니다. AI가 읽을 자료를 미리 정해 두고, 지금까지의 결정과 작업 상태를 남기고, 하면 안 되는 것을 문서로 막는 것입니다. 여기에 워크플로를 붙이면 단계마다 필요한 만큼만 읽게 되고, 단계에 맞는 모델을 골라 쓸 수 있습니다.

대신 문서를 쓰고 관리하는 시간이 늘었습니다. 프로젝트가 짧으면 손해고, 길면 이쪽이 낫다고 봅니다.