HTML 우선 사이트로 전환했더니 신청 완료자가 하룻밤 사이 2배가 된 이야기

• 한 유틸리티 회사가 고객 신청 폼을 HTML 우선 구조로 다시 만들었더니, 출시 직후 폼 완료자가 말 그대로 2배가 됨

  • 회사는 규제받는 독점 사업자였고, 고객 만족도가 약 96퍼센트 아래로 떨어지면 수백만 파운드 벌금까지 맞을 수 있는 상황이었음
  • 고객은 온라인 신청 폼을 쓰거나 더 비싼 수동 절차를 따라야 했는데, 기존 디지털 폼이 계속 문제를 일으키고 있었음

• 이전 시도는 꽤 처참했음. 특히 가장 최근의 React 앱은 온라인에 올라간 지 3일 만에 고객 불만 때문에 내려감

  • 작성자가 본 React 앱은 로딩 스피너와 전역 자바스크립트 상태가 뒤엉킨 구조였고, 접근성도 맞지 않았음
  • 더 큰 문제는 이미지 업로드가 필수인 폼인데, 이미지와 폼 데이터를 전부 로컬 저장소에 넣으려 했다는 점임
  • 로컬 저장소는 보통 5메가바이트 제한이 있어서, 이런 신청 폼의 핵심 저장소로 쓰기엔 애초에 무리였음

• 새 버전은 Astro로 만들었고, 핵심 원칙은 자바스크립트 없이도 완전히 동작하는 웹이었음

  • 자바스크립트는 웹 컴포넌트 안에서 점진적 향상용으로만 사용함
  • 기본 판단은 명확했음. 공공 서비스 성격의 폼이면 최대한 많은 기기, 나쁜 연결, 오래된 브라우저에서도 돌아가야 함
  • 한 번 입력한 데이터는 절대 날아가면 안 된다는 원칙도 같이 잡았음

• 요구사항도 그래서 프론트엔드 유행보다 실패 복구 쪽에 훨씬 가까웠음

  • 폼 세션마다 고유 아이디를 부여함
  • 사용자가 각 단계에서 제출할 때마다 업로드 파일까지 포함해 백엔드에 저장함
  • 자바스크립트 없이도 신청을 완료할 수 있어야 했음
  • 오래되고 별로인 브라우저에서도 동작해야 했고, 접근성은 WCAG AA 수준을 맞추기로 함

• 구현은 요즘 보면 오히려 신선한 고전 웹 앱 패턴임. 각 폼 단계가 별도 페이지고, 제출하면 서버 검증 뒤 다음 단계로 리다이렉트됨

  • 실시간 대시보드도 아니고 협업 편집기도 아니고, 그냥 큰 신청 폼이라서 무거운 클라이언트 앱이 필요하지 않았음
  • 사용자는 신축 주택 단지 한가운데에서 10년 된 보급형 안드로이드폰으로 신청할 수도 있음
  • 그런 사람에게 폼을 보여주기도 전에 자바스크립트 20메가바이트를 보내는 건 솔직히 좀 빡센 선택임

sequenceDiagram
    participant 사용자
    participant 브라우저
    participant 폼페이지
    participant 백엔드
    participant 다음단계
    사용자->>브라우저: 단계별 폼 입력
    브라우저->>폼페이지: 일반 HTML 폼 제출
    폼페이지->>백엔드: 입력값과 업로드 저장
    백엔드-->>폼페이지: 검증 결과 반환
    폼페이지-->>브라우저: 성공 시 다음 단계로 리다이렉트
    브라우저-->>다음단계: 저장된 세션으로 계속 진행

• 폼 검증도 ‘라이브러리로 다 갈아엎기’가 아니라 브라우저 기본 기능을 살리는 방향이었음

  • 작성자는 React 검증 라이브러리와 씨름하느라 팀들이 몇 사람월씩 쓰는 걸 많이 봤다고 함
  • 브라우저에는 이미 폼 검증 시스템이 있으니, 그걸 흉내 내는 거대한 레이어를 유지할 필요가 없다는 문제의식임

• 그래서 만든 게 HTML 폼을 감싸는 작은 웹 컴포넌트였음

  • Shadow DOM 없이 기존 HTML을 감싸고, 브라우저의 HTML 검증 결과를 가져와 더 보기 좋은 오류 표시로 바꿈
  • 기본 팝업 툴팁은 막고, 필드와 연결된 설명 영역에 오류를 표시함
  • 사용자가 입력 중 유효한 상태가 되면 오류를 지우고, blur나 submit 시점에 다시 검증함
  • 이 사용자 경험이 1킬로바이트 미만으로 구현됐고, 실패하면 브라우저 기본 검증으로 내려감

• 결과는 꽤 강력했음. 출시하자마자 신청 완료자가 2배로 뛰었고, 분석 담당자들도 사용자가 어디서 갑자기 온 건지 몰랐다고 함

  • 자바스크립트 기반 분석 도구는 자바스크립트 실패로 튕겨 나간 사용자를 애초에 못 봄
  • 그래서 기존 데이터만 보면 문제가 작아 보이지만, 실제로는 폼에 도달하지 못한 사람이 숨어 있었던 셈임
  • 서버 세션 저장 전략도 효과가 있었고, 어떤 사용자는 폼을 시작한 지 한 달 뒤에 완료했다고 함

• 마지막 얘기가 씁쓸함. 작성자가 떠난 뒤 후임자에게 ‘자바스크립트 없이도 항상 동작한다’고 설명했더니, 후임자는 ‘그럼 우리 일이 더 많아지잖아’라고 반응함

  • 하지만 작성자는 이걸 추가 노동이 아니라 업계가 성숙해지기 위해 감당해야 할 책임으로 봄
  • 오래된 브라우저, 나쁜 네트워크, 보조 기술 사용자라는 이유로 독점적 공공 서비스에서 사람을 튕겨내는 건 받아들일 수 없다는 주장임
  • 결론은 꽤 세다. 3G 연결의 PlayStation Portable에서도 돌아가는 웹 앱을 만들면, 모든 사용자에게 돌아가고 30년 뒤에도 버틸 가능성이 높다는 것임

기술 맥락

• 여기서 선택한 핵심 기술은 Astro 자체라기보다 HTML-first 구조예요. 왜냐면 이 서비스의 본질은 화려한 인터랙션이 아니라, 사용자가 어떤 환경에서도 신청 폼을 끝까지 제출하는 거였거든요.

• React 앱이 실패한 이유도 React라는 이름 때문만은 아니에요. 상태 관리, 로딩 처리, 업로드 저장, 접근성 같은 실패 지점이 전부 클라이언트 쪽에 몰려 있었고, 그 결과 브라우저나 네트워크가 조금만 약해져도 사용자가 빠져나갔어요.

• 페이지별 폼 제출과 서버 리다이렉트는 오래된 방식처럼 보이지만, 이 맥락에서는 오히려 제일 현실적인 선택이에요. 각 단계마다 백엔드에 저장하면 브라우저가 닫히거나 연결이 끊겨도 이어서 진행할 수 있고, 업로드 파일도 로컬 저장소 제한에 묶이지 않아요.

• 웹 컴포넌트도 프레임워크 대체제가 아니라 실패해도 되는 향상 레이어로 쓰였다는 게 중요해요. 컴포넌트가 동작하면 오류 메시지가 더 좋아지고, 동작하지 않으면 브라우저 기본 검증과 서버 검증이 계속 받쳐주는 구조라서 전체 흐름이 무너지지 않거든요.

• 이 사례는 한국 서비스에도 꽤 직접적으로 와닿아요. 본인인증, 민원, 금융, 통신 가입처럼 폼이 긴 서비스일수록 최신 프론트엔드 스택보다 저장, 복구, 접근성, 저사양 대응이 전환율을 더 크게 바꿀 수 있어요.