그레이스풀 디그러데이션

제품을 쓰는 환경은 한 가지가 아닙니다. 3년 된 보급형 휴대폰, 회사 정책 때문에 업데이트가 막힌 브라우저, 지하철에서 끊기는 회선이 같은 화면을 엽니다. 만드는 쪽은 최신 기기와 빠른 회선 앞에서 작업하니 이 차이가 잘 보이지 않습니다.

예전에는 두 가지 방식으로 처리했습니다. 하나는 "지원하지 않는 브라우저입니다" 라는 안내를 띄우고 돌려보내는 것이었고, 다른 하나는 아무 대비 없이 두었다가 화면이 통째로 깨지게 두는 것이었습니다. 둘 다 같은 문제를 안고 있습니다. 부가 기능 하나가 안 된다는 이유로 제품 전체를 못 쓰게 만든다는 점입니다.

페이지덱에서도 같은 일이 있었습니다. 여러 사람의 커서가 문서 위에 실시간으로 보이는 기능을 태오가 붙인 다음 날, 한 고객사에서 문서가 아예 열리지 않는다는 연락이 왔습니다. 그 회사 직원들이 쓰는 브라우저가 커서를 그리는 데 필요한 기능을 지원하지 않았고, 그 부분에서 멈추면서 문서 내용까지 같이 멈춘 것입니다. 읽고 고치는 일은 그 브라우저에서도 충분히 되는데, 있으면 좋은 기능 하나가 없는 기능 전부를 끌고 내려갔습니다.

이 방식은 그 지점을 다르게 다룹니다. 무엇이 안 될 수 있는지를 미리 인정하고, 안 될 때 무엇이 남아야 하는지를 만들 때 함께 정해 둡니다.

가장 좋은 환경을 기준으로 완성한 다음, 기능을 하나씩 떼어 냈을 때 무엇이 남아야 하는지를 정하고 그 남을 자리를 코드로 채웁니다. 순서는 셋입니다.

1. 없으면 제품이 성립하지 않는 것을 고릅니다. 협업 문서 툴이라면 문서를 열고, 글자를 넣고, 저장하는 세 가지입니다. 실시간 커서나 이모지 반응은 여기 들어가지 않습니다.
2. 환경을 확인할 지점을 정합니다. 브라우저 이름과 버전을 보고 판단하지 않고, 필요한 기능이 지금 이 환경에 있는지를 직접 물어봅니다. 이름으로 판단하면 목록에 없는 새 브라우저가 나올 때마다 멀쩡한 사용자를 막게 됩니다.
3. 없을 때 대신 내보낼 것을 정합니다. 이 자리를 비워 두면 화면이 멈춥니다.

대신 내보내는 방식은 보통 셋 중 하나입니다. 조용히 감추는 것이 첫째입니다. 커서가 안 그려지는 환경에서는 커서만 빼고 나머지는 그대로 둡니다. 낮은 버전으로 내려가는 것이 둘째입니다. 그림 편집기가 안 뜨면 그림을 이미지로만 보여 주고 편집 버튼을 숨깁니다. 셋째는 왜 안 되는지 알려 주는 것인데, 사용자가 다른 방법을 찾을 수 있을 때만 씁니다. 브라우저를 바꾸면 된다는 안내는 쓸모가 있지만, 그저 실패했다는 안내는 접은 것이 아니라 막은 것입니다.

엘리베이터가 멈춰도 건물을 못 쓰게 되지는 않습니다. 계단이 남아 있기 때문입니다. 계단 없이 엘리베이터만 놓은 건물은 평소에는 더 편하지만 멈추는 날 전부를 잃습니다.

화면 쪽에서는 구형 브라우저 대응이 대표적입니다. 폴리필로 없는 기능을 채워 넣는 방법도 있지만 모든 기능을 채울 수 있는 것은 아니고, 채워 넣은 코드가 무거워 느린 기기에서 오히려 손해가 되기도 합니다. 채우지 않고 접는 쪽을 고르는 판단이 여기서 나옵니다.

서버 쪽에서도 같은 원리가 쓰입니다. 기능별로 서비스를 쪼개 두는 마이크로서비스 구조에서는 일부가 멈추는 일이 늘 생깁니다. 문서 목록 화면이 추천 항목을 받아 오는 API 응답을 기다리다 함께 멈추게 두지 않고, 응답이 없으면 추천 영역만 비운 채 목록을 먼저 띄웁니다. 사고가 나도 서비스 전체가 아니라 한 칸만 꺼지게 만드는 방법입니다.

접근성 작업과도 만납니다. 글자 크기를 두 배로 키워 둔 사용자나 화면을 소리로 듣는 사용자에게는 애니메이션과 정교한 배치가 전달되지 않습니다. 그 층이 벗겨진 뒤에도 내용과 조작이 남아 있어야 한다는 요구가 이 방식이 다루는 문제와 같습니다.

기능을 껐다 켰다 하는 피처 플래그와는 결정 주체가 다릅니다. 플래그는 사람이 판단해 끄고, 이쪽은 환경을 보고 그때그때 알아서 접힙니다. 사고가 났을 때 사람이 알아채기 전에 이미 접혀 있어야 하는 자리가 이쪽입니다.

"이 기능 구형 브라우저에서 안 되는데, 안 되면 어떻게 보여야 할지 정해 주세요."

무엇을 대신 내보낼지가 정해지지 않으면 구현을 시작할 수 없다는 요청입니다.

"추천 영역은 응답 없으면 그냥 비우고 목록부터 띄웁시다."

부가 요소 하나 때문에 본 내용이 늦어지게 두지 말자는 결정입니다.

"지원 안 한다고 막지 말고, 되는 것만 남겨서 보여 주는 쪽으로 가죠."

접근 자체를 차단하는 대신 축소된 형태로라도 쓰게 하자는 제안입니다.

페이지덱에서는 이 논의가 시안 리뷰에 붙습니다. 민서가 새 화면을 올리면 태오가 "여기 이 부분 안 되는 환경에서는 뭐가 보여야 하나요" 하고 묻고, 민서가 그 상태의 화면을 한 장 더 그립니다. 한 장을 더 그리는 일이 번거로워 보이지만, 안 그리면 그 판단이 구현 단계에서 개발자에게 넘어가고 결과는 대개 오류 상태 화면이 됩니다. 고객이 보는 것은 접힌 모습이 아니라 고장 난 모습이 됩니다.

기능을 빼 두는 일을 대충 만드는 것으로 읽는 경우가 있습니다. 완성도를 낮추는 타협처럼 들리기 때문입니다. 실제로는 반대에 가깝습니다. 무엇이 없어도 되는지를 알려면 제품에서 무엇이 핵심인지를 먼저 정해야 하고, 접힌 상태의 화면을 따로 만드는 만큼 손이 더 갑니다. 이 판단을 미뤄 두면 나중에 급하게 대응하게 되고, 그때는 핵심을 고르는 대신 눈에 띄는 것부터 끄게 됩니다.

오류 메시지를 띄우면 이 방식을 지킨 것이라고 보는 것도 흔합니다. 화면이 깨지지 않고 안내가 나오니 정상 처리처럼 보입니다. 그런데 사용자가 하려던 일이 여전히 막혀 있으면 안내창은 잠긴 문 앞의 안내문일 뿐입니다. 기준은 메시지가 떴는지가 아니라 핵심 동작이 살아 있는지입니다. 이 기준을 놓치면 안내창만 늘어난 제품이 되고, 사용자는 접힌 기능이 아니라 막힌 제품을 경험합니다.