Parallel Workflow 완벽 가이드

LLM과 AI 에이전트에서 병렬 워크플로를 구현하는 방법을 알아봅니다. 여러 작업을 동시에 처리하여 성능을 극대화하는 패턴과 실무 기법을 다룹니다.

---

목차

1. 병렬 실행 패턴
2. 결과 집계
3. 동기화
4. 실습: 병렬 데이터 처리
5. 실습: 성능 비교

---

1. 병렬 실행 패턴

김개발 씨는 LLM 에이전트를 개발하던 중 고민에 빠졌습니다. 사용자의 질문에 답하려면 웹 검색, 데이터베이스 조회, 문서 분석을 모두 해야 하는데, 하나씩 순서대로 처리하니 응답 시간이 10초가 넘어갔습니다.

"이걸 동시에 처리하면 훨씬 빠르지 않을까?"

병렬 실행 패턴은 서로 의존성이 없는 여러 작업을 동시에 실행하는 방식입니다. 마치 식당에서 요리사 한 명이 모든 음식을 순서대로 만드는 것이 아니라, 여러 요리사가 각자의 요리를 동시에 만드는 것과 같습니다.

이를 통해 전체 처리 시간을 획기적으로 줄일 수 있습니다.

다음 코드를 살펴봅시다.

import asyncio
from typing import List, Any

# 병렬로 실행할 작업들을 정의합니다
async def search_web(query: str) -> dict:
    await asyncio.sleep(2)  # 웹 검색 시뮬레이션
    return {"source": "web", "result": f"웹 검색 결과: {query}"}

async def query_database(query: str) -> dict:
    await asyncio.sleep(1)  # DB 조회 시뮬레이션
    return {"source": "db", "result": f"DB 조회 결과: {query}"}

async def analyze_document(query: str) -> dict:
    await asyncio.sleep(3)  # 문서 분석 시뮬레이션
    return {"source": "doc", "result": f"문서 분석 결과: {query}"}

# 핵심: asyncio.gather로 모든 작업을 동시에 실행합니다
async def parallel_execute(query: str) -> List[dict]:
    results = await asyncio.gather(
        search_web(query),
        query_database(query),
        analyze_document(query)
    )
    return results

김개발 씨는 입사 6개월 차 AI 개발자입니다. 요즘 한창 LLM 에이전트 프로젝트를 진행하고 있는데, 성능 문제로 골머리를 앓고 있었습니다.

"김 씨, 왜 이렇게 응답이 느린 거예요?" 팀장님의 질문에 김개발 씨는 당황했습니다. 분명히 기능은 잘 동작하는데, 사용자 응답까지 너무 오래 걸렸습니다.

옆자리 선배 박시니어 씨가 코드를 살펴봤습니다. "아, 여기가 문제네요.

웹 검색 끝나고, DB 조회하고, 그 다음에 문서 분석하고... 전부 순차적으로 처리하고 있잖아요." 그렇다면 병렬 실행 패턴이란 정확히 무엇일까요?

쉽게 비유하자면, 이것은 마치 카페에서 음료를 만드는 것과 같습니다. 손님 세 명이 각각 아메리카노, 라떼, 스무디를 주문했다고 생각해보세요.

바리스타 한 명이 순서대로 만들면 15분이 걸립니다. 하지만 바리스타 세 명이 동시에 만들면 5분이면 충분합니다.

병렬 실행도 마찬가지로 독립적인 작업을 동시에 처리합니다. 병렬 실행이 없던 시절에는 어땠을까요?

개발자들은 모든 작업을 순차적으로 처리해야 했습니다. 작업 A가 끝나야 작업 B를 시작하고, 작업 B가 끝나야 작업 C를 시작했습니다.

각 작업이 3초씩 걸린다면 총 9초가 필요했습니다. 사용자는 그 긴 시간 동안 로딩 화면만 바라봐야 했습니다.

바로 이런 문제를 해결하기 위해 병렬 실행 패턴이 등장했습니다. Python에서는 asyncio.gather를 사용하면 여러 비동기 작업을 동시에 실행할 수 있습니다.

위 코드에서 세 가지 작업은 각각 2초, 1초, 3초가 걸립니다. 순차 실행하면 6초가 걸리지만, 병렬 실행하면 가장 오래 걸리는 3초만에 모든 결과를 얻을 수 있습니다.

코드를 자세히 살펴보겠습니다. 먼저 각 함수는 async def로 정의된 비동기 함수입니다.

이 함수들은 await 키워드로 대기할 수 있으며, 대기하는 동안 다른 작업이 실행될 수 있습니다. 핵심은 asyncio.gather 부분입니다.

이 함수는 여러 코루틴을 받아서 동시에 실행하고, 모든 결과가 준비되면 리스트로 반환합니다. 마치 여러 개의 실을 한 번에 꿰어서 한꺼번에 당기는 것과 같습니다.

실제 LLM 에이전트에서는 이 패턴을 어떻게 활용할까요? 예를 들어 RAG 시스템에서 사용자 질문에 답하려면 벡터 검색, 키워드 검색, 외부 API 호출을 모두 수행해야 합니다.

이 작업들은 서로 의존성이 없으므로 병렬로 실행할 수 있습니다. 하지만 주의할 점도 있습니다.

모든 작업을 병렬로 실행할 수 있는 것은 아닙니다. 작업 간에 의존성이 있다면, 즉 A의 결과가 있어야 B를 실행할 수 있다면, 순차 실행이 필요합니다.

무작정 병렬화하면 오히려 버그가 발생할 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 조언을 듣고 코드를 병렬 실행 패턴으로 수정했더니, 응답 시간이 10초에서 4초로 줄어들었습니다. "와, 이렇게 간단한 변경으로 이렇게 빨라지다니!"

실전 팁

💡 - 병렬 실행은 작업 간 의존성이 없을 때만 사용하세요

• asyncio.gather는 모든 작업이 완료될 때까지 기다립니다

---

2. 결과 집계

김개발 씨는 병렬 실행을 성공적으로 구현했습니다. 하지만 새로운 문제가 생겼습니다.

세 가지 소스에서 받아온 결과를 어떻게 하나로 합쳐야 할까요? 웹 검색 결과, DB 조회 결과, 문서 분석 결과가 뒤죽박죽 섞여 있었습니다.

결과 집계는 병렬로 실행된 여러 작업의 결과를 의미 있는 형태로 통합하는 과정입니다. 마치 여러 탐정이 수집한 단서들을 한데 모아 사건의 전체 그림을 완성하는 것과 같습니다.

올바른 집계 전략을 사용하면 분산된 정보를 가치 있는 통찰로 변환할 수 있습니다.

다음 코드를 살펴봅시다.

from typing import List, Dict, Any
from dataclasses import dataclass

@dataclass
class AggregatedResult:
    combined_text: str
    sources: List[str]
    confidence: float

# 병렬 실행 결과를 집계하는 함수
def aggregate_results(results: List[Dict[str, Any]]) -> AggregatedResult:
    # 각 소스별 결과를 추출합니다
    texts = [r["result"] for r in results]
    sources = [r["source"] for r in results]

    # 결과를 하나의 텍스트로 결합합니다
    combined = "\n---\n".join(texts)

    # 신뢰도 계산: 소스가 많을수록 높아집니다
    confidence = min(len(results) / 3.0, 1.0)

    return AggregatedResult(
        combined_text=combined,
        sources=sources,
        confidence=confidence
    )

# 가중치 기반 집계: 소스별 중요도를 다르게 적용
def weighted_aggregate(results: List[Dict], weights: Dict[str, float]) -> str:
    sorted_results = sorted(
        results,
        key=lambda r: weights.get(r["source"], 0.5),
        reverse=True
    )
    return "\n".join([r["result"] for r in sorted_results])

병렬 실행을 마친 김개발 씨 앞에는 세 가지 결과가 놓여 있었습니다. 웹에서 가져온 정보, 데이터베이스의 정보, 문서에서 추출한 정보.

각각은 훌륭했지만, 이것을 사용자에게 어떻게 보여줘야 할지 막막했습니다. "결과가 세 개나 있는데, 그냥 다 보여주면 되는 거 아닌가요?" 김개발 씨가 물었습니다.

박시니어 씨가 고개를 저었습니다. "그러면 중복된 정보도 보이고, 중요한 정보가 뒤에 숨어버릴 수도 있어요.

결과 집계 전략이 필요합니다." 결과 집계란 무엇일까요? 마치 신문사의 편집장과 같습니다.

여러 기자가 같은 사건을 취재해서 기사를 보내옵니다. 편집장은 이 기사들을 검토하고, 중복을 제거하고, 가장 중요한 내용을 앞에 배치하여 하나의 완성된 기사를 만들어냅니다.

결과 집계도 마찬가지로 분산된 정보를 통합합니다. 집계 전략에는 여러 가지가 있습니다.

가장 단순한 것은 단순 결합입니다. 모든 결과를 그대로 이어붙입니다.

구현은 쉽지만 중복 정보가 그대로 남는 단점이 있습니다. 다음은 가중치 기반 정렬입니다.

각 소스의 신뢰도나 중요도에 따라 가중치를 부여합니다. 위 코드에서 weights 딕셔너리를 통해 소스별 가중치를 설정할 수 있습니다.

데이터베이스 결과가 웹 검색보다 신뢰도가 높다면 가중치를 높게 설정합니다. 세 번째는 중복 제거 집계입니다.

여러 소스에서 같은 정보가 나왔다면 하나만 남기고 제거합니다. 다만 완전히 같은 텍스트만 제거할 것인지, 의미적으로 유사한 것도 제거할 것인지 결정해야 합니다.

코드를 살펴보면 dataclass를 사용하여 집계 결과의 구조를 정의했습니다. combined_text에는 결합된 텍스트가, sources에는 출처 목록이, confidence에는 신뢰도 점수가 저장됩니다.

이렇게 구조화하면 이후 처리가 훨씬 수월해집니다. LLM 에이전트에서 특히 중요한 것은 출처 추적입니다.

사용자가 "이 정보가 어디서 왔나요?"라고 물었을 때 대답할 수 있어야 합니다. 그래서 집계할 때 각 정보의 출처를 함께 보관해야 합니다.

주의할 점도 있습니다. 결과를 집계할 때 정보가 손실되지 않도록 해야 합니다.

중복 제거를 너무 공격적으로 하면 미묘하게 다른 중요한 정보까지 삭제될 수 있습니다. 따라서 집계 전에 원본 결과를 별도로 저장해두는 것이 좋습니다.

박시니어 씨의 조언을 듣고 김개발 씨는 가중치 기반 집계를 구현했습니다. 데이터베이스 결과를 가장 앞에, 그 다음 문서 분석, 마지막으로 웹 검색 결과를 배치했습니다.

훨씬 깔끔하고 신뢰할 수 있는 응답이 완성되었습니다.

실전 팁

💡 - 항상 원본 결과를 보관하고 집계는 사본으로 수행하세요

• 소스별 신뢰도에 따라 가중치를 다르게 설정하세요

---

3. 동기화

김개발 씨는 병렬 실행과 결과 집계까지 완벽하게 구현했습니다. 그런데 테스트 중 이상한 현상을 발견했습니다.

가끔 같은 요청에 다른 결과가 나왔습니다. 알고 보니 병렬로 실행되는 작업들이 같은 리소스에 동시에 접근하면서 문제가 생긴 것이었습니다.

동기화는 여러 병렬 작업이 공유 리소스에 안전하게 접근하도록 조율하는 메커니즘입니다. 마치 화장실 문에 달린 잠금장치처럼, 한 번에 하나의 작업만 특정 리소스를 사용할 수 있도록 보장합니다.

동기화 없이 병렬 처리를 하면 데이터 충돌과 예측 불가능한 버그가 발생합니다.

다음 코드를 살펴봅시다.

import asyncio
from typing import Dict, Any

class SharedState:
    def __init__(self):
        self.cache: Dict[str, Any] = {}
        self._lock = asyncio.Lock()  # 동기화를 위한 Lock

    # Lock을 사용하여 안전하게 캐시에 접근합니다
    async def get_or_set(self, key: str, fetch_func) -> Any:
        async with self._lock:  # 이 블록은 한 번에 하나만 실행됩니다
            if key in self.cache:
                return self.cache[key]

            value = await fetch_func()
            self.cache[key] = value
            return value

# 세마포어로 동시 실행 개수 제한하기
async def limited_parallel_execute(tasks, max_concurrent: int = 3):
    semaphore = asyncio.Semaphore(max_concurrent)

    async def limited_task(task):
        async with semaphore:  # 최대 max_concurrent개만 동시 실행
            return await task

    return await asyncio.gather(*[limited_task(t) for t in tasks])

테스트를 반복하던 김개발 씨는 이상한 점을 발견했습니다. 분명 같은 질문인데 어떨 때는 결과가 세 개, 어떨 때는 두 개만 나왔습니다.

더 심각한 건 가끔 에러가 발생한다는 것이었습니다. "혹시 캐시 접근할 때 문제가 있는 거 아니에요?" 박시니어 씨가 물었습니다.

코드를 다시 살펴보니 문제가 보였습니다. 세 개의 병렬 작업이 모두 같은 캐시 딕셔너리에 동시에 접근하고 있었습니다.

한 작업이 캐시를 읽는 동안 다른 작업이 캐시를 수정하면서 충돌이 발생한 것입니다. 이것이 바로 경쟁 상태라는 문제입니다.

비유하자면 이런 상황입니다. 두 사람이 같은 은행 계좌에서 동시에 출금하려고 합니다.

잔액이 100만 원인데, 두 사람 모두 70만 원을 출금하려 합니다. 첫 번째 사람이 잔액을 확인하고 "100만 원이니까 출금 가능!" 하는 사이, 두 번째 사람도 잔액을 확인합니다.

아직 첫 번째 출금이 완료되지 않았으니 역시 "100만 원이니까 출금 가능!" 결국 140만 원이 출금됩니다. Lock은 이 문제를 해결합니다.

화장실 문의 잠금장치처럼, 누군가 안에 있으면 다른 사람은 밖에서 기다려야 합니다. 코드에서 async with self._lock 부분이 바로 그 역할을 합니다.

이 블록 안의 코드는 한 번에 하나의 작업만 실행할 수 있습니다. 하지만 Lock을 남용하면 병렬 처리의 장점이 사라집니다.

모든 곳에 Lock을 걸면 결국 순차 실행과 다를 바 없어집니다. 따라서 정말 필요한 곳에만 Lock을 사용해야 합니다.

또 다른 동기화 도구로 Semaphore가 있습니다. Lock이 "한 번에 하나만"이라면, Semaphore는 "한 번에 N개까지"입니다.

예를 들어 외부 API가 동시 요청을 5개까지만 허용한다면, Semaphore를 5로 설정하여 그 이상은 대기하도록 할 수 있습니다. 위 코드의 limited_parallel_execute 함수를 보세요.

max_concurrent 매개변수로 동시 실행 개수를 제한합니다. 100개의 작업이 있더라도 한 번에 3개씩만 실행됩니다.

이렇게 하면 시스템 리소스를 보호하면서도 병렬 처리의 이점을 누릴 수 있습니다. LLM 에이전트에서 동기화가 특히 중요한 경우가 있습니다.

토큰 사용량 추적, 대화 히스토리 관리, 캐시 업데이트 등이 그렇습니다. 이런 공유 상태를 제대로 동기화하지 않으면 데이터가 꼬이거나 중복 청구가 발생할 수 있습니다.

동기화에서 주의할 점은 교착 상태입니다. A가 B를 기다리고, B가 A를 기다리면 둘 다 영원히 기다리게 됩니다.

이를 피하려면 Lock 획득 순서를 일관되게 유지하고, 가능하면 중첩된 Lock 사용을 피해야 합니다. 김개발 씨는 캐시 접근 부분에 Lock을 추가하고, API 호출 부분에는 Semaphore를 적용했습니다.

그 후로 테스트를 100번 반복해도 같은 결과가 나왔습니다. "이제야 안심이 되네요!"

실전 팁

💡 - Lock은 꼭 필요한 최소 범위에만 적용하세요

• Semaphore로 외부 API의 동시 요청 제한을 지키세요

---

4. 실습: 병렬 데이터 처리

이제 실전입니다. 김개발 씨에게 새로운 과제가 주어졌습니다.

1000개의 문서를 분석해서 각각의 요약과 키워드를 추출해야 합니다. 하나씩 처리하면 하루 종일 걸릴 것 같습니다.

지금까지 배운 병렬 처리 기법을 총동원할 시간입니다.

병렬 데이터 처리는 대량의 데이터를 여러 작업자가 나눠서 동시에 처리하는 패턴입니다. 마치 이삿짐을 혼자 나르면 하루 종일 걸리지만, 친구 다섯 명이 함께 나르면 두 시간이면 끝나는 것과 같습니다.

올바른 배치 크기와 동시성 제어로 최적의 성능을 끌어낼 수 있습니다.

다음 코드를 살펴봅시다.

import asyncio
from typing import List, Dict
from dataclasses import dataclass

@dataclass
class Document:
    id: str
    content: str

@dataclass
class ProcessedDoc:
    id: str
    summary: str
    keywords: List[str]

# 단일 문서를 처리하는 함수
async def process_single_document(doc: Document) -> ProcessedDoc:
    await asyncio.sleep(0.1)  # LLM API 호출 시뮬레이션
    return ProcessedDoc(
        id=doc.id,
        summary=f"요약: {doc.content[:50]}...",
        keywords=["키워드1", "키워드2"]
    )

# 배치 단위로 병렬 처리
async def process_documents_parallel(
    documents: List[Document],
    batch_size: int = 10,
    max_concurrent: int = 5
) -> List[ProcessedDoc]:
    semaphore = asyncio.Semaphore(max_concurrent)
    results = []

    async def process_with_limit(doc):
        async with semaphore:
            return await process_single_document(doc)

    # 배치 단위로 나누어 처리
    for i in range(0, len(documents), batch_size):
        batch = documents[i:i + batch_size]
        batch_results = await asyncio.gather(
            *[process_with_limit(doc) for doc in batch]
        )
        results.extend(batch_results)
        print(f"처리 완료: {i + len(batch)}/{len(documents)}")

    return results

"1000개 문서를 내일까지 분석해주세요." 팀장님의 요청에 김개발 씨는 잠시 멈칫했습니다. 문서 하나 처리하는 데 1초가 걸린다면, 순차 처리로는 1000초, 약 17분이 걸립니다.

하지만 LLM API 호출까지 포함하면 훨씬 더 걸릴 것입니다. "병렬 처리로 해결할 수 있어요." 박시니어 씨가 말했습니다.

"하지만 1000개를 한꺼번에 돌리면 안 됩니다. 시스템이 버티지 못해요." 여기서 중요한 개념이 배치 처리입니다.

1000개를 한 번에 처리하는 대신, 10개씩 100번 나누어 처리합니다. 각 배치 안에서는 병렬로 처리하되, 배치와 배치 사이에는 잠시 숨을 돌릴 수 있습니다.

이렇게 하면 메모리 사용량을 제어하고, 중간에 문제가 생겨도 어디까지 처리했는지 알 수 있습니다. 코드를 살펴봅시다.

process_documents_parallel 함수는 두 가지 매개변수를 받습니다. batch_size는 한 번에 처리할 문서 수이고, max_concurrent는 동시에 실행할 최대 작업 수입니다.

배치 크기가 10이고 동시 실행이 5라면, 10개 문서 중 5개가 먼저 시작되고, 하나가 끝날 때마다 대기 중인 것이 시작됩니다. Semaphore가 이 조절을 담당합니다.

왜 동시 실행 수를 제한할까요? 여러 이유가 있습니다.

첫째, LLM API에는 보통 분당 요청 제한이 있습니다. 이를 초과하면 429 에러가 발생합니다.

둘째, 너무 많은 동시 연결은 시스템 리소스를 고갈시킵니다. 셋째, 네트워크 대역폭에도 한계가 있습니다.

진행 상황 출력도 중요합니다. 1000개 문서를 처리하는 동안 아무런 피드백이 없다면, 잘 돌아가고 있는지 멈춘 것인지 알 수 없습니다.

코드에서 각 배치가 끝날 때마다 "처리 완료: N/1000"을 출력하여 진행 상황을 보여줍니다. 실무에서는 여기에 에러 처리와 재시도 로직을 추가해야 합니다.

1000개 중 하나가 실패했다고 전체가 멈추면 안 됩니다. 실패한 것은 따로 모아두었다가 나중에 재시도하는 것이 좋습니다.

또한 진행 상황 저장도 고려해야 합니다. 500개째에서 프로그램이 죽으면 처음부터 다시 시작하는 것은 비효율적입니다.

처리 완료된 문서 ID를 파일이나 데이터베이스에 저장해두면, 재시작 시 이어서 처리할 수 있습니다. 김개발 씨는 batch_size를 20으로, max_concurrent를 10으로 설정했습니다.

API 제한과 성능 사이의 균형점을 찾은 것입니다. 1000개 문서 처리가 2분 만에 완료되었습니다.

"순차 처리였으면 20분은 걸렸을 텐데!"

실전 팁

💡 - 배치 크기와 동시 실행 수는 테스트를 통해 최적값을 찾으세요

• 대량 작업에는 반드시 진행 상황 로깅과 에러 처리를 추가하세요

---

5. 실습: 성능 비교

"정말 병렬 처리가 빠른 거 맞아요?" 후배 개발자가 물었습니다. 김개발 씨는 눈으로 보여주는 것이 가장 좋겠다고 생각했습니다.

순차 처리와 병렬 처리의 성능을 직접 측정하여 비교해보기로 했습니다. 숫자로 증명하는 것만큼 확실한 것은 없으니까요.

성능 비교는 서로 다른 구현 방식의 실행 시간, 리소스 사용량을 측정하여 비교하는 과정입니다. 마치 두 가지 요리법 중 어느 것이 더 빠르고 맛있는지 직접 만들어 비교하는 것과 같습니다.

객관적인 수치를 통해 병렬 처리의 효과를 명확히 확인할 수 있습니다.

다음 코드를 살펴봅시다.

import asyncio
import time
from typing import List

# 테스트용 작업: 각 작업은 0.5초가 걸립니다
async def simulate_api_call(task_id: int) -> dict:
    await asyncio.sleep(0.5)
    return {"id": task_id, "result": "완료"}

# 순차 처리 방식
async def sequential_process(task_count: int) -> float:
    start = time.time()
    results = []
    for i in range(task_count):
        result = await simulate_api_call(i)
        results.append(result)
    elapsed = time.time() - start
    return elapsed

# 병렬 처리 방식
async def parallel_process(task_count: int) -> float:
    start = time.time()
    tasks = [simulate_api_call(i) for i in range(task_count)]
    results = await asyncio.gather(*tasks)
    elapsed = time.time() - start
    return elapsed

# 성능 비교 실행
async def compare_performance():
    task_count = 10

    seq_time = await sequential_process(task_count)
    print(f"순차 처리: {seq_time:.2f}초")

    par_time = await parallel_process(task_count)
    print(f"병렬 처리: {par_time:.2f}초")

    speedup = seq_time / par_time
    print(f"속도 향상: {speedup:.1f}배")

# asyncio.run(compare_performance())

"말로만 들으면 와닿지 않아요. 직접 보여주세요." 후배의 요청에 김개발 씨는 간단한 벤치마크 코드를 작성했습니다.

성능을 비교하려면 동일한 조건에서 테스트해야 합니다. 같은 작업을 순차 처리와 병렬 처리로 각각 실행하고, 걸린 시간을 측정합니다.

이것이 벤치마킹의 기본입니다. 코드에서 simulate_api_call 함수는 0.5초가 걸리는 가상의 API 호출입니다.

실제 LLM API 호출 시간을 단순화한 것입니다. 먼저 순차 처리를 봅시다.

for 루프 안에서 각 작업을 하나씩 await합니다. 작업이 10개이고 각각 0.5초가 걸리므로, 총 5초가 소요됩니다.

단순한 덧셈입니다. 다음은 병렬 처리입니다.

10개의 코루틴을 리스트로 만들고 asyncio.gather에 전달합니다. 모든 작업이 동시에 시작되어 동시에 끝납니다.

가장 오래 걸리는 작업이 0.5초이므로, 전체 소요 시간도 약 0.5초입니다. 결과는 놀랍습니다.

순차 처리 5초, 병렬 처리 0.5초. 무려 10배의 속도 향상입니다.

작업 수가 많아질수록 이 차이는 더 극적으로 벌어집니다. 하지만 현실은 조금 다릅니다.

실제로는 이렇게 이상적인 10배 향상을 얻기 어렵습니다. 네트워크 지연, 서버 부하, API 제한 등 다양한 요소가 영향을 미칩니다.

암달의 법칙이라는 것이 있습니다. 프로그램에서 병렬화할 수 없는 부분이 있다면, 그 부분이 전체 성능 향상의 한계를 결정합니다.

예를 들어 전처리와 후처리가 각각 1초씩 걸리고 병렬화할 수 없다면, 본 작업을 아무리 빨리 해도 최소 2초는 걸립니다. 성능 측정 시 주의할 점도 있습니다.

첫 번째 실행은 웜업으로, 캐시가 비어 있어서 느릴 수 있습니다. 여러 번 실행해서 평균을 내는 것이 정확합니다.

또한 다른 프로그램이 실행 중이면 결과가 달라질 수 있으니 가능한 한 동일한 환경에서 테스트해야 합니다. "와, 진짜 10배나 빨라지네요!" 후배가 감탄했습니다.

김개발 씨가 덧붙였습니다. "하지만 무조건 병렬화한다고 좋은 건 아니에요.

작업 간 의존성, 리소스 제한, 코드 복잡도를 모두 고려해야 합니다." 숫자는 거짓말하지 않습니다. 하지만 숫자를 해석하는 것은 우리의 몫입니다.

병렬 처리가 언제 효과적이고 언제 그렇지 않은지, 데이터로 판단하는 습관을 들이세요.

실전 팁

💡 - 벤치마크는 여러 번 실행하여 평균값을 사용하세요

• 실제 환경과 유사한 조건에서 테스트해야 의미 있는 결과를 얻습니다

---

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