AssemblyAI가 지원 에이전트 Joey의 해결률을 10%에서 80%로 올린 방식대로 오늘은 내 에이전트가 틀린 대화 하나를 지시 파일 규칙으로 옮깁니다 | DAKER 커뮤니티

에이전트를 만들다 보면 데모 질문에는 잘 답하던 에이전트가 처음 보는 질문 앞에서 엉뚱한 답을 내놓는 순간을 자주 만납니다. 그때 무엇을 고칠 수 있느냐가 다음 버전의 품질을 정합니다. AI Engineer 채널이 10월 4일 올린 약 16분짜리 발표 We Built an AI Support Agent That Resolves 80% of Tickets — AssemblyAI는 이 문제를 고객 지원 현장에서 보여 줍니다. 음성 AI 회사 AssemblyAI의 포워드 디플로이드 엔지니어(FDE) 리드 Matt Lawler는 기성 지원 챗봇이 문의의 약 10%만 해결하던 상황에서, 직접 만든 지원 에이전트 Joey로 사람 개입 없는 해결률을 80%까지 올렸다고 발표합니다. 비용은 토큰과 인프라를 합쳐 한 달 약 700달러였다고 합니다. 이 사례에서 에이전트를 만드는 참가자가 오늘 가져갈 행동은 하나입니다. 내 에이전트가 틀린 대화 하나를 골라 지시 파일의 규칙 한 줄로 옮기는 것입니다.

책상에서 키보드를 치는 개발자와 체크 표시가 붙은 대화 말풍선, 서류 더미를 그린 만화풍 생성 이미지와 제목 문의 해결률 10%에서 80%로, 틀린 대화는 규칙 한 줄로, AssemblyAI 공식 로고
설명용 생성 이미지입니다.

하루 1,000건의 API 가입과 온보딩 엔지니어 한 명

AssemblyAI는 음성 인식 파운데이션 모델을 직접 학습시키는 회사입니다. Matt Lawler는 회의 녹음 기록 서비스나 전화 상담 음성 에이전트처럼 이미 많은 서비스가 자사 모델 위에서 돌아간다고 소개합니다. 발표에 따르면 AssemblyAI에는 매일 약 1,000건의 신규 API 가입이 들어오는데, 발표 이틀 전까지 이 가입자들을 맞이하는 온보딩 엔지니어는 Matt Lawler 한 명뿐이었습니다.

그가 맡은 FDE는 고객의 사용 사례를 깊이 이해하고, 필요하면 고객 저장소에 직접 코드를 커밋하며, 한 달에도 여러 번 고객을 만나는 역할입니다. 신뢰를 쌓기에는 좋은 방식이지만 하루 1,000명에게 같은 밀도로 대응할 수는 없습니다. FDE를 계속 더 뽑는 것도 답이 아니었습니다. 그래서 Matt Lawler는 청중에게 FDE가 가진 지식으로 자기 업무를 자동화하라고 권합니다.

좋은 고객 경험을 대규모로 제공하려면, 내가 그 경험의 병목이 되어서는 안 됩니다.

해커톤 팀도 비슷한 구조를 겪습니다. 팀원 한 명이 데이터 형식, 제출 규칙, 배포 방법을 모두 알고 있으면 그 사람이 질문을 받는 병목이 됩니다. 발표가 말하는 자동화는 사람을 줄이는 이야기라기보다, 반복 질문을 에이전트에게 넘기고 사람은 판단이 필요한 일에 집중하자는 이야기에 가깝습니다.

기성 챗봇이 문의 10%에서 멈춘 이유

AssemblyAI가 처음 고른 방법은 많은 팀이 택하는 길이었습니다. 기성 지원 챗봇을 사서 공식 문서를 가리키게 하면 단순한 문서 질문은 모두 해결될 것이라고 기대했습니다. 결과는 문의의 약 10% 해결이었습니다. Matt Lawler의 계산대로라면 하루 1,000건 가운데 100건은 챗봇이 처리했지만, 남은 900건은 여전히 팀이 직접 답해야 했습니다.

그가 꼽은 진짜 문제는 해결률 숫자보다 고칠 수 없는 구조였습니다. 팀은 기성 챗봇의 시스템 프롬프트에도, 도구에도, 검색 증강 생성(RAG) 인프라에도 접근할 수 없었습니다. 무언가를 바꾸고 싶어 공급사에 요청하면 로드맵에 있다는 답이 돌아왔다고 합니다. 문서를 넣어 주는 것만으로는 부족했고, 틀린 답을 보고 바로 고칠 수 있는 권한이 필요했던 셈입니다.

틀린 답을 보고도 프롬프트와 도구와 검색 방식을 직접 고칠 수 없다면, 에이전트의 해결률도 그 자리에 머뭅니다.

대회에서 노코드 챗봇 빌더나 외부 서비스를 쓰는 팀이라면 이 대목을 한 번 점검해 볼 만합니다. 시스템 프롬프트, 검색 대상 문서, 호출 가능한 도구 가운데 우리 팀이 직접 바꿀 수 있는 것이 무엇인지 적어 보면, 심사 직전에 문제가 생겼을 때 손댈 수 있는 범위가 미리 보입니다.

Claude Agent SDK 위에 만든 Joey의 네 가지 구성

AssemblyAI는 사람을 한 명 더 뽑는 대신 팀원을 하나 만들었다며 그 에이전트에 Joey라는 이름을 붙였습니다. 지금은 웹사이트 채팅, 영업 문의, 지원 메일 주소 중 어디로 연락하든 Joey가 먼저 응대합니다. Joey는 지원 관리 도구 Pylon에 접근해 지난 대화를 기억하고, 팀은 같은 도구로 Joey의 지표를 추적합니다.

Joey의 바탕은 Anthropic의 Claude Agent SDK입니다. 공식 문서는 이 SDK를 Claude Code를 움직이는 도구, 에이전트 루프, 컨텍스트 관리를 Python과 TypeScript 라이브러리로 쓸 수 있게 한 것이라고 설명합니다. 파일 읽기·쓰기·편집, 명령 실행, 웹 검색 같은 내장 도구와 훅, 서브에이전트, MCP, 권한, 세션 기능도 함께 제공됩니다. Matt Lawler가 Joey를 일반 챗봇보다 FDE에 가깝다고 말하는 이유도 여기에 있습니다. Joey는 파일 시스템을 갖고 있고, 코드를 작성하고 디버깅하며, 도구를 호출할 수 있습니다.

발표에서 소개한 구성은 네 부분입니다.

  1. 로컬 마크다운 문서: 공식 문서 전체를 마크다운 파일로 받아 Joey의 파일 시스템에 둡니다. 문서 시스템에 업데이트가 올라가면 이 파일도 함께 갱신되므로, 문서 사이트가 내려가 있어도 Joey는 최신 내용으로 답할 수 있다고 합니다. 변경 이력과 요금 같은 주요 웹 페이지도 마크다운으로 바꿔 넣었고, 각 파일의 URL을 함께 두어 Joey가 답변에 출처를 달 수 있게 했습니다.
  2. 임베딩 검색: Voyage의 임베딩으로 가장 관련 있는 문서를 먼저 찾아, 오래 검색하지 않고도 빠르게 답하게 합니다.
  3. 에이전트형 파일 검색: 첫 검색으로 부족하거나 여러 문서를 엮어야 할 때는 Joey가 자기 파일 시스템을 직접 뒤져 필요한 자료를 찾습니다.
  4. Railway 배포: EC2 인스턴스를 직접 관리하지 않으려고 Docker 파일로 묶어 Railway에 올렸습니다. 저장소에 수정이 반영되면 약 30초 안에 새 버전이 서비스에 올라갑니다.

마지막 항목은 개선 속도와 직결됩니다. Matt Lawler는 진행 중인 고객 대화를 지켜보다 버그를 발견하고, 수정본을 배포해, 같은 대화의 나머지 부분에서는 고쳐진 Joey가 응답한 적도 있다고 말합니다. 고객은 그 사이에 수정이 있었다는 사실조차 알지 못했다고 합니다.

해결률 10%에서 80%로, 첫 주 숫자를 읽는 법

발표에서 가장 큰 숫자는 해결률입니다. Matt Lawler에 따르면 Joey는 배포 첫 주에, 그것도 그가 꽤 단순하다고 표현한 구현으로 사람 개입 없는 처리 기준 해결률 80%에 도달했습니다. 한 달 비용은 토큰과 인프라를 합쳐 약 700달러입니다. 그는 특정 유형의 문의만 골라 해결률을 높게 잡은 것이 아니라고 강조합니다. 고객은 Joey를 거치지 않고는 사람에게 연결될 수 없으므로 Joey가 들어오는 문의 100%를 받고, 그중 20%만 사람에게 넘긴다는 설명입니다.

항목기성 지원 챗봇Joey
사람 개입 없는 해결률약 10%약 80% (배포 첫 주)
프롬프트·도구·검색 수정공급사에 요청팀이 직접 수정
수정 반영 시간공급사 로드맵에 따름약 30초 (Railway 배포)
월 비용발표에서 공개하지 않음약 700달러 (토큰과 인프라)

다만 이 숫자는 발표자가 직접 밝힌 운영 지표이고, 측정 기간이나 해결 판정 방식을 담은 별도 공개 자료는 발표에 함께 소개되지 않았습니다. 첫 주 결과라는 점도 기억해 둘 필요가 있습니다. 그래도 해결의 정의를 사람이 개입하지 않고 끝난 대화로 분명히 정하고, 모든 문의가 같은 경로를 지나게 한 뒤 비율을 잰 방식은 대회 발표에서 성능을 설명할 때도 참고할 만합니다.

사람에게 넘긴 20%가 다음 할 일 목록이 됩니다

Joey가 사람에게 넘기는 문의에는 이유가 있습니다. Matt Lawler는 요금 조정, 데이터 수집 거부(옵트아웃), 계약서 서명처럼 FDE나 법무 담당자가 꼭 관여해야 하는 경우를 예로 듭니다. 그는 이 목록이 곧 다음에 자동화할 일의 목록이라고 말합니다. 예를 들어 Joey가 의료 정보 보호 계약인 BAA를 안내하지 못하면 참고 링크를 하나 더 주고, 요금 문의를 넘기던 부분은 Joey가 사용 시간을 듣고 요금을 제시하며 협상까지 하도록 바꾸었다고 합니다.

틀린 답을 고치는 방법도 구체적입니다. Joey의 지침과 주의 사항은 CLAUDE.md 파일에 모여 있고, Matt Lawler는 그 분량을 약 3만 줄로 기억합니다. 고객과 대화가 잘못 흘러가거나 틀린 답이 나오면 이 파일을 고쳐 배포하고, 그 뒤의 모든 대화가 수정된 지침을 따릅니다.

에이전트가 아직 하지 못하는 일은 실패가 아니라 다음에 만들 기능의 목록입니다.

여기서 하나 짚어 둘 점이 있습니다. Claude Code 공식 메모리 문서는 CLAUDE.md 파일 하나를 200줄 안쪽으로 유지하라고 권합니다. 파일이 길수록 컨텍스트를 더 차지하고 지시를 따르는 정도가 떨어진다는 이유입니다. 일부 파일에만 필요한 지시는 .claude/rules/ 아래의 경로별 규칙으로 옮기라고 안내하며, 구체적이고 간결한 지시일수록 더 일관되게 지켜진다고 설명합니다. Agent SDK 문서에 따르면 SDK도 Claude Code와 같은 방식으로 프로젝트의 .claude/ 폴더에서 스킬, 명령, 메모리를 불러옵니다. 대규모 운영 데이터를 가진 AssemblyAI와 달리 대회 기간에 처음 에이전트를 만드는 팀이라면, 규칙을 끝없이 덧붙이기보다 짧은 지시 파일과 주제별 규칙 파일로 나누어 시작하는 편이 관리하기 쉽습니다.

음성 모드와 Voice Agent API는 무엇이 다른가

발표 후반은 Joey에게 목소리를 붙이는 이야기입니다. AssemblyAI는 자사 고객이 음성 에이전트를 만들기 때문에, 자신들도 같은 제품으로 음성 에이전트를 만들어 봐야 한다고 판단했습니다. Joey에는 발표 주간에 음성 모드가 붙었고, 같은 도구를 그대로 쓰면서 말로 대화할 수 있게 되었습니다. 시연에서 Joey는 BAA 서명 방법을 묻는 질문에 카드가 등록된 유료 계정이 먼저 필요하고, BAA에 서명하면 모델 학습에서 자동으로 제외된다고 답했습니다.

여기에 쓰인 것이 AssemblyAI의 Voice Agent API입니다. 2026년 4월 29일 공개된 공식 블로그 글에 따르면, 이 API는 음성 인식, LLM 추론, 음성 합성을 웹소켓 연결 하나로 묶고 요금은 시간당 4.50달러입니다. 말이 끝났는지 판단하는 턴 감지는 서버에서 처리하며 기준값을 조정할 수 있고, 사용자가 말을 끊으면 에이전트가 곧바로 말을 멈추고 다시 듣습니다. 연결이 끊겨도 30초 안에 다시 붙으면 대화를 이어 갈 수 있다고 안내합니다. 이 부분은 발표자 회사의 제품 소개이기도 하므로, 음성 에이전트를 만드는 팀이라면 공식 문서의 시작 안내와 다른 선택지를 함께 비교해 보는 편이 좋습니다.

Matt Lawler가 이 부분에서 강조한 메시지는 제품보다 태도에 가깝습니다. 고객이 만드는 것과 같은 제품을 직접 만들어 봐야 지연 시간, 말 순서 주고받기, 끼어들기 처리 같은 벽을 고객과 똑같이 겪고 더 나은 조언을 할 수 있다는 것입니다. 대회 참가자에게 옮기면, 심사위원과 사용자가 실제로 겪을 흐름을 팀이 먼저 처음부터 끝까지 써 보는 일과 같습니다.

에이전트를 만드는 참가자가 오늘 할 한 가지: 틀린 대화 하나를 규칙 한 줄로 옮기기

Joey의 구성 전체를 하루 만에 따라 할 필요는 없습니다. 이 발표에서 바로 가져올 수 있는 것은 틀린 답을 보면 그 원인을 에이전트가 읽는 파일에 반영하고, 같은 질문으로 다시 확인하는 습관입니다. 오늘은 다음 순서로 한 건만 처리해 보시기를 권합니다.

  1. 지금까지 테스트한 대화 가운데 에이전트가 틀렸거나 답을 피한 대화 하나를 고릅니다.
  2. 원인을 네 가지 중 하나로 나눕니다. 참고할 문서가 없었는지, 지시가 모호했는지, 필요한 도구가 없었는지, 처음부터 사람이 판단해야 하는 일이었는지입니다.
  3. 문서가 없었다면 해당 내용을 마크다운 파일로 만들어 에이전트가 읽는 폴더에 넣고 원문 URL을 함께 적습니다. 지시가 모호했다면 지시 파일에 구체적인 규칙 한 줄을 씁니다. 사람이 판단할 일이라면 사람에게 넘기는 조건으로 적고, 따로 만든 목록에 기록합니다.
  4. 같은 질문을 다시 돌려 답이 바뀌었는지 확인하고, 질문과 고친 내용, 결과를 한 줄씩 기록해 둡니다.

이 기록이 쌓이면 Joey의 사람 이관 목록처럼 다음에 만들 기능의 우선순위가 됩니다. 대회 발표에서도 몇 건의 실패 대화를 어떤 방식으로 고쳤고 다시 돌렸을 때 결과가 어떻게 달라졌는지를 보여 줄 수 있습니다. 지시 파일은 공식 문서의 권고대로 짧게 유지하고, 길어지면 주제별 파일로 나누는 것을 잊지 마십시오.

출처

여러분의 에이전트가 최근에 틀린 대화는 어떤 유형이었습니까? 문서가 없어서였는지, 지시가 모호해서였는지, 원래 사람이 판단해야 하는 질문이었는지 댓글로 나눠 주시면 다른 참가자에게도 좋은 참고가 될 것 같습니다.