'더 많이'가 곧 '더 좋음'을 의미하던 시대가 끝나가고 있다. 기능을 쌓고, 애니메이션을 입히고, 프레임워크 위에 프레임워크를 얹는 방식이 오히려 사용자 경험을 갉아먹는다는 반증이 여기저기서 터져 나온다. 최근 세 가지 사례가 그 흐름을 선명하게 보여준다. 기술 선택은 단순한 개발자의 취향 문제가 아니라, 사용자가 매일 마주하는 경험의 품질을 직접 결정한다.
체인톱으로 버터 바르기: Next.js → Astro 마이그레이션
dev.to에 올라온 한 개발자의 포트폴리오 마이그레이션 회고는 꽤 솔직하다. React 19, Framer Motion, GSAP을 모두 갖춘 Next.js 포트폴리오를 Astro로 완전히 뜯어고친 이유는 단 하나였다. "정적 텍스트를 렌더링하기 위해 230KB의 JavaScript를 브라우저에 전송하고 있었다." 블로그 포스트 하나를 읽으려는 사용자에게 React 런타임, 애니메이션 라이브러리, 클라이언트 하이드레이션 비용을 고스란히 떠넘긴 셈이다.
이 사례가 흥미로운 이유는 Next.js를 부정하지 않는다는 점이다. 저자는 "대시보드, 이커머스, SaaS처럼 인터랙션이 많은 앱이라면 Next.js를 다시 선택할 것"이라고 명확히 선을 긋는다. 핵심은 도구의 우열이 아니라 맥락에 맞는 선택이다. Astro로 전환한 결과는 숫자로 나타났다. 블로그 포스트 페이지의 JavaScript 번들이 230KB에서 0KB로 줄었고, Lighthouse 성능 점수는 85~90에서 99~100으로 뛰었다. 빌드 시간도 15초에서 5초로 단축됐다. Astro의 아일랜드 아키텍처 덕분에 실제로 인터랙션이 필요한 컴포넌트에만 JavaScript가 붙고, 나머지는 순수 HTML로 서빙된다. View Transitions API를 네이티브로 지원해 Framer Motion 없이도 페이지 전환 애니메이션을 구현했다. 덜어냄으로써 더 빨라지고, 더 가벼워지고, 유지보수도 쉬워졌다.
추가했더니 오히려 망가진 인터페이스: macOS Tahoe 논란
반면 GeekNews를 통해 확산된 macOS Tahoe의 메뉴 아이콘 논란은 반대 방향의 교훈을 준다. Apple이 macOS Tahoe에서 메뉴바에 아이콘을 대거 추가했는데, 반응은 싸늘하다. 아이콘의 의미가 불분명하고, 앱마다 기준이 제각각이라 오히려 메뉴 탐색이 더 어려워졌다는 것이다. 커뮤니티 반응 중 가장 신랄한 표현은 "2005년 Gnome 테마" 혹은 "2009년 KDE 사용자 제작 테마 같은 싸구려 미래풍"이었다.
여기서 주목할 지점이 있다. 아이콘 자체가 문제가 아니다. 난독증이 있는 사용자는 아이콘이 텍스트보다 훨씬 빠르게 인식된다고 말한다. 아이콘은 접근성 관점에서 분명히 가치가 있다. 문제는 일관성 없는 시각 언어다. 예전의 Apple은 UI 통일성을 자랑했다. 지금은 앱마다 디자이너가 달라 보일 만큼 아이콘 선택 기준이 제각각이다. 결국 Steve Troughton-Smith가 터미널 명령어(defaults write -g NSMenuEnableActionImages -bool NO)로 아이콘 전체를 숨기는 방법을 공개했고, 이를 적용한 사용자들은 "아이콘이 사라진 상태가 더 깔끔하고 집중하기 쉽다"고 평가했다. 추가가 경험을 개선하지 못할 때, 사용자는 제거를 직접 선택한다. 이것이 디자인 실패의 가장 솔직한 피드백이다.
의도적으로 작게 만든 앱: Trinkt의 프로덕트 철학
dev.to에 소개된 Trinkt는 세 사례 중 가장 작지만, 가장 명확한 프로덕트 사고를 담고 있다. 펭귄이 해변에서 가장 매끈한 조약돌을 골라 상대에게 선물하는 의식에서 영감을 받은 이 앱의 핵심 기능은 단 하나다. 하루에 3개의 절차적 생성 아트 토큰 중 하나를 골라 친구에게 보내는 것. 팔로워 수도, 공개 프로필도, 피드도, 알고리즘도 없다.
개발자가 자랑스럽게 꼽은 기능 중 하나가 '심플 모드'다. 토글 하나로 스트릭, 희귀도 배지, 게임화 요소를 모두 걷어낸다. "모든 사람이 '인게이지먼트'를 원하지는 않는다. 어떤 사람은 그냥 친구에게 아트를 보내고 싶을 뿐이다." 이 문장은 현대 소셜 앱이 놓치고 있는 핵심을 찌른다. 기능을 추가해 사용자를 붙잡는 대신, 기능을 제거해 진짜 목적에 집중하게 만드는 것. Trinkt는 플랫폼이 되려 하지 않는다. 그게 이 앱의 전략이자 정체성이다.
세 사례가 가리키는 하나의 방향
세 사례를 관통하는 질문은 동일하다. "이게 진짜 사용자에게 필요한가?" Next.js → Astro 마이그레이션은 프레임워크 선택이 성능과 직결되며, 과도한 기술 스택이 사용자 경험을 훼손한다는 것을 수치로 증명했다. macOS Tahoe 논란은 추가된 기능이 일관성 없이 구현될 때 오히려 경험을 퇴보시킨다는 것을 Apple이라는 거대한 반면교사로 보여줬다. Trinkt는 '덜어냄'을 전략으로 삼은 프로덕트가 어떻게 명확한 정체성을 가질 수 있는지를 보여준다.
프론트엔드 개발자로서 이 흐름이 시사하는 바는 분명하다. 기술 선택은 취향의 영역이 아니라 프로덕트 결정의 영역이다. 어떤 프레임워크를 쓰느냐, 어떤 UI 요소를 추가하느냐, 어떤 기능을 빼느냐—이 모든 선택이 사용자가 매일 경험하는 속도, 명확함, 그리고 감정을 결정한다. "최고의 코드는 브라우저에 전송하지 않는 코드"라는 Astro 마이그레이션 회고의 첫 문장은, 사실 코드 이야기가 아니다. 사용자 경험 이야기다.