시스매

견고한 코드의 초석 에러 핸들링 완벽 가이드

26 min read

2025-09-22 23:28

  • 에러 핸들링은 예기치 않은 오류 발생 시 프로그램의 비정상적 종료를 막고 안정성을 유지하는 핵심적인 프로그래밍 기술이다.
  • 단순히 오류를 잡는 것을 넘어, 원인을 기록(로깅)하고, 사용자에게 친절한 피드백을 제공하며, 시스템 자원을 안전하게 해제하는 역할까지 포함한다.
  • 잘 설계된 에러 핸들링 전략은 코드의 유지보수성을 높이고, 잠재적인 버그를 쉽게 추적하게 하여 견고한 소프트웨어 개발의 초석이 된다.

견고한 코드의 초석 에러 핸들링 완벽 가이드

소프트웨어 개발은 순탄한 항해와 같지 않다. 예측하지 못한 암초(에러)는 언제나 나타날 수 있으며, 숙련된 개발자는 이러한 암초를 우아하게 피하거나 충돌하더라도 배가 침몰하지 않도록 설계하는 능력을 갖추어야 한다. **에러 핸들링(Error Handling)**은 바로 이 능력의 핵심이다. 단순히 프로그램이 ‘죽지 않게’ 하는 소극적 방어를 넘어, 시스템의 안정성을 보장하고, 문제의 원인을 신속하게 파악하며, 최종적으로 사용자 경험을 보호하는 적극적인 기술이다.

이 핸드북은 에러 핸들링이 왜 필요한지 그 탄생 배경부터 시작하여, 다양한 에러의 종류와 구조, 실전에서 사용하는 핵심 전략과 기법, 그리고 전문가로 나아가기 위한 심화 내용까지 포괄적으로 다룬다. 이 글을 끝까지 읽는다면, 당신의 코드는 예측 불가능한 상황에서도 흔들리지 않는 견고함을 갖추게 될 것이다.

1. 에러 핸들링의 탄생 배경: 왜 필요하게 되었나?

컴퓨터 프로그램이 처음 등장했을 때, ‘에러 처리’라는 개념은 매우 원시적이었다. 문제가 발생하면 프로그램은 그저 멈춰버렸다. 하지만 프로그램이 점점 복잡해지고 중요한 작업을 수행하게 되면서, 이런 방식은 더 이상 용납될 수 없었다.

초기 에러 처리 방식의 한계

초기 프로그래밍 언어, 특히 C언어와 같은 절차적 언어에서는 주로 다음과 같은 방식으로 오류를 처리했다.

  • 반환 값 (Return Values): 함수가 성공하면 0을, 실패하면 0이 아닌 특정 숫자(에러 코드)를 반환하는 방식. 예를 들어, 파일을 여는 함수가 실패하면 -1을 반환하는 식이다.
  • 전역 변수 (Global Variables): errno와 같은 전역 변수에 에러 코드를 저장하는 방식. 함수 자체는 성공/실패 여부만 간단히 반환하고, 구체적인 에러 내용은 전역 변수를 통해 확인한다.

이 방식들은 간단했지만 심각한 문제들을 안고 있었다.

  1. 코드의 오염: 모든 함수 호출마다 반환 값을 확인하는 if문이 따라붙어야 했다. 정상적인 로직을 처리하는 코드보다 에러를 확인하는 코드가 더 많아져 가독성이 심각하게 떨어졌다.
  2. 에러 처리 강제성의 부재: 개발자가 반환 값 확인을 잊어버리면, 에러는 조용히 무시되고 프로그램은 잘못된 상태로 계속 실행되어 나중에 훨씬 더 큰 문제를 야기했다.
  3. 컨텍스트 부족: 에러 코드(예: -1 또는 502)만으로는 ‘왜’ 에러가 발생했는지 구체적인 맥락을 알기 어려웠다.

구조적 예외 처리(SEH)의 등장

이러한 문제들을 해결하기 위해 **구조적 예외 처리(Structured Exception Handling, SEH)**라는 혁신적인 패러다임이 등장했다. C++, Java, Python, C# 등 현대적인 객체 지향 언어들이 이를 채택했다.

SEH의 핵심 철학은 **‘관심사의 분리(Separation of Concerns)‘**다. 즉, 정상적인 흐름을 처리하는 코드와 예외적인 상황을 처리하는 코드를 명확하게 분리하는 것이다. 이를 위해 try-catch와 같은 특별한 구문이 도입되었다.

  • 정상 코드의 가독성 향상: try 블록 안에는 성공적인 시나리오의 코드만 집중적으로 작성할 수 있게 되어, 코드의 주된 흐름을 파악하기 쉬워졌다.
  • 에러 처리의 중앙 집중화: catch 블록에서 특정 종류의 예외들을 한꺼번에 처리할 수 있게 되어, 에러 처리 코드가 중복되는 것을 막고 일관된 방식으로 관리할 수 있게 되었다.
  • 강력한 에러 전파: try-catch로 처리되지 않은 예외는 호출 스택(Call Stack)을 따라 상위 함수로 자동으로 ‘전파’된다. 이는 개발자가 에러를 놓치고 넘어갈 가능성을 획기적으로 줄여주었다.

이처럼 에러 핸들링은 ‘오류가 나면 멈춘다’는 원시적 개념에서 ‘오류를 체계적으로 관리하고 대응한다’는 성숙한 공학적 개념으로 발전해왔다.

2. 에러의 종류와 계층 구조

에러 핸들링을 제대로 이해하려면 먼저 우리가 다루어야 할 ‘에러’가 무엇인지 명확히 정의하고 분류할 수 있어야 한다. 많은 언어에서 에러는 계층적인 구조를 가지며, 크게 **시스템 에러(Error)**와 **예외(Exception)**로 구분된다.

구분에러 (Error)예외 (Exception)
발생 원인시스템 레벨의 심각한 문제 (JVM, 하드웨어 등)애플리케이션 레벨의 문제 (코드 로직, 외부 자원)
대표적인 예OutOfMemoryError, StackOverflowErrorNullPointerException, IOException, IllegalArgumentException
처리 가능성일반적으로 복구 불가능 (Unrecoverable)일반적으로 복구 가능 (Recoverable)
개발자의 책임애플리케이션 수준에서 처리하기 어려움반드시 처리(Handle)하거나 전파(Propagate)해야 함
비유갑작스러운 대규모 지진주방에서 발생한 작은 화재

**에러(Error)**는 비유하자면 갑작스러운 지진과 같다. 메모리 부족(OutOfMemoryError)이나 스택 오버플로우(StackOverflowError)처럼 애플리케이션 코드 수준에서는 예측하거나 복구하기 거의 불가능한 심각한 문제다. 이런 에러가 발생하면 시스템을 안정적으로 유지하기 위해 프로그램을 종료하는 것이 최선일 수 있다.

반면, **예외(Exception)**는 주방에서 발생한 작은 화재와 같다. 충분히 예측 가능하고, 적절한 도구(소화기, 즉 catch 블록)가 있다면 진압하고 정상적인 상태로 돌아갈 수 있다. 존재하지 않는 파일을 읽으려 하거나(FileNotFoundException), 잘못된 인자를 메소드에 전달하는(IllegalArgumentException) 등의 상황이 여기에 해당한다. 개발자는 바로 이 ‘예외’를 다루는 데 대부분의 노력을 쏟아야 한다.

Checked Exception vs. Unchecked Exception

Java와 같은 일부 언어는 예외를 다시 두 가지로 나눈다. 이 개념은 다른 언어 사용자에게도 유용한 사고의 틀을 제공한다.

  • Checked Exception: 컴파일러가 컴파일 시점에 예외 처리 여부를 강제로 확인하는 예외. API를 사용하는 개발자가 해당 예외 상황을 인지하고 반드시 try-catch로 처리하거나 throws로 상위 메소드에 책임을 전가하도록 강제한다. 주로 IOException, SQLException처럼 외부 자원과의 상호작용에서 발생하는, 복구 가능성이 높은 예외들이 해당된다. 이는 마치 서류 양식의 ‘필수 기입란’과 같아서, 채우지 않으면 제출 자체가 불가능하다.

  • Unchecked Exception (Runtime Exception): 컴파일러가 확인하지 않는 예외. 주로 프로그래머의 논리적 실수로 인해 발생한다. NullPointerException, ArrayIndexOutOfBoundsException 등이 대표적이다. 이는 ‘선택 기입란’과 같아서 비워둬도 제출은 되지만, 나중에 문제가 될 수 있다. 모든 잠재적 런타임 예외를 try-catch로 감싸는 것은 코드를 지저분하게 만들므로, 보통은 예외가 발생하지 않도록 코드를 견고하게 작성하는(방어적 프로그래밍) 방식으로 대응한다.

3. 에러 핸들링 핵심 전략과 구조

현대 프로그래밍에서 에러 핸들링은 몇 가지 핵심적인 키워드와 구조를 중심으로 이루어진다.

Try-Catch-Finally: 에러 처리의 기본 단위

이 세 가지 키워드는 에러 핸들링의 가장 기본적인 블록이다.

  • try: “위험 지대”를 선언하는 곳. 예외가 발생할 가능성이 있는 코드를 이 블록 안에 넣는다. 마치 안전모를 쓰고 위험한 공사 현장에 들어가는 것과 같다.
  • catch: “응급 구조팀”의 역할을 한다. try 블록에서 특정 종류의 예외가 발생했을 때 실행될 코드를 담는다. 발생할 수 있는 예외 종류별로 여러 개의 catch 블록을 만들 수 있다.
  • finally: “필수 정리 작업”을 수행하는 곳. try 블록의 성공 여부나 예외 발생 여부와 상관없이 항상 실행이 보장되는 코드 블록이다. 주로 사용했던 파일 스트림이나 데이터베이스 연결과 같은 외부 자원을 해제하는 코드를 여기에 넣는다. 자원 누수(Resource Leak)를 방지하는 매우 중요한 역할을 한다.
public void readFile() {
    FileReader reader = null;
    try {
        // 1. 위험 지대: 파일 읽기를 시도
        reader = new FileReader("myFile.txt");
        // ... 파일 읽기 로직 ...
    } catch (FileNotFoundException e) {
        // 2. 응급 구조팀: 파일이 없을 경우 처리
        System.err.println("파일을 찾을 수 없습니다: " + e.getMessage());
    } finally {
        // 3. 필수 정리 작업: 리더기(자원)를 항상 닫아줌
        if (reader != null) {
            try {
                reader.close();
            } catch (IOException e) {
                // close() 중에도 예외가 발생할 수 있음을 고려
                e.printStackTrace();
            }
        }
    }
}

Throw / Raise: 의도적으로 예외 발생시키기

때로는 시스템이 아니라 개발자가 직접 예외를 발생시켜야 할 때가 있다. 예를 들어, 함수의 인자로 음수가 들어오면 안 되는 비즈니스 규칙이 있다면, 이를 위반했을 때 명시적으로 예외를 던져야 한다.

public void setAge(int age) {
    if (age < 0) {
        // 비즈니스 규칙 위반 시, 적절한 예외를 직접 생성하여 던짐
        throw new IllegalArgumentException("나이는 음수일 수 없습니다.");
    }
    this.age = age;
}

이는 단순히 프로그램을 멈추는 것이 아니라, “이 메소드는 이런 식으로는 사용될 수 없다”는 계약 조건을 명확히 하는 행위다.

예외 전파 (Exception Propagation)

try-catch 블록으로 처리되지 않은 예외는 저절로 사라지지 않는다. 대신, 현재 메소드를 호출한 상위 메소드로 그 책임이 ‘전파’된다. 이 과정은 콜 스택의 최상단에 도달할 때까지 계속된다. 만약 최상단(예: main 메소드)에서도 예외가 처리되지 않으면, 프로그램은 비로소 비정상적으로 종료된다.

이 전파 메커니즘은 매우 중요하다. 모든 하위 메소드가 모든 예외를 다 처리할 필요 없이, 특정 예외는 그것을 처리하기에 가장 적합한 ‘문맥’을 가진 상위 계층에서 처리하도록 위임할 수 있기 때문이다. 예를 들어, 데이터베이스 접근 관련 SQLException은 데이터베이스 트랜잭션을 관리하는 서비스 계층에서 처리하는 것이 더 적합할 수 있다.

4. 실전 에러 핸들링 기법

기본 구조를 이해했다면, 이제 실전에서 코드를 더 견고하고 우아하게 만들어 줄 고급 기법들을 알아보자.

구체적인 예외를 잡아라 (Catch Specific Exceptions)

가장 흔한 안티패턴 중 하나는 모든 예외를 catch (Exception e) 와 같이 한 번에 잡으려는 시도다. 이는 “어딘가 아픈데 무슨 병인지는 모르겠어요”라고 말하는 것과 같다. NullPointerException과 IOException은 발생 원인과 해결 방법이 완전히 다르다. 각 예외에 맞는 구체적인 복구 로직을 작성해야 한다.

나쁜 예:

try {
    // ... 여러가지 작업 ...
} catch (Exception e) {
    // NullPointerException인지, IOException인지 알 수 없어 제대로 된 처리가 불가능
    log.error("알 수 없는 에러 발생");
}

좋은 예:

try {
    // ... 여러가지 작업 ...
} catch (IOException e) {
    log.error("파일 입출력 오류 발생", e);
    // 파일 관련 복구 로직
} catch (NullPointerException e) {
    log.error("객체가 초기화되지 않았습니다", e);
    // 기본값 설정 등의 복구 로직
}

에러 로깅: 모든 것을 기록하라

처리되지 않은 예외가 발생했을 때, 그 원인을 파악할 유일한 단서는 바로 **로그(Log)**다. 에러 로깅은 비행기의 블랙박스와 같다. 언제, 어디서, 왜 문제가 발생했는지에 대한 상세한 정보를 기록해야 한다.

좋은 로그에 포함되어야 할 정보:

  • 타임스탬프: 문제 발생 시각
  • 로그 레벨: ERROR, WARN 등 심각도
  • 스택 트레이스 (Stack Trace): 예외가 발생한 코드의 위치와 호출 경로. 디버깅의 핵심 정보다.
  • 컨텍스트 정보: 문제가 발생했을 당시의 주요 변수 값, 사용자 ID, 요청 파라미터 등 원인 파악에 도움이 될 만한 모든 정보.

사용자에게 친절한 오류 메시지를 제공하라

사용자에게 java.net.ConnectException: Connection refused 같은 시스템 내부의 오류 메시지를 그대로 보여주는 것은 최악의 사용자 경험이다. 사용자는 겁을 먹거나 혼란스러워할 뿐이다.

  • 내부 오류는 숨기고: 스택 트레이스나 구체적인 예외 클래스 이름은 로그에만 기록한다.
  • 간결하고 명확하게: “서버에 연결할 수 없습니다. 네트워크 상태를 확인하거나 잠시 후 다시 시도해주세요.” 와 같이 사용자가 이해할 수 있는 언어로 상황을 설명한다.
  • 액션을 유도: 사용자가 다음에 무엇을 해야 할지 안내한다. (예: ‘새로고침’, ‘고객센터 문의’)

전역 예외 처리기 (Global Exception Handler)

애플리케이션의 모든 try-catch를 완벽하게 작성하더라도, 놓치는 예외는 발생할 수 있다. 이를 대비한 최후의 보루가 바로 전역 예외 처리기다. 대부분의 웹 프레임워크(Spring, Express.js 등)는 애플리케이션의 어느 곳에서든 처리되지 않고 전파된 예외를 마지막에 한곳에서 통합 처리할 수 있는 기능을 제공한다.

전역 예외 처리기는 다음과 같은 역할을 한다.

  • 처리되지 않은 모든 예외를 로깅하여 놓치지 않도록 한다.
  • 사용자에게 일관된 형식의 오류 페이지나 JSON 응답을 보여준다.
  • 애플리케이션이 예기치 않게 종료되는 것을 방지한다.

5. 에러 핸들링 심화 및 모범 사례

이제 전문가 수준의 에러 핸들링을 위한 몇 가지 고급 주제와 모범 사례를 살펴보자.

자원 관리와 에러 핸들링: try-with-resources

finally 블록에서 자원을 해제하는 것은 중요하지만, 코드가 지저분해지기 쉽다. Java 7부터 도입된 try-with-resources 구문은 이를 매우 우아하게 해결한다. AutoCloseable 인터페이스를 구현한 자원 객체는 try 블록이 끝나면 자동으로 close() 메소드가 호출된다.

기존 방식:

FileInputStream input = null;
try {
    input = new FileInputStream("file.txt");
    // ...
} finally {
    if (input != null) {
        input.close();
    }
}

try-with-resources 방식:

try (FileInputStream input = new FileInputStream("file.txt")) {
    // ...
    // try 블록이 끝나면 input.close()가 자동으로 호출됨
}

코드가 훨씬 간결하고 자원 누수의 위험도 줄어든다.

예외 전환과 감싸기 (Exception Chaining & Wrapping)

때로는 하위 계층에서 발생한 구체적인 예외를 그대로 상위 계층으로 던지는 것이 적절하지 않을 수 있다. 예를 들어, 서비스 계층은 데이터 접근 기술로 JPA를 쓰는지 JDBC를 쓰는지 알 필요가 없다. SQLException같은 구체적인 기술 종속적 예외 대신, UserDataAccessException과 같이 비즈니스 의미가 담긴 추상적인 예외로 ‘감싸서(Wrapping)’ 던지는 것이 좋다.

이를 **예외 전환(Exception Translation)**이라 한다. 원래 발생했던 예외(cause)를 새로운 예외 안에 포함시켜, 근본 원인을 잃어버리지 않으면서도 계층 간의 결합도를 낮추는 효과를 얻을 수 있다.

public User findUser(String id) {
    try {
        // ... JDBC 코드 ...
    } catch (SQLException e) {
        // SQLException을 비즈니스 의미가 있는 예외로 감싸서 던진다.
        // 원래 발생한 e를 원인(cause)으로 지정하여 스택 트레이스를 잃지 않는다.
        throw new UserDataAccessException("사용자 정보를 가져오는 데 실패했습니다.", e);
    }
}

반드시 피해야 할 안티패턴

  • 예외 삼키기 (Exception Swallowing): catch 블록을 비워두는 행위. 에러가 발생했다는 사실 자체를 은폐하여 디버깅을 불가능하게 만드는 최악의 패턴이다.
  • 예외를 흐름 제어에 사용하기: 반복문을 종료하거나 특정 로직을 실행하기 위해 예외를 던지고 잡는 것은 성능 저하를 유발하고 코드의 의도를 파악하기 어렵게 만든다. 예외는 이름 그대로 ‘예외적인’ 상황에만 사용해야 한다.
  • 너무 광범위한 throws 선언: 메소드 시그니처에 throws Exception이라고 선언하는 것은 해당 메소드를 사용하는 개발자에게 어떤 예외를 처리해야 하는지 아무런 정보도 주지 않는 무책임한 행위다.

결론: 에러 핸들링은 비용이 아닌 투자다

에러 핸들링 코드를 작성하는 것은 때로 번거롭고 추가적인 노력이 드는 일처럼 느껴질 수 있다. 하지만 이는 결코 비용이 아니라, 미래의 자신과 동료들을 위한 투자다.

잘못된 데이터 하나 때문에 전체 시스템이 마비되거나, 원인을 알 수 없는 버그를 잡기 위해 며칠 밤을 새우는 끔찍한 상황을 막아주는 것이 바로 체계적인 에러 핸들링이다. 코드가 예상대로 동작할 때뿐만 아니라, 예상치 못한 상황에 처했을 때 어떻게 반응하는지가 진정한 프로페셔널의 실력을 보여주는 척도다.

이 핸드북에서 다룬 원칙과 기법들을 꾸준히 체화하고 적용하여, 어떤 상황에서도 흔들리지 않는 견고하고 신뢰성 높은 소프트웨어를 만들어나가길 바란다.

그래프 뷰