프로그레시브 인핸스먼트

가장 좋은 환경을 기준으로 만들고 나머지는 지원하지 않는다고 적어 두던 시절이 있었습니다. 최신 브라우저에서 제대로 보이면 만든 쪽의 일은 끝난 것으로 봤습니다.

문제는 사용자의 환경을 만드는 쪽이 고르지 못한다는 데 있습니다. 회사에서 지급한 노트북에 몇 년 전 브라우저가 깔려 있고, 지하철에서 연결이 느려 스크립트가 절반만 내려오고, 보안 정책 때문에 외부 스크립트가 차단된 사무실도 있습니다. 이 사용자들은 기능이 조금 불편한 것이 아니라 아무것도 하지 못합니다. 계약 직전에 고객사 보안 설정 때문에 저장 버튼이 아예 먹지 않는 것을 발견하는 상황이 여기서 나옵니다.

프로그레시브 인핸스먼트는 그래서 순서를 뒤집은 방식입니다. 가장 단순한 수단으로 핵심 동작을 먼저 완성해 두고, 그다음에 환경이 받아 주는 만큼 편의를 얹습니다. 얹은 층이 떨어져 나가도 아래층이 남아 있어 사용자는 하려던 일을 끝낼 수 있습니다.

핵심 동작을 가장 단순한 수단으로 먼저 만들고, 환경을 확인한 뒤에 그 위에 기능을 더합니다. 순서는 다섯 단계입니다.

1. 이 화면에서 반드시 되어야 하는 일 하나를 정합니다. 문서 편집 화면이라면 글을 쓰고 저장하는 것이고, 결제 화면이라면 카드 정보를 넘기는 것입니다. 편집 도구 모음이나 자동 정렬은 여기 들어가지 않습니다.
2. 그 일을 스크립트 없이 되는 수단으로 만듭니다. 웹에서는 링크 이동과 폼 전송이 그 수단입니다. 저장 버튼을 누르면 서버가 받아 처리하고 새 화면을 돌려주는 형태입니다. 느리고 투박하지만 어떤 환경에서도 됩니다.
3. 환경에 그 기능이 있는지 물어봅니다. 브라우저 이름과 버전으로 나누지 않고, 쓰려는 기능 하나하나가 이 환경에 있는지를 확인합니다. 이름으로 나누면 새 브라우저가 나올 때마다 목록을 고쳐야 하고, 목록에 없는 환경은 전부 배제됩니다.
4. 있으면 얹습니다. 입력할 때마다 자동으로 저장되는 동작, 파일을 끌어다 놓는 동작, 화면을 다시 그리지 않고 결과만 바꾸는 동작이 이 층에 들어갑니다. 얹는 순서는 없어도 일이 끝나는 것부터입니다.
5. 얹은 층 없이 한 번 써 봅니다. 스크립트를 끈 상태에서 저장이 되는지, 느린 연결에서 화면이 멈추지 않는지를 직접 확인합니다. 이 확인을 하지 않으면 2번 단계가 실제로는 비어 있는 채로 남습니다.

환경을 통제할 수 없는 제품에서 씁니다. 웹으로 파는 제품이 대표적이고, 그 안에서도 로그인과 결제와 제출처럼 실패하면 다른 방법이 없는 경로에 먼저 적용합니다.

기업 고객을 상대할 때 값이 커집니다. 회사마다 보안 정책이 다르고, 어떤 스크립트가 차단될지는 계약 전에 알 수 없습니다. 기본 층이 서 있으면 그 환경에서도 일이 되기 때문에 도입 검토에서 막히지 않습니다.

장애나 상황에 관계없이 쓸 수 있게 만드는 접근성과도 같은 방향을 봅니다. 화면 내용을 소리로 읽어 주는 스크린 리더를 쓰는 사용자나 마우스 없이 키보드만 쓰는 사용자는 대개 기본 층을 지나갑니다. 기본 층이 완결돼 있으면 이들에게 따로 만들 것이 줄어듭니다. 화면 크기에 따라 배치가 바뀌는 반응형 디자인에서 작은 화면을 먼저 설계하는 관행도 같은 생각의 다른 적용입니다.

맞지 않는 자리도 있습니다. 3차원 편집기나 영상 편집처럼 얹은 층 자체가 제품인 경우에는 기본 층으로 성립하는 형태가 없습니다. 이때는 무엇이 필요한지 미리 알리고 그 환경이 아니면 안내를 띄우는 편이 낫습니다. 환경을 회사가 정해 주는 사내 도구도 이 방식의 값이 작습니다. 브라우저와 버전이 한 가지로 정해져 있으면 확인할 갈래가 없습니다.

"스크립트가 막힌 환경에서도 저장은 되게 해 주세요."

기본 층 없이 얹은 층만 만들지 말라는 요청입니다.

"브라우저 이름으로 나누지 말고 이 기능이 있는지 물어봅시다."

환경 판정 방식을 목록에서 기능 확인으로 바꾸자는 제안입니다.

"이 기능은 기본 층으로 만들 수 없어요. 미지원 안내를 제대로 띄우죠."

이 방식을 적용할 수 없는 경우라고 판단한 말입니다.

페이지덱이 기업 고객과 처음 계약할 때 이 문제를 만났습니다. 고객사 보안 정책이 외부에서 불러오는 스크립트를 막고 있어서, 자동 저장이 돌지 않고 편집한 내용이 사라졌습니다. 태오가 확인해 보니 저장 경로가 자동 저장 하나뿐이었습니다.

고친 방식은 기능을 늘리는 쪽이 아니었습니다. 저장 버튼을 되살려 스크립트 없이도 서버가 받아 처리하게 만들고, 자동 저장은 그 위에 얹는 층으로 옮겼습니다. 민서는 자동 저장이 도는 환경에서는 버튼이 회색으로 남아 있게 두는 쪽을 택했습니다. 두 환경에서 화면이 달라지면 사용자가 헤매기 때문입니다.

낡은 환경을 지원하는 일이라고 읽는 경우가 가장 많습니다. 오래된 브라우저 이야기가 자주 나오니 그렇게 보입니다. 하지만 이 방식이 다루는 것은 환경의 낡음이 아니라 만드는 순서입니다. 새 기능을 못 쓰게 되는 것도 아닙니다. 다 쓰되 그것이 없을 때 일이 멈추지 않도록 아래층을 먼저 깔아 두는 것입니다. 낡은 환경 이야기로만 이해하면 최신 브라우저만 쓰는 시장에서는 필요 없다는 결론이 나오는데, 스크립트 차단과 느린 연결은 최신 브라우저에서도 일어납니다.

두 벌을 만들어야 하니 비용이 두 배라고 보는 것도 흔합니다. 기본 층과 얹은 층이 따로 있으니 자연스러운 계산입니다. 그런데 순서를 지키면 총량이 크게 늘지 않습니다. 기본 층은 단순한 수단으로 만드는 것이라 작고, 얹은 층은 그 위에서 덧붙이는 것이라 처음부터 두 벌을 설계하는 일이 아닙니다. 비용이 실제로 두 배가 되는 것은 반대 순서일 때입니다. 얹은 층만 만들어 내보낸 뒤에 안 되는 환경이 보고되면, 그때는 이미 굴러가는 화면을 뜯어 아래층을 끼워 넣어야 합니다.