신입 직원이 왔다. 판돌이 위키로 38문답 온보딩 사이트를 하루 만에 배포했다

📝 한 줄 요약

우리 부서에 새 직원이 온 것을 기회로 삼아, 판돌이 위키에서 신규 담당자가 가장 궁금해할 질문 38개를 뽑았습니다. 과대개발을 걷어낸 정적 학습 사이트를 만들고 GitHub CLI와 Vercel CLI로 바로 배포한 뒤, 모호한 답변 32개를 다시 감사해 실제 판단기준이 보이도록 고쳤습니다.

바쁘시면 이것만 읽어도 됩니다.

• 출발점: “새 직원에게 판돌리 위키로 온보딩을 해보자.”

• 콘텐츠: 첫날 필수부터 허가·신고·규격·심의·안전점검까지 38문답

• 기강 잡기: DB, 로그인, 관리자 화면, 진도 저장, CMS를 모두 제외

• 배포: GitHub CLI 인증 → 비공개 저장소 → Vercel CLI 인증 → production 배포

• 배포 후 감사: 추상적인 답변 32개를 수치·대상·분기기준 중심으로 수정

• 실제 검증: 자동 테스트 7 PASS / 0 FAIL, TypeScript PASS, production build PASS, Vercel Ready

• 남은 경계: 자동검증과 AI 원문 대조는 끝났지만 담당자의 법적·의미적 최종승인은 별도

운영 사이트: https://pandori-newbie-guide.vercel.app

👋 먼저, 판돌이가 무엇인가요?

판돌이는 우리 부서의 옥외광고물 업무를 돕기 위해 만들고 있는 업무 에이전트이자 위키입니다.

법령 검색만 하는 챗봇이 아닙니다. 실제 업무에서 생긴 질문과 판단을 다음과 같이 축적하는 것이 목표입니다.

새로운 사례
→ 사실관계와 법령 대조
→ 사례·판단·예외·재발방지 규칙으로 정리
→ 담당자 검토
→ 판돌이 위키에 반영
→ 다음 질문과 신규 직원 교육에 재사용

핵심은 담당자가 바뀔 때 문서 몇 개를 넘겨주는 데서 끝나지 않는 것입니다. 업무의 맥락과 주의사항을 익힌 전담 에이전트가 다음 담당자에게 계속 설명하고 함께 일하게 만드는 것입니다.

그런데 이런 위키가 정말 살아 있는지는 문서 개수로 알 수 없습니다.

업무를 처음 맡은 사람이 실제 질문을 했을 때, 바로 이해할 수 있는 답을 주는가?

마침 우리 부서에 새로운 직원이 왔습니다. 저는 이 상황을 인수인계의 부담이 아니라 판돌이 위키를 시험할 기회로 봤습니다.

🎯 새 직원이 온 것은 위키를 시험할 기회였다

기존 담당자는 업무용어를 이미 알고 있습니다. 그래서 위키에 “심의 여부를 검토한다”, “규격을 확인한다”고 적혀 있어도 머릿속에서 나머지를 채울 수 있습니다.

하지만 새 직원에게는 다릅니다.

• 무엇이 허가이고 무엇이 신고인가?

• 간판 종류는 이름으로 구분하는가, 설치 구조로 구분하는가?

• 처리기간은 며칠인가?

• 연장은 언제 신청해야 하는가?

• 안전점검은 언제 받아야 하는가?

• 서울시 심의와 강남구 심의는 어떻게 다른가?

• 본심의와 소심의는 규모만 보면 자동으로 정해지는가?

이 질문에 “관련 기준을 확인하세요”라고 답하면, 말은 맞아도 온보딩 자료로는 실패입니다.

그래서 Hermes Agent에게 이렇게 요청했습니다.

판돌이 위키를 활용해서 새로 온 직원이 가장 궁금해할 질문을 선정하고,
짧은 문답형 학습 사이트로 만들어보자.
기능을 과하게 붙이지 말고 실제 배포까지 하자.

🧭 1단계: 새 직원의 머릿속 순서로 38문답을 뽑았다

질문을 법령 목차 순서로 만들지 않았습니다. 처음 업무를 맡은 사람이 실제로 궁금해할 순서로 나눴습니다.

• 첫날 필수 7개: 광고물 해당성, 기본 확인사항, 허가·신고의 출발점

• 허가·신고 8개: 신청서류, 사용승낙, 자사·타사광고, 처리기간

• 유형·규격 11개: 벽면·돌출·창문·상단·옥상·지주·입간판

• 심의·안전·연장 9개: 심의 단계, 구조서류, 안전점검, 연장과 변경

• 실수·고위험 3개: 비대상과 적용배제, 위법시공, 철거·처분

각 답변은 다음 네 칸으로 통일했습니다.

결론
→ 먼저 확인할 것
→ 핵심 기준
→ 근거

고위험 질문에만 담당자 확인 경고를 붙였습니다. 신규 직원에게 내부 승인상태나 AI 운영용 메타데이터까지 가르치지는 않았습니다. 교육에 필요한 실무기준만 보여주고, 내부 품질관리는 화면 뒤에 남겼습니다.

🧹 2단계: 개발하기 전에 ‘과대개발 금지’부터 선언했다

이런 사이트를 만들면 기능 아이디어가 빠르게 늘어납니다.

• 로그인

• 개인별 진도 저장

• 관리자 화면

• DB

• 실시간 위키 연동

• 콘텐츠 승인 워크플로우

• 접속통계

• 별도 CMS

• AI 챗봇 연결

다 있으면 좋아 보입니다. 하지만 첫 목적은 하나였습니다.

새 직원이 질문을 보고, 답을 열어 보고, 검색할 수 있게 한다.

그래서 Hermes와 함께 과대개발 기강을 한 번 잡았습니다.

과감히 뺀 것

• DB와 서버 API

• 로그인과 관리자 화면

• 학습 진도 저장

• 실시간 wiki 연동

• 별도 CMS

• 접속통계

• 복잡한 승인상태 UI

• 판돌이 DB 미러 동기화

남긴 것

• 한 페이지짜리 정적 사이트

• 질문 38개

• 검색

• 5개 카테고리

• 처음에는 닫혀 있는 아코디언

• 모바일·PC 반응형

질문 수는 줄이지 않았습니다. 콘텐츠 범위는 유지하되 시스템의 복잡도만 줄였습니다.

저에게 이번 작업의 중요한 기준은 이것이었습니다.

심플함은 기준을 빼는 것이 아니라, 불필요한 시스템을 빼고 필요한 기준을 짧게 보여주는 것이다.

🛠️ 3단계: 테스트를 먼저 만들고, 판돌이 색감으로 구현했다

사이트는 Next.js와 TypeScript로 만들었습니다. 새 직원을 위한 별도 프로젝트로 분리해 기존 판돌이 앱의 미완료 작업과 섞이지 않게 했습니다.

처음에는 질문 데이터와 컴포넌트가 없는 상태에서 테스트가 실패하는 것을 확인했습니다. 그다음 필요한 만큼만 구현해 테스트를 통과시켰습니다.

주요 화면은 단순합니다.

• 상단 검색창

• 5개 카테고리 버튼

• 검색 결과 수

• 질문 목록

• 클릭하기 전에는 닫혀 있는 답변

아코디언도 별도 UI 라이브러리 대신 기본 HTML인 <details>와 <summary>를 사용했습니다. 키보드 Enter로 열 수 있고, 자바스크립트가 복잡해질 이유도 줄었습니다.

디자인은 기존 판돌이의 웜 라이트 배경과 딥틸 선택색을 이어갔습니다. 신규 직원에게 별도 서비스처럼 보이기보다 판돌이 업무체계의 한 부분처럼 느껴지게 하고 싶었습니다.

🚀 4단계: GitHub CLI, Vercel CLI 인증하고 그냥 배포했다

로컬에서만 잘 보이는 사이트는 실제 온보딩 도구가 아닙니다. 그래서 구현이 끝난 뒤 “배포 준비 문서”를 만드는 대신 CLI 인증을 확인하고 바로 배포했습니다.

GitHub CLI 인증 확인
→ 비공개 저장소 생성·main 브랜치 push
→ Vercel CLI 로그인 확인
→ production 배포
→ 운영 URL 확인

GitHub 저장소는 비공개로 유지하고, 학습 사이트만 URL로 접근할 수 있게 했습니다.

배포 결과:

• Vercel production 상태: Ready

• 운영 URL: https://pandori-newbie-guide.vercel.app

• GitHub main과 연결

이 과정에서 배운 점은 단순했습니다.

작은 내부도구는 완벽한 배포계획보다, 권한을 확인하고 실제 URL을 열어보는 것이 훨씬 빨리 문제를 드러낸다.

😅 그런데 배포하고 보니, 답변이 ‘맞지만 쓸모없게’ 모호했다

첫 배포 후 다시 읽어보니 문제가 보였습니다.

• “규격을 확인합니다.”

• “심의대상인지 검토합니다.”

• “기간 안에 신청합니다.”

• “안전점검 여부를 확인합니다.”

틀린 말은 아닙니다. 하지만 신규 직원의 다음 질문이 그대로 남습니다.

그래서 몇 층, 몇 제곱미터, 며칠인데요?

코드와 화면은 작동했지만, 콘텐츠가 초보자의 판단을 충분히 돕지 못했습니다. 자동 테스트는 데이터가 38개인지, 검색이 되는지, 화면이 닫혀 시작하는지를 검사할 수 있습니다. 그러나 “이 답변만 읽고 신규 직원이 실제 분기기준을 이해할 수 있는가?”까지 보장하지는 못합니다.

그래서 배포를 완료로 보지 않고, 공개된 화면을 기준으로 답변 전체를 다시 감사했습니다.

🔍 5단계: 38문항을 세 작업반으로 나눠 다시 감사했다

감사 범위를 세 부분으로 나눴습니다.

1. Q01~Q15: 허가·신고·서류·기간

2. Q16~Q26: 유형·규격·수량

3. Q27~Q38: 심의·안전·연장·고위험

각 작업반은 현재 답변을 판돌이 canonical wiki와 권위 원문에 다시 대조했습니다.

법
→ 시행령
→ 서울시 조례
→ 강남구 조례
→ 서울시 고시
→ 강남구 공고
→ 특정구역·운영기준

그 결과 38문항 중 32문항을 구체화했고, 이미 기준이 충분했던 6문항은 유지했습니다.

실제로 바뀐 것

• 허가·변경허가 10일

• 신고·변경신고 5일

• 심의가 필요한 사건 20일

• 관리자 정보 변경신고 변경일부터 15일 이내

• 표시기간 연장 만료일 전후 30일 이내

• 업소당 간판 총수량 2개·1개

• 안전점검 관련 15일 기준

• 30㎡ 이상과 30㎡ 초과의 구분

• 일반 돌출간판 5층 이하·세로 3m 이내 원칙

• 벽면·창문·상단·옥상·지주 간판의 층수·면적·수량 기준

물론 숫자를 많이 넣는다고 좋은 답변이 되는 것은 아닙니다. 어떤 조건에서 그 숫자가 적용되는지 함께 적어야 합니다.

⚖️ 가장 어려웠던 질문: 서울시 심의, 강남구 심의, 본심의와 소심의

처음 Q27은 서울시 심의, 강남구 본심의, 강남구 소심의 대상을 나눠 적으려 했습니다. 그런데 원문을 다시 감사하면서 중요한 경계를 발견했습니다.

법령과 조례가 먼저 정하는 것은 크게 서울시 심의 대상과 강남구 구 심의 대상입니다. 구 심의 대상이라고 해서 모두 자동으로 본심의가 되는 것은 아닙니다.

본위원회와 소위원회 배정은 현행 위임사항, 운영기준, 구청장의 안건 부의에 따라 확인해야 합니다. 규모만으로 본심의·소심의를 자동 확정하면 안 됩니다.

그래서 답변을 이렇게 고쳤습니다.

1. 먼저 서울시 심의 대상인지 확인
2. 아니면 강남구 구 심의 대상인지 확인
3. 구 심의 대상이면 현행 위임사항과 안건 배정기록 확인
4. 본위원회 또는 소위원회 배정
5. 심의가 끝나도 허가·신고 수리는 별도 절차

신규 직원에게 숫자표를 주는 것보다 더 중요한 것은 법정 대상과 내부 운영단계를 섞지 않는 것이었습니다.

✅ 실제 결과와 아직 끝나지 않은 것

2026년 8월 4일 다시 실행한 결과입니다.

질문: 38개
구체화한 문항: 32개
유지한 문항: 6개
자동 테스트: 7 PASS / 0 FAIL
TypeScript 검사: PASS
Next.js production build: PASS
정적 페이지 생성: PASS
Vercel production: Ready

하지만 이 숫자가 의미하는 범위를 분리해야 합니다.

완료된 것

• 질문 기획

• 정적 사이트 구현

• 검색·카테고리·아코디언 동작

• GitHub push

• Vercel 실제 배포

• 판돌이 위키와 법령 원문을 이용한 AI 재감사

• 재감사 결과의 코드 반영

• 자동 테스트·타입검사·프로덕션 빌드

아직 별도인 것

• 사람의 의미적·법적 최종검토

• 담당자의 공식 승인

• 개별 민원의 허가·신고·심의·처분 판단

따라서 7개 테스트가 통과했다는 것을 38개 답변의 법적 정답률 100%로 표현하지 않습니다. 자동검증은 구조와 동작을 확인했고, AI 감사는 원문 대조와 모호성 개선을 수행했습니다. 최종 행정판단의 책임과 승인은 여전히 사람에게 있습니다.

💡 이번 작업에서 배운 점

1. 신규 직원은 업무매뉴얼의 가장 좋은 테스트 사용자다

기존 담당자가 자연스럽게 보충해 읽는 문장은 신규 직원에게는 빈칸입니다. 새 직원이 다시 묻는 지점이 곧 위키에서 빠진 판단기준입니다.

2. 살아있는 위키는 문서 창고가 아니라 수정 루프다

위키에서 질문 선정
→ 학습자료 제작
→ 실제 화면에서 모호성 발견
→ 원문 재감사
→ 위키 기반 답변 구체화
→ 다시 테스트·배포

문서를 쌓기만 했다면 이번 수정은 일어나지 않았을 것입니다.

3. 과대개발을 막는 것도 에이전트의 중요한 역할이다

에이전트는 기능을 빠르게 만들 수 있기 때문에 오히려 더 쉽게 과대개발합니다. 그래서 “무엇을 만들까?”만큼 “무엇을 만들지 않을까?”를 먼저 정해야 했습니다.

4. 배포는 완료가 아니라 가장 현실적인 QA다

로컬 데이터 파일로 볼 때는 괜찮았던 문장이 실제 학습 화면에서는 모호하게 느껴졌습니다. 운영 URL을 열어보는 순간 독자의 시선으로 읽게 됐습니다.

5. 자동 PASS와 사람 승인을 분리해야 한다

테스트가 통과한 것, AI가 원문을 대조한 것, 담당자가 의미와 법적 적용범위를 승인한 것은 서로 다른 상태입니다. 이 구분이 있어야 행정업무에서 AI를 과신하지 않을 수 있습니다.

📋 비슷한 업무에 재사용할 프롬프트

우리 팀에 새 직원이 왔다.
기존 업무위키를 읽고 신규 직원이 가장 먼저 궁금해할 질문을 선정해줘.

조건:
1. 질문은 실제 업무 흐름 순서로 묶을 것
2. 답변은 결론·확인사항·핵심기준·근거로 구성할 것
3. “검토한다”, “확인한다”에서 끝내지 말고 적용 가능한 수치와 분기를 적을 것
4. 개별 처분이나 고위험 판단은 사람 확인으로 남길 것
5. 먼저 과대개발 요소를 찾아 제거할 것
6. 최소 기능으로 구현하고 실제 테스트·빌드·배포까지 할 것
7. 배포 후 모든 답변을 다시 읽어 모호한 문장을 전수감사할 것
8. 자동검증, AI 의미감사, 사람 승인 상태를 분리해 보고할 것

🌱 다음 단계

이번에는 38문답 정적 사이트로 시작했습니다. 다음 단계는 기능을 더 붙이는 것이 아닙니다.

실제 신규 직원이 사용하면서 다시 물어보는 질문을 모아 다음 루프를 돌리는 것입니다.

신규 직원의 추가 질문
→ 판돌이 위키와 법령 대조
→ 기존 답변 보강 또는 신규 문항 추가
→ 담당자 검토
→ 회귀시험
→ 재배포

이렇게 되면 온보딩은 한 번 만들고 끝나는 교육자료가 아니라, 새로운 사람이 올 때마다 조직의 업무지식이 더 선명해지는 과정이 됩니다.

마무리

이번 작업에서 가장 인상적이었던 것은 사이트를 하루 만에 만든 사실이 아니었습니다.

새 직원이 온 것을 계기로, 그동안 쌓아둔 판돌이 위키를 실제 질문으로 시험했고, 배포된 화면에서 모호함을 발견했으며, 다시 법령과 위키를 대조해 32개 답변을 고쳤다는 점이었습니다.

업무위키의 완성도는 문서 수가 아니라, 새로운 담당자의 질문을 얼마나 구체적으로 해결하고 그 질문을 다시 조직지식으로 남기는지에서 드러납니다.

판돌이 뉴비 가이드는 작은 정적 사이트입니다. 하지만 이 작은 사이트를 통해 ‘업무를 아는 사람의 머릿속’을 다음 담당자가 사용할 수 있는 구조로 바꾸는 첫 실험을 해봤습니다.