Frontend/JAVASCRIPT

완벽한 에러 핸들링을 위한 전략: try...catch 그 이상의 실무 패턴

미니임 2026. 3. 3. 12:15

 

소프트웨어 개발에서 "코드가 실행된다"는 것은 절반의 성공일 뿐입니다. 나머지 절반은 "예상치 못한 상황에서 코드가 어떻게 우아하게 실패하는가"에 달려 있습니다. 특히 네트워크 지연, 잘못된 사용자 입력, API 서버의 장애가 빈번한 현대 웹 생태계에서 에러 핸들링은 서비스의 신뢰도를 결정짓는 핵심 요소입니다.

단순히 에러를 잡는(catch) 것을 넘어, 시스템을 보호하고 사용자 경험을 해치지 않는 시니어 수준의 예외 처리 전략을 짚어보겠습니다.

1. Deep Dive: 왜 단순한 try...catch만으로는 부족할까?

대부분의 입문자는 모든 코드 블록을 try...catch로 감싸면 안전하다고 믿습니다. 하지만 이는 **"무차별적 수용"**이라는 함정에 빠지기 쉽습니다.

에러 핸들링의 본질: 전파(Propagation)와 억제(Suppression)

에러 핸들링의 핵심은 **"여기서 해결할 것인가, 아니면 상위 레이어로 보고할 것인가"**를 결정하는 것입니다. 모든 곳에서 에러를 잡아버리면(Silent Fail), 정작 디버깅이 필요한 시점에 에러의 근원지를 찾을 수 없는 '좀비 코드'가 생성됩니다.

비유로 이해하기 레스토랑에서 요리 도중 재료가 떨어졌다고 가정해 봅시다.

  • 하위 레이어(요리사): 재료가 없음을 인지하고 매니저에게 알립니다. (Error Throwing)
  • 상위 레이어(매니저): 손님에게 품절을 안내하거나 다른 메뉴를 추천합니다. (Error Handling)

만약 요리사가 재료가 없는데도 매니저에게 알리지 않고(Catch 후 아무것도 안 함) 빈 접시를 내보낸다면, 서비스 전체의 신뢰도가 무너지는 것과 같습니다.

2. Hands-on: 실무형 이커머스 결제 로직 예제

단순한 console.error가 아닌, 상태 복구와 로그 추적을 포함한 실전 결제 프로세스 코드를 살펴보겠습니다.

JavaScript
 
/**
 * 이커머스 결제 처리 함수
 * @param {string} orderId - 주문 ID
 * @param {object} paymentInfo - 결제 수단 정보
 */
async function processOrderPayment(orderId, paymentInfo) {
  try {
    // 1. 재고 확인 (Pre-condition Check)
    const stockAvailable = await checkInventory(orderId);
    if (!stockAvailable) {
      // 예상 가능한 비즈니스 에러는 커스텀 에러 객체를 사용합니다.
      throw new Error("INSUFFICIENT_STOCK");
    }

    // 2. 결제 API 호출
    const paymentResult = await externalPaymentGateway(paymentInfo);

    // 3. 주문 상태 업데이트
    await updateOrderStatus(orderId, 'PAID');
    
    return { success: true, transactionId: paymentResult.id };

  } catch (error) {
    // [Troubleshooting] 에러의 성격에 따른 분기 처리
    
    if (error.message === "INSUFFICIENT_STOCK") {
      // 비즈니스 로직 에러: 사용자에게 친절한 안내 필요
      console.warn(`[Order-Warn] 주문 ${orderId}: 재고 부족`);
      return { success: false, reason: "재고가 부족하여 결제가 취소되었습니다." };
    }

    if (error.name === "TimeoutError") {
      // 인프라 에러: 일시적인 문제이므로 재시도 권장
      console.error(`[Order-Error] 결제 게이트웨이 타임아웃: ${error.stack}`);
      return { success: false, reason: "결제 서버 응답이 지연되고 있습니다. 잠시 후 다시 시도해주세요." };
    }

    // 4. 예상치 못한 에러 (Critical)
    // 로그 시스템(예: Sentry, Datadog)에 에러 전송
    captureException(error, { extra: { orderId } });
    
    // 치명적 에러 발생 시 시스템 안정성을 위해 상위로 에러를 다시 던집니다 (Re-throw)
    throw new SystemError("결제 처리 중 내부 시스템 오류가 발생했습니다.", error);
  } finally {
    // 성공/실패 여부와 상관없이 실행 (예: 로딩 스피너 제거, 리소스 해제)
    hideLoadingSpinner();
  }
}

핵심 포인트 설명

  • Custom Error Identification: error.message나 error.name을 통해 에러의 성격을 분류했습니다.
  • Contextual Logging: 단순 에러 메시지가 아닌 orderId와 같은 컨텍스트를 함께 남겨 추적을 용이하게 했습니다.
  • finally의 활용: 에러가 발생하더라도 UI의 상태(로딩 인디케이터 등)는 반드시 정리되어야 합니다.

3. Trade-offs: 에러 핸들링의 비용과 대안

완벽한 에러 핸들링에도 비용(Trade-off)이 따릅니다.

  1. 가독성 저하: 모든 라인을 try...catch로 감싸면 비즈니스 로직보다 에러 처리 코드가 더 길어지는 "Pyramid of Doom"이 발생할 수 있습니다.
    • 대안: 미들웨어나 중앙 집중식 에러 핸들러(Global Error Boundary)를 활용하여 공통 로직을 분리하세요.
  2. 성능 오버헤드: 과도한 호출 스택 생성과 예외 객체 생성은 미세하게나마 메모리와 CPU를 소모합니다.
    • 대안: 제어 흐름(Control Flow)을 위해 에러를 사용하지 마세요. (예: 단순히 데이터가 없는 경우 throw를 하기보다 null이나 Optional 패턴을 반환하는 것이 효율적입니다.)

4. 결론 및 요약

에러 핸들링은 단순히 앱이 죽지 않게 만드는 방어 기제가 아닙니다. 실패한 상황에서도 시스템이 다음 동작을 예측 가능하게 만드는 설계입니다.

  • 비즈니스 에러와 시스템 에러를 구분하세요.
  • 사용자에게는 이해 가능한 언어로, 개발자에게는 추적 가능한 로그로 응답하세요.
  • try...catch는 해결할 수 있는 위치에서만 사용하고, 그렇지 않다면 과감히 위로 던지세요.
반응형