Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add new article #137

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file added public/2406030.jpg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
40 changes: 40 additions & 0 deletions src/content/blog/2406030.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
---
pubDate: "2024-06-03"
title: "Web에 대한 짧은 생각"
description: "미래의 어플리케이션은 어떤 모습일까요?"
heroImage: "/2406030.jpg"
---

# 앱 스토어는 지루해

알리페이 미니앱에 대해 들어보셨나요? 슈퍼앱인 알리페이가 제공하는 SDK를 바탕으로, 앱 스토어에 단독 앱을 제출하는 대신 알리페이에서 구동되는 작은(mini) 앱을 개발하는 것입니다. 이를 통해 알리페이의 거대한 사용자 층을 이용하는 전략을 마련할 수 있고, 또 알리페이에 이미 잘 구현된 여러 결제 등의 시스템 이점도 활용할 수 있게 됩니다.

이러한 흐름은 제 생각엔, 앱 스토어의 의미가 예전에 비해 많이 퇴색되었기 때문이지 않나 싶습니다. 기억하건대 오래 전 스마트폰이란 개념이 시장에 처음 출현했을 때는, 스토어를 장악한 앱이 그다지 많지 않았습니다. 앱을 설치하고 삭제하는 일은 매우 자유롭고 또 흥미로운 일이었죠. 하루가 다르게 새롭고 신기한 앱이 쏟아져 나오고, 앱 스토어의 메인 화면엔 언제나 놀라운 앱들이 가득했습니다. 지금은 어떤가요? 마지막으로 전혀 새로운 앱을 설치해본 적이 언제인가요? 우리들의 스마트폰에 설치되는 앱은, 이제 어쩌면 조금 뻔해졌습니다. 거의 모든 사람들의 폰에는 구글이나 네이버 같은 플랫폼 기업의 앱 몇개(유튜브 같은 것도 포함되겠죠), SNS 몇개, 그리고 업무나 개인적인 목적으로 사용하는 몇 가지 생산성 앱이 전부입니다. 대부분 비슷하다고 생각해요. 테크 산업에 관심이 많은 사람들 몇몇을 제외하면 앱 스토어는 그 방대한 등록된 앱의 수가 무색할 만큼, 그렇게 자주 들어가볼 만한 공간은 아니게 됐습니다. 이미 기존의 앱들로 스마트폰을 활용하는 거의 모든 방법이 가능해졌거든요.

게다가 이제 운영체제를 만드는 구글과 애플도 사실상 서드파티에 가까운 어플리케이션 개발에 적극적으로 바뀌었습니다. 저는 iPhone을 사용하니 이쪽을 기준으로 생각해본다면, 일기 앱과 Freeform이 있을 것 같아요. 이 둘이 얼마나 잘 만들어졌는가는 차치하고, 시장에 이미 같은 목적을 위한 서드파티 앱이 존재하고 있음에도 불구하고 OS에서 자체적으로 이러한 앱들을 제공한다는 사실은 제게 무언가 중요한 점을 의미하는 것 같습니다. 뻔해졌다는 거죠. 스마트폰을 할 만한 일은 지난 10년 간 거의 다 실험되었고, 가능하고 유용한 것과 그렇지 않은 것들이 적절히 평가되었습니다. 그러니 이제 애플이 나서서 일기 앱을 만드는 건 리스크를 감수하거나 쓸모없는 일에 시간을 벌이는 행위가 아닙니다. 오히려 그런 기초적인 앱이 내장형으로 제공되지 않는다는게 이상하다고 생각하는게 맞겠죠.

# 그럼 웹은?

웹은 어떨까요? 아시다시피 웹은 이 시장의 흐름을 완벽하게 주도하는 회사가 없습니다. 물론 기술적으로는 있지요. 특히 구글은 웹 시장에선 단연 독보적인 위치에 있습니다. 이 글을 읽고 계신 분들 중 Chrome이 아닌 다른 브라우저로 접속하시는 분이 얼마나 될지 모르겠네요. 아마 이름이 Chrome이 아니더라도, 거의 대부분의 브라우저는 Chrome 기반의 브라우저일 겁니다. 가깝게는 Edge, 멀게는 Brave나 Arc까지도요. Chrome의 V8은 Node.js에도 이식되어 있고 마찬가지로 Node.js는 서버 사이드 JS에서 단연 완벽한 승자로 자리매김하고 있습니다.

하지만 웹을 활용한 어플리케이션 시장 그 자체는 상황이 조금 다릅니다. 웹 어플리케이션을 만드는 일은 그 누구에게도 허가받을 필요가 없어요. 그리고 웹 브라우저가 존재하는 환경이라면 그 어디서든 접근할 수 있습니다. 여러가지 문제점이나 비판들 이전에, 이 특성은 그 어떤 플랫폼도 영원히 빼앗지 못할 웹만의 성좌같은 것이라고 생각합니다. 다르게 말하자면 어떤 플랫폼이든 이러한 특성을 의도한다면, 그건 사실상 또다른 웹을 창조하는 일이 되는 것이라고 생각해요. 물론 규모는 다를 수 있겠지만요. Server Driven UI 같은 재밌는 기술도 사실 어떻게 보면 경량, 혹은 특정 도메인에 최적화된 변종 웹으로 취급할 수 있다고 생각합니다.

## 문서를 앱으로

웹 기술은 근본적으로 문서에서 출발했습니다. 하나의 컴퓨터에 저장된 문서를 다른 컴퓨터에서도 읽을 수 있도록, 네트워크로 연결하고 (또 이후엔) 하이퍼링크를 통해 문서와 문서를 연결하는 형태가 되었습니다. 그리고 이것은 30년이 넘게 지난 오늘날에도 변함이 없습니다. 웹 페이지는 문서이고, 문서와 문서는 하이퍼링크로 연결됩니다. 이게 전부에요. 브라우저는 문서의 위치(=url)을 통해 문서의 내용을 가져오고, 하이퍼링크에 달린 또 다른 위치(=url)로 사용자가 원할 때 보내줍니다. 기술적으로 보아도 iOS나 Swift에서 화면을 View, Activity로 부르는 것과 달리 웹에는 (딱히 동등한 위치의 단어가 없기도 하고) document라는 이름으로 비슷한 개념을 칭한다는 것이 웹의 "문서"라는 본질을 아주 잘 드러내고 있다고 생각합니다.

문서는 어플리케이션과는 다릅니다. 문서는 정보를 전달하기만 합니다. 사용자와 상호작용하지 않죠. 어플리케이션은 사용자와 상호작용하여, 그 컨텐츠를 필요하다면 실시간으로 바꾸고 입력을 받고 또 다른 결과를 출력하는, 아주 유기적인 제품입니다. 예전의 어플리케이션은 사용자끼리 직접 만들고 설치하던 것에서 출발해서, 이제 우리가 현실의 가게에서 물건을 구입하듯 전용의 마켓을 통해 인증된 어플리케이션을 설치하고 또 큐레이팅 받는 모습으로 대단히 많이 진화했습니다. 동시에 웹은 어플리케이션을 구현하는 또 다른 공간이 되었습니다. 지난 10년 간 웹 어플리케이션은 기술의 발전과 함께 폭발적으로 증가하였고, 이제 네이티브 어플리케이션과 크게 차이가 없는 경험을 곧잘 제공할 수 있게 되었습니다.

물론 모든 웹 페이지가 어플리케이션이 될 필요는 없습니다. 저는 오히려 이러한 선택 가능함이 웹의 장점이라고 생각합니다. 단순히 정보를 전달하기만 할 뿐이라면, 크게 힘들이지 않고 간단한 웹 페이지를 만들면 됩니다. 사용자와 긴밀한 상호작용이 필요하다면, 이미 너무나도 잘 개발되어 있는 어플리케이션 프레임워크를 활용하면 됩니다. 웹의 한계는 기술의 한계가 아닌 상상력의 한계라고 해도 과언이 아닌 것 같아요.

### 인터렉션과 애니메이션

적어도 제 기준에선 가장, 가장 치명적인 문제입니다. 물론 예전에 비하면 정말 많이 좋아졌습니다. 하지만 페이지 간 이동이나 스크롤 기반의 애니메이션을 구현하는 일은 여전히 상당히 고통스럽습니다. 왜냐면 OS 레벨에서 지원해주는 게 거의 없기 때문이죠. Swift나 Kotlin으로 SDK를 이용해 앱을 개발할 땐, 이러한 인터렉션을 (상대적으로) 간단하고 유려하게 구현할 수 있습니다. 물론 메모리에 대해 좀 더 까다롭게 신경쓰긴 해야겠지만, JS에서는 애초에 고민할 만한 여지가 그다지 많지 않다는 점이 다소 아쉬운 것 같아요. 다행인 점은 브라우저가 이러한 구현을 전담해주려는 움직임이 있고, 최근엔 애니메이션과 관련된 새로운 기능 및 표준이 계속해서 만들어지고 있습니다. 그나마 문제 삼을 수 있는 지점은 OS에서 기본으로 제공하는 컴포넌트를 사용할 수 없다보니 아주 심리스한, 마치 기본 제공되는 앱인 것처럼 차이를 느낄 수 없는 앱을 개발하기 어렵다는 점이 있을 것 같은데요. 애당초 이런 목적은 웹으로 달성할 만한 것이 아니기도 하므로 넘어가겠습니다.

### 로딩, 로딩, 로딩...

웹이 가진 가장 강력한 무기이자 동시에 가장 치명적인 약점이 바로 로딩입니다. 물론 요즘 세상에 로딩이 없는, 네트워크를 사용하지 않는 어플리케이션은 사실상 없습니다. 하지만 네이티브 어플리케이션은 데이터만 로딩하면 됩니다. 화면을 그리는데 필요한 기초적인 요소는 이미 갖고 있고, 받아와야 하는 데이터는 사용자가 누구인지, 계좌에 얼마가 남았는지 등 입니다. 하지만 웹은 화면부터 가져와야 합니다. 다시 말해, 제아무리 빠른 네트워크에서 제아무리 작게 압축된 어플리케이션을 가져온다고 해도 사용자의 화면이 텅 빈 시간을 0으로 만들 수는 없습니다. Service Worker, Prefetching, Edge computing 등 이런 빈 화면을 마주하고 있는 시간을 단축하려는 온갖 기술이 쏟아져 나오고 있습니다. 하지만 어플리케이션의 그것에는 여전히 한참 모자라다고 생각합니다. 근본적으로 그럴 수 밖에 없죠.

## 웹을 받아들이는 방식

앞에선 웹 기술 그 자체의 장점과 한계에 대해 간단히 이야기 해보았습니다. 그렇다면 웹을 "사용"하는 방식은 어떨까요? 브라우저도 마찬가지로 지난 30년간 특별히 변한게 없습니다. 기껏해야 탭과 확장프로그램 정도가 가장 혁신적인 개념이 아니었을까요? 둘 모두 브라우징 생산성을 상당히 많이 올려주었지만 웹을 이해하는 우리의 시각 자체를 바꾸지는 않았습니다. 탭은 겨우 여러 페이지를 동시에 띄우는 기능이고, 확장 프로그램은 웹이 아니라 웹 옆에서 무언가 다른 동작을 구현해주는, 말 그대로 "확장"일 뿐입니다. "재구축" 프로그램이 아니니까요.
Loading