원본 문서를 업무매뉴얼형 LLM wiki로 바꾸고, 웹앱에서 승인·답변까지 연결한 기록

한 줄 요약

강남구 옥외광고물 업무에서 흩어진 원본 자료와 담당자 암묵지를 원본 → Markdown → LLM wiki → DB 검토상태 → 웹앱 답변 흐름으로 연결하고, 이후 규격 조회와 허가 판단기준 생성을 분리해 판돌이가 실제 업무매뉴얼처럼 답변하도록 개선해가는 과정이다.

이런 분들께 도움이 됩니다

법령·가이드라인·사례가 여러 파일에 흩어져 있어 매번 다시 찾는 분
담당자별 예외 판단과 민원 응대 문안을 업무매뉴얼로 남기고 싶은 분
단순 검색봇이 아니라 “왜 그렇게 판단하는지” 설명하는 내부 업무봇을 만들고 싶은 분
AI 에이전트에게 웹앱 개발, 문서 정리, 데이터 동기화를 나눠 맡겨보고 싶은 분

시작점: 문제는 검색이 아니라 “판단의 축적”이었다

처음에는 옥외광고물 법령과 설치가이드를 잘 찾는 보조봇이 필요했다.

하지만 실제 업무를 정리하다 보니 문제는 단순 검색이 아니었다.

현장에서는 이런 질문이 반복된다.

이 간판은 벽면이용간판인가, 상단간판인가?
허가 대상인가, 신고 대상인가?
심의 대상인가?
민원인에게 “가능합니다”라고 말해도 되는가?
예외 사례는 있었지만, 그걸 다음 담당자가 어떻게 다시 찾을 수 있는가?

법령 원문만 있으면 답이 부족했다.
설치가이드만 있어도 부족했다.
실제 민원 응대 사례와 담당자 판단이 같이 쌓여야 했다.

그래서 판돌이의 목표를 이렇게 잡았다.- 판돌이는 간판업무를 도와주는 hermes 봇입니다.

판돌이는 단순 검색창이 아니라, 원본 자료와 실제 사례를 업무매뉴얼로 바꿔가는 LLM wiki 인터페이스다.

만든 것: R2, DB, wiki, 웹앱을 역할별로 나눈 구조

판돌이 구조는 세 개의 역할로 나눴다.

R2 = 원문창고
DB = 대장
wiki = 업무매뉴얼

조금 더 풀어 쓰면 이렇다.

1. R2 / 원본창고

PDF, HWPX, Markdown, 민원 메모 같은 원본 파일을 보관하는 곳이다.
원문은 나중에 다시 확인해야 하므로, 지식으로 요약되더라도 버리지 않는다.

2. DB / 대장

DB는 “무엇이 등록되었고, 어떤 상태인지” 관리한다.
예를 들면 다음 상태를 기록한다.

원문 파일 자산 DocumentAsset
사례 CaseRecord
매뉴얼 후보 ManualArticle
담당자 의견 ReviewOpinion
검토상태 PENDING / REVIEWING / APPROVED / REJECTED

즉 DB는 판단 그 자체라기보다, 업무 기록과 승인 상태를 관리하는 대장이다.

3. LLM wiki / 업무매뉴얼

wiki는 사람이 읽을 수 있는 판단 지식이다.
법령, 가이드라인, 실제 사례, 예외, 재발방지 규칙을 연결한다.

예를 들어 하나의 사례를 그냥 저장하지 않고 다음 구조로 바꾼다.

사례
판단
예외
재발방지 규칙
추가 확인 필요사항
관련 문서

이 구조가 생기면서 판돌이가 단순히 파일을 찾는 것이 아니라, “이 업무는 어떤 기준으로 판단해야 하는지” 답변할 수 있게 됐다.

진행 과정

1단계. 원본 데이터를 Markdown으로 바꿨다

처음에는 법령집, 설치가이드, 조례, 질의회신 같은 원본 자료를 읽기 좋은 Markdown 형태로 정리했다.

이 단계의 목표는 완벽한 답변이 아니라 “AI가 읽을 수 있는 원천 자료”를 만드는 것이었다.

특히 판돌이에서는 다음 자료를 우선 기준으로 두었다.

2026 법규집
옥외광고물설치가이드2026
서울시 조례
강남구 조례
실제 민원 응대 사례

중요한 점은 모든 자료를 동급으로 보지 않았다는 것이다.
법령과 가이드라인은 상위 기준이고, 실제 사례는 그 아래에서 판단을 보완하는 근거로 두었다.

Adobe Adobe Adobe Adobe Adobe Adobe의 스크린샷

2단계. raw-data를 바로 답변에 쓰지 않고 wiki 컨셉으로 연결했다

원본 Markdown이 있다고 해서 바로 업무매뉴얼이 되는 것은 아니었다.

예를 들어 “벽면이용간판” 질문이 들어오면, 판돌이가 법령 파일 전체를 뒤지는 것보다 먼저 봐야 하는 정리 페이지가 필요했다.

그래서 wiki에 컨셉 페이지를 만들었다.

예시:

벽면이용간판 규격과 허가기준
유형별 광고물 가이드라인 설치가이드2026
2026 법규집 읽기안내
간판종류별 규격과 허가기준
KFC 파사드·컵 모형 민원응대 사례
FSN 에프에스엔 상단간판·주소변경·상표권 검토 사례

이렇게 하니 판돌이는 원본 문서를 그대로 읽는 것이 아니라, 원본을 바탕으로 정리된 업무 지도를 먼저 참고할 수 있게 됐다.

3단계. 웹앱 개발은 Claude Code에 위임했다

판돌이 웹앱은 Next.js 기반으로 만들었다.

웹앱에는 다음 화면을 두었다.

/search: 결론 → 기준 → 근거 순서로 답변하는 검색 화면
/sources: 원문 업로드와 raw-data 확인 화면
/cases: 사례 등록 화면
/manuals: 업무매뉴얼 목록 화면
/review: 위키 초안 승인/반려 화면
/opinions: 담당자 의견 등록 화면
/wiki: 위키 페이지 확인 화면

이 과정에서 Claude Code에는 웹앱 구조와 기능 구현을 위임했다.
사람은 “어떤 업무 흐름이 맞는지”를 판단하고, 에이전트는 코드를 만들고 고치는 역할을 맡았다.

처음부터 완성된 것은 아니었다.
DB와 wiki가 따로 노는 느낌이 있었고, 웹에서 보면 wiki 기반 답변이 제대로 반영되지 않는 문제가 있었다.
그래서 구조를 다시 정리했다.

핵심은 이것이었다.

wiki는 매뉴얼이고, DB는 그 매뉴얼의 검토 상태와 검색용 대장이다.

4단계. wiki 내용을 DB로 계속 동기화하게 만들었다

처음에는 wiki를 만들어도 DB와 웹앱이 따로 움직였다.
웹앱에서 보면 DB에 들어간 ManualArticle이 거의 없거나, wiki 문서가 제대로 반영되지 않았다.

그래서 wiki:sync 흐름을 만들었다.

흐름은 다음과 같다.

wiki Markdown
  → wiki index 생성
  → DB ManualArticle upsert
  → DocumentAsset으로 wiki 파일 연결
  → 웹앱 /search, /review에서 사용

중요한 개선은 “모든 wiki 문서를 자동 승인하지 않도록” 만든 것이다.

처음에는 wiki를 DB로 옮기면 전부 APPROVED가 될 위험이 있었다.
하지만 실제 업무에서는 검토대기 사례와 공식 매뉴얼을 구분해야 한다.

그래서 wiki frontmatter에 상태를 넣었다.

reviewStatus: PENDING
contested: true
confidence: low

또는 검토 완료 후에는 이렇게 바꿀 수 있다.

reviewStatus: REVIEWING
confidence: medium

이제 판돌이는 wiki 문서를 DB로 옮기면서도 다음 상태를 구분한다.

PENDING = 검토대기
REVIEWING = 검토 완료, 승인 대기
APPROVED = 공식 매뉴얼
REJECTED = 반려

이게 만들어지면서 “업무매뉴얼 초안 → 검토 → 승인 → 답변 반영” 흐름이 생겼다.

5단계. 답변 엔진을 “검색”에서 “판단기준 생성”으로 확장했다

다음 문제는 더 미묘했다.

판돌이가 간판종류별 규격과 허가기준 같은 적절한 wiki 문서를 찾기는 했지만, 정작 답변에서는 돌출간판의 핵심 수치가 빠졌다.
예를 들어 사용자가 이렇게 물었다.

돌출간판 규격 알려줘

wiki에는 돌출간판 규격이 숫자로 정리되어 있는데, 웹앱 답변은 다음처럼 빗나갔다.

건물의 4층 이상 층의 벽면 등에 설치하는 타사광고
건물의 4층 이상 층에 표시하는 것
건물 5층 이하의 벽면에 업소당 1개를 표시할 수 있다.

이 답변의 문제는 “wiki를 참조하지 않았다”가 아니었다.
오히려 wiki 제목은 잡았지만, 해당 문서 안에서 돌출간판 섹션과 규격 숫자를 정확히 추출하지 못한 것이었다.

그래서 오늘 개선 방향을 다시 정리했다.

규격 조회와 허가 판단을 분리한다.
- 돌출간판 규격 알려줘는 spec lookup이다.
- 결론에서 돌출폭, 세로길이, 두께, 표시위치, 개수 같은 숫자가 먼저 나와야 한다.
- 광범위한 4층/타사광고 문구만 반복하면 실패다.
허가 가능한지 판단기준 만들어줘는 decision criteria 흐름으로 본다.
- 바로 가능/불가를 단정하지 않는다.
- 필요한 조건 슬롯을 만든다.
- 설치 위치, 지면 간격, 돌출폭, 세로길이, 두께, 한 면 면적, 자사/타사광고, 기존 간판 유무, 특정구역 여부를 하나씩 확인한다.
사용자가 짧게 답해도 이전 질문과 연결한다.
- 예: “3.2m야” → 방금 물어본 지면 간격 슬롯에 채운다.
- 예: “1.1m야” → 방금 물어본 돌출폭 슬롯에 채우고, 1m 이내 기준 초과 가능성을 표시한다.
- 이미 받은 값은 다시 묻지 않는다.
판단 상태를 명확히 둔다.
- 정보 부족: 확정불가
- 기준 초과 가능성: 보완필요
- 모든 조건 충족 및 근거 확인: 검토가능 또는 허가검토 가능

이 단계에서 판돌이는 단순히 “검색 결과를 보여주는 앱”이 아니라, 담당자가 실제 검토표를 채우듯이 조건을 모아가는 업무 판단 보조봇으로 방향이 넓어졌다.

실제 inject 사례 1: 000사 파사드·컵 모형

첫 번째 inject 사례는 000 파사드·컵 모형 간판이었다.

원문은 민원인용 안내문 성격이었다.
내용에는 컵 모양 구조물, 로고, 파사드 또는 바탕판이 결합된 벽면 간판 검토가 들어 있었다.

이 사례에서 핵심은 “가능합니다”라고 단정하면 위험하다는 점이었다.

정리한 판단은 이렇다.

컵 모형과 로고가 하나의 디자인으로 결합되어 있으면 하나의 일체형 벽면이용간판으로 볼 수 있다.
파사드 또는 바탕판 위에 로고나 모형을 붙이면 로고만이 아니라 파사드 전체 외곽이 규격 산정 대상이 될 수 있다.
심의는 자동 허용 절차가 아니다.
“심의를 통과하면 가능합니다” 같은 표현은 피해야 한다.

그래서 000 사례는 공식 승인하지 않고 PENDING으로 남겼다.
대신 민원인 안내문에서 피해야 할 표현과 안전한 대체 문장을 wiki에 남겼다.

이 사례에서 배운 점은 명확했다.

실제 사례는 매우 중요하지만, 법령·가이드라인과 대조되기 전에는 공식 기준으로 승격하면 안 된다.

실제 inject 사례 2: @@@ 상단간판

두 번째 inject 사례는 @@@ 상단간판 관련 메모였다.

원문에는 이런 내용이 있었다.

상단간판은 가능하다는 취지
다만 광고주의 주소를 바꾸는 것이 좋다는 메모
필요 서류: 임대차계약서, 사업자등록증, 기존 상단간판 철거 전·후 사진
상표권자가 다른 회사인 경우의 질문

이 문서는 짧았지만 업무적으로 중요한 포인트가 많았다.
단순히 “가능”으로 저장하면 안 되고, 실제 담당자가 다음에 같은 질문을 받았을 때 무엇을 확인해야 하는지 남겨야 했다.

그래서 wiki에는 이렇게 정리했다.

사례: @@@상단간판 설치 가능 여부와 서류 검토
판단: 주소, 임대차계약, 사업자등록증, 기존 간판 철거 여부, 상표 사용 권한을 함께 확인
예외: 상표권자와 광고주가 다르면 권리관계 확인 필요
재발방지 규칙: 개인정보는 wiki 본문에 옮기지 않고, 업무 판단 포인트만 남김

처음에는 PENDING으로 넣었다.
이후 사용자가 “검토 완료로 하라”고 해서 REVIEWING, 즉 승인 대기 상태로 바꿨다.

이 과정에서 /review 화면의 역할도 명확해졌다.

wiki에서 만든 초안은 DB ManualArticle로 들어간다.
/review에서 내용을 보고 승인/반려한다.
승인하면 APPROVED가 되어 검색 답변에 더 강하게 반영된다.

이 구조가 생긴 것이 이번 작업의 가장 큰 전환점이었다.

Before vs After

Before

원본 파일은 많지만 어디에 어떤 판단이 있는지 찾기 어려웠다.
법령, 가이드라인, 사례가 따로 놀았다.
웹앱이 DB와 wiki를 제대로 연결하지 못했다.
민원 응대 사례를 저장해도 공식 매뉴얼과 검토대기 사례의 구분이 약했다.
“가능합니다” 같은 문장을 그대로 답변에 쓰면 위험했다.

After

원본은 R2 또는 local source asset으로 보존한다.
판단 지식은 wiki 문서로 정리한다.
DB는 wiki 문서를 ManualArticle로 받아 검토 상태를 관리한다.
/review에서 승인/반려할 수 있다.
/search는 DB와 wiki를 기반으로 결론 → 기준 → 근거 순서의 답변을 만든다.
KFC, FSN 같은 실제 사례가 업무매뉴얼 후보로 남고, 승인 전 상태도 구분된다.

After 2차 개선 방향

/search는 단순 검색 답변을 넘어서 질문 의도를 먼저 분류한다.
규격 조회 질문은 해당 간판 종류의 숫자 기준을 결론에 먼저 보여준다.
허가 판단 질문은 조건 슬롯을 만들고 부족한 정보를 되묻는다.
사용자가 후속으로 입력한 짧은 값은 이전 질문의 슬롯에 누적한다.
기준을 초과한 값은 즉시 보완필요로 표시한다.
공식 법규집/가이드와 wiki·사례가 충돌하면 최신 공식 기준을 우선하고, 충돌 사실을 숨기지 않는다.

가장 중요했던 설계 판단

이번 작업에서 가장 중요했던 판단은 “DB를 지식의 본문으로 보지 않은 것”이다.

DB는 필요하다.
하지만 DB는 대장이다.

진짜 업무지식은 wiki에 있다.

wiki에는 다음이 들어간다.

왜 그렇게 판단하는가
어떤 법령을 먼저 보는가
어떤 문장은 민원인에게 위험한가
예외는 어디까지 인정되는가
다음 담당자가 같은 실수를 하지 않으려면 무엇을 확인해야 하는가

DB는 그 지식을 웹앱에서 검색하고 승인하고 상태 관리하기 위한 운영 계층이다.

이 역할 분리가 잡히면서 판돌이가 드디어 “돌아가는 느낌”을 주기 시작했다.

사용한 도구와 역할

Hermes Agent: 원본 확인, wiki 작성, DB 동기화, 검증
Claude Code: 웹앱 기능 구현과 수정 위임
Next.js: 판돌이 웹앱
PostgreSQL + Prisma: DB 대장
Cloudflare R2: 원문창고
Markdown wiki: 업무매뉴얼
/review: 승인/반려 화면
/search: wiki와 DB를 기반으로 답변하는 화면

이번 작업에서 만든 핵심 흐름

원본 문서
  ↓
Markdown / raw-data
  ↓
wiki 컨셉 문서
  ↓
DB ManualArticle / CaseRecord / ReviewOpinion
  ↓
/review 검토·승인
  ↓
/search 답변 반영
  ↓
질문 유형 분류
  ↓
규격 조회 또는 판단기준 생성
  ↓
조건 슬롯 누적 / 보완필요 표시 / 근거 충돌 검토

이 흐름이 생기면서 판돌이는 단순한 문서 검색기가 아니라, 업무 지식을 축적하고 승인하는 시스템에 가까워졌다.

아직 남은 과제

아직 완성은 아니다.

앞으로 더 해야 할 일은 다음과 같다.

승인된 매뉴얼과 검토중 매뉴얼이 검색 답변에 어떻게 반영되는지 더 세밀하게 조정하기
/review 화면에서 “검토 완료”와 “승인”의 차이를 더 직관적으로 보여주기
원문 PDF/HWPX에서 자동 추출된 내용의 품질을 계속 점검하기
담당자별 관점, 예외 사례, 재발방지 규칙을 더 많이 축적하기
실제 민원 응대 문안까지 안전한 표현으로 자동 제안하게 만들기
돌출간판 규격 알려줘 같은 규격 조회에서 숫자 기준이 빠지지 않도록 섹션 추출 로직 보강하기
허가 가능한지 판단기준 만들어줘 같은 질문에서 조건 슬롯, 누락 정보, 후속 질문을 구조화하기
후속 답변 3.2m야, 1.1m야 같은 짧은 입력을 이전 질문과 연결해 누적하는 decision session 구현하기
공식 법규집/가이드, wiki, DB 사례, 담당자 의견이 서로 다를 때 근거 우선순위와 충돌 처리 결과를 답변에 표시하기

배운 점

이번 작업에서 가장 크게 배운 점은 이것이다.

업무봇은 답변을 잘하는 것보다, 어떤 근거와 상태의 지식을 답변에 쓰는지 구분하는 것이 더 중요하다.

그리고 오늘 추가로 배운 점은 이것이다.

“위키를 참조했다”는 말만으로는 부족하다. 업무봇은 해당 질문에 맞는 wiki 섹션을 찾고, 그 안의 숫자·조건·예외를 정확히 꺼내야 한다.

공식 매뉴얼은 APPROVED다.
돌출간판 규격 질문은 spec lookup이다.
돌출간판 허가 가능 여부 질문은 decision criteria다.

이 차이가 생겼기 때문에 판돌이는 이제 “아무 말이나 그럴듯하게 답하는 봇”이 아니라, 업무매뉴얼을 쌓아가며 조심스럽게 답변하고, 조건을 모아 판단기준을 만드는 시스템이 될 수 있다.

마무리

이번 사례는 웹앱 하나를 만든 이야기가 아니다.

원본 데이터를 Markdown으로 바꾸고, wiki로 컨셉을 연결하고, DB와 검토 상태를 붙이고, Claude Code로 웹앱 기능을 위임하면서, 실제 업무 지식이 쌓이는 구조를 만든 기록이다.

아직 갈 길은 남아 있지만, 이제 판돌이는 방향이 보인다.

원본은 보관하고, 판단은 wiki에 남기고, 승인은 웹앱에서 하고, 답변은 승인된 지식을 중심으로 만든다.

hermes 쓰면서 좋았던점은 프로젝트의 범위를 구애받지 않고 돌아다니면서 파악한다는 점이였다. 코딩할 때도 클로드에서 개발자 관점에서 이야기해달라고 하니, 프로젝트 폴더가 달라도 그 프로젝트로 가서 코드 보고 개선계획을 task단위로 만들수 있었다.

🔥<24기 AI 스터디> 9/21 모집 마감 🔥