최근 회사에서 공공기관에 납품해야 하는 프로젝트를 진행하면서 웹표준을 준수해야 합니다라는 요구사항을 받았습니다. 웹표준, 웹접근성을 지키는 것에 대한 필요성에 글은 여기저기서 많이 읽었지만 실제로 그 요구사항을 받은 경험은 없었기 때문에 이번 요구사항은 저에게 조금은 생소했습니다.
웹표준이란?
웹표준(Web Standards)은 월드 와이드 웹 컨소시엄(W3C , https://www.w3.org/)과 같은 국제 표준화 기구에서 정의한 웹 기술의 규칙과 지침을 의미합니다. 웹사이트나 웹 애플리케이션이 다양한 브라우저와 장치에서 일관되게 동작하도록 하기 위해 만들어졌습니다.
웹표준의 주요 요소는 다음과 같습니다.
- HTML (HyperText Markup Language): 문서의 구조를 정의하는 마크업 언어
- CSS (Cascading Style Sheets): 문서의 스타일과 레이아웃을 담당하는 스타일시트 언어
- JavaScript: 웹페이지의 동적 기능을 담당하는 프로그래밍 언어
- 웹 접근성 (Web Accessibility, WCAG): 장애인과 비장애인 모두가 접근할 수 있도록 웹사이트를 설계하는 기준
웹표준을 준수하면 다양한 브라우저에서 동일한 결과를 제공할 수 있으며, 검색 엔진 최적화(SEO)와 웹 접근성 향상에도 큰 도움이 됩니다.
제가 이번에 만든 웹표준 검사기에서 검사하는 것은 이 중에서 적절한 마크업 tag들이 사용되어있는지 검사해주는 Markup Validation Service 를 개발환경에서 더 편하게 사용할 수 있게 만든 것 입니다.
왜 개발했는가?
웹 표준에 맞는 마크업을 작성하는 일은 쉽지 않습니다. 특히, 리액트 컴포넌트 환경에서는 이를 더욱 까다롭게 느꼈습니다.
예를 들어, <section> 태그 내부에 적절한 <h1>~<h6> 태그가 존재하지 않으면 이는 웹 표준을 위반한 마크업이 됩니다. 그런데 <section> 태그를 컴포넌트화하여 여러 페이지에서 공통으로 사용한다면, 하위 컴포넌트에서 적절한 헤딩 태그를 강제하는 방법이 마땅치 않다고 생각했습니다. (물론, 린트 같은 도구를 활용하면 어느 정도 제한할 수 있겠지만, 이에 대한 명확한 해결책은 찾기 어려웠습니다.)
또한, 개발환경에서 핫 리로드로 수정된 HTML이 웹표준에 맞는지를 확인하기 위해서는 수정된 html을 복사하여 W3C 에서 제공하는 페이지에서 확인해야하는 번거로움을 감수해야했습니다.
이러한 고민 끝에, 개발 과정에서 실시간으로 핫 리로딩된 HTML을 웹 표준에 맞게 검사하고 즉각적인 피드백을 받을 수 있는 도구가 필요하다고 느꼈습니다.
개발 과정
개발 과정에서 가장 중요하게 생각했던 것은 "빠르고 가볍게 개발하기" 였습니다. 회사 내에서 마감이 얼마 안남은 프로젝트였으며 이 도구가 유용하게 쓰이려면 웹표준 QA전에 동료 개발자 분들에게 공유를 해드려야겠다고 생각했기 때문입니다. 그래서 최소한의 기능 (핵심기능 한가지) 과 빠르게 개발할 수 있는 기술 스택 (react vite, shadcn ui) 그리고 cursor AI 의 도움을 받아서 하루만에 개발하는 것이 목표였습니다. (실제로는 퇴근하고 3-4시간 정도)
이후 저는 자료조사를 시작했고, W3C HTML Validator API (https://github.com/validator/validator/wiki/Service-%C2%BB-Input-%C2%BB-POST-body) 사용하면 크롬익스텐션에서 해당 개발서버의 html을 요청해서 받아온 후 받아온 html을 기준으로 Validator 응답을 보여주면 되겠다는 생각으로 시작하였습니다.
크롬 익스텐션에서 Localhost HTML 요청 문제 해결
개발 과정에서 가장 큰 난관 중 하나는 크롬 익스텐션에서 localhost의 HTML을 받아오는 것이었습니다. 일반적으로 HTML 응답은 GET 요청을 통해 받을 수 있지만, 브라우저에서 직접 요청을 보내면 CORS(Cross-Origin Resource Sharing) 정책에 의해 차단되었습니다.
처음에는 프록시 서버를 이용해 문제를 해결하려 했지만, 보다 효율적인 방법을 찾고자 크롬 익스텐션에서 제공하는 background 속성을 활용하는 방향으로 전환하였습니다.
크롬익스텐션의 구조를 가볍게 설명하면 아래 그림과 같습니다.
background.js 파일에 작성된 script는 브라우저의 서비스 워커(Service Worker)에 의해 실행되고 브라우저에서 요청되는 네트워크 요청들을 가로챌 수 있기 때문에 CORS문제를 우회할 수 있었습니다.
서비스 워커(Service Worker)란?
서비스 워커(Service Worker)는 웹 브라우저에서 백그라운드에서 실행되는 스크립트로, 웹페이지와는 독립적으로 동작하는 JavaScript 파일입니다. 이를 통해 네트워크 요청을 가로채고, 캐시를 제어하며, 오프라인 상태에서도 웹 애플리케이션이 정상적으로 작동할 수 있도록 지원합니다.
서비스 워커의 특징
-
프록시 서버 역할
- 서비스 워커는 브라우저와 네트워크 사이에서 프록시 서버처럼 동작하며, 네트워크 요청을 가로채서 캐시된 데이터를 제공할 수 있습니다.
- 이를 통해 오프라인에서도 웹 애플리케이션을 사용할 수 있도록 도와줍니다.
-
캐시 관리 (오프라인 지원)
- 서비스 워커는
Cache API를 이용해 요청한 데이터를 저장하고, 네트워크가 불안정하거나 끊긴 경우에도 기존 데이터를 제공할 수 있습니다. - 이로 인해 빠른 로딩 속도와 데이터 절약 효과를 얻을 수 있습니다.
- 서비스 워커는
-
푸시 알림 지원
- 백그라운드에서 실행되므로 웹 페이지가 닫혀 있어도 푸시 알림을 받을 수 있습니다.
- 이를 통해 웹 푸시 알림(Notification API)을 활용한 사용자 경험 향상이 가능합니다.
-
백그라운드 동기화 (Background Sync)
- 네트워크 연결이 끊긴 상태에서 사용자가 데이터를 입력하거나 요청을 보낼 경우, 온라인 상태가 되면 자동으로 해당 작업을 수행할 수 있도록 지원합니다.
- 예를 들어, 사용자가 오프라인에서 메시지를 작성하면, 다시 온라인이 되었을 때 자동으로 전송됩니다.
-
독립적인 실행 환경
- 일반적인 JavaScript 코드와는 다르게 서비스 워커는 웹페이지와 독립적으로 동작합니다.
- 따라서 DOM을 직접 조작할 수 없으며, 대신
postMessage()API를 이용해 웹페이지와 데이터를 주고받습니다.
서비스 워커의 활용 사례
- 오프라인에서 웹페이지를 사용할 수 있도록 지원 (PWA, Progressive Web Apps)
- 빠른 로딩을 위한 정적 리소스 캐싱
- 푸시 알림을 통한 사용자 리마인드 기능
- 백그라운드에서 데이터를 동기화하여 최신 상태 유지
Cursor AI 의 활용
저는 사실 이전에는 Cursor AI를 사용하는 것을 꺼려하는 사람 중 한 명이었습니다. 이전에 제가 Cursor AI를 쓰기 꺼려졌던 가장 큰 이유는 결과물을 제가 못믿기때문에 AI가 생성한 모든 코드들을 검토하는 시간을 생각하면 더 비효율적이라 생각했기 때문입니다.
그러나 이번 개발에서 Cursor AI를 적극적으로 사용하면서 느꼈던 점을 따로 정리해보아야겠다는 생각을 했습니다. 확실히 Cursor AI 사용하는 경험은 좋은 경험이였고 개발의 생산성을 높혀주는 도구라는 느낌이 들었습니다.
크게는 두 가지 포인트에서 편리하다고 느꼈는데
첫 번째는 개발 방향성을 설정하는 과정입니다. 모든 개발 지식을 개발자가 머릿속에 담고 있을 수는 없습니다. (아직 저년차라 그런지도 모르겠지만요.) 이번에 Cursor를 사용하며, localhost에서 HTML을 받아오는 문제를 해결하는 과정에서 큰 도움을 받았습니다. 질문을 던지자 크롬 익스텐션의 Service Worker를 활용하는 방법을 제시해 주었고, 덕분에 빠르게 문제 해결의 방향성을 잡을 수 있었습니다. 세부적인 설정은 직접 조정해야 했지만, 막막했던 상황에서 중요한 힌트를 얻어 시간을 크게 단축할 수 있었습니다.
두 번째는 스타일링 작업에서의 도움입니다. 개인 사이드 프로젝트에서는 디자인 없이 무언가를 만들어야 할 때가 많고, CSS 작업에 예상보다 많은 시간이 소요되곤 합니다. (게다가, 열심히 스타일링을 해도 결과물이 예쁘지 않았던 경험도 많았습니다.) 하지만 이번에는 Cursor를 활용한 덕분에 만족스러운 결과물을 얻을 수 있었고, 디자인적으로도 꽤나 예쁜 CSS를 적용할 수 있었습니다.
이쯤 되면, 단순한 코드 보조 도구가 아니라 더 진화한 코파일럿이라는 느낌을 받았습니다.
더 해보기(?)
해당 프로젝트를 릴리즈하고 테스트 코드가 필요할 것 같아서 아래와 같이 테스트 코드 작성을 요청했습니다. cursor의 composer 기능을 이용하여 빠르게 테스트 코드를 구현해보았습니다.
처음에 요청한 '테스트 코드작성해줘' 라는 추상적인 요구의 결과물입니다.
'어떤 코드에 대한 테스트 코드인지', '어떤 프레임워크를 사용하고 싶은지' 에 대한 결과가 없기 때문에 결과물을 내놓지 않았습니다.
아래 사진은 주 로직이 있는 App.tsx 를 context 에 추가한 뒤에 같은 맥락으로 물어본 결과입니다.
자연스럽게 'App.tsx' 에 대한 코드를 테스트 하는 걸로 인식하고, react 로 만들어진 코드기 때문에 가장 보편적으로 사용하는 jest 와 React Testing Library 를 사용하여 테스트코드 '예시' 를 작성해줍니다.
이번엔 '유닛테스트 코드를 작성해줘' 라는 테스트 코드의 종류를 조금 더 구체적으로 명령했습니다. 이번에야 말로 테스트 코드 예시가 아닌 진짜 테스트 코드를 짜주고 accept 을 기다리는 것을 볼 수 있었습니다.
마지막으로 저는 vitest를 사용하고 싶어서 조금 더 구체적으로 'vitest'를 활용해서 '유닛테스트'를 작성해줘 라는 명령어로 test 코드를 작성할 수 있었습니다. 테스트 코드의 결과물은 생각보다 괜찮았고 필수 기능들 + 실패 테스트 까지 포함해서 만들어주는 것을 볼 수 있었습니다.
해당 로직이 있는 test의 coverage를 살펴보면 꽤나 높은 coverage로 만들어졌다는 것을 볼 수 있었습니다.
당연한 결과지만 Cursor의 컴포즈 결과물은 사용자가 더 구체적으로 어떤 곳에 어떤식으로 무엇을 하고싶은지 명령을 내리는게 더 퀼리티 좋은 결과를 얻을 수 있다는 것을 알수있는 좋은 경험이였습니다.
마무리
이번 프로젝트를 통해 웹표준 검사기 크롬 익스텐션을 빠르게 개발하고 실제 업무에 활용할 수 있도록 공유할 수 있었습니다. 웹표준을 실시간으로 검사할 수 있는 환경을 만들면서, 단순한 기능이더라도 개발 생산성을 높이는 도구가 얼마나 중요한지를 다시 한번 깨달았습니다.
또한, 개발 과정에서 Cursor AI를 적극적으로 활용하며 AI 기반 도구가 개발자에게 실질적인 도움을 줄 수 있다는 점을 체감했습니다. 특히, 문제 해결의 방향을 설정할 때와 스타일링 및 테스트 코드 작성 시 큰 도움이 되었고, AI의 활용 방법에 따라 결과물이 크게 달라진다는 점을 경험했습니다.
이번 프로젝트를 통해 얻은 경험을 바탕으로, 앞으로도 개발 생산성을 높일 수 있는 다양한 방법을 고민하고 실험해 볼 계획입니다. 또한, AI 도구를 보다 효과적으로 활용하는 방법을 익혀 더욱 효율적인 개발 프로세스를 만들어 보려합니다.
제가 만든 크롬익스텐션은 조금 더 기능을 보충해서 chrome web store 에 등록될 예정이며 현재 심사중입니다. 당 프로젝트의 소스 코드는 아래 깃허브 레포지토리에서 확인할 수 있습니다.
https://github.com/wade3420/html-validator-extension
참고
https://fe-developers.kakaoent.com/2022/221208-service-worker/
https://developer.mozilla.org/ko/docs/Web/API/Service_Worker_API
https://nyagm.tistory.com/262
https://developer.chrome.com/docs/extensions/reference/manifest/background?hl=ko
https://www.w3.org/standards/about/
https://www.youtube.com/watch?v=uUSGl0bzvnM
오호! 재미있는 글 감사합니다!