본문으로 건너뛰기
피드

나는 앱 안 깔아, 웹이면 충분한데 왜 자꾸 강요하는 건데

frontend 약 5분
vote
0
댓글
북마크

웹에서 잘 되는 서비스를 굳이 앱으로 써야 하는 현실에 대한 개발자의 비판. 대부분의 앱은 JSON 렌더링하는 씬 클라이언트일 뿐인데 100MB+ 설치와 권한을 요구하고, 크로스플랫폼 프레임워크로 만든 앱 퀄리티도 네이티브에 못 미침. 웹 사용자를 앱으로 몰아넣는 엔시티피케이션 루프의 구조적 문제를 지적함.

  • 1

    브라우저에서는 유저스크립트·광고차단 등으로 사용자가 UI를 통제 가능하지만, 앱은 다크패턴의 온상

  • 2

    대부분 앱은 API에서 JSON 받아 렌더링하는 씬 클라이언트에 불과한데 과도한 권한과 용량을 요구

  • 3

    Flutter 등 크로스플랫폼 앱의 미묘한 네이티브 불일치가 사용자 경험을 해침

  • 4

    웹에서 사용자 모은 뒤 의도적으로 웹 버전을 망가뜨려 앱으로 유도하는 엔시티피케이션 루프

  • "앱 깔아주세요"에 질린 한 개발자의 반격 — 브라우저에서 잘만 되는 서비스를 왜 굳이 앱으로 써야 하는지에 대한 날카로운 비판

    • 소셜 미디어는 물론이고 주차, 음식 주문 같은 기본적인 서비스까지 앱 설치를 강요하는 추세
    • 화면 절반을 덮는 "앱 다운로드" 모달, 스크롤하면 뜨는 팝업, "앱이 10배 낫다"는 헤더 — 수법도 점점 노골적
  • 브라우저에서는 사용자가 왕인데, 앱에서는 포로가 됨

    • 다크모드 없는 서비스? 유저스크립트 하나면 해결. 레딧 사이드바에 게임 섹션 생겼다고? 확장 프로그램으로 2초 만에 제거
    • 유저스크립트, 광고 차단기, 커스텀 확장 — 브라우저에서는 사용자가 UI를 통제할 수 있음
    • 반면 앱은 다크패턴의 블랙홀. 푸시 알림 남발, 침습적 텔레메트리 수집, 월드가든에 가두기 — 이 모든 게 "더 나은 UX"라는 포장 아래 진행됨
  • 대부분의 앱은 그냥 텍스트와 미디어를 보여주는 씬 클라이언트에 불과함

    • 3D 게임이나 LiDAR 같은 하드웨어 깊은 통합이 필요한 경우를 빼면, 결국 API에서 JSON 받아서 네이티브 뷰에 렌더링하는 게 전부
    • 레스토랑 메뉴 보려고 100MB+ 앱 깔고, 위치 권한 주고, 백그라운드 프로세스 돌리는 게 말이 되나?
  • 그렇게 강요하는 앱이 좋기라도 하면 모를까, 퀄리티도 별로임

    • 초기 Flutter 앱의 iOS 셰이더 컴파일 버벅임을 겪어본 사람은 알 거임 — Skia 엔진에서 Impeller로 교체되기 전까지 첫 애니메이션에서 UI가 끊기는 문제가 있었음 (2023년쯤 수정)
    • 프리컴파일된 셰이더를 앱에 번들로 넣어서 배포해야 했을 정도
    • 스크롤 속도가 OS와 미묘하게 다르고, 스와이프 백 제스처가 몇 밀리초 망설이는 그 "언캐니 밸리" 느낌
    • 인간의 뇌는 타이밍이 어긋나는 걸 기가 막히게 감지함 — XZ 백도어도 SSH 로그인이 아주 살짝 느려진 걸 엔지니어가 알아채서 발견된 거고, FPS 게이머들은 한 발 쏴보면 서버 리전을 구별한다고

중요

> 대부분의 앱은 API에서 JSON 받아서 렌더링하는 씬 클라이언트일 뿐인데, 100MB+ 설치와 각종 권한을 요구함. 웹으로 충분한 서비스까지 앱을 강요하는 건 사용자 경험이 아니라 사용자 가두기가 목적.

엔시티피케이션(Enshittification) 루프

  • 웹에서 사용자 모으고 → 앱으로 몰고 → 광고로 수익화하는 3단계 패턴

    • 처음에는 오픈 웹에서 마찰 없이 사용자를 끌어모음 (검색 노출도 되고 링크 공유도 쉬우니까)
    • 사용자가 충분히 모이면 웹 버전을 의도적으로 망가뜨려서 앱 설치를 유도
    • 앱에 갇힌 순간 광고 차단기가 안 먹히는 피드 광고의 포로가 됨
  • PM 입장에서 웹 고수하는 유저는 "허용 가능한 손실"

    • 웹 버전 열화시켜서 80%를 앱스토어로 보내면 그 PM은 승진하고 연봉 올라감
    • 인센티브 구조가 이렇게 돌아가니 웹 경험에 투자할 이유가 없음
    • 브라우저는 한때 위대한 범용 플랫폼이었는데, 이제는 앱스토어를 위한 마케팅 퍼널 입구로 전락하는 중

ℹ️참고

> 엔시티피케이션(Enshittification)은 코리 닥터로우가 만든 용어로, 플랫폼이 처음엔 사용자에게 좋다가 점점 광고주와 주주 이익을 위해 사용자 경험을 희생하는 패턴을 뜻함.

프론트엔드 개발자라면 '우리 서비스도 이러고 있진 않나' 돌아볼 만한 글. 웹 퍼스트 전략이 사용자 신뢰를 지키는 길이라는 메시지가 강력함.

댓글

댓글

댓글을 불러오는 중...

frontend

요즘 픽셀 폰트가 그냥 복고 감성이 아닌 이유

1990년대 기기 화면 느낌을 현대 폰트 시스템으로 재해석한 픽셀 폰트 몇 가지를 소개한 글이다. 핵심은 예쁜 복고풍 글자 모양만이 아니라, 실제 제품에서 쓸 수 있게 기준선, 자간, 메타데이터, 세로 메트릭까지 챙기는지가 중요하다는 점이다.

frontend

HTML의 `<dl>`이 생각보다 쓸모 많은 이유

이 글은 HTML의 description list, 즉 `<dl>`, `<dt>`, `<dd>`가 단순 용어 사전용 태그가 아니라 이름-값 쌍 UI를 표현하는 꽤 강력한 시맨틱 도구라고 설명한다. 숙소 편의시설, 요금 내역, 기술 용어 설명, 게임 능력치표처럼 흔한 패턴을 중첩 `<div>` 대신 의미 있는 HTML로 만들 수 있다는 얘기다.

frontend

HTML을 캔버스 안에 넣는 데모 모음이 등장함

구글 크롬 랩스 저장소에 HTML-in-Canvas 관련 데모와 프레임워크 지원 목록이 정리됐다. Duck Hunt 스타일 폼, 흔들리는 버튼, 셰이더 기반 페이지 전환, 천처럼 매달린 폼 같은 실험적 예제가 포함돼 있고 Three.js와 PlayCanvas 쪽 샘플도 연결돼 있다.

frontend

싱글 페이지 앱이 웹을 너무 비싸게 만들었다는 불평

이 글은 싱글 페이지 앱(SPA)이 사용자 경험을 좋게 만든다는 명분 아래 웹의 초기 로딩 비용, 도구 복잡도, 개발 진입 장벽을 키웠다고 비판한다. 페이스북 로그인 페이지의 CSS 3.8MB, 레딧 몇 개 클릭 후 33MB 다운로드 같은 숫자를 들며, 지금의 프론트엔드 생태계가 사람보다 대기업의 요구에 맞춰져 있다고 주장한다.

frontend

네이티브로 끝까지 가려다 텍스트에서 막힌 macOS 개발자의 고백

20년 가까이 macOS와 iOS 네이티브 개발을 해온 작성자가 SwiftUI, AppKit, TextKit 2로 마크다운 채팅 UI를 만들다 결국 WebKit과 Electron 쪽이 훨씬 낫다는 결론에 도달한 글이다. 문제는 성능 하나가 아니라 선택, 스트리밍, 스크롤, 접근성, 텍스트 상호작용 같은 ‘사용자가 당연히 기대하는 기본기’가 네이티브 조합에서 계속 깨진다는 점이다.