👋 처음 읽는 분을 위한 판돌이 위키 소개
판돌이는 강남구 옥외광고물 업무를 돕기 위해 만들고 있는 업무 에이전트입니다. 법령·시행령·서울시 조례·강남구 조례를 찾아주는 데서 끝나지 않고, 실제 업무에서 생긴 질문과 담당자의 판단을 다음 담당자도 다시 사용할 수 있는 살아있는 업무매뉴얼로 축적하는 것이 목표입니다.
옥외광고물이란? 쉽게 말해 간판입니다. 아래 그림과 같이 법령상 용어로는 이렇게 분류합니다.
한국의 다양한 건물 유형을 보 여주는 다이어그램
판돌이 위키는 자료의 역할을 다음처럼 나눕니다.
raw-data: 법령, 사례집, NotebookLM 자료 등 원본 보관wiki/inbox: 아직 믿으면 안 되는 신규자료의 검토대기 공간wiki/laws: 법령·조례 원문을 확인하는 근거wiki/cases: 특정 사건의 사실관계와 처리·판단 이력wiki/concepts: 여러 원문과 사례를 대조해 만든 재사용 가능한 업무규칙wiki/reviews,wiki/tests: 담당자 승인과 회귀시험을 관리하는 운영자료
새로운 답변이나 사례를 곧바로 정답으로 저장하지 않는 것이 핵심입니다. 먼저 인박스에 넣고 개인정보·출처·현행법을 확인한 뒤, 특정 사건은 사례로, 반복해서 쓸 수 있는 판단은 업무매뉴얼로 승격합니다. 담당자가 승인한 범위와 AI가 자동으로 단정하면 안 되는 행위도 문서에 함께 기록합니다.
새 질문·사례
→ 검토대기 inbox
→ 개인정보·출처·현행법 확인
→ 사례 또는 업무매뉴얼로 승격
→ 담당자 승인 또는 HOLD
→ 실제 질문으로 재시험
→ 실패한 지식·검색·절차를 다시 수정이 글은 이 운영체계에서 발견된 두 가지 문제, 즉 비어 있던 인박스를 실제 접수창구로 복구한 과정과 AI가 만든 업무매뉴얼 7개를 제한조건과 함께 담당자가 승인한 과정을 다룹니다.
📝 한 줄 요약
평소에 "NotebookLM에서 한 질문과 답변"과 "업무하면서 발생하는 신규 사례"가 검증 없이 업무매뉴얼로 들어가지 않도록 인박스 우선 접수 흐름을 복구하고, answerUsable 문서 39개에 적용할 담당자 승인기준을 만든 뒤 7개 문서를 조건부 승인했습니다. 이 과정에서 AI가 ‘출처를 못 찾음’을 ‘내용 충돌’로 잘못 판단했고, 담당자 정정 후에는 2026 법규집의 고시·공고 구간에서 정확한 근거까지 찾아냈습니다.
바쁘시면 이것만 읽어도 됩니다.
신규자료:
원문 → inbox → 출처·법령 검토 → case/concept 승격 → 담당자 승인승인원칙: 공통규칙 승인과 개별 허가·심의·처분 결정을 분리
실제 결정: 조건부 승인 7개, 전체 담당자 승인 10개, 승인대기 29개
핵심 오류: 일반 돌출간판 5층 이하 실무기준을 오답 후보로 분류
정정:
HOLD_CONFLICT → HOLD_SOURCE → 강남구 공고 원문 확인·출처해결검증: 7개 승인 메타데이터·정적 인덱스·런타임 제한표시 7/7, 고위험 자동승인 0
😫 문제 1: 인박스는 있는데 아무 자료도 들어오지 않았다
판돌이 위키에 인박스 폴더는 있었지만 실제 자료는 들어오지 않았습니다. 확인해 보니 원인은 세 가지였습니다.
한국어 메뉴 스크린샷
첫째, 예전에 모아둔 NotebookLM 자료는 사라진 것이 아니라 인박스가 아닌 raw-data 원자료 폴더에 보관돼 있었습니다. 자료는 있었지만 인박스에는 없었던 것입니다.
둘째, 이전에는 신규 사례를 인박스에 접수한 뒤 검토하기보다 바로 cases나 concepts 업무매뉴얼로 정리하는 작업도 있었습니다. 자료는 위키에 반영됐지만 인박스 접수기록은 남지 않았습니다.
기존 일부 작업
새 자료 → cases 또는 concepts
앞으로 적용할 방식
새 자료 → inbox → 출처·법령 검토 → cases 또는 concepts셋째, 판돌이 웹앱의 NotebookLM 접수 코드가 현재 Windows 위키가 아니라 이전에 사용하던 WSL 폴더를 기본 저장 위치로 보고 있었습니다. 그래서 웹에서 자료를 접수하더라도 현재 인박스에서는 보이지 않을 수 있었습니다.
결국 문제는 단순히 ‘자료가 없었다’는 것이 아니었습니다. 과거 자료의 보관 위치, 신규자료를 처리하던 작업방식, 웹앱의 실제 저장경로가 서로 달랐던 것입니다. 인박스라는 폴더만 만든다고 접수체계가 생기는 것은 아니었습니다. 자료를 쓰는 웹앱 코드와 사람이 지키는 승격규칙이 모두 같은 위키 정본을 가리켜야 했습니다.
🛠️ 인박스를 ‘단일 검토창구’로 복구한 방법
신규자료의 흐름을 다음처럼 통일했습니다.
원문 보존
→ wiki/inbox/notebooklm 또는 wiki/inbox/internal
→ 개인정보 검토
→ 출처 대조
→ 현행 법령 대조
→ 특정 사건이면 case로 승격
→ 반복 업무규칙이면 기존 canonical concept에 병합
→ 담당자 승인 또는 HOLD
→ 검색·회귀시험인박스 초안에는 다음 안전상태를 기본값으로 넣었습니다.
reviewStatus: PENDING
answerUsable: false
privacyReviewed: false
sourceChecked: false
lawChecked: false
promotionStatus: NOT_PROMOTED또한 일반 검색과 자동답변 인덱스는 inbox/ 문서를 제외하도록 유지했습니다. 인박스는 ‘새 지식’이 아니라 아직 믿으면 안 되는 검토대기 자료이기 때문입니다.
코드에서는 접수 경로의 우선순위를 다음처럼 바꿨습니다.
명시적 인박스 환경설정
현재 위키 정본 경로 아래
inbox/notebooklm현재 Windows 위키 정본의 기본 위치
과거 WSL 봇 경로를 기본값으로 되돌리지 않았습니다.
실제 검증
단순히 코드만 읽고 “고 쳤다”고 하지 않았습니다. 현재 위키 정본을 지정한 상태에서 일회용 NotebookLM 초안을 실제로 쓰고 다시 읽어 다음을 검사한 뒤 파일을 삭제하는 회귀검사를 추가했습니다.
실제 쓰기·읽기: PASS
생성 위치: 현재 정본의
wiki/inbox/notebooklmPENDING / answerUsable: false: PASS개인정보·출처·법령 미검토 상태: PASS
미승격 상태: PASS
테스트 파일 정리: PASS
🧑⚖️ 문제 2: answerUsable: true면 담당자가 모두 읽어야 할까?
판돌이에는 자동답변의 직접 근거로 사용할 수 있는 answerUsable: true concept이 39개 있었습니다. 하지만 이 값은 AI가 구조와 근거를 검토했다는 뜻이지, 담당자가 의미와 법적 적용범위를 승인했다는 뜻은 아니었습니다.
그렇다고 39개를 아무 기준 없이 한 줄씩 승인하는 것도 위험했습니다. 그래서 먼저 문서승인 판단헌법을 만들었습니다.