ADR-0010: HTTP 에러 화면을 전체 화면으로 통일하고 셸 유지 판정을 두지 않는다

상태

Accepted

2026-08-10

인증 후 업무 화면에서 존재하지 않는 경로로 이동하거나 권한이 없는 자원을 요청하면 에러 화면이 표시됩니다. 이때 앱셸의 네비게이션과 헤더를 유지할지 정해야 합니다.

셸을 유지하면 사용자가 다른 화면으로 한 번의 클릭으로 이동할 수 있습니다. 유지하지 않으면 화면 전체가 에러로 바뀝니다.

검토 과정에서 셸을 유지하고 싶어도 유지할 수 없는 경우가 있다는 점이 드러났습니다.

즉 셸 유지를 규칙으로 삼으면 에러가 발생할 때마다 "지금 셸을 그릴 수 있는가"를 판정해야 합니다. 판정이 들어가는 규칙은 1순위 품질 목표인 예측 가능성을 떨어뜨립니다.

401 · 403 · 404 · 500을 전체 화면 에러로 통일합니다. 앱셸의 네비게이션과 헤더를 유지하지 않으며, 셸 유지 여부를 상황마다 판정하지 않습니다.

전체 화면 에러는 다음을 필수로 갖습니다.

복구 액션은 이 결정의 전제입니다. 셸을 제거하고 화면 안에 복구 경로도 두지 않으면 사용자에게 남는 수단은 브라우저 뒤로가기뿐입니다.

다음은 에러 화면이 아니므로 이 규칙의 대상이 아닙니다.

세부 규칙은 레이아웃 5절이 원본입니다.

구분	내용
선례	Carbon Design System(IBM)이 `Full-page error` 패턴을 403 · 404 · 기타 세 변형으로 제공하며 기존 `HTTPError` 컴포넌트를 대체하는 것으로 등재했습니다
논거	셸 유지가 불가능한 경우가 존재하므로 유지를 규칙화하면 판정이 필요해집니다
확인하지 못한 것	"앱셸 크롬을 유지하는가"를 명시한 공개 디자인 시스템 문서를 찾지 못했습니다. IBM 상세 문서는 사내 인증이 필요했고 Storybook은 정적 조회가 되지 않았습니다. 일반 404 UX 가이드는 마케팅 사이트 기준이라 이 질문에 답하지 않습니다

구분	내용
장점	네비게이션이 남아 다른 화면으로 한 번에 이동할 수 있습니다. 여러 화면을 오가며 작업하던 흐름이 끊기지 않습니다
단점	401과 부트스트랩 실패에서는 셸을 그릴 수 없어 예외 처리가 필요합니다. 결국 두 경로를 모두 구현하게 됩니다
기각 사유	유지 가능한 경우와 불가능한 경우를 나누면 에러마다 판정이 들어갑니다. 전체 화면으로 통일하면 판정이 사라집니다

구분	내용
장점	각 상황에서 가장 나은 경험을 제공합니다
단점	에러 종류마다 규칙이 필요하고, 새 에러 유형이 생길 때마다 규칙을 추가해야 합니다
기각 사유	규칙의 개수가 상황의 개수를 따라 늘어납니다. 예측 가능성이 1순위인 표준에서 이 구조는 유지되기 어렵습니다

에러 처리 규칙이 하나로 줄고 구현이 라우트 하나와 컴포넌트 하나로 정리됩니다. 새 에러 유형이 생겨도 같은 화면을 재사용합니다.

감수하는 사항은 다음과 같습니다.

여러 화면을 오가며 작업하던 중 403을 만나면 맥락이 끊깁니다. 사이드바에서 다른 메뉴로 바로 이동하던 흐름이 한 단계 늘어납니다. 발생 빈도가 낮으므로 판정 제거의 이득이 크다고 판단했습니다.
복구 액션의 품질에 사용자 경험이 전적으로 의존합니다. 셸이라는 안전망이 없으므로 액션이 부실하면 사용자가 막힙니다. 필수 요소를 규칙으로 못박은 이유입니다.
셸 유지가 명백히 나은 사례가 실사용에서 확인되면 재평가 대상입니다. 다만 재평가 시에도 "판정을 추가하지 않는" 형태여야 합니다.