블라인드박스 서비스 디자인 정체성을 한번에 잡다
목차
몇 달 전부터 자꾸만 느껴진 게 있었다. 우리 블라인드박스 서비스가 화면마다 조금씩 다르다는 것. 상품 카드는 한 스타일, 카테고리 페이지는 다른 스타일, 드롭 페이지는 또 다른 톤... 사용자 입장에서는 같은 서비스를 쓰는 거지만, 우리 입장에선 매번 "이건 어떤 폰트지?", "이 카드는 왜 이렇게 생겼지?" 하면서 일관성 없이 개발하고 있었다.
그래서 이번에 간단하지만 확실한 결정을 내렸다. 폰트로 전체 톤을 맞추고, 카드 레이아웃을 이미지에 의존하지 않는 방식으로 통일하자. 이게 생각보다 작은 작업은 아니었는데, 다행히 우리 컴포넌트 구조가 좋아서 몇 가지 핵심 파일만 손대면 됐다.
폰트 선택, "읽기 쉬우면서도 친근한" 톤을 찾다
제목에는 Baloo 2, 본문과 작은 텍스트는 Nunito Sans로 가기로 했다. 둘 다 오픈 폰트 라이선스(OFL)라 라이선스 걱정도 없고, 글자가 친근하면서도 가독성이 좋다. 특히 블라인드박스는 "뭐가 나올지 몰라서 설레는" 느낌을 주는 서비스잖아. 딱딱한 기하학적 폰트보다는 조금 둥글둥글하고 따뜻한 톤이 맞다고 생각했다.
사실 폰트 선택은 단순히 "좋아 보인다" 수준으로 끝나면 안 되는 일이다. 팀 내에서:
- 부팅 성능: 웹폰트 2개 로딩 비용이 얼마나 되나?
- 호환성: 모바일 브라우저에서도 제대로 표시되나?
- 대체 폰트(fallback): OFL 폰트가 로드 실패할 때 어떤 시스템 폰트로 넘어갈 건가?
이런 걸 미리 논의하고 정했다. 폰트는 사소해 보이지만 실제로는 성능과 디자인 일관성에 모두 영향을 준다는 걸 이번에 더 확실히 느꼈다.
이미지리스 카드, 데이터로만 레어도를 표현하다
변경 파일 목록을 보면 FigureCard.astro, RequestWidget.astro, 그리고 여러 dex/ 컴포넌트들이 함께 수정됐다. 이게 뭐냐면, 상품 카드가 이미지 파일에 의존하지 않고도 레어도를 시각적으로 표현하게 바꿨다는 뜻이다.
구체적으로 뭘 바꿨냐면:
- 상품의 레어도(일반, 레어, 슈퍼레어 등)를 색상, 테두리, 아이콘 조합으로 구분
- DB의 seed-blindbox.sql에 이 정보를 메타데이터로 저장 → 런타임에 CSS 클래스나 데이터 속성으로 렌더링
- 이미지 에셋이 없어도 카드가 일관된 모습을 유지하고, 관리자가 레어도를 쉽게 수정 가능
이건 꽤 중요한 설계 결정이다. 왜냐하면:
1. 확장성: 새로운 레어도 등급이 추가되면, 이미지를 준비할 필요 없이 CSS 규칙 하나 추가하면 된다.
2. 성능: 이미지 파일을 안 로드하니까 초기 로딩이 빠르다.
3. 일관성: 컴포넌트마다 다르게 그려질 일이 없다. 폰트와 색상 규칙만 맞으면 자동으로 통일된다.
팀 입장에서도 코드리뷰가 간단해졌다. "이 카드 왜 저렇게 생겼어?" 물어볼 필요 없이, 데이터베이스의 레어도 값을 보면 스타일이 결정되니까.
브랜드, 드롭, 상세 페이지까지 한 번에
변경 파일을 보면 BrandDetailBody.astro, BrandsBody.astro, DropsBody.astro 등 여러 페이지 컴포넌트가 함께 수정됐다. 이건 단순한 "폰트만 바꾼 것" 이상의 작업이었다는 뜻이다. 각 페이지에서 상품을 표시하는 방식이 조금씩 달랐고, 그걸 모두 새로운 카드 표준에 맞춰야 했다.
여러 곳에 걸친 변경은 코드리뷰할 때 항상 조심해야 한다. 한 군데서는 잘 보이는데 다른 데서 뭔가 빠질 수 있기 때문이다. 우리는 이 PR을 리뷰할 때:
- 각 페이지에서 카드가 정말 같은 방식으로 렌더되는지 확인
- 반응형 레이아웃에서도 카드가 깨지지 않는지 테스트
- 폰트 로드 타이밍 문제가 없는지 점검
이런 식으로 여러 각도에서 봤다.
데이터 레이어도 함께 손 본 이유
db/seed-blindbox.sql 파일도 수정됐다는 건, 단순히 프론트엔드 컴포넌트만 바꾼 게 아니라 데이터 구조도 정리했다는 뜻이다. 카드의 레어도 정보가 일관되게 저장되고, 시드 데이터도 새 스타일에 맞춰 업데이트된 거다. 이게 중요한 이유는:
- 새 개발자가 온라보딩할 때 데이터-UI 매핑이 명확하다.
- 나중에 또 다른 디자인 변경이 생기면, 데이터 구조가 이미 일관되어 있으니 변경 범위가 줄어든다.
회고: 작은 결정이 시스템 전체에 주는 영향
이 작업을 통해 느낀 게 있다면, "폰트 하나, 카드 레이아웃 하나" 같은 작은 디자인 결정이 실제로는 얼마나 큰 영향을 주는지라는 거다. 폰트를 정하려고 해도 라이선스, 성능, 호환성을 다 챙겨야 하고, 카드 스타일을 바꾸려고 해도 DB부터 컴포넌트까지 모두 손을 봐야 한다.
그렇기 때문에 이런 작업은 빨리빨리 대충 하면 안 된다. 처음부터 "이걸 정하면 앞으로 몇 개월간 이렇게 쓸 건데, 정말 이게 맞나?" 를 충분히 생각하고 진행해야 한다는 걸, 이번 작업을 리드하면서 다시 한 번 느꼈다.
특히 팀 리딩 관점에서 보면, 이런 "기초 설정" 작업은 초반부터 제대로 해두는 게 훨씬 싸다는 것도 명확했다. 만약 카드 스타일이 페이지마다 다르게 자란 상태로 방치했다면, 나중에 통일할 때 훨씬 더 많은 파일을 수정했을 테니까.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.