왜 어떤 UI는 그냥 좋아 보일까
Linear나 Vercel, 애플 웹사이트를 쓰다 보면 딱 꼬집어 말하긴 어려워도 “이거 잘 만들었다” 싶을 때가 있죠. 반대로 기능은 다 되는데 어딘가 어색한 서비스도 있고요. 이 차이를 만드는 걸 흔히 테이스트(taste), 우리말로는 안목이라고 불러요.
토스트 알림 라이브러리 Sonner와 드로어 컴포넌트 Vaul을 만든 디자인 엔지니어 Emil Kowalski가 'Developing Taste'라는 글에서 바로 이 주제를 다뤘어요. 이 사람은 Vercel 등에서 일했고, 웹 인터랙션과 애니메이션을 가르치는 강의도 운영하고 있어요. 글의 메시지를 한 줄로 줄이면 이거예요. 안목은 타고나는 재능이 아니라 훈련으로 기르는 기술이다.
안목은 개인 취향과 다르다
여기서 헷갈리면 안 되는 게 있어요. 안목은 개인 취향과 달라요. 파란색이 좋으냐 빨간색이 좋으냐는 취향이죠. 하지만 버튼을 눌렀을 때 반응이 바로 오는지, 모달이 뜰 때 움직임이 자연스러운지, 글자 간격이 편하게 읽히는지는 대부분 이유를 들어 설명할 수 있는 영역이거든요.
커피 맛을 배우는 과정을 떠올려 보면 쉬워요. 처음엔 다 쓴맛으로만 느껴지는데, 여러 잔을 비교하며 마시다 보면 산미랑 바디감, 향이 하나씩 구분되기 시작하잖아요. UI도 똑같아요. 좋은 걸 많이 보면서 왜 좋은지 계속 따지다 보면, 전엔 안 보이던 차이가 눈에 들어와요.
안목을 기르는 구체적인 방법
첫째, 좋은 것을 많이 보되 의식하면서 보세요. 그냥 스크롤하며 구경하는 게 아니라 “이게 왜 좋지?”를 계속 물어보는 거예요. 메뉴가 어느 지점에서부터 펼쳐지는지, 마우스를 올렸을 때 색이 얼마나 빨리 바뀌는지, 요소 사이 여백은 얼마나 되는지 같은 것들이요. 브라우저 개발자 도구를 열어 실제 CSS 값을 확인해 보면 감으로만 느끼던 게 숫자로 보여요.
둘째, 따라 만들어 보세요. 화가가 명화를 따라 그리며 배우듯이, 잘 만든 컴포넌트를 직접 재현해 보는 거예요. 맥OS 독(Dock)이 마우스 근처에서 커지는 효과나, iOS에서 시트가 아래서 올라오는 느낌을 웹으로 만들어 보세요. 보기엔 단순한 동작 안에 결정할 게 얼마나 많은지 금방 알게 될 거예요.
셋째, 디테일마다 이유를 공부하세요. 애니메이션 이징(easing)을 예로 들어 볼게요. 이징은 움직임이 빨라지고 느려지는 정도를 나타내는 곡선인데요, 화면에 들어오는 요소는 빠르게 출발해서 천천히 멈추는 ease-out이 자연스럽게 느껴져요. 현실에서 물체가 움직이다 멈추는 모습과 닮았기 때문이에요. 기본 ease 대신 transition: transform 200ms cubic-bezier(0.23, 1, 0.32, 1);처럼 직접 고른 곡선을 쓰면 같은 애니메이션도 훨씬 또렷하게 느껴져요. 하루에도 수십 번 쓰는 동작, 예를 들어 단축키로 여는 커맨드 메뉴는 애니메이션을 아예 빼거나 아주 짧게 하는 게 낫다는 원칙도 있어요. 반복해서 보면 아무리 예쁜 움직임도 결국 기다림이 되거든요. 이런 원리를 알게 되면 막연한 “느낌”이 근거 있는 “판단”으로 바뀌어요.
넷째, 시간을 두고 다시 보세요. 막 만든 직후엔 다 괜찮아 보이거든요. 하루쯤 지나서 다시 보면 어색한 부분이 신기할 만큼 잘 보여요.
업계 맥락: 왜 지금 안목인가
최근 몇 년 사이 디자인 엔지니어(Design Engineer)라는 직군이 뚜렷해졌어요. 디자인과 개발을 둘 다 하면서, 시안을 코드로 옮길 때 사라지기 쉬운 디테일을 지켜내는 사람들이에요. Vercel, Linear, Raycast 같은 회사가 제품 품질로 인정받는 데에는 이런 사람들의 역할이 커요.
여기에 AI 코딩 도구가 흐름을 더 키우고 있어요. 이제 기능 구현은 AI가 몇 분이면 해주잖아요. 그러니 차별점은 “만들 수 있느냐”에서 “뭐가 좋은지 알아보고 고를 수 있느냐”로 옮겨가고 있어요. 폴 그레이엄도 오래전 에세이 'Taste for Makers'에서 좋은 취향은 상대적인 게 아니라 배울 수 있는 것이라고 주장했는데요, 그 이야기가 AI 시대에 다시 힘을 얻고 있는 셈이에요.
한국 개발자에게 주는 시사점
국내에서도 토스처럼 인터랙션 디테일로 이름난 서비스가 생기면서, 프론트엔드 개발자에게 바라는 것도 달라지고 있어요. 시안을 똑같이 옮기는 것에서 그치지 않고, 시안에 없는 부분을 채우는 능력이 중요해졌거든요. 로딩 중일 때, 에러가 났을 때, 데이터가 비어 있을 때 화면이 어떻게 보이고 어떻게 전환되는지는 시안에 다 그려져 있지 않은 경우가 많잖아요. 이런 걸 잘 채우는 개발자가 팀에서 대체하기 어려운 사람이 돼요.
당장 해볼 만한 것도 있어요. 매일 쓰는 앱에서 마음에 드는 인터랙션을 하나씩 녹화해 두고, 주말에 하나씩 따라 만들어 보세요. Motion(구 Framer Motion) 같은 라이브러리를 쓰면 생각보다 빨리 시작할 수 있어요. 이렇게 한 달만 해도 디자이너와 이야기할 때 쓰는 말부터 달라질 거예요.
마무리
한 줄 정리: 안목은 좋은 걸 많이 보고, 왜 좋은지 따지고, 직접 따라 만들면서 길러지는 기술이에요.
여러분이 “이건 진짜 잘 만들었다” 싶었던 UI는 뭐였나요? 그리고 그게 왜 좋았는지 말로 설명할 수 있나요? 댓글로 같이 이야기 나눠봐요.
🔗 출처: Hacker News