Flow Node Creator

콜센터/OB/CS 스크립트(자유 텍스트)를 vox.ai 시스템 프롬프트의 # 대화 흐름 섹션에 삽입할 수 있는 flow node로 변환한다.

왜 이 형식이 필요한가

vox.ai 음성 에이전트는 하나의 시스템 프롬프트 안에 대화 흐름을 정의한다. 원본 스크립트를 그대로 넣으면 LLM이 단계 경계, 전환 시점, 재시도 제한 등을 자의적으로 해석해서 예측할 수 없는 발화가 나온다. 이 스킬은 원본 스크립트를 “한 단계 = 한 목적 + 명확한 exit ì¡°ê±´”으로 쪼개서 LLM이 각 단계에서 할 일과 빠져나갈 조건을 정확히 파악하게 만든다.

핵심 원리:

1. 단계 안에서 할 일(프롬프트 본문)과 빠져나갈 조건(전환조건)을 분리한다.
2. 전환조건에 “다음 단계”를 지정하지 않는다. exit 조건만 정의하고, 흐름 연결은 노드 순서와 LLM의 문맥 판단에 맡긴다.

입력

사용자가 다음 중 하나 이상을 제공한다:

• 원본 스크립트: 통화/OB/CS 스크립트의 특정 구간(자유 텍스트). 전체 스크립트가 아닌 부분 단위로 들어온다.
• 필수 수집 항목: 이름, 전화번호, 주소 등 반드시 수집해야 할 데이터 목록 (있으면)
• 재권유/재시도 제한: 권유 최대 횟수, 재확인 제한 등 (있으면)
• 운영 제약: 통화 중, 한 턴 한 질문 등 (있으면)
• {{...}} 변수: 원본 스크립트에 런타임 변수가 있으면 노드 멘트 안에 그대로 유지한다

사용자가 스크립트만 던지고 나머지를 생략하면, 스크립트에서 추론 가능한 것은 추론하고, 추론 불가능한 핵심 사항(수집 항목, 재시도 제한 등)만 짧게 질문한다. 질문은 최대 2개로 제한한다.

출력

마크다운 코드 스니펫(```md ... ```)으로 대화에 직접 출력한다. 파일은 만들지 않는다.

작업 절차

1단계: 스크립트 분석

원본 스크립트를 읽고 다음을 파악한다:

• 대화의 전체 목적 (세일즈/CS/예약/안내 등)
• 대화 흐름의 주요 분기점
• 각 구간에서 달성하려는 목적 (인사, 본인확인, 정보수집, 안내, 마무리 등)
• {{...}} 런타임 변수
• 재권유/재시도 제한이 있는 구간
• 예외 처리가 필요한 구간

2단계: 노드 쪼개기

스크립트를 노드 단위로 쪼갠다.

한 노드 = 고객에게 1가지 목적을 달성하는 최소 단위

쪼갤 때 판단 기준:

• “정보 수집 + 확인”이 한 덩어리면 하나의 노드 (요약 안내 + 확인 질문 포함)
• “선택지 제시 + 선택 결과에 따른 짧은 안내”가 밀접하면 하나의 노드
• 선택 결과에 따른 후속 흐름이 길면 별도 노드로 분리
• 응답 처리 항목이 7개 이상이면 노드가 너무 큰 것이므로 분리 검토
• 목적이 2개 이상이면 반드시 분리

3단계: 노드 작성

각 노드를 아래 고정 포맷으로 작성한다.

노드 출력 포맷

이 포맷은 고정이다. 섹션 이름과 최상위 구분은 아래 3개로만 출력한다:

• name
• content
• transition conditions

가독성 규칙(강제):

• content는 heading(###)ê³¼ ordered list(1. 2. 3.)를 적극 사용한다.
• depth는 최대 2까지만 허용한다(중첩 1단까지만). 3단 이상 중첩 금지.
• transition conditions는 depth 없이 1줄(또는 2문장)로만 쓴다. 중첩 리스트 금지.

## name
[노드 이름]

## content
### 목적
1. [단 하나의 목적]

### 진행 멘트
1. 기본 질문: "[예시 멘트]"
2. 응답 처리
   1. [상황 A] 시: "[예시 멘트]"
   2. [상황 B] 시: "[예시 멘트]"
   3. 애매 시 확정 질문 1회: "[예시 멘트]"
   4. 무응답 시 반복 1회: "[직전 질문 또는 직전 멘트 그대로]"
3. 예외/처리(필요 시만)
   1. [예외 상황]: "[예시 멘트]"
4. 유의(필요 시만)
   1. [재권유 제한/수집 순서 등]

## transition conditions
- [exit 상태 1]: 고객이 "[예시 발화]"처럼 [동의/의향]을 긍정으로 표현한 경우.
- [exit 상태 2]: 고객이 "[예시 발화]"라고 말했고, 조건A && 조건B를 만족한 경우.
- [exit 상태 3]: 고객이 "[예시 발화]"처럼 [거절/보류/오대상]을 확정한 경우.

작성 규칙

턴 운영 규칙

음성 대화에서 에이전트가 한 번에 너무 많이 말하면 고객이 끊거나, 중간에 끼어들어서 대화가 꼬인다.

• 한 턴에 한 질문 또는 한 확인만 한다.
• 기본 1~2문장. 예외적으로 3문장까지 허용하는 경우:
  • 신원확인 + AI 여부 + 통화 가능 여부를 한 번에 처리할 때
  • 동의 확정 시
  • 필수 정보 2개를 동시에 수집할 때 (서로 밀접한 경우만)
• 애매한 응답이 오면 같은 단계 안에서 확정 질문 1회만 한다.
• 무응답이면 직전 질문(또는 직전 요청 멘트)을 그대로 1회 반복한다.

전환조건 작성 규칙

전환조건은 LLM이 “이 노드에서 빠져나가도 되는지”를 판단하는 유일한 기준이다. 잘못 쓰면 너무 빨리 넘어가거나 빠져나오지 못한다.

원칙:

• 고객 발화 기반으로만 작성한다. 에이전트의 내부 상태나 추측이 아니라, 고객이 실제로 말한 것을 기준으로 판단한다.
• 각 노드의 exit 가능한 ê²°ê³¼ 상태를 2~5개로 정리한다. 대표적인 exit 상태: 성공 확정 / 대체 정보 확정 / 거절 확정 / 콜백·보류 확정 / 오대상 확정.
• 다음 단계 이름을 절대 쓰지 않는다. “다음은 결제 안내로 넘어간다” 같은 표현 금지. 오직 “이 노드를 exit하는 경우의 수”만 나열한다.
• 예/아니오(동의/확인)처럼 긍정 수락만 받으면 진행되는 노드는 전환조건을 유하게 쓴다. 고객이 “네”, “좋아요”, “알겠습니다” 같은 짧은 긍정 응답만 해도 exit 가능하도록 포함한다. 단, 선택/정보수집처럼 구체 값이 필요한 노드는 “네”만으로는 exit하지 않게 쓴다.
• 재권유/재시도 제한이 있으면 전환조건에 “아직 사용하지 않은 경우 / 이미 사용한 경우”를 포함한다(단, 중첩 없이 1~2문장으로 풀어쓴다).
• 형식 강제: transition conditions는 depth 없이 - 불릿만 사용한다(하위 불릿/번호/중첩 금지).
• 문장 길이: 각 조건은 1문장 또는 2문장으로 끝낸다.
• 논리 결합: “ì¡°ê±´A && ì¡°ê±´B 인 경우”처럼 한 줄에서 조건을 풀어쓰는 것은 허용한다(단, depth를 늘리지 않는다).

문장 형식은 아래 4가지 패턴으로 통일한다:

• “고객이 ‘네’, ‘좋아요’, ‘알겠습니다’처럼 긍정으로 수락하거나, …라고 명확히 말한 경우”
• “고객이 …라고 말한 뒤 …를 제공했고, …라고 확정한 경우”
• “고객이 …라고 확정 거절한 경우”
• “고객이 …라고 보류/콜백을 요청한 경우”

멘트 작성 규칙

• 예시 멘트는 반드시 큰따옴표(“”)로 감싼다.
• 표/마크다운 테이블/괄호 연출 금지. 일반 텍스트만 사용한다.
• 이모지/이모티콘/특수 장식 문자 사용 금지.
• {{...}} 런타임 변수가 원본 스크립트에 있으면 멘트 안에 그대로 유지한다.
• 음성으로 자연스럽게 들리는 한국어 존댓말(높임 공손: ~실까요, ~드릴까요)로 작성한다.
• TTS가 읽을 수 없는 특수문자(*, #, → 등)를 멘트 안에 넣지 않는다.

자가 점검

노드 작성이 끝나면 아래를 확인한다:

• 각 노드의 목적이 정확히 1개인가
• 전환조건에 “다음 단계 이름”이 들어가지 않았는가
• ## name / ## content / ## transition conditions 3개로만 출력했는가
• content의 리스트 depth가 2를 초과하지 않는가
• transition conditions가 중첩 없이 1~2문장으로만 작성됐는가
• 예시 멘트가 모두 큰따옴표로 감싸져 있는가
• 한 턴의 발화가 3문장을 초과하지 않는가
• 원본 스크립트의 {{...}} 변수가 빠지지 않았는가

적용 예시

아래는 “결제방법 안내” 구간의 스크립트를 노드로 변환한 결과다.

## name
결제방법 안내

## content
### 목적
1. 고객이 결제 방식(전액 또는 예약금)을 선택하도록 돕는다.

### 진행 멘트
1. 기본 질문: "결제방법 안내 도와드리겠습니다. 전액 결제와 예약금 결제 중 어떤 방식으로 안내 도와드릴까요?"
2. 응답 처리
   1. 전액결제 선택 시: "네, 전액 결제로 안내드릴게요. 퀵계좌이체, 간편결제, 신용 또는 체크카드, 해외간편결제 중 어떤 방식으로 진행 도와드릴까요?"
   2. 예약금결제 선택 시: "네, 예약금 결제로 안내드릴게요. 나중결제와 ARS결제 중 어떤 방식으로 안내 도와드릴까요?"
   3. 선택을 못 하는 경우 1차 전액결제 권유: "방송 중 안내된 결제 혜택은 전액 결제에서만 제공되고 있습니다. 전액 결제로 안내 도와드릴까요?"
   4. 전액이 부담스럽다고 하면 2차 예약금 권유: "네, 부담되실 수 있어요. 그럼 예약금 결제 안내로 도와드릴까요?"
   5. 예약금에서 나중결제 선택 시 안내: "네, 나중결제는 결제 링크를 삼십 분 이내로 문자로 보내드리겠습니다. 링크 받으시면 안내드린 시간 안에 결제 진행 부탁드릴게요."
   6. 예약금에서 ARS결제 선택 시 질문: "네, ARS 결제 진행을 위해 통신사부터 확인드릴게요. 사용하시는 통신사가 어디신가요?"
   7. 애매 시 확정 질문 1회: "정확히 확인드리려고요, 전액 결제와 예약금 결제 중 어느 쪽으로 안내 도와드릴까요?"
   8. 무응답 시 반복 1회: "[직전 질문 또는 직전 멘트 그대로]"
3. 예외/처리
   1. 고객이 "회원가입 해야 하나요"처럼 회원가입을 먼저 물으면: "네, 전액 결제는 회원가입 후 진행이 필요하고요, 예약금 결제도 예약금 결제 후 회원가입이 필요합니다. 원하시는 결제 방식부터 선택해주실까요?"
4. 유의
   1. 전액결제 권유는 1회, 예약금 전환 권유는 1회까지만 한다.
   2. 이 단계에서는 '선택'만 확정하고, 링크 발송/잔금 규정/마이페이지 안내는 다음 단계에서 짧게 한다.

## transition conditions
- 전액결제 선택 확정: 고객이 "전액으로 할게요" 또는 "전액 결제요"처럼 전액결제를 명확히 선택한 경우.
- 예약금결제 선택 확정: 고객이 "예약금으로 할게요" 또는 "예약금 결제요"처럼 예약금결제를 명확히 선택한 경우.
- 예약금 결제 수단 선택 확정: 고객이 "나중결제로 할게요" 또는 "ARS로 할게요"처럼 예약금 결제 수단을 명확히 선택한 경우.
- 권유 2회 이후 미선택 종료: 고객이 "결정 못하겠어요" 또는 "나중에 할게요"처럼 선택을 확정하지 않고 보류 의사를 명확히 표현한 경우.
- 강한 거절 종료: 고객이 "안 할게요" 또는 "필요 없어요"처럼 결제 진행 자체를 확정 거절한 경우.

vox.ai 연동 참고

이 스킬의 출력은 vox.ai 시스템 프롬프트의 # 대화 흐름 섹션 안에 들어가는 노드다. 전체 시스템 프롬프트의 다른 섹션(역할, 컨텍스트, 변수, 목표, 말투, 필러, 턴테이킹, 정규화, 도구, 가드레일, 에러 처리)은 이 스킬의 범위 밖이다. 필요하면 vox-best-practice 스킬을 별도로 사용한다.