ALF 테스트

규칙이나 지식 등 ALF 설정을 변경하면 기존에 잘 답변하던 케이스도 의도치 않게 달라질 수 있어요. ALF 테스트는 이런 변화를 배포 전에 확인하고 보완할 수 있는 기능입니다.

미리 만들어 둔 고객 시나리오를 바탕으로 ALF가 가상 고객과 시뮬레이션 대화를 나누고, 설정해 둔 평가 기준에 따라 통과/실패를 자동으로 판정해요. 설정을 바꿀 때마다 같은 테스트를 반복 실행하면, 답변 품질이 잘 유지되는지 한눈에 비교할 수 있습니다.

• 유료 플랜에서 사용할 수 있어요. 다만 실제 ALF 실행은 그로스 플랜 이상부터 가능해요.

• 'AI 설정' 권한이 있는 팀 멤버가 설정할 수 있어요.

• 지식, 규칙 등 ALF 세팅을 완료한 상태에서 테스트를 진행해야 의미있는 결과를 얻을 수 있어요.

• 전화 상담(보이스 ALF) 에 대해서도 테스트 케이스를 만들 수 있어요. 채팅과 전화를 하나의 케이스로 함께 테스트하거나, 채널별로 따로 관리할 수 있습니다. (적용일: 2026년 8월 27일 이후)

• 테스트를 위해서는 해당 서비스에 최근 90일 이내 상담 100건 이상이 쌓여 있어야 상담 기반 자동 생성을 사용할 수 있어요.

테스트 케이스를 만드는 방법은 세 가지예요. 아래 3가지 중 상황에 맞는 방법을 선택해 주세요.

1. 직접 만들기

   → (좋은 테스트 케이스 작성 팁 을 참고하면 완성도 높은 테스트 케이스를 만들 수 있어요.)

2. 상담 내역으로 자동 케이스 만들기

3. AI CoS로 만들기

테스트 케이스는 ALF가 처리해야 할 고객 상황 하나를 정의해 두는 단위예요. 한 번 만들어 두면 ALF 세팅을 바꿀 때마다 반복해서 사용할 수 있습니다.

1. [고객] - [서포트] - [테스트]에서 [+ 테스트 케이스 추가] 버튼을 클릭해 주세요.

2. 아래 항목을 입력해 주세요. 시나리오와 사용자 첫 메시지를 실제 고객 말투에 가깝게 작성할수록 시뮬레이션이 더 현실적으로 이루어져요. 자주 들어오는 문의 유형부터 테스트 케이스로 만들어 두면, 설정을 바꿀 때마다 핵심 시나리오가 정상 동작하는지 빠르게 확인할 수 있습니다.

3. 입력이 끝나면 오른쪽 위 [저장] 버튼을 클릭하세요. 항목을 모두 채워야 저장 버튼이 활성화돼요.

채널톡 메시지와 전화를 둘 다 선택해서 하나의 케이스로 만들면, 실행 시 아래처럼 동작해요.

• 실행 기록: 서비스별로 따로 쌓여요.

• 결과 요약: 두 서비스를 합산해서 작성돼요.

• 설정된 규칙·지식·태스크에 따라 서비스별로 결과가 다르게 나올 수 있어요.

채팅과 전화는 응대 시나리오가 다르기 때문에, 되도록 서비스별로 케이스를 나눠 만드는 걸 권장해요.

케이스를 하나씩 직접 입력하지 않아도, 최근 90일 이내의 상담 내역을 분석해 자주 들어온 문의를 테스트 케이스로 한 번에 만들 수 있어요. 처음 테스트를 준비할 때 빠르게 환경을 갖출 수 있습니다.

1. [고객] - [서포트] - [테스트]에서 [상담 기반 케이스 생성] 버튼을 클릭해 주세요.

2. 어떤 서비스의 케이스를 생성할지 묻는 창이 나타나요. 채널톡 메시지 / 전화 중 하나만 선택하거나 둘 다 선택할 수 있어요.

   • 하나만 선택 → 선택한 서비스의 케이스만 생성돼요.

   • 둘 다 선택 → 채널톡 메시지용, 전화용 케이스가 각각 따로 생성돼요. 채널별 상담 유형과 건수에 따라 서비스별로 생성되는 케이스 개수는 다를 수 있어요.

3. 채널톡 메시지의 경우 최근 90일 이내 상담 내역을 분석해 테스트 케이스를 자동으로 만들어요. 최대 100개까지 만들수있습니다. 다만, 상담의 갯수와 유형에 따라 생성될 케이스의 수가 달라져요.

4. 전화와 채널톡 메시지 둘 다 90일 이내에 상담 내역이 100개 이하인 경우 선택이 불가능합니다.

5. 이미 등록된 테스트 케이스가 있는 상태에서 [상담 기반 케이스 생성]을 실행하면, 새로 생성된 케이스가 기존 케이스 목록에 그대로 추가됩니다.

• 케이스를 만들 때 테스트에 사용할 고객 유형을 함께 지정할 수 있어요. 신규 고객과 기존 고객처럼 안내가 달라지는 상황이라면, 고객 유형별로 케이스를 나눠 ALF 답변을 비교해 볼 수 있습니다.

• 테스트 케이스에서 설정하고 싶은 특정 상담 상황이 있다면, [고급 설정]을 열어 상담 정보를 직접 수정할 수 있어요.

어떤 케이스부터 만들어야 할지 막막하다면, 채널톡의 AI 비서 AI CoS에게 물어볼 수 있어요. 테스트가 처음이거나 어디서 시작할지 모를 때 활용해 보세요.

유저챗 링크를 함께 붙여 "ALF가 이 대화에서 왜 이렇게 답했어?"처럼 질문하면, AI CoS가 상황을 분석해 테스트 케이스 만들기를 도와줍니다.

• AI CoS 문의 경로: 채널톡 데스크 화면 상단의 AI CoS 아이콘 혹은 채널톡 데스트의 팀챗, 수신함 화면의 사이드뷰

등록한 테스트 케이스를 실행해, ALF가 가상 고객과 시뮬레이션 대화를 나누도록 하는 단계예요.

1. 테스트 케이스 목록에서 실행할 케이스를 고르거나, 오른쪽 위 [모두 실행]을 클릭해 전체를 한 번에 실행하세요.

2. 실행이 시작되면 ALF가 가상 고객과 차례대로 시뮬레이션 대화를 진행해요.

   • 실행 도중 설정을 바꿔도 진행 중인 테스트에는 영향을 주지 않아요

3. 테스트 실행이 완료되면 나와의 대화방을 통해 알림을 받게 됩니다.

테스트가 끝나면 케이스별로 아래 결과를 확인할 수 있어요.

• 결과 요약: 테스트 케이스를 여러 번 실행한 결과를 종합해 표시해요. 각 실행의 통과율에 따라 통과, 주의, 실패로 판정되며, 판정 사유도 함께 확인할 수 있어요.

  • 통과(): 통과율 80% 이상

  • 주의(): 통과율 50% 이상 ~ 90% 미만

  • 실패(): 통과율 50% 미만

• 실행별 결과: 각 실행(실행 1, 실행 2 …)마다 통과, 실패 여부와 그렇게 판정한 평가 사유,CX Score(5점 만점) 와 점수 사유를 확인할 수 있어요.

• 대화 보기: 실제로 오간 시뮬레이션 대화를 [고객 화면]과 [대화 로그]로 직접 확인할 수 있어, 어디서 어떻게 답변이 어긋났는지 파악할 수 있어요.

설정을 바꾼 뒤 같은 테스트를 다시 실행하고 이전 결과와 비교하면, 어떤 변경이 ALF 답변 품질에 영향을 줬는지 알 수 있어요. 지난 실행 기록은 오른쪽 위 [실행 로그]에서 다시 확인할 수 있습니다. 테스트 실행 시점의 ALF 설정이 자동으로 저장돼, 어떤 설정 상태에서 나온 결과인지 확인할 수 있어요.

화면 오른쪽 위 [실행 로그]를 누르면 지금까지의 테스트 실행 기록을 한 번에 볼 수 있어요. 채널 내 모든 팀 멤버의 실행 결과가 함께 표시돼요.

• 마지막 실행 일시: 해당 테스트가 실행된 시점

• 통과율: 그 실행의 전체 통과율

  • 전체 통과율 = 통과 케이스 수 ÷ 전체 케이스 수 × 100

• 평균 실행 시간: 케이스당 평균 소요 시간

• 실행자: 테스트를 실행한 팀 멤버

1. 각 시도의 대화 내용과 결과는 실행일로부터 90일 후 자동으로 삭제돼요. 설정 변경 전후 비교처럼 중요한 결과는 따로 기록해 두시길 권장해요.

2. 채팅과 전화는 고객 응대 시나리오가 다르기 때문에, 서비스별로 테스트 케이스를 따로 만드는 걸 권장해요. 다만 직접 만들기(수동 생성)에서는 하나의 케이스로 두 서비스를 동시에 테스트하는 것도 가능합니다.

1. 핵심 흐름만 담으세요.

시나리오가 단순할수록 의도한 흐름대로 시뮬레이션이 재현될 확률이 높아요.

AI는 같은 시나리오를 줘도 실행할 때마다 조금씩 다르게 반응하는 특성이 있는데, 시나리오가 복잡할수록 이 차이가 두드러져서 예상 밖의 방향으로 흘러가기 쉬워요.

(좋은 예 ) 핵심만 포함한 시나리오

  1. 고객은 배송 조회를 요청한다.
  2. 에이전트의 안내를 받은 후, 고객은 주문번호를 제공한다.

(나쁜 예 ) 너무 복잡한 시나리오

  1. 고객은 배송 조회를 요청한다.
  2. 상담원이 주문번호를 묻자 고객이 헷갈려하며 이전 주문과 혼동한다.
  3. 상담원이 재차 확인을 요청한다.
  4. 고객이 정확한 주문번호를 찾아 제공한다.
  5. 고객은 배송 조회 결과에 안도한다.

2. 시나리오는 단계별로 나누어, 번호를 매긴 뒤 줄바꿈(엔터)으로 구분하여 작성하세요.

• 전체 시나리오 흐름을 번호 목록으로 나누면, 원하는 순서대로 시뮬레이션이 전개될 확률이 높아져요.

• 한 단계에서는 고객의 행동이 하나만 나오게 하세요.

• 각 단계의 기본 형식은 "고객은 (행동)한다." 또는 "에이전트의 안내를 받은 후, 고객은 (행동)한다." 두 가지예요.

  두 번째 형식에서 "에이전트의 안내를 받은 후"는 그대로 두고, 에이전트가 구체적으로 뭐라고 안내하는지는 쓰지 않는 것을 권장합니다.

(좋은 예 )

  1. 고객은 배송 조회를 요청한다.
  2. 에이전트의 안내를 받은 후, 고객은 주문번호를 제공한다.

(나쁜 예 ) 한 단계에 두 행동이 섞임

  1. 고객은 배송 조회를 요청하고, 주문번호를 물어보면 바로 제공한다.

3. 고객의 행동만 쓰고, 에이전트가 어떻게 답할지는 미리 짐작해서 넣지 마세요.

실제 고객은 ALF가 어떤 답을 줄지 모르는 상태로 대화를 시작해요. ALF의 답변 내용을 미리 전제로 한 단계를 넣으면, 시나리오 자체가 특정 결과를 가정하게 돼서 시뮬레이션이 부자연스러워지고 평가도 왜곡돼요.

(좋은 예 ) ALF의 대응 결과에 상관없이 이어지는 고객의 행동 흐름만 남김

  1. 고객은 환불을 요청한다.
  2. 에이전트의 안내를 받은 후, 고객은 상담원 연결을 요청한다.

(나쁜 예 ) ALF의 대응 방식이 시나리오에 드러남

  1. 고객은 환불을 요청한다.
  2. 에이전트는 환불 정책을 안내하고, 고객에게 주문번호를 물어본 뒤, 고객은 자신의 주문번호를 제공한다.

4. 테스트하고 싶은 task가 있는 경우, task 트리거 조건을 시나리오 안에 상황으로 풀어서 설명하세요.

Task는 특정 조건이 충족돼야 실행되는데, 시나리오에 그 조건이 상황으로 드러나 있지 않으면 시뮬레이션 중 ALF가 아예 그 task를 타지 않을 수 있어요.

Task의 트리거 조건이 특정 유저 속성(요금제, 가입 기간, 지역 등)에 따라 갈리는 경우, 고급 설정에서 그 조건에 맞는 유저를 지정해 주세요.

(좋은 예 ) 해외 배송 통관 조회에 대한 task가 있는 경우

  # 시나리오
  1. 고객은 해외 배송 상품의 통관 지연 여부를 문의한다.

  # 고급 설정
  "해외 배송 이용 고객" 속성을 가진 유저로 지정

(나쁜 예 ) 트리거 조건을 잘 설정하지 않은 경우

  # 시나리오
  1. 고객은 배송이 왜이렇게 늦는지 문의한다

  # 고급 설정
  (없음)

5. 테스트하려는 task의 시나리오가 특정 함수 노드를 거치는 경우, "실행 완료 후" 값으로 저장되는 변수와 원하는 응답값을 [조건]에 명시하세요.

Task 안의 함수 노드는 실행이 끝나면 그 결과를 특정 변수에 담아두는데, 이 값에 따라 다음에 어느 노드로 이어질지가 정해질 수 있어요.

원하는 흐름으로 이어지게 하려면, 함수 노드의 "실행 완료 후" 응답값이 무엇이어야 하는지 [조건]에 적어주세요.

예시상황.

다음 Task에서 "V. 교환접수" 함수 노드 → "W. 주문교환 성공 안내"로 이어지길 원하는 경우

테스트하려는 시나리오가 "V. 교환접수" 함수 노드를 실행하고, 실행 완료 후 exchangeStatus 값이 "exchangeRequested"가 되어 "W. 주문교환 성공 안내"로 이어지길 원한다고 가정해볼게요.

• 이 흐름을 타려면 exchangeStatus="exchangeRequested"라는 조건이 필요해요. 이 조건을 [조건] 문항에 추가하면 돼요.

# 시나리오
1. 고객은 교환을 하고 싶다고 묻는다.
....

[조건]
- 고객의 교환 요청은 성공적으로 접수된다 (exchangeStatus="exchangeRequested")

1. 평가 기준은 줄바꿈(엔터)으로 구분해서 여러 개를 작성할 수 있어요.

여러 판정 포인트를 한 줄에 몰아 쓰지 말고, 줄을 나눠서 각각 하나의 기준으로 작성하세요.

결과를 볼 때도 어떤 기준이 통과/실패했는지 항목별로 명확하게 확인할 수 있어요.

2. 하나의 평가 기준에는 하나의 판정 포인트만 담으세요.

여러 내용을 한 기준에 섞으면 어느 부분 때문에 실패했는지 구분할 수 없어요.

(좋은 예 )

  배송 예정일을 안내한다 (#1)
  배송 경로를 안내한다 (#1)

(나쁜 예 ) 한 기준 안에 여러 내용 기재

  배송 예정일과 배송 경로, 담당 택배사를 안내한다 (#1)

3. 평가 기준 각 항목 끝에는 (#1), (#2)처럼 시나리오 몇 번째 단계에 대한 평가인지 표시할 수 있어요.

특정 단계를 거치지 않고도 ALF가 상담을 성공적으로 마무리하는 경우가 있는데, 이때 단계 번호를 표시해두면 실제로 일어나지 않은 단계에 대한 기준은 채점에서 자동으로 제외돼요.

  # 시나리오
  1. 고객은 환불을 요청한다.
  2. 에이전트의 안내를 받은 후, 고객은 상담원 연결을 요청한다.

  # 평가 기준
  환불 가능 여부를 안내한다 (#1)
  상담원 연결 요청을 수락한다 (#2)

4. 시나리오에서 고객이 "직접" 요청한 내용만 평가 기준에 담으세요.

시나리오에 없는 내용을 평가 기준에 넣으면, 실제로는 고객이 묻지도 않은 것을 안내하지 못했다는 이유로 케이스가 실패 처리될 수 있어요.

(좋은 예 )

  # 시나리오
  1. 고객은 배송 조회를 요청한다

  # 평가 기준
  배송 조회 결과를 안내한다.

(나쁜 예 ) 시나리오에 없는 "반품 정책"을 안내할 것을 기준에 넣음

  # 시나리오
  1. 고객은 배송 조회를 요청한다

  # 평가 기준
  배송 조회 결과를 안내한다.
  반품 정책도 안내한다

5. "어떻게" 안내하는지보다 "무엇을" 안내하는지로 작성하세요.

특정 전달 방법이나 수단을 기준으로 못박으면, ALF가 다른 방식으로 똑같이 잘 안내해도 실패로 판정될 수 있어요.

• (좋은 예 ) 요금제를 안내한다

• (나쁜 예 ) 요금제 비교표를 첨부한다

6. 날짜·금액·채널명 같은 구체적인 값 대신, 일반화된 기준으로 작성하세요.

테스트를 반복 실행할 때마다 실제 값이 달라질 수 있어서, 특정 값을 못박으면 값이 바뀔 때마다 케이스가 매번 실패하게 돼요.

• (좋은 예 ) 연장 가능 여부와 기한을 안내한다

• (나쁜 예 ) 2026-07-22까지 연장 가능하다고 안내한다

7. 시나리오상 에이전트가 아직 답하지 않은 부분에 대한 기준은 넣지 마세요.

마지막 단계가 "고객이 ~를 요청한다"로 끝난다면, 그 요청에 대한 응대 기준은 만들지 마세요. 에이전트가 아직 답할 기회조차 없었던 부분을 평가하면 실패로 나올 수도 있어요.

(좋은 예 ) 마지막에 "에이전트가 답변한다"는 단계를 추가하여 답할 기회를 명시

  # 시나리오
  1. 고객은 환불 요청을 하고싶다고 말한다.
  2. 고객은 환불 절차를 문의한다.
  3. 에이전트는 이에 맞는 답변을 한다.

  # 평가 기준
  환불 절차를 안내한다 (#2)

(나쁜 예 ) 마지막 문의에 대해 에이전트가 답하지 않을 수도 있음

  # 시나리오
  1. 고객은 환불 요청을 하고싶다고 말한다.
  2. 고객은 환불 절차를 문의한다.

  # 평가 기준
  환불 절차를 안내한다 (#2)

8. Task 관련 평가 기준은 시뮬레이션 대화에 드러날 수 있는 부분만 넣으세요.

테스트 성공 여부는 시뮬레이션 중 오간 대화만 보고 이루어져요. Task 내부적으로 어떤 처리가 일어나는지는 채점 대상이 아니에요.

(좋은 예 ) 대화 중 실제로 주고받는 내용을 위주로 평가 기준 작성

  # 상황
  배송 조회 task가 고객의 이름과 연락처를 확인하는 단계가 있는데, 이를 테스트하고 싶음

  # 시나리오
  1. 고객은 주문한 상품이 아직 도착하지 않았다며 배송 상태를 문의한다.

  # 평가 기준
  고객의 이름을 확인한다 (#1)
  고객의 연락처를 확인한다 (#1)

(나쁜 예 ) Task 내부 처리 과정을 평가 기준으로 삼음

  # 상황
  배송 조회 task가 고객의 이름과 연락처를 확인하는 단계가 있는데, 이를 테스트하고 싶음

  # 시나리오
  1. 고객은 주문한 상품이 아직 도착하지 않았다며 배송 상태를 문의한다.

  # 평가 기준
  고객 정보를 조회 시스템에서 찾는다 (#1)
  내부 태그를 부여한다 (#1)