676명의 개발자가 분노했다: 당신의 앱은 그저 웹페이지일 뿐

2026년 7월 9일, 영국 개발자 Dan Q가 화약내음이 감도는 제목의 글을 하나 올렸다. 「당신의 ‘앱’은 원래 웹페이지여도 됐다(그래서 내가 대신 고쳐놨다)」. 이 글은 Hacker News에서 676명의 개발자가 뜨겁게 토론하는 바람에, 댓글 420개가 달리며 앱 스토어 경제와 개방형 웹 사이의 그 얇은 막을 정통으로 뚫어버렸다.

사건의 시작은 아주 일상적이었다. Dan의 아이가 디즈니랜드에서 공연을 하는데, 여행사가 학부모들에게 “Travelbound”라는 휴대폰 앱을 반드시 설치해야만 일정을 확인할 수 있다고 했다. Dan이 그 앱의 용량을 확인해보니 설치 파일은 43MB, 깔고 나니 124MB까지 불어났다. 십수 년 경력의 베테랑 개발자인 그는 말도 안 된다고 느꼈다. 그저 시간표 하나 보고 싶은데, 슈퍼 마리오보다 큰 앱을 왜 내려받아야 하는가?

그는 개발자가 가장 잘하는 짓을 해버렸다. 리버스 엔지니어링이다.

124MB짜리 앱 안에는 대체 뭐가 들었나

▲ 바로 그 124MB짜리 Travelbound 앱이다. 하는 일이라곤 텍스트와 이미지, PDF 링크를 보여주는 것뿐. 출처: Dan Q 개인 블로그.

Dan은 패킷 분석 도구로 이 앱의 네트워크 트래픽을 가로챘고, 기가 막힌 진실을 발견했다. 이 앱이 하는 유일한 일은 사용자 이름과 비밀번호를 이어 붙여서 URL을 만들고, 서버에서 데이터 뭉치를 받아 화면에 띄우는 것뿐이었다.

구체적으로 말하면, 이 앱이 뒤에서 쓰는 로직은 이렇다.

https://travelbound.api.vamoos.com/api/itineraries/{사용자이름}-{비밀번호}

서버가 돌려주는 것은 커다란 JSON 형식의 데이터 — 일정 목록, 숙박 정보, PDF 다운로드 링크, 곁들임 이미지들이 담겨 있다. 그런데 이 내용은 그 자체로 HTML 형식으로 포장되어 있었다. 달리 말해, 이 앱의 서버 쪽에서는 이미 웹페이지를 만들고 있었던 셈이다. 다만 그 웹페이지를 124MB짜리 껍데기에 밀어 넣고서야 사용자에게 보여주었을 뿐.

▲ 가로챈 서버 응답 데이터. 일정 정보가 이미 HTML 형식으로 존재함을 볼 수 있다. 출처: Dan Q 개인 블로그.

그렇다면 124MB라는 부피는 대체 무엇으로 채워졌기에, 본질적으로 “웹뷰어”에 불과한 물건이 이리도 뚱뚱해졌을까? Dan이 밝혀낸 바로는, 이 앱이 웹페이지보다 더한 기능은 딱 두 가지뿐이었다.

1. 사용자의 Google 계정을 추적하여 사용 데이터를 여행사에 되돌려 보낸다
2. 광고를 푸시한다(공식 용어로는 “여행 영감”이라 부른다). 더 많은 일정을 사도록 유도하는 광고다

Dan의 표현은 더 직설적이었다. 이 두 가지는 “반기능(anti-feature)” — 사용자에게 백해무익한 것들이라고.

124MB에서 0.05MB로: 웹페이지 하나면 충분했다

Dan은 반나절을 들여 작은 Ruby 스크립트를 하나 짜서, 서버에서 주기적으로 최신 데이터를 긁어와 자동으로 순수 웹페이지 버전을 생성했다. 결과는 어땠을까?

• 앱 버전: 124MB(추적과 광고 포함)
• 웹 버전: 0.05MB짜리 HTML 페이지에, 선택적으로 내려받을 수 있는 이미지 일부(35MB, 그러나 받지 않아도 된다)

웹 버전은 비밀번호로 보호되며 원래 앱과 같은 계정을 쓴다. 화려한 인터페이스는 없지만, 복사·붙여넣기가 되고, 인쇄가 되고, 휴대폰에 저장되며, 어떤 기기에서든 열린다 — 그리고 이런 것들이 바로 원래 앱이 하지 못하는 일이었다.

▲ Dan이 직접 만든 웹 버전. 광고와 추적을 빼고 모든 핵심 정보를 남겼다. 출처: Dan Q 개인 블로그.

Dan은 마지막에 영혼이 담긴 질문을 던졌다.

“정말 앱으로 만들어야만 하는 앱도 분명 있다. Travelbound는 그 어느 쪽에도 속하지 않는다. 우리가 어떻게 이 지경까지 오게 됐는지 나는 이해할 수가 없다 — 소프트웨어 회사들이 굳이 스스로의 삶을 더 어렵게(그리고 더 비싸게: 앱 스토어에 올리는 건 만만치 않은 일이다!) 만들어가며, 더 적은 사람에게 더 적은 기능으로 HTML 콘텐츠를 밀어내기 위해 말이다.”

왜 이 지경까지 왔을까? 애플 경제학

Dan이 품은 의문의 이면에는 더 큰 문제가 숨어 있다. 웹페이지로 해결될 일을 개발자들이 굳이 앱으로 포장하는 까닭은 무엇인가?

Hacker News의 676명 토론 중 가장 추천을 많이 받은 댓글 하나가 핵심을 찔렀다 — 애플과 구글이 수십억 달러를 쏟아부어 일반 사람들들의 머릿속 모델을 재구성해, “휴대폰으로 무언가를 한다 = 앱을 쓴다”고 믿게 만들었기 때문이다.

생각해보라. 일반 사람들이 새 휴대폰을 손에 쥐었을 때 홈 화면에서 보는 게 무엇인가? 빼곡한 앱 아이콘들이다. 뭔가를 찾으려면? “앱 스토어”를 연다. 어떤 서비스를 쓰고 싶으면? “앱 없나?”

이런 “앱이 곧 전부”라는 인식은 본래부터 있던 것이 아니다. 지난 15년간, 두 거대 기술 기업이 진짜 돈을 태워가며 만들어낸 결과물이다.

그리고 그 이면의 동력은 돈 — 정확히 말해 그 유명한 **“애플 세금”**이다.

애플 세금: 30% 수수료 경제학

애플 앱 스토어를 통해 판매되는 앱이나 디지털 콘텐츠에 애플은 15%에서 30%의 수수료를 걷는다. 2024년, 앱 스토어 단일 항목만으로 애플이 거둬들인 수익은 850억 달러를 넘었다(애플 공시 자료와 Epic Games와의 소송에서 공개된 재무 데이터를 바탕으로 추산). 인터넷 업계 전반을 통틀어, 이토록 돈을 잘 버는 “톨게이트”는 찾아보기 힘들다.

그런데 웹페이지는? 웹은 개방적이다. 누구든 웹페이지 하나를 올리면 애플에 돈을 줄 필요도, 애플의 심사를 거칠 필요도 없이, 사용자가 브라우저로 바로 열면 그만이다. 서비스가 웹 형태로 존재한다면 애플은 한 푼도 벌 수 없다.

그래서 애플이 iOS에서 의도하든 아니든 웹 앱을 “쓰기 불편하게” 만드는 이유가 설명된다.

• 모든 iPhone용 브라우저는 반드시 애플의 WebKit 엔진을 써야 한다 — Chrome이나 Firefox라도 iPhone 위에서는 껍데기만 다른 Safari일 뿐이다. 2026년 6월, 마이크로소프트 엔지니어가 발표한 벤치마크 보고서에 따르면, iOS에서 Chromium 엔진의 구동을 허용한다면 브라우저 성능이 Safari보다 28.6% 높아질 수 있음을 보여줬다.
• 웹 앱(PWA)은 iOS에서 Face ID를 쓸 수 없고, 백그라운드 데이터 동기화가 안 되며, 푸시 알림이 심각하게 제한된다 — 이런 것들이 바로 많은 앱의 핵심 매력이다.
• Safari의 웹 표준 지원은 Chrome보다 수개월에서 수년 뒤처진다 — 개발자가 새 기술을 쓰고 싶으면, 미안하지만 애플이 따라올 때까지 기다려야 한다.

유럽에서는 「디지털 시장법(DMA)」이 이 상황을 풀려 애써왔고, 애플에 브라우저 엔진 제한을 풀도록 요구하고 있다. 하지만 애플의 대응 방식을 미국 판사는 “악의적 순응”이라 불렀다 — 겉으로는 규칙을 고쳤으나, 실제로는 경쟁사가 제대로 진입하지 못하게 일련의 기술 장벽을 쳐두었기 때문이다.

이 모든 것의 최종 효과는 무엇인가? 개발자는 앱 스토어라는 배에 “억지로” 태워지고, 사용자는 앱 아이콘만 알아보는 식으로 “길들여진다”.

논란의 다른 편: 어떤 상황에선 앱이 실제로 더 낫다

여기까지 읽고 나면, 필자는 꼭 짚고 넘어가야겠다. 이 글은 “앱 원죄론”이 아니다. HN 토론에서 상당수 개발자가 앱이 실제로 웹페이지보다 나은 상황을 지적했다.

OkayPhysicist라는 아이디의 개발자는 자신의 경험을 공유했다. 사내에 비용 정산과 문서 도구가 있어서, 이걸 모바일에 맞춘 웹 버전으로 만들었다. 그랬더니? 동료들이 뒤쫓아와 “웹사이트를 폰에 어떻게 넣냐?”, “웹사이트를 폰에서 어떻게 여냐?”, “앱으로 못 만들어주냐?”라고 물었다.

문제는 사용 습관에 있다. 대부분의 일반 사람들에게 “앱”은 이해되는 개념인 반면, “웹페이지”는 오히려 추상적이다. 브라우저 주소창에 URL을 직접 치게 하는 것보다, 알록달록한 아이콘 하나를 누르게 하는 게 훨씬 자연스럽다.

또 다른 개발자가 내놓은 의견도 타당했다. 하루에 열 몇 번씩 쓰는 서비스라면, 독립된 네이티브 앱이 브라우저에서 왔다 갔다 하는 것보다 확실히 편하다. 예를 들어 위챗, 알리페이, 지도 앱 — 이런 고빈도 사용 환경에선 앱의 성능 우위(더 빠른 반응 속도, 더 매끄러운 애니메이션, 오프라인 기능)가 실재한다.

그리고 웹 기술이 아직 커버하기 힘든 영역들도 있다.

• 고성능 게임: GPU 가속과 복잡한 3D 렌더링이 필요한 것
• AR/VR 앱: 카메라와 센서에 깊이 접근해야 하는 것
• 전문 오디오·비디오 편집: 실시간 처리와 하드웨어 코덱이 필요한 것
• 백그라운드에서 지속 실행되어야 하는 서비스: 운동 추적, 내비게이션 같은 것

이것들은 웹 기술의 합리적인 경계선이다. 필자는 모든 것이 웹페이지가 되어야 한다고 보지 않지만, 그렇다고 모든 것이 앱이 될 이유가 있다고도 보지 않는다.

본질적 문제: 기술 싸움이 아니라 권력 싸움

이 “앱 vs 웹페이지” 논쟁의 본질은 당신이 어떤 소프트웨어를 쓸 수 있는지를 누가 결정하느냐 하는 권력 다툼이다.

개방형 웹의 세계에서는, URL 하나로 서비스를 올릴 수 있고 브라우저가 곧 당신의 “앱 스토어”다. 당신의 콘텐츠를 심사하는 이도, 수익을 가로채는 이도, 당신 제품이 “상점에 오를지”를 결정하는 이도 아무도 없다.

앱 스토어의 세계에서는 애플과 구글이 문지기다. 그들은 무엇이 심사를 통과할지 결정하고(심사관 500명이 앱 200만 개를 관리한다), 얼마를 거둘지 결정하며(15%에서 30%), 당신의 앱이 폰의 어떤 기능을 쓸 수 있는지 결정한다. 사용자는 실제로 일정한 “안전 보장”을 얻는다 — 적어도 이론상으로는 앱 스토어 안의 물건들은 심사를 거쳤다 — 그러나 그 대가로 선택권을 잃는다.

이것이 Dan의 글이 676명을 분노하게 만든 깊은 이유다. 시스템 전체가 이렇게 설계되어 있다 — 본래 0.05MB짜리 웹페이지여야 할 것을 억지로 124MB짜리 앱으로 뭉쳐버리는 식으로. 그 여행 앱 자체가 나쁜 건 아니지만, 시스템이 그것을 뚱뚱한 길로 몰아넣은 것이다.

맺음말: 당신의 선택은 무엇인가?

Dan의 이야기는 따뜻한 끝맺음이 있다. 그는 손수 만든 웹 버전을 팀 동료인 다른 학부모들에게 나눠주었고, 사람들은 처음으로 그 뚱뚱한 앱을 안 깔아도 일정을 볼 수 있다는 걸 알게 됐다. 그의 딸이 디즈니 무대 위에서 노래하고 춤추는 동안, 그의 폰에서는 124MB짜리 추적기가 하나 줄어 있었다.

우리 일반 사람들에게 이 이야기가 주는 시사는 사실 간단하다. 다음에 누군가 뭘 보려고 앱을 내려받으라 할 때, 한마디 더 묻는 것이다: 이거 웹페이지면 안 되나?

왜냐하면 대부분의 경우, 답은 “된다”이기 때문이다.

---

참고 링크:

• Dan Q: 당신의 “앱”은 웹페이지여도 됐다(그래서 내가 고쳐놨다)
• Hacker News 인기 토론: 676개 댓글로 본 앱 vs 웹 심층 논쟁
• 마이크로소프트 엔지니어 벤치마크: iOS 브라우저, WebKit 제한으로 성능 28.6% 뒤처져
• 애플 WebKit 제한과 EU DMA 준수 논란 분석 보고서
• iOS상의 PWA 제한과 Safari 지원 현황(2026년 완전 가이드)
• 애플 30% 수수료 정책 변경: Epic Games 반독점 소송 이후 파장
• 앱 스토어 심사 제도 논란: 심사관 500명과 앱 200만 개의 실제 상황
• 개방형 웹 옹호 단체: 애플 브라우저 엔진 제한의 반경쟁적 영향