LLM

LLM을 “정확하고 효율적으로” 사용하는 방법 정리

ksc-dev 2026. 5. 13. 20:33

OpenAI 및 Gemini 기반 LLM 활용 경험을 실제 개발 관점에서 정리한 내용이다.


💡 시작하며 (느낀 점)

LLM 최적화 가이드를 읽기 전까지는
“내가 LLM을 잘못 쓰고 있는 건가?”라는 고민이 있었다.

프롬프트를 어떻게 써야 할지도 감이 잘 안 잡혔고,
결과도 들쭉날쭉해서 일관성이 없었다.

특히 축덕 퀴즈 같은 프로젝트에서
데이터가 반복되거나 구조가 깨지는 문제를 보면서
“이건 그냥 운인가?”라는 느낌도 있었다.


하지만 문서를 읽고 나서 방향이 완전히 바뀌었다.

  • LLM은 질문을 잘하는 도구가 아니라 구조를 설계하는 시스템
  • 결과 품질은 모델이 아니라 입력 설계가 결정
  • 비용, 중복, 안정성 모두 “프롬프트 구조 문제”

이후 생각이 이렇게 바뀌었다:

“어떻게 질문할까?” → “어떤 구조로 설계할까?”
 

🧠 전체 구조

1. 프롬프트 엔지니어링
2. 파인튜닝
3. 비용 최적화
4. 실전 적용 (축덕 퀴즈 / 월드컵 이벤트)
 

1️⃣ 프롬프트 엔지니어링

📌 개념

LLM 모델을 바꾸지 않고 입력 설계로 결과를 제어하는 방식


⚽ 실전 경험 ①: ETF 프롬프트

나는 초보 ETF 투자자이다.
내 포트폴리오를 평가해줘.
 

👉 역할 기반으로 답변 품질 개선
👉 하지만 기준이 없으면 답변이 애매해짐


⚽ 실전 경험 ②: 축덕 퀴즈 초기

축구 선수 300명 JSON 만들어줘
 

❌ 문제 발생

  • 동일 선수 반복 생성
  • JSON 구조 깨짐
  • 데이터 중복 관리 불가능

🔁 당시 방식

생성 → 사람 검수 → 문제 발견 → 재요청 → 반복
 

👉 구조 없이 사람이 보정하는 방식


💡 핵심 인사이트

  • 프롬프트는 단순 요청이 아니라 데이터 설계 규칙
  • 구조 없으면 결과는 항상 불안정

2️⃣ 파인튜닝

OpenAI 모델을 직접 학습시켜 출력 패턴을 고정하는 방식


⚽ 적용 영역

  • 답변 스타일 고정
  • 도메인 특화 모델
  • 구조화된 출력 강화

✔ 현재 판단

  • 아직 불필요
  • 프롬프트 + 구조 설계로 충분히 해결 가능

3️⃣ 비용 최적화

📌 핵심 전략

  • JSON 구조 고정
  • context 최소화
  • 중복 생성 방지

📦 캐싱 전략

Redis 기반

  • 동일 데이터 재생성 방지
  • API 비용 감소
  • 응답 속도 개선

4️⃣ 실전 적용 (축덕 퀴즈 / 월드컵 이벤트)

⚽ 기본 데이터 구조

 
{
  "id": 1,
  "name": "선수 이름",
  "story": "커리어 설명",
  "hint": "힌트"
}
 

❌ 초기 문제

  • 동일 선수 반복 생성
  • JSON 구조 불안정
  • 데이터 품질 흔들림

💡 현재 구조 방향

  • id 유니크 보장
  • name 중복 방지
  • story 구조 표준화
  • hint 단계형 설계

🚀 확장 예정: 월드컵 이벤트 자동화

국가: 브라질
수량: 10
story는 선수의
- 2026년 국가대표 활약
- 최근 리그 퍼포먼스
- 주요 경기 내용
- 시즌 흐름

등을 기반으로 생성 예정

→ 프롬프트 자동 생성
→ LLM 호출
→ JSON 검증
→ 캐싱 후 저장
 

⚙️ 전체 구조

입력
 ↓
프롬프트 자동 생성
 ↓
LLM 호출
 ↓
Validation
 ↓
Cache (Redis)
 ↓
DB 저장
 ↓
Frontend
 

🧠 핵심 결론

LLM 최적화의 핵심은 모델이 아니라
“입력 설계 + 검증 구조 + 캐싱 + 자동화 시스템”이다
 

📊 전체 요약

프롬프트 엔지니어링 → 입력 설계
파인튜닝 → 선택적 고도화
비용 최적화 → 호출 최소화
실전 적용 → 시스템 자동화
 

🔗 참고 링크


🧠 마지막 한 줄

LLM은 “질문을 잘하는 도구”가 아니라 “구조를 설계하는 시스템”이다