APICK 멀티챗으로 상품 상담 만들기: 대화 기록과 비용 관리

확인일: 2026-10-11 · 공식 공개 문서 기반 · 아래 코드는 실행하지 않은 연동 예제입니다. 실제 키·고객 데이터는 포함하지 않았습니다.
이전 답변을 바탕으로 다시 질문하는 상품 도우미
사용자가 “가벼운 우산을 찾고 있어요”라고 말한 뒤 “그중 접었을 때 작은 제품은요?”라고 묻는다면 첫 질문과 첫 답변이 다음 요청에 들어가야 합니다. APICK 멀티챗을 붙일 때 중요한 일은 우리 서비스가 각 사용자의 대화 상태를 일관되게 관리하는 것입니다.
대화 저장의 책임과 응답 처리
APICK 멀티챗 문서는 서버가 대화 히스토리를 보관하지 않는 stateless 계약을 설명합니다. 앱은 messages 배열을 보내고, 응답의 data.compacted_messages로 다음 턴의 히스토리를 통째 교체합니다. 이전 배열에 assistant 답변을 다시 덧붙이면 중복 문맥이 생길 수 있습니다. 멀티챗 가이드
curl --fail-with-body --request POST https://apick.app/rest/llm/chat \
--header "Authorization: Bearer $APICK_API_KEY" \
--form-string "model=$APICK_MODEL" \
--form-string 'messages[0][role]=user' \
--form-string 'messages[0][content]=가벼운 접이식 우산을 고를 때 무엇을 봐야 하나요?' \
--form-string 'compact[strategy]=sliding_window' \
--form-string 'compact[window_pairs]=5'
서버 코드: 사용자별 저장소에 연결할 최소 함수
// 호출자가 해당 사용자만의 history를 전달합니다. 공유 전역 배열을 쓰지 않습니다.
async function nextTurn(history, question) {
const messages = [...history, { role: 'user', content: question }];
const form = new FormData();
form.append('model', process.env.APICK_MODEL);
form.append('compact[strategy]', 'sliding_window');
form.append('compact[window_pairs]', '5');
messages.forEach((message, i) => {
form.append(`messages[${i}][role]`, message.role);
form.append(`messages[${i}][content]`, message.content);
});
const r = await fetch('https://apick.app/rest/llm/chat', {
method: 'POST', headers: { Authorization: `Bearer ${process.env.APICK_API_KEY}` },
body: form, signal: AbortSignal.timeout(120000)
});
const result = await r.json();
if (!r.ok || result.error || result.data?.error || result.api?.success === false) {
throw new Error('대화 요청을 확인하세요.');
}
if (!Array.isArray(result.data?.compacted_messages)) {
throw new Error('다음 대화 기록 형식을 확인하세요.');
}
return { history: result.data.compacted_messages, response: result };
}
짧은 히스토리와 중요한 사용자 조건을 나누기
sliding_window의 window_pairs는 남길 대화쌍 수입니다. 예제의 5는 이 글의 설계 선택이며 모든 서비스의 최적값은 아닙니다. 우산 무게처럼 다음 답변에도 필요한 조건이 잘리는지 테스트하세요. 오래된 원문 전체를 계속 전송하는 대신 앱에서 승인된 선호 조건을 별도 데이터로 관리하고, 필요한 조건만 다음 질문에 함께 넣는 방식을 검토할 수 있습니다.
제품 재고·가격·반품 정책은 대화 내용만으로 확정하지 마세요. 백엔드에서 현재 값을 확인하고 답변에 근거를 제공하는 구조가 필요합니다. 모델의 “구매가 완료됐다”는 텍스트를 주문 완료 신호로 취급해서도 안 됩니다. 주문 처리 결과는 주문 시스템이 반환한 상태로 판단합니다.
비용을 관찰하는 방법
입력 히스토리를 매 턴 다시 보내므로 첫 질문보다 후속 질문의 입력량이 커질 수 있습니다. 과금은 선택 모델의 토큰 요금을 따릅니다. 5턴과 20턴 테스트에서 요청당 입력량·출력량·포인트를 비교해 대화 창의 크기를 결정하세요. 공식 문서의 2026-11-06 기본요금 5P 시행일도 배포 시점에 다시 확인합니다. 모델별 요금표
자주 묻는 질문
새로고침해도 대화가 유지되나요? 앱이 인증된 사용자별 저장소에 보관해야 합니다. 동시에 두 질문을 보낼 수 있나요? 같은 대화에서는 요청 순서를 직렬화하거나 버전 번호로 오래된 응답의 덮어쓰기를 막는 편이 안전합니다. 브라우저에 키를 넣어도 되나요? 키는 서버에 두고 브라우저는 자체 백엔드만 호출하게 구성하세요.
댓글
댓글 쓰기