HTML 우선 사이트를 구축해 하룻밤 사이 사용자를 두 배로 늘린 방법

2026-06-11 · 2026-06-11_html-first-site-doubled-users.md

#web-development #html-first #progressive-enhancement #accessibility #form-design #astro

원문 출처

HTML 우선 사이트를 구축해 하룻밤 사이 사용자를 두 배로 늘린 방법

한 줄 요약

영국 공기업의 온라인 신청 양식을 React SPA에서 HTML 우선 아키텍처로 바꾸자, 양식 완료자가 하룻밤 사이에 두 배로 늘어났다. 핵심은 "기술이 아닌 설계의 변화"였다.

배경과 문제

상황

저자 Alistair Davidson의 클라이언트는 영국 규제 독점 공기업이었다. 고객들이 서비스를 신청하려면 두 가지 방법 중 하나를 선택해야 했다.

  1. 웹사이트에 있는 오래된 ASP 양식
  2. 수동으로 처리하는 오프라인 절차

수동 절차는 회사에 더 비쌌다. 여기에 더해서, 이 회사는 규제 독점 기업이라 고객 만족도가 96% 아래로 떨어지면 수백만 파운드의 벌금을 물게 되는 상황이었다.

실패했던 이전 시도들

두 번의 실패가 있었다. 가장 최근 시도는 해외 계약업체가 만든 React 애플리케이션이었다. 이 앱은 출시 후 단 3일 만에 고객 불평 때문에 서비스에서 내려졌다.

React 앱이 문제였던 이유:

  • 로딩 스피너와 전역 JavaScript 상태가 엉망으로 얽혀 있었다
  • 접근성(Accessibility)이 전혀 고려되지 않았다. 스크린 리더 등 보조 기술 사용자들이 사용할 수 없는 수준이었다
  • 이미지 업로드가 양식의 핵심 기능인데, 이미지와 모든 양식 데이터를 localStorage에 저장하려고 했다. localStorage는 5MB 한도가 있어서 이미지 몇 장만 업로드해도 실패했다

저자가 이 코드를 보고 상사에게 "이걸 우리가 책임질 수 없다"고 말했다.

해결책: HTML 우선 아키텍처

네 가지 설계 원칙

저자가 세운 원칙은 다음과 같다:

  1. 이것은 공공 서비스다 — 모든 사람이 접근할 수 있어야 한다
  2. 가능한 모든 기기에서 작동해야 한다 — 최신 스마트폰뿐 아니라 오래된 기기, 낮은 사양의 기기에서도
  3. 네트워크가 나빠도 작동해야 한다 — 3G 연결이나 신호가 약한 곳에서도
  4. 한 번 입력한 데이터는 절대 잃지 않는다 — 사용자가 중간에 끊겨도 다시 시작하지 않게 한다

Terence Eden의 PSP 이야기

저자는 GOV.UK(영국 정부 웹사이트)를 만들었던 Terence Eden의 이야기를 인용한다. 런던의 주택 수당 사무소에서, 가재도구가 캔버스 가방에 담긴 젊은 여성이 PlayStation Portable(PSP) 게임기에서 GOV.UK 웹사이트를 보고 있었다. PSP 브라우저는 성능이 매우 나쁘다. 메모리가 부족하고, 탭을 3개까지만 열 수 있다. 하지만 GOV.UK는 단순한 HTML로 만들어져 있어서 PSP에서도 완벽하게 작동했다.

이 이야기가 저자에게 준 교훈: 웹은 모든 사람을 위한 것이다.

기술적 요구사항

  • 각 세션에 고유 ID 부여
  • 양식 마법사(단계별 양식)의 각 단계마다 데이터를 백엔드에 저장 (이미지 포함)
  • JavaScript 없이도 양식 완료 가능
  • 오래된 브라우저에서도 작동
  • WCAG AA 접근성 표준 준수
  • JavaScript와 현대 CSS는 경험을 향상시키기 위한 선택적 추가 요소

아키텍처: Astro + 단계별 페이지

프레임워크로 Astro를 선택했다. Astro는 서버 사이드 렌더링을 기본으로 하며, JavaScript를 필요할 때만 보내주는 프레임워크다.

양식 마법사의 각 단계가 별도의 HTML 페이지다. 사용자가 "다음"을 누르면:

  1. 표준 HTTP POST로 폼 제출
  2. API가 데이터 유효성 검증
  3. 유효하면 다음 단계 페이지로 리다이렉트

이 패턴을 저자의 동료들에게 설명하는 데 시간이 걸렸다. 모두가 클라이언트 중심 웹 애플리케이션(SPA, Single Page Application)에 익숙해져서, "폼 제출과 리다이렉트"라는 웹의 기본 개념을 설명해야 했다.

저자는 이렇게 말한다: "사용자가 새로 건축되는 주택 단지 한가운데 서서, Tesco에서 산 10년 된 안드로이드 폰을 들고 있을 수도 있다. 폼 하나 보여주기도 전에 20MB의 JavaScript를 보내주는 것은 터무니없는 일이다."

폼 검증: 1KB짜리 웹 컴포넌트

React 검증 라이브러리 때문에 팀들이 몇 달을 낭비하는 것을 보았다. 저자는 브라우저에 내장된 HTML 검증 기능을 활용하는 커스텀 웹 컴포넌트를 만들었다.

validation-enhancer라는 웹 컴포넌트:

  • 표준 HTML 폼을 감싸서 작동
  • 브라우저의 기본 HTML 검증( required, type="email" 등)을 활용
  • 브라우저의 팝업 대신 aria-describedby(또는 aria-errormessage)를 통해 접근성 있는 에러 메시지 표시
  • 타이핑 중 유효해지면 에러 즉시 제거
  • 포커스 이탈(blur)과 제출(submit) 시 다시 검증
  • 크기는 1KB 미만
  • JavaScript가 실패하면 브라우저 기본 검증으로 폴백
  • 그마저 실패하면 백엔드 API가 검증
<validation-enhancer>
  <form>
    <label for="my-email">Email</label>
    <input type="email" name="my-email" aria-errormessage="my-email-error" required />
    <div id="my-email-error"></div>
    <button type="submit">Submit</button>
  </form>
</validation-enhancer>

이 컴포넌트를 npm 패키지로 공개했다: validation-enhancer

결과

  • 양식 완료자가 출시 당일 두 배로 증가
  • 분석 팀이 이 사용자들이 어디서 왔는지 몰랐다. JavaScript 기반 분석 도구는 JavaScript 실패로 이탈한 사용자를 볼 수 없었기 때문이다
  • 백엔드 세션 전략이 효과 입증: 한 사용자는 시작한 지 한 달 만에 양식을 완료했다. 데이터는 전혀 손실되지 않았다

비극적인 에필로그

계약 기간이 끝나고 저자가 떠났다. 후임자에게 "JavaScript 없이도 항상 작동한다"고 설명했더니, 후임자는 충격적으로 말했다: "그런데 그게 우리한테 훨씬 더 많은 일인데."

커뮤니티 반응 (Hacker News)

HN에서 1006점, 463개 댓글로 뜨거운 반응을 보였다. 주요 논점을 정리한다.

1. "단순함이 낫다" vs "설계가 낫다"

가장 핵심적인 논쟁이다.

onion2k: "이건 'React 앱을 HTML 폼으로 바꿨더니 성능이 좋아졌다'가 아니다. '나쁜 웹페이지를 좋은 웹페이지로 바꿨더니 성능이 좋아졌다'다. React로도 훌륭한 UX를 만들 수 있고, 순수 HTML로도 끔찍한 사이트를 만들 수 있다. 개선의 핵심은 기술이 아닌 설계 변경이다."

arnorhs: "이 글을 '순수 HTML이 React보다 낫다'는 프레임으로 읽는 것은 잘못이다. React에서도 브라우저 기본 HTML 검증을 쓸 수 있고, 모든 것이 React에서 더 복잡해지는 것은 아니다. 문제는 오프쇼어 개발팀이 불완전한 지식으로 빠르게 복잡한 솔루션을 만드는 인센티브 구조다."

이 관점은 중요하다. HTML 우선이 마법인 것이 아니라, 사용자 중심 설계가 마법이다.

2. 웹 개발의 퇴행에 대한 한숨

LoganDark: "'폼 제출과 리다이렉트' 개념을 동료들에게 설명하는 데 시간이 걸린다는 사실이 너무 슬프다"

ezbie: "이 글이 쓰여져야 한다는 사실 자체가 웹 개발 전체가 얼마나 어리석게 변했는지 증명한다"

0xpgm: "10년 넘게 진행해오던 점진적 향상(Progressive Enhancement)을 다시 발견하게 될 거라고 말하지 마라. VC 돈과 빅테크 영향력이 JS 생태계를 일부에서는 더 나쁘게 만들었다"

abraxas: "이 혁신의 책임은 소셜 미디어 회사들에게 있다. 그들은 사용자를 자신의 폐쇄 생태계에 가두기 위해 이런 패턴을 도입했고, 나머지 산업은 레밍처럼 따라왔다. 소프트웨어는 패션 산업이다"

3. 접근성과 포용성에 대한 감정적 반응

ThomW: "PSP 이야기를 읽다가 눈물이 났다. 기술 수준이 낮은 사람들은 삶을 누리는 데 불공평한 대우를 받는다는 게 너무 슬프다"

ninalanyon: "Terence Eden의 인용문이 거의 울릴 뻔했다. 사실 글 전체가 그랬다"

motoboi: "60대 사람들은 컴퓨터의 내부 모델을 가지고 있지 않다. 버튼을 누르면 뒷단에서 무언가가 작동한다는 것을 이해하지 못한다. 화면에 보이는 게 전부다. '다음'을 누르고 아무 반응이 없으면 사이트가 고장 난 것이라고 생각한다. 그들은 싸우지 않고 즉시 포기한다"

xzhenis: "저자의 아빠는 64세다. 코로나 때 약을 받기 위해 의사에게 이메일을 보내야 했는데, 이메일 주소가 WhatsApp으로 온 종이 사진이었다. 컴퓨터 친화도가 낮은 사람들의 현실을 많은 개발자가 모른다"

4. 실제 사례: YouTube와 아프리카

butterfi: "YouTube가 새로운 HTML 플레이어를 도입했을 때, 갑자기 아프리카 농촌 지역에서 모든 트래픽이 몰려왔다. 크기가 중요하다"

이 사례는 저자의 주장과 정확히 일치한다. JavaScript 무거운 사이트를 가볍게 바꾸면, 개발자가 생각지도 못했던 지역의 사용자들이 나타난다.

5. 비판적 시각

miki123211: "2026년에 JavaScript를 지원하지 않는 브라우저를 쓰는 사람이 얼마나 될까? 1% 미만일 것이다. 그런 기기들이 현대 TLS 인증서도 지원할까? 이 논리로 가면 평문 HTTP도 써야 하는가?"

regnull: "제목이 오해의 소지가 있다. '사용자가 두 배로 늘었다'가 아니라 '양식을 완료한 사람이 두 배로 늘었다'"

fd-codier: "좋은 클릭베이트 제목이다"

tgtweak: "몇 번 채용하면 다시 React 앱으로 대체될 거다"

6. 대안과 실제 기술 스택

7xmohamed: "내 앱 대부분은 이제 HTMX + Go + SQLite다. 대부분의 프로젝트에 충분하다"

ecshafer: "React, Angular, Vue, Rails ERB, Rails Hotwire, HTMX 모두 사용해봤다. HTML 우선 웹사이트가 정답이라고 생각한다. Rails Hotwire + View Components가 개발도 빠르고 재사용도 쉽다"

qsort: "React 사용자들을 위한 친절한 알림: 컴포넌트를 HTML로 렌더링해서 사용자에게 제공할 수 있다. 비슷한 제약 조건이 있던 프로젝트에서 .tsx 파일로 UI 모델을 관리하고, 브라우저에는 순수 HTML만 보냈다"

7. 시스템적 문제

bandrami: "관리자가 되면서 이 문제가 자기 강화(self-reinforcing)된다는 것을 이해하게 되었다. 모든 지원자가 React만 알고 있고, React 없이 간단한 프론트엔드를 만드는 법을 모르면, 설계가 나쁘다는 것을 관리자가 이해해도 React를 써야 한다. 대체할 사람을 채용해야 하기 때문이다"

yesco: "중요 인프라를 책임지는 사람들이 싸고 경험이 없는 소프트웨어 엔지니어들만 고용하는 게 정말 아쉽다. 심장마비 때 심장 전문의 대신 레지던트 간호의에게 의존하는 것과 같다"

새로운 시각

1. 분석 도구의 맹점: 보이지 않는 사용자

JavaScript 기반 분석 도구는 JavaScript가 실패한 사용자를 볼 수 없다. 즉, 문제가 있는 사이트는 그 문제를 측정할 수 없다. 이는 의료에서 "진단 도구가 질병을 감지하지 못하면 그 질병이 존재하지 않는다고 결론 내리는 것"과 같은 오류다. HTML 우선으로 바꾸어서야 비로소 "보이지 않는 사용자"들이 나타났다.

2. 기술 민주화의 역설

웹은 원래 누구나 접근할 수 있는 매체였다. 하지만 2010년대 중반부터 SPA(싱글 페이지 애플리케이션)와 JavaScript 프레임워크가 주류가 되면서, 웹은 점점 더 "최신 기기 + 빠른 네트워크 + 최신 브라우저"를 전제로하는 공간이 되었다. 이는 기술 발전의 역설이다. 도구가 강력해질수록 오히려 배제되는 사람이 늘어났다.

3. "점진적 향상"의 부활

점진적 향상(Progressive Enhancement)은 2000년대 초반부터 알려진 개념이다. 기본 기능은 HTML/CSS로 제공하고, JavaScript는 경험을 향상시키는 선택적 추가 요소로 사용하는 접근법이다. 이 개념이 잊혔다가 다시 부활하고 있다는 것은, 웹 개발 커뮤니티가 자정(self-correction) 능력을 가지고 있다는 증거다.

자녀와 미래에 대한 시사점

아인, 석현, 은한이 웹 개발을 전공할 때

  • 기본기를 먼저: HTML/CSS/JavaScript의 기본을 이해한 후에 프레임워크를 배워야 한다. 프레임워크가 기본을 대체하는 것이 아니라 보완해야 한다
  • 사용자 공감이 핵심: 기술적 화려함보다 "누가 이 제품을 사용할까"를 먼저 묻는 습관
  • 단순하게 만드는 것이 훨씬 어렵다: 복잡한 것을 만드는 것은 쉬운데, 단순하게 만드는 것이 훨씬 어렵다. 이는 모든 분야에 적용되는 원칙이다

의료 분야에 적용하면

의료 소프트웨어도 같은 원칙이 적용된다. 병원에서 쓰는 시스템은 오래된 컴퓨터, 느린 네트워크, 다양한 사용자(의사, 간호사, 환자)를 모두 지원해야 한다. JavaScript 무거운 웹 앱을 병원에 도입하면, 실제 진료 현장에서는 작동하지 않을 가능성이 높다.

관련 노트