웹앱

Web App

도구

브라우저에서 주소를 열면 설치 없이 바로 쓰는 애플리케이션으로, 고친 코드를 올리는 즉시 모든 사용자가 새 버전을 씁니다.

등장 배경

소프트웨어를 쓰려면 먼저 설치해야 하던 시절이 있었습니다. 설치 파일을 내려받아 실행하고, 새 기능이 나오면 그 과정을 다시 밟았습니다. 만드는 쪽에는 이 구조가 세 가지 부담을 남겼습니다. 운영체제마다 설치본을 따로 만들어야 했고, 고쳐도 사용자가 받아 가기 전까지는 고쳐지지 않았고, 그래서 돌아다니는 버전이 동시에 열 개쯤 됐습니다.

지원 창구의 대화도 늘 같은 모양이었습니다. 고객이 "저장이 안 됩니다" 하고 적으면 담당자는 먼저 버전을 물어야 했습니다. 2.3에서 이미 고친 문제인데 고객은 1.9를 쓰고 있고, 업데이트를 안내하면 사내 전산 규정 때문에 못 받는다는 답이 돌아왔습니다.

브라우저가 화면을 그리고 계산까지 맡을 수 있게 되면서 다른 길이 열렸습니다. 프로그램을 사용자 컴퓨터에 내려놓지 않고 서버에 두고, 브라우저는 그것을 불러다 보여 주는 창으로만 쓰는 방식입니다. 설치가 사라지고, 고친 코드를 한 번 올리면 모든 사용자의 버전이 동시에 바뀝니다.

해결하는 문제

웹앱이 없애는 것은 사용자와 제품 사이에 놓인 설치라는 단계, 그리고 그 단계 때문에 생기던 버전 차이입니다.

  1. 데려오는 길이 짧아집니다. 링크 하나를 보내면 상대가 그 자리에서 제품을 열어 볼 수 있습니다. 설치 파일을 받고 경고창을 넘기고 재시작하는 과정에서 사람이 빠져나가지 않습니다.
  2. 버전이 하나로 유지됩니다. 금요일에 고친 것을 올리면 월요일 아침 모든 고객이 고친 화면을 씁니다. 설치형이라면 같은 수정이 고객사마다 몇 주씩 늦게 도착합니다.
  3. 운영체제별로 따로 만들지 않습니다. 한 벌을 만들면 윈도우와 맥과 리눅스에서 같은 것이 돌아갑니다.
  4. 공유가 제품 안에서 끝납니다. 문서 주소를 보내면 받은 사람이 같은 화면을 보고, 그 사람에게 설치를 요구하지 않습니다.

페이지덱이 이 형태를 고른 이유도 2번과 4번입니다. 문서를 함께 쓰는 제품이라 링크를 받은 사람이 곧바로 열어야 하고, 오류를 고친 날 모든 팀이 같은 버전을 써야 합니다.

대안

다른 형태를 고르는 이유는 대개 웹앱이 못 하는 세 가지 때문입니다. 인터넷이 끊기면 멈추고, 작은 화면에서 쓰기 불편하고, 카메라나 알림처럼 기기에 붙은 기능에 손이 잘 닿지 않습니다.

  1. 모바일 앱은 휴대폰에 설치해 쓰는 형태입니다. 알림을 보낼 수 있고 첫 화면에 아이콘이 남아 다시 열릴 확률이 높습니다. 대신 새 버전마다 앱 장터의 심사를 받고 결제액의 일부를 떼어 줘야 합니다.
  2. 데스크톱 앱은 PC에 설치해 쓰는 형태입니다. 기기 성능을 온전히 쓰고 하드디스크의 파일을 직접 다뤄야 하는 영상 편집이나 코드 작성 도구가 여기 남아 있습니다.
  3. 브라우저 확장은 브라우저에 덧붙어 남의 웹사이트 위에서 동작하는 프로그램입니다. 사용자가 이미 일하고 있는 화면 안으로 들어간다는 점이 다릅니다.
  4. API 제품과 SDK는 화면을 아예 두지 않습니다. 전자는 다른 프로그램이 주소로 요청을 보내 결과를 받아 가는 통로이고, 후자는 남의 앱 안에 끼워 넣어 함께 돌아가는 개발 도구 묶음입니다. 사용자가 사람이 아니라 다른 시스템이면 이쪽입니다.

웹앱과 모바일 앱 사이를 메우는 중간 형태도 있습니다. PWA는 웹으로 만든 것을 홈 화면에 설치하고 알림도 받을 수 있게 포장한 방식으로, 한 벌로 양쪽을 덮고 싶을 때 먼저 검토합니다.

플랫폼과 마켓플레이스는 같은 갈래에 묶여 있지만 웹앱의 대안은 아닙니다. 전자는 남의 서비스가 그 위에 얹히는지, 후자는 파는 쪽과 사는 쪽을 연결하는지를 가르는 말입니다. 설치 없이 구독해 쓰는 판매 방식을 가리키는 SaaS도 마찬가지여서, 기업에 구독으로 파는 웹앱이라는 문장 하나에 셋이 함께 들어갑니다.

실무 용례

"이건 웹앱으로 먼저 내고 모바일 앱은 다음 분기에 보죠."

설치 없이 링크로 퍼지는 쪽을 먼저 택해 반응을 보겠다는 뜻입니다.

"웹앱이니까 배포하면 바로 반영돼요. 고객사에 업데이트 안내는 안 나가도 됩니다."

버전 파편화가 없다는 점을 근거로 일정을 앞당기는 말입니다.

"휴대폰 브라우저에서 이 표가 깨지는데요. 웹앱이라고 아무 데서나 되는 건 아니잖아요."

브라우저에서 돌아간다는 것과 작은 화면에서 쓸 만하다는 것은 다른 이야기라는 지적입니다.

페이지덱은 웹앱 한 벌로 시작해 지금도 그것이 중심입니다. 민서가 좁은 화면용 배치를 따로 잡고, 태오가 사파리와 크롬에서 같은 동작이 나오는지 확인합니다. 지현은 기능 하나를 낼 때마다 이번 주에 올릴지 다음 주에 올릴지만 정하고, 어느 고객이 어느 버전을 쓰는지는 셈에 넣지 않습니다.

걸리는 자리는 판매 쪽에서 나옵니다. 수아가 만나는 기업 고객 가운데 자료를 외부 서버에 두지 못하는 곳이 있어 사내망에 설치해 쓰는 방식을 요구합니다. 그때는 형태를 다시 검토하지 않고 그 고객사 전용 설치본을 별도 계약으로 다룹니다.

흔한 오해

웹앱과 웹사이트를 같은 것으로 보는 경우가 가장 많습니다. 둘 다 브라우저에서 주소를 열어 보는 것이니 겉모습이 다르지 않습니다. 차이는 사용자가 무엇을 하느냐입니다. 웹사이트는 놓인 것을 읽는 자리이고, 웹앱은 사용자가 무언가를 만들고 고치고 저장해 그 결과가 남는 자리입니다. 그래서 로그인과 권한과 저장 실패 처리가 필요하고, 화면 수가 같아도 만드는 양이 다릅니다. 이 둘을 섞으면 회사 소개 페이지를 만드는 일정으로 문서 편집기를 약속하게 됩니다.

브라우저에서 돌아가니 아무 기기에서나 잘 될 것이라고 보는 오해도 흔합니다. 브라우저가 어디에나 깔려 있다는 사실 때문에 그렇게 읽히기 쉽습니다. 다만 브라우저는 종류마다 버전마다 다르게 그리고, 화면 폭이 좁아지면 표와 여러 단 배치가 먼저 무너집니다. 설치본을 만들지 않는 대신 어느 브라우저의 어느 버전까지 받아 줄지를 정하고 그 조합을 시험해야 합니다. 이 목록을 정해 두지 않으면 사파리에서만 깨지는 화면을 고객이 먼저 발견하게 됩니다.

같이 보면 좋은 페이지

  • 제품 형태

    여덟 가지 형태가 어떤 기준으로 갈리는지 보면 웹앱의 자리가 분명해집니다

  • 모바일 앱

    가장 자주 함께 검토되는 형태여서 둘을 나란히 읽으면 선택 기준이 잡힙니다

마지막 업데이트 2026-09-16