JavaScript 에러 객체와 스택 트레이스는 디버깅에 어떻게 활용하나요?

Error 객체의 message는 실패 이유를, stack은 호출 경로를 보여줍니다. 커스텀 에러와 적절한 로깅을 사용하면 원인 추적이 쉬워지지만 민감 정보가 로그에 남지 않도록 주의해야 합니다.

핵심 개념

핵심 기준은 message, stack, 로깅 컨텍스트입니다. 이 개념은 단순한 용어가 아니라, 실제 코드나 시스템에서 반복적으로 생기는 문제를 다루기 위해 등장했습니다.

JavaScript는 실행 문맥, 비동기 흐름, 참조 관계가 코드 동작에 직접 영향을 주는 언어입니다. 그래서 문법을 외우는 것보다 값이 언제 결정되고 어떤 순서로 실행되는지 이해하는 것이 중요합니다.

동작 흐름

1. 먼저 어떤 문제가 있는지 확인합니다.
2. 이 개념이 그 문제를 어떤 기준으로 나누거나 해결하는지 봅니다.
3. 실제 코드에서는 입력, 상태, 실행 순서, 비용이 어떻게 바뀌는지 확인합니다.
4. 마지막으로 한계와 부작용을 함께 점검합니다.

실제 예시

try {
  await createOrder(input);
} catch (error) {
  console.error("order creation failed", {
    message: error.message,
    stack: error.stack,
  });
  throw error;
}

스택 트레이스는 실패한 위치뿐 아니라 어떤 호출 경로로 도달했는지 보여줍니다. 다만 로그에 개인정보나 토큰이 남지 않도록 주의해야 합니다.

실무에서 주의할 점

• 암묵적 변환이나 실행 문맥에 기대면 작은 리팩터링에도 동작이 달라질 수 있습니다.
• 비동기 코드에서는 실행 순서와 에러 전파 경로를 반드시 확인해야 합니다.
• 브라우저 이벤트나 타이머를 사용했다면 정리(cleanup) 시점을 놓치지 않는 것이 좋습니다.

함께 연결해서 보면 좋은 키워드

JS, Error, 디버깅, 로그

정리

한 줄로 정리하면, Error 객체의 message는 실패 이유를, stack은 호출 경로를 보여줍니다. 커스텀 에러와 적절한 로깅을 사용하면 원인 추적이 쉬워지지만 민감 정보가 로그에 남지 않도록 주의해야 합니다. 실무에서는 개념을 적용하는 조건과 적용하지 않았을 때 생기는 문제까지 함께 이해하는 것이 중요합니다.

Error 객체의 정보

JavaScript의 Error 객체는 보통 name, message, stack을 가집니다. stack trace는 오류가 어디서 시작되어 어떤 호출 경로를 거쳤는지 보여줍니다.

try {
  risky();
} catch (error) {
  if (error instanceof Error) {
    console.error(error.message);
    console.error(error.stack);
  }
}

원인 보존하기

try {
  await paymentGateway.request();
} catch (cause) {
  throw new Error('결제 승인 요청에 실패했습니다', { cause });
}

상위 계층에서 도메인 친화적인 메시지를 던지되, cause로 원래 오류를 보존하면 디버깅이 쉬워집니다.

실무 활용

• 사용자에게는 안전한 메시지, 로그에는 상세한 stack을 남깁니다.
• source map을 설정해야 번들된 프론트엔드 코드의 원래 위치를 추적할 수 있습니다.
• 비동기 경계에서는 stack이 끊겨 보일 수 있으므로 요청 ID, 사용자 ID, trace ID를 함께 기록합니다.