에이전시 인턴 시절, 가장 두려웠던 순간은 화려한 인터랙션이 들어간 시안을 들고 개발팀에 찾아가는 시간이었습니다. "다은 님, 이거 웹에서 구현하면 프레임 다 끊겨요." 혹은 "이런 물리 효과는 라이브러리 용량이 너무 커서 모바일에서는 못 씁니다."라는 피드백을 들을 때마다 저는 작아졌습니다. 당시의 저는 디자인 툴인 피그마(Figma)나 애프터 이펙트(After Effects)의 화면이 곧 구현될 결과물이라고 착각했습니다. 하지만 개발자들에게 화면은 픽셀의 집합이 아니라, 브라우저가 연산해야 할 비용(Cost)이자 논리의 결과물이었습니다. 그때 뼈저리게 느꼈습니다. 디자이너가 개발 언어의 구조, 특히 렌더링의 비용을 이해하지 못하면 영원히 '예쁜 그림을 그리는 사람'에 머물 수밖에 없다는 사실을 말입니다.
오늘 소개할 Dwitter는 바로 그 '비용'과 '논리'를 극단적으로 훈련할 수 있는 도구입니다. 겉보기에는 화려한 그래픽 아트 사이트처럼 보이지만, 이곳의 규칙은 잔인하리만큼 단순합니다. 단 140자의 자바스크립트 코드만으로 시각적인 데모를 만들어야 합니다. 트위터(현 X)의 옛 글자 수 제한과 동일한 이 초소형 코드 안에 3D 회전, 파티클 시스템, 프랙탈 구조 같은 복잡한 그래픽을 담아내야 합니다. 이곳에는 이미지를 불러오는 `<img>` 태그도, 편리한 CSS 애니메이션 라이브러리도 없습니다. 오직 순수한 수학과 논리, 그리고 캔버스(Canvas) API를 다루는 날 것의 코드만 존재합니다.
왜 UI/UX 디자이너가 이런 '코드 골프(Code Golf, 코드를 최대한 짧게 줄이는 놀이)' 사이트를 봐야 할까요? 바로 화면을 구성하는 가장 효율적인 논리를 배울 수 있기 때문입니다. 디자이너가 마우스로 한 땀 한 땀 그린 수백 개의 벡터 곡선은 개발 단계에서 엄청난 용량의 SVG 파일이나 복잡한 경로(Path) 데이터가 됩니다. 하지만 Dwitter의 코드를 보면, 그 복잡한 곡선들이 단 한 줄의 `Math.sin(t)` 함수로 표현됩니다. 우리는 시각적 결과물에 집착하여 리소스를 낭비하지만, 코드는 시간 변수 `t`와 삼각함수만으로 무한히 반복되는 파도를 만들어냅니다.
이 차이를 이해하는 것이 제가 말하는 '생존형 디자인'의 핵심입니다. Dwitter의 작품들을 뜯어보면, 개발자들이 왜 그토록 "규칙"과 "패턴"을 강조하는지 알게 됩니다. 140자 안에 코드를 욱여넣으려면 불필요한 변수는 제거하고, 반복되는 동작은 `for` 문으로 묶어야 하며, 복잡한 if-else 조건문 대신 수학적 공식을 사용해야 합니다. 이것은 곧 프로덕트 디자인에서의 최적화 원칙과 맞닿아 있습니다. 우리가 디자인 시스템을 만들고 컴포넌트를 재사용 가능한 형태로 구조화하는 이유도 결국 개발의 효율성과 유지보수의 용이성 때문입니다. Dwitter는 그 원리를 시각 예술의 형태로, 가장 압축적으로 보여주는 교과서입니다.
저는 요즘도 인터랙션 가이드를 작성하기 전, 머리를 식힐 겸 Dwitter를 켜봅니다. 그리고 움직임을 보며 생각합니다. "저 물결은 일일이 프레임별로 그린 게 아니라, 사인 함수(Sine function) 주기를 조절한 거구나." 이렇게 사고의 회로를 바꾸면 개발자에게 전달하는 문서의 질이 달라집니다. "물결이 꿀렁거리게 해주세요"라는 추상적인 요청 대신, "X축 이동은 등속도로 하되, Y축 높이값은 2초 주기의 사인 그래프 형태로 움직이게 구현해 주세요"라고 구체적인 로직을 제안할 수 있게 됩니다.
개발을 직접 할 줄 몰라도 괜찮습니다. 하지만 적어도 우리가 그리는 화면 뒤에서 어떤 연산이 일어나는지, 1px의 움직임을 위해 CPU가 어떤 계산을 해야 하는지에 대한 감각은 반드시 필요합니다. Dwitter에 접속해서 아무 데모나 클릭해 보세요. 그리고 아래 적힌 알 수 없는 외계어 같은 140자의 코드를 멍하니 바라보세요. 그 짧은 텍스트가 화면 가득 채우는 화려한 비주얼을 만들어낸다는 경이로움을 느끼는 것만으로도, 여러분은 이미 '공대생의 논리'에 한 걸음 다가선 것입니다. 개발자와의 불필요한 기싸움을 줄이고 싶다면, 가끔은 화려한 레퍼런스 사이트 대신 이 차가운 코드의 세계를 들여다보시길 권합니다.
