1. 배경

1.1. 목적

• 아래에서 기술하는 내용은 서버 입장에서 다른 사이드와의 통신시 원활한 에러 핸들링을 위해 작성하였다.
• 사이드란 프론트, 외부 서버 등 물리적으로 구분된 영역을 뜻한다.

1.2. 상황

1.2.1. 로직 기반 에러 핸들링 방법

• 구체적으로 단위로 처리하라(제일 큰 단위의 에러로 처리하지 마라)
• 의미 있는 것을 잡아라(= 잡고나서 아무것도 안하는 형태는 하지 마라)
• 다시 위를 향하여, 그대로 올리지 마라 등등
• 여러가지 에러 핸들링 방식이 있으며 이는 로직 또는 함수 단위에서 적용할 수 있다.
• 그렇다면 외부와 소통할때 우리는 여기서 무엇을 더 해야할까?

1.2. 우리(서버)는 어떠한 목적을 위해서 에러를 처리해야할까?

• 단순히 서버가 터지지 않게 하기 위함은 1차원적인 목적이고 이제는 그 이후까지 생각을 해야한다.

2. 에러의 정의

2.1. 에러란 무엇일까?

an error is an unexpected or unintended issue that occurs in a program or software application

• 에러란 결국 우리가 예상 하지 못한 또는 의도하지 않은 상황이라 할 수 있다.
  • 예상하지 못한 상황: 신택스 에러 & DB 가 down 됨
  • 의도하지 않는 상황: client 가 잘못된 정보를 보내줌

2.2. 에러를 왜 잡아야 할까?

• 결국 에러란 서버가 기대한 상황이 아닌 것들이기에 우리가 직접 대응해줘야하는 것들이라고 추가적으로 정의할 수 있다.
• 그렇기에 우리는 여기서 대응이 가능한, 또는 필요한 것들과 그렇지 않은 것들을 구분해야하며 이를 바탕으로 에러를 처리하는데 있어서 다르게 접근해야한다.
• 그래야만 한정된 리소스를 대응하는데 적절히 사용할 수 있으며 이를 바탕으로 서버를 이용하는 곳(프론트, 다른 서버 등)에게도 에러 상황에 대해적절히 설명과 할 수 있기 때문이다.

2.3. 에러의 종류

• 그렇기에 에러를 handle / unhandled 과 같은 개념이 아닌 대응 해야하는 것(또는 할 수 있는것)과 그렇지 않은것을 구분지어야한다.
• 이를 위해 내가 에러를 구분 지은 것은 아래와 같다.

1. 사용자 문제(대응 필요 없음)
2. 공급자 문제(대응 할 수 없음)
3. 도메인 문제(대응 필요함)

2.3.1. 사용자 문제

• 사용자 문제란 이를 사용하는 사람에게서 발생하는 문제 이며 우리 입장에선 사용자의 행동을 교정해줘야한다.
• 그렇기에 사용자 문제가 발생한 경우 이를 필히 알려줘야한다. 그래야 다음에 사용을 할때 다른 행동을 하던 아니면 추가 행동을 하지 않던 또는 내 행동이 왜 작동 안하는 지 등을 알 수 있기 때문이다.
• 사용자 문제 에러는 2가지로 구분 할 수 있다.

1. 잘못된 요청

   회원 가입시 닉네임을 입력 안했다.
   나이를 문자로 입력 하였다

2. 도메인 룰 위반

   숫자 + 문자로 구성되어야 하는 비밀번호에 숫자만 입력하였다.
   회원 가입시 이미 가입된 이메일을 입력하였다.

• 잘못된 요청 이나 도메인 룰 위반이나 사실상 비슷해보인다.
• 중요한 점은 이 문제에 대해 요청한 쪽에게는 충분히 안내를 해줘야한다는 점이다. 왜 행동이 안되는지 또는 행동을 어떻게 바꿔야 하는 지 등
• 다만 이 에러는 서버에서 대응할 필요가 없는 에러이다. 따라서 서버 입장에선 에러로 처리를 하되 굳이 모니터링(sentry 등 까지)툴 까지 할 필요는 없는 에러들이다.

2.3.2. 공급자 문제

• 서버 및 각종 인프라, 외부 서비스 등에서 발생하는 문제이다.
• 여기서 발생하는 문제는 요청하는 쪽에선 알아도 무언가를 할 수 있는 수준이 아니다. 그렇기에 이에 대해서 구체적으로 알려줄 필요가 없다(로깅 등은 자세히 해야한다.
• 서버 문제 에러는 2가지로 구분 할 수 있다.

1. 내부 문제

   신택스 에러

2. 외부 문제

   인프라와 관련된 문제(DB 연결이 안됨, 서드파티 서비스가 다운 됨-이메일 인증 서비스가 다운)

• 이러한 문제는 사용자가 잘못한 것은 아니며 또한 사용자가 대응 할 수 있는 것이 아니므로 현재 사용을 하지 못한다는 사실만 안내해주면 된다. 또한 최소한의 모니터링툴에 추가해주면 된다.

2.3.3. 도메인 문제

• 비즈니스 혹은 도메인 로직에서 발생하는 문제이다.
• 이 문제를 구체적으로 명시한 이유는 바로 이러한 문제들이 서버가 적극적으로 대응해야하는 케이스 이기 때문이다.

  1. user-token 이 있어야 사용 가능한 API 및 비즈니스 로직에서 getUser 를 했는데 user 가 없는 경우
  2. 이벤트를 한번만 응시가 가능한데 2회 이상 응시 한것으로 확인 되는 경우 등

• 이러한 문제들은 사용자가 의도적으로 악용한 case 일 수도 있고 아니면 우리가 미쳐 파악하지 못한 버그일 수도 있다.
• 중요한 점은 이러한 상황에 대해선 적극적 대응이 필요로 하다는 점이다. 여기서 적극적 대응이 필요하다는 것은 요청한 곳과 우리(=서버) 둘다를 뜻한다.
• 즉 서버로부터 도메인 문제가(아마도 버그) 발생 했으며 이러한 문제를 파악하기 위한 full-context 가 필요로 하게 된다. 그렇기에 이러한 에러를 response 로 받게 된다면 요청한 쪽에서는 충분한 정보 제공을 위해 무엇을 요청했는지 등의 data 를 로깅하거나 별도의 모니터링 툴에 에러로 등록하거나 하는 등의 액션이 필요로 하다.

3. 결론

3.1. 그렇다면 어떻게 하는 것이 좋을까?

• 위에서 구분한 3개의 에러 계층을 바탕으로 사용하는 쪽과 protocol 을 약속하자.
• 이는 http code 가 될 수도 있고 자체 error code가 될 수도 있고 enum 이 될 수도 있다.

3.2. 중요한 것은 구분한 에러에 대한 서로 다른 대응을 하는 것이다.

1. 사용자 문제 에러의 경우: 서버는 로깅 & 모니터링 필요 X / 사용처에게 문제 상황, 방법 구체적으로 알려줘야함
2. 서버 문제 에러: 서버는 로깅 & 모니터링이 필요 / 사용처에겐 대략적인 문제 상황만 안내 하면 됨
3. 도메인 문제 에러: 서버는 로깅 & 모니터링 필요, 되도록 자세하게 / 사용처에겐 대략적인 문제 상황 안내, 사용처에서는 사용 방법(input) 등 context 에 대한 모니터링 필요

3.3. 결국 서버가 에러를 핸들링 해야하는 이유는!

• (기본) 서버의 안전성, 신뢰성을 확보
• (핵심) 문제 되는 상황에 대한 모든 정보 확보를 통한 해당 문제 상황 해소

이 두가지로 요약 & 확장 할 수 있다.