Jev는 자료와 질문을 보내고 구조화된 판단을 받는 방식으로 사용합니다. Playground에서 질문을 시험한 뒤 API로 업무 프로그램과 연결할 수 있습니다.
처음에는 결과를 추천으로만 사용하고 사람이 내린 판단과 비교하세요. 오분류율과 검토 비율을 확인한 뒤 자동 처리 범위를 정하는 편이 좋습니다.
어디에서 시작하면 되나요?
안녕하세요! AI를 업무에 연결하는 방법을 소개하는 OCstory입니다. 이번에는 Jev로 고객 문의를 분류하는 과정을 살펴보겠습니다. 처음부터 여러 업무를 연결하기보다 자주 반복하는 판단 하나를 고르는 편이 좋습니다.
1. Playground에 자료와 질문 입력
공식 콘솔의 Playground에서 로그인한 뒤 state에 텍스트를 넣고 질문을 추가합니다. 예를 들어 오늘 결제했는데 유료 기능이 활성화되지 않았다는 문의를 넣어보세요. 담당 부서와 긴급성은 각각 질문합니다. 출처: 공식 Quick start
2. 질문 하나에 판단 하나
어떻게 처리할까라는 질문에는 부서 배정과 보상 여부가 섞입니다. 우선 담당 부서만 물으면 답이 잘못됐을 때 선택지와 질문 중 어디를 수정할지 찾기 쉽습니다.
API는 어떻게 연결하나요?
1. 요청 주소와 인증 설정
요청 주소는 POST https://api.typesafe.ai/v1/systemone입니다. Authorization 헤더에는 Bearer 방식의 API 키를 넣습니다. 요청 본문은 state와 model 및 questions로 구성합니다. 계정에서 사용할 수 있는 모델은 GET /v1/models로 확인합니다. 출처: 공식 API 명세
API 키는 서버의 환경 변수나 비밀 저장소에서 관리합니다. 공개된 블로그 HTML이나 브라우저 코드에 넣으면 방문자가 키를 읽을 수 있습니다.
2. 문의 분류용 요청 만들기
문의 분류용 Choice에는 billing과 technical 및 review 같은 선택지를 둘 수 있습니다. billing에는 결제와 구독 문제를 정의합니다. technical에는 결제와 무관한 기능 오류를 넣고 review에는 정보 부족이나 분류 불가 사례를 배정합니다.
{
"model": "jev-latest",
"state": "오늘 결제했는데 유료 기능이 활성화되지 않았습니다.",
"questions": {
"team": {
"type": "choice",
"instructions": "문의의 주된 목적에 따라 담당 부서를 고르세요.",
"criteria": {
"billing": "결제, 청구, 구독 활성화 문제",
"technical": "결제와 무관한 기능 오류나 접속 문제",
"review": "정보가 부족하거나 어느 기준에도 맞지 않는 문의"
}
}
}
}응답의 answers.team에서 선택 결과와 확률 및 confidence를 확인합니다. 위 JSON은 공식 형식에 맞춘 요청 예시이며 실제 호출 결과는 아닙니다. 출처: 공식 요청·응답 예시
3. 추천부터 시작해 자동 배정으로 확대
처음에는 담당 부서를 추천하는 데만 사용하세요. API 호출이 실패하거나 결과가 없으면 검토 대기열로 보내도록 구성합니다. 분류 결과를 받았다는 이유만으로 환불이나 계정 변경까지 실행할 필요는 없습니다.
어떤 업무에 활용할 수 있나요?
1. 고객 문의 분류
고객 지원에서는 담당 부서와 긴급성을 따로 판단합니다. 다만 긴급하다는 이유로 환불 자격까지 인정해서는 안 됩니다. 환불은 실제 거래 기록과 정책을 확인한 뒤 처리합니다.
2. 블로그 초안 점검
블로그에서는 초안에 가격이나 날짜 주장이 있는지 분류할 수 있습니다. 단정적인 표현이나 광고성 문구도 검토 항목으로 만들 수 있습니다. 다만 출처 링크가 있다는 사실만으로 내용이 검증되지는 않습니다. 실제 팩트체크에는 원문과의 대조가 필요합니다.
3. 요청별 처리 경로 선택
업무 시스템에서는 요청을 고정 안내문으로 처리할지 검색으로 넘길지 분류하는 데 쓸 수 있습니다. 하지만 분류 단계 자체에도 시간과 비용이 듭니다. 단순한 조건은 코드로 처리하고 자연어 판단이 필요한 부분에 모델을 배치하세요.
자동화 전에 무엇을 점검해야 하나요?
1. 선택지의 경계와 시험 자료
선택지의 범위가 겹치면 결과가 애매해집니다. 계정 문제와 기술 문제처럼 경계가 흐린 항목에는 포함 사례와 제외 사례를 적어두세요. 분류할 수 없는 입력을 처리할 경로도 마련합니다.
시험 자료에는 오타와 짧은 문장도 넣습니다. 여러 요구가 섞인 문의도 포함하세요. 질문을 고칠 때 쓴 자료와 최종 평가 자료는 나누는 편이 좋습니다.
2. 자동 처리 기준과 운영 기록
confidence의 임계값은 실제 데이터로 정합니다. 처음에는 추천 결과와 사람의 판단을 비교하세요. 오분류율과 검토 비율을 측정하고 처리 시간과 비용도 함께 기록합니다. 자동 처리 비율만 높이면 오류가 늘어날 수 있습니다.
응답의 모델 이름과 질문 버전을 기록하면 결과가 달라진 원인을 추적하기 쉽습니다. 시간 초과나 호출 실패도 정상적인 판단 결과와 구분해야 합니다.
자주 묻는 질문 (FAQ)
코딩을 몰라도 시험할 수 있나요?
공식 Playground에서 자료와 질문을 입력해 시험할 수 있습니다. 업무 시스템과의 연결에는 API 연동이 필요합니다.
한국어 문의를 바로 자동 처리해도 되나요?
실제 한국어 자료로 평가한 뒤 적용 범위를 정하세요. 업종별 용어와 오타가 섞인 문의를 포함해야 합니다.
높은 confidence만 보고 실행해도 되나요?
confidence는 실행 권한이나 정책 적합성을 보증하지 않습니다. 분류 결과와 별개로 실제 행동의 허용 조건을 검사해야 합니다.
자료 확인 기준: 2026년 10월 9일.