[AI Agent] 2기 1주차: LLM 구성과 출력 제어
AI Agent 2기 1주차 수업 자료입니다. 토큰과 Context window, LLM의 생성 흐름, API 요청과 생성 설정, 구조화 출력과 검증을 이커머스 CS 분류 사례로 살펴봅니다.
1. 개요
이번 주차의 목표는 LLM 구성 요소를 간단하게 이해하고 의도한 대로 호출하는지 확인하는 것입니다.
모델을 호출하기 위한 구성 요소와 간단한 모델 아키텍처를 살펴봅니다.
- 모델에 대한 자세한 내용은 모델 튜닝과 서빙 과정에서 다루겠습니다.
2. LLM 구성과 출력 제어
이커머스 고객센터에 다음 문의가 들어왔다고 가정해보겠습니다.
주문한 신발의 배송지를 바꾸고 싶어요.
사람은 이 문장을 읽고 주문 변경 요청이라고 판단합니다.
하지만 LLM은 문장을 사람처럼 통째로 읽지 않습니다.
입력을 토큰으로 나누고 지금까지 주어진 문맥에서 다음에 올 토큰을 하나씩 생성합니다.
고객 문의가 분류 결과로 바뀌는 사이에는 여러 단계가 있습니다.
- tokenizer가 텍스트를 토큰으로 바꾸고 모델이 문맥을 처리합니다.
- 생성 설정값이 다음 토큰 후보 선택에 관여하고 출력 형식이 결과를 코드가 읽을 수 있는 형태로 만듭니다.
더 자세히 들어가 보겠습니다.
2.1 LLM의 역할
LLM은 Large Language Model의 약자입니다.
많은 텍스트와 코드에서 언어 패턴을 학습하고 입력 문맥에 이어질 토큰의 확률을 계산하는 언어 모델입니다.
여기서 모델은 문서를 그대로 저장해두고 검색하는 데이터베이스와 다릅니다. 학습 과정에서 언어의 관계와 패턴이 모델의 파라미터에 반영되고 추론할 때는 이 파라미터와 현재 입력을 사용해 응답을 만듭니다.
전통적인 규칙 프로그램과도 차이가 있습니다.
| 구분 | 규칙 프로그램 | LLM |
|---|---|---|
| 판단 기준 | 개발자가 조건을 코드로 작성 | 학습한 패턴과 입력 문맥으로 판단 |
| 장점 | 같은 조건에서 결과가 명확함 | 다양한 표현과 모호한 문장을 다루기 쉬움 |
| 한계 | 표현이 달라질 때 규칙이 늘어남 | 출력이 확률적이며 의미 오류가 생길 수 있음 |
주문 취소라는 표현만 찾는 규칙은 “이거 안 살래요” 같은 문장을 놓칠 수 있습니다. LLM은 표현이 달라도 비슷한 의도를 분류할 수 있지만 그 결과가 항상 옳다고 보장되지는 않습니다.
같은 모델이 분류, 요약, 번역, 답변 생성에 쓰이는 이유도 여기에 있습니다. 작업마다 별도의 프로그램이 모델 안에 들어 있는 것이 아닙니다.
지시와 입력 문맥이 달라지면 같은 다음 토큰 생성 방식으로 다른 형태의 결과를 만듭니다.
이제 LLM의 구성 요소와 특징을 살펴보겠습니다.
2.1.1 학습과 추론
LLM을 이해하려면 학습과 추론을 구분해야 합니다.
- 학습과 추론은 AI를 설명할 때 자주 쓰는 용어입니다.
| 구분 | 학습 | 추론 |
|---|---|---|
| 입력 | 대규모 학습 데이터 | 현재 요청의 지시와 데이터 |
| 처리 | 오차를 줄이도록 파라미터 조정 | 학습된 파라미터로 다음 토큰 계산 |
| 결과 | 학습된 모델 | 요청에 대한 응답 |
| 시점 | 모델을 만드는 과정 | API를 호출할 때마다 실행 |
일반적인 LLM API 호출은 추론입니다. 고객 문의 한 건을 보냈다고 해서 모델이 그 자리에서 다시 학습되는 것은 아닙니다. 모델은 이미 학습된 파라미터와 요청에 포함된 문맥으로 응답을 생성합니다.
2.2 입력에서 출력까지
LLM은 다음 흐름으로 텍스트를 받아 응답을 만듭니다.
텍스트 입력
→ tokenizer가 토큰으로 분할
→ 토큰을 수치 표현으로 변환
→ 모델이 입력 문맥을 처리
→ 다음 토큰의 확률 분포 계산
→ 생성 설정값에 따라 토큰 선택
→ 선택한 토큰을 문맥에 추가
→ 종료 조건까지 반복
→ 토큰을 텍스트로 변환현재 널리 쓰이는 생성형 LLM은 대부분 Transformer 계열 구조를 사용합니다.
Transformer의 Attention은 입력 문맥 안에서 토큰 사이의 관계를 계산합니다. 예를 들어 배송지 변경 문의를 처리할 때 배송지, 바꾸고, 싶어요가 어떤 관계인지 문맥 안에서 반영합니다.
Attention이 곧 정답을 찾는 장치는 아닙니다. 모델이 문맥을 처리하는 내부 계산의 일부입니다. 여기서는 수식보다 입력 문맥을 처리해 다음 토큰의 분포를 만든다는 흐름만 살펴봅니다.
2.3 토큰과 Context Window
LLM은 문장을 그대로 읽고 쓰지 않습니다.
텍스트를 tokenizer가 처리할 수 있는 토큰 단위로 바꿉니다.
토큰은 단어와 일치하지 않습니다. 한 단어가 여러 토큰으로 나뉠 수도 있고 짧은 표현이 하나의 토큰이 될 수도 있습니다. 같은 문장이라도 모델과 tokenizer가 다르면 토큰 수와 분할 결과가 달라집니다.
그래서 “한국어는 항상 영어보다 몇 배 많은 토큰을 사용한다”처럼 고정된 비율로 계산하면 안 됩니다. 토큰 수는 사용할 모델의 tokenizer나 API 응답에 기록된 사용량으로 확인해야 합니다.
토큰은 서비스의 세 가지 조건과 연결됩니다.
- 입력 범위: 한 요청에 넣을 수 있는 지시, 사용자 입력, 대화 기록의 크기
- 출력 범위: 모델이 한 응답에서 생성할 수 있는 크기
- 사용량: 모델과 제공자에 따라 비용과 처리 시간에 영향을 주는 단위
Context window는 모델이 한 요청에서 참고할 수 있는 전체 문맥의 범위입니다.
지시, 사용자 입력, 이전 대화와 Tool 결과 등 무엇이 포함되는지는 API마다 다릅니다. 입력 토큰, 출력 토큰, reasoning token이 한도를 사용하는 방식도 모델의 공식 문서에서 따로 확인해야 합니다.
Context window와 출력 토큰 한도는 같은 개념이 아닙니다.
Context window가 모델이 참고할 수 있는 전체 범위라면 출력 토큰 한도는 이번 응답에 허용할 최대 생성량입니다.
2.4 Autoregressive 생성
LLM은 완성된 답변을 한 번에 꺼내지 않습니다.
현재까지 주어진 입력과 이미 생성한 내용을 바탕으로 다음 토큰의 후보를 계산하고 하나를 선택합니다. 이 과정을 응답이 끝날 때까지 반복합니다.
입력 문맥
→ 다음 토큰의 확률 분포 계산
→ 토큰 하나 선택
→ 선택한 토큰을 문맥에 추가
→ 다음 토큰의 확률 분포를 다시 계산
→ 종료 조건까지 반복이 생성 방식 때문에 앞에서 만든 내용이 뒤의 생성에 계속 영향을 줍니다. 초반에 문의 의도를 잘못 잡으면 뒤에 생성하는 urgency나 route_to도 그 판단을 따라갈 수 있습니다.
서비스에서는 이런 성질을 확인합니다.
- 같은 입력에도 출력이 달라질 수 있습니다.
- 자연스러운 문장이 사실이나 업무 규칙의 정확성을 보장하지 않습니다.
- 출력이 길어지면 생성 단계가 늘어나 지연과 사용량이 증가할 수 있습니다.
- 출력 한도에 도달하면 문장이나 JSON이 중간에 끊길 수 있습니다.
LLM은 입력 문맥을 참고해 다음 토큰을 반복적으로 생성합니다. 서비스는 이 결과를 바로 정답으로 취급하지 않습니다. 형식과 의미를 따로 검증해야 합니다.
2.5 API 요청과 응답
LLM API는 애플리케이션이 모델에 추론을 요청하는 접점입니다.
제공자마다 이름과 형식은 다르지만 요청은 대체로 다음 요소로 구성됩니다.
| 구성 | 역할 | CS 분류 사례 |
|---|---|---|
| 모델 | 사용할 모델과 기능 선택 | 분류와 구조화 출력을 지원하는 모델 |
| 지시 | 수행할 작업과 판단 기준 전달 | 문의 유형과 분류 기준 |
| 입력 | 이번 요청에서 처리할 데이터 | 고객 문의 한 건 |
| 출력 형식 | 응답의 필드와 자료형 정의 | intent, urgency, needs_clarification, route_to |
| 생성 설정값 | 토큰 선택과 출력 범위 조정 | temperature, top-p, 출력 토큰 한도 |
개념적인 호출 구조입니다.
response = llm.generate(
model=selected_model,
instructions=classification_rules,
input=customer_message,
output_schema=ticket_schema,
generation_limit=output_budget,
)이 코드는 특정 SDK의 사용법이 아니라 요청을 구성하는 요소를 보여주기 위한 예시입니다. 실제 필드명과 지원 기능은 사용하는 API와 모델의 공식 문서에서 확인해야 합니다.
2.5.1 지시와 사용자 입력
서비스 규칙과 사용자가 보낸 데이터는 분리해서 관리하는 편이 좋습니다.
반복되는 분류 기준은 지시에 두고 매번 달라지는 문의 내용은 사용자 입력으로 전달합니다. 이렇게 나누면 같은 규칙으로 여러 문의를 테스트하거나 지시의 버전을 따로 기록하기 쉽습니다.
역할 메시지는 지시의 우선순위를 모델에 전달합니다.
다만 system이나 developer 역할을 사용했다고 보안 경계가 생기는 것은 아닙니다. 권한 검사와 입력 검증은 애플리케이션이 맡아야 합니다.
2.6 모델과 생성 설정값
2.6.1 모델
가장 성능이 높은 모델이 모든 작업에 필요한 것은 아닙니다. 짧은 문의를 정해진 유형으로 분류하는 작업과 여러 문서를 읽고 판단하는 작업은 요구하는 모델 수준이 다릅니다.
모델을 비교할 때는 대표 데이터를 같은 조건으로 실행합니다. 분류 품질뿐 아니라 구조화 출력 지원 여부, 지연, 비용, rate limit과 버전 관리 조건도 함께 봐야 합니다. 모델명과 가격은 바뀌므로 고정된 서열보다 비교 기준을 익히는 편이 낫습니다.
2.6.2 Temperature와 Top-p
Temperature와 top-p는 다음 토큰 후보를 선택하는 분포에 영향을 줍니다.
일반적으로 낮은 temperature는 확률이 높은 토큰을 선택하는 경향을 강화하고 높은 값은 여러 후보가 선택될 가능성을 높입니다.
지원 여부와 허용 범위는 API와 모델마다 다릅니다.
Temperature와 top-p를 모두 바꾸면 어느 설정이 결과에 영향을 줬는지 구분하기 어려우므로 보통 하나를 기준으로 실험합니다.
낮은 temperature도 의미적 정확성을 보장하지 않습니다.
- Temperature를 0으로 설정해도 완전한 재현성을 전제로 삼으면 안 됩니다.
- 분류 결과가 얼마나 안정적인지 판단하려면 같은 대표 입력을 반복해 측정해야 합니다.
2.6.3 출력 토큰 한도
출력 토큰 한도는 응답이 사용할 수 있는 최대 크기입니다.
값이 작으면 JSON이나 문장이 중간에 끊길 수 있습니다. 반대로 값을 크게 지정한다고 모델이 반드시 길게 답하는 것은 아닙니다.
출력 한도를 정할 때는 예상 응답이 들어갈 공간과 종료 상태를 함께 확인합니다. Reasoning token을 사용하는 모델은 보이는 답변 외의 토큰이 한도에 포함될 수 있으므로 모델별 계산 방식도 살펴봐야 합니다.
2.7 구조화 출력과 검증
상담 화면이나 업무 시스템은 자유로운 설명보다 예측 가능한 데이터를 다루기 쉽습니다.
{
"intent": "order_change",
"urgency": "medium",
"needs_clarification": false,
"route_to": "order_ops"
}Prompt에 JSON으로 답하세요라고 쓰는 것과 Schema로 출력 구조를 제한하는 것은 다릅니다.
| 방식 | 다루는 범위 | 남는 문제 |
|---|---|---|
| Prompt로 JSON 요청 | 모델이 형식을 따르도록 유도 | 설명 추가, 필드 누락, 잘못된 값 |
| JSON 형식 제한 | 문법적으로 유효한 JSON | 필드와 허용 값이 달라질 수 있음 |
| Schema 기반 출력 | 지원 범위 안에서 필드와 자료형 제한 | 의미가 틀린 결과는 여전히 가능 |
| 애플리케이션 검증 | 업무 규칙과 허용 값 확인 | 실패 처리 방식이 필요함 |
Schema 기반 출력도 응답의 정상 완료를 보장하지 않습니다.
모델이 응답을 거절하거나 길이 제한으로 생성을 끝낼 수 있고 API 오류가 발생할 수도 있습니다. 애플리케이션은 응답 상태를 먼저 확인한 뒤 구조와 의미를 검증해야 합니다.
형식이 맞아도 분류가 틀릴 수 있습니다.
{
"intent": "shipping_issue",
"urgency": "medium",
"needs_clarification": false,
"route_to": "shipping_ops"
}이 JSON은 필드와 자료형이 맞습니다. 하지만 배송지 변경 요청을 이미 발생한 배송 사고로 분류했다면 업무 결과는 오답입니다. 구조적 유효성과 의미적 정확성은 따로 평가해야 합니다.
2.8 이커머스 CS 분류 흐름
앞의 내용은 하나의 요청 흐름으로 이어집니다.
고객 문의
→ 분류 지시와 사용자 입력 구성
→ tokenizer가 토큰으로 변환
→ 모델이 다음 토큰을 반복 생성
→ 구조화된 분류 결과 반환
→ 응답 상태와 Schema 검증
→ 업무 기준으로 의미 검증
→ 상담 조직으로 전달
각 단계에서 발생하는 문제도 다릅니다.
| 문제 | 예시 | 확인할 위치 |
|---|---|---|
| 입력 부족 | 주문번호나 변경 시점이 없음 | 사용자 입력과 추가 질문 |
| 의미 오류 | 배송지 변경을 배송 사고로 분류 | 분류 기준과 평가 데이터 |
| 구조 오류 | 필드 누락이나 허용하지 않은 값 | Schema와 애플리케이션 검증 |
| 불완전 출력 | 토큰 한도로 JSON이 중간에 종료 | 응답 상태와 출력 한도 |
| API 오류 | rate limit, timeout, 일시 장애 | 재시도와 오류 처리 |
문의 분류 결과는 상담원을 돕는 데이터로 사용할 수 있습니다. 주문 변경이나 환불처럼 외부 시스템의 상태를 바꾸는 작업은 별도의 권한과 승인 절차를 거쳐야 합니다. LLM의 출력 형식을 통제하는 일과 실제 업무 권한을 통제하는 일은 서로 다른 문제입니다.
2.9 정리
LLM은 입력 문맥에서 다음 토큰을 하나씩 생성하는 언어 모델입니다.
텍스트는 tokenizer를 거쳐 토큰으로 바뀌고 모델은 토큰 사이의 관계를 계산해 다음 토큰의 분포를 만듭니다. Temperature와 top-p는 후보 선택에 영향을 주며 출력 토큰 한도는 생성 가능한 크기를 제한합니다.
API 요청에서는 모델, 지시, 사용자 입력, 출력 형식과 생성 설정값을 구분합니다. 구조화 출력은 코드가 다룰 수 있는 형태를 만드는 데 도움이 되지만 의미까지 맞다고 보장하지는 않습니다. 구조화 출력만으로는 충분하지 않습니다. 응답 상태, Schema, 업무 규칙을 차례로 확인해야 합니다.
이커머스 CS 분류는 이 흐름을 작게 경험하기 좋은 작업입니다. 짧은 문의가 어떤 토큰과 설정을 거쳐 구조화된 결과로 바뀌는지 볼 수 있고 형식이 맞는 결과와 업무상 옳은 결과의 차이도 확인할 수 있습니다.