주제: 에러 처리 구조 설계
✨ 설계 목표
- 시스템 예외와 도메인 예외를 구분하고,
- 응답 구조, 로그 처리, 책임 분리를 명확히 정의하는 설계 감각을 키운다.
❓ GPT 질문 + 선택지 + 응답 요약
Q1. 비즈니스 로직 실패와 시스템 장애를 같은 방식으로 처리해도 될까?
선택지
- A. 하나의 예외 계층에서 처리한다
- B. 비즈니스 예외와 시스템 예외를 분리해서 처리한다
선택: B
이유:
- 시스템 예외는 재시도/점검이 필요하고
- 도메인 예외는 사용자 실수일 가능성이 높아 분리해야 후처리/알림이 유연해짐
Q2. 비즈니스 예외가 발생했을 때 HTTP 상태 코드는?
선택지
- A. 500 Internal Server Error
- B. 400 Bad Request
- C. 200 OK (실패 메시지를 body에 담는다)
선택: B
이유:
- 200은 정상 처리처럼 보이기 쉬움
- 500은 서버 책임처럼 보일 수 있음
- 사용자 요청 자체가 문제이므로 400이 적절
Q3. 예외 메시지를 그대로 사용자에게 반환해도 될까?
선택지
- A. 내부 예외 메시지를 그대로 반환
- B. 사용자 친화적인 메시지를 따로 만들어서 반환
선택: B
이유:
- 사용자 입장에서 이해가 어렵고
- 시스템 구조 노출 가능성 있음
- 로그에만 내부 메시지를 남기고 응답은 안전하게 가공해야 함
Q4. 사용자에게 전달할 에러 응답 구조는 어떻게?
선택지 없음 (자유응답)
응답:
code + message- message는 "이름 항목이 비어 있습니다"처럼 필드 기반 메시지 포함
Q5. 서버 로그에는 어떤 정보가 포함되어야 할까?
선택지 없음 (자유응답)
응답:
- 로그 시점의 발생 시간
- 예외 발생 클래스, 스택
- Log4j 등을 기준으로 더 확장 가능
- 필요 시 DB 기록도 고려
Q6. 도메인 예외가 발생했을 때 서비스에서 바로 throw 해도 될까?
선택지
- A. 서비스에서 throw 후 핸들러에서 가공
- B. 서비스에서 바로 응답 메시지 구성까지 담당
선택: A
이유:- 예외 발생 위치가 가장 풍부한 정보 보유
- 표현 책임(응답 구조)은 공통 핸들러에서 맡는 것이 분리 관점에서 바람직
Q7.
e.printStackTrace()사용에 대한 생각은?선택지 없음 (자유응답)
응답:
- 사용 지양
- 이유: 로그 시스템 연동 안됨, 로그 레벨 지정 불가, 운영 환경에선 출력 손실 가능
- 대안:
log.error("메시지", e)사용
✍️ 설계 구조 예시 (Java)
// 예외 정의 class DomainException extends RuntimeException { private final String code; public DomainException(String msg, String code) { super(msg); this.code = code; } public String getCode() { return code; } } // 도메인 서비스에서 예외 발생 if (order.isAlreadyPaid()) { throw new DomainException("이미 결제된 주문입니다", "ORDER_ALREADY_PAID"); } // 공통 예외 핸들러 @ExceptionHandler(DomainException.class) public ResponseEntity<ErrorResponse> handle(DomainException e) { log.warn("도메인 예외 발생", e); return ResponseEntity.status(400) .body(new ErrorResponse(e.getCode(), e.getMessage())); }
🎯 오늘의 한 줄 정리
사용자에게는 친절하게, 개발자에게는 정확하게.
예외는 의미별로 나누고, 책임은 계층별로 분리하라.
