1편에서 하고 싶은 것을 열일곱 개 적었다고 썼다. 그다음에 한 일은 코드를 쓰는 게 아니라 화면을 그리는 것이었다.
1. 화면을 먼저 그렸다
1.1 글로 적은 요구사항은 생각보다 흐릿하다
"발행 전에 직접 손보는 편집기"라고 적어놨지만, 그게 어떤 모양인지는 적혀 있지 않다. 버튼이 몇 개인지, 미리보기가 옆에 있는지 아래에 있는지, 저장은 언제 되는지 — 전부 만들면서 정해야 한다. 그리고 만들면서 정한 것은 대체로 내가 원한 것과 다르다.
그래서 화면을 먼저 그렸다. 다른 디자인 도구를 켜는 대신 클로드 Design을 이용하여 화면을 HTML로 만들게 하고, 보면서 고쳐나갔다. 말로 고쳐달라고 하면 바로 반영된 화면이 나오니, 머릿속에만 있던 배치를 몇 번이고 바꿔볼 수 있었다.
실제로 열리는 페이지라는 점이 중요했다. 브라우저에서 눌러볼 수 있고, 나중에 그 CSS를 구현에 그대로 가져다 쓸 수 있다.
1.2 시안과 요구사항을 번갈아 고쳤다
flowchart LR
A[요구사항 확인 및 수정] --> B[디자인 시안 제작]
B --> C[시뮬레이션 및 검증]
C --> D[설계 문서 반영]
D --> A
요구사항 단계에서는 말로만 정의했던 조건이 디자인 시안으로 옮겨지면서 빠진 부분이나 모순되는 부분이 눈에 보이기 시작한다. 시뮬레이션 및 검증 단계에서는 그 시안이 실제 데이터나 사용 흐름 앞에서 버티는지를 확인하고, 여기서 걸린 문제를 설계 문서에 반영한 뒤 다시 요구사항 재정립 단계로 가져가 문장을 고친다. 결국 이 루프는 한 번에 끝나지 않고 몇 차례 돌아야 말이 맞는 요구사항이 된다.
2. 시안이 구현을 바꾼 지점
2.1 편집기는 아예 처음부터 만들었다
Payload에는 글 편집기가 이미 들어 있다. 그런데 시안에 그려둔 편집기와 모양이 너무 달랐다.
그래서 기본 편집기를 버리고 새로 만들었다. 커서가 있는 문단만 원본이 보이고 나머지는 결과물로 보이는 방식이다.
이 결정이 예상 못 한 곳까지 번졌다. 기본 편집기를 안 쓰기로 하니 저장 형식도 바뀌었다. 원래는 그 편집기가 쓰는 구조화된 형식으로 저장할 참이었는데, 직접 만들면서 마크다운 텍스트로 확정됐다.
디자인 결정 하나가 데이터베이스에 무엇을 넣을지까지 바꾼 셈이다. 이런 건 요구사항 목록에 적혀 있지 않다.
위가 그려둔 편집기 시안이다. 툴바 모양, 본문과 발행 패널의 좌우 배치, 상태를 고르는 방식까지 여기서 먼저 정했다.
2.2 시안에 있는데 데이터에 없는 것
대시보드 시안에는 "이번 주 방문자"와 추천 주제 옆 카테고리 이름이 있었다. 그리는 동안에는 당연히 있을 값이라고 생각했다.
만들 때 보니 둘 다 없었다. 방문자 수를 담을 자리가 스키마에 없었고, 추천 주제에는 카테고리가 붙어 있지 않았다.
여기서 그럴듯한 숫자를 채워 넣을 수도 있었다. 그러지 않고 실제로 있는 값으로 바꿨다. 방문자 대신 검색 유입 클릭 수, 카테고리 대신 추천받은 날짜. 시안과 달라지지만, 화면에 거짓 숫자가 떠 있는 것보다는 낫다.
(추천 주제의 카테고리는 나중에 스키마에 추가해서 지금은 시안대로 나온다.)
3. 시안이 요구사항이 되었다
이 과정을 몇 번 반복하고 나서 방침을 하나 정했다.
시안이 요구사항의 총집합이다. 구현이 시안과 다르면 구현이 틀린 것이다.
그리고 시안 HTML에서 규칙을 뽑아 문서로 정리했다. 색과 글꼴 같은 기본값, 컴포넌트별 사용법, 화면별 스펙, 구현할 때 빠지기 쉬운 함정, 검수 체크리스트까지 다섯 개 문서다.
문서로 옮긴 이유가 있다. 시안 HTML은 "이 화면은 이렇게 생겼다"만 말해준다. 커버 이미지 비율을 16:9로 맞춘다거나, 화면 크기 구분점을 두 개만 쓴다거나, 한글은 단어 중간에서 줄바꿈하지 않는다는 규칙은 그림만 봐서는 알 수 없다. 실제로 이 두 가지는 한 번씩 놓쳐서 다시 고쳤다.
지금은 문서가 시안보다 우선이다. 시안 화면에 문서 규칙이 안 보이면, 문서가 맞다.
이 규칙이 실제로 작동한 적이 있다. 시안 푸터에 "매일 자동으로 발행"이라는 문구가 들어 있었는데, 정작 문서에는 실제 발행 방식과 다른 표현은 쓰지 말라고 적혀 있었다. 시안이 자기 규칙을 어긴 셈이다. 그 문구는 안 넣었다.
4. 시안에 없는 화면은 먼저 만들어보고 결정했다
AI 검수 결과를 보여주는 카드는 시안에 없었다. 설계 단계에서 생각하지 못한 기능이라 그렇다.
이런 건 바로 만들면 십중팔구 다시 만들게 된다. 그래서 따로 시험용 페이지를 하나 만들어 실제 검수 결과 하나와 예시 두 개를 넣고 화면으로 먼저 확인했다. 괜찮다고 판단한 뒤에 편집기에 옮겼다.
여기서도 깃허브가 보여주는 방식을 그대로 베끼지 않고, 이 블로그의 규칙에 맞춰 색을 골랐다 — 고치기 전 문장은 빨강 계열 취소선, 고친 뒤 문장은 초록 계열. 이미 정해둔 의미 색을 그대로 쓴 것이다.
그러다 뜻밖의 것도 발견했다. 편집기 쪽 CSS가 존재하지도 않는 색 변수를 가져다 쓰고 있었다. 아무도 정의한 적이 없어서 계속 기본값으로 떨어지고 있었던 것이다. 이때 제대로 채웠다.
5. 돌아보면
화면을 먼저 그린 것 자체는 잘한 일이었다. 그리는 동안 "이 버튼은 왜 있지?" 같은 질문이 나오고, 그게 요구사항을 다듬어준다.
틀린 건 그려놓고 대충 비슷하게 만들어도 된다고 생각한 것이었다. 비슷하게 만든 화면은 비슷해 보이지 않는다. 그럴 바엔 처음부터 시안대로 만드는 편이 결국 빠르다.
다음 편에서는 이 화면들을 무엇으로 만들었는지 — Astro와 Payload와 Cloudflare를 고른 이유를 쓴다.