답변.

분산 IT 시스템의 발전 역사에서 오류 처리 및 실패 시나리오에 대한 문제는 오랫동안 비즈니스 논리에 비해 덜 중요하게 여겨졌습니다. 그러나 규모가 커지고 인프라가 복잡해짐에 따라, 덜 정교한 오류 처리 시나리오가 대규모 실패와 데이터 손실로 이어질 수 있음을 보였습니다.

문제는 복잡한 시스템이 다양한 유형의 실패를 경험한다는 것입니다: 특정 서비스의 비가용성, 데이터 불일치, 또는 통신 채널의 부분적 실패 등입니다. 종종 고객은 '실패'를 명백한 오류(예: 서버 비가용)만 이해하고, 서비스 간의 오류 연쇄나 사용자 경험의 저하를 간과합니다.

효과적인 해결책은 시스템 접근 방식에 기반합니다:

• 모든 가능한 실패 지점을 발견합니다.
• 아키텍트, QA, 설계자 및 운영 엔지니어와 협력하여 이들이 발생할 수 있는 포괄적인 시나리오를 개발합니다.
• 비즈니스와 시스템의 동작을 조정합니다 (예: 주문을 연기할 수 있는지, 작업을 캐시해야 하는지).
• 모든 유형의 오류 메시지와 처리 경로에 대한 명확한 문서화가 필요합니다.

주요 특징:

• 치명적인 실패뿐만 아니라 부드럽고 변동적인 실패(예: 외부 서비스의 일시적 비가용성)를 처리합니다.
• UI 및 기능의 저하 시나리오를 포함합니다.
• 요구 사항을 개발하는 모든 단계에서 비즈니스 오류와 기술적 실패를 구분합니다.

함정 질문.

애플리케이션 레벨의 예외와 인프라 레벨의 예외의 차이점은 무엇인가요?

후보자들은 비즈니스 오류(예: '사용자를 찾을 수 없음')와 실제 실패(예: '데이터베이스가 비가용')를 자주 혼동합니다. 애플리케이션은 항상 두 가지 유형의 예외를 명확히 구분하고, 서로 다른 처리 전략(롤백, 알림, 경고)을 제공해야 합니다.

내부 API의 실패 시나리오는 어떻게 모델링해야 하나요? 공개되지 않은 경우?

실패 시나리오는 모든 API에 대해 중요합니다: 내부 API일지라도 실패는 언제든지 발생할 수 있으며(자동화 컨투어 내에서도), 이들을 명시적으로 모델링하여 신뢰할 수 없는/누락된 데이터로 작업할 수 있어야 합니다.

시스템이 최대의 사용자 경험을 위해 모든 오류를 사용자에게 숨겨야 하나요?

아니요, 모든 오류를 절대적으로 숨기면 사용자에게 잘못된 정보를 줄 수 있습니다. 정보 제공(사용자가 다음에 무엇을 해야 할지 이해할 수 있도록)과 안전성(구현 세부 사항 공개 금지) 간의 균형을 찾는 것이 중요합니다.

일반적인 오류 및 안티 패턴

• 비공식적인 실패 처리(기본값인 catch로 남겨둠).
• 부분 실패 시 저하 시나리오 부족(예: 마이크로서비스의 사례에서, 작동하지 않는 장바구니가 주문 진행을 완전히 차단함).
• '침묵하는' 실패 누적 무시(비상 상황에 대한 경고/모니터링 없음).

실제 사례

부정적인 사례: 대형 e-commerce 프로젝트에서 시스템 애널리스트는 모든 네트워크 오류 처리를 아키텍처에 맡겼습니다. 비상 업데이트 및 이메일 서비스 실패로 인해 시스템은 주문 알림을 전송하지 않았고, 사용자들은 자신의 주문이 생성되었는지 이해하지 못했습니다.

장점:

• 요구 사항 설명의 단순화.

단점:

• 데이터 손실(주문 생성 증명 불가).
• 제품 출시 후 지원 비용 증가.

긍정적인 사례: 시스템 애널리스트는 아키텍트와 함께 각 비판적인 서비스에 대한 별도의 시나리오를 모델링했습니다: 이메일 큐 비가용성, 결제 게이트웨이 장애, 검색 서비스 저하. 고객을 위한 사용자 친화적인 메시지가 작성되었습니다.

장점:

• 플랫폼에 대한 고객의 신뢰도 향상.
• 운영 위험 최소화.

단점:

• 문서량 및 테스트의 복잡성 증가.