서버와 네트워크가 아플 때: 서버 오류와 네트워크 장애

세상의 모든 에러와 맞서기

프론트엔드 개발자는 항상 "서버는 언제든 죽을 수 있고, 네트워크는 언제든 끊길 수 있다"는 비관적인(?) 태도를 가져야 합니다. 우리가 다뤄야 할 대표적인 외부 에러는 두 가지입니다.

1. 서버 내부 오류 (500 Internal Server Error): 백엔드 서버에서 코드 문제나 DB 장애로 올바른 데이터를 내려주지 못하는 상황.
2. 네트워크 장애 (Network Error): 사용자의 와이파이가 끊기거나 터널을 지나갈 때처럼 아예 인터넷 연결이 안 되는 상황.

이런 상황에서 자바스크립트는 조용히 작동을 멈춥니다(Crash). 화면은 멈추고 버튼을 눌러도 반응이 없어집니다. 우리는 이를 막기 위해 코드 전체에 안전망을 깔아야 합니다.

try-catch: 에러를 잡아채는 그물망

데이터를 주고받는 비동기 함수(fetch 등)를 작성할 때는 반드시 `try-catch` 구문으로 감싸야 합니다. 이것이 가장 기초적인 방어선입니다.

```typescript
async function fetchUserData() {
  try {
    const response = await fetch('/api/user');
    
    // 서버가 정상(200번대) 응답을 하지 않으면 강제로 에러를 던집니다.
    if (!response.ok) {
      throw new Error('서버에 문제가 발생했습니다.');
    }
    
    const data = await response.json();
    return data;
    
  } catch (error) {
    // 인터넷이 끊겼거나 위에서 던진 에러가 이쪽으로 넘어옵니다.
    console.error(error);
    alert('데이터를 불러오지 못했습니다. 잠시 후 다시 시도해주세요.');
  }
}
```

Next.js의 방어막: error.tsx

컴포넌트마다 일일이 `try-catch`를 작성하고 에러 상태를 관리하는 것은 매우 피곤한 일입니다. 다행히 Next.js는 `loading.tsx`처럼 파일 시스템 기반의 에러 처리 기능인 `error.tsx`를 제공합니다.

특정 컴포넌트에서 에러가 터지면, 그 에러가 전체 화면을 망가뜨리지 않도록 Next.js가 중간에서 에러를 격리합니다. 그리고 미리 만들어둔 `error.tsx` 화면을 사용자에게 보여주어, 우아한 실패(Graceful Degradation)를 만들어냅니다.

// app/error.tsx
'use client'; // 에러 컴포넌트는 무조건 클라이언트 컴포넌트여야 합니다.

export default function Error({ error, reset }) {
  return (
    <div className="error-container">
      <h2>앗, 무언가 잘못되었습니다!</h2>
      <p className="text-gray-500">
        서버와 통신하는 중 문제가 발생했습니다. 네트워크 상태를 확인해주세요.
      </p>
      {/* reset 함수를 호출하면 에러가 발생한 컴포넌트를 다시 렌더링 시도합니다. */}
      <button onClick={() => reset()} className="retry-btn">
        다시 시도하기
      </button>
    </div>
  );
}

친절한 에러 안내 문구 작성하기

에러 상황에서 가장 피해야 할 것은 기술적인 용어를 그대로 노출하는 것입니다. "500 Internal Server Error"나 "Failed to fetch" 같은 문구는 개발자에게나 유용하지 일반 사용자에게는 공포감을 줍니다.

네트워크 장애나 서버 오류는 피할 수 없는 현실입니다. 이 오류들을 감추려 하지 말고, 사용자가 당황하지 않게 다독이며 "다시 시도하기" 같은 명확한 다음 행동을 제시하는 것이 진정한 프론트엔드 장인의 자세입니다.