이 가이드는 짧은 명령어 하나로 끝나지 않습니다. 필요한 자료를 정리하고, AI가 추측하지 않게 경계를 주고, 출력 내용을 원문과 대조해 실제로 사용할 수 있는 결과로 만드는 전체 과정을 설명합니다.
예시 안내 본문의 입력과 기대 결과는 절차를 설명하기 위해 구성한 예시입니다. 실제 수행 결과나 성과를 주장하지 않으며, 중요한 업무에는 원자료와 담당자의 최종 확인이 필요합니다.
- 수정일보다 먼저 문서가 답해야 하는 업무 질문과 공식 근거를 연결합니다.
- AI는 차이 후보를 찾는 데만 쓰고 정책 변경 여부와 공개 결정은 담당자가 확인합니다.
- 즉시 수정, 담당자 확인, 유지, 폐기 후보로 나눠 다음 점검까지 기록합니다.
완성 결과물
누구에게 필요하고, 누구에게는 맞지 않을까
이런 분께 맞습니다
- FAQ와 업무 매뉴얼이 늘어나 무엇이 최신인지 판단하기 어려운 운영자
- 담당자가 바뀌어도 같은 기준으로 문서를 점검하고 싶은 팀
- AI 검색 도우미에 넣기 전에 지식 원문의 품질부터 정리하려는 기획자
이 경우에는 멈추세요
- 법무·의료·안전 정책을 담당 전문가 승인 없이 AI가 최신이라고 판정하게 하는 경우
- 원문 접근 권한과 개인정보 처리 기준이 없는 상태에서 전체 문서를 외부 서비스에 올리려는 경우
- 문서 개수만 줄이기 위해 사용 기록과 보존 의무를 확인하지 않고 삭제하려는 작업
시작 전에 준비할 것
도구를 열기 전에 입력 자료와 최종 확인자를 정하면, 그럴듯하지만 틀린 결과를 줄일 수 있습니다.
- 문서 ID, 제목, 공개 범위, URL, 담당자, 마지막 검토일을 담은 목록
- 각 문서가 인용하는 정책·제품 도움말·표준의 공식 원문 링크
- 최근 문의, 실패 티켓, 검색어처럼 문서가 실제로 쓰이는 상황의 비식별 표본
- 즉시 수정과 담당자 확인을 구분할 판정 기준
- 최종 승인자와 변경 이력을 기록할 위치
단계별 과정
문서 목록에 식별자와 책임자를 붙입니다
왜 필요한가 — 제목만 비슷한 문서가 여러 개 있으면 어느 문서를 고쳐야 하는지부터 흔들립니다.
먼저 현재 공개되거나 내부에서 참조되는 문서를 한 표에 모읍니다. 제목과 URL만 적지 말고 바뀌지 않는 문서 ID, 독자, 담당 팀, 적용 업무, 공식 근거, 마지막 확인일을 나눠 적습니다.
마지막 수정일과 마지막 검토일은 별도 칸으로 둡니다. 맞춤법을 고친 날짜가 정책을 다시 확인한 날짜처럼 보이면 오래된 내용이 새 문서로 오인되기 때문입니다. 담당자가 비어 있으면 최신 판정을 내리지 말고 먼저 소유자 지정 대상으로 분류합니다.
제목: 반품 접수 방법 URL: /kb/returns 마지막 수정: 2026-07-20 본문 근거: 교환·반품 정책 RETURN-2025-09 담당자: 미기재
KB-014 | 반품 접수 방법 | 고객지원 담당자용 | 근거 RETURN-2025-09 | 마지막 내용 검토 미확인 | 소유자 없음 | 상태: 판정 보류
최신성 판정 기준을 문서 유형별로 정합니다
왜 필요한가 — 모든 문서를 30일마다 고치는 식의 규칙은 변하지 않은 글에 새 날짜만 붙이는 결과를 만들기 쉽습니다.
정책 문서는 원문 개정, 제품 사용법은 화면·기능 변경, 연락처 문서는 담당 채널 변경처럼 낡았다고 볼 조건이 서로 다릅니다. 유형마다 변경 신호, 확인 주기, 반드시 물어볼 담당자를 정합니다.
판정값은 ‘근거와 일치’, ‘부분 변경’, ‘근거 확인 불가’, ‘중복’, ‘업무 종료’로 제한합니다. 날짜가 오래됐다는 이유만으로 오류라고 쓰지 않고, 실제 차이가 확인된 경우에만 부분 변경으로 올립니다.
문서 유형: 제품 사용법 변경 신호 후보: 메뉴명, 버튼 위치, 지원 파일 형식, 계정 권한 공식 근거: 공급자 도움말 기본 확인 주기: 분기
제품 사용법 판정 규칙 | 공식 도움말과 핵심 절차 일치=유지 | 메뉴명·권한·지원 범위 차이=부분 변경 | 공식 문서 접근 실패=근거 확인 불가 | 검토 책임=서비스 운영자
공식 원문과 내부 문서를 작은 단위로 대조합니다
왜 필요한가 — 문서 전체를 한 번에 비교하면 AI가 표현 차이를 정책 변경처럼 과장하거나 중요한 숫자를 놓칠 수 있습니다.
내부 문서를 대상, 조건, 단계, 예외, 연락처, 날짜와 숫자로 쪼갭니다. 공식 원문도 같은 필드로 정리한 뒤 한 행씩 대조하게 합니다. 모든 차이 행에는 내부 문장과 공식 원문 위치를 함께 붙입니다.
AI에게 ‘최신 버전으로 고쳐 달라’고 바로 요청하지 않습니다. 먼저 동일, 표현 차이, 사실 차이, 근거 없음 중 하나를 고르고 확신하지 못한 이유를 쓰게 합니다. 링크가 열리지 않거나 개정 이력을 알 수 없으면 담당자 확인으로 넘깁니다.
내부 문장: 파일은 PDF와 DOCX만 올릴 수 있습니다. 공식 도움말: PDF, DOCX, TXT 파일을 지원합니다. 확인일: 2026-08-15 규칙: 두 문장만 비교하고 지원 범위를 추정하지 말 것.
차이 유형: 사실 차이 내부 값: PDF, DOCX 공식 값: PDF, DOCX, TXT 수정 후보: TXT 추가 검토 필요: 해당 기능이 우리 요금제와 계정에도 적용되는지 담당자가 실제 화면에서 확인
사용 흔적에서 빠진 문제를 찾습니다
왜 필요한가 — 공식 원문과 맞더라도 사용자가 그 문서로 일을 끝내지 못하면 지식베이스 역할을 다하지 못합니다.
최근 검색어, 해결되지 않은 문의, 문서에서 이탈한 뒤 들어온 질문을 개인정보 없이 묶습니다. 문서가 답해야 할 질문과 실제 본문 위치를 연결하고, 답이 없으면 내용 보강 후보로 표시합니다.
검색량이나 문의 건수만으로 원인을 단정하지 않습니다. 예를 들어 ‘반품 배송비’ 검색이 많아도 정책이 틀렸다는 뜻은 아닙니다. 사용자가 필요한 조건을 제목이나 첫 화면에서 찾기 어려운지 별도로 확인합니다.
최근 비식별 문의 12건 중 4건: 반품 배송비를 누가 내나요? KB-014 본문: 반품 접수 단계는 있으나 배송비 조건 없음 정책 원문: 귀책 사유별 조건이 별도 표에 있음
보강 후보: KB-014에 배송비 조건 표 연결 근거: 문의 4건 + 정책 원문 표 현재 문서 오류 여부: 확인되지 않음 우선순위: 높음 — 접수 전 의사결정에 필요한 정보 누락
수정 우선순위와 처리 상태를 분리합니다
왜 필요한가 — 차이 목록만 길게 만들면 위험한 오류와 사소한 표현 수정이 같은 줄에서 경쟁합니다.
영향도, 노출 범위, 근거 확실성, 사용 빈도, 수정 난도를 각각 낮음·중간·높음으로 매깁니다. 결제, 안전, 개인정보, 권한처럼 잘못 안내했을 때 피해가 큰 항목은 사용량이 적어도 먼저 담당자에게 알립니다.
처리 상태는 ‘즉시 비공개 검토’, ‘수정 초안’, ‘담당자 확인’, ‘유지’, ‘통합 후보’, ‘폐기 검토’로 둡니다. AI가 점수를 제안하더라도 최종 우선순위와 공개 상태는 문서 소유자가 확정합니다.
KB-014 차이: 지원 형식 1개 누락 영향: 업로드 실패 가능 노출: 고객지원 담당자 18명 근거: 공식 도움말 확인, 실제 계정 미확인 수정 난도: 낮음
우선순위: 중간 상태: 담당자 확인 이유: 공식 문서 차이는 명확하지만 계정별 적용 여부 미확인 다음 행동: 운영자가 시험 계정 확인 후 문장 수정 또는 예외 추가
변경 이력과 다음 검토일을 남깁니다
왜 필요한가 — 최종본만 덮어쓰면 왜 바뀌었는지, 다시 확인해야 할 시점이 언제인지 알 수 없습니다.
수정한 문장, 이전 값, 새 값, 근거 URL, 확인자, 공개일을 변경 기록에 남깁니다. 화면이나 정책이 실제로 달라진 경우에만 업데이트 날짜를 바꾸고, 확인 결과 내용이 그대로라면 검토일만 갱신합니다.
다음 검토일은 일괄적으로 같은 날짜를 넣지 않습니다. 정책 개정 예정일, 계약 갱신일, 제품 릴리스 주기처럼 실제 변경 신호에 맞춥니다. 담당자가 떠나거나 문서 링크가 끊기면 날짜를 기다리지 않고 점검 대기열로 다시 보냅니다.
문서 ID: KB-014 변경: 지원 형식에 TXT 추가 근거: 공급자 도움말 실제 계정 확인: 운영자 김OO, 2026-08-20 정책 개정 예정: 미정
v1.4 | PDF·DOCX → PDF·DOCX·TXT | 근거 URL 및 확인일 기록 | 확인자: 운영 담당자 | 공개: 2026-08-21 | 다음 검토: 2026-11-21 | 조기 점검 신호: 업로드 정책 변경 공지
수정해 쓰는 재사용 입력
중괄호 부분을 자신의 상황으로 바꾸고, 실제 자료를 넣기 전에 개인정보와 공개하면 안 되는 내용을 제거하세요. 결과는 반드시 원문과 대조합니다.
아래 [내부 문서]와 [공식 원문]만 비교해 최신성 점검표를 만드세요. 문장을 바로 고치지 말고 차이 후보를 먼저 추출하세요.
[규칙]
1. 동일 / 표현 차이 / 사실 차이 / 내부 문서에만 있음 / 공식 원문에만 있음 / 확인 불가 중 하나로 분류합니다.
2. 각 행에 내부 문장과 공식 원문 문장을 짧게 인용하고 위치 또는 URL을 붙입니다.
3. 요금제, 지역, 권한, 적용일이 명시되지 않으면 추정하지 않습니다.
4. 마지막 수정일이 오래됐다는 이유만으로 오류라고 판단하지 않습니다.
5. 수정 후보와 사람에게 물어볼 질문을 분리합니다.
[출력]
문서 ID | 비교 항목 | 차이 유형 | 내부 값 | 공식 값 | 근거 위치 | 영향 후보 | 확인 질문 | 권장 상태
[내부 문서]
{{문서 ID와 본문}}
[공식 원문]
{{URL, 확인일, 관련 문장}}결과 확인 체크리스트
- 모든 문서에 고유 ID와 담당자가 있다.
- 마지막 수정일과 내용 검토일을 구분했다.
- 문서 유형별 변경 신호와 확인 주기를 정했다.
- 공식 근거 URL과 확인일을 기록했다.
- 차이마다 내부 문장과 공식 원문 위치가 연결됐다.
- 표현 차이와 사실 차이를 구분했다.
- 요금제·지역·권한 조건을 확인했다.
- 검색어와 문의 표본에서 개인정보를 제거했다.
- 영향도와 근거 확실성을 따로 평가했다.
- 최종 판정과 공개는 담당자가 승인했다.
- 이전 값과 새 값이 변경 기록에 남았다.
- 실질적 변경 없이 업데이트 날짜만 바꾸지 않았다.
- 다음 검토일과 조기 점검 신호를 등록했다.
자주 막히는 지점과 해결법
공식 원문과 실제 절차의 차이가 확인될 때만 수정 대상으로 올리고, 그대로인 문서는 검토일만 기록합니다.
차이 후보, 적용 조건, 근거 URL을 한 표로 넘기고 문서 소유자가 실제 계정과 정책을 확인하게 합니다.
대표 문서를 지정하고 중복 문서는 통합 또는 안내 링크로 전환한 뒤 검색 결과도 확인합니다.
내용 변경일과 검토 완료일을 분리하고, 변경 기록에 실제로 달라진 문장을 남깁니다.
개인정보·저작권·정확성 주의
AI가 자연스럽게 작성했다는 사실은 정확성과 이용 권한을 보장하지 않습니다. 공개하거나 전달하기 전에 아래 항목을 확인하세요.
- 사내 문서에 고객정보, 계약 조건, 접근 키가 포함되어 있다면 승인되지 않은 AI 서비스에 입력하지 마세요.
- 법률·세무·의료·안전 문서의 최신성은 해당 분야 책임자가 원문과 적용 시점을 직접 확인해야 합니다.
- 공식 도움말도 요금제, 지역, 계정 권한에 따라 실제 화면과 다를 수 있습니다.
- 문서 폐기 전에는 기록 보존 의무와 기존 링크, 자동화가 참조하는 ID를 확인하세요.
- 사용량이 적다는 이유만으로 위험도가 높은 문서를 방치하지 마세요.
- AI의 비교 결과는 누락될 수 있으므로 핵심 숫자와 예외 조항은 사람이 문장 단위로 대조하세요.
자주 묻는 질문
오래된 문서는 모두 새로 써야 하나요?
아닙니다. 날짜보다 공식 근거와 실제 절차의 차이를 먼저 확인합니다. 내용이 맞다면 검토 기록과 다음 확인일만 갱신할 수 있습니다.
점검 주기는 얼마나 자주 잡아야 하나요?
일괄 주기보다 문서의 위험도와 변경 신호에 맞춥니다. 가격·권한·안전처럼 변할 때 영향이 큰 문서는 더 짧게, 안정적인 설명 문서는 개정 공지를 신호로 점검할 수 있습니다.
AI가 공식 링크를 찾아 주면 그대로 믿어도 되나요?
검색 후보로만 사용하세요. 담당자가 실제 도메인, 문서 날짜, 적용 대상과 원문 문장을 열어 확인해야 합니다.
중복 문서는 바로 삭제해도 되나요?
기존 링크와 참조 시스템을 먼저 확인합니다. 대표 문서로 연결하거나 보존 정책에 따라 처리한 뒤 검색과 자동화가 깨지지 않는지 검증해야 합니다.
공식 출처와 확인 기준
출처는 각 원자료가 다루는 범위 안에서 참고했습니다. 서비스 화면과 기능은 바뀔 수 있으므로 실제 사용 전 최신 문서를 다시 확인하세요.
수정 이력
2026-08-15 — 작성 및 편집 검수.
이어서 볼 가이드
03. AI 직원 7명에게 바로 일을 시키는 프롬프트
3줄 요약 AI에게 역할 이름만 주지 말고 입력·업무·출력·규칙을 함께 정합니다. 대표실, 마케팅, 영업, 고객지원, 재무, 개발, 운영의 책임과 결과물을 서로 다르게 설정합니다. 대괄호 안의 상품·고객·자료만 바꾸면 반복해서 사용할 수 있는 AI 직원 7명의 업무 프롬프트를 만들 수 있습니다. 완성 결과물 대표실부터 운영팀까지 AI 직원 7명의 역할과 결과물을 고정하고, 필요한 업무가 생길 때 해당 프롬프트를 복사해 […]
2편. AI에게 이름 말고 결과물을 주세요: 7개 부서 역할표 만드는 법
3줄 요약 완성 결과물 부서별 입력, 결과물, 완료 조건, 하지 않을 일이 한 줄씩 적힌 7행짜리 역할표를 만들고, 이번 달에 실제로 가동할 부서만 골라 첫 업무를 배정할 수 있습니다. 누구에게 필요한가 이 경우에는 먼저 멈추세요 시작 전 준비 부서를 만들기 전에 각 부서가 무엇을 받고 무엇을 내놓을지 정해두면, 결과물이 다음 부서로 넘어갈 때 다시 설명하지 […]