LLM 기술 강의 핵심 정리
LLM의 토큰화 메커니즘, 프롬프트 설계 원칙, 코딩 에이전트(Cursor, Claude Code) 활용법에 대한 기술 강의 요약.
1. 토큰화 메커니즘
토큰의 정의와 동작 원리
- 토큰: LLM이 텍스트를 이해하는 최소 단위. 단어보다 작은 조각으로 분해됨
- 예시:
@transactional→@,trans,actional(3개 토큰)
- 예시:
- 비용 구조
- 입력 토큰이 길수록 → 비용 증가
- 출력 토큰이 길수록 → 응답시간 증가
- 컨텍스트 윈도우: 일정 맥락을 넘으면 정보가 잘리거나 요약됨
언어별 토큰 효율성
| 구분 | 특징 |
|---|---|
| 영어 | 더 작은 토큰으로 분리 → 효율 좋고 의미 보존 우수 |
| 한국어 | 같은 글자 수라도 토큰 수가 더 많이 계산됨 |
⚠️ 코드 파일을 많이 붙여넣는다고 무조건 답이 좋아지는 것은 아님. 토큰 증가로 비용·지연이 증가하고, 중요 정보가 긴 문맥에 묻힐 수 있음.
2. 다음 토큰 예측 메커니즘
확률적 생성 과정
- 모델이 다음에 올 가능성이 높은 후보 토큰 여러 개 생성
- 하나의 토큰 선택 후 3~4개 토큰을 연속으로 생성
- 문맥이 자연스러우면 확정 → 확정되지 않은 토큰들은 캐시 데이터로 보관
비결정적 특성
- 같은 질문에도 완전히 같은 답이 나오지 않음
- 정답 테이블이 아닌 확률 분포에서 다음 토큰을 선택
- LLM의 본질: 어떻게든 말이 되게끔 생성하는 것
3. 할루시네이션 (Hallucination)
발생 원인
문맥이 부족하거나 지시가 애매하면, LLM이 빈칸을 자기 방식으로 채워 그럴듯한 내용을 생성함.
대표적 사례
| 유형 | 설명 |
|---|---|
| 존재하지 않는 어노테이션 | 실제로 없는 Spring 어노테이션 제안 |
| 가짜 메서드 | 실제 라이브러리에 없는 메서드 호출 |
| 오래된 설정 | 오래된 설정을 최신 방식처럼 설명 (가장 위험) |
| 가짜 옵션 | 공식 문서에 없는 옵션 생성, 없는 클래스·파일이 있다고 가정 |
방지 전략
- 버전 명시:
"Spring 몇 버전 기준으로"명확히 지정 - 공식 문서 제공:
"이 안에서 만들어내"같은 지침 제공 - 긴 컨텍스트 활용: 공식 문서를 토큰화하여 LLM이 기억하도록 하고, 그 위에서 요구사항 처리
- 최신성 확보:
"공식 문서 기준으로 확인해줘"또는"버전을 명시해서 비교해줘"
4. GPU와 추론 (Inference) 프로세스
Inference 단계
1. 메시지 정리 → 사용자 요청을 정리하고 토큰화
2. 행렬 변환 → 토큰을 행렬로 만들어 GPU 메모리(VRAM)에 적재
3. 임베딩 조회 → 토큰의 임베딩 값 조회
4. Transformer → 다음 토큰을 연속 생성
5. 디코딩 → 토큰 ID 집합을 사람이 읽을 수 있는 텍스트로 변환Prefill 단계
- 입력 토큰 전체를 GPU에 올리는 과정
- Attention 계산: 각 토큰 간의 상관관계를 계산
- 예:
"나무에서 사과가 떨어졌다. 그건 왜 떨어졌을까?"에서"그건"→"사과"를 가리킨다고 인지
- 예:
- 2018년 Attention 개념 도입으로 토큰 간 중요도 파악 가능
- 계산 결과는 Key-Value 캐시에 저장
Decode 단계
- 숫자 형태의 토큰 ID → 사람이 이해할 수 있는 텍스트로 변환
- 토큰을 만들고 선택하는 과정을 반복하여 응답 반환
5. Key-Value 캐시
역할과 기능
- 이전 토큰들의 Attention 계산 결과 중 재사용 가능한 정보를 저장하는 메모리
- 새 채팅을 시작하지 않으면 KV 캐시는 계속 유지됨
"위에서 이렇게 말했잖아. 이거대로 해줘"같은 이전 결과 참조 가능
처리 메커니즘
- 현재 입력을 Query로 계산
- Key-Value 캐시와 Attention 계산
- 결과를 바탕으로 다음 토큰 예측
성능 트레이드오프
| 항목 | 내용 |
|---|---|
| 속도 | KV 캐시로 속도 향상 |
| 메모리 | 문맥이 길어질수록 GPU 메모리 사용 증가 |
| 동시 처리 | 메모리 사용 증가 → 동시 처리 가능한 요청 수 감소 |
6. 긴 컨텍스트 (Long Context)
비용 구조
- KV 캐시 값 증가 → GPU 메모리(VRAM) 사용 증가
- 계산할 거리가 많아져 Attention도 비대화
- 첫 토큰 지연: 어디서부터 생성할지 결정하는 첫 토큰이 늦게 나옴
긴 컨텍스트의 기준
| 기준 | 내용 |
|---|---|
| 실제 기준 | 소설 약 5권 분량 |
| 일반 사용 | 20문장, 3,000자 → 전혀 문제없음 |
| 프롬프트 지침 | 빠르게 읽고 답변 가능 |
모델별 발전
- GPT-3.0 시절: 소설 반 권 수준의 컨텍스트
- 현재: 소설 50권 수준까지 확장 (단, 매우 큰 GPU 필요)
7. 생성 파라미터 (Generation Parameters)
Temperature
- 다음 토큰을 고를 때 얼마나 보수적으로 움직일지 조절
| 값 | 특성 |
|---|---|
| 낮음 | 안정적, 확실한 답변 (코드 작업 등에 적합) |
| 높음 | 창의적, 다양한 답변 |
GPT, Claude, Gemini 같은 서비스는 Temperature가 고정되어 있으며, Ollama·Hugging Face에서 직접 모델을 실행할 때 조절 가능.
Top-P / Top-K
- 후보 토큰 범위를 제한
- 몇 개의 후보 토큰을 조합해볼지 결정
Max Tokens
- 출력 길이의 상한
- 숫자로 제어하기보다 출력 형식 지정 권장 (예:
"JSON 형태로 답변해줘")
Stop Sequence
- 특정 문자열이 나오면 생성을 중단
- 예: JSON, 로그 템플릿 같은 형식에서 종료 지점 지정
8. 프롬프트 엔지니어링
프롬프트의 본질
프롬프트는 말로 작성하지만 본질은 인터페이스 — AI와 사람이 어떻게 협업할지 정의하는 것
좋은 프롬프트의 구성 요소
| 요소 | 설명 | 예시 |
|---|---|---|
| 역할 (Role) | AI의 역할 설정 | "너는 시니어 백엔드 개발자야" |
| 태스크 (Task) | 구체적인 작업 지시 | "이 코드를 리팩터링해줘" |
| 맥락 (Context) | 길지 않은 배경 정보 | "Spring Boot 3.2 프로젝트야" |
| 제약사항 (Constraints) | 하지 말아야 할 것 | "외부 라이브러리는 추가하지 마" |
| 판단 기준 (Criteria) | 스스로 판단할 수 있는 기준 | "성능보다 가독성 우선" |
| 출력 형식 (Output Format) | 답변 구조 고정 | "JSON 형태로 반환해줘" |
| 실패 처리 (Failure Handling) | 정보 부족 시 행동 지침 | "부족한 정보는 먼저 질문하세요" |
나쁜 프롬프트 예시
❌ "이 코드 고쳐줘"무엇이 빠졌나?
- 목표, 제약사항, 기술 스택, 성공 기준, 검증 방식 — 모두 없음
- LLM은 부족한 정보를 질문하지 않고 자기 방식으로 처리하거나
"고칠 게 없습니다"라고 답변
실패 조건의 중요성
"추측하지 말고 부족한 정보를 먼저 말하세요" 같은 실패 조건을 넣으면, LLM이 작업 중 실패 가능성을 감지하고 명확히 "실패했습니다" 라고 알림.
9. 모델별 프롬프팅 차이
GPT (OpenAI)
- 학습 방식: 사용자가 무엇을 말할지 몰라서 있는 그대로 학습
- 프롬프팅 스타일: 자연어로 말하는 것처럼 작성
- 특징: 폭넓은 범용성, 다양한 사용자 대응 가능
Claude (Anthropic)
- 학습 방식: 프리필 단계가 정해져 있고, 특정 방식으로 대답하도록 사전 학습
- 프롬프팅 스타일: XML 태그로 구조화
<role>시니어 백엔드 개발자</role>
<context>Spring Boot 3.2 프로젝트</context>
<code>...</code>- 특징: 특수한 목적이 있는 사용자가 더 잘 활용 가능
토크나이저 차이
- GPU에 넣기 전, 토크나이저가 메시지를 정리하여 토큰으로 변환하는 과정이 LLM마다 다름
- GPT와 Claude 모두 프롬프팅 방법에 대한 공식 문서 제공
10. 코딩 에이전트 (Cursor, Claude Code)
정의와 역할
LLM을 잘 사용하기 위한 모든 기능을 사용자가 몰라도 사용할 수 있게 만든 도구.
단순히 Claude API나 GPT API를 랩핑한 것이 아님.
핵심 기능
- 도구 사용 규칙: 파일 접근 권한, 프로젝트 지침, 승인 정책 등 포함
- 프롬프트 최적화: 사용자 프롬프트를 각 LLM이 잘 이해할 수 있는 형식으로 자동 변환
- 프로젝트 지침:
.cursorrules.md같은 설정 파일 포함 - 도구와 권한: 파일 읽기·수정, 터미널 실행 등
동작 메커니즘
1. 사용자 요청 → 프롬프트 입력
2. 프롬프트 변환 → LLM에 맞는 형식으로 변환
3. LLM 호출 → 변환된 프롬프트로 요청
4. 도구 실행 → 파일 읽기/수정, 터미널 명령 실행
5. 루프 → 결과를 다시 코딩 에이전트로 가져와 반복Cursor의 구조
| 구성 요소 | 역할 |
|---|---|
| 모델 선택 | 어떤 LLM 모델을 사용할지 지정 |
| 에이전트 지침 | 어떤 에이전트를 사용할지 설정 |
| 샌드박스 | 보안 레이어 제공 |
자동 업데이트
최신 프롬프트 기법들이 Cursor나 Claude Code 업데이트 하나로 자동 반영됨.
Claude Code의 특징
KV 캐시가 아닌, 반복되는 선호 패턴(빌드 명명, 디버깅 방식 등)을 학습하여 메모리에 저장.
11. 조언 및 모범 사례
✅ Spring 버전 명시: 최신 정보가 중요한 질문은 항상 버전을 명시하거나 공식 문서 기준을 제시
✅ 컨텍스트 길이 관리: 3,000자·20문장 정도는 문제없지만, 소설 5권 이상은 비용과 지연 고려
⚠️ LLM 신뢰 한계: LLM은 굉장히 많이 틀림 → 항상 검증 필요
⚠️ 코드 파일 붙여넣기: 많이 붙여넣는다고 무조건 답이 좋아지는 것은 아님. 중요 정보가 묻힐 수 있음
개발자가 되고 싶습니다