광고 자리 모집 중 · 제휴 문의

Dust와 GitHub·Zendesk 연동 가이드: 고객 지원 티켓 분류 및 이슈 트리아지 자동화

365Finds Editorial
Wiki 문서 11,430편 수록

내 AI에서 365 Wiki 사용하기

아래 프롬프트를 복사해 평소 사용하는 AI에 붙여넣고 바로 질문하세요.

전체 Skill 다운로드

먼저 프롬프트로 체험해 보세요. 365 Wiki를 자주 쓴다면 전체 365Wiki Skill을 설치해 매번 붙여넣는 수고를 줄일 수 있습니다. 평소 쓰는 AI가 없다면 Gemini나 Microsoft Copilot 웹 버전도 사용할 수 있습니다.

기술 지원 엔지니어와 기술 운영(TechOps) 팀은 일상적으로 심각한 업무 단절을 경험합니다. 고객의 문의, SLA 관리, 서비스 티켓은 Zendesk에 누적되는 반면, 코드 수정 내역, 버그 추적, 풀 리퀘스트(PR), 개발자 간 논의는 GitHub에 보관되기 때문입니다. 두 시스템이 분리되어 있으면 지원 담당자는 창을 번갈아 오가며 GitHub 저장소에서 이슈를 일일이 검색하고, 스택 트레이스를 복사해 붙여넣고, Slack에서 개발자에게 진행 상황을 재차 확인해야 합니다. 이는 버그 보고의 중복을 유발하고 고객 대응 시간을 지연시키는 주된 원인이 됩니다.

Dust(dust.tt)는 단순한 데이터 필드 동기화 플러그인과 달리, 전사적 지식 컨텍스트를 아우르는 AI 오케스트레이션을 통해 이 문제를 해결합니다. Zendesk와 GitHub를 Dust에 함께 연동하면, 과거 고객 지원 대화 내역과 개발 코드베이스를 동시에 이해하는 맞춤형 AI 에이전트를 구축할 수 있습니다. 이러한 에이전트는 유입된 티켓을 자동으로 분류하고, 기존 GitHub 이슈와의 중복 여부를 감지하며, 서비스 데스크에 비공개 사내 분석 메모를 작성하고, 필요시 개발 이슈를 표준화된 서식으로 자동 생성합니다.

본 가이드에서는 Dust, Zendesk, GitHub를 결합하여 완결성 높은 지원 티켓 분류 및 기술 트리아지(Triage) 파이프라인을 구축하는 방법을 단계별로 살펴봅니다.


아키텍처 개요: Dust가 지원과 엔지니어링을 연결하는 방식

Dust가 Zendesk와 GitHub 사이에서 작동하는 방식을 명확히 파악하려면 플랫폼의 3계층 아키텍처를 이해해야 합니다.

아키텍처 계층Zendesk 측 기능GitHub 측 기능
Connections (데이터 연결 계층)해결(Solved) 및 종료(Closed) 상태의 티켓(기본 180일 범위)과 헬프 센터(Guide) 문서를 시맨틱 검색 인덱스로 수집합니다.저장소의 Issue, Discussions, PR 최상위 댓글 및 기본 브랜치 소스 코드를 실시간으로 색인화합니다.
Tools (동작 실행 계층)에이전트에 Get Ticket(상세 조회), Search Tickets(구문 검색), Draft Reply(비공개 사내 메모 작성) 권한을 부여합니다.에이전트에 저장소 검색, 신규 Issue 등록, PR 및 토론 댓글 작성 권한을 부여합니다.
Surfaces (인터페이스 및 트리거 계층)Zendesk 티켓 화면 사이드바에 Dust 앱을 상주시키고, 티켓 수명주기 이벤트에 따라 웹훅으로 에이전트를 자동 실행합니다.GitHub 이벤트(이슈 상태 변경, PR 생성 등)를 수신하여 자율 워크플로를 트리거합니다.

이러한 구조 덕분에 Dust는 단순한 데이터 전달 파이프에 그치지 않고, GitHub의 기술적 맥락을 바탕으로 Zendesk의 고객 증상을 종합 분석한 후 양방향 시스템에서 안전한 조치를 수행합니다.


1단계: 워크스페이스 데이터 연결(Connections) 구성

에이전트가 정확한 진단을 수행하려면 먼저 과거 고객 지원 지식과 개발 이슈 데이터에 대한 읽기 권한을 확보해야 합니다.

1. Zendesk 연결 설정

  1. Dust 워크스페이스에서 Spaces > Connections로 이동한 뒤 목록에서 Zendesk를 선택합니다.
  2. 회사의 Zendesk 서브도메인(https://<서브도메인>.zendesk.com)을 입력합니다.
  3. Dust 관리자이자 Zendesk 관리자(Support 및 Guide 관리 권한 보유자) 계정으로 OAuth 인증을 완료합니다.
  4. 연결 관리 화면(Manage)에서 동기화 옵션을 조정합니다.
    • 티켓 범위 및 보존 기간: 기본적으로 최근 180일 이내에 업데이트된 Solved 및 Closed 티켓이 동기화되며, 120일 기준 롤링 삭제가 적용됩니다. 현재 진행 중인 인시던트도 참조해야 한다면 Sync Unresolved Tickets를 활성화합니다.
    • 고객 개인정보 보호(PII 비식별화): Hide Customer Information을 활성화하면 티켓 본문의 기술 내용은 유지하면서 요청자의 이름과 이메일 주소를 메타데이터에서 제거합니다.
    • 태그 및 커스텀 필드 필터링: Included Tags(예: tier-2, bug)를 지정하여 기술 관련 티켓만 선별 수집할 수 있습니다. Zendesk 커스텀 필드로 장애 모듈이나 심각도를 관리한다면 해당 필드의 숫자 ID를 Custom Field Tags에 등록하여 fieldName:value 레이블로 검색에 활용합니다.
    • API 호출 제한(TPS): Zendesk 플랜의 API 한도 초과를 방지하기 위해 초당 트랜잭션 수(TPS) 상한을 설정할 수 있습니다.

2. GitHub 연결 설정

  1. Dust에서 Spaces > Connections > GitHub로 이동하여 Connect를 클릭합니다.
  2. GitHub 조직 관리자 권한으로 인증을 진행합니다.
  3. Dust가 접근할 특정 저장소(핵심 백엔드 API, 프론트엔드 웹 앱, 연동 SDK 등)를 선택합니다.
  4. 필요시 Code synchronization을 활성화합니다. 활성화 시 에이전트가 Issue/PR 외에도 기본 브랜치의 소스 코드를 직접 열람하여 장애 원인을 추적할 수 있습니다(코드는 8시간마다 갱신, Issue/PR은 준실시간 동기화).
  5. 설정을 저장하면 Dust가 Issue 제목, 본문, 라벨, 작성자 정보를 바탕으로 시맨틱 인덱스를 생성합니다.

2단계: Zendesk 및 GitHub 액션 도구(Tools) 활성화

데이터 연결이 '읽기' 권한을 제공한다면, 에이전트가 티켓을 실시간으로 검색하고 비공개 사내 메모를 작성하며 GitHub Issue를 발행하려면 Tools를 활성화해야 합니다.

  1. Spaces > Tools로 이동하여 Add Tools를 클릭합니다.
  2. Zendesk Tools를 추가합니다.
    • Search Tickets: 검색 쿼리 문법(예: status:open priority:urgent tags:bug)을 통한 티켓 검색.
    • Get Ticket: 티켓의 전체 대화 내용, 메타데이터 및 SLA 응답 지표 확인.
    • Draft Reply: 외부 고객에게 노출되지 않는 비공개 사내 메모(Private Comment)를 작성하여 지원 담당자의 검토를 지원.
  3. GitHub Tools를 추가합니다.
    • 자격증명 모드를 선택합니다. 자동화 파이프라인의 경우 공식 봇인 @dust-agent 명의로 모든 액션이 기록되는 Workspace Credentials를 권장합니다(개별 사용자의 저장소 권한을 그대로 반영하려면 Personal Credentials 선택).

3단계: Agent Builder에서 트리아지 에이전트 구축

데이터와 도구가 준비되면 Dust의 Agent Builder에서 기술 지원 및 트리아지 전용 에이전트(예: @tier2-triage)를 생성합니다.

에이전트 설정 기준

당신은 2차 기술 지원 및 장애 트리아지를 전담하는 코파일럿(Tier-2 Triage Copilot)입니다. Zendesk 고객 티켓을 분석하고, GitHub 저장소의 개발 내역과 대조하여 실행 가능한 기술적 진단을 도출하십시오.

Zendesk 티켓 분석 시 다음 절차를 준수하십시오:
1. 티켓에서 오류 메시지, 스택 트레이스, 이상 징후를 추출하고, 지정된 GitHub 저장소(기본값: dust-tt/app-backend)에서 유사한 Open/Closed 이슈가 존재하는지 검색하십시오.
2. 과거 Zendesk 티켓 내역을 검색하여 과거에도 동일한 증상이 접수된 적이 있는지, 엔지니어링 검증을 마친 임시 우회책(Workaround)이 있는지 확인하십시오.
3. 기존 GitHub 이슈와 일치하는 경우:
   - Zendesk "Draft Reply" 도구를 호출하여 비공개 사내 메모(Private Comment)를 작성하십시오.
   - 메모 포함 내용: (a) 해당 GitHub Issue URL 및 현재 처리 상태, (b) 장애 근본 원인 요약, (c) 고객 응대 시 권장되는 기술 설명 또는 임시 조치 방안.
4. 확인된 신규 버그이며 재현 경로가 명확한 경우:
   - GitHub 도구를 사용하여 대상 저장소에 신규 Issue를 등록하십시오(제목 형식: [Triage] 오류 요약). 본문에는 관련 Zendesk 티켓 번호, 운영 환경, 재현 단계, 상세 에러 로그를 기재하십시오.
   - Zendesk 티켓에 신규 생성된 GitHub Issue 번호와 트리아지 결과를 기록한 비공개 사내 메모를 남기십시오.
5. 절대로 최종 고객에게 공개 메시지를 직접 발송하지 마십시오. 모든 출력물은 내부 사내 메모 또는 Dust 사이드바 응답 형태로 제공되어 지원 담당자의 최종 검토를 거쳐야 합니다.

4단계: UI 연동 및 웹훅 기반 자동화 배포

구축된 에이전트는 두 가지 방식으로 현업에 배치할 수 있습니다. 상담원이 필요할 때 직접 호출하는 방식과 웹훅을 통한 무인 자동 트리아지 방식입니다.

방식 A: Zendesk 티켓 사이드바 코파일럿 연동

  1. Zendesk Marketplace에서 공식 Dust 앱을 설치합니다.
  2. Zendesk 관리 센터의 Dust 앱 설정으로 이동합니다.
  3. Dust 관리자가 생성한 Workspace ID와 API Key를 입력합니다.
  4. Default Agent IDs 항목에 생성한 @tier2-triage 에이전트 ID를 입력합니다. 이렇게 하면 상담원이 티켓을 열었을 때 우측 사이드바에 해당 트리아지 에이전트가 기본 노출됩니다.
  5. 상담원의 Zendesk 이메일이 Dust 계정 이메일과 일치하는지 확인합니다. 상담원은 까다로운 티켓을 확인하며 "이 결제 타임아웃 오류가 최근 배포에서 해결되었는가?"라고 질문하여 GitHub의 PR 및 이슈 현황을 즉시 파악할 수 있습니다.

방식 B: 웹훅 기반 고우선순위 티켓 자동 트리아지

긴급 티켓이 접수되는 즉시 백그라운드에서 사전 진단을 수행하려면:

  1. Dust에서 Spaces > Triggers > Add source로 이동합니다.
  2. 기본 제공자인 Zendesk를 선택하고 계정을 연동합니다.
  3. @tier2-triage 에이전트 편집 화면에서 Triggers > Add triggers를 선택한 후 해당 Zendesk 웹훅 소스를 지정합니다.
  4. 실행 조건을 설정합니다.
    • 감지 이벤트: Ticket Created(티켓 생성) 또는 Ticket Updated(티켓 갱신).
    • 실행 조건: 자연어로 필터 조건을 기술합니다(예: "priority is urgent or tags contain technical-escalation").
    • 페이로드 전달: Include webhook payload를 켜서 티켓 제목, 본문, 태그를 에이전트에 직접 전달합니다.
    • 호출 제한(Rate Limit): 장애 상황에서 대량 티켓 유입으로 인한 크레딧 급증을 방지하기 위해 24시간 실행 횟수 상한을 설정합니다.
  5. 저장합니다. 긴급 티켓이 접수되면 상담원이 티켓을 클릭하기도 전에 Dust가 백그라운드에서 GitHub를 조회하고 체계적인 사내 분석 메모 작성을 완료합니다.

솔루션 비교: Dust AI 트리아지 vs 기존 단순 동기화 플러그인

평가 요소단순 포인트 투 포인트 동기화 도구 (예: Git-Zen)Dust 기반 맥락형 AI 트리아지 체계
중복 버그 탐지상담원이 수동으로 번호를 조회하거나 커밋 메시지에 정확한 ID를 넣어야 함.시맨틱 RAG 검색을 통해 유사한 오류 양상과 이전 논의를 분석하여 중복 이슈를 자동 식별.
근본 원인 분석 지원불가. 단순히 양쪽 시스템의 텍스트를 기계적으로 복제 전달함.소스 코드 구현, 과거 해결 티켓, 오류 로그를 종합하여 원인 가설 및 대응책 제안.
답변 초안 작성기능 없음. 지원 담당자가 기술적 답변을 백지 상태에서 작성해야 함.Draft Reply를 활용하여 기술적 정확성을 갖춘 비공개 사내 메모 초안을 자동 생성.
개인정보 보호 및 규정 준수고객 개인정보(PII)가 여과 없이 개발자 코드 저장소로 복사될 위험 존재.연결 설정에서 고객 메타데이터를 마스킹하여 안전하게 분리 관리 가능.
처리 시간 단축 효과링크 복사 수고만 덜어줄 뿐, 실질적인 기술 분석 시간은 단축되지 않음.초기 분석, 기존 결함 대조, 개발 에스컬레이션 소요 시간을 수 시간에서 수 분 단위로 단축.

거버넌스, 요금제 및 도입 권장사항

  1. Human-in-the-Loop 원칙 고수: 자동화 흐름에서 에이전트는 오직 Draft Reply를 통한 사내 비공개 메모 작성만 수행하도록 통제해야 합니다. 외부 고객과의 소통은 반드시 사람이 최종 검토한 후 승인 발송하는 절차를 유지하십시오.
  2. 웹훅 필터 최적화를 통한 리소스 절약: 모든 일반 티켓(단순 계정 문의, 비밀번호 초기화 등)에 고비용 대규모 언어 모델을 호출하지 않도록, 특정 태그나 긴급도 필터를 통해 기술적 검토가 필요한 티켓만 트리거되도록 구성하십시오.
  3. 플랜 및 크레딧 소모량 계획: Dust 비즈니스 플랜은 Pro(연간 결제 시 월 24유로/시트, 월 8,000 크레딧 제공)와 Max(연간 결제 시 월 120유로/시트, 월 40,000 크레딧 제공)로 구성됩니다. 대규모 조직의 경우 전사 크레딧 풀, SCIM 계정 연동, 감사 로그, 전담 SLA를 지원하는 Enterprise 플랜을 활용할 수 있습니다. 예상 웹훅 호출량에 맞게 크레딧을 산정하십시오.

Zendesk의 고객 접점과 GitHub의 엔지니어링 지식을 Dust를 통해 결합하면, 시스템 간 정보 복사라는 비효율을 없애고 체계적이고 신속한 기술 트리아지 운영 체계를 구축할 수 있습니다.


참고 자료