“주간 보고서 스크롤 할 게 너무 많아.” 맞는 말이었습니다. 그래서 탭을 만들었더니, 예전의 제가 막았습니다.
개발노트 · 설계 · 품질 검사
한 주 영업이 끝나면 결과 보고서가 나옵니다. 여기에는 등급, 다음 주에 바꿀 것, 핵심 기록, 손익 계산서, 메뉴별 결과, 주간 추이, 자원 사용량, 운영 전후 비교, 미션 결과, 일별 손익까지 열두 덩이가 들어 있습니다.
하나씩 보면 다 필요한 것들입니다. 「매출이 얼마인지」만 알려 주고 끝내면 다음 주에 무엇을 고쳐야 할지 알 수 없으니까요. 그런데 다 넣다 보니 끝까지 내려가야 다 읽히는 화면이 됐습니다.
«요약 · 손익 · 메뉴 · 운영» 네 칸으로 나누고, 한 번에 한 칸만 보여 주게 했습니다. 흔한 탭 구현입니다. 만들고 빌드했더니 이렇게 나왔습니다.
FAIL 모바일 주간 분석 보고서
FAIL 자원 사용·운영 전후 비교 상시 표시
— 실제 자원 사용과 운영 전후 비교는 접기·펼치기 없이 바로 보여야 합니다
FAIL 튜토리얼 실제 레이아웃·히트 테스트
— 주간 리포트 360px 가독성 구조 실패
{"tableVisible":false, "trendVisible":false, ...}
통과 40개 / 실패 3개
이 프로젝트는 빌드할 때마다 43가지 검사를 돌립니다. 그중 하나가 «보고서 내용은 조작 없이 바로 보여야 한다»였습니다. 언젠가 제가 직접 걸어 둔 것입니다.
가장 쉬운 해결은 검사를 지우는 것입니다. 실제로 잠깐 그 생각을 했습니다. 사용자가 «탭으로 해 달라»고 했으니 예전 규칙이 낡은 것 아닌가, 하고요.
그런데 이 프로젝트 규칙에는 이런 문장이 있습니다.
이 검사를 통과시키려고 검사 자체를 고치지 마세요. 그건 화재경보기를 떼는 것과 같습니다.
그래서 검사가 왜 있는지 먼저 생각했습니다. 접기·펼치기로 감춰 두면, 플레이어는 접힌 걸 안 펴 봅니다. 그러면 «이번 주에 오븐이 부족했다»는 사실을 모른 채 다음 주 계획을 세우게 됩니다. 이 검사는 보고서를 읽지 않게 만드는 개편을 막으려고 있었습니다. 여전히 유효한 규칙이었습니다.
원래 요청은 «탭»이 아니라 «스크롤 할 게 너무 많다»였습니다. 탭은 그 사람이 제안한 해결책이지 문제 자체가 아니었습니다.
스크롤이 길어서 불편한 건 원하는 곳까지 가는 데 오래 걸려서입니다. 그건 내용을 감추지 않고도 풀 수 있습니다. 탭을 감추개가 아니라 이동표로 만들면 됩니다.
고정된 상단 바에 가려지지 않도록 scroll-margin-top을 118px 잡아 뒀습니다. 네 칸 모두 눌렀을 때 정확히 같은 위치에서 멈춥니다.
| 탭 | 눌렀을 때 스크롤 | 구역이 멈추는 위치 |
|---|---|---|
| 요약 | 316px | 화면 상단 118px |
| 손익 | 870px | 118px |
| 메뉴 | 1,125px | 118px |
| 운영 | 1,489px | 118px |
이렇게 하고도 두 검사는 계속 실패했습니다. 읽어 보니 가시성이 아니라 소스 코드 문자열을 그대로 비교하는 검사였습니다.
mobileReport.includes("desktopWeeklyAnalysisReport(state,report)")
mobileReport.includes('html+=renderWeeklyResultComparison(report,"report")')
개편하면서 변수 이름을 html에서 detail로 바꿨더니 철자가 어긋난 것이었습니다. 지키려던 내용(자원 사용과 전후 비교가 접기 없이 보이는 것)은 그대로였습니다.
그래서 철자만 맞췄습니다. 다만 검사를 건드렸다는 사실은 기록으로 남겨 두는 편이 낫습니다. 나중에 «왜 이 검사가 이렇게 생겼지»를 되짚을 때 필요하니까요.
탭을 누르면 부드럽게 스크롤되게 하려고 «움직임 최소화» 설정을 확인하는 함수를 썼습니다.
function prefersReducedMotion(){ return false; }
항상 false를 돌려주는 껍데기였습니다. 진짜 함수는 prefersReducedMotionForUi()라는 다른 이름으로 따로 있었습니다. 이 껍데기를 쓰는 곳에서는 사용자의 «움직임 최소화» 설정이 계속 무시되고 있었을 겁니다. 이번에 바꿨습니다.
자동 검사의 진짜 값어치는 «버그를 잡는 것»보다 «과거의 판단을 지금의 나에게 다시 들려주는 것»에 있는 것 같습니다. 그 규칙을 왜 만들었는지 잊었더라도, 검사가 멈춰 세워 주면 최소한 한 번은 다시 생각하게 됩니다.
그리고 요청받은 해결책과 실제 문제를 나눠서 보는 게 도움이 됐습니다. 이번엔 탭이 아니라 «빨리 가고 싶다»가 문제였습니다.