휴가·경비·와이파이 질문에 하루를 쓰는 경영지원팀

120명 회사의 경영지원 담당자가 베타 챗봇을 만들었다

휴가 신청 위치, 개인 카드로 쓴 경비 처리, 사무실 와이파이 접속 방법은 질문하는 직원에게는 당장 필요한 정보다. 경영지원 담당자에게는 이미 여러 번 답한 질문이다. 답을 알고 있어도 규정을 찾아 링크를 보내고, 직원의 상황을 다시 듣고, 다른 담당자에게 전달하는 일이 이어진다. 반복 문의를 줄이려면 직원이 실제로 쓰는 메신저에서 답을 찾을 수 있어야 한다.

지피터스에 제작 과정을 올린 찬영은 임직원 120명 회사의 비개발자 경영지원 담당자다. 통신비·경조금·휴가·와이파이·복합기 같은 질문에 대응하려고 Google Chat에 규정을 묻는 베타 챗봇을 만들어 테스트하고 있다고 밝혔다. 120명은 회사 인원이며, 실제 챗봇 이용자 수를 뜻하지 않는다. 사례의 중심은 완성된 인력 절감 실적보다 직원들이 써보면서 발견한 오류와 개선 과정에 있다. 지피터스 제작 사례

도입을 준비하는 경영지원팀은 여기서 첫 범위를 좁힐 수 있다. 휴가 일수를 계산하거나 비용 지급을 결정하는 기능보다, 신청 화면과 필요한 서류를 찾는 기능부터 붙이는 방식이다. 안내가 틀렸을 때 어떤 문서를 고쳐야 하는지 분명하고, 직원이 최종 신청 내용을 직접 확인할 수 있는 업무부터 시작한다.

챗봇이 있다는 이유로 직원에게 질문을 금지하면 잘못된 안내를 발견하기 어렵다. 베타에서는 답을 받은 뒤 실제 신청을 마쳤는지, 같은 문제로 담당자에게 다시 연락했는지가 중요하다. 대화가 끝났다는 표시와 직원의 일이 끝났다는 상태를 구분해야 한다.

반복 질문을 모으면 문서가 빠진 곳부터 보인다

사내 규정 검색을 도입할 때 먼저 할 일은 최근 문의를 업무별로 묶는 것이다. 팀이 기억하는 자주 묻는 질문과 직원들이 실제로 보내는 질문은 다를 수 있다. 신청 경로를 모르는 질문, 규정의 대상을 묻는 질문, 자기 상황에서 예외가 되는지 묻는 질문을 구분하면 챗봇에 맡길 범위가 드러난다.

아래는 경영지원팀이 도입할 때 사용할 수 있는 준비표다. 회사 규정과 승인된 업무 절차를 채우는 양식이며, 특정 회사의 이미 검증된 챗봇 기능 목록은 아니다. 같은 휴가 질문이라도 신청 화면 안내와 개인별 승인 판단은 다른 업무로 두어야 한다.

문서마다 소유자와 시행일, 적용 대상, 신청 위치가 있어야 한다. 인사팀이 쓰는 규정 파일과 총무팀이 메신저에 고정한 안내가 다르면 챗봇도 무엇을 우선할지 정하기 어렵다. 두 파일을 모두 넣기 전에 현재 효력이 있는 문서를 정하고 오래된 안내를 수정해야 한다.

첨부 파일에 규정만 있고 실제 제출 화면이 없으면 직원은 다시 질문하게 된다. 설명 문서에 신청 링크, 서류 양식, 담당 부서를 붙여서 답변 이후의 행동까지 이어지게 한다. 링크가 이동했을 때 어느 담당자가 바꾸는지도 문서에 남겨야 한다.

이 지식을 업무 화면 가까이에 두는 경험도 있다. 다른 지피터스 사용자는 매장 운영 시스템 안에 WIKI를 붙여 화면별 역할과 업데이트 이력을 남겼다고 밝혔다. 별도 문서와 실제 기능이 떨어져 있으면 인수인계 때 설명을 반복해야 한다는 문제에서 출발했다. 사내 챗봇 역시 직원이 답을 읽는 위치에서 절차와 근거를 함께 볼 수 있게 만드는 편이 낫다. 앱 내부 WIKI 사례

직원이 쓰는 말은 규정의 제목과 다르다

찬영은 개인 카드를 뜻하는 실무 표현을 경비 청구와 연결했다. 그러나 직원이 실제로 쓰기 시작하자 두 질문 중 하나만 답하고, 출처가 문서 대신 폴더로 열리며, 캐시가 옛 오답을 반복하는 문제가 나타났다고 밝혔다. 처음 그럴듯한 답을 만들었던 상태와 실제 문의를 처리하는 상태는 달랐다.

직원은 문서 제목을 외워서 질문하지 않는다. 개인 카드, 법인 카드, 청구, 결의처럼 서로 연결된 표현을 사용하고, 한 문장에 신청 방법과 제출 기한을 함께 묻기도 한다. 규정 검색을 설계할 때는 공식 용어를 정확히 쓰는 질문만 시험해서는 안 된다.

이때 질문과 문서를 바로 이어 붙이기보다, 무엇을 묻는지 확인하는 짧은 단계를 둔다. 경비 처리로 이해했다는 문장 뒤에 해당 절차를 제시하고, 질문에 두 업무가 있으면 항목을 나눠 답한다. 직원이 다른 뜻이었다고 바로 고칠 수 있어야 한다.

도입팀이 만들 용어표에는 직원 표현, 공식 개념, 연결 문서, 혼동하기 쉬운 다른 업무를 함께 적는다. 약어 하나를 규정 하나에 무조건 연결하면 같은 단어를 다른 의미로 쓴 질문이 잘못 분류된다. 단어가 같아도 주변 문장에서 어떤 행동을 하려는지 확인해야 한다.

특히 휴가와 시설 예약, 복지 지원처럼 같은 메신저에서 다루는 업무가 많을수록 잘못된 분류를 발견할 질문이 필요하다. 한 단어만 넣는 시험에 더해, 두 개의 문의를 함께 넣고 어느 부분이 답변에서 빠지는지 읽는다. 처리하지 못한 두 번째 질문을 답한 것처럼 끝내지 않고 남은 항목을 표시한다.

Google Chat 공식 문서는 직접 메시지 등 기존 대화 화면에서 앱과 상호작용하는 방식을 제공한다. 직원이 매번 새 사이트에 로그인해서 검색하게 하기보다 기존 메신저에 접점을 둘 수 있다. 다만 대화 화면을 붙였다고 문서 검색과 답변 검증까지 완성되는 것은 아니다. Google Chat 상호작용 문서

출처 링크는 직원이 실제 규정을 열 수 있어야 한다

사내 챗봇의 답변은 확인할 규정과 연결돼야 한다. 신청 방법을 안내하면서 어느 문서의 어떤 항목을 근거로 삼았는지, 그 문서가 언제부터 적용되는지 함께 보여준다. 내용이 맞아도 직원이 휴대전화에서 파일을 열지 못하면 담당자에게 다시 질문해야 한다.

도입 설계에서는 문서 이름, 관련 항목, 시행일, 직접 링크를 답변의 기본 필드로 둔다. 검색 결과가 없을 때는 안내문을 완성하려고 규정을 덧붙이지 않는다. 근거가 없는 부분을 표시하고 담당 부서가 확인할 질문으로 남기는 편이 신청 오류를 줄이는 데 유용하다.

Google의 답변 API에는 출처와 인용을 연결하는 구조가 있으며, 근거 확인 기능은 생성한 주장과 제공한 사실의 연결을 점검한다. 이 기능을 활용하더라도 도입팀은 실제 답변이 인용한 규정의 대상을 확인해야 한다. 다른 고용 형태에 적용되는 문서를 붙이면 링크 자체는 유효해도 질문의 답은 틀릴 수 있다. 답변 API 출처 구조, 근거 연결 점검

규정을 바꿀 때는 검색 자료와 저장된 답변을 함께 갱신하는 절차를 둬야 한다. 담당자가 문서만 고친 뒤 챗봇이 옛 답을 계속 내보내면 직원은 두 가지 안내를 받는다. 문서의 새 버전이 검색에 반영됐는지 확인하고, 관련 질문으로 최신 신청 경로가 나오는지 시험한다.

답변을 저장해 재사용하는 기능도 규정 버전과 연결한다. 규정이 바뀌었다는 이유로 회사의 모든 답변을 매번 다시 생성할 필요는 없지만, 변경된 문서를 근거로 만든 답은 다시 확인해야 한다. 문서 소유자가 변경 내용을 전달할 창구가 있어야 이 작업을 유지할 수 있다.

챗봇 접근권한과 문서 접근권한은 따로 확인한다

직원이 챗봇에 질문할 수 있다는 사실은 모든 사내 자료를 읽을 수 있다는 뜻이 아니다. 전체 직원이 읽는 신청 안내와 특정 담당자만 읽는 개인별 정보는 검색 단계부터 분리해야 한다. 숨겨진 문서를 읽은 뒤 답변 문장만 짧게 줄이는 방식으로는 접근 범위를 관리할 수 없다.

Google 검색의 데이터 소스 접근 제어는 사용자 신원과 문서 권한을 연결해 검색 결과를 제한한다. 해당 기능은 문서에 미리보기 기능으로 표시돼 있으며, 데이터 저장소 생성과 신원 제공자 설정 등 적용 조건이 있다. 사내 메신저 설치만으로 이 권한이 자동 설정된다고 보면 안 된다. Google 검색 접근 제어

Google Chat API도 사용자 인증과 앱 인증을 구분한다. 도입 담당자는 챗봇이 어느 계정의 권한으로 문서를 찾는지 확인해야 한다. 운영자의 넓은 문서 접근권한을 그대로 모든 직원 답변에 사용하면 직원에게 허용하지 않은 내용이 섞일 수 있다. Google Chat 인증·인가

아래는 도입팀이 답변과 전달 경로를 정할 때 쓸 기준이다. 개별 직원의 자격·승인 여부를 챗봇이 결정하게 하려면 별도 업무 규칙과 권한 검토가 필요하다. 첫 단계에서는 승인된 안내와 담당자 연결을 명확하게 두는 편이 운영 범위를 관리하기 쉽다.

담당자 연결은 연락처 한 줄을 붙이는 일로 끝나지 않는다. 챗봇이 무엇을 확인했고 무엇이 남았는지 짧게 전달하면 직원이 같은 설명을 반복하지 않아도 된다. 대화 전체에 다른 개인 정보가 포함됐을 때는 필요한 업무 내용만 넘기는 범위를 정한다.

답변 수보다 같은 문의가 다시 들어오는지 본다

운영할 때는 질문 건수와 실제 문의 감소를 따로 기록한다. 직원이 답변을 읽고도 신청 위치를 못 찾았다면 대화 한 건을 처리했지만 문의는 줄지 않았다. 같은 직원이 같은 업무로 다시 물은 이유를 보아야 문서 문제와 검색 문제를 구분할 수 있다.

처음에는 자주 묻는 절차 몇 개를 골라 질문 표현, 연결 문서, 결과를 기록한다. 틀린 답이 나오면 어느 문서를 찾았는지, 문서는 맞는데 해석이 틀렸는지, 링크가 열리지 않았는지 나눈다. 답변 문구만 고치면 원인이 다른 오류를 같은 방식으로 처리하게 된다.

변경 후에는 원래 질문과 직원이 쓰던 다른 표현을 함께 시험한다. PC와 모바일에서 출처가 열리는지, 두 질문 모두 답하는지, 접근권한이 다른 계정에서는 허용된 내용만 나오는지 확인한다. 새 기능을 추가했을 때 기존 질문의 답이 바뀌는지도 읽어야 한다.

담당자가 문서를 고치고 질문을 시험하는 시간도 운영 업무에 포함한다. 이를 빼고 챗봇의 대화 수만 성과로 보고하면 관리 부담을 놓친다. 직원이 직접 신청을 마친 문의, 담당자에게 넘어간 문의, 잘못 안내해 다시 처리한 문의를 구분하면 다음에 줄일 일이 보인다.

사내 규정 챗봇을 처음 만드는 팀의 목표는 모든 질문에 긴 답을 붙이는 데 두지 않는 편이 낫다. 최신 규정이 있는 반복 문의에는 짧은 절차와 열리는 링크를 제공하고, 규정만으로 결정할 수 없는 질문에는 권한 있는 담당자를 연결한다. 경영지원팀이 같은 질문을 반복해서 설명하던 시간을 줄이려면 답변 문장보다 이 경로가 먼저 완성돼야 한다.

자주 묻는 질문