소프트웨어 오류 처리: 운영 시스템에서 오류를 분류, 기록 및 복구하는 방법

오류 처리는 시스템이 제대로 작동한 후에 추가하는 기능이 아닙니다. 오류 처리는 시스템이 작동을 멈췄을 때 어떻게 동작할지를 결정하는 설계 단계의 핵심 요소입니다. 실제 운영 환경에서는 오류 발생 여부가 아니라 언제 발생할지가 문제입니다. 네트워크 연결이 끊기거나, 데이터베이스를 일시적으로 사용할 수 없게 되거나, 사용자가 개발자의 모든 가정을 어기는 입력을 제출하거나, 외부 서비스에서 예상치 못한 응답이 발생하거나, 하드웨어에 오류가 발생하는 등 다양한 상황이 발생할 수 있습니다. 이러한 모든 상황을 데이터 손상이나 민감한 정보 유출 없이 예측 가능하게 처리하는 시스템은 잘 설계된 시스템입니다. 반대로 이러한 상황 중 하나라도 발생했을 때 시스템이 충돌하거나, 상태 정보가 조용히 손상되거나, 내부 구현 세부 정보가 유출되는 시스템은 아무리 기능을 개발해도 해결할 수 없는 구조적 문제를 안고 있는 것입니다.

부적절한 오류 처리의 실질적인 결과는 가상적인 것이 아닙니다. 잘못된 오류 처리는 이제 소프트웨어 개발에서 가장 중요한 보안 위험 중 하나로 명시적으로 인식되고 있습니다. OWASP A10:2025(예외 조건의 잘못된 처리, 논리적 오류, 오류 발생 시 시스템 개방 유지 등 비정상적인 상황에서 발생하는 관련 시나리오에 중점)는 시스템에서 발생하는 오류를 다룹니다. 이는 2025 OWASP Top 10에 새롭게 추가된 범주로, 오류 처리 실패가 운영 불안정뿐 아니라 악용 가능한 보안 취약점을 초래한다는 점에 대한 성숙한 이해를 반영합니다. 이 범주의 주요 취약점으로는 CWE-209(민감한 정보가 포함된 오류 메시지 생성), CWE-476(NULL 포인터 역참조), CWE-636(안전한 오류 발생 안 함) 등이 있습니다. 이러한 취약점들은 코드베이스 전체에 일관되게 적용되는 체계적인 오류 처리 관행을 통해 예방할 수 있습니다.

소프트웨어 개발에서 오류 처리란 무엇인가?

오류 처리란 소프트웨어 시스템이 정상적인 실행을 방해하는 상황을 감지, 분류 및 대응하는 메커니즘의 집합입니다. 여기에는 예외 포착, 오류 상태 관리, 진단 로깅, 사용자 또는 하위 시스템에 오류 알림, 그리고 영향을 받는 프로세스의 제어된 복구 또는 종료가 포함됩니다. 적절한 오류 처리를 갖춘 시스템은 오류가 전혀 발생하지 않는 시스템이 아니라, 데이터 손상이나 민감한 정보 노출 없이, 그리고 오류가 정상적으로 작동해야 하는 다른 구성 요소로 전파되지 않도록 예측 가능한 방식으로 오류에 대응하는 시스템입니다.

예측 가능한 오류와 혼란스러운 오류의 차이는 운영상 매우 중요합니다. 예측 가능한 오류는 명확한 로그를 생성하고, 정의된 복구 메커니즘을 작동시키며, 운영팀에게 문제 진단 및 해결에 필요한 정보를 제공합니다. 반면, 혼란스러운 오류는 불완전한 로그를 생성하고, 눈에 띄는 오류가 발생하기 전에 시스템 상태를 손상시키며, 온콜팀이 장애 해결보다는 대부분의 시간을 오류 발생 원인을 재구성하는 데 소모하게 만듭니다. 10분 만에 해결되는 장애와 3시간 동안 지속되는 장애의 차이는 종종 오류 자체보다는 오류 발생을 둘러싼 오류 처리의 질에 달려 있습니다.

오류 처리는 보안에 직접적인 영향을 미칩니다. 부적절한 오류 처리로 인해 발생하는 가장 흔한 보안 문제는 스택 트레이스, 데이터베이스 덤프, 오류 코드와 같은 상세한 내부 오류 메시지가 사용자에게 표시되는 경우입니다. 이러한 메시지는 절대 공개되어서는 안 되는 구현 세부 정보를 드러내어 해커에게 사이트의 잠재적 취약점에 대한 중요한 단서를 제공합니다. 효과적인 오류 처리는 내부적으로 기록되는 진단 정보와 사용자에게 반환되거나 API를 통해 노출되는 정보를 엄격하게 분리해야 합니다.

소프트웨어 오류 유형 및 식별 방법

소프트웨어 오류는 하나의 범주로 묶이지 않습니다. 오류는 발생 시점, 감지 방법, 필요한 대응 방안, 그리고 해당 대응 방안의 자동화 가능 여부 등에서 차이를 보입니다. 따라서 오류 분류 체계를 이해하는 것은 모든 오류에 동일한 메커니즘을 적용하는 대신, 각 오류 유형에 적합한 처리 전략을 설계하는 데 필수적입니다.

구문 오류

구문 오류는 코드가 프로그래밍 언어의 문법 규칙을 위반할 때 발생합니다. 컴파일러와 인터프리터는 실행 전에 이러한 오류를 감지하므로, 구문 오류는 처리하기 가장 쉬운 유형입니다. 자동화된 빌드 파이프라인이 있는 시스템에서는 구문 오류가 프로덕션 환경에 배포될 수 없습니다. 그러나 Python이나 JavaScript와 같은 인터프리터 언어에서는 테스트 스위트에서 실행되지 않는 코드 경로의 구문 오류가 프로덕션 환경에 배포되어 해당 경로가 처음 실행될 때 런타임 오류를 일으킬 수 있습니다. 린팅 및 정적 분석 도구는 이러한 환경에서 배포 전에 구문 오류를 잡아냅니다.

런타임 오류

런타임 오류는 프로그램이 정상적인 제어 흐름으로 처리할 수 없는 상황에 직면했을 때 발생합니다. 예를 들어 널 포인터 역참조, 0으로 나누기, 존재하지 않는 파일, 네트워크 연결 실패, 일시적으로 사용할 수 없는 데이터베이스 등이 있습니다. 이러한 오류는 예측 불가능하고, 코드의 제어 범위를 벗어난 외부 조건에 의존하며, 트랜잭션 실행 중 언제든지 발생할 수 있기 때문에 운영 시스템에서 오류 처리 메커니즘의 주요 대상이 됩니다.

런타임 오류는 복구 가능한 오류와 복구 불가능한 오류로 나뉘는데, 이는 오류 처리 시스템이 반드시 내려야 하는 가장 중요한 분류 기준입니다. 일시적인 데이터베이스 연결 실패는 복구 가능한 런타임 오류입니다. 잠시 후 재시도하면 해결될 가능성이 높습니다. 반면, 구성 파일 손상으로 인해 애플리케이션 초기화가 불가능한 경우는 복구 불가능한 런타임 오류입니다. 재시도해도 해결되지 않으며, 명확한 진단 메시지와 함께 시스템을 종료하는 것이 올바른 대응 방법입니다. 이 두 가지 유형의 오류를 동일하게 취급하고, 재시도로 해결할 수 없는 상황에도 동일한 재시도 로직을 적용하는 것은 실제 운영 시스템에서 오류 처리 동작이 통제 불능 상태가 되는 가장 흔한 원인 중 하나입니다.

논리 오류

논리 오류는 표준 오류 처리 메커니즘에 감지되지 않기 때문에 가장 위험한 유형입니다. 프로그램은 예외를 발생시키지 않고 실행되지만, 구현된 논리가 의도한 동작과 일치하지 않아 잘못된 결과를 생성합니다. 반복문 내의 가격 계산 오류, 시간대 차이를 고려하지 않은 날짜 비교, 잘못된 사용자에게 접근 권한을 부여하는 권한 확인 등이 모두 논리 오류입니다. 이러한 오류는 예외 처리기를 작동시키지 않고, 오류 로그에도 기록되지 않으며, 누군가 문제를 알아차리기 전에 여러 하위 시스템으로 잘못된 결과가 전파되는 경우가 많습니다.

논리 오류를 감지하려면 예외를 포착하는 것보다는 결과의 유효성을 검증해야 합니다. 즉, 사후 조건을 확인하는 어설션, 알려진 정확한 참조값과 출력을 비교하는 테스트, 그리고 비즈니스 지표가 예상 범위를 벗어날 때 경고하는 모니터링이 필요합니다.

시스템 오류

시스템 오류는 애플리케이션 코드 외부에서 발생합니다. 하드웨어 오류, 메모리 부족, 운영 체제 리소스 제한, 네트워크 인프라 장애 등이 그 예입니다. 이러한 오류는 일반적으로 애플리케이션 자체에서 해결할 수 없으며, 인프라 계층과의 협력을 통해 대응해야 합니다. 예를 들어, 중복 구성 요소로의 페일오버, 기능 축소를 통한 점진적 시스템 다운, 또는 운영팀에 알림을 보내는 제어된 종료 등이 있습니다. 애플리케이션 코드의 역할은 이러한 상황을 조기에 감지하고, 치명적인 오류 발생보다는 적절한 시스템 다운으로 대응하며, 인프라팀이 발생 원인을 파악할 수 있도록 진단 정보를 제공하는 것입니다.

아래 표는 각 오류 유형을 해당 오류의 감지 메커니즘 및 적절한 대응 전략과 연결합니다.

오류 유형	일어날 때	감지 메커니즘	대응 전략
통사론	컴파일/인터프리트 시간	컴파일러, 린터, 정적 분석	배포 전 수정
런타임(복구 가능)	실행	try-catch, 예외 처리	백오프를 사용하여 재시도하고, 대체 경로를 선택합니다.
런타임 오류(복구 불가)	실행	try-catch, 예외 처리	제어된 종료, 에스컬레이션
논리	실행	결과 검증, 모니터링	논리 오류 수정, 데이터 감사
시스템	실행	인프라 모니터링, 알림	장애 조치, 정상적인 성능 저하

오류 처리가 부적절할 경우 발생하는 결과

부적절한 오류 처리의 결과는 네 가지 범주로 나뉘며, 각 범주는 운영 또는 비즈니스에 직접적인 영향을 미칩니다. 이러한 결과를 구체적으로 이해하는 것이 체계적인 오류 처리 접근 방식에 대한 엔지니어링 투자의 정당성을 확보하는 핵심입니다.

애플리케이션 불안정 및 연쇄 오류

처리되지 않은 예외가 호출 스택의 최상단까지 전파되면 해당 예외를 만난 프로세스 또는 스레드가 종료됩니다. 웹 애플리케이션의 경우, 이는 사용자의 요청에 응답이 없거나, 조치를 취할 수 있는 정보가 없는 일반적인 오류 응답만 받게 됨을 의미합니다. 활성 트랜잭션이나 세션 상태를 사용하는 시스템에서는 트랜잭션이 데이터베이스 관점에서 일관성이 없는 부분적으로 완료된 상태로 남을 수 있습니다.

마이크로서비스 아키텍처에서 처리되지 않은 오류로 인한 애플리케이션 불안정성은 악순환을 초래합니다. 외부 종속성에 대한 서킷 브레이커를 구현하지 못한 서비스는 해당 종속성이 느려지거나 사용 불가능해지면 완료되지 않는 요청을 시도하느라 자체 연결 풀을 고갈시키게 됩니다. 연결 풀이 고갈되면 근본 원인이 상위 호출자와 관련이 있는지 여부와 관계없이 해당 서비스는 상위 호출자에게 접근할 수 없게 됩니다. 예외를 무시하거나, 오류 메시지에 민감한 데이터를 노출하거나, 오류를 조용히 발생시키는 등의 부적절한 오류 처리는 버그와 보안 취약점의 일반적인 원인입니다. 특히 분산 시스템에서 오류를 조용히 발생시키는 것은 경고가 발생하기 전에 오류가 보이지 않게 확산될 수 있기 때문에 매우 위험합니다.

데이터 무결성 손상

여러 단계를 거치는 쓰기 작업 도중에 발생하는 오류는 해당 작업이 원자적 트랜잭션으로 묶이지 않은 경우 시스템을 일관성 없는 상태로 만들 수 있습니다. 대표적인 예는 결제 처리입니다. 사용자의 결제 수단으로의 청구는 성공했지만, 보상 트랜잭션이 발생하지 않고 해당 주문 기록 생성이 실패하면 사용자는 시스템에 존재하지 않는 구매에 대해 비용을 지불하게 됩니다. 이러한 문제를 사후에 해결하려면 수동으로 대조해야 하는데, 이는 비용이 많이 들고 오류 발생 가능성이 높으며 완벽하지 않습니다.

부적절한 오류 처리로 인한 데이터 무결성 실패는 종종 오류가 발생한 후 오랜 시간이 지나서야 발견됩니다. 잘못된 데이터를 사용한 하위 시스템이 이미 그 데이터에 기반하여 조치를 취한 후이기 때문입니다. 오류 발생과 발견 사이의 시간차가 길어질수록 수정 비용은 증가하므로, 원자적 트랜잭션 설계를 통한 예방이 사후 수정보다 훨씬 경제적입니다.

오류 출력에서 ​​발견되는 보안 취약점

데이터베이스 오류를 부적절하게 처리하여 사용자에게 전체 시스템 오류를 노출시키는 것은 공격자에게 더욱 정교한 공격을 계획하는 데 필요한 정보를 제공합니다. 이는 OWASP 2025에서 10대 보안 위험으로 공식 분류되었습니다. HTTP 응답에 노출되는 스택 트레이스는 프레임워크 버전, 파일 경로, 클래스 이름 및 메서드 시그니처를 드러냅니다. 데이터베이스 오류 메시지는 테이블 이름, 열 이름 및 쿼리 구조를 보여줍니다. 이러한 세부 정보는 SQL 인젝션이나 경로 탐색 공격을 성공적으로 수행하는 데 필요한 노력을 추측에서 정보에 기반한 타겟팅으로 줄여줍니다.

이 문제를 해결하려면 두 가지가 필요합니다. 첫째, 사용자에게 노출되는 모든 예외 처리기는 내부적인 세부 정보가 아닌 사용자에게 적합한 메시지만 반환해야 합니다. 둘째, 내부 진단 정보는 폐기하지 않고 적절한 접근 제어가 적용된 로깅 시스템에 기록해야 합니다. 사용자 메시지와 진단 메시지는 목적이 다르므로 독립적으로 생성되어야 합니다.

일관성 없는 오류 처리로 인한 유지보수 부채

표준화된 오류 처리 방식이 없는 코드베이스는 규모가 커짐에 따라 유지보수 부채가 누적됩니다. 각 개발자는 자신만의 규칙을 구현하는데, 어떤 개발자는 사용자 지정 예외를 사용하고, 어떤 개발자는 오류 코드를 반환하며, 어떤 개발자는 오류 발생 시점에 로그를 기록하고, 어떤 개발자는 로깅 없이 오류를 전파합니다. 그 결과, 프로덕션 환경에서 오류 발생 원인을 파악하려면 호환되지 않는 형식의 여러 로그 파일을 읽어야 하고, 모듈별로, 그리고 누가 작성했는지에 따라 다른 오류 처리 규칙을 이해해야 하며, 관련 catch 블록이 비어 있거나 원래 예외 컨텍스트를 무시하는 일반적인 메시지만 기록하여 실제 근본 원인이 기록되지 않았다는 사실을 자주 발견하게 됩니다.

소프트웨어 엔지니어링을 위한 오류 처리 모범 사례

다음 모범 사례는 스타일 선호도가 아닙니다. 각각의 사례는 해당 사례가 없을 때 운영 장애를 일으키는 특정 오류 모드를 해결합니다. 이러한 사례들은 기초적인 내용부터 고급 내용 순으로 나열되어 있으며, 이는 오류 처리 시스템을 구축하거나 기존 시스템을 개선하는 팀이 고려해야 할 순서를 반영합니다.

오류를 발견 시점에 복구 가능 또는 복구 불가능으로 분류합니다.

모든 오류 처리 결정은 단 하나의 분류에서 시작됩니다. 이 오류를 사람의 개입 없이 해결할 수 있는가, 아니면 상위 부서로 보고하거나 프로세스를 종료해야 하는가? 이러한 분류는 오류가 처음 감지된 시점에 이루어져야 하며, 분류에 필요한 맥락 정보가 손실될 수 있는 상위 호출 스택으로 미뤄서는 안 됩니다.

복구 가능한 오류는 재시도, 대체 경로로의 전환 또는 기능 축소 응답을 통해 작업을 허용 가능한 수준으로 완료할 수 있는 오류입니다. 복구 불가능한 오류는 실행을 계속할 경우 잘못된 결과가 발생하거나, 데이터가 손상되거나, 보안 취약점이 생성되는 오류입니다. 필수 구성 파일의 부재, 중요 저장소의 데이터 손상 감지, 대체 수단이 없는 리소스 고갈은 복구 불가능한 오류입니다. 일시적인 네트워크 시간 초과, 외부 API의 속도 제한 응답, 일시적으로 사용 불가능한 보조 서비스는 복구 가능한 오류입니다.

복구 불가능한 오류를 복구 가능한 오류로 잘못 분류하고 재시도 로직을 적용하면 재시도 폭풍이 발생합니다. 이는 재시도를 통해 개선될 수 없는 상황에 대해 무한히 반복되는 프로세스로, 다른 요청을 처리하는 데 사용될 수 있는 리소스를 낭비합니다. 반대로 복구 가능한 오류를 복구 불가능한 오류로 잘못 분류하고 프로세스를 종료하면 불필요한 다운타임이 발생합니다. 따라서 오류 분류는 설계 단계에서 결정해야 하는 사항이며, 각 catch 블록에서 임의로 설정하는 것이 아니라 오류 유형별로 문서화해야 합니다.

중앙 집중식 오류 처리를 구현합니다.

중앙 집중식 오류 처리란 시스템 내 단일 위치에서 오류를 수신하고, 분류하고, 표준화된 메타데이터와 함께 로깅하고, 대응 정책을 결정하는 모든 과정을 담당하는 것을 의미합니다. 개별 모듈은 오류를 감지하고 전파하지만, 로깅 형식, 경고 임계값 또는 대응 전략은 담당하지 않습니다. 이러한 요소들은 중앙 집중식 핸들러에서 한 번 정의되어 일관되게 적용됩니다.

웹 애플리케이션에서 중앙 집중식 오류 처리는 일반적으로 요청 경계에서 처리되지 않은 모든 예외를 포착하고, 요청 컨텍스트(사용자 식별자, 요청 식별자, 엔드포인트, 실행 시간)와 함께 로그를 기록하고, 분류 로직을 적용하고, 오류 클래스에 적합한 응답을 반환하는 미들웨어 구성 요소 형태로 이루어집니다. 언어 프레임워크는 이를 위한 연결 고리를 제공합니다. Node.js의 Express 미들웨어가 그 예입니다. @ControllerAdvice Spring에서 React의 오류 경계 구성 요소 app.errorhandler Flask에서.

가장 큰 장점은 일관성입니다. 시스템 어디에 기록되든 모든 오류는 동일한 형식을 갖습니다. 사용자에게 노출되는 모든 오류는 동일한 검증 로직을 거칩니다. 정의된 심각도 임계값을 초과하는 모든 오류는 동일한 경고를 발생시킵니다. 이러한 일관성 덕분에 로그 분석 및 사고 대응이 수작업이 아닌 효율적인 방식으로 이루어질 수 있습니다.

지터를 사용하여 재시도 횟수를 늘리는 지수 백오프 알고리즘을 구현하세요.

백오프 없이 재시도를 수행하면 오히려 문제를 악화시킬 수 있습니다. 데이터베이스에 일시적으로 과부하가 걸린 상태에서 100개의 클라이언트가 동시에 1초 간격으로 실패한 요청을 재시도하면, 재시도 트래픽으로 인해 데이터베이스가 전혀 복구되지 못할 수 있습니다. 지수 백오프는 재시도 간 지연 시간을 점진적으로 증가시켜 실패한 구성 요소에 가해지는 재시도 부담을 줄이고 복구할 시간을 제공합니다.

지터는 재시도 폭주 현상을 방지하기 위해 지연 시간에 무작위성을 도입합니다. 모든 클라이언트가 동일한 결정론적 백오프 스케줄을 사용하는 경우, 각 지연 시간 후 모든 클라이언트가 동시에 재시도하게 되어 동기화 문제가 발생합니다. 지연 시간을 특정 범위 내에서 무작위화하면 여러 클라이언트의 재시도 트래픽이 동기화되는 대신 시간에 걸쳐 분산됩니다.

재시도는 재시도 대상 작업이 멱등성을 가질 때만 안전합니다. 즉, 여러 번 실행해도 한 번 실행했을 때와 동일한 결과를 생성한다는 의미입니다. 읽기 작업은 본질적으로 멱등성을 가집니다. 쓰기 작업은 설계 단계부터 멱등성을 갖도록 해야 하며, 일반적으로 서버가 동일한 요청의 중복 전송을 제거하는 데 사용하는 요청에 멱등성 키를 포함시키는 방식으로 구현됩니다.

파이썬

import time
import random

def with_retry(operation, max_attempts=4, base_delay_seconds=1.0):
    """
    Execute an operation with exponential backoff and jitter.
    Only retries on recoverable IOError and TimeoutError.
    Propagates all other exceptions immediately without retry.
    """
    for attempt in range(max_attempts):
        try:
            return operation()
        except (IOError, TimeoutError) as exc:
            if attempt == max_attempts - 1:
                raise  # exhausted retries, propagate
            delay = base_delay_seconds * (2 ** attempt) + random.uniform(0, 0.5)
            print(f"Attempt {attempt + 1} failed ({exc}). Retrying in {delay:.1f}s")
            time.sleep(delay)
        except Exception:
            raise  # unrecoverable, do not retry

전체 진단 컨텍스트를 포함하는 구조화된 로깅을 사용하십시오.

실행 중이던 작업, 입력값, 시스템 상태 등 컨텍스트 정보 없이 예외 메시지만 포함된 로그 항목은 디버깅 엔지니어가 오류를 재현해야만 이해할 수 있도록 만듭니다. 하지만 실제 운영 환경에서는 오류 재현이 불가능한 경우가 많습니다. 구조화된 로깅은 오류를 정의된 필드를 가진 객체로 캡처합니다. 이러한 필드에는 ISO 8601 형식의 타임스탬프, 심각도 수준, 고유 오류 식별자, 모듈 및 함수, 전체 스택 추적, 그리고 사용자 식별자, 요청 식별자, 실패한 작업과 관련된 매개변수 등의 작업별 컨텍스트 필드가 포함됩니다.

이러한 구조 덕분에 비정형 로그 텍스트로는 불가능한 로깅 시스템에 대한 쿼리가 가능해집니다. 예를 들어 지난 30분 동안 결제 모듈에서 발생한 모든 타임아웃 오류, 지난 24시간 동안 사용자 ID 12345의 요청에 영향을 미친 모든 오류, 스택 트레이스에 특정 함수에 대한 참조가 포함된 모든 오류 등을 검색할 수 있습니다. 이러한 쿼리 기능 덕분에 사고 후 분석이 효율적으로 이루어집니다.

사용자에게 표시되는 오류 메시지는 내부 로그 항목과는 별개의 문제입니다. 로그 항목에는 진단에 필요한 모든 정보가 포함되어야 합니다. 사용자에게 표시되는 메시지에는 구현 세부 정보가 드러나서는 안 되며, 발생한 상황, 필요한 조치, 그리고 문제가 지속될 경우 어떻게 해야 하는지에 대한 정보를 제공해야 합니다.

소프트웨어 플랫폼은 오류를 사용자에게 어떻게 알려야 할까요?

효과적인 사용자 오류 메시지 전달은 네 가지 원칙을 따릅니다. 첫째, 시스템 내부 구조를 반영하는 용어가 아닌 사용자가 이해하기 쉬운 용어로 문제를 설명해야 합니다. "현재 결제를 처리할 수 없습니다."와 같은 표현이 "거래 롤백: 주문 테이블 제약 조건 위반"보다 효과적입니다. 둘째, 문제가 일시적인지 또는 사용자 조치가 필요한지 명확히 해야 합니다. 일시적인 서비스 중단의 경우 "잠시 후 다시 시도해 주세요."와 같이 안내하고, 유효성 검사 오류의 경우 "카드 번호가 정확한지 확인해 주세요."와 같이 안내해야 합니다. 셋째, 진행 중인 거래에 영향을 미치는 오류의 경우 해당 거래의 상태를 명확하게 알려야 합니다. 결제가 이루어지지 않았다면 명확하게, 주문이 완료되지 않았다면 명확하게 알려야 합니다. 거래 상태에 대한 불확실성은 사용자 불신의 주요 원인 중 하나입니다. 넷째, 사용자가 스스로 문제를 해결할 수 없는 경우 지원을 받을 수 있는 방법을 제공해야 합니다.

이러한 원칙을 구현하려면 사용자에게 노출되는 경계면의 오류 처리 코드가 오류 분류(표시할 메시지 유형을 결정하기 위해), 오류 컨텍스트(사용자가 수행하던 작업에 맞춰 메시지를 구체화하기 위해) 및 애플리케이션 전체에서 일관된 메시지 형식을 생성하는 템플릿 시스템에 접근할 수 있어야 합니다.

오류 발생 시 접근을 차단하는 설계 원칙: 보안 제어 오류 발생 시 접근을 차단합니다.

부적절한 오류 처리로 인해 발생하는 일반적인 보안 문제 중 하나는 'fail-open' 보안 검사입니다. 모든 보안 메커니즘은 명시적으로 허용될 때까지 접근을 거부해야 하며, 거부될 때까지 접근을 허용해서는 안 됩니다. 이는 'fail-open' 오류가 발생하는 흔한 원인입니다. 인증 검사에서 예기치 않은 예외가 발생하면 접근을 거부하는 것이 올바른 동작입니다. 권한 부여 검사에서 데이터베이스 오류로 인해 사용자 권한을 가져오지 못하는 경우에도 접근을 거부하는 것이 올바른 동작입니다. 접근을 거부해야 할 메커니즘이 실패했음에도 불구하고 접근을 허용하는 결과를 반환하는 것이 바로 'fail-open'이며, OWASP 2025의 A10 범주에서 심각한 취약점 패턴으로 명시적으로 나열되어 있습니다.

보안 제어에서 실패 시에도 안전한 오류 처리를 구현한다는 것은 예외 발생 시 가장 엄격한 결과를 기본적으로 적용하는 오류 처리기로 제어를 감싸는 것을 의미합니다. 즉, 보안에 민감한 컨텍스트에서 실행을 계속 허용하는 단순한 catch 블록을 절대 사용하지 않는 것을 의미합니다. 또한 보안 제어의 오류 경로를 정상 경로만큼 엄격하게 테스트하는 것을 의미합니다.

분산 시스템을 위한 오류 처리 설계 패턴

회로 차단기 패턴

회로 차단기 패턴은 한 서비스의 장애가 하위 서비스로 확산되는 것을 방지합니다. 서비스 종속성이 정의된 오류율 임계값을 초과하면 회로 차단기가 열려 해당 종속성으로의 요청 전달을 중단하고, 종속성의 응답을 기다리지 않고 즉시 오류 또는 대체 응답을 반환합니다. 구성 가능한 대기 시간 후, 회로 차단기는 반개방 상태로 전환되어 소수의 프로브 요청을 허용합니다. 이러한 요청이 성공하면 회로가 닫히고 정상적인 트래픽이 재개됩니다. 요청이 실패하면 회로가 다시 열리고 대기 시간이 재설정됩니다.

회로 차단기가 없으면, 느리거나 사용 불가능한 종속성으로 인해 해당 서비스의 스레드가 응답을 기다리며 차단되고, 응답이 오지 않을 수도 있습니다. 스레드 풀이 가득 차고 새로운 요청을 처리할 수 없게 되며, 결국 해당 서비스 자체를 호출자가 사용할 수 없게 됩니다. 회로 차단기는 이러한 연쇄적인 장애를 제한된 장애로 전환합니다. 즉, 종속성을 사용할 수 없게 되지만, 해당 서비스를 계속 운영하여 종속성에 의존하지 않는 요청을 처리할 수 있습니다.

격벽 패턴

벌크헤드 패턴은 의존성에 따라 리소스 풀을 격리하여 한 풀의 리소스가 고갈되더라도 해당 풀을 사용하지 않는 요청에는 영향을 미치지 않도록 합니다. 예를 들어, 세 개의 외부 API를 호출하는 서비스에서 각 API에 별도의 스레드 풀을 할당하면 API A에 대한 느린 요청이 폭주하더라도 API A의 스레드 풀만 고갈됩니다. API B와 C에 대한 요청은 스레드 풀이 분리되어 있으므로 정상적으로 처리됩니다.

격리 경계는 격리의 중요도와 각 접근 방식에 따른 오버헤드에 따라 스레드 풀 수준, 연결 풀 수준 또는 프로세스 수준에서 적용할 수 있습니다. 모든 경우에 적용되는 원칙은 동일합니다. 즉, 하나의 종속성에서 오류가 발생하더라도 다른 종속성에 필요한 리소스를 소모해서는 안 됩니다.

분산 트랜잭션을 위한 사가 패턴

여러 서비스에 걸쳐 비즈니스 운영이 이루어지는 분산 시스템에서 한 단계가 실패하더라도 데이터 무결성을 유지하려면 보상 전략이 필요합니다. 사가 패턴은 일련의 로컬 트랜잭션을 정의하며, 각 트랜잭션에는 해당 트랜잭션의 효과를 되돌리는 보상 트랜잭션이 대응됩니다. 사가의 N번째 단계가 실패하면, 사가는 N-1번째 단계부터 1번째 단계까지의 보상 트랜잭션을 역순으로 실행하여 시스템을 사가 이전 상태로 복원합니다.

사가 패턴은 데이터베이스 수준에서 원자성을 보장하지 않습니다. 롤백이 아닌 보상을 통해 최종 일관성을 달성합니다. 즉, 단계의 성공과 보상 실행 사이의 시간 간격 동안 시스템이 비즈니스 규칙에서 의도하지 않은 상태에 있을 수 있습니다. 각 단계의 오류 처리는 이러한 상황을 고려해야 합니다. 보상 트랜잭션은 멱등성을 가져야 하며, 사가 오케스트레이터는 장애 발생 시에도 마지막으로 일관된 상태에서 복구할 수 있도록 설계되어야 합니다.

안전하지 않은 출력 처리를 방지하는 방법

오류 메시지 맥락에서 안전하지 않은 출력 처리는 웹 애플리케이션에서 가장 지속적으로 악용되는 취약점 유형 중 하나입니다. 공격 패턴은 간단합니다. 잘못된 형식의 입력, 예상치 못한 데이터 유형 또는 예외 경로를 유발하는 경계값을 전송하여 애플리케이션이 오류를 발생시키도록 강제합니다. 그런 다음 오류 메시지 또는 HTTP 응답 본문을 읽고, 드러난 구현 세부 정보를 추출합니다. 추출한 정보를 사용하여 공격을 더욱 정교하게 만듭니다.

안전하지 않은 출력 처리를 방지하려면 다음 사항이 필요합니다.

사용자에게 표시되는 응답에 내부 예외 세부 정보를 절대 포함하지 마십시오. 사용자가 수신하는 HTTP 응답 본문, JSON 오류 객체 및 HTML 오류 페이지에는 사용자에게 적합한 메시지와 (선택적으로) 지원 담당자가 내부 로그 항목을 조회하는 데 사용할 수 있는 오류 참조 코드가 포함되어야 합니다. 이러한 요소에는 스택 트레이스, SQL 문, 파일 경로, 클래스 이름 또는 프레임워크 버전이 절대 포함되어서는 안 됩니다.

오류 처리 코드가 테스트되었는지 확인하십시오. 오류 조건에 대한 단위 테스트는 오류 응답에 포함된 내용뿐만 아니라 포함되지 않은 내용에 대해서도 검증해야 합니다. 응답 상태가 500임을 확인하는 테스트는 응답 본문에 스택 트레이스가 포함되어 있지 않음을 검증하지 않는 한, 이 취약점에 대한 불완전한 테스트입니다.

구조화된 오류 응답 형식을 일관되게 사용하십시오. 모든 엔드포인트에 일관되게 적용되는 표준화된 오류 응답 체계를 사용하면 반환되는 정보를 감사하기 쉽고 내부 세부 정보가 포함되지 않도록 강제하기 쉽습니다. 임의적인 오류 응답 형식은 불일치와 의도치 않은 정보 유출이 발생하는 지점입니다.

진단 세부 정보를 모두 내부적으로 기록합니다. 사용자에게 표시되는 응답에 포함되어서는 안 되는 진단 정보는 엔지니어링 팀이 접근할 수 있는 곳에 기록되어야 합니다. 구조화된 필드와 적절한 접근 제어 기능을 갖춘 로깅 시스템이 적합한 대상입니다. 로깅 호출과 사용자에게 표시되는 응답 생성은 오류 처리 코드 내에서 명확하게 분리된 작업이어야 하며, 공통 메시지 문자열을 공유해서는 안 됩니다.

진단 로깅과 사용자 응답 간의 분리를 보여주는 구체적인 Java 예제:

자바

@ExceptionHandler(Exception.class)
public ResponseEntity<ErrorResponse> handleUnexpectedError(
        Exception ex, HttpServletRequest request) {

    // Full diagnostic context logged internally; never sent to the user
    String errorId = UUID.randomUUID().toString();
    log.error("Unhandled exception [errorId={}] [path={}] [userId={}]",
            errorId,
            request.getRequestURI(),
            getCurrentUserId(),
            ex);  // full stack trace captured in the log entry

    // User-facing response: error ID for support lookup, no internal details
    ErrorResponse response = new ErrorResponse(
            "An unexpected error occurred. Reference: " + errorId,
            Instant.now()
    );
    return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(response);
}

이 패턴은 스택 트레이스, 예외 클래스 및 모든 내부 컨텍스트가 로그에 기록되도록 보장하는 동시에 사용자에게는 지원 담당자가 해당 로그 항목을 검색하는 데 사용할 수 있는 참조 코드만 제공합니다.

오류 처리 격차 분석을 위한 정적 코드 분석

실제 운영 환경에서 문제를 일으킬 가능성이 가장 높은 오류 처리 허점은 코드 리뷰어가 쉽게 발견하는 명백한 오류가 아닙니다. 오히려 규모가 커지는 코드베이스 전체에 걸쳐 조용히 축적되는 구조적 패턴들이 문제입니다. 예를 들어, 예외를 로깅하지 않고 그대로 두는 빈 catch 블록, 원래 예외는 무시하고 일반적인 메시지만 로깅하는 catch 블록, 호출자가 확인하지 않는 오류 반환 값, 그리고 보안에 민감한 코드 경로에서 예외 처리가 실패하더라도 실행을 계속하도록 허용하는 경우 등이 있습니다. 이러한 패턴들은 리뷰어가 특별히 찾아보지 않는 한 눈에 띄지 않으며, 대규모 코드베이스에서 모든 catch 블록을 검토하는 것은 현실적으로 불가능합니다.

정적 코드 분석 도구는 이러한 문제를 체계적으로 해결합니다. 코드를 실행하지 않고 소스 코드를 추상 구문 트리로 파싱한 다음, 해당 구조에서 잘못된 오류 처리와 관련된 패턴을 찾아냅니다. SonarQube와 같은 도구는 소스 코드에서 안전하지 않고 신뢰할 수 없는 오류 처리 패턴, 예를 들어 비어 있는 catch 블록, 노출된 스택 트레이스, 누락된 유효성 검사 등을 탐지합니다. 이러한 분석은 최근 변경된 파일이나 최근 문제가 발생한 모듈뿐만 아니라 전체 코드베이스를 한 번에 분석합니다.

여러 언어가 혼합된 엔터프라이즈 시스템의 경우, 분석은 환경에 존재하는 모든 언어를 포괄해야 합니다. 오류를 올바르게 처리하는 Java 서비스라도 메인프레임 계층에서 오류를 전달하지 않는 인터페이스를 통해 COBOL 프로그램을 호출하는 경우, Java 전용 정적 분석으로는 파악할 수 없는 오류 처리상의 허점이 발생합니다. 이는 앞서 논의된 맥락에서 확인할 수 있습니다. 다양한 언어에 걸친 엔터프라이즈 정적 코드 분석시스템 내 모든 언어를 아우르는 통합 분석은 파일 수준이 아닌 시스템 수준에서 오류 처리의 허점을 찾아내는 데 필요한 기술적 전제 조건입니다.

레거시 시스템의 경우, 오류 처리 부채는 일반적으로 코드베이스의 가장 오래된 부분에 집중되어 있는데, 이는 최신 관행이 표준화되기 전에 오류 처리 규칙이 확립되었기 때문입니다. 분석에서 살펴본 바와 같이 기존 시스템의 현대화 및 오류 처리분산되고 일관성이 없는 오류 처리 방식에서 중앙 집중식의 표준화된 접근 방식으로 전환하는 것은, 변경이 이루어지기 전에 현재 상태를 파악할 수 있는 자동화 도구를 활용하면 이점을 얻을 수 있는 현대화 작업입니다.

방법 SMART TS XL 시스템 규모의 오류 처리 문제를 다룹니다.

SMART TS XL 이 도구는 COBOL, JCL, Java, .NET, Python, JavaScript, TypeScript, SQL을 포함한 모든 언어 및 플랫폼의 소스 코드를 수집하여 전체 소프트웨어 환경에 대한 통합된 상호 참조 모델을 구축하고, 모든 구성 요소 간의 관계를 나타내는 구조적 인덱스를 생성합니다. 오류 처리 분석과 관련하여 이 모델은 단일 언어 도구로는 답할 수 없는 질문, 즉 COBOL 프로그램에서 어떤 함수가 호출자에게 오류를 전파하는지, 해당 함수를 호출한 어떤 함수가 전파된 오류를 처리하는지, 그리고 호출 체인에 오류 처리가 없이 시스템을 통해 어떤 경로로 사용자에게 표시되는 출력을 생성할 수 있는지에 대한 답을 제공합니다.

플랫폼의 영향 분석 기능은 이를 변경 평가까지 확장합니다. 공유 구성 요소의 오류 처리 동작을 수정하기 전에 영향 분석을 통해 현재 동작에 의존하는 시스템 내 다른 모든 구성 요소를 식별하여, 알 수 없는 하위 시스템에 미치는 영향을 감수하면서 배포하는 대신 변경 사항을 단계적으로 검증할 수 있도록 합니다. 이것이 바로 본문에 설명된 분석입니다. 영향 분석 솔루션 IN-COM이 기업 환경에 제공하는 기능은 오류 처리 로직 변경이 어떤 영향을 미칠지 변경 전에 파악하는 문제에 특히 적용됩니다.

SMART TS XL이 회사의 엔터프라이즈 검색 기능은 분석을 쉽게 탐색할 수 있도록 해줍니다. 시스템에서 예외를 로깅하지 않고 처리하는 모든 함수를 검색하면 특정 파일 위치와 함수 이름이 반환되며, 언어별 및 해당 함수를 호출하는 사용자 수에 따른 심각도별로 정리됩니다. 이러한 우선순위 지정 덕분에 오류 처리 관련 문제점을 해결하는 것이 부담스럽지 않고 실행 가능한 조치로 이루어질 수 있습니다.

시스템 수준 속성으로서의 오류 처리

효과적인 오류 처리는 개별 모듈만의 고유한 특성이 아닙니다. 모듈이 자체 오류를 올바르게 처리하더라도, 중앙 집중식 로깅이 없고, 외부 종속성에 대한 안전장치가 없으며, 다단계 쓰기 작업에 대한 원자적 트랜잭션 설계가 없는 시스템에서 작동한다면, 진단하기 어려운 운영상의 문제를 여전히 발생시킬 수 있습니다. 모듈 수준의 정확성은 필수적이지만 충분조건은 아닙니다.

전체 애플리케이션에서 효과적인 오류 처리를 가능하게 하는 시스템 수준의 속성은 다음과 같습니다. 복구 가능한 조건과 복구 불가능한 조건을 모든 계층에서 다르게 처리하도록 일관된 오류 분류 체계를 구축하고, 모든 오류 이벤트를 표준화된 메타데이터와 함께 단일 쿼리 가능한 시스템에 캡처하는 중앙 집중식 로깅 시스템을 운영하며, 하나의 종속성 실패로 인해 다른 종속성에 필요한 리소스가 고갈되지 않도록 모든 외부 종속성에 회로 차단기를 적용하고, 부분 완료로 인해 일관성이 없는 상태가 발생하지 않도록 모든 다단계 쓰기 작업에 대해 원자적 트랜잭션 설계를 적용하며, 접근 제어 검사에서 오류가 발생하면 접근을 허용하는 대신 거부하도록 모든 보안 민감 코드 경로에 안전한 오류 처리 기본값을 적용합니다.

현재 이러한 기능을 갖추지 못한 시스템에 이러한 속성을 구축하는 것은 단 한 번의 리팩토링으로 해결되는 것이 아니라 점진적인 작업입니다. 실질적인 접근 방식은 정적 분석을 통해 현재의 부족한 부분을 파악하고, 안정성과 보안에 미치는 잠재적 영향에 따라 우선순위를 정한 다음, 위험도가 가장 높은 패턴부터 단계적으로 개선하는 것입니다. 최종 목표는 엔지니어가 새로운 기능을 작성할 때마다 오류 처리를 고민하지 않아도 되는 시스템을 구축하는 것입니다. 패턴이 표준화되고, 프레임워크가 이를 강제하며, CI 파이프라인이 새로운 코드가 팀에서 제거하기로 합의한 안티 패턴을 도입하지 않는지 검증하기 때문입니다.