실무로 통하는 웹 API - 라이브러리를 넘어, 근간의 웹 API

최관수·7일 전
1

서평

목록 보기
20/20

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

웹 API를 처음 접한 건 아마도 Fetch API가 아닐까 싶다. 그땐 그게 웹 API인지도 몰랐고, 그 이후에 axios로 CRUD를 구현하면서 큰 고민 없이 사용했다. 개발자로서 첫 1년은 웹 API보다는 잘 알려진 서드파티 라이브러리로 기능을 구현하는 데 익숙했다. 주니어 입장에서 익숙하지 않은 웹 API를 당장 적용해야 할지 확신하기 어려웠고, 라이브러리 공식 문서보다 딱딱하고 불친절한 MDN 문서를 급한 마음에 들여다볼 여유도 없었다. 라이브러리 관련 자료는 차고 넘치기에 당장 기능 구현하기에 바빴던 게 사실이었다.

연차가 쌓이면서 라이브러리 의존도가 높을 때의 단점이 눈에 보이기 시작했다. 책에서 언급하듯이 오픈 소스가 유지보수를 중단하는 경우도 있고, 번들 사이즈가 커지는 경우, 혹은 보안 이슈가 터지는 경우도 있었다. 그 와중에 웹 API는 꾸준히 발전해 왔고, 기존 라이브러리를 대체할 만한 수준에 이른 경우도 생겨났다. 이제는 Moment.js나 Day.js 대신 Intl API를 사용하고, 무한 스크롤은 라이브러리 대신 Intersection Observer API로 구현하는 것이 자연스러운 흐름이 되었다.

책의 흐름은 개별 섹션으로 구분되어 있다. 각 섹션 상단에는 실무에서 마주할 법한 ‘문제’가 정의되어 있다. 예컨대 비동기 API를 다루는 첫 챕터에서는 Promise로 해결할 수 있는 실무적 과제를 섹션별로 제시하는 식이다. 만약 특정 과제를 서드파티 라이브러리로 해결한 경험이 있다면, 웹 API를 통해 해결하는 사례를 보고 비교하며 더 즐겁게 읽어 나가는 것이 가능하다.

그런 맥락에서 requestAnimationFrame 또한 실무 관점에서 살펴볼 수 있다. 까다롭거나 리소스가 많이 필요한 애니메이션 구현의 경우 requestAnimationFrame를 활용하면 최적화가 가능한데, 기본적으로 다른 브라우저 탭으로 전환하면 애니메이션을 잠시 중단하기도 하고, 디스플레이 주사율에 맞게 최적화되어 있기 때문이다.

웹 스토리지 API는 비교적 익숙했다. 하지만 단순히 getItem, setItem에 국한된 게 아니라 직렬화, 역직렬화를 한다거나, 스토리지 변경을 리스닝하는 등 다양한 방식에 대해 한 번쯤 다시 훑어보기에 용이하다. 덕분에 과거 실무에서 스토리지 변경 감지를 시도했던 경험을 다시 한번 복기할 수 있어 좋았다.

URL과 라우팅 챕터도 마찬가지이다. 쿼리 파라미터를 읽고 추가하고, 그걸 통해 상태 관리를 해본 경험이 있다면 조금 더 익숙하게 읽힐 챕터였다. 일반적으로 React Router나 TanStack Router 같은 라이브러리를 사용하기에 직접 구현할 일은 거의 없지만, 그 기반 기술인 history.pushStatepopstate 이벤트의 동작 원리를 짚어준다는 점에서 의미가 있었다. 추가로 과거 크로스 브라우징 이슈로 적용하지 않고 끝내 정규식을 사용하긴 했지만, URL Pattern API도 함께 다루고 있어 반가웠다.

XMLHttpRequest나 Fetch API, SSE, 웹소켓을 다루는 4장은 조금은 익숙한 파트였는데, 요구사항에 맞게 그때그때 이 챕터를 찾아보는 게 꽤 훌륭한 레퍼런스가 될 듯하다. IndexedDB 또한 마찬가지이다. 실제로 아직까지는 IndexedDB가 필요할 만큼 복잡한 요구사항을 마주하진 않았지만, 오프라인 환경을 지원하거나 개인화 데이터가 필요한 경우 이를 활용해 구현해 볼 수 있겠다는 생각이 들었다.

‘DOM 엘리먼트 감시’라는 이름으로 묶인 6장은 더욱 친숙했다. 특히 DOM의 변화를 감시하고 그에 따라 특정 이벤트를 실행해야 할 일이 꽤 있기 때문에 좀 더 익숙했던 것 같다. MutationObserver, IntersectionObserver, ResizeObserver 같은 옵저버는 이미 여러 서드파티 라이브러리 기반 기술로 쓰이고 있다. 하지만 이 옵저버 자체의 사용법 자체가 복잡한 편은 아니기 때문에, 여유가 있다면 직접 구현하는 편이 유지보수 관점에서 더 유리할 수 있다.

반면 Form은 상황에 따라 라이브러리를 활용하는 편이 나을 수도 있다. Form 관련 API 호출을 통해 기능 구현이 가능하지만, Form은 특성상 요소가 많고 기획에 따라 꽤 다양한 형태가 나올 수 있기 때문에 잘 알려진 라이브러리를 통한 구현이 가독성과 안정성을 높이는 방향일 수도 있다. 다만 실제로 Form 요소의 근본적인 특성과 유효성 처리 방식에 대해 이해하는 것이 중요하고, 이 챕터는 그런 기본기를 다지는 데에 도움을 준다.

화면 단위에서의 애니메이션 구현은 개발자에 따라 다르고 접근에 따라 다르겠지만, 난 주로 CSS를 통해 구현해 왔다. 웹 애니메이션 API를 통한 구현은 실제로 시도해본 적이 없었는데, CSS로 구현해 왔던 애니메이션 구성을 자바스크립트를 통해 구현한 예시를 보며 비교해 볼 수 있었다. 간단한 구현은 CSS로 처리하되, 다른 이벤트와 상호작용이 필요한 경우엔 활용할 수 있겠다는 생각이 들었다.

Web Speech API는 가장 흥미로운 챕터였다. IoT와 더불어 AI 관련 기술의 성장과 동시에 최근 몇 년 사이에 많이 활용되었던 기술이 STT(Speech to Text), TTS(Text to Speech) 일 것이다. Web Speech API는 그에 대응하는 표준 기술이지만, 아쉽게도 호환성과 성능 이슈로 상용 웹서비스에서는 클라우드 기반의 외부 API를 사용하는 것이 일반적이다. 그럼에도 불구하고 표준 기술의 가능성을 엿보는 경험은 충분히 흥미로웠다. 문제는 앞서 나온 이슈로 상용 서비스에 적용하기에는 아직 어렵다는 것과 이게 벌써 몇 년이나 지난 API라는 점이다. 표준 API임에도 발전이 더딘 것을 보면 그만큼 우선순위에 밀려 신경을 못 쓰고 있거나, 실제로 이런 기술에는 언어를 포함해 다양한 요소를 고려해야 하기 때문에 다른 웹 표준 API에 비해 들어가는 공수가 많지 않을까 싶다. 사실 그렇게 공수가 많이 들어가는 기술이라면 기업이 소유하고 싶지 않을까. 표준이라는 건 공공성과 웹의 정신을 계승한다는 대의가 있겠지만, 그럼에도 불구하고 브라우저 공급자들의 이해관계가 있다는 걸 감안해야 한다.

다음으로 파일을 다루는 API와 국제화를 위한 API가 이어진다. 파일 API는 익숙한 주제였지만 세부적인 내용을 깊이 들여다볼 기회가 되어 도움이 되었다. 기존에 구현했던 서비스는 day.js를 사용하고 있고 초기 번들 사이즈는 작지만, 각각의 국제화를 세부적으로 구현하려면 번들 사이즈가 늘어나는 구조이다. 반면 브라우저에 내장된 Intl API는 초기 로딩 속도와 캐싱 관리 측면에서 이점이 있다. 다만 개발자 경험적인 측면에서는 여전히 day.js 같은 라이브러리의 사용이 용이하기 때문에 국제화의 규모가 작다면 기존의 라이브러리를 활용도 좋은 선택이다. 하지만 국제화가 메인이 되는 서비스라면 처음부터 Intl API로 접근하는 편이 장기적으로 더 좋은 선택이라고 생각한다.

UI 엘리먼트 관련 API는 여러 요소를 묶어 설명을 이어간다. <dialog>, <details>를 거쳐 최근에 일부 기술 요소로 사용되고 있는 popover 속성 등을 다루고 있다. 여기서 다루는 UI 요소는 예전부터 요구사항을 온전히 반영하기 위해 다양한 방식으로 구현되고 있었는데, 문제는 표준 방식은 아니다 보니 접근성이나 커스텀을 위해선 꽤나 공수가 들어가는 부분이 있어왔다. 그에 비해 표준 API를 활용하면 더 적은 코드로도 견고하고 접근성 높은 UI 구현이 가능하다는 장점이 있다. 물론 아직 일부 브라우저 호환성 문제가 남아 있기 때문에 서비스의 지원 범위나 폴리필 사용 여부에 대한 고민은 동반되어야 한다.

이 외에도 사용자 기기의 배터리나 네트워크 상태를 확인하거나 성능을 측정하는 API를 언급하기도 하고, 텍스트 영역을 강조하거나 DOM 전환 애니메이션을 다루는 API 등 다양한 기술을 가볍게 훑으며 넘어갔다. 일부는 아직 실험적인 기능이라 당장 실무에 적용하기는 어렵지만, 웹의 미래를 엿볼 수 있는 대목들이었다. 그리고 콘솔을 세부적으로 다루는 챕터를 지나 비디오와 오디오 스트림을 다루는 API를 설명하며 마무리된다.

마지막 챕터를 통해 저자가 이야기하지만, 이 책은 모든 서드파티 라이브러리를 버리고 내장 API만 사용하라고 주장하지 않는다. 오히려 라이브러리를 사용할 때 왜 이 라이브러리를 써야 하는지에 대한 근본적인 답을 스스로 내릴 수 있는 힘을 길러준다. 무작정 유행하는 기술을 도입하기 전에, 번들 사이즈, 유지보수, 브라우저 호환성, 그리고 개발 경험 사이의 트레이드오프를 현명하게 저울질할 수 있는 시야를 제공하는 셈이다. 표준 API의 발전이 더디게 느껴질 때도 있지만, 웹 생태계가 커짐과 동시에 그 속도는 분명 빨라지고 있다. 오늘날 당연하게 쓰이는 라이브러리의 기능이 내일의 브라우저 표준이 될 수 있기에 우린 빠른 변화의 흐름에 놓여 있고, 이 책은 그 흐름에 적응하는 데에 분명한 도움을 줄 책이라고 생각한다.

profile
평소엔 책과 영화와 음악을 좋아합니다. 보편적이고 보통사람들을 위한 서비스 개발을 꿈꾸고 있습니다.

0개의 댓글