[ TIL / iOS ] 명확한 책임 분리로 완성한 에러 처리 체계

문제 상황

1. 맥락 에러(ContextualError) 도입 후 문제 발생
   맥락 에러를 통해 에러의 발생 위치와 상황을 명확히 하려 했으나, 일부 레거시 코드로 인해 에러가 올바르게 전달되지 않고 비효율적으로 처리되고 있었습니다.
2. 레거시 코드로 인한 의존성 및 책임 문제
   레거시 코드가 여전히 존재하면서 의존성 규칙(Clean Architecture 원칙)이 어긋났고, 각 계층의 책임이 명확히 분리되지 않은 상태였습니다.

이러한 문제로 인해 에러 처리 체계의 일관성이 떨어지고, 코드 유지보수 및 확장성이 저하되는 상황이었습니다.

해결방법

1. 레거시 코드 제거 및 의존성 재정비

• 데이터 계층(Data Layer)에서 발생한 에러(DataError)를 도메인 계층으로 전달할 때, 불필요한 변환 로직과 중복된 에러 처리를 제거
• 도메인 계층(Domain Layer)에는 ContextualError(Domain Error)를 생성 의존성 규칙에 어긋나지 않도록 Data Error 직접 참조가 아닌 Error 데이터 형태로 참조
• Presentation Error 변환 로직은 Presentation Layer로 위임

2. ErrorMapper 활용

• 도메인 계층에서 ContextualError를 사용자 친화적인 PresentationError로 변환하기 위해 ErrorMapper를 도입
• 모든 에러를 공통적으로 처리할 수 있는 체계적인 변환 로직을 구축

3. 책임 분리 강화

< Data Layer >

• 데이터 계층은 데이터 접근 및 에러 방출에만 집중.
• DataSource : API 통신 담당, 통신 과정에서 발생하는 에러 방출
• Repository(구현부): 응답 데이터 DTO -> Domain or 요청 데이터 Domain -> DTO 변환 담당, 매핑과정에서 발생하는 에러 방출 (DataSource에서 발생한 에러는 별다른 처리 없이 그대로 전달)

< Domain Layer>

• 도메인 계층은 비즈니스 로직과 맥락 추가(ContextualError) 등의 에러핸들링에만 집중.
• UseCase: 비즈니스 로직 처리, 데이터 레이어에서 전달받은 에러를 ContextualError로 변환 및 대체 값으로 변환 등의 에러핸들링

< Presentation Layer>

• 프레젠테이션 계층은 사용자 UI에 적합한 메시지와 동작(PresentationError)만 처리하도록 역할을 명확히 분리.

성과

1. 에러 처리 체계 개선
   • 레거시 코드 제거와 의존성 규칙 준수를 통해, 에러 처리 흐름이 단순화되고 일관성을 확보
   • 에러 발생 위치와 맥락(Context)을 포함한 정보를 정확히 전달 가능
2. DX와 UX 모두 개선
   • DX: 디버깅이 쉬워지고, 로깅이 체계적으로 이루어져 개발 효율성 증가
   • UX: 사용자에게 정확하고 친화적인 에러 메시지를 제공하여, 사용자 경험 향상

마무리

의존성과 책임 분리가 만드는 명확함

• 에러 처리 체계를 개선하면서, 각 계층의 역할과 책임을 명확히 나누는 것이 얼마나 중요한지 깨달았습니다.
• 이전에는 “그냥 동작만 하면 된다”라고 생각했던 부분도, 각 계층의 역할에 따라 에러를 분리하고 변환하니 코드의 흐름이 더 직관적으로 느껴졌습니다.
• 특히, 데이터 계층의 원시 에러를 도메인 계층에서 비즈니스 맥락을 추가해 처리하고, 이를 사용자 친화적인 방식으로 변환하는 구조가 체계적으로 다가왔습니다.

이번 개선 과정을 통해 단순히 문제를 해결하는 것을 넘어, 명확한 책임 분리와 구조적인 설계의 중요성을 깊이 이해하게 되었습니다.