평가-최적화 개요 LLM 자기 개선 패턴 완벽 가이드

LLM이 스스로 결과물을 평가하고 개선하는 평가-최적화 패턴을 다룹니다. 자기 평가 개념부터 반복적 개선 프로세스, 효과적인 피드백 루프 구성까지 실무에서 바로 활용할 수 있는 내용을 담았습니다.

---

목차

1. 평가-최적화 패턴이란?
2. 자기 평가(Self-Evaluation) 개념
3. 반복적 개선 프로세스
4. 패턴의 장점
5. 평가 기준 설계하기
6. 주요 활용 사례 분석
7. 효과적인 피드백 루프 구성

---

1. 평가-최적화 패턴이란?

김개발 씨는 최근 회사에서 LLM을 활용한 프로젝트를 맡게 되었습니다. 첫 번째 결과물을 보고받은 팀장님이 고개를 갸웃거립니다.

"음, 괜찮은데... 이걸 어떻게 더 좋게 만들 수 있을까?" 김개발 씨도 같은 고민에 빠졌습니다.

평가-최적화 패턴은 LLM이 생성한 결과물을 스스로 평가하고, 그 평가를 바탕으로 결과물을 개선하는 반복적인 프로세스입니다. 마치 작가가 원고를 쓰고, 다시 읽어보며 퇴고하는 과정과 같습니다.

이 패턴을 활용하면 단순히 한 번 생성하고 끝나는 것이 아니라, 점진적으로 품질을 높여갈 수 있습니다.

다음 코드를 살펴봅시다.

# 평가-최적화 패턴의 기본 구조
def evaluate_and_optimize(llm, initial_prompt, max_iterations=3):
    # 1단계: 초기 결과 생성
    current_result = llm.generate(initial_prompt)

    for i in range(max_iterations):
        # 2단계: 결과물 평가
        evaluation = llm.evaluate(current_result)

        # 3단계: 품질 기준 충족 시 종료
        if evaluation["score"] >= 0.9:
            break

        # 4단계: 피드백 기반 개선
        current_result = llm.improve(current_result, evaluation["feedback"])

    return current_result

김개발 씨는 입사 2년 차 개발자입니다. 요즘 회사에서는 LLM을 활용한 자동화 프로젝트가 한창입니다.

그런데 문제가 있었습니다. LLM이 생성한 결과물의 품질이 들쭉날쭉했던 것입니다.

어떤 날은 완벽에 가까운 결과가 나오고, 또 어떤 날은 도저히 쓸 수 없는 수준의 결과가 나왔습니다. 김개발 씨는 고민에 빠졌습니다.

"매번 사람이 확인하고 수정해야 하나?" 선배 개발자 박시니어 씨가 다가와 말했습니다. "평가-최적화 패턴을 써보는 건 어때?

LLM이 스스로 자기 결과물을 평가하고 개선하게 만드는 거야." 그렇다면 평가-최적화 패턴이란 정확히 무엇일까요? 쉽게 비유하자면, 이 패턴은 마치 숙련된 작가의 글쓰기 과정과 같습니다.

작가는 초고를 쓴 뒤 바로 출판하지 않습니다. 자신이 쓴 글을 다시 읽어보고, 어색한 부분을 찾아내고, 더 나은 표현으로 다듬습니다.

이 과정을 여러 번 반복하면서 원고의 완성도를 높여갑니다. 평가-최적화 패턴도 마찬가지입니다.

LLM이 결과물을 생성하면, 그 결과물을 다시 LLM에게 보여주며 평가를 요청합니다. "이 결과물의 품질은 어때?

부족한 점은 뭐야?" LLM은 자신이 만든 결과물의 장단점을 분석하고, 개선이 필요한 부분을 지적합니다. 이 패턴이 없던 시절에는 어땠을까요?

개발자들은 LLM의 결과물을 그대로 사용하거나, 일일이 사람이 검토하고 수정해야 했습니다. 전자는 품질을 보장할 수 없고, 후자는 시간과 비용이 많이 들었습니다.

위의 코드를 살펴보겠습니다. 먼저 initial_prompt를 받아 초기 결과를 생성합니다.

그 다음 반복문 안에서 결과물을 평가하고, 점수가 기준에 미달하면 피드백을 바탕으로 개선합니다. 이 과정을 최대 max_iterations번 반복합니다.

실제 현업에서는 콘텐츠 생성, 코드 작성, 번역 등 다양한 분야에서 이 패턴을 활용합니다. 특히 품질이 중요한 업무에서 큰 효과를 발휘합니다.

주의할 점도 있습니다. 무한히 반복하면 오히려 품질이 떨어지거나, 과도한 비용이 발생할 수 있습니다.

따라서 적절한 종료 조건을 설정하는 것이 중요합니다.

실전 팁

💡 - 반복 횟수는 3~5회가 적당합니다

• 평가 기준을 명확하게 정의해야 효과적입니다

---

2. 자기 평가(Self-Evaluation) 개념

"LLM이 자기가 만든 걸 자기가 평가한다고요? 그게 가능해요?" 김개발 씨가 의아한 표정으로 물었습니다.

박시니어 씨가 빙긋 웃으며 대답했습니다. "생각보다 꽤 잘 돼.

핵심은 어떻게 물어보느냐야."

자기 평가란 LLM이 자신이 생성한 결과물을 스스로 분석하고 점수를 매기는 과정입니다. 마치 학생이 시험을 본 뒤 채점표를 보며 자신의 답안을 채점하는 것과 같습니다.

적절한 평가 프롬프트를 설계하면 LLM은 놀라울 정도로 객관적인 평가를 수행할 수 있습니다.

다음 코드를 살펴봅시다.

# 자기 평가 구현 예시
def self_evaluate(llm, content, criteria):
    evaluation_prompt = f"""
    다음 콘텐츠를 평가해주세요.

    [콘텐츠]
    {content}

    [평가 기준]
    {criteria}

    각 기준에 대해 1-10점으로 평가하고,
    구체적인 개선 피드백을 제공해주세요.
    """

    # LLM에게 평가 요청
    evaluation_result = llm.generate(evaluation_prompt)

    return parse_evaluation(evaluation_result)

김개발 씨는 처음에 반신반의했습니다. 자기가 만든 것을 자기가 평가한다니, 그게 과연 객관적일 수 있을까요?

박시니어 씨가 설명을 이어갔습니다. "사람도 마찬가지야.

글을 쓰고 나서 다시 읽어보면 실수가 보이잖아. LLM도 비슷해.

생성할 때와 평가할 때 다른 관점으로 접근하게 만들면 돼." 핵심은 평가 프롬프트를 잘 설계하는 것입니다. 그냥 "이거 어때?"라고 물으면 LLM은 모호한 답변을 내놓습니다.

하지만 구체적인 평가 기준을 제시하면 상황이 달라집니다. 비유하자면, 이것은 마치 요리사가 자신의 음식을 맛보는 것과 같습니다.

요리사는 자신이 만든 음식을 먹어보며 간이 맞는지, 식감이 좋은지, 온도가 적절한지 확인합니다. 명확한 기준이 있기 때문에 객관적인 판단이 가능합니다.

위 코드에서 criteria 변수가 바로 그 역할을 합니다. "명확성은 어떤가?", "논리적 흐름은 자연스러운가?", "문법 오류는 없는가?"와 같은 구체적인 기준을 제시하면 LLM은 각 항목에 대해 체계적으로 평가합니다.

자기 평가의 또 다른 장점은 개선 피드백을 함께 얻을 수 있다는 것입니다. 단순히 "7점"이라고 점수만 매기는 것이 아니라, "두 번째 문단의 논리 전개가 약하다", "결론 부분에 구체적인 예시를 추가하면 좋겠다"와 같은 구체적인 피드백을 받을 수 있습니다.

다만 주의할 점이 있습니다. LLM은 때때로 자신의 결과물에 대해 지나치게 관대하거나, 반대로 지나치게 엄격할 수 있습니다.

따라서 평가 기준을 세밀하게 조정하고, 필요하다면 여러 번 평가하여 평균을 내는 것도 좋은 방법입니다.

실전 팁

💡 - 평가 기준은 5개 이내로 명확하게 정의하세요

• 점수뿐 아니라 구체적인 피드백도 함께 요청하세요

---

3. 반복적 개선 프로세스

"한 번 고치면 끝나는 거 아니에요?" 김개발 씨가 물었습니다. 박시니어 씨가 고개를 저었습니다.

"처음부터 완벽한 건 없어. 여러 번 다듬어야 진짜 좋은 결과가 나와.

마치 조각가가 돌을 깎듯이 말이야."

반복적 개선 프로세스는 평가와 수정을 여러 차례 반복하여 점진적으로 품질을 높이는 방법입니다. 마치 조각가가 거친 돌덩이를 조금씩 깎아 정교한 작품으로 만들어가는 것처럼, 각 반복마다 결과물이 조금씩 나아집니다.

다음 코드를 살펴봅시다.

# 반복적 개선 프로세스 구현
class IterativeOptimizer:
    def __init__(self, llm, max_iterations=5, threshold=0.85):
        self.llm = llm
        self.max_iterations = max_iterations
        self.threshold = threshold
        self.history = []  # 개선 이력 추적

    def optimize(self, initial_content):
        content = initial_content

        for iteration in range(self.max_iterations):
            # 현재 상태 평가
            score, feedback = self.evaluate(content)
            self.history.append({"iteration": iteration, "score": score})

            # 목표 달성 시 종료
            if score >= self.threshold:
                return content, self.history

            # 피드백 기반 개선
            content = self.improve(content, feedback)

        return content, self.history

김개발 씨는 처음에 단순하게 생각했습니다. LLM이 결과를 만들고, 한 번 평가해서 고치면 끝이라고요.

하지만 박시니어 씨의 설명은 달랐습니다. "첫 번째 수정에서 새로운 문제가 생길 수도 있어.

그래서 여러 번 반복하는 거야." 이것은 마치 집을 짓는 과정과 비슷합니다. 기초 공사를 하고, 골조를 세우고, 내부 공사를 하고, 마감을 합니다.

각 단계에서 점검을 하고, 문제가 있으면 수정합니다. 한 번에 완벽한 집을 짓는 것은 불가능합니다.

위 코드에서 핵심은 history 리스트입니다. 이것은 각 반복에서의 점수를 기록합니다.

이 기록을 보면 품질이 어떻게 변화하는지 추적할 수 있습니다. 만약 점수가 오르락내리락한다면, 개선 전략을 수정해야 할 신호입니다.

threshold 값도 중요합니다. 이것은 "이 정도면 충분하다"는 기준점입니다.

완벽을 추구하다 보면 끝없이 반복하게 됩니다. 현실적인 목표를 설정하고, 그 목표에 도달하면 멈추는 것이 효율적입니다.

실무에서는 보통 3~5회 반복이 적당합니다. 연구에 따르면, 대부분의 품질 향상은 처음 몇 번의 반복에서 일어납니다.

그 이후로는 개선 폭이 크게 줄어들기 때문에 비용 대비 효과가 떨어집니다. 한 가지 더 중요한 것은 개선 이력을 추적하는 것입니다.

어떤 피드백이 효과적이었는지, 어떤 유형의 문제가 반복되는지 분석하면, 다음 프로젝트에서 더 효율적인 평가 기준을 설계할 수 있습니다.

실전 팁

💡 - 반복 횟수와 품질 향상의 관계를 모니터링하세요

• 점수가 정체되면 평가 기준이나 개선 전략을 재검토하세요

---

4. 패턴의 장점

"이거 좋은 건 알겠는데, 구체적으로 뭐가 좋은 건가요?" 김개발 씨가 정리가 필요한 표정으로 물었습니다. 박시니어 씨가 손가락을 접어가며 장점을 하나씩 설명하기 시작했습니다.

평가-최적화 패턴의 핵심 장점은 품질 향상, 자동화, 일관성, 비용 효율입니다. 사람의 개입 없이도 안정적인 품질의 결과물을 얻을 수 있으며, 대량 처리가 필요한 상황에서 특히 빛을 발합니다.

다음 코드를 살펴봅시다.

# 패턴 적용 전후 비교 예시
class QualityComparison:
    def compare_approaches(self, test_cases):
        results = {"단순_생성": [], "평가_최적화": []}

        for case in test_cases:
            # 방법 1: 단순 생성 (한 번만)
            simple_result = self.llm.generate(case)
            simple_score = self.evaluate(simple_result)
            results["단순_생성"].append(simple_score)

            # 방법 2: 평가-최적화 패턴 적용
            optimized_result = self.optimize(case)
            optimized_score = self.evaluate(optimized_result)
            results["평가_최적화"].append(optimized_score)

        # 평균 품질 향상률 계산
        improvement = self.calculate_improvement(results)
        return improvement  # 보통 20-40% 향상

박시니어 씨가 첫 번째 손가락을 접었습니다. "첫째, 품질 향상이야." 단순히 한 번 생성하고 끝내는 것과 비교하면, 평가-최적화 패턴을 적용했을 때 품질이 20~40% 향상된다는 연구 결과가 있습니다.

특히 복잡한 작업일수록 그 효과가 두드러집니다. 두 번째 손가락이 접혔습니다.

"둘째, 자동화야." 예전에는 사람이 직접 결과물을 검토하고 수정해야 했습니다. 하지만 이 패턴을 사용하면 LLM이 스스로 품질을 관리합니다.

개발자는 시스템만 설계해두면 됩니다. 밤새 수천 건의 콘텐츠를 처리해도 아침에 결과만 확인하면 됩니다.

세 번째, 일관성입니다. 사람은 피곤하면 실수를 하고, 기분에 따라 판단이 달라질 수 있습니다.

하지만 잘 설계된 평가 기준은 항상 동일한 잣대를 적용합니다. 1번 결과물이든 1000번째 결과물이든 같은 기준으로 평가됩니다.

마지막으로 비용 효율입니다. "어?

여러 번 호출하면 비용이 더 드는 거 아니에요?" 김개발 씨가 반문했습니다. 박시니어 씨가 웃으며 답했습니다.

"그것만 보면 그렇지. 하지만 사람이 검토하고 수정하는 비용을 생각해봐.

또 품질 문제로 다시 작업하는 비용도 있고. 전체적으로 보면 오히려 저렴해." 실제로 많은 기업에서 이 패턴을 도입한 후 전체 운영 비용이 줄었다고 보고합니다.

초기 설정에 시간이 좀 걸리지만, 장기적으로는 확실한 이득입니다.

실전 팁

💡 - 처음에는 소규모 테스트로 효과를 검증하세요

• 품질 향상률과 추가 비용을 함께 모니터링하세요

---

5. 평가 기준 설계하기

"그런데 평가 기준은 어떻게 만들어요?" 김개발 씨가 본격적인 질문을 던졌습니다. 박시니어 씨가 노트북을 열며 말했습니다.

"이게 사실 가장 중요한 부분이야. 평가 기준이 엉망이면 아무리 반복해도 소용없거든."

평가 기준 설계는 평가-최적화 패턴의 성패를 좌우하는 핵심 요소입니다. 마치 시험 문제를 잘 출제해야 학생들의 실력을 정확히 측정할 수 있듯이, 좋은 평가 기준이 있어야 LLM이 올바른 방향으로 개선할 수 있습니다.

다음 코드를 살펴봅시다.

# 체계적인 평가 기준 설계 예시
evaluation_criteria = {
    "정확성": {
        "weight": 0.3,
        "description": "제공된 정보가 사실에 부합하는가?",
        "scoring": "1-10점, 오류 개수에 따라 감점"
    },
    "완전성": {
        "weight": 0.25,
        "description": "필요한 모든 내용을 포함하고 있는가?",
        "scoring": "누락된 핵심 요소당 -2점"
    },
    "명확성": {
        "weight": 0.2,
        "description": "내용이 이해하기 쉽게 작성되었는가?",
        "scoring": "모호한 표현 개수에 따라 감점"
    },
    "구조": {
        "weight": 0.15,
        "description": "논리적 흐름과 구성이 적절한가?",
        "scoring": "단락 간 연결성 평가"
    },
    "톤앤매너": {
        "weight": 0.1,
        "description": "목적에 맞는 어조를 사용했는가?",
        "scoring": "대상 독자 적합성 평가"
    }
}

박시니어 씨가 화면에 평가 기준 예시를 띄웠습니다. 김개발 씨는 생각보다 체계적인 구조에 놀랐습니다.

"평가 기준을 설계할 때 가장 중요한 건 구체성이야." 박시니어 씨가 설명을 시작했습니다. "좋은 글인가?"라고 물으면 LLM은 애매한 답을 내놓습니다.

하지만 "문법 오류가 있는가?", "핵심 키워드가 포함되어 있는가?", "단락 길이가 적절한가?"처럼 구체적으로 물으면 명확한 답을 얻을 수 있습니다. 두 번째로 중요한 것은 가중치입니다.

모든 기준이 똑같이 중요한 것은 아닙니다. 예를 들어 의료 정보를 다루는 콘텐츠라면 정확성의 가중치가 높아야 합니다.

반면 마케팅 카피라면 명확성과 톤앤매너가 더 중요할 수 있습니다. 세 번째는 측정 가능성입니다.

"느낌이 좋은가?"는 측정하기 어렵습니다. 하지만 "능동태 비율이 70% 이상인가?"는 명확하게 측정할 수 있습니다.

가능하면 정량적인 기준을 포함하세요. 위 코드에서 각 기준에는 description과 scoring이 있습니다.

description은 무엇을 평가하는지 설명하고, scoring은 어떻게 점수를 매기는지 구체화합니다. 이렇게 해야 LLM이 일관된 방식으로 평가할 수 있습니다.

한 가지 팁을 더 드리자면, 평가 기준은 처음부터 완벽할 필요가 없습니다. 실제로 적용해보면서 조정하세요.

어떤 기준이 너무 관대한지, 어떤 기준이 너무 엄격한지 데이터를 보면서 튜닝하는 것이 효과적입니다.

실전 팁

💡 - 평가 기준은 5개 이내로 유지하세요

• 각 기준의 가중치 합이 1이 되도록 설계하세요
• 실제 결과를 보며 기준을 조정하세요

---

6. 주요 활용 사례 분석

"이론은 알겠는데, 실제로 어디에 쓰이는 건가요?" 김개발 씨가 실무가 궁금해졌습니다. 박시니어 씨가 그동안 진행했던 프로젝트 폴더를 열었습니다.

"우리 회사에서도 이미 여러 곳에서 쓰고 있어."

평가-최적화 패턴은 콘텐츠 생성, 코드 작성, 번역, 요약 등 다양한 분야에서 활용됩니다. 특히 품질의 일관성이 중요하고 대량 처리가 필요한 업무에서 큰 효과를 발휘합니다.

다음 코드를 살펴봅시다.

# 실무 활용 사례: 마케팅 카피 생성기
class MarketingCopyOptimizer:
    def __init__(self, llm):
        self.llm = llm
        self.criteria = {
            "설득력": "구매 욕구를 자극하는가?",
            "간결성": "핵심 메시지가 명확한가?",
            "브랜드_톤": "브랜드 가이드라인에 부합하는가?",
            "CTA": "행동 유도가 효과적인가?"
        }

    def generate_copy(self, product_info, target_audience):
        # 초기 카피 생성
        copy = self.llm.generate_marketing_copy(product_info)

        # 최대 3회 개선
        for _ in range(3):
            evaluation = self.evaluate_copy(copy, target_audience)
            if evaluation["overall_score"] >= 8.5:
                break
            copy = self.improve_copy(copy, evaluation["suggestions"])

        return copy

박시니어 씨가 첫 번째 사례를 보여주었습니다. "이건 마케팅팀에서 쓰는 카피 생성기야." 매일 수십 개의 광고 카피를 작성해야 하는 마케팅팀에서는 이 패턴이 필수입니다.

카피라이터가 일일이 작성하기에는 시간이 부족하고, 단순히 LLM으로 생성만 하면 품질이 들쭉날쭉합니다. 평가-최적화 패턴을 적용하면 일정 수준 이상의 품질을 안정적으로 유지할 수 있습니다.

두 번째 사례는 코드 리뷰 자동화입니다. LLM이 코드를 작성하고, 다시 LLM이 그 코드를 검토합니다.

버그 가능성, 보안 취약점, 코드 스타일 등을 평가하고 개선합니다. 물론 최종적으로 사람의 검토가 필요하지만, 기본적인 품질 관리가 자동으로 이루어집니다.

세 번째는 다국어 번역입니다. 번역은 단순히 단어를 바꾸는 것이 아니라 뉘앙스와 문맥을 살려야 합니다.

평가-최적화 패턴을 적용하면 자연스러움, 정확성, 현지화 수준을 체크하고 개선할 수 있습니다. 네 번째는 문서 요약입니다.

긴 문서를 요약할 때, 핵심 정보가 빠지거나 왜곡될 수 있습니다. 평가 단계에서 원문의 핵심 포인트가 포함되어 있는지 확인하고, 누락된 부분을 보완합니다.

김개발 씨가 감탄했습니다. "생각보다 적용 범위가 넓네요." 박시니어 씨가 고개를 끄덕였습니다.

"사실 LLM을 쓰는 거의 모든 곳에 적용할 수 있어. 핵심은 그 업무에 맞는 평가 기준을 잘 설계하는 거지."

실전 팁

💡 - 자신의 업무에 맞는 평가 기준부터 설계해보세요

• 처음에는 간단한 케이스로 시작하고 점차 확장하세요

---

7. 효과적인 피드백 루프 구성

"마지막으로 하나만 더 알려줄게." 박시니어 씨가 말했습니다. "평가를 했으면 그 결과를 어떻게 활용하느냐가 중요해.

이걸 피드백 루프라고 해."

피드백 루프는 평가 결과를 개선 과정에 효과적으로 반영하는 메커니즘입니다. 마치 네비게이션이 현재 위치와 목적지를 비교해 경로를 수정하듯, 평가 결과와 목표 기준의 차이를 분석하여 정확한 개선 방향을 제시합니다.

다음 코드를 살펴봅시다.

# 효과적인 피드백 루프 구현
class FeedbackLoop:
    def __init__(self, llm):
        self.llm = llm

    def create_improvement_prompt(self, content, evaluation):
        # 구체적인 개선 지시 생성
        feedback_prompt = f"""
        현재 콘텐츠를 개선해주세요.

        [현재 콘텐츠]
        {content}

        [평가 결과]
        - 전체 점수: {evaluation['score']}/10
        - 주요 문제점: {evaluation['issues']}
        - 구체적 피드백: {evaluation['detailed_feedback']}

        [개선 지시]
        위 피드백을 반영하여 콘텐츠를 수정해주세요.
        특히 {evaluation['priority_issue']}을(를) 최우선으로 개선하세요.
        """

        improved_content = self.llm.generate(feedback_prompt)
        return improved_content

박시니어 씨가 마지막 핵심을 짚었습니다. "평가만 하고 끝내면 의미가 없어.

그 평가를 어떻게 개선에 연결하느냐가 중요해." 피드백 루프는 마치 네비게이션 시스템과 같습니다. 네비게이션은 현재 위치를 파악하고, 목적지와 비교해서, 어느 방향으로 가야 하는지 알려줍니다.

"다음 교차로에서 좌회전하세요"처럼 구체적인 지시를 내립니다. 피드백 루프도 마찬가지입니다.

단순히 "점수가 낮다"고 알려주는 것이 아니라, "두 번째 문단의 논리가 약하다, 예시를 추가해라"처럼 구체적인 개선 방향을 제시해야 합니다. 위 코드에서 핵심은 priority_issue입니다.

여러 문제점 중에서 가장 시급한 것을 지정하면, LLM이 집중해서 개선합니다. 한 번에 모든 것을 고치려고 하면 오히려 혼란스러워질 수 있습니다.

또 하나 중요한 것은 맥락 유지입니다. 개선을 요청할 때 원래 콘텐츠와 평가 결과를 함께 전달해야 합니다.

LLM은 대화의 맥락을 기억하지만, 명시적으로 제공하는 것이 더 정확한 결과를 얻는 방법입니다. 효과적인 피드백 루프를 구성하면 각 반복에서 품질이 확실하게 향상됩니다.

반대로 피드백이 모호하면 같은 실수를 반복하거나, 오히려 품질이 떨어질 수도 있습니다. 김개발 씨는 지금까지 배운 내용을 정리했습니다.

평가-최적화 패턴은 생각보다 단순하면서도 강력했습니다. 결과물을 만들고, 평가하고, 개선하고, 다시 평가하고.

이 순환 과정을 통해 LLM의 출력 품질을 안정적으로 높일 수 있었습니다. "이제 직접 한번 해봐." 박시니어 씨가 키보드를 김개발 씨 앞으로 밀었습니다.

"처음에는 간단한 것부터 시작해. 익숙해지면 점점 복잡한 케이스에도 적용할 수 있을 거야."

실전 팁

💡 - 피드백은 구체적이고 실행 가능하게 작성하세요

• 한 번에 하나의 핵심 이슈에 집중하도록 우선순위를 정하세요
• 개선 전후를 비교하여 피드백의 효과를 검증하세요

---

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