20년 치 고객 지원 티켓 앞에 AI 에이전트를 배치했습니다
저희는 100만 건의 티켓이 쌓인 헬프데스크 시스템을 운영하고 있습니다. 2,400개의 매뉴얼과 두 개의 방대한 코드베이스도 보유하고 있죠.
개발자가 이전에 이 문제를 해결한 적이 있는지 물으면 대답은 항상 "예"입니다. 데이터가 그냥 묻혀 있을 뿐이죠. 시니어 직원은 검색하는 데 몇 시간을 허비하고, 주니어 직원은 몇 주를 허비합니다.
저는 이 모든 데이터 앞에 위치할 AI 에이전트를 구축했습니다. 현재는 실제 서비스(production)에 적용되어 있습니다. 실제로 어떤 일이 일어났는지 알려드리겠습니다.
데이터가 어려운 부분은 아니었습니다. 어디를 찾아봐야 할지 아는 것이 어려웠습니다. 에이전트가 말을 지어내지 않게 만드는 것은 훨씬 더 어려웠습니다.
작동 방식:
- 자연어 입력을 받는 하나의 에이전트.
- 헬프데스크 데이터베이스, 프로젝트 도구, GitLab, SVN을 읽습니다.
- 매뉴얼과 오래된 티켓에 대해 벡터 검색을 수행합니다.
- .xlsx 또는 .docx와 같은 파일을 생성할 수 있습니다.
- 스스로 도구를 선택하고 병렬로 실행합니다.
아키텍처는 간단합니다. 메인 앱과 분리된 Node 컨테이너에서 실행됩니다. 장애 격리(failure isolation)를 위해 이렇게 설계했습니다. AI가 실패하더라도 헬프데스크는 계속 작동해야 하기 때문입니다.
가장 큰 교훈은 프롬프트에 관한 것이었습니다. 처음에는 40,000 토큰에 달하는 거대한 텍스트 덩어리로 시작했습니다. 유지보수가 어려웠고 에이전트가 집중력을 잃었습니다.
접근 방식을 바꿨습니다. 프롬프트를 작은 스킬(skill) 파일로 나누었습니다.
- 티켓 검색은 하나의 파일입니다.
- 코드 히스토리는 또 다른 파일입니다.
- 프로젝트 관리는 세 번째 파일입니다.
메인 프롬프트는 라우터 역할을 합니다. 필요할 때만 해당 스킬을 로드합니다. 이를 통해 요청당 토큰 사용량을 40,000개에서 8,000개로 줄였습니다. 에이전트는 작업에 집중할 수 있고 코드는 업데이트하기 쉬워졌습니다.
사용자 프로필도 추가했습니다. 개발자에게는 코드 경로를, 프로젝트 매니저에게는 상태 요약을 제공합니다. 에이전트는 누가 질문하는지 따로 알려주지 않아도 알 수 있습니다.
완벽하지는 않습니다. 다음과 같은 실제 실패 사례들을 겪었습니다:
- 환각(Hallucinations): 에이전트가 가짜 URL을 만들어냈습니다. 해결책: 정확한 패턴을 고정하거나 강제로 조회를 수행하게 합니다.
- 메모리 손실: 긴 대화 중에 에이전트가 규칙을 잊어버렸습니다. 해결책: 매 대화마다 구조화된 할 일 목록(to-do list)을 주입합니다.
- 무한 루프: 에이전트가 도구를 너무 많이 호출했습니다. 해결책: 요청당 엄격한 예산(budget)을 설정합니다.
- 보안: 사용자들이 에이전트를 속이려 했습니다. 해결책: 보안을 프롬프트에만 의존하지 마세요. 인프라 수준에서 읽기 전용 데이터베이스 자격 증명을 사용하세요.
진짜 작업은 매주 반복되는 루프입니다. 로그를 읽고, 세션을 평가하고, 스킬을 미세 조정하고, 프로필을 업데이트합니다.
이 루프를 건너뛰면 데모에 불과하지만, 이를 수행하면 제품이 됩니다.
목표는 단순히 더 빠른 답변을 얻는 것이 아닙니다. 목표는 조직의 지식(institutional knowledge)을 사내에 유지하는 것입니다. 사람이 떠나더라도 그들의 지식은 대화 기록(transcripts) 속에 남습니다.
구축을 위한 요약:
- 자체 히스토리에 대한 RAG로 시작하세요.
- 하나의 큰 프롬프트 대신 지연 로딩(lazy-loaded)되는 스킬 파일을 사용하세요.
- 개인화된 컨텍스트를 위해 사용자 프로필을 사용하세요.
- AI를 별도의 컨테이너에 격리하세요.
- 지침이 아닌 인프라를 통해 보안을 강화하세요.
- 매주 로그를 확인하세요.
Optional learning community: https://t.me/GyaanSetuAi