LLM 평가 태스크 완벽 가이드

대형 언어 모델의 성능을 측정하는 핵심 벤치마크인 CORE, ARC, MMLU, GSM8K, HumanEval을 초급 개발자도 이해할 수 있도록 쉽게 설명합니다. 각 평가 지표의 의미와 실제 활용법을 배워봅니다.

---

목차

1. LLM_평가가_중요한_이유
2. CORE_점수란
3. ARC_Easy_Challenge_분석
4. MMLU_다중_선택_평가
5. GSM8K_수학_문제_평가
6. HumanEval_코딩_평가
7. report.md_리포트_생성

---

1. LLM 평가가 중요한 이유

김개발 씨는 최근 회사에서 새로운 AI 프로젝트를 맡게 되었습니다. GPT, Claude, Gemini 등 수많은 LLM 중에서 어떤 모델을 선택해야 할지 막막했습니다.

선배에게 물어보니 "벤치마크 점수를 비교해봐"라는 답이 돌아왔는데, MMLU가 뭔지, ARC가 뭔지 도통 알 수가 없었습니다.

LLM 평가는 대형 언어 모델의 능력을 객관적으로 측정하는 시험과 같습니다. 마치 학생이 수능을 보듯이, AI 모델도 다양한 시험을 통해 자신의 실력을 증명해야 합니다.

이 평가 점수를 통해 개발자는 프로젝트에 적합한 모델을 선택할 수 있습니다.

다음 코드를 살펴봅시다.

# LLM 평가 점수 비교 예제
evaluation_scores = {
    "GPT-4": {"MMLU": 86.4, "ARC": 96.3, "GSM8K": 92.0},
    "Claude-3": {"MMLU": 88.7, "ARC": 96.4, "GSM8K": 95.0},
    "Gemini": {"MMLU": 83.7, "ARC": 94.4, "GSM8K": 94.4}
}

# 특정 태스크에 가장 적합한 모델 찾기
def find_best_model(task_name):
    best_model = max(evaluation_scores.keys(),
                     key=lambda x: evaluation_scores[x][task_name])
    return best_model, evaluation_scores[best_model][task_name]

# 수학 문제 해결에 최적인 모델 찾기
model, score = find_best_model("GSM8K")
print(f"수학 추론 최고 모델: {model} ({score}%)")

김개발 씨는 입사 6개월 차 주니어 개발자입니다. 이번에 처음으로 AI 기반 서비스를 개발하게 되었는데, 시장에는 수십 개의 LLM이 존재했습니다.

각 회사는 자사 모델이 최고라고 광고하고 있었습니다. "도대체 어떤 모델을 써야 할까요?" 김개발 씨가 팀장에게 물었습니다.

"모델마다 장단점이 달라요. 우리 서비스에 필요한 능력이 뭔지 먼저 정하고, 그에 맞는 벤치마크 점수를 비교해보세요." 그렇다면 LLM 평가란 정확히 무엇일까요?

쉽게 비유하자면, LLM 평가는 마치 자동차 성능 테스트와 같습니다. 자동차를 살 때 우리는 연비, 최고 속도, 안전성 등 다양한 지표를 비교합니다.

마찬가지로 LLM도 추론 능력, 지식 수준, 코딩 실력 등 여러 측면에서 평가받습니다. 왜 이런 평가가 필요할까요?

LLM 평가가 없던 시절에는 모델 선택이 순전히 주관적이었습니다. "이 모델이 좋다더라", "저 모델이 더 똑똑한 것 같아"라는 느낌에 의존해야 했습니다.

프로젝트에 부적합한 모델을 선택하면 시간과 비용을 낭비하게 됩니다. 바로 이런 문제를 해결하기 위해 표준화된 벤치마크가 등장했습니다.

MMLU는 학문적 지식을, ARC는 과학적 추론을, GSM8K는 수학 능력을, HumanEval은 코딩 실력을 측정합니다. 각 벤치마크는 특정 능력에 초점을 맞추고 있습니다.

위의 코드를 살펴보겠습니다. 먼저 각 모델의 벤치마크 점수를 딕셔너리로 정리했습니다.

그다음 특정 태스크에서 가장 높은 점수를 받은 모델을 찾는 함수를 작성했습니다. 이렇게 하면 객관적인 데이터를 기반으로 모델을 선택할 수 있습니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 고객 상담 챗봇을 만든다면 일반 지식과 대화 능력이 중요합니다.

반면 코드 리뷰 도구를 만든다면 HumanEval 점수가 높은 모델을 선택해야 합니다. 목적에 맞는 벤치마크를 확인하는 것이 핵심입니다.

주의할 점도 있습니다. 벤치마크 점수가 전부는 아닙니다.

실제 사용 환경에서의 응답 속도, 비용, API 안정성 등도 고려해야 합니다. 또한 일부 모델은 특정 벤치마크에 과적합되어 실제 성능과 점수가 다를 수 있습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 팀장의 조언을 듣고 벤치마크를 공부하기 시작한 김개발 씨는 이제 자신 있게 모델을 비교할 수 있게 되었습니다.

"아, 우리 서비스는 수학 계산이 많으니까 GSM8K 점수가 높은 모델을 써야겠군요!" LLM 평가를 이해하면 더 나은 기술 의사결정을 내릴 수 있습니다. 여러분도 프로젝트를 시작할 때 벤치마크 점수를 꼭 확인해보세요.

실전 팁

💡 - 단일 벤치마크가 아닌 여러 벤치마크를 종합적으로 비교하세요

• 최신 벤치마크 결과는 Papers with Code나 Hugging Face Leaderboard에서 확인할 수 있습니다

---

2. CORE 점수란

박시니어 씨가 김개발 씨에게 새로운 LLM 리포트를 건네며 말했습니다. "이번에 나온 모델인데, CORE 점수가 꽤 높아요." 김개발 씨는 MMLU는 들어봤지만 CORE는 처음이었습니다.

"CORE가 뭔가요? 핵심이라는 뜻인가요?"

CORE는 Comprehensive Open-source Reasoning Evaluation의 약자로, LLM의 종합적인 추론 능력을 평가하는 지표입니다. 마치 종합 건강검진처럼 모델의 다양한 추론 능력을 한 번에 측정합니다.

여러 벤치마크의 결과를 통합하여 모델의 전반적인 성능을 파악할 수 있습니다.

다음 코드를 살펴봅시다.

# CORE 점수 계산 예제
def calculate_core_score(model_results):
    # 각 벤치마크별 가중치 설정
    weights = {
        "reasoning": 0.25,    # 논리적 추론
        "knowledge": 0.25,    # 지식 활용
        "math": 0.20,         # 수학적 사고
        "coding": 0.20,       # 코딩 능력
        "language": 0.10      # 언어 이해
    }

    # 가중 평균 계산
    core_score = sum(
        model_results[category] * weight
        for category, weight in weights.items()
    )
    return round(core_score, 2)

# 모델 평가 결과
gpt4_results = {
    "reasoning": 92.5, "knowledge": 88.4,
    "math": 91.0, "coding": 87.1, "language": 95.2
}
print(f"GPT-4 CORE 점수: {calculate_core_score(gpt4_results)}")

김개발 씨는 새로운 용어를 만날 때마다 조금 당황했습니다. 이미 MMLU, ARC, GSM8K 등 외워야 할 벤치마크가 너무 많았기 때문입니다.

그런데 이제 CORE까지 알아야 한다니요. 박시니어 씨가 친절하게 설명해주었습니다.

"CORE는 여러 벤치마크를 종합한 점수라고 생각하면 돼요." 그렇다면 CORE 점수가 왜 필요할까요? 쉽게 비유하자면, CORE는 마치 학교의 종합 성적표와 같습니다.

국어, 영어, 수학 점수를 따로 보는 것도 좋지만, 때로는 전교 석차처럼 하나의 숫자로 비교하고 싶을 때가 있습니다. CORE는 바로 그런 역할을 합니다.

개별 벤치마크만 보면 문제가 생깁니다. 모델 A는 MMLU에서 1등이고, 모델 B는 GSM8K에서 1등입니다.

그렇다면 어떤 모델이 더 좋을까요? 이런 상황에서 종합 점수가 없으면 비교가 어렵습니다.

CORE 점수는 이런 문제를 해결합니다. 논리적 추론, 지식 활용, 수학적 사고, 코딩 능력, 언어 이해 등 다양한 영역을 측정합니다.

각 영역에 가중치를 부여하여 하나의 점수로 통합합니다. 이렇게 하면 모델 간 전반적인 비교가 쉬워집니다.

위의 코드에서 가중치 설정을 주목해보세요. 추론과 지식에 각각 25%를 배정하고, 수학과 코딩에 각각 20%, 언어 이해에 10%를 배정했습니다.

이 가중치는 평가 목적에 따라 조정할 수 있습니다. 코딩 중심 서비스라면 코딩 가중치를 높이면 됩니다.

실무에서는 CORE 점수를 빠른 필터링에 활용합니다. 수십 개의 모델 중에서 먼저 CORE 점수로 상위권을 추립니다.

그다음 세부 벤치마크를 확인하여 프로젝트에 적합한 모델을 최종 선택합니다. 이렇게 하면 시간을 절약할 수 있습니다.

하지만 주의할 점이 있습니다. CORE 점수가 높다고 모든 상황에서 좋은 것은 아닙니다.

예를 들어 수학 튜터링 서비스를 만든다면 CORE 점수보다 GSM8K 점수가 더 중요합니다. 종합 점수는 참고용이고, 최종 결정은 개별 지표를 보고 내려야 합니다.

김개발 씨는 고개를 끄덕였습니다. "그러니까 CORE는 대학 입시의 표준점수 같은 거네요.

전체적인 위치를 파악하는 데 유용하지만, 세부 과목 점수도 꼭 봐야 하는 거죠?" 박시니어 씨가 웃으며 대답했습니다. "정확해요.

이제 벤치마크 읽는 법을 제대로 알게 된 것 같네요."

실전 팁

💡 - CORE 점수는 빠른 모델 비교에 유용하지만 최종 결정은 개별 벤치마크를 확인하세요

• 프로젝트 특성에 맞게 가중치를 조정한 커스텀 CORE 점수를 계산해볼 수 있습니다

---

3. ARC Easy Challenge 분석

김개발 씨가 모델 스펙을 보다가 ARC-E와 ARC-C라는 두 가지 점수를 발견했습니다. "둘 다 ARC인데 왜 나눠져 있죠?" 박시니어 씨가 답했습니다.

"Easy와 Challenge의 차이예요. 과학 추론 능력을 두 난이도로 측정하는 거죠."

ARC(AI2 Reasoning Challenge)는 초등학교 수준의 과학 문제로 AI의 추론 능력을 평가합니다. ARC-Easy는 단순한 지식 검색으로 풀 수 있는 쉬운 문제이고, ARC-Challenge는 여러 단계의 추론이 필요한 어려운 문제입니다.

이 두 점수를 비교하면 모델의 진정한 추론 능력을 파악할 수 있습니다.

다음 코드를 살펴봅시다.

# ARC 평가 시뮬레이션
arc_questions = {
    "easy": {
        "question": "물이 끓으면 어떻게 되나요?",
        "choices": ["얼음이 된다", "수증기가 된다", "기름이 된다", "사라진다"],
        "answer": 1,
        "reasoning_steps": 1
    },
    "challenge": {
        "question": "밀폐된 용기에서 물을 끓이면 압력은?",
        "choices": ["감소", "증가", "변화없음", "측정불가"],
        "answer": 1,
        "reasoning_steps": 3  # 여러 개념 연결 필요
    }
}

def evaluate_arc_response(question_type, model_answer):
    correct = arc_questions[question_type]["answer"]
    is_correct = model_answer == correct
    difficulty = "쉬움" if question_type == "easy" else "도전"
    print(f"[ARC-{difficulty}] 정답: {is_correct}")
    return is_correct

# 모델 응답 평가
evaluate_arc_response("easy", 1)      # 정답
evaluate_arc_response("challenge", 1)  # 정답

김개발 씨는 벤치마크를 공부할수록 재미를 느꼈습니다. 각 평가가 AI의 어떤 능력을 측정하는지 알게 되니, 모델 스펙시트가 읽히기 시작했습니다.

"ARC가 과학 문제라면, 그냥 검색해서 답하면 되는 거 아닌가요?" 김개발 씨가 물었습니다. 박시니어 씨가 고개를 저었습니다.

"그래서 Easy와 Challenge로 나눈 거예요." ARC-Easy는 마치 오픈북 시험과 같습니다. "물이 끓는점은 몇 도인가요?" 같은 질문은 지식만 있으면 바로 답할 수 있습니다.

대부분의 최신 LLM은 이런 문제에서 90% 이상의 정확도를 보입니다. ARC-Challenge는 다릅니다.

이건 마치 응용 문제와 같습니다. "밀폐된 용기에서 물을 끓이면 압력은 어떻게 되나요?" 이 질문에 답하려면 여러 개념을 연결해야 합니다.

물이 수증기가 된다, 기체는 부피가 크다, 밀폐 공간에서 부피 증가는 압력 증가를 의미한다. 이런 추론 체인이 필요합니다.

왜 이런 구분이 중요할까요? LLM이 정보를 단순히 암기하는지, 아니면 진정으로 이해하고 추론하는지 알 수 있기 때문입니다.

ARC-Easy 점수는 높은데 ARC-Challenge 점수가 낮다면, 그 모델은 지식은 많지만 응용력이 떨어지는 것입니다. 위의 코드에서 reasoning_steps 값을 주목하세요.

Easy 문제는 한 단계 추론이면 충분하지만, Challenge 문제는 세 단계 추론이 필요합니다. 이 차이가 난이도를 만듭니다.

실제 서비스에서 이 지표는 어떻게 활용될까요? 예를 들어 과학 교육 앱을 만든다면 ARC-Challenge 점수가 높은 모델을 선택해야 합니다.

학생들이 "왜요?"라고 물었을 때 단순 암기가 아닌 논리적 설명을 제공해야 하기 때문입니다. 주의할 점도 있습니다.

ARC는 초등학교 수준의 과학에 초점을 맞춥니다. 대학 수준의 전문 과학 지식은 다른 벤치마크로 평가해야 합니다.

또한 영어로 된 문제이기 때문에 한국어 성능과는 다를 수 있습니다. 김개발 씨가 정리했습니다.

"그러니까 ARC-Easy는 기본기, ARC-Challenge는 응용력을 보는 거네요. 두 점수 차이가 크면 암기형 모델이라는 신호고요." "맞아요.

좋은 모델은 두 점수가 모두 높고, 그 차이가 크지 않아요."

실전 팁

💡 - ARC-Easy와 Challenge의 점수 차이가 10% 이내면 균형 잡힌 추론 능력을 가진 모델입니다

• 과학 관련 서비스를 개발한다면 ARC-Challenge 점수를 우선적으로 확인하세요

---

4. MMLU 다중 선택 평가

회의 시간에 팀장이 발표 자료를 띄웠습니다. "이번에 검토 중인 모델들의 MMLU 점수입니다." 화면에는 57개 분야별 세부 점수가 나열되어 있었습니다.

김개발 씨는 압도당하는 기분이었습니다. "이걸 다 봐야 하나요?"

MMLU(Massive Multitask Language Understanding)는 57개 학문 분야에 걸쳐 14,000개 이상의 4지선다 문제로 LLM의 지식 수준을 평가합니다. 마치 수능처럼 인문학부터 STEM까지 광범위한 영역을 측정합니다.

이 점수가 높을수록 모델의 일반 지식이 풍부하다고 볼 수 있습니다.

다음 코드를 살펴봅시다.

# MMLU 평가 구조 예제
mmlu_categories = {
    "STEM": ["물리학", "화학", "수학", "컴퓨터과학"],
    "인문학": ["철학", "역사", "문학", "법학"],
    "사회과학": ["경제학", "심리학", "사회학", "정치학"],
    "기타": ["의학", "비즈니스", "윤리학"]
}

def calculate_mmlu_score(model_answers, correct_answers):
    # 카테고리별 정확도 계산
    category_scores = {}
    for category, subjects in mmlu_categories.items():
        correct = sum(1 for s in subjects
                     if model_answers.get(s) == correct_answers.get(s))
        category_scores[category] = correct / len(subjects) * 100

    # 전체 평균 계산
    overall = sum(category_scores.values()) / len(category_scores)
    return {"categories": category_scores, "overall": round(overall, 1)}

# 예시 결과
result = {"categories": {"STEM": 88.5, "인문학": 82.3}, "overall": 85.4}
print(f"MMLU 종합 점수: {result['overall']}%")

김개발 씨에게 MMLU는 처음에 벽처럼 느껴졌습니다. 57개 분야라니, 도대체 어떻게 이 많은 점수를 해석해야 할까요?

팀장이 설명을 시작했습니다. "MMLU는 크게 네 카테고리로 나눠서 보면 됩니다." MMLU는 마치 대학 입학시험과 같습니다.

수능이 언어, 수리, 과학탐구, 사회탐구 등 여러 영역으로 나뉘듯이, MMLU도 STEM, 인문학, 사회과학, 기타로 분류됩니다. 각 영역에서 모델이 얼마나 잘 답하는지 측정합니다.

왜 이렇게 광범위한 평가가 필요할까요? 실제 사용자들은 다양한 질문을 합니다.

어떤 사람은 물리학을 물어보고, 어떤 사람은 역사를 물어봅니다. LLM이 특정 분야에만 강하다면 범용 서비스에는 적합하지 않습니다.

MMLU의 문제는 모두 4지선다 형식입니다. 이는 평가의 객관성을 높입니다.

주관식 답변은 채점 기준이 모호할 수 있지만, 객관식은 정답이 명확합니다. 덕분에 모델 간 공정한 비교가 가능합니다.

흥미로운 점은 세부 분야별 점수를 볼 수 있다는 것입니다. 예를 들어 법률 서비스를 만든다면 법학 분야 점수를, 의료 서비스를 만든다면 의학 분야 점수를 중점적으로 확인하면 됩니다.

위의 코드에서 카테고리별 점수 계산 로직을 보세요. 각 카테고리 내 과목들의 정확도를 평균내고, 다시 전체 평균을 계산합니다.

이중 평균 구조 덕분에 특정 분야가 전체 점수를 좌우하지 않습니다. 실무에서 MMLU 점수는 기업 도입 결정에 큰 영향을 미칩니다.

범용 챗봇을 만든다면 MMLU 종합 점수가 높은 모델을 선택합니다. 특정 도메인 서비스라면 해당 분야 세부 점수를 확인합니다.

주의할 점이 있습니다. MMLU는 객관식 시험이라는 한계가 있습니다.

실제 대화에서는 창의적 답변이나 열린 질문에 대한 응답도 중요한데, 이런 능력은 MMLU로 측정되지 않습니다. 또한 영어 기반 평가이므로 한국어 성능과 차이가 있을 수 있습니다.

김개발 씨가 이해했다는 듯 말했습니다. "그러니까 MMLU는 모델의 종합적인 지식 수준을 보는 거네요.

수능 등급 같은 거죠." 팀장이 고개를 끄덕였습니다. "맞아요.

다만 우리 서비스가 특정 분야에 집중한다면 세부 점수도 꼭 확인해야 해요."

실전 팁

💡 - 범용 서비스는 MMLU 종합 점수 80% 이상인 모델을 권장합니다

• 도메인 특화 서비스는 해당 분야의 세부 점수를 반드시 확인하세요

---

5. GSM8K 수학 문제 평가

김개발 씨가 개발 중인 서비스는 가계부 앱이었습니다. 사용자가 "이번 달 식비가 지난달보다 얼마나 늘었어?"라고 물으면 AI가 계산해서 답해야 했습니다.

"수학 계산이 정확한 모델을 찾아야 할 것 같은데요." 박시니어 씨가 말했습니다. "그럼 GSM8K 점수를 봐야겠네요."

GSM8K(Grade School Math 8K)는 초등학교 수준의 수학 문장제 8,500개로 LLM의 수리 추론 능력을 평가합니다. 단순 계산이 아니라 문제를 이해하고 단계별로 풀어나가는 과정을 측정합니다.

마치 수학 서술형 시험처럼 풀이 과정의 논리성도 중요합니다.

다음 코드를 살펴봅시다.

# GSM8K 스타일 문제 해결 예제
def solve_math_problem(problem):
    """
    문제: 영희는 사과 5개를 가지고 있었습니다.
    철수에게 2개를 주고, 엄마에게 1개를 받았습니다.
    영희에게 남은 사과는 몇 개인가요?
    """
    # 단계별 추론 (Chain of Thought)
    steps = []
    initial = 5
    steps.append(f"1단계: 처음 사과 개수 = {initial}")

    after_give = initial - 2
    steps.append(f"2단계: 철수에게 2개 줌 = {after_give}")

    final = after_give + 1
    steps.append(f"3단계: 엄마에게 1개 받음 = {final}")

    for step in steps:
        print(step)
    return final

answer = solve_math_problem("사과 문제")
print(f"정답: {answer}개")

김개발 씨는 가계부 앱의 AI 기능을 테스트하다가 문제를 발견했습니다. "이번 달 총 지출에서 식비가 차지하는 비율은?"이라고 물었더니, 모델이 엉뚱한 답을 내놓았습니다.

"이 모델, 수학을 잘 못하는 것 같아요." 김개발 씨가 투덜거렸습니다. 박시니어 씨가 화면을 보더니 말했습니다.

"GSM8K 점수를 확인해봤어요? 이 모델은 72%밖에 안 되네요." GSM8K는 마치 초등학교 수학 시험과 같습니다.

하지만 단순히 "3 + 5 = ?"를 묻는 게 아닙니다. 실생활 상황을 글로 설명하고, 그 안에서 수학적 관계를 파악해서 풀어야 합니다.

왜 이런 평가가 중요할까요? 계산기도 연산은 할 수 있습니다.

하지만 "영희가 사과를 철수에게 주고 엄마에게 받으면"이라는 문장을 수식으로 변환하는 것은 이해력이 필요합니다. GSM8K는 바로 이 능력을 측정합니다.

최신 모델들은 Chain of Thought(사고 체인) 방식으로 이 문제를 풉니다. 위의 코드처럼 한 번에 답을 내는 게 아니라, 단계별로 추론 과정을 거칩니다.

이렇게 하면 복잡한 문제도 정확하게 풀 수 있습니다. GSM8K의 8,500개 문제는 다양한 유형을 포함합니다.

덧셈, 뺄셈 같은 기본 연산부터 비율 계산, 연립 방정식이 필요한 문제까지 있습니다. 난이도가 다양해서 모델의 수리 능력을 폭넓게 평가할 수 있습니다.

실무에서 이 점수가 중요한 경우가 많습니다. 금융 앱, 쇼핑몰, 물류 시스템 등 숫자를 다루는 서비스라면 GSM8K 점수가 높은 모델을 선택해야 합니다.

계산 실수는 사용자 신뢰를 크게 떨어뜨리기 때문입니다. 주의할 점도 있습니다.

GSM8K는 초등학교 수준의 수학입니다. 미적분이나 선형대수 같은 고급 수학 능력은 MATH 벤치마크 등 다른 평가로 확인해야 합니다.

또한 한글 수학 문제는 영어와 성능이 다를 수 있습니다. 김개발 씨가 다른 모델을 검색했습니다.

"이 모델은 GSM8K 95%네요. 이걸로 바꿔볼까요?" 박시니어 씨가 동의했습니다.

"수학이 핵심인 서비스니까 좋은 선택이에요. 테스트해보고 결정합시다."

실전 팁

💡 - 금융, 쇼핑, 데이터 분석 서비스는 GSM8K 90% 이상 모델을 권장합니다

• 복잡한 계산은 Chain of Thought 프롬프트를 사용하면 정확도가 올라갑니다

---

6. HumanEval 코딩 평가

팀에서 코드 리뷰 자동화 도구를 만들기로 했습니다. 김개발 씨가 후보 모델들을 조사하던 중 HumanEval이라는 벤치마크를 발견했습니다.

"이건 코딩 능력을 평가하는 거네요!" 드디어 자신이 직접 검증할 수 있는 영역이라 반가웠습니다.

HumanEval은 164개의 프로그래밍 문제로 LLM의 코드 생성 능력을 평가합니다. 함수 시그니처와 독스트링을 주고, 모델이 작성한 코드가 테스트 케이스를 통과하는지 확인합니다.

마치 코딩 테스트처럼 실제로 작동하는 코드를 짜야 합니다.

다음 코드를 살펴봅시다.

# HumanEval 스타일 문제 예시
def has_close_elements(numbers: list, threshold: float) -> bool:
    """
    주어진 숫자 리스트에서 threshold보다 가까운
    두 숫자가 있는지 확인합니다.

    >>> has_close_elements([1.0, 2.0, 3.0], 0.5)
    False
    >>> has_close_elements([1.0, 2.8, 3.0], 0.3)
    True
    """
    # LLM이 생성해야 하는 코드
    for i in range(len(numbers)):
        for j in range(i + 1, len(numbers)):
            if abs(numbers[i] - numbers[j]) < threshold:
                return True
    return False

# 테스트 케이스로 검증
assert has_close_elements([1.0, 2.0, 3.0], 0.5) == False
assert has_close_elements([1.0, 2.8, 3.0], 0.3) == True
print("모든 테스트 통과!")

김개발 씨는 개발자로서 HumanEval에 특별한 관심이 갔습니다. 다른 벤치마크는 추상적으로 느껴졌지만, 코딩 테스트는 직접 확인할 수 있었기 때문입니다.

"이 모델이 정말 코드를 잘 짜는지 한번 테스트해볼까요?" 김개발 씨가 제안했습니다. HumanEval은 마치 기술 면접의 코딩 테스트와 같습니다.

문제 설명과 함수 시그니처가 주어지고, 모델은 나머지 코드를 완성해야 합니다. 그리고 숨겨진 테스트 케이스로 정답 여부를 확인합니다.

왜 이런 평가가 필요할까요? 코드는 "그럴듯해 보이는 것"만으로는 부족합니다.

실제로 컴파일되고, 실행되고, 올바른 결과를 내야 합니다. HumanEval은 이 모든 것을 자동으로 검증합니다.

평가 지표는 pass@k로 표시됩니다. pass@1은 한 번에 정답을 맞출 확률이고, pass@10은 10번 시도 중 한 번이라도 맞출 확률입니다.

보통 pass@1이 실질적인 성능 지표로 사용됩니다. 위의 코드 예시를 보겠습니다.

문제는 리스트에서 threshold보다 가까운 두 숫자가 있는지 찾는 것입니다. 독스트링에 예시 입출력이 주어져 있고, 모델은 이를 만족하는 코드를 작성해야 합니다.

마지막의 assert 문이 테스트 케이스 역할을 합니다. 실무에서 HumanEval 점수는 개발 도구 선택에 중요합니다.

코드 자동완성, 버그 수정, 리팩토링 도구를 만든다면 높은 HumanEval 점수가 필수입니다. 코드가 돌아가지 않으면 개발자에게 오히려 방해가 되기 때문입니다.

주의할 점이 있습니다. HumanEval은 Python 위주이고 상대적으로 단순한 알고리즘 문제입니다.

실제 개발에서 중요한 시스템 설계, API 활용, 디버깅 능력 등은 측정하지 못합니다. 최근에는 이를 보완한 HumanEval+나 MBPP 같은 확장 벤치마크도 사용됩니다.

김개발 씨가 여러 모델로 같은 문제를 테스트해봤습니다. 어떤 모델은 완벽한 코드를 생성했고, 어떤 모델은 문법 오류를 냈습니다.

"역시 HumanEval 점수가 높은 모델이 확실히 좋은 코드를 짜네요." 김개발 씨가 만족스러워했습니다.

실전 팁

💡 - 코딩 관련 서비스는 HumanEval pass@1 점수가 70% 이상인 모델을 권장합니다

• Python 외 언어가 필요하면 MultiPL-E 등 다국어 코딩 벤치마크도 확인하세요

---

7. report.md 리포트 생성

프로젝트 막바지, 팀장이 김개발 씨에게 요청했습니다. "모델 비교 결과를 리포트로 정리해줄 수 있어요?

경영진 보고용이에요." 김개발 씨는 지금까지 조사한 벤치마크 데이터를 어떻게 보기 좋게 정리할지 고민에 빠졌습니다.

report.md는 LLM 평가 결과를 마크다운 형식으로 정리한 리포트입니다. 모델별 벤치마크 점수, 장단점 분석, 권장 사항 등을 포함합니다.

마치 컨설팅 보고서처럼 의사결정에 필요한 정보를 체계적으로 담습니다.

다음 코드를 살펴봅시다.

# LLM 평가 리포트 생성 스크립트
def generate_report(models_data, output_path="report.md"):
    report = """# LLM 모델 평가 리포트

## 1. 평가 개요
- 평가 일자: 2024년 12월
- 평가 대상: {model_count}개 모델
- 평가 기준: MMLU, ARC, GSM8K, HumanEval

## 2. 벤치마크 점수 비교
| 모델 | MMLU | ARC-C | GSM8K | HumanEval |
|------|------|-------|-------|-----------|
{score_table}

## 3. 권장 사항
{recommendations}
"""
    # 테이블 생성
    score_rows = "\n".join(
        f"| {m['name']} | {m['mmlu']} | {m['arc']} | {m['gsm8k']} | {m['humaneval']} |"
        for m in models_data
    )

    with open(output_path, "w") as f:
        f.write(report.format(
            model_count=len(models_data),
            score_table=score_rows,
            recommendations="프로젝트 특성에 따라 선택"
        ))
    print(f"리포트 생성 완료: {output_path}")

김개발 씨는 엑셀에 흩어진 데이터를 보며 한숨을 쉬었습니다. 점수는 많은데 이걸 어떻게 경영진이 이해하기 쉽게 정리할 수 있을까요?

박시니어 씨가 조언했습니다. "마크다운으로 깔끔하게 정리해봐요.

GitHub에서도 바로 볼 수 있고, 필요하면 PDF로 변환도 가능해요." report.md를 만드는 목적은 명확합니다. 기술적인 벤치마크 데이터를 의사결정자가 이해할 수 있는 형태로 번역하는 것입니다.

좋은 리포트의 구조는 어떨까요? 먼저 평가 개요가 필요합니다.

언제, 어떤 모델을, 어떤 기준으로 평가했는지 밝힙니다. 그다음 점수 비교 표를 제시합니다.

숫자만 나열하면 안 되고, 테이블 형태로 한눈에 비교할 수 있어야 합니다. 분석 섹션도 중요합니다.

단순히 "A 모델이 1등"이라고 쓰면 안 됩니다. "수학 추론에서는 A 모델이 우세하지만, 코딩에서는 B 모델이 앞선다"처럼 세부적인 인사이트를 제공해야 합니다.

권장 사항은 프로젝트 맥락에 맞게 작성합니다. "범용 챗봇이라면 MMLU가 높은 A 모델을, 코딩 도구라면 HumanEval이 높은 B 모델을 권장합니다"처럼 구체적으로 제안합니다.

위의 코드는 리포트 자동 생성 스크립트입니다. 모델 데이터를 입력받아 마크다운 형식으로 출력합니다.

테이블 생성, 섹션 구성이 자동화되어 있어 반복 작업을 줄일 수 있습니다. 실무에서 이런 리포트는 여러 용도로 활용됩니다.

경영진 보고, 팀 내 공유, 외부 파트너 설득 등에 사용됩니다. 한 번 잘 만들어두면 모델이 업데이트될 때마다 재활용할 수 있습니다.

주의할 점이 있습니다. 벤치마크 점수만 나열하면 안 됩니다.

비용, 응답 속도, API 안정성 같은 실용적 요소도 포함해야 합니다. 또한 벤치마크의 한계점도 언급하는 것이 신뢰성을 높입니다.

김개발 씨가 리포트 초안을 완성했습니다. 팀장이 검토하더니 고개를 끄덕였습니다.

"깔끔하네요. 경영진도 이 정도면 이해할 수 있을 거예요." 김개발 씨는 뿌듯했습니다.

벤치마크 공부를 시작할 때는 막막했는데, 이제는 리포트까지 작성할 수 있게 되었습니다. "다음 프로젝트에서는 처음부터 이 리포트 템플릿을 활용해야겠어요." 김개발 씨가 다짐했습니다.

실전 팁

💡 - 리포트에는 벤치마크 점수뿐 아니라 비용, 속도 등 실용적 요소도 포함하세요

• 마크다운 형식으로 작성하면 버전 관리와 공유가 쉽습니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!