Map-Reduce 패턴 완벽 가이드

대용량 데이터를 효율적으로 처리하는 Map-Reduce 패턴을 배웁니다. 분산 처리의 핵심 개념부터 실제 문서 분석과 병렬 요약 시스템까지 실무 예제로 익혀봅니다.

---

목차

1. Map_단계_분산_처리
2. Reduce_단계_결과_통합
3. 대용량_데이터_처리
4. 실습_문서_분석_파이프라인
5. 실습_병렬_요약_시스템

---

1. Map 단계 분산 처리

어느 날 김개발 씨는 회사에서 긴급 요청을 받았습니다. "고객 리뷰 10만 건을 분석해서 오늘 중으로 보고서를 만들어 주세요." 한 건씩 처리하면 며칠이 걸릴 텐데, 어떻게 해야 할까요?

Map 단계는 큰 작업을 여러 개의 작은 작업으로 쪼개는 과정입니다. 마치 피자를 여러 조각으로 나눠서 친구들과 함께 먹는 것과 같습니다.

혼자 다 먹으려면 오래 걸리지만, 나눠 먹으면 금방이죠. 데이터 처리도 마찬가지입니다.

다음 코드를 살펴봅시다.

from concurrent.futures import ThreadPoolExecutor
from typing import List, Callable

# Map 함수: 데이터를 쪼개서 각각에 함수를 적용합니다
def map_phase(data: List[str], mapper: Callable) -> List[dict]:
    results = []
    # 각 데이터 조각에 mapper 함수를 적용합니다
    for item in data:
        mapped_result = mapper(item)
        results.append(mapped_result)
    return results

# 실제 사용 예시: 리뷰 텍스트를 분석하는 mapper
def analyze_review(review: str) -> dict:
    return {
        "text": review,
        "length": len(review),
        "word_count": len(review.split())
    }

reviews = ["좋은 제품입니다", "배송이 빨라요", "가격이 적당해요"]
mapped_data = map_phase(reviews, analyze_review)

김개발 씨는 입사 6개월 차 주니어 개발자입니다. 오늘 받은 요청은 정말 막막했습니다.

고객 리뷰 10만 건을 분석해야 하는데, 한 건 처리하는 데 0.1초가 걸린다면 총 약 3시간이 필요합니다. 하지만 마감은 오늘 저녁입니다.

선배 개발자 박시니어 씨가 김개발 씨의 고민을 듣고 다가왔습니다. "Map-Reduce 패턴을 써보는 건 어때요?

먼저 Map 단계부터 이해해 봅시다." 그렇다면 Map 단계란 정확히 무엇일까요? 쉽게 비유하자면, Map 단계는 마치 대형 마트의 계산대 시스템과 같습니다.

손님이 100명 줄을 서 있다면, 계산대 하나로는 시간이 오래 걸립니다. 하지만 계산대를 10개 열면 손님들이 분산되어 훨씬 빠르게 처리됩니다.

이처럼 Map 단계도 데이터를 여러 조각으로 나누어 동시에 처리하는 역할을 담당합니다. Map 단계가 없던 시절에는 어땠을까요?

개발자들은 반복문 하나로 데이터를 순차적으로 처리해야 했습니다. 첫 번째 데이터가 끝나야 두 번째를 시작할 수 있었죠.

데이터가 적을 때는 괜찮았지만, 빅데이터 시대가 오면서 이런 방식은 한계에 부딪혔습니다. 하루 종일 돌려도 끝나지 않는 작업이 생겨났습니다.

바로 이런 문제를 해결하기 위해 Map 단계가 등장했습니다. Map 단계를 사용하면 데이터를 독립적인 조각으로 나눌 수 있습니다.

각 조각은 서로 영향을 주지 않으므로 동시에 처리가 가능합니다. 10개로 나누면 이론상 10배 빨라지는 것이죠.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 map_phase 함수를 보면 데이터 리스트와 처리 함수를 받는 것을 알 수 있습니다.

이 함수가 Map 단계의 핵심입니다. 반복문 안에서 각 데이터에 mapper 함수를 적용하고, 결과를 리스트에 담습니다.

마지막으로 모든 처리 결과가 반환됩니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 이커머스 서비스를 개발한다고 가정해봅시다. 매일 쌓이는 수만 건의 주문 데이터에서 배송 지연 건수를 파악해야 합니다.

Map 단계로 주문 데이터를 날짜별로 나누고, 각각에 지연 여부를 판단하는 함수를 적용하면 빠르게 분석할 수 있습니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 의존성이 있는 데이터를 무작정 나누는 것입니다. A 데이터의 결과가 B 데이터 처리에 필요하다면, 이 둘은 나눌 수 없습니다.

따라서 각 조각이 독립적으로 처리 가능한지 먼저 확인해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 데이터를 나누는 게 첫 번째군요!"

실전 팁

💡 - Map 함수는 반드시 순수 함수로 작성하세요. 외부 상태에 의존하면 병렬 처리 시 예상치 못한 버그가 생깁니다.

• 데이터를 나눌 때는 각 조각의 크기가 비슷하도록 균등하게 분배하세요.

---

2. Reduce 단계 결과 통합

김개발 씨는 Map 단계로 리뷰 10만 건을 잘게 쪼개서 분석했습니다. 그런데 결과가 10만 개의 조각으로 나뉘어 있습니다.

이걸 어떻게 하나의 보고서로 만들 수 있을까요?

Reduce 단계는 Map 단계에서 나온 결과들을 하나로 합치는 과정입니다. 마치 퍼즐 조각을 맞춰서 완성된 그림을 만드는 것과 같습니다.

아무리 조각이 많아도 규칙에 따라 차곡차곡 합치면 원하는 결과를 얻을 수 있습니다.

다음 코드를 살펴봅시다.

from functools import reduce
from typing import List, Dict, Any

# Reduce 함수: 여러 결과를 하나로 합칩니다
def reduce_phase(mapped_results: List[dict], reducer) -> dict:
    # 초기값 설정
    initial = {"total_count": 0, "total_words": 0}
    # 모든 결과를 순회하며 하나로 합칩니다
    final_result = reduce(reducer, mapped_results, initial)
    return final_result

# 실제 사용 예시: 분석 결과를 합치는 reducer
def combine_stats(accumulated: dict, current: dict) -> dict:
    return {
        "total_count": accumulated["total_count"] + 1,
        "total_words": accumulated["total_words"] + current["word_count"]
    }

# Map 결과를 Reduce로 통합
mapped_data = [{"word_count": 3}, {"word_count": 2}, {"word_count": 3}]
summary = reduce_phase(mapped_data, combine_stats)
# 결과: {"total_count": 3, "total_words": 8}

김개발 씨는 Map 단계를 성공적으로 마쳤습니다. 리뷰 10만 건이 각각 분석되어 10만 개의 작은 결과물이 생겼습니다.

하지만 팀장님이 원하는 건 "전체 리뷰의 평균 길이"와 "총 단어 수" 같은 통합 지표입니다. 박시니어 씨가 다시 등장합니다.

"이제 Reduce 단계가 필요해요. 조각난 결과들을 하나로 모아야 하거든요." 그렇다면 Reduce 단계란 정확히 무엇일까요?

쉽게 비유하자면, Reduce 단계는 마치 선거 개표 과정과 같습니다. 전국 각지의 투표소에서 개표한 결과가 중앙선거관리위원회로 모입니다.

각 지역의 득표수를 하나씩 더해가며 최종 당선자를 발표하죠. 이처럼 Reduce 단계도 흩어진 결과들을 규칙에 따라 합쳐서 최종 결과를 만들어냅니다.

Reduce 단계가 없다면 어떻게 될까요? Map으로 처리한 결과가 수만 개라면, 이것들을 일일이 확인하고 수동으로 합치는 건 불가능에 가깝습니다.

실수도 생기기 쉽고, 무엇보다 시간이 너무 오래 걸립니다. 결국 분산 처리의 의미가 사라지게 됩니다.

바로 이런 문제를 해결하기 위해 Reduce 단계가 필수적입니다. Reduce 단계를 사용하면 명확한 규칙으로 결과를 합칠 수 있습니다.

덧셈, 평균, 최대값 찾기 등 다양한 연산이 가능합니다. 또한 이 과정도 병렬화할 수 있어서 대량의 결과도 빠르게 처리됩니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 reduce_phase 함수는 Map 결과 리스트와 합치는 규칙인 reducer를 받습니다.

initial은 합치기를 시작할 때의 초기값입니다. Python의 reduce 함수가 리스트를 순회하며 각 요소를 누적해서 합칩니다.

최종적으로 하나의 딕셔너리가 반환됩니다. 실제 현업에서는 어떻게 활용할까요?

로그 분석 시스템을 예로 들어봅시다. 서버 100대에서 발생한 로그를 각각 분석한 뒤, 전체 에러율, 평균 응답 시간, 최대 트래픽 시간대를 계산해야 합니다.

Reduce 단계에서 각 서버의 분석 결과를 합치면 전체 시스템의 상태를 한눈에 파악할 수 있습니다. 하지만 주의할 점도 있습니다.

reducer 함수는 결합 법칙을 만족해야 합니다. 즉, (A + B) + C와 A + (B + C)의 결과가 같아야 합니다.

그렇지 않으면 병렬로 Reduce를 수행할 때 순서에 따라 결과가 달라질 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

"Map과 Reduce가 짝을 이루는군요! 쪼개고, 합치고." 김개발 씨의 눈이 반짝입니다.

실전 팁

💡 - Reduce 함수의 초기값을 신중하게 설정하세요. 빈 리스트가 들어와도 에러가 나지 않아야 합니다.

• 가능하면 Reduce도 병렬로 수행하세요. 트리 구조로 합치면 훨씬 빠릅니다.

---

3. 대용량 데이터 처리

김개발 씨는 Map-Reduce의 기본을 익혔습니다. 그런데 실제로 10만 건을 처리하려니 또 다른 고민이 생겼습니다.

메모리는 충분할까요? 동시에 얼마나 처리할 수 있을까요?

대용량 데이터 처리는 단순히 분산만으로는 부족합니다. 청크 단위로 나누기, 메모리 관리, 병렬 처리 수준 조절이 필요합니다.

마치 고속도로에서 차선을 늘리고 톨게이트를 효율적으로 배치하는 것처럼, 데이터의 흐름을 잘 설계해야 합니다.

다음 코드를 살펴봅시다.

from concurrent.futures import ProcessPoolExecutor, as_completed
from typing import List, Iterator
import math

# 대용량 데이터를 청크 단위로 나눕니다
def chunk_data(data: List, chunk_size: int) -> Iterator[List]:
    for i in range(0, len(data), chunk_size):
        yield data[i:i + chunk_size]

# 병렬로 Map-Reduce를 실행합니다
def parallel_map_reduce(data: List, mapper, reducer, workers: int = 4):
    chunk_size = math.ceil(len(data) / workers)
    chunks = list(chunk_data(data, chunk_size))

    # 병렬로 Map 단계 실행
    with ProcessPoolExecutor(max_workers=workers) as executor:
        futures = [executor.submit(process_chunk, chunk, mapper) for chunk in chunks]
        mapped_results = []
        for future in as_completed(futures):
            mapped_results.extend(future.result())

    # Reduce 단계로 결과 통합
    return reduce(reducer, mapped_results, {})

def process_chunk(chunk: List, mapper) -> List:
    return [mapper(item) for item in chunk]

김개발 씨는 의기양양하게 코드를 실행했습니다. 그런데 10만 건 데이터를 메모리에 한꺼번에 올리자 컴퓨터가 버벅거리기 시작합니다.

"아, 메모리가 부족하네요..." 박시니어 씨가 조언합니다. "데이터를 한 번에 다 올리면 안 돼요.

청크 단위로 나눠서 처리해야 해요." 그렇다면 대용량 데이터 처리란 정확히 무엇일까요? 쉽게 비유하자면, 이사할 때 짐을 나르는 과정과 같습니다.

모든 짐을 한 번에 트럭에 싣기보다는, 박스 단위로 나눠서 여러 번 나르는 게 효율적입니다. 트럭 용량에 맞게 짐을 분배하고, 여러 사람이 동시에 나르면 더 빠르죠.

데이터 처리도 마찬가지입니다. 대용량 처리를 제대로 하지 않으면 어떻게 될까요?

메모리 부족으로 프로그램이 강제 종료될 수 있습니다. 또는 처리 속도가 급격히 느려지는 스래싱 현상이 발생합니다.

최악의 경우 서버 전체가 다운되어 다른 서비스에도 영향을 줄 수 있습니다. 바로 이런 문제를 해결하기 위해 체계적인 대용량 처리 전략이 필요합니다.

첫째, 청크 분할입니다. 데이터를 적절한 크기로 나눠서 메모리에 순차적으로 올립니다.

둘째, 병렬 워커 관리입니다. CPU 코어 수에 맞게 동시 처리 개수를 조절합니다.

셋째, 제너레이터 활용입니다. 리스트 대신 제너레이터를 쓰면 메모리를 크게 절약할 수 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. chunk_data 함수는 큰 리스트를 지정된 크기로 쪼갭니다.

yield를 사용해서 제너레이터로 만들었기 때문에 메모리 효율이 좋습니다. ProcessPoolExecutor는 여러 프로세스를 생성해서 각 청크를 병렬로 처리합니다.

as_completed는 완료되는 순서대로 결과를 가져와서 대기 시간을 줄입니다. 실제 현업에서는 어떻게 활용할까요?

데이터 파이프라인을 운영하는 회사를 예로 들어봅시다. 매일 밤 수천만 건의 로그를 분석해야 합니다.

서버 메모리는 16GB로 한정되어 있고요. 이때 1만 건씩 청크로 나누고, 8개의 워커로 병렬 처리하면 메모리 문제 없이 빠르게 분석을 완료할 수 있습니다.

하지만 주의할 점도 있습니다. 워커 수를 무작정 늘리면 오히려 느려질 수 있습니다.

프로세스 간 통신 비용이 증가하기 때문입니다. 보통 CPU 코어 수를 기준으로 워커 수를 설정하는 것이 좋습니다.

또한 청크 크기가 너무 작으면 오버헤드가 커지고, 너무 크면 메모리 문제가 생깁니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

청크 크기를 1000으로 조절하고 워커를 4개로 설정하자, 10만 건 데이터가 부드럽게 처리되었습니다. "오, 진짜 빠르다!"

실전 팁

💡 - 청크 크기는 사용 가능한 메모리의 10-20% 정도로 설정하세요.

• I/O 바운드 작업은 ThreadPoolExecutor, CPU 바운드 작업은 ProcessPoolExecutor를 사용하세요.
• 진행 상황을 모니터링하려면 tqdm 라이브러리를 활용하세요.

---

4. 실습 문서 분석 파이프라인

이론은 충분히 배웠습니다. 이제 김개발 씨는 실제로 문서 분석 파이프라인을 구축해보려 합니다.

여러 개의 텍스트 문서에서 키워드를 추출하고, 빈도를 분석하는 시스템을 만들어볼까요?

문서 분석 파이프라인은 Map-Reduce 패턴의 대표적인 활용 사례입니다. 여러 문서를 병렬로 분석하고, 결과를 통합해서 전체 문서군의 특성을 파악합니다.

검색 엔진, 추천 시스템, 텍스트 마이닝의 기초가 되는 중요한 기술입니다.

다음 코드를 살펴봅시다.

import re
from collections import Counter
from concurrent.futures import ThreadPoolExecutor
from typing import List, Dict

# 문서에서 단어 빈도를 추출하는 Mapper
def word_count_mapper(document: str) -> Dict[str, int]:
    # 특수문자 제거 및 소문자 변환
    words = re.findall(r'\b\w+\b', document.lower())
    # 각 문서의 단어 빈도 계산
    return dict(Counter(words))

# 여러 문서의 빈도를 합치는 Reducer
def word_count_reducer(acc: Dict[str, int], curr: Dict[str, int]) -> Dict[str, int]:
    result = acc.copy()
    for word, count in curr.items():
        result[word] = result.get(word, 0) + count
    return result

# 문서 분석 파이프라인 실행
def analyze_documents(documents: List[str], max_workers: int = 4) -> Dict[str, int]:
    with ThreadPoolExecutor(max_workers=max_workers) as executor:
        # Map 단계: 각 문서를 병렬로 분석
        mapped_results = list(executor.map(word_count_mapper, documents))
    # Reduce 단계: 결과 통합
    from functools import reduce
    return reduce(word_count_reducer, mapped_results, {})

김개발 씨에게 새로운 과제가 주어졌습니다. 회사 블로그에 올라온 글 500개를 분석해서 가장 많이 사용된 키워드를 찾아달라는 요청입니다.

이제 Map-Reduce를 직접 적용해볼 시간입니다. 박시니어 씨가 옆에서 지켜봅니다.

"문서 분석은 Map-Reduce의 고전적인 활용 사례예요. 차근차근 해봐요." 문서 분석 파이프라인이란 무엇일까요?

쉽게 비유하자면, 여러 권의 책에서 공통으로 많이 등장하는 단어를 찾는 것과 같습니다. 한 명이 모든 책을 읽으면 오래 걸리지만, 여러 명이 책을 나눠 읽고 각자 단어 목록을 만든 뒤 합치면 훨씬 빠릅니다.

이것이 바로 문서 분석 파이프라인의 핵심입니다. 이런 분석이 왜 필요할까요?

마케팅팀은 고객들이 어떤 단어에 관심 있는지 알고 싶어합니다. 검색팀은 문서의 주제를 자동으로 분류하고 싶습니다.

추천 시스템은 비슷한 문서를 찾아야 합니다. 이 모든 것의 기초가 바로 단어 빈도 분석입니다.

위의 코드를 단계별로 살펴보겠습니다. 먼저 word_count_mapper 함수를 봅시다.

이 함수는 하나의 문서를 받아서 단어 빈도를 계산합니다. 정규표현식으로 단어만 추출하고, 소문자로 통일해서 "Hello"와 "hello"를 같은 단어로 처리합니다.

Counter 클래스가 빈도 계산을 간편하게 해줍니다. 다음으로 word_count_reducer 함수를 봅시다.

두 개의 빈도 딕셔너리를 받아서 하나로 합칩니다. 같은 단어가 있으면 빈도를 더하고, 새로운 단어면 그대로 추가합니다.

analyze_documents 함수가 전체 파이프라인을 조율합니다. ThreadPoolExecutor로 Map 단계를 병렬 실행하고, reduce로 결과를 통합합니다.

실제 현업에서는 이 파이프라인을 어떻게 확장할까요? 검색 엔진을 만든다면 TF-IDF 계산을 추가할 수 있습니다.

감성 분석을 한다면 긍정/부정 단어 비율을 계산하는 mapper를 만들 수 있습니다. 스팸 필터라면 스팸 특성 단어의 빈도를 추출할 수 있습니다.

기본 구조는 같고, mapper와 reducer만 바꾸면 됩니다. 하지만 주의할 점도 있습니다.

불용어(the, is, a 같은 의미 없는 단어) 처리를 빼먹으면 안 됩니다. 또한 한국어는 형태소 분석기를 사용해야 정확한 결과를 얻을 수 있습니다.

영어와 달리 띄어쓰기만으로 단어를 구분하기 어렵기 때문입니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

500개 블로그 글을 분석한 결과, "인공지능", "데이터", "서비스"가 가장 많이 등장한 키워드였습니다. 팀장님이 흡족해하며 말합니다.

"역시 우리 회사는 AI 회사야!"

실전 팁

💡 - 한국어 문서는 konlpy, mecab 등의 형태소 분석기를 함께 사용하세요.

• 불용어 리스트를 만들어서 의미 없는 단어를 필터링하세요.
• 결과를 시각화할 때는 wordcloud 라이브러리가 유용합니다.

---

5. 실습 병렬 요약 시스템

김개발 씨의 마지막 도전입니다. LLM을 활용해서 여러 문서를 동시에 요약하는 시스템을 만들어달라는 요청이 왔습니다.

Map-Reduce 패턴으로 대규모 문서 요약을 어떻게 효율적으로 처리할 수 있을까요?

병렬 요약 시스템은 LLM과 Map-Reduce를 결합한 고급 활용 사례입니다. 각 문서를 개별적으로 요약하는 Map 단계와, 요약들을 다시 합쳐서 최종 요약을 만드는 Reduce 단계로 구성됩니다.

대량의 문서를 빠르게 요약해야 할 때 매우 유용합니다.

다음 코드를 살펴봅시다.

from concurrent.futures import ThreadPoolExecutor
from typing import List
import asyncio

# 가상의 LLM API 호출 (실제로는 OpenAI, Claude 등 사용)
def call_llm(prompt: str) -> str:
    # 실제 구현에서는 API 호출
    return f"요약: {prompt[:50]}..."

# Map 단계: 개별 문서 요약
def summarize_document(document: str) -> str:
    prompt = f"다음 문서를 3문장으로 요약해주세요:\n\n{document}"
    return call_llm(prompt)

# Reduce 단계: 요약들을 합쳐서 최종 요약 생성
def combine_summaries(summaries: List[str]) -> str:
    combined = "\n".join(summaries)
    prompt = f"다음 요약들을 하나의 통합 요약으로 만들어주세요:\n\n{combined}"
    return call_llm(prompt)

# 병렬 요약 파이프라인
def parallel_summarize(documents: List[str], max_workers: int = 5) -> str:
    # Map 단계: 병렬로 각 문서 요약
    with ThreadPoolExecutor(max_workers=max_workers) as executor:
        summaries = list(executor.map(summarize_document, documents))
    # Reduce 단계: 요약들을 통합
    final_summary = combine_summaries(summaries)
    return final_summary

김개발 씨는 이제 Map-Reduce의 고수가 되었습니다. 오늘은 더 도전적인 과제입니다.

회의록 100개를 분석해서 프로젝트 진행 상황을 한 페이지로 요약해달라는 요청이 왔습니다. LLM을 쓰면 되지만, 100개를 순차적으로 요약하면 시간이 너무 오래 걸립니다.

박시니어 씨가 힌트를 줍니다. "Map-Reduce로 병렬 요약을 해보는 건 어때요?

LLM API는 동시에 여러 번 호출할 수 있잖아요." 병렬 요약 시스템이란 무엇일까요? 쉽게 비유하자면, 신문사의 편집 과정과 같습니다.

각 기자가 자신의 담당 분야 기사를 작성합니다. 그 다음 편집장이 모든 기사를 모아서 1면 헤드라인을 정합니다.

각 기자의 작업이 Map 단계이고, 편집장의 작업이 Reduce 단계입니다. 왜 이런 방식이 필요할까요?

LLM에는 컨텍스트 윈도우 제한이 있습니다. 문서 100개를 한 번에 넣을 수 없습니다.

또한 순차 처리는 너무 느립니다. 문서 하나 요약에 5초가 걸린다면, 100개는 약 8분이 필요합니다.

하지만 10개씩 병렬로 처리하면 약 50초로 줄어듭니다. 위의 코드를 단계별로 살펴보겠습니다.

summarize_document 함수가 Map 단계를 담당합니다. 각 문서를 받아서 LLM에게 요약을 요청합니다.

이 함수는 완전히 독립적이라서 병렬 실행이 가능합니다. combine_summaries 함수가 Reduce 단계를 담당합니다.

개별 요약들을 모아서 다시 LLM에게 통합 요약을 요청합니다. 이렇게 하면 원본 문서 전체를 넣지 않아도 핵심 내용을 담은 최종 요약을 얻을 수 있습니다.

parallel_summarize 함수가 파이프라인을 조율합니다. ThreadPoolExecutor로 Map 단계를 병렬 실행하고, 모든 요약이 완료되면 Reduce 단계를 진행합니다.

실제 현업에서는 이 시스템을 어떻게 발전시킬 수 있을까요? 계층적 Reduce를 적용할 수 있습니다.

요약이 100개라면, 먼저 10개씩 묶어서 10개의 중간 요약을 만들고, 다시 이것들을 합쳐서 최종 요약을 만듭니다. 이렇게 하면 더 정확한 결과를 얻을 수 있습니다.

하지만 주의할 점도 있습니다. LLM API에는 보통 Rate Limit이 있습니다.

동시에 너무 많이 호출하면 에러가 발생합니다. 따라서 max_workers를 API 제한에 맞게 설정해야 합니다.

또한 요약 과정에서 중요한 정보가 손실될 수 있으므로, 핵심 키워드는 별도로 추출해두는 것이 좋습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

회의록 100개가 5분 만에 한 페이지 요약으로 정리되었습니다. 팀장님이 감탄합니다.

"이걸 매주 자동으로 돌리면 프로젝트 현황 파악이 훨씬 쉬워지겠네!" 김개발 씨는 뿌듯한 마음으로 퇴근 준비를 합니다. Map-Reduce 패턴 덕분에 대용량 데이터 처리가 더 이상 두렵지 않습니다.

실전 팁

💡 - LLM API의 Rate Limit을 확인하고 max_workers를 적절히 설정하세요.

• 비용 절감을 위해 작은 모델로 1차 요약을 하고, 큰 모델로 최종 요약을 하는 전략도 좋습니다.
• 요약 품질을 높이려면 프롬프트에 구체적인 지시사항을 추가하세요.

---

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