답변.

질문 배경

마이크로서비스 아키텍처와 분산 시스템으로의 전환으로 인해 서비스 간 상호작용에서 발생하는 오류의 가능성이 급격히 증가했으며, 이를 처리하는 복잡성이 높아졌습니다. 초기 접근 방식은 네트워크 상호작용의 불안정성을 종종 고려하지 않아, 프로덕션에서 대규모 사고가 발생하였습니다.

문제

핵심 문제는 복잡한 실패 시나리오, 서비스의 성능 저하 및 통합 오류가 요구 사항에 충분히 형식화되지 않았다는 것입니다. 이로 인해 개발자들은 오류 처리에 대한 결정을 스스로 내려야 하며, 이는 다양한 사례와 테스트의 어려움을 초래합니다.

해결책

효과적인 오류 처리는 다음을 포함해야 합니다:

• 오류 유형 정의 (네트워크 실패, 타임아웃, 제3자 서비스의 실패, 비즈니스 논리의 오류, 데이터 불일치).
• 각 오류 유형에 대한 반응 옵션 문서화: 재시도, 트랜잭션 롤백, 기능성 저하, 알림, 사용자 메시지.
• 실패 테스트를 위한 명확한 시나리오 도입 (fail-over, graceful degradation), 비특정 및 연쇄 사고 포함.
• 오류 계약 및 형식 문서화 (예: 표준 JSON 오류 응답 계약).

핵심 특징:

• 서비스 간 오류 처리 템플릿 표준화.
• 성능 저하 시나리오 검증 및 비즈니스와의 조정.
• 후속 사고 분석을 위한 오류 추적 및 로깅 보장.

헷갈리는 질문들.

기술적 오류 처리를 요구 사항에 설명하는 것이 필수인가요? 개발자의 업무가 아닌가요?

필수입니다. 오류 처리 정책이 반영되지 않으면 작업에 오류가 발생하고 오해가 생길 수 있습니다. 시스템 분석가는 오류 발생 시 동작을 논의해야 합니다.

매우 드물게 발생하는 경우(예: 서비스 간의 부분적 연결 손실)를 설명해야 하나요?

네, 드물게 발생하는 오류가 가장 복잡한 사고로 이어질 수 있습니다. 그 결과는 비즈니스에 치명적일 수 있습니다.

오류 발생 시 사용자에게 표시되는 메시지를 비즈니스와 조정해야 하나요?

네. 정확하고 정보가 풍부하지만 과도하거나 두려움을 주지 않는 메시지는 비즈니스와 조정되어야 하며, 그렇지 않으면 사용자 경험과 충성도에 악영향을 미칩니다.

일반적인 오류 및 안티 패턴

• 해피 패스만 설명하고 실패 시나리오를 무시함.
• 시스템의 성능 저하 고려 부족 (예비 시나리오 미기재).
• 사용자에게 기술적으로 복잡하거나 일관되지 않은 오류 메시지.

실생활 사례

부정적인 사례: 프로젝트에서 서비스 간 타임아웃 처리 시나리오가 설명되지 않았습니다. 결과적으로 불안정한 네트워크로 서비스가 "멈춤" 없이 응답하지 않았습니다. 장점: 주요 시나리오의 빠른 실행. 단점: 프로덕션에서의 대규모 중단, 고객의 부정적인 반응, 수동 인시던트 종료.

긍정적인 사례: 분석가는 성능 저하 및 재시작, 재시도 및 정확한 메시지에 대한 시나리오를 문서화했습니다. 장점: 장애 시 서비스의 높은 안정성, 사고 수 감소. 단점: 시나리오 아키텍처 작업에 더 많은 시간 소요.