LLM API를 서비스에 넣을 때는 단순히 API 호출만 보면 안 됩니다. 응답 지연 시간, token 비용, rate limit, 장애 대응, prompt injection, 개인정보와 내부 데이터 유출 위험을 고려해야 합니다.
또 LLM 응답은 비결정적일 수 있으므로 품질 평가와 logging, guardrail, fallback UX가 필요합니다. 긴 작업은 streaming이나 background job으로 처리하고, cache 가능한 요청은 cache로 비용과 latency를 줄일 수 있습니다.
꼬리질문
조금 더 깊게 물어본다면
답변 뒤에 이어질 수 있는 질문들을 하나씩 열어볼 수 있어요.
Prompt injection은 무엇인가요?
사용자 입력이 시스템 지시를 우회하거나 모델이 숨겨진 정보나 잘못된 행동을 하도록 유도하는 공격입니다.
LLM API 응답을 검증해야 하는 이유는?
LLM 응답은 비결정적이고 형식이 보장되지 않습니다. 기대한 JSON 구조가 아닐 수 있고, 요청과 무관한 내용이 포함되거나, 서비스 정책에 맞지 않는 내용이 출력될 수 있습니다. 응답을 그대로 사용하면 파싱 오류나 보안 문제로 이어질 수 있어 schema 검증과 content filtering이 필요합니다.
민감한 데이터를 LLM API에 보낼 때 주의사항은?
사용자 개인정보, 내부 시스템 구조, 인증 정보 같은 민감한 데이터가 prompt에 포함되면 외부 API 공급자에게 전송됩니다. 데이터 처리 정책, 학습 데이터 사용 여부를 확인하고, 최소한의 정보만 전달하도록 익명화하거나 마스킹해야 합니다.
LLM API 비용을 줄이는 방법은?
짧은 prompt, 필요한 context만 제공, cache, model tier 선택, batch/background 처리, 재시도 정책 최적화가 있습니다.
LLM 응답 품질은 어떻게 평가하나요?
정답이 있는 작업은 benchmark와 regression set을 만들고, 주관적 작업은 rubric과 human review, sampling evaluation을 함께 사용할 수 있습니다.
토큰(token)이란 무엇인가요?
LLM이 텍스트를 처리하는 단위입니다. 단어나 음절 단위로 나뉘며, 영어는 대략 단어 하나가 1-2토큰, 한국어는 조금 더 많이 소모됩니다. 입력과 출력 토큰 수에 따라 API 비용이 결정되고, 모델마다 처리할 수 있는 최대 context window 크기도 토큰 수로 제한됩니다.
LLM API 장애가 나면 어떻게 대응하나요?
timeout, retry, fallback model, degrade UX, queue 기반 재처리 같은 전략을 준비해야 합니다. 무한 재시도는 비용과 장애를 키울 수 있습니다.
Fallback 전략은 어떻게 설계하나요?
주 모델 호출이 실패하면 더 작은 모델이나 다른 provider로 전환하거나, 캐시된 이전 응답을 반환하거나, 기능 자체를 비활성화하는 graceful degradation을 적용합니다. 중요도가 낮은 기능은 LLM 없이도 동작하는 대체 흐름을 미리 만들어두면 전체 서비스 영향을 최소화할 수 있습니다.
부가 설명
서비스 기능이라면 “좋아 보이는 답변”이 아니라 실패했을 때 어떤 UX와 안전장치를 둘지까지 설계해야 합니다.
입력/출력 validation, moderation, user data retention 정책, observability도 중요합니다.
한 줄 정리
LLM API 통합은 latency, 비용, rate limit, prompt/data 보안, 품질 평가, fallback을 함께 고려해야 합니다.