[1주차] LLM 호출을 테스트하고 이해하기

1. 실습 목표와 구성

1) 개요

이번 실습의 목표는 LLM API를 직접 호출해보며 요청(Request)과 응답(Response)의 구조를 이해하고, structured output 방식의 필요성과 활용 방법을 익히는 것이다. 이를 위해 고객 문의 티켓 데이터를 기반으로 LLM을 활용한 정보 추출 과정을 수행한다.

 
2) 태스크(LLM이 수행해야 하는 구체적인 목적)

 입력 : 

• 고객 문의 티켓 텍스트 12건

출력 :

• 아래 JSON 스키마를 만족하는 구조화 결과

{
  "intent": "order_change | shipping_issue | payment_issue | refund_exchange | other",
  "urgency": "low | medium | high",
  "needs_clarification": true,
  "route_to": "order_ops | shipping_ops | billing_ops | returns_ops | human_support"
}

 

3) 스키마 정의
intent

• order_change: 주문 수정, 취소, 주소 변경, 옵션 변경
• shipping_issue : 출고, 배송 지연, 배송 누락, 배송 완료 오표시
• payment_issue : 결제 실패, 중복 결제, 청구 이상
• refund_exchange : 반품, 환불, 교환, 불량 접수
• other : 위로 단정하기 어렵거나 맥락이 부족한 경우

urgency

• low : 일반 문의, 즉시 장애 아님
• medium : 처리가 필요하지만 긴급 장애 / 금전 리스크는 아님
• high : 결제 이상, 분실 / 오배송, 고객 불만 고조, 수동 확인이 시급함

needs_clarification

• true : 현재 텍스트만으로 intent 또는 처리 방향을 단정하기 어려움
• false : 현재 정보만으로 1차 분류 가능

route_to

• order_ops : 주문 / 수정 담당
• shipping_ops : 배송 담당
• billing_ops : 결제 / 청구 담당
• returns_ops : 환불 / 교환 담당
• human_support : 맥락 부족, 다부서 이슈, 에스컬레이션 필요

 

4) 구현 요구 사항
 필수

1. SDK를 사용해 LLM을 직접 호출할 것
2. system 메시지와 user 메시지를 분리할 것
3. model, temperature, max_tokens 를 코드에 명시할 것
4. prompt v1, prompt v2 두 버전을 실험할 것
5. 응답을 JSON으로 파싱하고 코드에서 검증할 것
6. 12건 전체에 대해 결과를 저장할 것
7. v1과 v2의 결과를 비교한 짧은 리포트를 작성할 것
8. LLM API를 사용하여 Python으로 코드 만들어서 진행 할 것

 

---

2. 실습 진행

 

1. 사용한 모델, SDK, 실행 환경

• SDK : google-genai Python SDK
  • https://aistudio.google.com/api-keys
• Language : Python 3.12.13
• 실행 환경 : local macOS terminal (venv -> 가상화를 통해 격리화) 

2. 실제 요청 구조 설명 

• Model : gemini-3-flash-preview
• temperature : 0
  • 출력 랜덤성 정도 0은 가장 최소화 특히 이번 실습에서는 창의성보다 일관성이 중요하니까 0이 좋음
• max_output_token : 256 
  
  • 모델이 생성할 최대 출력 길이 제한, 단위는 토큰 1토큰은 대략 0.75 단어 (영어 기준) 해당 기준으로 api 비용 청구 됨
• v1, v2 system 메시지 : 페르소나와 메타인지, MoE 방식으로 진행
  • 페르소나와 메타인지, MoE 관련 내용은 아래 주소
    • https://roboco.io/posts/persona-vs-metacognition/

v1 (system 메시지)

 
v2 (system 메시지)

 

• Pydnatic 사용
  • 파이썬에서 데이터 구조를 정의하고 자동 검증해주는 라이브러리

 
 

3. 실제 응답 구조
 
v1과 v2의 12개 데이터셋 테스트 결과가 다음과 같은 형태로 나옴 
 
예시) 

 
 

4. v1 에서 v2로 바뀐점
 

개요 :
v1 프롬프트는 일부 판단 기준이 명확하지 않아 모델이 항목을 추론에 의존해야 했다. 
v2 에서는 모호함을 줄이기 위해 규칙을 추가하고, 일부 필드는 추론이 아니라 고정 매핑 방식으로 바꾸었다.
 
1. urgency 규칙 추가
 
v1

• urgency 판단 기준이 없음
• 따라서 모델이 문맥만 보고 urgency를 임의로 결정해야 함

v2

• intent별 urgency 기준을 일부 명시함
• order_change -> medium
• payment_issue -> high

2. route_to를 추론에서 매핑으로 변경
 
v1

• 모델이 intent를 보고 적절한 route_to를 추론해야 했음
• 즉, intent와 route_to의 관계가 프롬프트에 간접적으로 드러남

v2

• intent와 route_to 관계를 더 명확하게 매핑 형태로 제시함
• order_change -> order_ops
• payment_issue -> billing_ops

 
3. needs_clarification 기준 명시
 
v1

• 언제 needs_clarification = true 로 처리해야 하는지 기준이 없음
• 모델이 애매한 상황을 일관되게 처리하기 어려움

v2

• clarification이 필요한 대표 상황을 명시
• 환불인지 교환인지 불명확한 경우 -> true
• 주문 문제인지 결제 문제인지 불명확한 경우 -> true

정리 :
 
v2의 핵심은 모델이 자유롭게 추론하던 부분을 줄이고, 명시적인 규칙과 매핑을 추가해 출력의 일관성과 정확도를 높인 것이다.
 
 

5. 결과 비교
 

v1

 

v2

1.  

 
비교 요약

• 파싱 성공률 : v1 66.7% -> v2 100.0%
• exact match : v1 6개 -> v2 9개

 

6. 상세 코드
 

테스트 깃허브 주소

https://github.com/jasonpark112/aiagent-repo/tree/jasonpark112/week-1/jasonpark112

aiagent-repo/week-1/jasonpark112 at jasonpark112 · jasonpark112/aiagent-repo

 

 

---

3. LLM 동작 원리와 비용을 줄이는 법

https://platform.claude.com/docs/en/build-with-claude/context-windows?ref=blog.aibox.today

 

LLM 동작 원리

1. 이전 대화 + 현재 입력을 모두 LLM에 넣음
2. 그걸 기반으로 응답 생성
3. LLM은 이를 기억하지 않아서 매번 시스템에서 이전 입력을 저장해뒀다가 입력값과 전부 다시 넣어줌

이러한 LLM 동작 원리 문제점

• 대화 길어질수록 토큰 증가
• 컨텍스트 제한 존재

해결

• 이를 해결하기 위해 구조화 (Structured Output)이 필요하다.
• 구조화를 통해
  • 불필요한 토큰 감소
  • 중복 정보 제거
  • 불안정한 응답 제거

결론
 

LLM은 기억이 아니라 입력 누적으로 동작하기 때문에, 이전 대화를 계속 포함할수록 토큰이 증가하고 컨텍스트 한계에 도달하게 된다.

이를 해결하기 위해 구조화(Structured Output)를 활용하여 대화를 상태(state)로 압축하고, 불필요한 토큰을 제거하며 핵심 정보만 유지하는 것이 중요하다.

이를 통해 토큰 사용량을 줄이고, 응답의 일관성과 안정성을 확보할 수 있다.

또한, 판단 기준을 명확히 정의한 구조화된 출력은 모델의 정확도를 높이고, 프롬프트를 효율적으로 관리할 수 있게 해준다.

결과적으로 비용(토큰)과 응답 시간 모두를 최적화할 수 있다.