디자이너 취준생 포트폴리오를 보다 보면 한숨이 나올 때가 있습니다. 화려한 인터랙션, 3D 지도로 꽉 채운 화면, 형형색색의 그래프까지. 비주얼은 플러스엑스 뺨치는데, 정작 뜯어보면 '가짜 데이터'로 범벅이 된 경우가 허다합니다. Lorem Ipsum으로 채워진 텍스트 박스처럼, 그래프의 수치도 아무 의미 없는 랜덤 값입니다. 심지어 개발 구현 가능성은 고려조차 안 되어 있죠. "개발자가 알아서 하겠지"라고요? 천만에요. 그건 디자인이 아니라 그냥 그림 그리기입니다.
오늘 제가 소개할 케이스는 'bikemap.nyc'라는 프로젝트입니다. 뉴욕의 공유 자전거 Citi Bike의 전체 운행 기록을 브라우저 상에서 시각화한 결과물이죠. 이 프로젝트를 보면서 '데이터가 디자인을 어떻게 주도해야 하는가'에 대해 뼈저리게 느낀 점을 공유하려 합니다.
1. "느낌적인 느낌" 말고, "압도적인 팩트"
많은 주니어 디자이너들이 클라이언트나 기획자에게 시안을 설명할 때 이런 말을 씁니다. "역동적인 느낌을 주려고 파티클을 썼어요." 혹은 "사용자의 흐름을 보여주려고 라인을 그렸어요." 근거가 빈약하니 설득도 안 됩니다. 결국 "저는 파란색이 좋은데..." 같은 취향 싸움으로 변질되죠.
이 프로젝트를 보세요. 단순히 예쁘게 보이려고 점들을 찍은 게 아닙니다. 2013년부터 쌓인 실제 운행 데이터를 기반으로 합니다. 사용자가 특정 시점을 선택하면(예: 2025년 1월 1일 수요일 오전 9시), 그 시간에 실제로 움직였던 자전거들의 흐름이 화면에 나타납니다. 'Rides'라는 수치와 'FPS(초당 프레임)'가 실시간으로 찍히죠.
이게 왜 중요할까요? 디자인의 근거가 '데이터' 그 자체이기 때문입니다. "왜 여기에 점이 이렇게 많아요?"라고 물으면 "여기가 출근 시간대 타임스퀘어니까요"라고 답할 수 있습니다. 뇌피셜이 끼어들 틈이 없죠. 데이터 시각화 프로젝트에서 디자이너의 역할은 데이터를 왜곡 없이, 그리고 성능 저하 없이 보여주는 '그릇'을 만드는 것입니다.
2. 픽셀 1px보다 중요한 건 '렌더링 퍼포먼스'
에이전시 인턴 시절, 웹사이트에 화려한 인터랙션을 넣었다가 개발자분께 불려 간 적이 있습니다. "다은 씨, 이거 모바일에서 돌리면 폰 터져요." 그때는 그 말이 야속했는데, 지금은 압니다. 퍼포먼스를 고려하지 않은 디자인은 폭력입니다.
이 시각화 프로젝트의 핵심은 '브라우저에서' 이 방대한 역사를 돌린다는 점입니다. 맵박스(Mapbox)나 일반적인 DOM 조작으로는 수십만 개의 데이터를 실시간으로 뿌리기 어렵습니다. 아마도 WebGL이나 WebGPU 같은 기술을 활용해 GPU 가속을 극대화했을 겁니다.
디자이너로서 우리는 여기서 무엇을 배워야 할까요? 바로 '개발 제약 사항에 대한 이해'입니다. 단순히 "개발자가 안 된다는데요?"라며 징징거릴 게 아니라, 우리가 그리려는 화면이 브라우저에서 렌더링될 때 부하가 얼마나 걸릴지 예측해야 합니다.
- 수만 개의 점을 한 번에 찍어야 하는가?
- 줌 레벨(Zoom Level)에 따라 클러스터링(뭉치기)을 해야 하는가?
- 데이터 로딩 중일 때 빈 화면(Skeleton UI)은 어떻게 처리할 것인가?
이런 고민 없이 XD나 Figma에서 점만 예쁘게 찍어서 넘겨주는 건 직무 유기입니다. bikemap.nyc는 하단의 타임라인 바, 재생 컨트롤, 데이터 상태 표시(FPS 등) 같은 UI 요소들이 지도 렌더링을 방해하지 않으면서도 필수 정보를 전달하도록 미니멀하게 설계되었습니다. 기술적 한계를 디자인으로 영리하게 풀어낸 사례죠.
3. 사용성은 디테일에서 온다 (단축키와 상태 표시)
이 사이트의 UI를 뜯어보면 흥미로운 지점이 있습니다. 검색 ⌘ K, 재생 Space, 무작위 R, 정보 A 같은 단축키 가이드가 화면에 노출되어 있다는 점입니다. 보통 웹 기반 대시보드에서는 클릭 인터랙션을 주로 사용하지만, 이 프로젝트는 전문가용 툴(Pro Tool)처럼 키보드 중심의 조작을 유도합니다.
데이터 시각화를 다루는 사용자는 일반적인 이커머스 쇼핑객과는 다릅니다. 데이터를 탐색하고, 특정 구간을 반복해서 보려는 니즈가 강하죠. 마우스로 타임라인을 미세하게 조절하는 것보다 키보드 단축키가 훨씬 효율적일 수 있습니다.
또한 'FPS', 'Rides' 같은 시스템 상태 정보를 숨기지 않고 드러냈습니다. 이는 사용자에게 "지금 당신의 브라우저가 열심히 일하고 있어요"라는 피드백을 줌과 동시에, 데이터의 신뢰도를 높여주는 장치로 작동합니다. 불친절해 보일 수 있는 시스템 정보를 UX의 일부로 승화시킨 겁니다.
결론: 디자이너여, 데이터 깎는 노인이 되자
주니어 시절, 저도 '비핸스(Behance) 스타일'의 디자인을 동경했습니다. 하지만 쏘카에서 실제 프로덕트를 다루면서 깨달았습니다. 진짜 좋은 디자인은 화려한 껍데기가 아니라, 복잡한 데이터를 사용자가 이해하기 쉬운 형태로 가공해 주는 '논리적 설계'라는 것을요.
bikemap.nyc는 화려한 장식 하나 없이, 오직 데이터와 그 흐름만으로 아름다움을 만들어냈습니다. 여러분이 만약 대시보드나 관리자 페이지, 혹은 데이터 관련 프로젝트를 맡게 된다면 이 점을 기억하세요.
- 가짜 데이터 대신 실제 더미 데이터(Real-dummy data)를 확보해서 시안을 잡으세요. 극단적인 값(최대/최소)을 넣었을 때 디자인이 깨지는지 확인해야 합니다.
- 개발자와 초기 단계부터 렌더링 방식에 대해 논의하세요. "이거 캔버스로 그려야 하나요, DOM으로 가능한가요?"라고 먼저 물어보는 디자이너는 사랑받습니다.
- 사용자가 이 데이터를 통해 무엇을 얻고자 하는지 파악하세요. 예쁜 그래프보다 중요한 건 '인사이트'를 줄 수 있는 정보 구조입니다.
예술은 갤러리에서 하시고, 피그마 앞에서는 철저히 공학자가 되시길 바랍니다. 그래야 우리 디자인이 개발팀에서 반려되지 않고 살아남을 수 있으니까요.
