EP90 비동기 작업 파이프라인과 지연 평가

개요

이 에피소드는 비동기 작업을 파이프라인으로 구성할 때 발생하는 지연 평가(Lazy Evaluation)와 에러 전파의 미묘한 상호작용을 다룬다. 표면적으로는 Promise 체이닝 패턴을 논의하지만, **실제 핵심은 ‘비동기 작업의 조합 가능성(Composability)을 어떻게 훼손하지 않으면서도 예측 가능한 에러 처리를 보장할 것인가’**라는 더 근본적인 질문이다.

핵심 통찰

1. 지연 평가의 역설

비동기 파이프라인에서 지연 평가는 성능 최적화와 디버깅 가능성 사이에서 긴장을 만든다.

• 표면적 의도: “필요할 때만 실행하자” (메모리/CPU 효율)
• 숨겨진 의도: “실행 순서를 제어함으로써 부수 효과(Side Effect)를 관리하자”
• 통찰: 실제로 지연 평가는 에러의 발생 시점과 감지 시점을 분리시킨다. 이는 에러가 ‘발생한 곳’과 ‘처리되는 곳’이 다를 수 있다는 뜻이며, 이 간극이 **예상치 못한 상태 불일치(State Inconsistency)**를 초래한다.

2. 에러 전파의 이중성

클리핑에서 다루는 에러 처리 방식은 Monadic Error Handling과 Try-Catch 폭포수의 하이브리드에 가깝다.

• 발견: 화살표 함수 내부에서 throw된 에러는 Promise 체인의 .catch()로 전파되지만, 동기적 지연 평가 함수 내부에서 발생한 에러는 체인을 타지 못하고 조용히 사라진다.
• 전문가 통찰: 이는 **비동기/동기 경계면(Async/Sync Boundary)**에서 발생하는 근본적인 임피던스 불일치다. 함수형 프로그래밍에서 Either/Try 모나드가 필요한 이유가 바로 여기에 있다.

주요 개념

비동기 파이프라인의 3가지 패턴

1. Eager Pipeline: 모든 작업을 즉시 실행. 단순하지만 리소스 낭비.
2. Lazy Pipeline: 필요 시점까지 실행 지연. 효율적이지만 디버깅 난이도 상승.
3. Hybrid Pipeline: 일부는 지연, 일부는 즉시 실행. 실제 프로덕션에서 가장 많이 쓰이나, 규칙 정의가 까다로움.

에러 경계(Error Boundary)의 위치

• 파이프라인 진입점: 에러 조기 감지 가능 but 과도한 검증으로 인한 성능 저하
• 파이프라인 종료점: 성능 최적화 but 에러 원인 추적이 어려움
• 각 단계 사이: 가장 균형 잡힌 접근 but 코드 복잡도 증가

실용적 응용

권장 패턴: “Fail-Fast with Context”

1. 각 단계에서 에러 발생 시 **즉시 실패(Fail-Fast)**하되, 에러 객체에 **현재 컨텍스트(단계명, 입력값, 타임스탬프)**를 포함시켜 전파
2. 파이프라인 종료 지점에서 컨텍스트를 분석하여 **에러의 근본 원인(Root Cause)과 영향 범위(Blast Radius)**를 동시에 파악
3. 지연 평가가 필요한 경우, 명시적인 “평가 트리거(Evaluation Trigger)” 함수를 두어 실행 시점을 코드 레벨에서 가시화

관련 개념

• async-patterns: 비동기 처리의 다양한 패턴과 비교
• functional-programming: 모나드와 함수형 에러 처리
• error-boundary: 에러 경계 패턴의 심층 분석