지난달에 갓 전환 배치된 동료와 함께 스마트 고객서비스 프로토타입을 만들었는데, 요구사항은 아주 간단했습니다. 사용자가 질문하면 모델이 답변하고, 약간의 컨텍스트 기억이 있고, 스트리밍 타이핑이 되는 것. 이틀이면 끝낼 것 같았는데, 결과적으로 그는 API Key 하드코딩, 재시도 로직, 스트리밍 연동에서 각각 한 번씩 함정을 밟았습니다. 전체 과정을 정리해서 이 글을 씁니다. 신입 교육 노트로 봐주세요.
첫 번째 단계: 먼저 요구사항을 분해하고, 그다음 모델을 선택하라
시작부터 코드를 작성하지 마세요. 스마트 고객서비스의 역량 요구사항은 대략 세 가지로 나뉩니다. 의도 인식, 지식 Q&A, 멀티턴 잡담. 의도 인식은 빠르고 저렴해야 하므로 DeepSeek-V3나 Qwen API면 충분합니다. 지식 Q&A는 사내 문서가 관련되므로 RAG를 거쳐야 하고, 모델은 긴 컨텍스트 이해가 요구됩니다. 멀티턴 잡담은 어조 요구가 높아서 Claude 4 Sonnet이나 GPT-4o가 더 안정적입니다.
제 방식은 먼저 범용 모델 하나로 전체 파이프라인을 돌려보고, 그다음 항목별로 교체하는 것입니다. SiCore TokenWorks의 멀티 모델 라우팅이 이때 편리한데, 동일한 코드에서 모델 이름만 바꾸면 효과를 비교할 수 있고 인증을 수정할 필요가 없습니다. 대규모 언어 모델 API 선택은 가장 강력한 것을 고르는 게 아니라, 과업에 가장 적합한 것을 고르는 것입니다.
두 번째 단계: Key 관리, 코드에 작성하지 마라
Key를 소스코드에 하드코딩하는 것은 신입에게 가장 흔한 실수입니다. 일단 git에 커밋되면 공개된 것과 같습니다. 올바른 방법은 환경 변수와 설정 파일을 계층화하는 것입니다. 로컬은 .env를 쓰고, 테스트와 프로덕션은 설정 센터나 키 관리 서비스를 씁니다.
다중 환경 격리에서 기억해야 할 세 가지: 개발, 테스트, 프로덕션은 서로 다른 Key를 사용한다; 각 Key에 독립적인 할당량 상한을 설정한다; 프로덕션 Key는 서버에만 주고 프론트엔드는 절대 가질 수 없다. 우리 프로젝트에서는 SiCore TokenWorks를 사용하는데, Key 하나로 GPT-4o, Claude, DeepSeek, Qwen, ERNIE, Doubao 등 주요 모델을 호출할 수 있어 여러 인증 체계를 유지보수하는 번거로움이 사라지고, 다중 환경 Key 전환도 변수 하나만 바꾸면 됩니다.
세 번째 단계: 호출 캡슐화와 오류 재시도
SDK를 그대로 호출하는 코드는 유지보수가 불가능합니다. 한 겹 감싸서 타임아웃, 속도 제한, 재시도를 통일적으로 처리하세요.思路은 이렇습니다. 모델 호출을 하나의 함수로 감싸고, 파라미터는 messages와 모델 이름이며, 내부에서 세 가지 오류를 잡습니다. 네트워크 타임아웃, 429 속도 제한, 5xx 서버 오류.
재시도 전략은 지수 백오프를 사용해서 첫 번째는 1초, 두 번째는 2초, 세 번째는 4초 기다리고 최대 세 번입니다. 429는 특별히 처리해야 하는데, 반환된 retry-after 헤더를 봐야 합니다. 모든 오류에 재시도하지 마세요. 파라미터 오류는 백 번 재시도해도 소용없습니다. 모델 게이트웨이의 가치가 바로 이 계층에 있습니다. 재시도, 폴백, 로그를 한곳에 모으고 비즈니스 코드는 결과만 받으면 됩니다.
함정 알림: 재시도는 멱등해야 합니다. 호출에 부작용이 있다면(예: 데이터베이스 쓰기), 재시도 전에 이전 호출이 정말 실패했는지 먼저 확인하세요.
네 번째 단계: 스트리밍 출력과 프론트엔드 연동
고객서비스 경험의 핵심은 "타자기 효과"입니다. 서버는 SSE로 token을 조각조각 프론트엔드에 밀어주고, 프론트엔드는 EventSource나 fetch의 ReadableStream으로 받습니다.
백엔드 핵심 포인트: stream=True를 설정하고, 반환된 delta를 조각별로 파싱하며, [DONE]을 만나면 종료합니다. 프론트엔드 핵심 포인트: 문자 하나 받을 때마다 setState하지 마세요. 20~50밀리초를 모아서 배치 렌더링해야 합니다. 그렇지 않으면 페이지가 슬라이드처럼 버벅입니다.
또 하나의 함정은 스트리밍 도중 사용자가 페이지를 닫을 수 있다는 것입니다. 서버는 연결 끊김 이벤트를 감지해서 상위 요청을 즉시 취소해야 합니다. 그렇지 않으면 token을 헛되이 태웁니다. 종량제 과금에서는 이런 낭비가 쌓이고 쌓입니다.
다섯 번째 단계: 비용 모니터링과 알림
출시 전에 반드시 계측을 심어야 합니다. 매 호출마다 기록하세요: 모델 이름, 입력 token 수, 출력 token 수, 소요 시간, 재시도 여부. 이 데이터를 일주일 모으면 돈이 어디에 쓰이는지 알게 됩니다.
알림은 두 개의 선을 설정하세요: 일일 비용이 임계값을 초과하면 경보, 단일 호출 token이 비정상이면 경보. 한번은 어떤 사용자가 문서 전체를 붙여넣어서 단일 입력이 수만 token이 된 적이 있었는데, 알림이 없었다면 월말 청구서가 보기 안 좋았을 겁니다.
비용 절약 경험: 의도 인식처럼 고빈도 저난이도 과업은 저렴한 국산 모델로 전환하면 비용이 한 단계 줄어듭니다. 대량 구매에 그린 에너지 스케줄링을 더하는 것이 SiCore TokenWorks 같은 집계 플랫폼의 가격이 공식 직접 구매보다 낮은 이유이며, 우리가 비교해보니 고빈도 호출 시나리오에서 차이가 확연했습니다.
한마디로 요약하면: 스마트 고객서비스 프로토타입의 어려움은 모델이 아니라 엔지니어링 세부사항에 있습니다. Key를 잘 관리하고, 재시도를 올바르게 작성하고, 스트리밍을 안정적으로 연결하고, 비용을 주시하면, 남은 것은 prompt 조정뿐입니다. 다중 모델 통합 연동과 모델 라우팅 구현을 더 깊이 알고 싶다면, 대규모 언어 모델 API 게이트웨이라는 라인을 따라 계속 읽어보세요.