명품 요리의 Recipe와 AI의 LLM을 비교
저자: 김성중 · 작성일: 2026-05-05 00:00:00 · 분야: AI, 방법론
명품 요리의 Recipe와 AI의 LLM을 비교
기본 구조 (Claude 답변)
- 재료(Ingredients): 신선도, 품질, 적합성
- 레시피(Recipe): 순서, 비율, 기법
- 조리 도구(Tools): 칼, 불, 오븐의 정밀도
- 요리사의 판단(Chef's judgment): 간보기, 조정, 플레이팅
| 요리 | LLM |
|---|---|
| 재료 | Context (입력 데이터, RAG, 도메인 지식) |
| 레시피 | Prompt (지시문, 구조, 제약) |
| 조리 도구 | Model 선택 + Tool calling + Agent framework |
| 요리사 판단 | Evaluation, iteration, human-in-the-loop |
핵심 원칙
재료가 응답 품질의 70%를 결정합니다.
요리에서도 그렇듯, 아무리 좋은 레시피라도 재료가 평범하면 평범한 음식이 나옵니다. LLM에서 Context Engineering에 해당합니다.
- 신선한 재료: 최신 정보 확보 (RAG, 웹 검색, API 연동)
- 선별된 재료: 노이즈 제거, 도메인 특화 데이터 큐레이션
- 재료 손질: 청킹 전략, 메타데이터 부여, 임베딩 품질
레시피는 기법의 조합입니다.
전문가의 레시피는 단순히 '이거 넣고 저거 넣어'가 아니라, 각 기법이 왜 그 순서에 있어야 하는지가 명확합니다.
- Mise en place (사전 준비): System prompt에 역할, 제약, 출력 형식 명시
- 순차 조리: Chain-of-Thought, 단계별 지시
- 온도 조절: Temperature, top_p 같은 샘플링 파라미터
- 간보기: Few-shot examples로 기준점 제시
- 불 조절: 문제를 작은 sub-task로 분해 (decomposition)
도구는 손의 연장입니다.
요리사가 좋은 칼을 쓰는 이유는 손의 정밀도를 확장하기 때문입니다.
- 모델 선택: 모든 요리에 미슐랭 셰프가 필요하진 않습니다. 단순 분류는 작은 모델, 복잡한 추론은 큰 모델
- Tool 사용: 계산은 계산기에게, 검색은 검색엔진에게 — LLM이 못하는 걸 강요하지 않기
- 멀티 에이전트: 한 명이 모든 걸 하는 게 아니라, 수셰프(sous chef)에게 분담
요리사의 판단은 평가에서 나옵니다.
가장 중요하지만 간과하는 부분입니다. 전문가 셰프는 주기적으로 간을 봅니다.
- Eval set 구축: 골든 데이터셋으로 회귀 테스트
- LLM-as-Judge: 다른 모델로 출력 검증 (solar-thermal 프로젝트의 VLM 검증과 같은 맥락)
- Human-in-the-loop: 중요한 결정에는 사람의 검토
- Feedback loop: 실패 사례를 다시 프롬프트/RAG로 환류
기본 구조 (Gemini 답변)
LLM의 응답을 하나의 '요리'로 본다면, 단순히 재료를 넣고 끓이는 것을 넘어 미슐랭 스타급 전문 요리를 만들어내기 위한 전략이 필요합니다.
최상급 식재료 준비: RAG (Retrieval-Augmented Generation)
재료가 신선하지 않으면 아무리 뛰어난 요리사라도 제대로된 음식을 만드는데 한계가 있습니다. 전문가 수준의 응답을 원한다면 실시간 데이터와 전문 지식을 확보해야만 합니다.
- 외부 지식의 결합: 최신 논문, 기업 내부 문서, 특정 시장 데이터 등을 LLM에 직접 입력합니다.
- 데이터의 정제: 불필요한 노이즈를 제거한 깨끗한 데이터(Clean Data)를 제공할수록 응답의 정확도가 높아집니다.
정교한 레시피 설계: 구조화된 프롬프팅
레시피가 모호하면 요리사마다 맛이 달라집니다. LLM에게도 명확한 페르소나와 제약 조건을 설정해 주어야 합니다.
- 페르소나 설정 (The Chef): "너는 10년 차 퀀트 투자 전문가야" 또는 "너는 시니어 소프트웨어 아키텍처야"라고 명확한 역할을 부여합니다.
- 퓨샷(Few-shot) 가이딩: "이런 질문에는 이렇게 답변해"라는 훌륭한 예시(Sample)를 2~3개만 보여줘도 LLM은 그 '간'을 정확히 맞춥니다.
- 제약 조건 설정: 답변의 길이, 반드시 포함해야 할 용어, 금지어 등을 설정하여 출력의 품질을 통제합니다.
요리 기법의 고도화: 추론 체인 (Chain of Thought)
전문가는 어떤 논리적 과정을 거쳐서 결론에 도달했는지 설명합니다. LLM에게도 '생각의 과정'을 요구해야 합니다.
- 단계별 사고: "단계별로 생각해서 답변해줘(Let's think step by step)"라는 주문은 LLM의 논리적 오류를 비약적으로 줄여줍니다.
- 자가 비판(Self-Criticism): 첫 번째 응답을 바로 내놓게 하지 말고, "방금 네 답변에서 논리적 허점이 무엇인지 검토하고 수정해줘"라는 루프를 추가하세요. 이 과정이 '맛을 보는 과정'입니다.
주방 시스템 구축: 멀티 에이전트(Multi-Agent) 워크플로우
혼자서 모든 요리를 하는 것보다 소스 전문가, 고기 전문가, 플레이팅 전문가로 나누어야 효율적입니다. 복잡한 문제는 여러 개의 전문 에이전트로 나누어서 처리해야 합니다.
| 역할 | 수행 작업 |
|---|---|
| Planner | 전체적인 응답 구조를 짜고 필요한 정보를 정의함 |
| Researcher | 필요한 데이터와 전문 지식을 검색하고 수집함 |
| Writer | 수집된 정보를 바탕으로 전문적인 톤앤매너로 글을 작성함 |
| Reviewer | 사실 관계를 검증하고(Hallucination 체크) 최종 품질을 승인함 |
💡 전문가의 팁: "플레이팅(Formatting)"의 중요성
- Markdown 활용: 표, 불렛포인트, 굵은 글씨 등을 사용하여 핵심 내용을 한눈에 들어오게 하세요.
- 시각화 요청: 필요한 경우 데이터 구조를 다이어그램이나 코드로 표현해달라고 명시하는 것이 좋습니다.
"전문가" 패턴
도메인(금융, 산업 AI)을 고려해서 실용적인 패턴을 제안합니다.
Layer 1 — Retrieval & Context (재료 준비) 도메인 지식 베이스 + 실시간 데이터 소스 + 사용자 컨텍스트를 결합. 단일 RAG가 아니라 Hybrid Retrieval (BM25 + Dense + Graph)을 권장합니다.
Layer 2 — Pre-processing Agents (사전 조리) 입력 의도 분류, 쿼리 재작성(query rewriting), 필요한 도구 결정. 이 단계에서 작은 모델로 빠르게 처리하면 비용/지연이 크게 줄어듭니다.
Layer 3 — Core Reasoning (본 조리) 가장 강력한 모델(Claude Opus)을 여기서만 씁니다. Plan-and-Execute, ReAct, 또는 도메인 특화 워크플로우입니다.
Layer 4 — Output Shaping (플레이팅) 구조화된 출력(JSON Schema, Pydantic), 인용(citation), 신뢰도 점수 부여. 사용자가 결과를 검증 가능하게 만드는 것이 전문가다움의 핵심입니다.
Layer 5 — Validation & Critique (간보기) 별도 모델 또는 규칙 기반 검증자가 출력을 평가. 금융 분야라면 숫자 정합성, 규제 준수 체크가 필수입니다.
LLM에서 흔한 실수 = 흔한 요리 실패
- 재료 부족인데 양념으로 해결하려 함 → 데이터가 부족한데 프롬프트 튜닝만 함
- 너무 많은 재료를 한 번에 넣음 → Context window 가득 채우기, 오히려 성능 저하 (lost in the middle)
- 간을 안 봄 → Eval 없이 배포
- 만능 셰프 가정 → 모든 작업에 가장 비싼 모델 사용
- 레시피만 바꾸고 재료는 그대로 → Prompt 튜닝에만 집착, RAG 품질 개선은 안함