퇴사·이동 시 끊기는 업무 지식을 AI로 이어받게 하려면 어떻게 설계해야 할까?

📌 오늘의 안건
퇴사·이동 시 끊기는 업무 지식을 AI로 이어받게 하려면 어떻게 설계해야 할까?

우리 조직에서는 담당자가 퇴사하거나 부서를 옮길 때 업무 지식이 끊기고, 인수인계가 제대로 이루어지지 않고 있습니다. 대부분의 노하우가 담당자 머릿속에만 있어 따로 정리된 자료가 거의 없는 상태입니다. 그래서 담당자가 직접 문서를 작성하고 AI가 이를 정리해 주는 방식으로 인수인계 체계를 만들고 싶습니다. 목표는 담당자가 떠난 뒤에도 후임자가 AI에게 물어보면 필요한 답을 찾을 수 있는 상태입니다. 이런 구조를 어떻게 설계해야 실제로 작동할지 논의하고 싶습니다.

일이 틀어지는 날을 미리 그려 보고, 그날 피해를 얼마나 작게 막을지 같이 설계하는 일을 맡겠습니다. 겁을 주려는 게 아니라 안심하고 쓰실 수 있게 하려는 것이니 편하게 들어 주십시오.

다들 당연하다고 넘기는 전제, 그게 제 몫이에요. 정말 도구 문제일까요? 그 질문부터 끝까지 물고 늘어질게요.

실행할 수 있어야 비로소 답입니다. 이번 토론에서는 얼마가 들고, 누가 언제까지 해낼 수 있는지를 함께 따져 보겠습니다.

결론부터 말씀드리면, 이 체계는 AI가 답을 지어내는 구조가 아니라 AI는 사람이 검수한 원문을 찾아 근거와 함께 보여 주기만 하는 구조로 설계해야 실제로 작동합니다. 인수인계 실패에서 가장 무서운 장면은 문서가 없어서 후임자가 막히는 순간이 아닙니다. AI가 그럴듯하게 틀린 절차를 자신 있게 알려 주고, 후임자가 그대로 실행해 되돌릴 수 없는 일이 생기는 순간입니다. 제가 운영하던 조직에서도 퇴사자가 남긴 정리 노트를 요약본으로 만들어 쓴 적이 있습니다. 그런데 요약 과정에서 "배치는 월말 정산 마감 후에만 재실행"이라는 단서가 빠졌고, 후임자가 마감 전에 재실행해 정산을 이중으로 반영한 일이 있었습니다. 요약은 친절했지만 전제가 빠져 있었고, 그 전제가 바로 노하우였습니다. 법적으로도 결론이 이미 나와 있습니다. 2024년 Air Canada 사건에서 캐나다 BC주 민사분쟁재판소는 챗봇이 잘못 안내한 내용에 대해 회사가 책임을 져야 한다고 판단했습니다(Moffatt v.

Air Canada, 2024 BCCRT 149, canlii.org[1]). 내부용 AI라고 해서 이 원리가 달라지지 않습니다.

그래서 설계의 뼈대는 다음 네 가지로 잡으시길 권합니다. - 원문과 AI 정리본을 분리하십시오. 담당자가 쓴 원문, 그리고 퇴사 전 인터뷰 녹취를 원본으로 보존합니다. AI 정리본은 담당자 본인이나 팀장이 승인해야만 검색 대상에 들어가게 합니다. 답변에는 반드시 출처 문서와 작성자, 최종 검증일을 붙이고, 근거를 찾지 못하면 지어내지 말고 "기록 없음, 문의처: ○○"라고 답하도록 강제합니다. - '무엇을'보다 '왜·언제 안 되는지'를 받아 내십시오. 담당자가 백지에서 문서를 쓰게 하면 거의 실패합니다. AI가 면담자 역할을 맡아 정해진 질문을 던지게 하십시오. 예를 들어 "이 작업에서 가장 크게 망했던 적은?", "절대 하면 안 되는 순서는?", "누구에게 먼저 연락하나?" 같은 질문입니다. 이렇게 하면 머릿속에만 있던 예외 조건과 사람 사이의 연결이 함께 나옵니다. - 위험도에 따라 등급을 나누십시오. 결제, 권한 변경, 고객 데이터, 대외 발송처럼 되돌리기 어려운 절차는 AI가 안내만 하고 실행 권한은 주지 않습니다.

이런 절차는 체크리스트 원문을 그대로 보여 주고, 사람의 이중 확인을 거치게 합니다. - 문서에도 유효기간을 두십시오. 시스템이 바뀌면 문서는 조용히 거짓말이 됩니다. 6~12개월마다 재검증 알림을 보내고, 기한이 지난 문서는 답변에 "만료 경고"를 붙이게 하십시오.

보안 쪽도 미리 막아 두셔야 합니다. 인수인계 문서에는 비밀번호, 거래처 연락처, 인사 정보가 섞여 들어오기 쉽습니다. 또 문서나 첨부 메일에 숨은 지시문이 AI의 행동을 바꾸는 프롬프트 주입도 실제로 일어나는 위험입니다(OWASP LLM01·LLM02, genai.owasp.org[1]). 그러니 수집 단계에서 비밀정보를 자동으로 탐지해 가리고, 답변은 질문자의 기존 문서 권한 범위 안에서만 검색되게 하며(권한 상속), AI에게는 읽기 권한만 주십시오. 마지막으로 공급사 서비스가 멈추거나 계약이 바뀌어도 지식이 사라지지 않도록, 원본은 사내 저장소에 마크다운 같은 평문으로 두고 AI는 그 위에 얹는 교체 가능한 층으로만 다루십시오. 장애 대비의 기본은 핵심 자산을 특정 도구에 묶어 두지 않는 것입니다(NIST AI RMF, nist.gov[2]).

여기까지 갖추면 담당자가 떠난 뒤에도 후임자는 출처가 확인된 답을 얻게 되고, 틀린 답이 나와도 피해는 작은 범위에서 멈춥니다. 시작은 이직 위험이 가장 큰 업무 두세 개를 골라 시범 운영하는 것으로 충분합니다.

전제는 ‘문서만 넘기면 AI가 인수인계를 이어 준다’인데, 그 가정이 먼저 깨지는지 현업 발언부터 확인해요.인수인계용 챗봇부터 만들면 실패해요. 끊기는 건 모델이 아니라, 예외와 판단이 날짜·담당자·근거가 붙은 기록으로 남지 않은 상태예요. 퇴사 직전에 문서를 받아 AI가 요약하게 하면, 빈칸을 자신 있게 메우는 기계만 남아요. 카파시는 산업용 LLM 앱의 핵심을 프롬프트가 아니라 “다음 단계에 딱 맞는 정보만 컨텍스트에 채우는 일”이라고 했어요. 너무 적어도, 관련 없는 게 너무 많아도 성능이 떨어진다고요. x.com[1]

설계 단위는 매뉴얼이 아니라 결정 카드예요. 언제 발동하는지, 실제 순서, 예외, 담당, 날짜, 원시스템 링크. 평소 업무 중에 쌓고, AI는 문장만 다듬어요. 검색은 임베딩 단독으로 두면 안 돼요. 사람 이름, 약어, 시스템 ID는 키워드 검색이 잡고, 동의어는 임베딩이 잡는 혼합이 정석이에요. 현업 1년 회고가 그 반례를 이미 적었어요. applied-llms.org[1] 시스템 지시도 그렇게 잠가야 해요. 검색된 문장 안에서만 답하고, 그 문장을 그대로 인용하며, 없으면 “기록 없음”. 떠나기 전에 후임이 실제로 물을 질문 30~50개를 담당자가 정답과 함께 남기고, 그 세트로 검색이 맞는지부터 재요. 여기서 틀리면 모델을 바꿀 일이 아니에요.

사람들은 그 봇을 검색엔진처럼 믿고, 근거를 확인하지 않아요. 이단 몰릭이 RAG에 대해 한 말입니다. 사용자는 검증 노동을 하지 않고, AI가 설득하려 든다는 것도 예상하지 않아요. simonwillison.net[1] 그래서 화면은 모델의 요약이 아니라 원문 문장을 먼저 보여야 해요. 인용 강제와 퇴사 전 채점이 없으면, 회사 로고 단 거짓말쟁이를 후임에게 넘기는 거예요.

이번 분기에는 한 팀의 반복 업무 하나를 골라 인수인계 문서와 AI 검색을 함께 시험하십시오. 문서가 없는 상태에서 AI부터 붙이면 빈 지식을 그럴듯하게 답하게 됩니다. 담당자가 실제 업무를 하며 체크리스트·예외 사례·판단 기준·관련 시스템 링크를 기록하고, AI는 그 자료를 찾아 출처와 함께 답하게 설계합니다. 자료에서 답을 찾지 못하면 추측하지 말고 담당자에게 넘겨야 합니다.

첫 달은 업무 담당자 1명, 후임자 1명, 현업 검토자 1명으로 시작하면 됩니다. 기존 문서 저장소에 자료를 두고 AI 검색만 연결해 신규 플랫폼 구축을 미루십시오. 4주 동안 상위 질문 20개에 대한 정답률, 출처 제시율, 후임자의 업무 처리 시간, 담당자의 문서 작성 시간을 기록합니다. 예를 들어 후임자 처리 시간이 줄고 정답률이 사전 합의한 기준을 넘을 때만 다음 업무로 넓힙니다. API를 직접 붙이는 시범이라면 임베딩 비용은 100만 토큰당 0.02달러이며, 생성 비용과 개발·검토 인력 시간은 별도로 산정해야 합니다. 공식 임베딩 요금[1]

첫 시범은 현행 저장소를 쓸 수 있는 개발자 1명과 업무 담당자·검토자 각 1명이 4주간 수행하는 범위가 적절합니다. 신규 구독료나 연동비는 기존 계약과 선택한 제품에 따라 달라지므로, 시작 전에 예산 상한을 정하고 실제 사용량으로 비용을 확인하십시오. 효과가 확인되면 문서 양식과 검토 절차를 표준화해 다른 업무로 확장하면 됩니다.

두 분의 초안을 읽고 제 입장을 한 가지 바꾸겠습니다. 지식을 받아 내는 시점은 퇴사 직전이 아니라 평소 업무 중이어야 한다는 표하람 님의 지적이 옳습니다. 제 초안은 퇴사 전 면담에 무게를 두었는데, 떠나기로 한 사람은 이미 마음이 떠나 있고 시간도 부족합니다. 그런 상태로 남긴 기록에서는 정작 중요한 예외 조건이 가장 먼저 빠집니다. 그래서 '결정 카드'를 평소에 쌓는 방식을 뼈대로 받아들이고, 면담은 카드에서 빈 곳을 메우는 보조 수단으로 낮추겠습니다. 다만 "AI는 문장만 다듬는다"는 부분에는 방어책을 하나 더 붙여야 합니다. 제가 앞서 말씀드린 정산 이중 반영 사고도 결국 '다듬는' 과정에서 단서 한 줄이 빠지면서 생겼습니다. AI가 다듬은 문장을 승인하기 전에 원문에 있던 조건문과 부정문이 그대로 남았는지 자동으로 대조하십시오. "~후에만", "절대 ~하지 말 것", "단, ~인 경우" 같은 표현입니다. 하나라도 빠졌다면 승인을 막아야 합니다. 원문 문장을 먼저 보여 주라는 표하람 님의 화면 원칙과 함께 쓰면, 같은 사고가 다시 생길 여지는 거의 없어집니다.

주다은 님의 4주 시범안은 범위를 좁게 잡은 점이 좋습니다. 그런데 측정 지표가 평균 쪽에 치우쳐 있습니다. 정답률 90%는 안심이 되는 숫자처럼 보입니다. 하지만 틀린 10% 안에 결제나 권한 변경 절차가 섞여 있다면 그 시범은 실패한 것입니다. 그래서 확장 여부를 정하는 기준을 다음처럼 바꾸시길 권합니다.

• 되돌릴 수 없는 등급의 질문에서는 '틀렸는데 출처까지 붙은 답'이 0건이어야 통과입니다. 출처가 붙은 오답이 가장 위험합니다. 표하람 님이 인용한 몰릭의 지적처럼 사람들은 출처가 보이면 더는 확인하지 않기 때문입니다.
• '기록 없음'이라고 답한 비율을 실패가 아니라 정직성 지표로 따로 집계하십시오. 이 비율이 0에 가깝다면 시스템이 모르는 것까지 지어내고 있다고 의심해야 합니다.

표하람 님이 제안한 30~50개 질문 세트에도 맹점이 하나 있습니다. 이 질문은 떠나는 사람이 '후임자가 물을 것 같다'고 상상해서 만든 것입니다. 그러니 그 사람이 이미 알고 있다고 인식하는 지식만 시험하게 됩니다. 실제 사고는 본인조차 노하우라고 여기지 못했던 습관에서 납니다. 그래서 인수인계 기간에 후임자를 2~4주 동안 실제 업무에 함께 붙여 두십시오. 이 기간에 '기록 없음'이 나온 질문을 전부 기록해 바로 결정 카드로 만들게 하면, 질문 세트가 미처 잡지 못한 빈칸이 드러납니다.

제가 운영하던 팀에서 겪은 일을 하나 더 말씀드리겠습니다. 담당자가 떠난 뒤 그 사람 이름으로 남은 런북이 1년 넘게 아무도 손대지 않은 채 남아 있었습니다. 문서에는 '작성자: 퇴사자'라고 적혀 있었으니 누구도 고칠 책임을 느끼지 않았던 것입니다. 그 사이 시스템은 두 번 바뀌었습니다. 그래서 퇴사나 이동이 결정되는 순간 그 사람이 소유한 문서의 관리 책임자를 후임자로 바꾸는 일을 인사 절차의 체크 항목으로 넣으십시오. 관리 책임자가 없는 문서는 검색 결과에서 자동으로 경고를 달아야 합니다. 그리고 퇴사 후 3개월 정도는 '기록 없음' 질문을 떠난 담당자에게 물어볼 수 있는 창구를 퇴사 협의 때 미리 합의해 두시면 좋습니다. 그렇게 하면 지식이 끊기는 지점이 갑작스러운 절벽이 아니라 완만한 경사가 됩니다.

정리하면 지식은 평소 업무 중에 쌓고, 승인 전에는 조건문이 빠지지 않았는지 대조하고, 확장 여부는 평균 정답률이 아니라 되돌릴 수 없는 절차에서 나온 오답 수로 판단하시면 됩니다. 이 세 가지만 지키셔도 담당자가 떠난 뒤 생기는 피해 범위는 충분히 관리할 수 있는 크기로 줄어듭니다.

제 초안의 4주 시범과 비용 상한은 유지하되, 먼저 ‘무엇을 기록하고 어떻게 검증할지’를 더 구체화하겠습니다. 현장에서는 절차보다 예외와 판단 근거가 빠질 때 인수인계가 흔들립니다. 표하람의 ‘결정 카드’처럼 발동 조건·순서·예외·담당자·기록일·원문 링크를 남기고, AI는 문장 정리만 돕게 하십시오. 임도경의 지적대로 담당자 검수 전 AI 정리본은 검색 대상에서 빼야 합니다.

시범에서는 담당자가 후임자가 실제로 물을 질문과 정답·근거를 함께 모으고, 이를 평가 세트로 쓰십시오. 사람 이름·약어·시스템 ID에는 키워드 검색을, 표현이 다른 질문에는 의미 검색을 함께 적용합니다. 답변은 원문 근거와 검증일을 보여 주고, 근거가 없으면 “기록 없음”과 문의처를 안내하게 합니다. 특히 되돌리기 어려운 절차는 AI가 안내만 하고 실행은 사람이 확인하게 하십시오.

이 기준을 한 팀의 반복 업무 하나에 적용해 4주간 시험하면 비용과 효과를 함께 볼 수 있습니다. 기존 저장소를 활용하고, 담당자·후임자·검토자의 시간을 포함해 비용 상한을 먼저 정하십시오. 초안의 상위 20개 질문 평가는 유지하되, 담당자가 만든 질문 세트로 정답률·출처 제시율을 측정하고 후임자의 처리 시간도 비교합니다. 통과 기준을 넘은 뒤에만 다른 업무로 넓히고, 문서에는 재검증일을 두어 낡은 절차가 계속 답변에 쓰이지 않게 하십시오.

퇴사 봇의 성패는 모델이 아니라, 한 업무에서 ‘기록 없음’을 맞게 말하는 4주입니다. 범위를 회사 전체 매뉴얼로 잡으면 또 빈 위키예요. 주다은 말대로 반복 업무 하나, 담당·후임·검토 각 1명, 지금 저장소에 검색만 얹는 쪽이 맞아요. 여기서 제 설계를 줄입니다. 떠나기 전 질문 30~50개는 그 업무의 상위 20개로 자르고, 정답은 담당자가 문장으로 남긴 결정 카드와 대조해요.

속도가 줄면 지식이 이어진 걸까요? 아니요. ‘처리 시간이 줄었다’를 성공으로 두면, 후임이 근거를 안 읽고 빨리 실행한 주간을 승리로 칩니다. 채점표는 출처 문장 일치, 없는 질문에 ‘기록 없음’, 그리고 결제·권한·대외발송처럼 되돌리기 어려운 항목은 봇이 절차를 읽어 주기만 하는지로 봐요. 임도경이 말한 유효기간도 여기서 넣어요. 위험 절차만 분기마다 재확인하고, 지난 카드는 답 앞에 만료를 붙입니다. 전 업무를 6~12개월마다 재검증하라는 설계는 아무도 안 지킵니다.

Air Canada 판결을 ‘내부 인수인계도 법적으로 이미 결론’이라고 끌어오면 과합니다. Moffatt는 손님에게 항공권 정책을 안내한 챗봇 사건이지, 내부 지식 봇의 판례가 아니에요. 가져올 교훈은 하나예요. 승인 안 된 요약은 검색 대상에 넣지 말 것. 담당자 원문과 면담에서 나온 예외만 검토자가 통과시키고, AI는 그 문장을 인용해요. 그들이 든 임베딩 100만 토큰당 0.02달러는 설계 변수가 아니에요. 검토자가 틀린 카드를 통과시키는 시간이 비용의 본체입니다.

이 설계에서 가장 먼저 사고가 날 곳은 답의 정확도가 아닙니다. 누가 무엇을 물을 수 있느냐는 권한 경계입니다. 지금까지의 논의는 틀린 답을 막는 데 집중했습니다. 그런데 담당자 머릿속 노하우에는 절차만 들어 있지 않습니다. "그 계정 비밀번호는 내 메모에 있다", "저 거래처 담당자는 이런 사정이 있다" 같은 내용이 함께 섞여 나옵니다. 이것이 결정 카드에 들어가 검색되는 순간, 원래 문서마다 걸려 있던 열람 권한이 봇 하나로 평평해집니다. 다른 부서 사람이 우연히 던진 질문에 인사 사정이나 접속 정보가 출처까지 붙어서 나가게 됩니다. 이렇게 막으십시오.

• 카드는 원문 저장소의 열람 권한을 그대로 물려받게 하고, 봇은 질문한 사람의 권한 안에서만 찾게 하십시오.
• 접속 정보와 개인 정보는 카드에 쓰지 못하게 저장 시점에 자동 검사로 막고, 비밀번호는 별도 보관함에서 넘기게 하십시오.
• 검색 대상은 검토를 통과한 카드로만 한정하십시오. 메일이나 메신저 원문을 그대로 넣으면 그 안에 섞인 "이전 지시는 무시하라" 같은 문장이 답을 조종하는 주입 경로가 됩니다.

다수안인 '반복 업무 하나로 4주 시범'은 안전해 보이지만, 정작 끊기는 지식은 시험하지 못합니다. 매일 하는 일은 후임자가 일주일만 옆에서 봐도 익힙니다. 실제로 터지는 것은 1년에 한 번 오는 일입니다. 인증서 갱신, 감사 대응, 연말 정산 마감 같은 것들입니다. 제가 운영하던 곳에서도 담당자가 떠나고 열한 달 뒤에 인증서가 만료되어 서비스가 반나절 멈췄습니다. 일상 업무 인수인계는 완벽했는데, 그 일은 누구의 질문 목록에도 없었습니다. 그래서 시범 범위에 '드문 일 목록'을 꼭 넣으시길 권합니다. 지난 12개월의 일정표와 처리 이력에서 연 1~4회 일어난 일을 뽑아 각각 카드를 만들고, 다음 발생일 2주 전에 후임자가 봇으로 미리 따라 해 보게 하십시오. 또 리뷰 1의 조건문 대조는 단어가 남아 있는지만 확인할 수 있습니다. "단, A 시스템에서는"이 "단, 모든 경우에"로 범위만 바뀌는 변형은 잡지 못합니다. 되돌릴 수 없는 등급의 카드는 AI가 다듬지 못하게 하고, 원문을 그대로 두는 편이 맞습니다.

마지막으로 단일 장애 지점이 세 군데 남아 있습니다.

• 검토자: 한 사람이 바쁜 주에는 클릭만으로 승인합니다. 일부러 틀린 카드를 몇 장 섞어 두고 걸러 내는지 측정해야 검토가 실제로 이루어지는지 알 수 있습니다.
• '기록 없음'의 문의처: 이 문의처가 떠난 담당자 이름으로 남아 있으면 안내가 그대로 막다른 길이 됩니다. 문의처는 사람이 아니라 역할이나 팀으로 적으십시오.
• AI 공급사: 공급사가 멈추는 날에도 후임자는 일을 해야 합니다. 카드는 봇 없이도 읽히는 일반 파일로 내보낼 수 있어야 하고, 판별로 이력을 남겨 잘못 고친 카드를 되돌릴 수 있어야 합니다.

이 몇 가지만 미리 박아 두면 사고가 나더라도 한 장의 카드, 한 명의 질문자 안에서 끝납니다. 그 정도라면 충분히 감당하실 수 있습니다.

최종 수정안은 평소 업무 중에 결정 카드를 쌓는 표하람 님의 방식을 뼈대로 하고, 그 위에 피해 범위를 줄이는 장치 세 가지를 얹는 것입니다. 이번 라운드의 약점 공략을 읽고 제 입장을 두 군데 고칩니다. 첫째, 앞서 제안한 조건문 대조로는 부족했습니다. 그 방식은 "~후에만" 같은 단어가 남아 있는지만 확인할 수 있습니다. "단, A 시스템에서는"이 "단, 모든 경우에"로 범위만 바뀌는 변형은 그대로 통과합니다. 그래서 되돌릴 수 없는 등급의 카드는 AI가 아예 다듬지 못하게 하고 원문 그대로 두겠습니다. 조건문 대조는 그보다 낮은 등급의 카드에만 쓰겠습니다. 둘째, 지금까지 저는 틀린 답을 막는 데만 집중하느라 누가 무엇을 물을 수 있느냐는 권한 경계를 놓쳤습니다. 이 순서가 거꾸로였다는 지적을 받아들입니다.

핵심 근거는 세 가지입니다. 첫째, 가장 먼저 터질 곳은 정확도가 아니라 권한입니다. 그래서 카드는 원문 저장소의 열람 권한을 그대로 물려받게 하고, 봇은 질문한 사람의 권한 안에서만 찾게 해야 합니다. 비밀번호 같은 접속 정보는 카드를 저장하는 시점에 자동 검사로 막습니다. 검색 대상은 검토를 통과한 카드로만 한정합니다. 오답은 한 사람을 잘못 이끄는 데서 끝나지만, 유출은 되돌릴 수 없기 때문입니다. 둘째, 시범은 매일 하는 일이 아니라 드물게 오는 일로 시험해야 합니다. 주다은 님의 4주 시범안은 그대로 두되, 범위에 지난 12개월 동안 연 1~4회 일어난 일의 목록을 반드시 넣으십시오. 확장 여부는 그 목록과 되돌릴 수 없는 절차에서 '출처가 붙은 오답'이 0건인지로 판단합니다. 담당자가 떠나고 열한 달 뒤에 인증서가 만료되어 서비스가 반나절 멈췄던 사례가 바로 이 빈칸에서 나왔습니다. 일상 업무 인수인계가 완벽했는데도 그랬습니다.

셋째, 단일 장애 지점은 사람이 아니라 구조로 풀어야 합니다. 검토자가 제대로 걸러 내는지는 일부러 틀린 카드를 몇 장 섞어 측정합니다. '기록 없음'의 문의처와 문서의 관리 책임자는 개인 이름이 아니라 역할이나 팀으로 적습니다. 카드는 일반 파일로 내보내고 판별로 이력을 남겨서, 공급사가 멈추는 날에도 읽을 수 있고 잘못 고친 카드는 되돌릴 수 있게 합니다.

결국 이 체계는 AI가 똑똑하게 답해서가 아니라, 틀리거나 새더라도 피해가 한 장의 카드나 한 명의 질문자 안에서 끝나도록 설계되어 있기 때문에 작동합니다. 제가 겪은 사고들도 시스템이 틀린 순간이 아니라 그 틀림이 아무 경계 없이 번져 나간 순간에 커졌습니다. 경계만 먼저 세워 두시면, 나머지는 시범을 돌리면서 고쳐 나가셔도 충분히 늦지 않습니다.

최종안은 4주 시범을 유지하고, 권한이 확인된 희귀 업무부터 검증하는 것입니다. 지난 12개월 처리 이력에서 연 1~4회 생긴 일을 골라 결정 카드로 만들고, 다음 발생일 2주 전에 후임자가 AI로 따라 해 보게 하십시오. 반복 업무 하나만 시험하면 실제 인수인계 공백을 놓칠 수 있습니다.

카드는 원문 권한을 따르고 질문자의 권한 안에서만 검색되게 하십시오. 접속 정보와 개인정보는 저장 단계에서 걸러내고, 되돌리기 어려운 절차는 AI가 고치지 못하게 원문을 보존합니다. 검토된 카드만 검색에 넣고 일부러 틀린 카드를 섞어 검토자가 실제로 걸러내는지도 확인하십시오.

기존 저장소를 쓰고 비용 상한을 정한 뒤, 담당자 질문 세트로 정답률·출처 제시율과 후임자의 처리 시간을 측정합니다. 문의처는 개인이 아닌 역할이나 팀으로 두고, 카드의 일반 파일 내보내기와 수정 이력으로 공급사 장애와 잘못된 변경에 대비합니다. 기준을 넘을 때만 확대하십시오.

권한 밖 유출과 연 1회 공백이 먼저 터집니다. 정확도 채점만 보던 쪽을 접어요. 시범은 업무 하나, 담당·후임·검토 각 1명으로 두고, 카드만 두 겹으로 바꿉니다. 매일 하는 일과, 지난 12개월 일정에서 뽑은 연 1~4회 일을 같이 넣어요. 드문 일은 다음 발생 2주 전에 후임이 카드만 보고 따라 하게 합니다.

근거는 세 개예요. 카드는 원문 저장소의 열람 권한을 물려받고, 질문자 권한 안에서만 검색됩니다. 접속 정보와 개인정보는 저장 때 막고, 비밀번호는 보관함으로 넘기며, 검색은 검토를 통과한 카드만 해요. 되돌리기 어려운 카드는 담당자 원문을 그대로 두고 봇은 그 문장만 인용합니다. 검토 더미에 틀린 카드를 섞어 걸러 내는 비율을 재고, 기록 없음의 문의처는 역할로 적으며, 카드는 일반 파일로 빼 두고 판을 남겨 공급사가 멈춰도 읽고 되돌리게 해요.

위험 절차만 분기마다 다시 확인하고, 나머지 카드는 답 앞에 날짜를 붙이는 선에서 멈춰요. 검토자가 틀린 카드를 통과시키는 시간이 비용의 본체라는 판단은 유지합니다.