모달 폭이 네 가지였다 — 하루 동안의 일관성 청소

시작은 사소했습니다. 뽀모도로 화면의 프로젝트 칩이 너무 작아 보여서 키웠습니다. 그러다 옆에 있는 Steps 섹션 헤더만 다른 섹션들과 색이 다른 게 눈에 들어왔습니다. 하나를 고치니 다음 게 보였습니다. 그렇게 하루가 갔습니다.

세어 보니

“또 어긋난 게 있나?” 싶어서 전수 조사를 했습니다. grep으로 데스크톱의 모달 선언을 전부 세어 봤습니다.

• 모달 폭: 560, 640, 720, 960 — 네 가지
• 상세·생성 화면의 제목 행 구성: 화면마다 제각각 — 어떤 곳은 라벨+제목, 어떤 곳은 제목 따로 카테고리 별 따로
• 날짜 표기: 2026. 7. 22.(공백형), 2026.07.22(패딩형), 2026-07-22(하이픈형) — 세 계열

일부러 이렇게 만든 사람은 없습니다. 할 일 생성 모달을 만들 때는 960이 맞았고, 몇 주 뒤 메모 생성 모달을 만들 때는 720이 적당해 보였을 뿐입니다. 각 결정은 그 순간에는 합리적이었습니다. 문제는 그 결정들이 서로를 모른다는 것.

수렴

고치는 원칙은 하나였습니다. 같은 역할이면 같은 규격. 스케일을 새로 설계하는 게 아니라, 이미 있는 것 중 지배적인 규격으로 나머지를 수렴시키는 방식입니다.

• 문서 계열 모달(상세·생성·미리보기)은 전부 960px
• 상세·생성의 제목 행은 [별][제목] 한 줄 — 별도 카테고리 행과 라벨 제거
• 날짜는 YYYY.MM.DD 패딩형으로, 모바일까지 같이
• Steps 헤더도 다른 섹션 바와 같은 색·같은 파란 점

함정 하나

별 버튼을 제목 입력창 높이에 맞추려고 CSS의 align-self: stretch + aspect-ratio 조합을 썼다가 한 번 데였습니다. 브라우저가 요소의 기본 폭을 계산하는 시점에는 늘어난 높이를 모르기 때문에, 버튼 폭이 아이콘 폭으로 잡히고 실제 렌더는 그보다 넓게 넘쳐서 옆 입력창을 덮었습니다. 퍼센트 높이에서 파생되는 비율 계산은 이런 타이밍 문제가 있습니다. 결국 고정 52px로 확정했습니다. 영리한 CSS보다 고정 숫자가 나을 때가 있습니다.

배운 것

일관성은 사건으로 깨지는 게 아니라 조금씩 샙니다. 어느 날 갑자기 모달 폭이 네 가지가 된 게 아니라, 화면을 하나 추가할 때마다 1mm씩 어긋난 결과입니다. 그래서 “언제 깨졌지?“라는 질문은 성립하지 않고, 주기적으로 세어 보는 수밖에 없습니다.

그리고 고치는 것만으로는 다시 샙니다. 오늘 고친 규격은 전부 프로젝트의 스타일 문서에 박았습니다. “문서 모달은 960”, “제목 행은 [별][제목]”, “날짜는 패딩형”. 다음에 화면을 추가할 때 이 문서가 기준이 됩니다. 청소보다 중요한 건 청소가 유지되는 구조입니다.

fecit은 이런 식으로, 조금씩, 계속 다듬어지고 있습니다.