행은 데이터보다 먼저 — 다듬는 날의 기록

기능을 만드는 날이 있고, 다듬는 날이 있습니다. 이번 주는 Table 뷰 필터를 갈아엎는 큰 작업 뒤에 다듬는 날이 따라왔습니다. 다듬기는 목록으로 계획되지 않습니다. 화면을 실제로 쓰다가 “어라?” 하는 순간이 소재가 되고, 그 자리에서 고치고, 다음 “어라?“로 넘어갑니다. 하루가 끝나고 보니 고친 것들 사이에 문법이 있었습니다.

덜컥임의 해부

첫 번째 “어라?“는 할 일 생성 모달이었습니다. 열릴 때마다 화면이 한 번 덜컥합니다. 원인을 따라가 보니 담당자 행이 범인이었습니다. 프로젝트 멤버 목록을 서버에서 받아온 뒤에야 행이 나타나도록 조건이 걸려 있어서, 모달이 뜨고 반 박자 늦게 행이 끼어들며 아래 내용을 밀어냈던 겁니다.

재미있는 건 바로 위의 두 행 — 프로젝트, 중간 목표 — 은 이미 올바르게 되어 있었다는 점입니다. 항상 렌더하고, 데이터가 없으면 비활성으로 보여줍니다. 담당자 행만 그 문법에서 빠져 있었습니다. 같은 문법으로 맞추고, 멤버가 로드되기 전엔 “나”를 미리 채워 넣으니 모달이 첫 프레임부터 완성된 모습으로 뜹니다.

같은 날 서제션 목록에서도, 템플릿 목록에서도 비슷한 걸 발견했습니다. 프로젝트가 없는 항목은 둘째 줄이 비면서 제목이 위에 붙어 어색하고, 프로젝트가 있는 항목과 높이가 달랐습니다. 처방도 같았습니다. 텍스트 영역의 높이를 고정하고, 내용이 한 줄이면 세로 중앙에 둡니다. 행 높이는 내용이 결정하는 게 아니라 설계가 결정합니다.

세 사례의 공통 원리를 한 줄로 적으면 이렇습니다. 행은 데이터보다 먼저 있어야 합니다. 데이터는 늦게 올 수 있고, 없을 수도 있습니다. 그래도 화면의 뼈대는 첫 프레임에 완성되어 있어야 하고, 데이터는 도착하는 대로 그 안을 채울 뿐입니다. fecit에는 “화면 진입 시 전신 스피너 금지 — 프레임 먼저, 내용 채움”이라는 원칙이 이미 있는데, 이번에 배운 건 같은 원칙이 화면 단위만이 아니라 행 하나 단위에도 적용된다는 것이었습니다.

설명되지 않는 다름은 버그다

두 번째 묶음은 색과 크기였습니다.

모바일 읽기 전용 화면에서 “단계” 섹션 헤더가 다른 섹션보다 연해 보인다는 제보(사실은 제 눈)가 있었습니다. 글자색을 의심했는데 아니었습니다 — 글자는 전부 같은 색이었고, 그 화면에서만 헤더 바의 배경이 한 단계 밝았습니다. 다섯 화면 중 네 화면은 같고 하나만 달랐으니, 답은 화면 쪽이 아니라 그 하나에 있었습니다.

About 모달들은 반대 방향이었습니다. 본문 길이에 따라 모달 높이가 제각각이어서, 여는 대상마다 크기가 다른 창이 떴습니다. 높이를 고정하고 짧은 본문은 여백으로, 긴 본문은 스크롤로 흡수하게 했습니다. 할 일과 메모의 템플릿 꺼내기 모달도 헤더 구조부터 아이템 모양까지 서로 달라서, 한쪽 문법으로 통일했습니다.

다름 자체가 나쁜 건 아닙니다. 의도가 있는 다름은 설계입니다. 문제는 설명되지 않는 다름입니다. “이 화면은 왜 얘만 밝지?“에 답이 없으면 그건 개성이 있는 게 아니고 버그가 있는 겁니다.

줄이다가 잡은 버그

템플릿 꺼내기 목록이 너무 길어 한 페이지를 20개에서 10개로 줄였습니다. 그러자 스크롤이 안 된다는 제보가 왔습니다.

따라가 보니 다음 페이지 로드가 스크롤 이벤트에 걸려 있었습니다. 아이템이 콤팩트해지고 10개로 줄자 목록이 컨테이너를 채우지 못했고, 넘치지 않는 목록에선 스크롤 이벤트가 발생하지 않으니 두 번째 페이지를 영영 못 부르는 겁니다. 20개일 때는 우연히 항상 넘쳤기 때문에 몇 달 동안 아무도 몰랐던 결합이었습니다.

처방은 자동 보충입니다. 페이지가 렌더될 때마다 “아직 안 넘쳤고 더 있으면 다음 페이지”를 확인해서, 내용이 넘칠 때까지 채우고 그 뒤부터 스크롤 트리거에 넘깁니다. 다듬기가 기능을 깨뜨린 게 아니라, 줄이는 행위가 원래 있던 숨은 가정을 드러낸 사례였습니다. “이 목록은 항상 화면보다 길다”는 가정은 어디에도 적혀 있지 않았지만 코드가 그 위에 서 있었습니다.

다듬는 날의 리듬

이날 고친 것 중 설계 문서가 필요한 건 하나도 없었습니다. 전부 화면을 쓰다가 눈에 걸린 것들이고, 대부분 한두 시간짜리였습니다. 하지만 이런 날이 없으면 “어라?“들은 쌓여서 제품의 인상이 됩니다. 사용자는 담당자 행의 렌더 조건을 모르지만, 모달이 덜컥이는 건 압니다.

다듬는 날의 소재는 백로그에서 오지 않고 실제 사용에서 옵니다. 그래서 만든 사람이 자기 제품을 매일 쓰는 것 이상의 QA 를 아직 찾지 못했습니다. fecit 을 fecit 으로 만들고 있다는 말은 저희에게 슬로건이기 전에 버그 트래커입니다.