---
title: "에러의 두 가지 종류"
published: 2026-03-01T23:29:40.000Z
canonical: https://jeff.news/article/210
---
# 에러의 두 가지 종류

소프트웨어 에러를 expected(정상 운영 중 발생, 처리 필요)와 unexpected(버그, crash 허용)로 나누는 프레임워크를 제안하는 글. 맥락에 따라 선 긋는 위치가 달라지며, Rust의 에러 철학과 맥이 같음.

- Evan Hahn의 블로그 글로, 소프트웨어 에러를 딱 두 종류로 나눠서 생각하자는 제안임
- **예상 가능한 에러(Expected errors)**: 유효성 검증 실패, 네트워크 장애, 권한 부족 같은 것들. 정상 운영 중에 당연히 발생할 수 있고, 개발자 잘못이 아님. Result 타입이나 null 유니온 같은 걸로 반환해서 처리해야 하고, throw/panic은 하면 안 됨. 로그 레벨은 WARN이나 INFO가 적절
- **예상 못한 에러(Unexpected errors)**: assertion 위반, 로직 에러, 잘못된 데이터 같은 것들. 이건 버그라는 뜻이므로 crash/panic 해도 됨. 오히려 프로그램을 완전히 뻗게 만드는 게 장기적으로 더 안정적인 소프트웨어를 만든다는 입장. 로그는 ERROR/FATAL 레벨로
- 어디에 선을 긋느냐는 맥락에 따라 다름. 프로토타입이면 모든 에러가 unexpected이고, 50년짜리 우주 탐사선이면 거의 모든 에러가 expected임. 실무에서는 신뢰성을 높일수록 expected로 분류하는 범위가 점점 넓어지게 됨
- 언어별 철학도 다른데, Rust나 Zig 같은 엄격한 언어는 더 많은 에러를 expected로 취급하고, JavaScript나 Python은 unexpected 쪽으로 빠지는 경향이 있음. 본인은 프로덕션엔 엄격한 언어, 스크립트엔 느슨한 언어를 선호한다고
- 결국 Rust의 에러 처리 철학(Result vs panic)과 거의 같은 이야기인데, 언어 불문하고 적용할 수 있는 사고 프레임워크로 정리한 거임

## 핵심 포인트

- Expected error는 throw/panic 대신 Result 타입 등으로 반환하고, WARN/INFO 로그 사용
- Unexpected error는 버그를 의미하므로 crash/panic 허용, ERROR/FATAL 로그 사용
- 프로토타입이면 대부분 unexpected, 미션 크리티컬이면 대부분 expected로 분류
- Rust/Zig는 엄격하게, JS/Python은 느슨하게 에러를 분류하는 경향

## 인사이트

새로운 이야기는 아니지만, 언어 불문하고 에러 처리 전략을 정리하는 깔끔한 멘탈 모델. 특히 주니어 개발자에게 유용한 프레임워크임.