서버 로그와 예외 처리

로그는 실행 중 발생한 사건을 기록하고, 예외 처리는 정상 흐름을 벗어난 오류를 처리하거나 상위 호출자에게 전달한다. 로그 수준, 예외 전파, 처리기 순서와 자원 정리를 구분한다.

그림으로 확인하기

좌우로 이동해 그림을 확인하세요.그림 크게 보기

로그의 목적과 종류

로그는 프로그램의 상태와 발생한 사건을 나중에 확인할 수 있도록 남긴 기록이다. 오류 위치를 찾거나 요청 처리 결과를 확인하는 데 사용한다. 보통 발생 시각, 수준, 위치, 메시지 등이 포함된다.

로그는 기록, 모니터링은 상태 관찰, 경보는 조건 충족 시 통지를 뜻한다. 오류 로그를 남겼다는 사실만으로 경보가 전달되거나 예외가 해결되는 것은 아니다.

로그 수준

수준 이름은 제품마다 다르지만 흔히 TRACE < DEBUG < INFO < WARN < ERROR < FATAL 순서로 심각도가 높아진다. 일부 제품은 WARNING 또는 CRITICAL이라는 이름을 사용한다.

일반적인 임계값 방식에서 INFO를 기준으로 설정하면 DEBUG는 제외되고 INFO 이상의 심각도는 출력 대상이 된다. 실제 출력 여부에는 추가 필터도 영향을 줄 수 있다. ERROR 기록 자체가 프로그램 종료 명령은 아니다.

예외의 발생과 전파

예외는 프로그램 실행 도중 정상적인 흐름을 계속할 수 없을 때 발생한다. 0으로 나누기, 존재하지 않는 파일 열기, 숫자로 변환할 수 없는 문자열 등이 대표적인 상황이다. 언어에 따라 발생시키는 키워드는 throw 또는 raise, 처리하는 구문은 catch 또는 except이다.

예외가 발생한 뒤에는 해당 try 블록의 남은 문장을 그대로 계속 실행하는 것이 아니라 일치하는 처리기를 찾는다. 현재 위치에서 처리할 수 없으면 상위 호출자로 전파된다. 끝까지 처리되지 않으면 해당 실행 흐름이 비정상 종료될 수 있다.

예외는 종류에 따라 처리 방법이 달라야 한다. 입력 오류를 다시 입력받을 수는 있지만 모든 파일 오류나 내부 결함을 같은 기본값으로 바꾸면 실패가 감춰질 수 있다.

처리기 순서와 자원 정리

여러 예외 처리기를 둘 때는 일반적으로 구체적인 예외를 먼저, 넓은 범위의 예외를 나중에 둔다. 상위 예외를 먼저 잡으면 하위 예외도 함께 처리하여 뒤의 처리기에 도달할 수 없기 때문이다. Java는 도달할 수 없는 catch를 컴파일 오류로 판단할 수 있다.

finally는 정상 종료와 예외 발생 경로에 공통으로 필요한 정리에 사용한다. 파일이나 DB 연결 같은 자원은 사용이 끝나면 반환해야 한다. 자원을 정리했다고 예외를 처리한 것과 같아지는 것은 아니다. 강제 프로세스 종료와 같은 상황까지 finally의 실행을 보장하는 것으로 해석하지 않는다.

안전한 오류 정보

사용자에게는 이해할 수 있는 오류를 전달하고, 내부 로그에는 진단에 필요한 정보를 남긴다. 비밀번호·인증 토큰·상세 DB 접속 문자열을 로그나 응답에 그대로 넣지 않는다. 내부 파일 경로나 SQL 오류 원문을 외부에 노출하면 구현 정보가 드러날 수 있다.

예외를 기록한 뒤 다시 전달했다면 실패는 계속 전파된다. 반대로 catch나 except에서 실패를 숨기고 정상값을 반환하면 호출자는 실패를 알지 못할 수 있다. 기록 여부와 처리 결과를 각각 판단해야 한다.