블로그 디자인 시안 3개, 에이전트 심사위원이 골랐다

시안 b 의 첫 화면 HTML 은 316KB 였다. 글 카드마다 작은 그림이 하나씩 붙어 있었는데, 그 그림이 전부 HTML 안에 직접 박힌 인라인 SVG 였다. 세어 보니 145개. 같은 124편을 보여 주는 시안 c 는 80KB 가 안 됐다.

블로그를 브루니 월드에서 떼어 bruni.log 라는 독립 사이트로 옮기면서 첫 화면 시안을 셋 만들었다. a, b, c. 같은 글을 같은 분류로 보여 주는데 생김새는 꽤 달랐다. 셋 중 하나를 직접 고르지 않고 심사를 따로 시켰다. 만든 쪽이 자기 시안을 보면 문제가 잘 안 보인다.

심사 결과는 「c 를 표준으로 삼고, a 와 b 에서는 좋은 부분만 접붙인다」였다. 하나를 통째로 고른 게 아니다. 가져올 것과 버릴 것을 항목 단위로 갈랐다. 그 갈림이 꽤 재미있다.

같은 124편을 세 시안은 이렇게 놓았다

시안 a 의 이름은 「bruni 기록」이다. 밝은 바탕이 기본이고, 머리 막대의 해·달 버튼으로 어둡게 바꿀 수 있다. 첫 줄은 「서버가 느려진 이유를 끝까지 따라가 봐요」. 그 아래 전체 글 124, 개발 글 80, 분류 6 이 숫자로 서 있고, 목록은 그림 없이 글줄 124개가 촘촘히 이어진다.

시안 b 는 「브루니의 기록」. 표정이 다른 브루니 그림 세 장을 그려 두고, 첫 화면 위쪽에 「브루니가 고른 글」 큰 카드 하나와 작은 카드 둘을 올렸다. 그 아래로 개발 분류 넷이 가로로 흐르는 카드 줄이 되어 하나씩 깔린다. 인덱스·쿼리 성능 20편, 트랜잭션·락·DB 운영 21편, 장애·확장 23편, 배포·관측 16편. 카드가 많고, 카드마다 그림이 있다.

시안 c 는 「bruni.log」. 어두운 바탕에 민트 한 색이다. 히어로 오른쪽에 터미널 창을 하나 그려 놓고 pg_stat_statements 결과를 띄웠다. calls 가 120만 번이 넘는데 평균은 0.84ms 인 쿼리, 그리고 그 아래 「범인은 개수예요」 한 줄. 이 블로그가 어떤 글을 쓰는지 그림 한 장이 말한다. 글 화면은 왼쪽 목차, 가운데 본문, 오른쪽 같은 분류 글의 3단이다.

세 폴더에는 1280px 과 500px 폭에서 찍은 화면이 같이 들어 있었다. 넓은 화면과 휴대폰 화면이 나란히 있는 셈이다.

표준은 c, 그런데 열두 줄짜리 접붙이기 표가 붙었다

블로그를 옮길 때 여럿이 동시에 코드를 쓰도록 고정값을 한 문서에 박아 두었다. 그 문서에서 화면 쪽 결정은 한 줄로 시작한다. 표준은 시안 c 다. c 의 스타일시트를 출발점으로 복사하고, 토큰과 컴포넌트 이름도 그대로 쓴다. 새 컴포넌트를 만들 때도 c 의 간격·글자 크기·색 토큰만 쓰고, 색 hex 값을 직접 적지 않는다.

그 바로 아래 「접붙일 것(심사위원 제안 중 채택)」 표가 있다. G1 부터 G12 까지 열두 줄이고, 줄마다 출처가 붙어 있다.

이름표가 있으니 나중에 「이건 왜 이렇게 했지?」 싶을 때 거꾸로 찾아갈 수 있다. 결정이 어디서 왔는지 모르는 코드는 다음 사람이 함부로 지운다.

a 에서 가져온 건 밝은 화면과 엄지손가락

c 는 어둡기만 했다. a 의 밝은 테마와 토글 버튼이 그대로 들어왔다. 다만 c 의 「민트 위 검정」을 밝은 테마에 그대로 옮기지는 않는다. 밝은 바탕에서 민트는 #0b7a55 로 진하게 바꾸고, 본문과 보조 글자 모두 대비 4.5:1 이상을 기준으로 잡았다. 코드 블록은 두 테마 모두 어두운 바탕에 둔다. 그래야 밝은 테마에서 코드 색을 따로 맞출 일이 없다.

휴대폰 쪽은 a 가 더 친절했다. 「← 이전 · 1 / 11 · 다음 →」 짧은 막대 하나로 쪽을 넘긴다. 640px 미만에서는 숫자 버튼을 숨기고 이 막대만 남긴다. 링크·버튼·칩은 전부 누르는 높이가 최소 44px 이다. 엄지로 눌러도 되는 크기다.

글 끝 꼬리도 손봤다. c 는 넓은 화면에서 오른쪽 칸이 다음 읽을 글을 안내했는데, 화면이 좁아져 그 칸이 사라지면 갈 곳도 같이 사라졌다. a 와 b 처럼 글 아래에 「이어서 읽기」 카드 셋과 큰 이전/다음 버튼을 두고, 모바일에서도 보이게 했다.

b 에서는 그림 한 장만, 방식은 바꿔서

b 의 카드 그림은 좋았다. 그래서 가져왔다. 단 한 곳, 「최근 개발 글」 큰 카드의 빈 자리에만. 전체 목록 줄에는 그림을 넣지 않는다.

더 중요한 건 넣는 방식이다. b 는 카드마다 다른 SVG 를 HTML 에 통째로 넣었다. 그게 145개, 316KB 다. 고정값 문서는 이 방식을 이름까지 짚어 금지했다. 대신 분류가 6개뿐이니 그림도 6개만 그린다. 페이지에 한 번 <symbol> 로 넣고, 쓰는 자리에서는 <use> 로 불러온다.

<!-- 페이지 맨 위에 한 번 -->
<svg hidden>
  <symbol id="pic-db-query" viewBox="…">…</symbol>
  <symbol id="pic-db-ops" viewBox="…">…</symbol>
  …
</svg>

<!-- 카드에서는 이 한 줄 -->
<svg><use href="#pic-db-query"/></svg>

여섯 개를 합쳐 6KB 이하. 같은 문서의 무게 예산은 첫 화면 HTML 60KB 이하인데, b 의 첫 화면은 그 다섯 배가 넘었다. 그림 하나하나는 예뻤지만 그 무게를 매번 첫 화면이 짊어질 이유는 없었다.

b 에서 버린 것도 하나 더 있다. 분류별 카드 줄이다. 줄 넷이 겹겹이 쌓이면 첫 화면이 길어지고, 정작 「모든 글」 목록은 한참 내려가야 나온다. 검색해서 들어온 사람에게 필요한 건 목록이다.

세 시안이 다 놓친 것: 숫자에 이름이 없었다

심사가 공통으로 짚은 것 중 제일 작은데 제일 날카로운 게 숫자였다. b 는 소개 문장에 「80편 모았어요」라고 써 놓고 바로 옆 숫자 칸에는 124편을 띄웠다. c 도 80과 124가 한 화면에서 부딪쳤다. 둘 다 맞는 숫자다. 80은 개발 글이고 124는 교양까지 합친 전체 글이다. 이름이 없으니 틀린 것처럼 보였을 뿐이다.

그래서 히어로는 「개발 글 80편 · 전체 글 124편 · 마지막 글 10.19」처럼 무엇을 센 숫자인지 이름을 붙인다. 숫자는 빌드가 데이터에서 센다. 템플릿에 숫자를 박아 두면 글이 하나 늘 때마다 또 어긋난다.

페이지 주소도 심사 공통 항목이었다. /page/2/, /c/db-ops/page/2/ 같은 진짜 주소를 만들고, 그 정적 HTML 안에 글 12편이 실제로 들어 있게 했다. 자바스크립트가 없어도 목록이 끝까지 읽힌다. 검색엔진도 사람도 같은 목록을 본다.

통째로 고르지 않아서 남은 것

하나를 골랐다면 일은 더 빨랐을 것이다. c 를 고르고 끝. 그러면 밝은 테마도, 엄지 크기 버튼도, 모바일의 다음 글 안내도 없었다. b 를 골랐다면 316KB 짜리 첫 화면이 그대로 나갔을 것이다.

심사를 따로 시킨 덕에 결론이 「무엇을 고른다」가 아니라 「무엇을 어디서 가져오고 무엇을 왜 버린다」로 나왔다. 버린 목록이 문서에 남아 있다는 게 생각보다 쓸모 있다. 다음에 누가 카드마다 그림을 넣자고 하면, 그 결정은 이미 숫자와 함께 한 번 내려져 있다.

핵심 한 줄시안은 통째로 고르지 않는다. 항목으로 갈라 출처를 붙이고, 버린 것도 이유와 함께 적어 둔다.