「문의 1차 대응·서비스 데스크를 AI로 옮겨놓고 싶다」라고 하는 상담은, 더 이상 일반적인 발상이라고 말해도 좋은 것은 아닐까? 실제로, 하고 싶은 것 자체는 명쾌하다. 대기 시간을 줄이고 운영자 부하를 줄이고 인력을 줄이고 대응 품질을 평준화하고 싶습니다. 이 목적에 이론은 없다.

자주 있는 실패는 그 수단으로서 「일단 RAG에 전부 먹이게 한다」가 선택되기 쉬운 것이다. 저 자신, 과거 로그·조직내 Wiki·채팅 이력을 정리해 투입하는 구성을 검증했지만, 얻어진 것은 기대한 효율화가 아니고, 보기 그렇게 보이는 쓰레기 답변의 양산이었다.

결론은 명확하다. 일부 대체는 가능하지만 지식 운영을 설계하지 않는 SD 대체는 고확률로 실패한다. 그리고 실패 원인의 대부분은 모델 선정 실수가 아니다. 입력 데이터의 품질과 운영 책임의 설계 부족이다.

서비스 데스크 영역에서는 응답의 정확성과 감사 가능성이 동시에 요구됩니다. 이 두 가지를 양립하기 위해서는 결국 ‘승인이 끝난 조직으로 올바른 공식 지식’에 착지할 수밖에 없다.

먼저 결론

  • 과거 로그를 통째로 투입해도, 품질이 낮으면 쓰레기를 고속 검색해, 쓰레기와 같은 대답을 돌려줄 뿐이다.
  • 조직내 정보를 전투입해도 공식과 비공식의 경계가 모호하다면 조직으로서의 공식적인 문맥이나 규칙을 전제로 하지 않고, 오답을 정당화하는 장치가 된다.
  • 일반론만으로 응답하는 구성은 조직의 규칙에 반하여 현장에서 사용할 수 없다.
  • 현실해는 KCS(Knowledge-Centered Service) 루프를 AI 어시스트로 돌려 참조원의 품질과 책임자를 명확히 하는 것이다.
  • 승인된 공식 지식을 참조할 수 없는 AI는 서비스 데스크 프로덕션에서는 운용을 견딜 수 없다.

왜 “일단 모두 넣는다"가 실패하는지

1. 과거의 대응 로그는 원래 지식이 아니다.

많은 쿼리 로그는 현장에서 티켓을 닫기 위해 작성되었습니다. 그 자체는 업무로서 옳지만 재사용 가능한 지식으로서는 불충분한 경우가 많다.

  • 전제 정보가 누락되었습니다 (이용 단말기, 권한, 연결 경로, 환경 차이).
  • 티켓 완료를 목적으로 하고 있으며, 극단적인 이야기 ‘대응 완료’로 끝나거나 한다. 재사용을 의도하지 않는다.
  • 약어와 구어가 섞여 있으며 담당자의 암묵 지식에 의존합니다.
  • 근본 원인과 임시 해결 방법이 분리되지 않았습니다.

이 상태의 로그를 RAG에 투입하면, 검색이 성공했다고 해도 응답은 제대로 되지 않는다. 인간이 읽어도 애매하거나 의미불명하거나 하는 문서를, AI가 그럴듯하게 보완해도 없는 망상의 답변이 완성되어 버리기 때문이다. ‘답이 빠르다’는데 ‘해결하지 않는다’는 귀찮은 상태가 되는 것이다. 프롬프트가 나쁜지 생각하고 열심히 튜닝하려고 해도 아마 도로로 끝난다. 적어도 나는 그렇게 되었다.

2. 조직내 정보의 전체 투입은 「공식의 희석」을 일으킨다

「조직내 Wiki 전부」 「파일 서버 전부」 「채팅 로그 전부」를 읽게 하는 구성은, 외형만은 망라적이다. 그러나 실태로서는, 신뢰도가 다른 정보를 같은 검색면에 늘어놓는 행위에 가깝다.

일반적으로 다음이 발생합니다.

  • 공식 절차(승인됨)와 개인 메모(미승인)가 동렬로 검색됨
  • 폐지된 절차가 남아 있으며 최신 절차와 충돌
  • 일시 대응 노하우가 영구 절차로 오인용됨
  • 기사 갱신일시는 새롭지만 내용은 낡다는 역전이 일어난다

RAG는 ​​"문서를 찾아내는"것을 잘 한다. 하지만 ‘그 문서가 조직으로서 올바른가’를 보장하는 구조는 별도 운용으로 만들어야 한다.

3. 조직 규칙을 모르는 일반론은 정확하게 사용할 수 없다.

공식 지식이 부족한 AI가 잘 돌려주는 것은 기술적으로는 옳지만 운용적으로 실행 불가능한 대답이다.

  • 로컬 관리자 권한 부여
  • 보안 설정의 임시 완화
  • 개인 판단에서 외부 클라우드 이용
  • 부서 횡단 데이터에 직접 액세스

AI가 일반해를 되돌려도 조직 규칙에 위배되면 실행 불가능하다. 이 순간 서비스 데스크 AI는 규칙 위반을 정당화하는 장치조차 할 수 있다. 업무 과제의 해결 장치는 될 수 없다.

현장에서 일어나는 실패 예

실패 예 1 : VPN 연결 실패로 인한 잘못된 유도

  • 증상: ‘재택에서 VPN 연결할 수 없음’
  • AI 답변 : “OS의 네트워크 설정을 초기화하고 다시 시작하십시오”
  • 실제 : 원인은 인증 기반 측의 인증서 해지이며 사용자 측에서 해결할 수 없습니다.

왜 일어났는가? 과거 로그에 「개인 단말의 일시 부조」가 다수 포함되어 있어 AI가 거기에 당겨졌기 때문이다. 또한 “서비스 측 장애 분리” 절차가 공식 지식으로 약해 상위 후보에 오르지 않았다. 또한 원래 “NW 설정을 사용자가 마음대로 재설정 할 수 있는지"라는 조직 컨텍스트가 답변에 포함되지 않았습니다.

실패 예 2 : 소프트웨어 신청에서 규정 위반 제안

  • 증상: “분석 도구 사용”
  • AI 답변 : “시용판을 각자 다운로드하여 이용 개시”
  • 실제: 조직에서는 조달·라이센스 관리·반입 심사가 필수

왜 일어났는가? 사외 일반 기사와 개인 메모를 참조하여 공식 조달 흐름 문서가 묻혀 있었기 때문이다. “할 수있는 것"과 “할 수있는 것"을 분리 할 수없는 전형적인 예입니다.

실패 예 3 : 동일한 질문으로 답변이 매번 바뀝니다.

  • 증상: “메일 전달 설정 절차는?”
  • AI 답변: 일에 따라 다름
  • 실제: 이전 운영 절차 페이지와 새 절차 페이지가 공존

왜 일어났는가? “유효판"을 나타내는 메타데이터(유효 개시일, 폐지일, 승인자)가 없고, 검색 순위로 응답이 흔들렸기 때문이다. 개인 메일이나 채팅의 단편이 섞이면 비공식 설명이 우연히 상위에 나올 확률도 올라간다.

##에서 어떻게 해야 합니까? KCS 루프를 AI 어시스트로 돌립니다.

현실해는 KCS를 AI로 대체하는 것이 아니다. KCS를 AI로 가속하는 것이다.

KCS란 무엇인가

KCS(Knowledge-Centered Service)는, 문의 대응의 현장에서 태어난 지식을, 그 자리에서 기록해, 재이용해, 개선해 계속하는 운용 사상이다. 중요한 것은 “해결한 후에 문서를 쓴다"가 아니라 해결행위 그 자체에 지식갱신을 묻는점이다. RAG 시대에 KCS가 재평가되는 이유는 간단하고, 검색처의 품질이 응답 품질을 거의 결정하기 때문이다.

소화 : 오래된 이야기지만 효과

KCS는 1992년에 시작된 사고방식으로 AI보다 훨씬 오래되었다. 그래도 현재 유효한 이유는 현장의 과제가 본질적으로 변하지 않았기 때문이다.

  • 로그는 있지만 읽을 수는 없습니다.
  • 문서는 있지만 공식을 모른다.
  • 업데이트되지 않고 썩음

생성 AI를 넣으면, 이 3개는 사라지는 커녕 증폭하기 쉽다. 그렇기 때문에 화려한 신기능보다 먼저 수수하지만 깨지기 어려운 KCS의 형태로 돌아가는 의미가 있다.

KCS 운영 최소 구성

  • Capture: 문의 대응시 증상·원인·대처·적용 조건을 구조화하여 기록
  • Structure : 템플릿화하여 환경 조건, 대상 범위, 금지 사항을 필수 항목으로 설정
  • Reuse : 다음 번 조회로 참조하고 답변과 근거 URL을 세트로 제시
  • Improve : 실제 운영의 차이를 반영하여 모호한 단어와 오래된 절차를 계속 수정

실제 운영 루프 : AI 응답을 공식 지식에서 키우기

현장에서는 다음 루프에서 점차 적용 범위를 넓히는 것이 현실적이다.

  1. 사용자가 먼저 AI에 문의
  2. AI로 해결하지 않으면 서비스 데스크(SD)로 에스컬레이션
  3. SD의 대응 기록을 AI에 읽을 수 있는 적합한 템플릿으로 지식화
  4. 검토를 통과한 승인된 공식 지식만 AI 참조 데이터 소스에 추가
  5. 동종 문의로 AI의 1차 응답률과 정답률이 오른다

이 루프의 요점은 “양"보다는 “승인"또는 공식 응답에 사용할 수있는 지식의 축적이다. 「기록된 정보」가 아니라 「승인된 정보」만을 AI의 데이터 소스로 한다. 여기를 무너뜨리면 응답 범위가 넓어져도 정확성은 퍼지지 않는다.

AI에 맡겨지는 영역

  • 유사한 문의 클러스터링
  • 초안 응답 생성(근거 포함)
  • 누락 항목 지적(‘대상 OS 불명’, ‘권한 전제가 미기록’ 등)
  • 중복 지식의 통합 후보 제시

인간이 책임을 져야 할 영역

  • 공식/비공식 판정
  • 절차 승인 및 폐지 판단
  • 예외 대응 허가
  • 지식 만료 관리

여기를 AI 맡기려고 해도 괜찮은 대답을 하는 AI는 되지 않는다.

실무상의 포인트

다음은 실무상 유의해야 할 관점이다.

지식 운영 측

  • 누가 언제 어떤 공식 지식을 작성하고 공개할지 정의하고 작성 및 품질 담보 체계를 결정한다.
  • 누가 그 지식을 볼 수 있는지 정의하고 액세스 제어를 결정합니다.

AI측

  • 답변에 반드시 근거를 나타내도록 프롬프트에서 명시적으로 지시한다.
  • 비공식 및 비승인 소스를 응답 생성에 사용하지 마십시오.

개선 운영

  • AI의 오답을 수집하는 수단을 결정하고 개선을 위한 지식 작성을 정상 업무에 통합한다.

이 3점은 추상론으로 보이지만, 구현할 때 차이가 나온다. ‘누가 책임을 가지는가’를 먼저 결정한 팀은 개선이 빠르고, 결정하지 않는 팀은 같은 오답을 반복한다.

“대체 할 수 있습니까?“에 대한 대답

서비스 데스크를 AI 에이전트로 100% 대체할 수 있을지 묻는다면 현시점의 대답은 ‘할 수 없다’이다. 다만, 문의 종별을 분해해, 지식 책임을 명확화한 운용을 짜면, 1차 응답·정형 안내·표준 절차의 제시는 충분히 대체 가능이다.

즉 논점은 AI의 현명 자체가 아니다.

  • 어떤 지식을 공식으로 채택할 것인가
  • 누가 품질을 보장하는가
  • 틀렸을 때 누가 멈출까

이 3점을 설계할 수 있는 조직만이 AI 에이전트를 ‘채팅이 빠른 만큼의 도구’에서 ‘업무 전력’으로 바꿀 수 있다. 반대로, 승인된 공식 지식의 운용을 갖지 않는 조직은, 얼마나 고성능의 모델을 사용해도 서비스 데스크 품질을 만들 수 없다.

요약

“로그를 전부 넣으면 현명해진다"는 환상이다. 서비스 데스크 AI가 막히는 진짜 이유는 지식의 양이 아니라 지식의 통치 부재에 있다.

지금해야 할 일은 장엄한 완전 자동화가 아닙니다. KCS 루프를 AI 어시스트로 돌려 공식 지식을 키우는 수수한 운용이다.

이 수수함을 받아들인 조직부터 순서대로 응답 품질은 눈에 띄게 바뀐다. 서비스 데스크에서 AI를 사용한다면 최우선 순위는 항상 동일합니다. ** 승인된 조직으로 올바른 공식 지식을 지속적으로 키우는 것. **

참고 자료