1,136페이지를 다 읽을 수 없다 — 인용 가능한 지식창고를 만드는 법
전자회로를 개발할 때 우리는 데이터시트를 매우 많이 참조합니다. 그런데 BMS IC의 데이터시트와 레퍼런스 매뉴얼은 방대하고 난이도가 높습니다. STM32F103 MCU는 데이터시트와 레퍼런스 가이드를 합치면 거의 1,300페이지입니다. 한 개발자가 이 계열을 제대로 익히는 데 몇 년이 걸리고, 경우에 따라서는 다 알지 못한 채 개발하는 것이 현실입니다.
그래서 가설을 세웠습니다. 만약 어떤 제2의 머리가 있어서 이 모든 지식을 완벽하게 가지고 있다면, 회로·펌웨어 개발이 근본적으로 달라질 것이다. 이 글은 그 가설로 전자부품 문서 908건짜리 지식창고를 만들면서 네 번 스스로 반증하고 도달한 방법론의 기록입니다.
프로젝트를 규정한 질문
섹션 제목: “프로젝트를 규정한 질문”작업이 한창일 때 결정적인 질문이 던져졌습니다.
“1,136페이지짜리
RM0008을 보고 답하라고 하면, 너는 이 문서를 100% 이해하고 즉각 답변할 수 있는가? 읽으라고 지시하면 진짜 모두 다 읽어서 정직한 답변을 할 수 있는가? 회로 개발에 필요한 데이터시트가 30개 정도 된다면, 그 모든 문서를 다 읽고 답변해 줄 수 있는가?”
필요한 것은 100% 확신할 수 있는 답변이기 때문입니다. 그리고 이 질문에는 이미 정확한 관찰이 들어 있었습니다 — “제가 알기로 당신은 모든 문서를 다 읽지 않습니다. 일부분만 읽고 답변을 하면 하드웨어 BMS 회로 개발에서는 절대로 안 되는 것입니다.”
정직한 답 — 못 읽는다
섹션 제목: “정직한 답 — 못 읽는다”돌려 말하지 않겠습니다. LLM은 1,136페이지를 다 읽지 못합니다. 이유는 셋입니다.
- 도구 상한 — PDF 읽기는 요청당 20페이지가 상한입니다.
RM0008하나에 57회 호출이 필요하고, 문서 30개면 원리적으로 불가능합니다. - 컨텍스트를 키워도 해결되지 않는다 — 창을 가득 채운 상태에서 주의(attention)는 균일하지 않습니다.
- 가장 결정적으로 — 모델은 자기가 어느 부분을 건너뛰었는지 스스로 신고하지 않습니다. 일부만 읽고도 완결된 문장으로 답합니다. 하드웨어 개발에서 치명적인 이유가 바로 이것입니다.
”100% 색인”의 두 가지 의미
섹션 제목: “”100% 색인”의 두 가지 의미”목표(“100% 확신할 수 있는 답변”)는 달성 가능합니다. 다만 전제 하나를 분리해야 합니다 — 색인이 답을 담는다는 전제입니다.
| 달성 가능성 | 판정 | |
|---|---|---|
| 커버리지 100% 모든 페이지가 도달 가능, 누락이 조용히 발생하지 않음 | 가능하고 측정 가능 | ✅ 이것을 목표로 삼는다 |
| 요약 정확도 100% 큐레이션된 문장이 전부 옳음 | 불가능 (LLM 요약의 본질적 한계) | ❌ 신뢰 사슬에서 제거 |
무엇이 이 문서들을 어렵게 만드는가
섹션 제목: “무엇이 이 문서들을 어렵게 만드는가”- 문서가 크고 많다.
RM0008은 1,136페이지, 약 60~70만 토큰입니다. 회로 설계에서는 놓친 각주 하나(“이 비트는 특정 순서로만 써야 한다”)가 실제 하드웨어 결함이 됩니다. - 틀린 답이 “모른다”보다 위험하다. “모른다”의 손해는 제한적입니다. 그러나 그럴듯하게 틀린 전압 임계값·레지스터 값은 회로도에 박히고, 보드가 제작되고, 현장에 나간 뒤에야 발견됩니다.
- 문서가 원래부터 틀려 있다. 이건 파이프라인의 버그가 아니라 원본의 성질입니다. 공식 문서에도 표 컬럼 뒤바뀜·행 누락·페이지 간 값 모순이 실재합니다. 벤더가 에라타(errata)를 따로 발행하는 제도 자체가 그 증거입니다.
- 정보가 텍스트로만 존재하지 않는다. 레지스터 맵, 핀 배치도, 회로도, 특성 그래프, 각주 딸린 조건부 수치표 — 순수 텍스트 추출로는 구조가 무너지는 형태로 존재합니다.
그래서 설계 목표의 우선순위는 ①틀린 답을 하지 않는 것 → ②빠르고 정확하게 찾는 것 순입니다. 이 글의 모든 구조적 선택이 이 하나에서 파생됩니다.
”표준 스택”이 왜 여기선 안 맞는가
섹션 제목: “”표준 스택”이 왜 여기선 안 맞는가”지식베이스를 만든다고 하면 반사적으로 나오는 목록이 있습니다. 벡터DB로 임베딩 검색, 지식그래프로 엔티티 관계, LangChain류로 에이전트 오케스트레이션. 셋 다 강력합니다. 그런데 “인용 가능하고, 검증 가능하고, 틀리면 틀렸다고 말하는 답변” 앞에서는 이 도구들의 기본 동작 방식 자체가 걸림돌이 됩니다.
벡터 임베딩 — 청킹이 인용을 깨뜨린다
섹션 제목: “벡터 임베딩 — 청킹이 인용을 깨뜨린다”임베딩 검색을 쓰려면 문서를 일정 크기 청크로 잘라야 하는데, 이 절단선이 표 중간이나 각주와 본문 사이를 가로지르는 일이 흔합니다. 아래는 실제 데이터시트의 보호 임계값 표입니다.
| PARAMETER | CONDITION | MIN / MAX | UNIT |
|---|---|---|---|
| V(OVP) | Nominal, 50.6 mV steps | 1.012 / 5.566 | V |
| V(OVP_ACC) | TA=+25°C, 3.036~5.06 V | −10 / 10 | mV |
| V(OVP_DLY) | Nominal, 3.3 ms steps | 10 / 6753 | ms |
고정 토큰 길이로 자르면 절단선이 조건(condition)과 값(min/max)을 서로 다른 청크로 떼어놓습니다. 검색은 값 쪽 청크만 돌려주고, “이 값이 어느 온도·어느 설정 구간에서의 값인지”는 유실됩니다. 그 각주가 바로 회로가 타는 지점입니다.
더 근본적인 문제는 유사도가 진실을 보장하지 않는다는 점입니다. 같은 계열의 5셀용 칩과 16셀용 칩은 임베딩 공간에서 아주 가깝게 배치됩니다 — 스펙 문서의 어휘·구조가 거의 같기 때문입니다. 하지만 보호 임계값·핀 배치·레지스터 주소는 다릅니다. 유사도 점수만 보고 상위 결과를 인용하면 이 차이가 조용히 사라집니다.
지식그래프 — 조용히 전파되는 오류
섹션 제목: “지식그래프 — 조용히 전파되는 오류”그래프의 매력은 다단계 관계 질의입니다. 문제는 그 엣지를 텍스트에서 자동 추출해야 한다는 것 — 이 추출은 결국 또 다른 LLM 추론이고, 여기서 생기는 오류는 검색 오류보다 훨씬 조용히 퍼집니다.
LangChain류는 성격이 다릅니다. 오케스트레이션 도구지 정확성 도구가 아닙니다. 기각 이유가 “정확도를 해친다”가 아니라 **“지금은 필요 이상”**이라는 점에서 앞의 둘과 다릅니다.
물리적 형태 — 왜 그냥 폴더인가
섹션 제목: “물리적 형태 — 왜 그냥 폴더인가”별도 DB 서버나 클라우드 SaaS가 아니라 일반 폴더에 마크다운과 원본 PDF를 나란히 두는 방식을 택했습니다. 세 가지 이유입니다.
- 파일이 곧 데이터다(벤더 락인 없음). 마크다운·PDF는 평문/표준 포맷이라 특정 앱이 없어도 열립니다. 17년 넘게 유지될 회사 지식창고에서 “특정 회사의 정책이 바뀌면 지식이 인질로 잡힌다”는 위험은 협상 대상이 아닙니다.
- AI의 기본 도구와 저항 없이 맞물린다. DB는 항상 API/쿼리 계층을 거쳐야 하지만 파일시스템은 네이티브 조작 대상입니다. 이건 제약이 아니라 별도 검색 서버 없이 리트리버 역할을 스스로 하게 해주는 조건입니다.
- 사람과 에이전트가 같은 자산을 각자의 방식으로 쓴다. 지식을 이중 유지할 필요가 없습니다.
폴더 설계 원칙도 하나입니다. 제조사·인터페이스·전압범위까지 전부 폴더로 만들면 조합폭발이 일어납니다. 그래서 물리적 위치(폴더)는 가장 안정적인 축 하나만, 나머지는 전부 frontmatter 태깅입니다. 새 분류축이 필요해져도 폴더 재구성 없이 필드 하나만 추가하면 됩니다.
4계층 아키텍처 — 그리고 그것이 축 하나였다는 발견
섹션 제목: “4계층 아키텍처 — 그리고 그것이 축 하나였다는 발견”처음 설계한 구조는 4계층이었습니다.
| 계층 | 내용 |
|---|---|
| ① 원문 보존층 | PDF → 구조·표 보존 마크다운화 + [p.N] 페이지 앵커 |
| ② 복합 색인층 | 목차·챕터분할 + 결정론적 카탈로그 + 순위검색(BM25 + 한국어 형태소) |
| ③ 검증된 지식층 ★ | 큐레이션 작성 + 원본 PDF 대조 적대적 재검증(2패스) + 기계 게이트 |
| ④ 행동 규약층 | 인덱스는 탐색 전용 · 수치는 원본에서 확정·인용 · 못 찾으면 단정 금지 |
핵심은 지도와 원문의 분리입니다. 어떤 도구도 표·회로도·수식을 100% 무손실로 텍스트화하지 못합니다. 선택지는 둘입니다. (a) 변환 품질을 완벽하게 만들려고 계속 투자하거나, (b) 변환 결과는 “탐색용 지도”일 뿐이고 확정은 항상 원본에서 한다고 아키텍처로 못박는 것. 우리는 (b)를 택했습니다. 완벽함은 도구가 아니라 구조로 보장합니다.
그런데 이 4계층이 아키텍처의 전부가 아니었다는 것이 이 프로젝트에서 가장 값비싼 발견이었습니다.
4계층의 적용 단위는 **“이미 대상으로 인지된 문서 1건”**입니다. 그 한 건을 얼마나 깊이 처리하는가만 다룹니다. 나머지 축은 4계층이 완벽해도 그대로 뚫려 있을 수 있습니다. 각 사고가 개별 실수였던 게 아니라 점검 축 목록 자체가 없었던 것이 공통 원인이었습니다.
| 축 | 무엇을 보는가 | 실제 사고 사례 |
|---|---|---|
| ① 깊이 | 한 문서를 얼마나 깊이 처리했는가 (4계층 본체) | — (자동 게이트) |
| ② 존재 | 원본은 있는데 마크다운이 없음 | 원본만 있고 md 없는 8건, 에라타 0건 |
| ③ 라벨 | status 자기선언 ≠ 실제 본문 | 허위완료 4회 반복 |
| ④ 횡단색인 | 문서를 가로지르는 조회(레지스터·그림·파라메트릭) | 색인 결함 4건 |
| ⑤ 재발 | 일회성 배치인가 파이프라인 편입인가 | 한 번 하고 끝난 작업이 다음 문서에서 재발 |
| ⑥ 범위 | 게이트 스캔 폴더 경계 자체 | 하드코딩 루트 밖 9건 |
| ⑦ 외부 확인 | 문서로는 원리적으로 못 닫는 것 | 벤더 회신·실측 대기 |
| ⑧ 사정거리 | 검사도 있고 대상도 범위 안인데 둘이 만나지 않음 | 6건, 전부 증상이 침묵 |
그리고 이 목록을 만든 것과 그 목록을 실제로 쓰는 것은 다른 일이었습니다. 축 목록을 문서로 갖고 있으면서도, 같은 형태의 결함을 여섯 건 만나고도 매번 개별 수정만 하고 축 판정을 하지 않은 날이 있었습니다. 그래서 규칙이 하나 더 생겼습니다 — 새 결함 유형을 발견하면 개별 수정 전에 “이건 어느 축인가”를 먼저 판정한다.
검색 — 왜 이래야 “고급 검색”인가
섹션 제목: “검색 — 왜 이래야 “고급 검색”인가”| 도구 | 실제로 하는 일 | 한계 |
|---|---|---|
| Grep | 패턴 존재 여부만 판정 — 순위 없는 boolean | 결과가 100개면 100개를 다 봐야 함 |
| BM25(FTS5) | 관련도 점수로 순위. 정확 식별자에 강함, 결정론적, 로컬, 무료 | 동의어·다른 표현은 놓칠 수 있음 |
| 임베딩 | 의미가 비슷하면 표현이 달라도 찾음 | 정확 식별자에는 오히려 방해 |
“Grep이면 충분하다”는 흔한 오해입니다. Grep은 순위가 없어 색인 없이 전체에 돌리면 무관한 결과에 파묻힙니다. Grep이 쓸모 있는 건 색인이 먼저 범위를 좁혀주기 때문입니다. 색인층은 부가기능이 아니라 검색 전체가 기대는 척추입니다.
한국어는 교착어라 “밸런싱/밸런싱이/밸런싱을”이 문자열로는 전부 다릅니다. 동시에 bq76952나 CC_CFG 같은 식별자는 형태소 분석하면 안 됩니다(“bq”+“76952”로 쪼개지면 정확검색이 깨집니다). 그래서 원문과 한국어 형태소를 별개 컬럼으로 나란히 색인하고 하나의 질의로 동시 검색합니다. "bq76952 셀밸런싱" 같은 혼합 질의가 동작하는 이유입니다.
문서를 가로지르는 조회는 전문검색으로 긁으면 비결정론적이라 별도 색인을 둡니다. 그중 파라메트릭 색인(절대최대정격·권장동작조건, 1,661행/90부품)은 의도적으로 LLM을 거치지 않습니다. 중간에 추론이 없으므로 재귀 오염 경로가 원천적으로 없습니다. 대신 파싱 실패를 조용히 넘기지 않고 사유와 함께 전량 기록합니다.
가장 큰 공백은 큐레이션이 아니라 답변 시점이었다
섹션 제목: “가장 큰 공백은 큐레이션이 아니라 답변 시점이었다”큐레이션 시점은 중무장돼 있었습니다 — 4계층, 기계 게이트, 1,678건 의미검증 캠페인. 그러나 답변 시점의 규약은 규범이지 기구가 아니었습니다. 근거 조회 도구와 원본 열람 도구가 존재해도 쓰지 않으면 아무것도 막지 않았습니다. 그럴듯한 마크다운 한 줄을 찾아 원본을 안 열고 답해도 시스템은 침묵했습니다.
실사용의 실패 모드는 큐레이션 결함이 아니라 원본 미열람 답변이었습니다.
완전한 강제는 불가능합니다 — 도구는 소비자를 통제할 수 없습니다. 대신 관측 가능하게 만들었습니다. 세션 내 원본 열람 이력을 추적하고, 근거 조회 응답이 “아직 원본을 안 봤다”를 구조화 필드로 스스로 신고합니다.
answer_gate | 의미 | 허용되는 행동 |
|---|---|---|
PENDING_ORIGINAL | 인용 대상 페이지 중 이 세션에서 안 연 것이 있음 | ❌ 수치 단정 금지 — 먼저 원본을 연다 |
ORIGINAL_CONFIRMED | 인용 페이지 전부 원본 확인 완료 | ✅ 문서명 rev, p.N 병기해 인용 |
NO_PAGES_CITED | 인용할 [p.N]이 없음 | ⚠️ “문서에서 확인 불가”로 답할 것 |
이래야 사람도 소비 프로그램도 침묵이 아니라 명시 신호를 보고 분기할 수 있습니다. 사람은 애매한 답을 받으면 “이거 맞나?” 하고 스스로 거릅니다. 프로그램은 그 필터링을 못 합니다 — “확인 불가”가 산문 속에 묻혀 있으면 자동화 파이프라인은 그냥 문자열로 취급하고 지나갑니다.
실제로 무엇이 무너졌나 — 경험 연대기
섹션 제목: “실제로 무엇이 무너졌나 — 경험 연대기”방법론만 남기면 “왜 이 규칙이 있는가”가 사라집니다. 아래는 실제로 겪은 사고와 발견입니다. 대부분 우리가 먼저 찾았다는 것이 이 목록의 요점입니다.
| 무엇이 있었나 | 무엇을 배웠나 |
|---|---|
| 문서유형 폴더 이관 중 목적지 폴더를 먼저 만들지 않고 반복 move를 실행해 부품 3개의 원본 PDF 소실 | 방법론이 견고해도 기본 파일 조작이 자산을 지운다. 공식 사이트 재다운로드로 복구 |
| 벤더 원본에서 예제 산술오기·표 오기·그림-표 매핑 불일치 발견. 구 색인의 라벨 블록이 실제로는 다른 챕터 | 원본조차 의심하고 교차검증해야 한다 |
| bulk 치환 중 이스케이프 버그로 파일 17개 손상 | 대량 치환은 그 자체가 사고원 |
| 원본만 있고 마크다운이 없는 8건 발견 | ”제3의 축”(②존재)의 첫 인지. “못한 것”과 “안 한 것”을 구분한다 — 후자는 예외 없이 마저 한다 |
| 검색 도구가 gitignore를 존중해 거짓 “매치 없음” 반환 | 검증 결과를 조용히 뒤집는 함정. 무시설정 우회 옵션이 필수 규약이 됨 |
| status는 “완료”인데 본문이 플레이스홀더 — 같은 축에서 네 번 반복 | 표본으로 멈추면 안 된다. 전수 비용이 작으면 표본화 금지 |
| 횡단색인 결함 4건이 “완벽하다” 선언 직후 발견 | 원인은 실행이 아니라 검증 계획 자체가 표본검사였다는 것. 공개 블로그의 핵심 주장을 폐기 |
| ”133건 전량완료” 오선언 — 재확인에서 25건이 신규로 나옴 | VERIFIED_EMPTY 상태 신설. “확인했는데 정말 없음”과 “아직 안 봄”을 구분 |
| 압축 메모만 보고 “vault에 실채택본 없음”이라 단정했다가 반박당함 | 원본을 다시 열지 않은 상태의 “갭” 주장은 금지 |
신설 게이트가 즉시 R_FILT: min=100 > max=40 역전을 검출 | 원본 대조 결과 표 열병합 훼손 확인. 게이트가 스스로 결함을 잡은 첫 사례 |
| 권위 서열 최상단인 에라타 폴더가 3개월째 0건 | 규칙은 있고 문서만 없었다. 게다가 한글 검색어로만 찾아 영문으로 적힌 규칙을 한 번 놓쳤다 |
특히 아팠던 것은 권위 서열 최상단의 빈 슬롯이었습니다. 실리콘 결함·예외에 대해서는 에라타가 데이터시트보다 우선한다고 규칙에 적어 두고, 정작 에라타 폴더는 원본 0건이었습니다. 연쇄 결과로 “교차 문서 확인” 상태는 원리적으로 도달 불가였고, 검증질의세트의 해당 유형은 실행 불가능했습니다.
더 중요한 건 왜 늦게 드러났는가입니다. 개별 큐레이션은 정직했습니다 — 어느 챕터 노트는 *“실리콘 결함/예외는 이 데이터시트보다 에라타가 우선”*이라고 정확히 적어놨습니다. 문제는 그런 문장들이 산문 속에 흩어져만 있고 집계 장치가 없었다는 것입니다.
사람이 병목이 되지 않는 운영
섹션 제목: “사람이 병목이 되지 않는 운영”남은 최대 문제는 정확도가 아니라 운영 부하입니다. 문서가 수천~수만 건으로 늘면, 한 사람이 직렬 병목이 되어 구조적으로 멈춥니다.
큐레이션 중 운영자에게 쏟아진 질문들은 세 종류였고, 셋 다 대부분 사람이 필요 없었습니다.
| 질문 유형 | 진단 | 처방 |
|---|---|---|
| ”이 문서가 마지막 버전인가?” | 기계 판정 가능 — PDF 헤더에 리비전이 인쇄돼 있다 | 규칙 + 신뢰도 점수로 자동 판정. 애매하면 REVISION_AMBIGUOUS로 기록하고 전진 |
| ”파일명이 틀린 것 같은데 고칠까?” | 애초에 막으면 안 되는 것 — 진실은 frontmatter가 갖고 파일명은 표시용 | parse_confidence: low 부착 후 전진. 질문 금지 |
| ”같은 부품인데 문서마다 값이 다르다. 뭐가 맞나?” | 질문하는 것 자체가 규약 위반 — 임의 선택 말고 충돌을 공개하라고 이미 정해 두었다 | 하나를 고르지 말고 CONFLICTED 충돌 레코드를 만들어 답변 시점에 함께 제시 |
공통 원인은 하나였습니다 — 시스템에 “미확정”을 담을 자리가 없어서, 갈 곳 없는 불확실성이 전부 사람에게 밀려나왔습니다.
그래서 “완료”를 두 상태로 쪼갰습니다.
USABLE— 추출 + 색인 + 게이트 통과 + 충돌·미확정이 전부 레코드로 기록됨. 기계가 만들고 사람 개입 0. 즉시 서비스.CONFIRMED— 해당 값에 대해 사람이 원본 대조·판단 완료. 필요할 때만.
정확도 요구도 문서가 아니라 소비 경로가 정합니다. 같은 지식창고를 쓰는 세 경로는 위험도가 전혀 다릅니다. 연구소 직원 Q&A와 사람이 검토하는 회로도 분석은 사람 필터가 있어 USABLE로 충분하고, 충돌·미확정을 답변에 표시해 제공하면 됩니다. 그러나 값이 곧장 펌웨어로 들어가는 자동생성 경로는 사람 필터가 없어 CONFIRMED를 요구하고, 미확정이면 하드 차단됩니다.
아직 못 푸는 것
섹션 제목: “아직 못 푸는 것”못 푸는 것을 숨기지 않고 “언제, 어떤 신호가 오면 무엇을 추가할지” 미리 정의해두는 것 — 이 표 자체가 방법론의 일부입니다.
| 못 푸는 것 | 왜 |
|---|---|
| 에라타 부재 | 권위 최상단 문서가 0건 — 실리콘 결함 질의는 원리적으로 답할 수 없음. 자동 다운로드가 네트워크 차단돼 수동 입수 필요 |
| 범위 축 담당 게이트 없음 | 스캔 루트가 하드코딩돼 그 밖은 구조적으로 안 보임. 일회성 전역 스캔은 실행했으나 상설화 미완 |
| 라벨 축 상시 게이트 없음 | status가 자유 텍스트라 기계가 참·거짓 판정 불가. 상태기계 구현 미완 |
| 도입 트리거 실측 장치 없음 | ”실패율이 실측되면 임베딩을 도입한다”고 썼지만 감사로그가 없어 트리거가 영원히 안 당겨질 수 있음 |
| 큐레이션 자동 오케스트레이터 미구현 | 추출·색인·게이트는 이미 배치 프로그램이나, 큐레이션을 헤드리스로 호출하는 워커가 없어 매번 사람이 CLI를 띄워야 함 |
| 스키매틱/넷리스트 분석 | 회로 자체를 구조화해 읽는 파이프라인이 없음 — 부품 정보와는 별개 능력 |
원칙 12
섹션 제목: “원칙 12”마지막으로, 지금까지의 전부를 열두 줄로 압축합니다.
- 원본은 불변, 해시로 신원을 고정하라. 파이프라인은 언제든 다시 만들 수 있어야 하지만 원본의 무결성은 되돌릴 수 없어야 한다.
- 인용 없는 주장은 주장이 아니다. 수치·조항·임계값은 원본 위치가 없으면 “사실”이 아니라 “확인 필요”다.
- 지도와 원문을 명시적으로 분리하라. 1차 추출은 틀려도 되는 지도다. 확정은 반드시 별도 계층에서.
- “확인 불가”를 1급 시민으로 대우하라. 억지로 답을 짜내는 것보다 근거 없음을 구조화 신호로 반환하는 게 안전하다.
- 청크가 아니라 청크의 경계를 설계하라. 표 행·조건-값 쌍·레지스터 1개 같은 의미 단위를 절대 자르지 않는 규칙을 먼저 정하라.
- 그래프는 파생물이지 원천이 아니다. 관계는 태그·위키링크 같은 값싼 씨앗으로 먼저 심어라.
- 자동화 소비자에겐 산문이 아니라 계약을 줘라. 사람이 읽는 문장과 프로그램이 분기하는 구조화 필드는 처음부터 분리하라.
- “완료”를 말할 때 반드시 축과 범위를 함께 말하라. “게이트 통과”는 언제나 특정 축을, 특정 루트 안에서 통과했다는 뜻이다.
- 새 결함은 고치기 전에 축부터 판정하라. 축 미분류 개별 수정은 같은 축의 나머지 사례를 남긴다.
- 반복될 기능은 파이프라인에 편입하라. 일회성 배치로 끝난 작업은 다음 문서에서 반드시 다시 뚫린다.
- 전수 비용이 작으면 표본화하지 마라. 검증 계획에 “샘플/몇 개/리뷰”라고 쓰는 순간 그 항목은 실패한다.
- 달성 주장에는 축·범위·시점 세 수식어를 붙여라. “N건 완료”는 금지. “N건 ○○축 완료(△△ 범위, YYYY-MM-DD 시점)“만 허용한다. 수식어를 붙일 수 없으면 그건 아직 할 수 없는 주장이다.
이어지는 기록 — 문서를 지식 그래프로 다루는 실험은 〈graphify와 serena〉와 〈문서 위키〉, AI에게 규율을 강제하는 장치는 〈하니스 엔지니어링〉, 검증을 2패스로 나누는 이유는 〈에이전트 파이프라인〉에 있습니다. 이 지식창고가 실제로 쓰이는 회로·펌웨어 쪽 맥락은 〈BMS 회로 설계〉와 〈BMS 펌웨어 자동화〉를 참고하세요.