우연히 깃허브 트렌딩을 보다가 흥미로운 프로젝트를 발견했습니다. vamos라는 도구인데, 쉽게 말해 '아미가(Amiga) OS를 위한 와인(Wine)'입니다. 보통 옛날 소프트웨어를 돌리려면 무거운 에뮬레이터(UAE 등)를 띄우고 그 안에서 OS를 부팅하는 번거로운 과정을 거쳐야 합니다. 하지만 vamos는 다릅니다. 하드웨어를 통째로 에뮬레이션하는 대신, 아미가 OS의 API 호출을 호스트 시스템(Mac이나 Linux)의 명령어로 '번역'해서 실행합니다. 즉, 무거운 가상 머신 없이도 레거시 바이너리가 현세대 시스템 위에서 가볍게 돌아가는 것이죠.
이 기술적인 설명을 읽으며 저는 무릎을 탁 쳤습니다. 이것이야말로 우리 UI/UX 디자이너가 개발자에게 전달해야 할 산출물의 이상적인 형태라고 느꼈기 때문입니다. 에이전시 인턴 시절, 저는 디자인을 '그림'으로 접근했습니다. 포토샵이나 피그마 캔버스 위에 예쁘게 그려진 화면을 개발자에게 넘기면, 그들이 알아서 구현해 줄 것이라 착각했습니다. 마치 개발자가 거대한 에뮬레이터를 돌려서 내 그림을 픽셀 하나하나 똑같이 렌더링해주길 바랐던 셈입니다. 결과는 뻔했습니다. 개발자는 "이거 마진 값이 몇인가요?" "해상도 바뀌면 이 버튼은 어디로 가나요?"라고 끊임없이 되물었고, 저는 "그냥 느낌대로 맞춰주세요"라는 최악의 답변을 하곤 했습니다.
vamos가 하드웨어를 에뮬레이션하지 않고 라이브러리(exec.library, dos.library)를 교체하여 작동한다는 점은 시사하는 바가 큽니다. 디자인 핸드오프(Handoff)도 마찬가지여야 합니다. 개발자에게 완성된 '화면(Image)'이라는 무거운 덩어리를 던지는 것이 아니라, 그 화면을 구성하는 논리적인 '규칙(Library)'을 전달해야 합니다. 저는 이것을 뼈저리게 느낀 후부터 작업 방식을 완전히 뜯어고쳤습니다. 단순히 화면을 그리는 시간을 줄이고, 그 화면이 왜 그렇게 구성되어야 하는지 설명하는 문서를 깎는 데 시간의 70%를 쏟기 시작했습니다.
실패했던 디자인 전달 방식이 '망한 사례'라면, 개선된 방식은 철저한 '컴포넌트 기반 사고'입니다. 예를 들어 버튼 하나를 전달하더라도 단순히 RGB 값을 적는 게 아니라, 우리 디자인 시스템의 어떤 컬러 토큰(Token)을 사용했는지, 호버(Hover) 시에는 어떤 물리적 변화가 일어나는지, 텍스트가 길어지면 줄바꿈은 어떻게 처리되는지를 명시합니다. 마치 vamos가 아미가의 명령어를 호스트 CPU가 이해할 수 있게 번역해주듯, 디자이너의 시각적 의도를 개발자가 이해할 수 있는 코드의 언어(변수, 로직, 상태값)로 번역해서 전달하는 것입니다.
많은 주니어 디자이너들이 "개발자가 제 디자인을 망쳤어요"라고 하소연합니다. 하지만 냉정하게 말해, 그건 디자이너가 '번역기' 역할을 제대로 수행하지 못했기 때문일 확률이 높습니다. 개발자는 그림을 감상하는 사람이 아니라, 우리가 설계한 논리를 코드로 구축하는 엔지니어입니다. 그들에게 감성적인 뉘앙스는 노이즈일 뿐입니다. 우리가 제공해야 할 것은 명확한 런타임 환경, 즉 오해의 소지가 없는 스펙 문서입니다.
vamos 프로젝트를 보며 다시금 다짐합니다. 우리의 디자인이 레거시(Legacy)로 남지 않고 어떤 환경에서도 유연하게 돌아가는 라이브러리가 되려면, 우리는 더 집요하게 논리를 세워야 합니다. "뭔가 엣지있게"라는 말 대신 "보더 라디우스 4px, 스트로크는 인사이드 1px"이라고 말할 수 있어야 합니다. 미대생의 감성은 잠시 접어두고 공대생의 논리를 장착하십시오. 그래야만 당신의 디자인은 비로소 살아 움직이는 프로덕트가 될 수 있습니다.
