빠른 시대일수록 잃어버리기 쉬운 것이 있다. 바로 이 코드가 사용자에게 진짜 도움이 되는가라는 질문이다. AI가 컴포넌트를 순식간에 생성하고, 에이전트가 PR을 자동으로 열고, 프레임워크가 알아서 최적화를 약속하는 환경에서 프론트엔드 개발자는 역설적으로 제품 감각을 잃을 위험에 처해 있다. 최근 잇달아 등장한 세 편의 글은 각기 다른 각도에서 같은 경고를 보낸다.
버튼 하나를 위해 700KB를 보내는 세계
dev.to에 올라온 「Stop Shipping 700KB of JavaScript for a Button」은 제목만으로도 고통이 느껴지는 글이다. 저자가 지적하는 문제는 버그가 아니다. 페이지는 로드되고, 버튼은 보이고, 디자인은 멀쩡하다. 그런데 중저가 폰 사용자가 버튼을 탭하는 순간 메인 스레드는 이미 다른 일로 꽉 차 있다. 인터페이스가 소프트웨어가 아니라 협상 처럼 느껴지기 시작하는 순간이다.
버튼 하나가 어떻게 작은 마을이 되는지 추적해보면 섬뜩하다. 컴포넌트 라이브러리, 테마 프로바이더, 애널리틱스 래퍼, 아이콘 패키지, 툴팁, 애니메이션 프리미티브, 클라이언트 컴포넌트 경계, 하이드레이션 루트, 그리고 아무도 요청하지 않은 작은 상태 머신까지. 사용자 눈에는 버튼 하나지만 브라우저는 도시를 받는다. 핵심 처방은 단순하다. 브라우저가 이 코드를 첫 번째 상호작용에 진짜 필요로 하는가? 아니라면 서버로 옮기거나, 지연하거나, 삭제하라.
여기서 주목할 것은 기술적 팁보다 사고방식이다. 성능 예산을 페이지가 느려진 뒤에 따지는 게 아니라 설계 초입에 제약으로 세운다는 발상, 번들 분석을 감각이 아니라 숫자로 대화한다는 태도, "use client" 한 줄을 계약서로 읽는 습관—이것들이 합쳐져야 Core Web Vitals 수치가 아닌 실제 사용자 경험이 달라진다. 2025 Web Almanac 데이터도 이를 뒷받침한다. 성능 격차는 여전히 기기 스펙 차이에서 가장 크게 벌어진다.
게이미피케이션이 제품 자체가 되는 순간
두 번째 글은 더 불편한 질문을 던진다. dev.to의 「I almost added streaks to my app. Then I remembered what Duolingo did to me.」에서 저자는 멘탈 웰니스 앱 SecondStep을 만들며 스트릭 시스템 도입을 거의 결정했다가 멈춘 이야기를 쓴다. 스트릭은 리텐션을 높이고, 리텐션은 성장을 만든다. 공식은 명확했다.
그런데 저자는 뒤를 돌아봤다. 듀오링고를 쓰다 어느 순간 독일어가 아니라 스트릭 자체를 지키기 위해 앱을 열고 있었다는 자각. 심지어 독일어 대신 체스 레슨을 해도 스트릭이 유지된다는 것을 발견하고 방향을 틀었다는 고백. 게이미피케이션이 조용히 제품 자체가 되어버린 순간이다. SecondStep의 타깃 사용자는 이미 과부하 상태인 사람들이다. 매일 앱에 출석해야 한다는 의무감은 도움이 아니라 또 다른 짐이 된다. 그래서 그는 스트릭을 뺐다. 알림도, 데일리 체크인도, 죄책감을 주는 푸시도 없다. 앱은 사용자가 필요할 때 조용히 거기 있을 뿐이다.
이 결정은 단순한 기능 삭제가 아니다. 사용자에게 진짜 도움이 되는가라는 프로덕트 질문을 리텐션 지표보다 앞에 놓겠다는 선언이다. 데이터 저장도 온디바이스로만 하고 계정도 만들지 않았다. 최악의 날 앱을 열면서 개인 정보를 건네야 한다는 부담을 주지 않기 위해서다. iOS는 일회성 구매로 출시했고, Android 수익화 모델은 아직 고민 중이다. 광고 기반은 답이 아니라고 확신하기 때문이다. 쉬운 선택지를 거부하는 이 태도가 윤리적 설계의 실체다.
소프트웨어의 Emacs화: AI가 바꾸는 프로토타이핑의 의미
세 번째 흐름은 방향이 다르다. GeekNews를 통해 소개된 「소프트웨어의 Emacs화」는 AI 에이전트 덕분에 개인용 네이티브 앱을 몇 시간 안에 만들 수 있게 된 세계를 묘사한다. 저자는 macOS용 Markdown 뷰어 MDV.app을 Claude와 함께 약 30분의 실질 상호작용으로 만들었다. App Store의 기존 뷰어들은 검색이 없거나, 인앱 구매를 요구하거나, 텍스트 복사가 안 됐다. 필요한 것을 찾는 대신 직접 만들었고, 그게 더 빨랐다.
이 글이 흥미로운 건 기술 자랑이 아니기 때문이다. 저자는 MDV를 설치해서 쓰라고 권하는 완제품이 아니라, Emacs 사용자가 반짝이는 .emacs 설정을 보듯 아이디어를 훔쳐 더 나은 것을 만들 대상으로 봐달라고 한다. Emacs 문화에서 오랜 사용자들이 elisp로 자신만의 불편을 해결하는 도구를 만들어왔던 것처럼, AI 에이전트는 이 문화를 Emacs 밖으로 밀어내고 있다. 화면과 입력에 접근할 수 있으면 네이티브 UI를 안정적으로 만들 수 있게 됐고, 그것은 더 이상 전문 개발자의 영역만이 아니다.
이 흐름에서 프론트엔드 개발자가 읽어야 할 신호는 이것이다. 빠른 프로토타이핑의 진입 장벽이 거의 사라진 세계에서, 코드보다 프롬프트가, 완성된 산출물보다 아이디어와 관찰이 더 중요해질 수 있다. 소스 코드를 자세히 읽는 것보다 "이런 것도 만들 수 있고 잘 작동한다"는 인사이트가 더 빠르게 전파된다. 단, Hacker News 댓글에서도 날카롭게 지적됐듯이 팀 협업과 코드 공유, 버전 관리의 새로운 문법은 아직 정착되지 않았다.
세 흐름이 수렴하는 한 가지 질문
번들 최적화, 윤리적 게이미피케이션, 소프트웨어의 Emacs화는 표면적으로 다른 이야기다. 그런데 세 글 모두 같은 압박 앞에 서 있다. AI와 프레임워크가 개발 속도를 극적으로 높일수록, 무엇을 만들 것인가와 왜 만드는가에 대한 판단은 온전히 인간의 몫으로 남는다는 것. 700KB 번들을 보내는 건 프레임워크가 아니라 설계 결정이다. 스트릭을 넣는 건 알고리즘이 아니라 프로덕트 판단이다. AI가 SwiftUI를 능숙하게 짜더라도 무엇을 짜게 할지는 여전히 사람이 정의한다.
AI 시대의 프론트엔드 개발자에게 필요한 것은 더 빠른 코딩이 아니다. 버튼 하나를 화면에 띄우기 전에 이 코드가 진짜 필요한가를 묻는 습관, 리텐션 지표 뒤에 숨은 사용자 부담을 읽어내는 감수성, 그리고 빠른 프로토타입이 가능해진 세계에서 어떤 문제를 풀 가치가 있는가를 먼저 정의하는 제품 감각이다. 도구가 빨라질수록 느려져야 하는 것은 바로 그 판단의 속도다.