사내 규정 AI를 만들기 전에 정할 것, 문서만 올려서는 부족한 이유

먼저 결론

• 문서 정리(전처리)는 AI와 함께 만든 파이썬 프로그램이 맡고, 사람은 "무엇이 회사의 공식 기준인가"만 확정합니다.
• 규정을 잘 설명하는 AI와 규정대로 정확하게 업무를 처리하는 시스템은 다릅니다.
• 돈이 걸린 판단은 AI의 답에 맡기지 않고 검증된 규칙으로 계산한 뒤 사람이 승인합니다.
• 시작은 문서 20~30개와 실제 질문 50개로 4주 동안 시험하고, 틀린 답의 원인을 찾아 필요한 부분만 고칩니다.

파일을 올리면 AI 서비스도 안에서 전처리를 한다

질문 자체는 맞는 말입니다. 파일을 올리면 AI 서비스도 안에서 글자를 뽑고, 나누고, 검색합니다. 자동이라 안 보일 뿐입니다.

문제는 회사 문서의 특성에서 생깁니다. 같은 규정이 여러 버전으로 남아 있습니다. 그대로 넣으면 옛 규정과 새 규정이 같이 검색되고, AI가 어느 쪽이 맞는지 헷갈립니다.

스캔본, 표, 계산식도 많습니다. 자동으로 읽어도 이런 곳에서 자주 틀립니다.

예외 사례가 규정처럼 보이기도 합니다. 작년에 한 번 승인한 예외를 올해의 일반 규정으로 안내할 수 있습니다. 직원마다 볼 수 있는 문서도 다릅니다. 개인 파일 질문과 수백 명이 쓰는 시스템은 다른 문제입니다.

그래서 저는 방향을 이렇게 잡았습니다. AI와 함께 전처리 프로그램을 만들어 돌리고, 사람은 애매한 것만 잡는다. 사람이 문서를 하나하나 정리하지도, AI에게 문서를 통째로 맡기지도 않습니다.

코드를 직접 다 짜지 않아도 됩니다. 무엇을 뽑고 어떻게 나눌지 설명하면 AI가 파이썬 코드를 써 줍니다.

프로그램은 같은 문서에 늘 같은 결과를 냅니다. 결과가 틀리면 어느 단계에서 틀렸는지 다시 돌려 볼 수 있습니다. 처음엔 단순하게 굴려 보고, 검증만 촘촘하게 합니다.

다만 사내 문서를 외부 AI 서비스로 보내도 되는지는 반드시 먼저 확인합니다.

규정을 설명하는 AI와 처리하는 시스템은 다르다

앞의 것은 문서 검색과 AI만으로도 상당 부분 됩니다. 뒤의 것은 그렇지 않습니다.

특히 지급 조건, 적용일, 환수 금액처럼 돈이 걸린 판단은 AI의 답에 맡기지 않습니다. 검증된 규칙으로 계산하고 사람이 최종 승인합니다.

회사 지식은 네 가지로 나눠야 섞이지 않는다

이 넷을 섞어서 AI에 넣으면 앞에서 말한 사고가 납니다. 예외 사례가 규정처럼, 폐지된 규정이 현행처럼 안내됩니다.

그래서 지식 정리는 파일을 모으는 일로 끝나지 않습니다. 정보마다 성격, 적용 범위, 책임자, 유효기간을 정하는 일입니다.

첫 단계는 PDF 변환보다 문서 대장이다

처음부터 모든 PDF를 변환하지 않습니다. 먼저 문서가 어디에 얼마나 흩어져 있는지 목록을 만듭니다. 문서마다 최소한 이런 항목을 적습니다.

• 문서 ID, 버전, 원본 파일 위치
• 공지일, 시행일, 종료일
• 적용 대상(조직·직급·업무)
• 담당 부서와 승인자
• 공개 범위, 개인정보 포함 여부
• 이전 버전과 대체 문서
• 검증 상태(검토 전 / 검토 완료)

원칙이 하나 있습니다. 문서 상태를 자동으로 '최신'이나 '유효'로 판정하지 않습니다. 담당자가 원본을 확인하고 적용 범위를 승인한 다음에 씁니다.

최신 규정만 검색하면 오히려 틀린다

규정이 여러 번 바뀌는 회사에서는 "최신 규정만 검색"하면 오히려 틀립니다. 실제 업무 질문은 이렇게 들어오기 때문입니다.

• 올해 4월에 입사한 사람에게 처음 적용된 규정은 무엇인가?
• 10월 개정 규정이 기존 대상자에게도 적용되는가?
• 신청일과 입사일이 다르면 어느 날짜가 기준인가?

그래서 날짜를 최소 세 가지로 나눕니다.

경과조치와 소급 적용도 따로 기록합니다. 10월에 규정이 바뀌어도 7월에 지원받은 사람은 이전 규정으로 평가받을 수 있습니다. 이런 내용은 시행일만으로는 판단할 수 없습니다.

실무에 쓰려면 원문 → 개정 이력 → 경과조치 → 개인별 적용 규정까지 이어져야 합니다.

금액 계산은 문서와 따로 만든 업무 규칙으로 한다

문서 검색은 AI가 잘 도와줍니다. 하지만 지급액이나 환수액 계산은 검증된 규칙으로 하는 편이 안전합니다.

그래서 규정 원문과 별도로, 조건을 구조화한 규칙 파일을 만듭니다. 금액 없이 구조만 보면 이렇습니다(설명용 가상 예시).

rule_id: SUPPORT-004
source: { document: SUPPORT-001, clause: "제4조" }
applies_to: experienced_staff
date_basis: hire_date        # 무엇을 기준일로 볼지
valid_from: 2026-10-01
required_data: [hire_date, recognized_income, requested_amount, guarantee_status]
on_missing_data: manual_review   # 데이터가 없으면 사람 검토로
on_conflict: manual_review       # 규정이 충돌하면 사람 검토로
final_approval: human_required

규칙은 이런 순서로 등록합니다.

1. AI와 함께 만든 추출 프로그램이 원문에서 규칙 후보를 뽑는다.
2. 담당자가 조건, 예외, 적용 대상을 검증한다.
3. 검증된 규칙만 등록한다.
4. 담당자가 확인한 과거 실제 사례로 계산 결과를 시험한다.
5. 승인된 규칙만 실제 업무에 적용한다.

저도 비슷한 일을 겪었습니다. 담당자가 없는 고객에게 새 담당자를 정하는 업무였습니다. 처음에는 지역·상품 등 100여 개 조건을 엑셀 함수식으로 관리했습니다.

사람 손과 시간이 너무 많이 들어 VBA로 옮겼습니다. 이후 파이썬으로 조건을 코드 규칙으로 다시 만들었고, 지금은 결과 파일만 확인합니다.

규정을 "읽는" 일과 규정대로 "처리하는" 일은 처음부터 다른 도구가 맡는 게 맞았습니다.

하나 덧붙이면, Claude Code의 지침 파일(CLAUDE.md)은 이런 업무 규칙을 담는 곳이 아닙니다. 지침 파일에는 개발 기준과 작업 방식을 씁니다. 규정 원문과 규칙, 지급 데이터는 별도 저장소에 둡니다.

전처리는 AI와 함께 만든 프로그램이 맡는다

표에서 프로그램이 맡는 칸은 모두 AI와 대화하며 만든 프로그램입니다. AI는 문서를 직접 고치지 않고 "이 문서들을 이렇게 처리하는 코드"를 만듭니다. 실제 전처리는 그 코드가 합니다.

기존 문서가 100개라도 사람이 100개를 다시 쓸 필요는 없습니다. 예를 들어 인사팀 문서라면 AI에게 이런 요구사항을 주고 전처리 프로그램을 만듭니다.

문서 폴더 전체를 읽어서 연차휴가와 관련된 규정, 신청 절차, 예외 사항, 담당자, 전산 처리 방법을 뽑는 파이썬 프로그램을 만들어 줘. 같은 내용이 여러 문서에 있으면 연결하고, 충돌하면 임의로 판단하지 말고 표시해서 따로 목록으로 남겨.

직원은 규정과 절차를 구분해서 묻지 않습니다. "연차는 어떻게 신청하나요?" 한 번에 규정(조건)과 전산 매뉴얼(신청 방법)이 같이 나와야 합니다. 전처리 프로그램이 여러 문서를 미리 이어 두어야 하는 이유입니다.

다만 프로그램이 정리한 결과를 새 정답 원본으로 삼지는 않습니다. 정리된 FAQ와 절차 요약은 검색을 돕는 보조 자료로 씁니다. 공식 답변의 근거는 원본 규정과 승인된 절차로 보여 줍니다.

문서에 없는 지식은 AI 인터뷰로 모은다

실제 업무의 상당 부분은 문서가 아니라 담당자의 경험에 있습니다. 퇴사자가 생기면 어떤 순서로 처리하고, 어느 부서에 연락하고, 무엇을 회수하는지가 그렇습니다. 담당자만 아는 경우가 많습니다. 문서를 아무리 올려도 AI가 알아낼 수 없습니다.

그래서 AI가 담당자를 인터뷰하게 합니다. "퇴사자가 생기면 가장 먼저 무엇을 하나요?", "승인 후에는요?", "예외가 있나요?"처럼 묻습니다. 답을 정리해 업무 매뉴얼 초안을 만들고, 담당자는 읽고 고쳐서 승인만 합니다.

초안에는 최소한 이 여섯 가지가 있어야 합니다.

• 언제 이 절차를 시작하는가
• 어떤 단계를 거치는가
• 단계별 담당자는 누구인가
• 필요한 서류와 확인은 무엇인가
• 예외는 무엇인가
• 언제 끝난 것으로 보는가

"제 연차 몇 개 남았어요?"는 문서로 답할 수 없다

"연차 신청 방법 알려줘"는 문서 검색으로 답합니다. 그런데 "제 연차 몇 개 남았어요?"는 다릅니다. 이건 문서에 없고 인사 시스템의 개인별 데이터에 있습니다.

이런 질문은 업무 시스템을 직접 조회해서 답해야 합니다. 실적, 지급액, 잔여 일수 같은 숫자를 문서로 만들어 넣으면 금방 낡은 숫자로 답하게 됩니다.

보안은 지시문으로 되지 않는다

권한은 검색하기 전에 막습니다. 화면에서 메뉴를 숨기는 것으로는 부족합니다. AI가 검색하는 문서에도 같은 권한이 적용되어야 합니다.

"개인정보를 보여 주지 마라"를 지시문에 쓰는 것으로는 보안이 되지 않습니다. 데이터베이스 권한과 서버의 승인 로직이 실제로 막아야 합니다.

문서 안에 숨은 명령도 조심합니다. 검색된 문서에 "이전 지시를 무시하라" 같은 문장이 있으면 AI가 따를 수 있습니다. 문서 내용은 자료로만 다루게 설계합니다.

지급, 환수, 예외 처리는 사람이 최종 확인합니다. 외부 AI API를 쓴다면 어떤 데이터가 얼마나 나가는지 먼저 정리하고 승인을 받습니다.

규정이 바뀌면 원본 등록, 규칙 변경, 승인, 반영을 각각 이력으로 남깁니다. 이 구조가 없으면 처음엔 잘 돌다가 반년 뒤에는 옛 규정이 남은 시스템이 됩니다.

4주 실험으로 작게 시작한다

처음부터 전사 규정을 구조화하지 않습니다.

구조화 작업은 정확도가 실제로 좋아지는 것을 확인한 다음에 늘립니다. 처음부터 프로그램이 만든 수많은 정리 파일을 관리할 필요는 없습니다.

실험이 잘 되면 규정 한 종류를 골라 끝까지 완주합니다. 원본 → 구조화된 지식 → 검색 → 규칙 판정 → 신청 처리까지가 첫 프로젝트의 완료 기준입니다. 여러 종류를 동시에 하는 것은 그다음입니다.

직접 시험해 보니 같은 지점에서 막혔다

이 정리는 머릿속 계획만은 아닙니다. 앞서 사내 문서 AI를 직접 시험하며 같은 지점에서 막혔습니다.

PC 한 대로 로컬 RAG를 띄웠을 때 문서는 100% 찾았습니다. 그런데 내용으로 답한 비율은 0%였습니다.

가장 큰 문제는 모든 단계가 한 도구에 묶여 어디서 끊겼는지 볼 수 없었던 것입니다. 4주 실험의 4주차에 "틀린 답의 원인을 단계별로 나눈다"를 넣은 이유입니다. (로컬 시험 실패기)

AI 코딩 도구로 만든 코드가 계획과 다르게 동작한 적도 있습니다. 사내 문서에서 답을 못 찾으면 웹 검색으로 넘어가는 구조였습니다. 규정 챗봇이 인터넷 내용을 회사 답처럼 말하면 안 됩니다. AI가 만든 결과물은 계획과 대조해야 합니다.

지식형인지 업무형인지부터 정해야 한다

시작 전에 꼭 정할 질문이 하나 있습니다. 직원이 "경조금 지급 기준이 뭔가요?"라고 물으면 답하는 지식형 AI가 우선인지입니다. 아니면 "연차 신청해 줘", "퇴사 처리 진행해 줘"처럼 실제 업무까지 하는 AI로 갈지입니다.

앞의 것이면 문서 대장, 날짜, 출처 표시에 집중하면 됩니다. 뒤의 것이면 처음부터 업무 규칙, 개인별 데이터 연결, 승인 권한, 이력을 설계에 넣어야 합니다.

이 답에 따라 문서를 정리하는 방식과 저장 구조가 처음부터 달라집니다. 로컬에서 직접 막힌 과정은 로컬 시험 실패기에 적었습니다.