채널톡 ALF 4개월 사용 후기

들어가며

채널톡의 AI 에이전트 ALF를 약 4개월간 운영했습니다. 회사는 MAU 약 10만+ 규모의 모바일 게임 서비스고, 3개국 채널 중 한국과 글로벌(영문) 채널 2개에 ALF를 적용 중입니다. 월 평균 사용량은 약 125,000 AU 수준.

ALF의 구성

ALF의 설정 영역은 크게 3가지로 나뉩니다.

• 규칙: 페르소나, CX 톤매너, 금지사항 등 응대의 기본 룰
• 지식: AI가 답변에 참조하는 지식 베이스
• 태스크: 노드 기반의 응대 플로우 (실제 액션 수행)

셋업에 소요된 시간은 최초 1주일 + 이후 추가 유지보수 기간 (산정 불가)입니다. 각 영역마다 운영하면서 발견한 함정과 의사결정이 있어서, 이 글은 셋 다 별도 섹션으로 다룹니다.

지식 - 자체 도큐먼트로 수렴한 이유

지식 베이스 소스로는 세 가지 후보가 있었습니다. 저희 웹사이트 크롤링, 노션 연동, ALF 자체 도큐먼트. 결국 셋 중 자체 도큐먼트로 수렴했습니다.

웹사이트 크롤링

사이트맵이 정상적으로 노출되어 있어야 사이트 문서를 제대로 수집할 수 있는 것으로 보였습니다. 저희 사이트 기준으로는 웹이 핵심 서비스가 아니라 사이트맵은 seo를 위한 최소한으로만 관리되어 있었고 크롤링은 고려하지 않았기 떄문에 정상적으로 크롤링이 이루어지지 않았습니다. 설령 크롤링이 가능하더라도 수집이 폴링 방식이라 즉시 반영되지 않는 단점도 치명적이었습니다. 결국 단순 채널톡 크롤링을 위해 웹사이트 구조를 재설계하고 관리하는 것은 ROI가 맞지 않다고 판단해 포기했습니다.

노션 연동

가장 아쉬웠던 부분입니다. 저희는 확률 정보 같은 자주 참조되는 문서를 노션에 정리해두고 있었는데, 노션 페이지가 ALF에 잘 먹지 않았습니다. 제가 추가로 해줘야 할 설정을 놓쳤을 가능성도 배제할 수 없지만, 검색 등 시도해본 범위 안에서는 안정적으로 수집하는 방법을 찾지 못했습니다. (만약 정말 추가 설정이 필요한 거였다면 그건 그것대로 UX 문제입니다. 가장 보편적인 사내 CMS의 연동법이 명시되어 있지 않은 셈이니까요.)

자체 도큐먼트

가장 잘 동작했습니다. 장점이 명확합니다.

• 발행 즉시 적용: 폴링 대기 없음
• 다국어 작성 지원: 글로벌 서비스 운영 입장에서 의미 있는 기능
• 공개/비공개 분리:
  • 공개 도큐먼트는 응답 시 출처가 표기되어 신뢰도가 올라갑니다
  • 비공개 도큐먼트는 출처 없이 응답에만 활용됩니다. 알려진 버그 리스트, 내부 응대 가이드처럼 외부에 그대로 노출하면 곤란하지만 AI 응답에는 반영되어야 하는 문서를 여기에 담을 수 있습니다

빈도 높은 질문을 도큐먼트로 정리하기 시작하니 자동 응답 처리율이 체감 상승했습니다.

도큐먼트의 한계 - 운영 비용과 Vendor Lock-in

도큐먼트가 잘 동작한다고 모든 걸 옮기는 건 별개 문제입니다.

도큐먼트 안에서 알려진 버그 리스트처럼 슬랙, 노션, 이슈 트래커와 별개로 주기적으로 갱신해줘야 하는 문서는 자연적으로 폐기됐습니다. 구조적으로 잘 관리가 이루어지기 힘들었습니다. (CS팀 인원이 적은 것도 한 몫 했습니다.) 이런 케이스를 커버하려면 둘 중 하나가 필요해 보입니다.

1. CS팀이 충분히 커서 별도 CMS 관리 인력을 둘 수 있습니다
2. 애초에 사내 CMS 자체가 채널톡 도큐먼트에 종속되어 있습니다

2번은 개인적으로 올바르지 않다고 생각합니다. 채널톡 도큐먼트는 제가 확인한 범위 내에서는 외부 추출 기능이 없어서, 종속도가 깊어지면 Vendor Lock-in 위험이 따라옵니다. 노션 정도의 안정적인 이주 옵션을 기대하긴 어렵다는 게 제 판단입니다.

태스크 - ALF의 진짜 핵심

지식이 “답변 소스”라면, 태스크는 “실제 행동”입니다. ALF의 핵심 가치는 사실상 여기서 나옵니다.

태스크는 노드 기반 응대 플로우입니다. 트리거 인덱스(자연어 조건)를 등록해두면, AI가 사용자 발화가 해당 조건을 만족한다고 판단할 때 그 태스크로 인입됩니다.

코드 실행 노드와 메모리

태스크의 코드 실행 노드는 메모리와 컨텍스트 기반으로 동작하는 JavaScript 실행 환경입니다. 자세한 스펙은 공식 개발자 가이드에 정리되어 있는데, 실제 운영하면서 체감한 주요 사양은 다음과 같습니다.

• 언어: JavaScript만 지원
• 실행 시간: 노드당 최대 60초
• 외부 호출: axios 사용 (require 가능한 라이브러리는 제한적)
• 인자: 함수 시그니처에 context와 memory가 주입됨

memory는 노드 간 데이터를 주고받는 인터페이스입니다. API는 단순합니다.

refund-node

async function handler(context, memory) {
  const receiptId = memory.get("receiptId")
  const userId = context.user.id
 
  const res = await axios.post("https://api.our-service.internal/refund", {
    userId,
    receiptId,
  })
 
  memory.put("refundResult", res.data.status)
  await memory.save()
}

문서를 제대로 읽지 않으면 쉽게 빠지는 함정이 memory.save()입니다. memory.put()만 호출하고 save()를 빠뜨리면 변경이 영구화되지 않습니다.

context는 읽기 전용 객체로, user(고객 정보)와 userChat(상담 세션 정보) 등이 들어있습니다. 수정은 불가능하고, 식별 정보 조회용으로 씁니다.

운영자 입장에서 알아야 할 또 하나의 핵심은, 코드 실행 진입 전에 응대 프롬프트 노드에서 메모리를 set해놓고 들어간다는 점입니다. 예를 들면:

~를 물어보고 ~에 대한 정보를 수집했으면 {memory_var}에 ~를 설정하고 다음 단계로 넘어가세요.

이렇게 AI가 자연어 대화로 수집, 구조화한 값을 메모리에 박아두면, 코드 노드는 그 메모리를 꺼내 결정적으로 처리합니다. 자연어 파싱(AI) + 비즈니스 로직(코드)의 명확한 역할 분리. 구조적으로 사이클도 가능해서, axios로 저희 내부 API를 호출해 결제 처리 같은 작업도 수행할 수 있습니다.

디버깅은 노드 단위 테스트와 console.log() 출력 확인이 가능하고, 각 실행의 입출력 JSON과 메모리 Diff를 결과 화면에서 추적할 수 있습니다.

보안 - IP 화이트리스팅

내부 API를 외부 AI 에이전트에 연결한다는 건 보안 이슈와 직결됩니다. 여기서 가장 답답했던 게 관련 정보가 공식 문서에 보이지 않았다는 점입니다. 적어도 제가 검색한 범위에선 그랬습니다. CX팀에 문의해도 답을 받지 못했고, 결국 채널톡 개발팀까지 거쳐서 채널톡 측의 호출 IP 주소를 제공받을 수 있었습니다. 현재 저희 내부 서버도 IP 화이스트리스팅 방식을 베이스로 (추가 보안 절차는 생략) 동작합니다.

문서화만 됐어도 한 단계에 끝날 일이지만, 어쨌든 동작은 합니다. 같은 정보가 필요하면 채널톡에 문의하면 됩니다.

일반 메시지 노드 - 결정성이 필요한 구간의 가드

태스크에는 코드 실행 외에도 일반 메시지 보내기, 상담 처리 액션(태그 부여, 우선순위 설정, 상담사 연결 등) 같은 노드가 있습니다.

이 중 일반 메시지 노드가 생각보다 유용했습니다. AI는 본질적으로 비결정적이지만, 응대 중에는 결정적이어야 하는 구간이 분명히 존재합니다. 예를 들면:

영수증 번호 확인을 완료했습니다. {영수증번호} 맞으신가요?

이런 확인 메시지를 AI가 매번 새로 작문하게 두면, 어느 순간 표현이 미묘하게 바뀌거나 누락되거나 합니다. 일반 메시지 노드로 박아두면 그 구간만큼은 항상 동일한 문구가 나갑니다.

할루시네이션

생성형 AI니까 할루시네이션은 당연히 존재합니다. 다만 위험한 환각의 종류가 직관과 다소 다릅니다.

모르는 정보를 사실인 양 만들어내는 환각의 빈도는 확실히 낮은 편입니다. 채널톡 측에서 이 부분은 꽤 신경 쓴 인상입니다.

임의 추론 - 사용자 발화를 자기 사전 지식으로 끼워맞추기

예를 들어, 저희 게임에서 “달리기”라는 일시적 이벤트(스텝업 BM, 무료 재화 계단 사이에 유료 상품을 끼워 넣는 구조)를 진행 중이었습니다. 한 유저가 “달리기에서 유료 상품이 미지급됐다”고 문의를 보냈는데, ALF의 첫 응답은 대략 이런 톤이었습니다.

달리기 미니게임을 잘 하셨는데 ~

존재하지 않는 미니게임을 추론해낸 것입니다. 단순한 사실 환각보다 이런 맥락 끼워맞추기가 훨씬 불편하게 느껴졌습니다. 사용자 입장에서 보면 “이 봇은 저희 게임을 모른다”는 인상이 즉시 박힙니다.

대응은 규칙 노드에서 이런 임의 추론 예시를 명시적으로 나열해 금지시키는 방식입니다. 어느 정도 완화되긴 했지만, 완전히 사라지진 않았습니다. 채널톡이 어떤 LLM을 백본으로 쓰는지는 블랙박스이고, 솔직한 인상으로는 모델 자체의 추론 깊이가 아주 깊은 편은 아닌 듯합니다. 이건 어디까지나 운영 체감이라 주관이 들어가 있습니다.

다국어 운영의 함정

글로벌 채널을 운영하면서 가장 고생한 영역입니다.

저희는 글로벌 출시를 대만에서 시작했고, 한동안 대만 유저가 글로벌 채널의 90%였습니다. 문제는 개발팀도 CS팀도 대만어(번체 중국어)를 못한다는 것. 그렇다고 프롬프트를 대만어로 작성할 수도 없었습니다.

플로우 중에는 유저 버그 제보를 받아 저희 슬랙으로 보고서를 보내는 구간도 있습니다. 이 보고서는 당연히 한국어여야 합니다. 저희가 읽어야 하니까요.

그래서 다음과 같이 분리를 시도했습니다.

• 프롬프트: 한국어
• 응대 (유저 노출): 대만어
• 특정 메모리 변수 (보고서 등): 한국어

결과적으로 이 조합은 안정적으로 동작하지 않았습니다. 어느 순간 대만 유저에게 한국어로 응대하거나, 저희 슬랙에 뜬금없이 대만어 보고서가 도착하는 일이 반복됐습니다. 시도해본 거의 모든 조합으로 안 풀렸고, 적어도 저희 케이스에선 해결책을 찾지 못했습니다.

결국 글로벌 본격 대응 시점에 방향을 바꿨습니다.

• 프롬프트: 영어로 통일
• 대만 유저: 채널톡 내장 번역 기능 사용 안내

이걸로 일단락됐습니다. 다국어 운영을 계획 중이라면 처음부터 프롬프트를 영어로 통일하는 것을 권합니다. (추후 ALF 노드의 다국어 프롬포트 설정 기능이 나온다면 말이 달라집니다.)

토큰 낭비 우려와 실제

AI 에이전트를 도입할 때 자주 따라오는 우려는 “헛소리로 AU를 태우는 유저가 많지 않냐”는 것입니다. 결론부터 말하면, 저희 경험상 이 우려는 생각보다 작았습니다.

한국 채널

초반에 “너 안 괴롭히냐”, “개발자한테 한 마디” 같은 도발성 메시지가 꽤 들어왔습니다. 다만 대부분 곧 흥미를 잃고 이탈했습니다. 일주일도 안 가서 정상 트래픽으로 돌아왔습니다.

글로벌 채널 - 16시간 대화 케이스

흥미로웠던 건 글로벌 쪽이었습니다. 한국에선 챗봇이 보편화된 지 오래라 처음 보는 사람이 적은데, 글로벌 일부 마이너 시장의 유저들은 AI를 진짜 처음 보는 것처럼 반응했습니다. 가장 인상적이었던 케이스는 인도네시아 유저 한 명이 16시간 동안 자기 인생사를 풀어놓은 사례입니다.

비용이 걱정돼서 채널톡에 별도로 문의했는데, 답변은 다음과 같았습니다.

• 토큰은 채팅당 500 AU(약 500원) 단위로 캡이 걸려 있습니다
• 24시간 비활성 시 세션이 종료됩니다
• 채널톡 측 답변은 “주제와 무관한 응대는 무시”를 권장

500원이면 16시간 인생사도 큰 부담은 아닙니다. 다만 저희는 채널톡 측 권유와 달리 응대를 그냥 두기로 했습니다. 글로벌, 특히 일부 시장에서는 이런 응대를 무시당했을 때 별점 1점 리스크가 비용보다 훨씬 크다는 판단이었습니다.

가격과 플랜

저희는 1년 넘게 채널톡을 꾸준히 사용하다보니 매니저님이 별도로 컨택하여 플랜을 제안해주셨습니다. 단가나 가격을 적을까 생각도 해봤는데, 지속적으로 바뀔 수 있는 정보이기 때문에 기록하지 않겠습니다.

다만, 최근 채널톡 가격 정책에 있었던 유의미한 변화는 기록합니다:

• 2025-11-28: 과금 모델 개편. 기존 “건당 해결(per-resolution)” → “참여당(per-participation)“으로 변경. ALF가 첫 응답을 시작한 시점부터 마지막 응답이 끝난 시점(상담사 전환 또는 24시간 비활성 후 세션 종료)까지를 한 단위로 산정.
• 2026-04: 태스크 실행 비용(기존 건당 200 AU) 무료화.

태스크를 적극적으로 활용하는 입장이라면 2026-04 개편이 특히 의미가 컸습니다. 저희도 코드 실행 노드가 들어간 플로우를 더 적극적이고 공격적으로 짤 수 있게 됐습니다.

마무리

도입의 가장 큰 효과는 CS 비용 절감이었고, 이건 기대한 만큼 체감합니다. 부수적으로는 ALF 도입 이후 기존에 짜둔 규칙 기반 워크플로우는 사실상 폐기했습니다. 같은 일을 ALF가 더 자연스럽게 처리하니 굳이 유지할 이유가 없었습니다.

가장 큰 한계는 모델 자체의 추론 깊이가 깊어보이지 않는 다는 것이지만, 이 부분도 운영하다보면 감당할 수 있는 범위가 예상이 되고 다른 기능들로 충분히 커버가 가능해 크게 불편한 점은 없었습니다.

사용할 수록 채널코퍼레이션은 꽤 괜찮은 회사라는 생각이 듭니다. 과금 구조나 정책이 납득 가능한 범위 안에서 운영되고 회사의 이익 사이에서 그 균형을 절묘하게 잘 맞춘다는 생각이 듭니다.