속도는 기능이 아니라 태도입니다
티켓 오픈 1분과 10만 자 풀이가 가르쳐 준 것
성능 이야기를 숫자로만 하면 설득이 잘 되지 않습니다. 하지만 티켓 오픈 17시 정각에 서버가 버티지 못하면, 그날의 공연은 이미 절반쯤 망가집니다. 우리 서비스에서 직접 겪은 두 장면을 통해 속도를 어떻게 설계하는지 정리했습니다.
17시 정각, 1분이 전부인 순간
티켓 오픈은 트래픽이 완만하게 오르지 않습니다. 정해진 시각에 수직으로 꽂힙니다. 티키팅을 만들면서 가장 먼저 붙잡은 문제가 이것이었습니다. 대기열을 길게 세우는 방식은 겉으로만 버티는 것처럼 보일 뿐, 사용자 입장에서는 여전히 "내 차례가 올지 모르는 화면"을 보고 있는 것과 같습니다.
그래서 화면이 먼저 뜨고, 재고 확인은 그다음에 붙도록 순서를 바꿨습니다. 실제로 몇 장이 남았는지, 내 요청이 어디까지 갔는지를 숨기지 않고 보여 주는 편이 훨씬 덜 불안합니다. 성능 개선의 절반은 기다림을 줄이는 일이고, 나머지 절반은 기다리는 이유를 설명하는 일입니다.
10만 자를 어떻게 빨리 보여 줄 것인가
미요사주의 인생 사용설명서는 11장 87개 풀이, 10만 자에 이릅니다. 이걸 한 번에 내려받게 하면 첫 화면이 뜨기까지 한참이 걸립니다. 우리는 앞 2장을 먼저 완성된 상태로 보여 주고, 나머지는 읽는 속도에 맞춰 이어 붙입니다. 무료로 열어 둔 앞 2장이 가장 빨라야 한다는 건 사업적으로도 당연한 요구였습니다.
- 보이는 것부터 그린다 — 첫 화면에 필요한 것만 먼저 렌더링합니다.
- 필요할 때만 불러온다 — 이미지와 긴 본문은 스크롤을 따라 붙입니다.
- 배포할 때마다 잰다 — 성능 예산을 넘으면 배포를 멈춥니다.
성능은 사용자의 시간을 존중하겠다는 약속입니다. 약속은 기능 목록에 적히지 않습니다.
성능 예산은 디자인 회의에서 정해집니다
속도는 개발자 혼자 지킬 수 없습니다. 이미지 한 장, 폰트 한 벌, 화면 전환 애니메이션 하나가 모두 예산을 씁니다. 그래서 프로젝트 시작할 때 디자이너와 개발자가 같은 자리에서 성능 예산을 정하고, 이후 모든 결정을 그 안에서 내립니다. "이 효과를 넣으면 무엇을 빼야 하는가"가 회의의 기본 질문이 됩니다.
이 기준은 외부 프로젝트에도 그대로 적용합니다. 우리 서비스에서 지키지 못하는 기준을 남의 제품에 요구할 수는 없으니까요. 반대로 우리 서비스에서 한 번 겪어 본 문제는, 다른 제품에서 만났을 때 훨씬 빨리 알아봅니다.
빠른 화면은 그 자체로 신뢰가 됩니다. 아무 설명 없이도, 이 팀이 제대로 만들었다는 걸 1초 안에 전달하는 방법은 아직 이것뿐입니다.
