(번역) 웹 개발에 대해 엔지니어들이 믿는 이상한 것들

원문 : https://birtles.blog/2024/01/06/weird-things-engineers-believe-about-development/

이 글의 대부분은 2022년에 작성되었지만, 2024년에도 유효하다고 생각되어 이후 세대를 위해 게시하려고 합니다. 저는 이러한 게시글을 별로 좋아하지 않습니다. 차라리 무해한 배움이나 팁을 공유하고 싶지만, 제게도 의견이 있는 건 어쩔 수 없네요 😓 죄송합니다!

저는 Mozilla를 퇴사하고 다시 풀타임 웹 개발자로 돌아온 이후, 몇 가지 놀라운 점을 발견했습니다. 그것은 웹 개발은 실제로 매우 어렵고, 웹 개발자들은 실제로 매우 똑똑하며, 브라우저 엔지니어로서 조롱했던 몇몇 프레임워크와 기술들은 실제로 그렇게 나쁘지 않다는 것입니다.

동시에 전직 브라우저 엔지니어이자 표준 에디터인 저의 입장에서 웹 개발자들이 브라우저와 웹에 대해 갖고 있는 다소 의아한 생각들을 발견했습니다.

다음은 저를 놀라게 한 몇 가지 주장입니다.

1. "웹 브라우저 엔지니어들은 웹 개발을 매우 잘 안다"
2. "웹 명세를 만드는 사람들은 웹 개발을 매우 잘 안다"
3. "웹 개발자들은 웹 개발을 매우 잘 안다"
4. "브라우저는 SPA를 실행하도록 만들어지지 않았다"
5. "MPA는 SPA를 대체할 것이다"
6. "모든 사이트는 자바스크립트 없이 동작해야 한다"
7. "웹 개발은 빌드 단계가 필요하지 않다"
8. "내 블로그는 일반적인 웹 개발을 대표한다"

"웹 브라우저 엔지니어들은 웹 개발을 매우 잘 안다"

웹 플랫폼을 구성하는 코드를 작성하는 웹 브라우저 엔지니어가 웹에 대해 누구보다도 잘 알고 있을 거라고 생각하기 쉽습니다.

문제는 웹 브라우저를 개발하는 것이 매우 어렵다는 것입니다.

대부분의 브라우저 엔지니어는 특정 분야에 중점을 두고 해당 분야에 대해서 매우 잘 알고 있지만, 다른 분야에 대해서는 피상적인 이해만 갖고 있습니다. 게다가, 브라우저 플랫폼 엔지니어들은 하루 종일 C++ 및 Rust 코드를 작성하며, 아주 간단한 자바스크립트 테스트 케이스를 약간씩 섞어가며 사용합니다. 그뿐만 아니라 이들은 모든 툴을 다른 누군가가 맡아서 관리하는 하나의 거대한 저장소에 기여합니다.

결과적으로, 브라우저 엔지니어들은 그들의 일과 동안 웹팩과 씨름하지도 않고, 전체 페이지 타입스크립트 에러를 이해하려고 애쓰지도 않으며(이들에겐 그 공백을 메우기 위한 C++ 템플릿 에러가 있습니다), iOS 사파리를 다른 브라우저 동작과 일치시키려고 하지도 않으며, 거대한 CSS와 씨름하지도 않고, 최신 SSR/SSG/아일랜드 프레임워크가 탐구할 만한 가치가 있는지 판단하지도 않으며, 최적으로 청크를 나누기 위해 거대한 자바스크립트 코드를 리팩토링하지도 않으며, 최신 버전의 의존성이 앱을 망가뜨려서 깃헙에 분노의 이슈를 작성하지도 않고, 모든 도구가 ESM vs CJS 형식을 따르는지 확인하지도 않으며, 올바른 상태 관리 접근 방식을 선택했는지, 아니면 전체 내용을 열 번 다시 작성해야 하는지를 고민하며 잠을 설치지도 않습니다.

요약하자면, 브라우저 엔지니어는 하루 종일 웹 개발을 하는 게 아니기 때문에 웹 개발자들이 기대하는 것보다 실제 웹 개발에 대해 잘 알지 못합니다.

브라우저 개발자 도구와 브라우저 프런트엔드를 작업하는 엔지니어는 일상적으로 자바스크립트를 사용하고 있기 때문에 문제에 대한 인식은 확실히 높아졌지만, 여전히 일반적인 웹 개발과는 거리가 있습니다. 예를 들어, 이들은 종종 단일 브라우저 엔진의 플랫폼 기능과 단일 브라우저 버전만 타겟으로 삼고(호환성에 대한 걱정 없이 새롭고 빛나는 기능을 사용할 수 있는건 놀라운 일이죠), 번들 크기나, 서버, 오프라인 상태 또는 웹 개발을 어렵게 만드는 많은 다른 이슈에 대해 걱정할 필요가 없습니다.

물론 몇몇 브라우저 엔지니어들은 취미 프로젝트를 진행하지만, 웹 앱의 성공에 따라 생사가 갈리는 스타트업의 세계와 취미 프로젝트는 전혀 다른 차원의 문제입니다.

저는 그래픽 디자인과 웹 개발 분야에서 커리어를 시작했고 파이어폭스에 기여하기 시작한 이후에도 한동안 오사카의 웹 개발 회사에서 일하고 Mozilla Japan에서 몇몇 웹 앱을 개발하기도 했습니다. 그러나, Mozilla를 관두고 풀 타임 웹 개발로 돌아온 이후 그동안 웹 개발이 얼마나 변화했으며 제가 얼마나 아는 것이 적은지에 대해 충격을 받았습니다.

브라우저 엔지니어로서의 경험은 웹 개발에 있어서 매우 유용했습니다. 왜냐하면 어디를 살펴보고, 누구에게 요청하고 버그를 어디로 접수할지 알기 때문입니다. 그러나 브라우저 엔지니어가 되었다고 해서 자동으로 웹 개발자의 자격이 주어졌다고 생각한다면 큰 오산입니다.

Mozilla에 있는 동안, Firefox OS 시절은 단연 가장 즐거웠습니다. 내부 팀에서 실제 모바일 웹 앱을 개발 중이었는데, 플랫폼 팀으로서 앱의 디버깅과 성공을 최우선으로 삼아야 했습니다. 저는 transitionend 이벤트가 얼마나 불안정하며 웹 앱을 얼마나 복잡하고 버그투성이로 만드는지 알게 되었고, 따라서 transitioncancel 이벤트와 웹 애니메이션의 Animation.finished Promise를 제안하고 구현하였습니다.

그러나 웹 개발자와 나란히 일하더라도 실제로 풀 타임 웹 개발자가 되기 위한 준비를 하기는 어려웠습니다. 대부분의 경우 브라우저 엔지니어는 웹 개발자들과 다른 세계에서 일하며, 우리가 상상하는 웹 개발자의 영웅이 아닐 수도 있습니다.

"웹 명세를 만드는 사람들은 웹 개발을 매우 잘 안다"

좋습니다, 그러면 웹 표준과 명세를 만드는 사람들(대부분 브라우저 엔지니어)은 분명 웹 개발을 잘 알고 있겠네요, 그렇죠?

2012년으로 돌아가서, Brendan Eich는 John Godfrey Saxe의 다음 인용문을 언급하며 "법률 제정과 같은 표준 제정은 명백히 소시지 만들기 입니다."라고 지적했습니다.

"마치 소시지와 같이, 법률이 어떻게 만들어지는지 알면 그에 대한 존경심을 잃게됩니다."

웹 개발자로서, 웹 기술에 관련된 모든 것에 대해 무한한 지혜를 가지며, 각 제안의 기술적인 장점과 업계의 요구에 대한 철저한 이해를 바탕으로 냉정하고 합리적인 결정을 내리는 사람들을 상상하기 쉽습니다.

그 환상은 대개 첫 번째 그룹 미팅까지 이어지지 못합니다. 최선의 의도에도 불구하고, 때로는 한 사람의 카리스마나 강압적인 성격, 당시 회의실에 누가 있었는지, 사람들이 얼마나 피곤한 상태인지, 심지어는 감히 말하건대 누군가의 승진 서류에 넣기 위한 기능을 출시해야 할 필요성에 따라 의사 결정이 내려질 때가 있습니다.

냉소적으로 들릴 수 있기 때문에 두 가지만 명확히 짚고 넘어가겠습니다.

먼저, 이 그룹의 사람들은 선의가 있고 훌륭합니다. 게다가 종종 본인들의 한계를 알아차리고 웹 개발자들의 피드백을 끌어내기 위해 노력합니다. 안타깝게도, 아직 이를 성공적으로 해내는 그룹을 보지 못했습니다. 예를 들어, 트위터/X의 설문조사가 있지만, 이는 기술의 최전선에 있는 웹 개발자들만 응답하는 경향이 있으며, 누가 설문조사에 대한 소문을 퍼뜨리느냐에 따라 결과가 쉽게 왜곡될 수 있습니다.

두 번째로, 저는 의사 결정이 비동기적으로 이루어지는 것처럼 보이는("대면 회의에서 이뤄진 모든 결정은 구속력이 없는 것으로 간주한다"-WHATWG 회의) HTML과 DOM과 같은 WHATWG 스펙에 대한 경험이 많지 않습니다. 그러나 그들이 더 나은 결정을 내리는 것 같다는 인상을 받았습니다. Anne van Kesteren, Simon Pieters, 그리고 Domenic Denicola와 같은 사람들은 아마 지구상의 누구보다도 웹에 대해 잘 알고 있을 것입니다. 하지만 심지어는 이조차도 웹 개발을 잘 아는 것과는 별개입니다.

"웹 개발자들은 웹 개발을 매우 잘 안다"

브라우저 엔지니어로서 새로운 플랫폼 기능을 출시하는 것은 매우 뿌듯한 일입니다. Smashing Magazine과 CSS tricks에 새 기능과 관련된 글이 올라오고, Twitter/X는 뉴스로 떠들썩합니다. 이제 전 세계가 이 새롭고 훌륭한 기능에 대해 알고 있다고 생각하기 쉽습니다.

몇 년 전 어느 날, Mozilla Japan팀의 우리 중 몇 명은 어떤 개발 도구가 도움이 되는지 알아보기 위해 도쿄의 현지 웹 개발자들을 인터뷰하기로 결정했습니다.

결과는 놀라웠습니다.

많은 개발자는 10년 전에 출시된 신규 CSS 기능에 대해 모르고 있었습니다. 게다가 새로운 기능에 대해 말했을때도 그다지 신기해하지 않는 것 같았습니다. 그들은 jQuery와 WordPress만으로도 괜찮아 보였습니다.

대신에 다음과 같은 사항들에 대해 문제를 겪고 있었습니다. "고객들에게 사이트를 반응형 디자인 모드로 보여줄 때 만약 윈도우 주변에 아이폰 목업이 없다면, 고객들은 이 사이트가 스마트폰에서 어떻게 보일지에 대한 프리뷰를 보고 있다고 인식하지 못합니다. 아이폰 목업이 절실히 필요합니다."

새로운 웹 표준을 개발하는 브라우저 엔지니어로서 약간 실망스러웠지만, 웹 사이트와 웹 앱을 출시하며 생계를 유지하는 사람들에게 제약이 있다는 점이 오래도록 기억에 남았습니다.

브라우저를 개발하거나 투자를 잘 받는 실리콘밸리 스타트업에서 일하는 사람들과는 다르게, 이들 중 상당수는 작은 사업체에서 일하며 빠르게 무언가를 제공하고 비용을 지불하기 위해 다음 프로젝트로 넘어가야 한다는 상당한 압박을 받고 있었습니다. 이들은 곧 출시될 기술을 만지작거리며 아침을 보낼 여유가 없으며, 대신에 이미 경험이 있는 검증된 솔루션을 사용하는 것에 익숙한 듯 보였습니다.

"브라우저는 SPA를 실행하도록 만들어지지 않았다"

브라우저 개발에서 웹 개발로 돌아왔을 때 또 하나의 놀랐던 점은 브라우저 동작 방식에 대한 몇 가지 주장이었습니다.

제가 애니메이션 쪽을 담당하고 있을 때, 얼마나 많은 사람들이 일부 애니메이션이 "GPU에서 실행"된다고 믿고 있는지에 놀랐습니다 (브라우저는 GPU를 사용하여 합성하거나 또는 각각의 프레임을 페인트하도록 일부 애니메이션을 분리된 프로세스나 스레드로 보낼 수 있지만, 이를 모조리 GPU에 넘기지는 않습니다). 그러나 이는 "브라우저는 SPA(single page application)를 실행하도록 만들어지지 않았다"와 같은 주장에 비하면 사소한 오해에 불과합니다.

제가 생각하기에 여기에서의 주장은 원래 브라우저는 네트워크에서 콘텐츠를 로드하여, 점진적으로 배치하고 렌더링하며, 이에 맞춰 고도로 최적화되어 있지만, 동적인 콘텐츠는 나중에 등장했기 때문에 고도로 최적화되지 않았다는 것입니다.

브라우저 개발을 거의 20년 정도 해온 사람으로서, 저는 실제 그런지에 대한 확신하지 못하거나, 적어도 더 이상은 그렇지 않다고 생각합니다.

Firefox 프런트엔드와 개발자 도구도 결국에는 SPA에 속합니다. 특히 개발자 도구는 리액트와 리덕스로 작성되었으며 모든 면에서 SPA입니다.

브라우저가 자바스크립트를 통해 동적으로 변경되는 복잡하고 오래 지속되는 DOM 트리를 다루는데 부족하다고 생각하는 주장에 대해, 브라우저 자체가 이러한 주장과 모순된 입장을 취하고 있습니다.

모바일 브라우저는 SPA를 실행하기에 최적화되지 않았다는 주장이 나올 수 있습니다. 안드로이드에서 Firefox는 성능 향상을 위해 결국에 HTML 렌더링 브라우저 크롬에서 네이티브 브라우저 크롬으로 전환하였습니다. 저는 이러한 변경을 초래한 성능 제약이 무엇인지에 대해 언급할 수 있는 입장이 아닙니다. 그러나 그 당시의 블로그 글에서 앱의 시작 소요 시간 그리고 패닝 및 스크롤 성능과 연관되어 있음을 알 수 있고, 이들 중 어느 것도 브라우저가 다른 아키텍처에 비해 SPA를 다루기에 부족하다는 것을 지적하고 있지 않습니다.

"좋습니다. 그러면 브라우저가 동적인 변화가 빈번한 상황에서 복잡하고 수명이 긴 DOM 트리를 다룰 수 있다고 합시다. 그러나 SPA는 초기 렌더링을 블로킹하고 다운로드 및 파싱하는 데 오랜 시간이 걸리는 자바스크립트 번들을 갖는 경우가 많습니다." 이는 정당한 주장이지만 렌더링을 차단하는 초기 번들의 크기가 작아야 한다는 것에 대한 주장이며, 일반적인 워드프레스 사이트에도 동일하게 적용되는 것이지 브라우저가 SPA 실행에 부적합하다는 주장이 될 수는 없습니다.

"MPA는 SPA를 대체할 것이다"

앞서 우리는 SPA와 "웹 앱을 개발하는 단 하나의 진실한 방법"에 대해 이야기했지만, "브라우저는 SPA를 다루지 못한다"의 최근 변형은 "MPA(multi page application)는 SPA를 대체할 것이다"입니다.

저는 MPA에 대한 기대가 큽니다. 좀 더 자세히 말하자면, 많은 애니메이션 스펙에 관여했던 사람으로서 뷰 전환 스펙에 대한 기대가 큽니다. 이는 특히 Firefox OS 시절부터 Mozilla에서 진행하고 싶었던 것이고 이를 위한 제안을 만들었습니다. Jake를 포함하여 이를 마침내 실현해 낸 모든 분께 찬사를 보냅니다.

뷰 전환은 원래 SPA를 위해 구현되었지만 여러 페이지로 구성된 사이트를 즐겁게 만들 수 있을 정도로 MPA에 맞게 조정되었다는 점에서 매우 환영할 만한 추가 기능입니다.

그러나 "SPA는 나쁘다"라는 생각에 기반하여 MPA가 미래고 SPA는 쇠퇴하는 중이라고 생각하는 경향이 있는 것 같습니다.

앞서 언급했던 것들과는 다르게, 이 관점에 대해 제가 놀랐던 점은 브라우저 개발을 했던 경험이 아니라 최근의 웹 앱 작업에 기반합니다.

우선, MPA가 무엇을 의미할까요?

제가 이해하기로는 SPA는 수명이 긴 DOM 트리를 가지고 스크립트에 의해 종종 업데이트되는 특징이 있는 반면에, MPA는 주로 네트워크에서 제공하는 서로 다른 HTML 리소스를 탐색하며 콘텐츠를 업데이트합니다. 이는 최상위 탐색일 필요가 없습니다. 예를 들어 <iframe> 탐색이 될 수도 있습니다. 유사하게 SPA도 청킹의 개념으로 <iframe>을 사용할 수 있지만, 어떻게 콘텐츠가 업데이트되는지에 따른 차이점이 있습니다.

이 정의에 의하면, 구글 독스는 각각의 문서가 분리된 자원으로 제공되지만, 대부분의 시간 동안에는 자바스크립트를 통해 계속 업데이트되는 한 개의 문서만 사용하기 때문에 SPA입니다. 유튜브는 MPA로 간주되지만 실제로는 콘텐츠 변경을 원활히 하고, 탐색을 가로채고, 스크립트를 통해 콘텐츠를 대체하기 위해 SPA로 구현되어 있을 겁니다. 즉, 뷰 전환을 적용하기 전까지는 말이죠.

위의 두 경우에서 MPA가 모든 SPA를 대체할 것이라는 생각에 대해 놀랐던 점은 간단합니다. 웹에서 동작하는 피그마 또는 포토샵이 어떻게 MPA로 동작할 수 있을까요? 슬랙, 디스코드, 구글 맵은 또 어떨까요?

저는 현재 데이터를 로컬에 저장해두고 서버와 동기화하는 오프라인 우선의 모바일 웹 앱을 제작하고 있습니다. 웹 기술의 최전선에 서고 싶기에 MPA를 수용할 수 있는 방법을 조사했습니다.

짧게 요약하자면, 독립적으로 탐색할 수 있는 패널과 오프라인 우선의 요구사항과 같은 UX를 유지하려고 한다면, 일부 기능을 별도의 HTML 요청(별도의 스크립트 청크 요청과 반대되는)으로 분리하기 위해 <iframe>을 도입하거나, 때로는 몇몇 청크를 미리 렌더링할 수도 있습니다. 문제점은 이 방법이 복잡성은 10배(양방향 동기화가 3방향 동기화로 바뀜) 증가시키는 와중에 고객들에게는 아무런 이점이 없다는 것입니다. 대신에 거의 확실하게 더 많은 버그와 대기 시간이 발생하고 기능 출시 속도가 느려질 것입니다.

우리의 앱이 아직 출시되지 않았기 때문에 누구도 앱을 보고 더 나은 접근 방식을 제안할 수 없고, 따라서 상당히 약한 주장이라는 것을 알고 있습니다. 따라서 이 주제에 대해서는 저를 신뢰해 주시길 부탁드립니다. 제가 노력해 봤습니다. 정말로요. 이 특정 앱에 적합한 아키텍처가 아니며 모든 것이 MPA가 되어야 한다는 주장은 놀라울 따름입니다.

"모든 사이트는 자바스크립트 없이 동작해야 한다"

웹 개발의 모범 사례에 대한 주제를 계속 이어 나가면, 자바스크립트 없이 동작하는 사이트를 만드는 것은 훌륭한 목표입니다. 이는 사이트의 품질이 부드럽게 저하되고, 초기 렌더링을 차단하는 자바스크립트가 없으며 광범위한 브라우저에서 동작하는 것을 의미합니다. 그러나 이 주장이 종종 독단적인 형태로 변해가는 것을 보면 놀랍습니다. 바로 "모든 사이트는 자바스크립트 없이 동작해야 한다."는 것이죠.

만약 당신의 사이트가 자바스크립트 없이 동작할 수 있다면("내 블로그는 일반적인 웹 개발을 대표한다" 섹션을 참고하세요) 이러한 결론에 도달하기는 쉬울거라고 예상하지만 저에게는 다소 근시안적인 주장으로 느껴집니다.

앞서 웹을 위한 피그마와 포토샵을 언급했습니다. 이들이 자바스크립트 없이 동작하는 모습을 상상하기란 어렵습니다. 브라우저의 개발자 도구도 마찬가지입니다. 심지어 Parapara 애니메이션도요!

게다가 자바스크립트에 반대하는 많은 옹호자가 접근성에 대해서 우려를 표할지라도, 앱의 접근성을 높이기 위해서는 자바스크립트가 필요한 경우가 종종 있습니다.

Mozilla의 접근성 담당자가 키보드 탐색에 대해 알려준 한 가지에 대해 말씀드리면, Tab 탐색은 상당히 거칠어야 한다는 것이었습니다. 즉, 툴바와 같은 컨트롤 그룹을 탐색하기 위해 Tab을 사용하고 그런 다음 방향키를 이용해서 그룹 내에서 움직이게 됩니다. 따라서 모든 컨트롤에 대해 일일이 Tab을 누를 필요 없이 앱을 빠르게 탐색할 수 있습니다. WAI는 이를 "roving tabindex"라고 부릅니다.

하지만, 이렇게 거친 키보드 탐색을 구현하기 위해서는 자바스크립트가 필요합니다. 만약 방향키 기반의 이차원 탐색을 구현한다고 하면, 더 많은 자바스크립트가 필요하게 됩니다. 아마 언젠가는 플랫폼 차원에서 이 격차를 메울 수 있겠지만(focusgroup을 참고), 지금은 앱을 접근할 수 있게 만들기 위해 자바스크립트를 사용하는 것에 대해 부끄러워할 필요가 없습니다.

솔직하게 저는 웹 사이트에 자바스크립트가 더 필요하다고 생각합니다.

예를 들어, Eleventy 문서는 대부분 클라이언트 측 자바스크립트를 사용하지 않는 것으로 보입니다. Eleventy는 다양한 템플릿 언어를 지원하기 때문에 각각의 다른 언어로 코드 샘플을 제공합니다. 유감스럽게도, 선택한 언어는 따로 저장되지 않기 때문에 기본값이 아닌 언어를 선택했다면 각각의 매 코드 샘플마다 탭을 변경해야 합니다. 클라이언트 측 자바스크립트가 약간만 더해진다면 사용자들에게 더 좋은 경험을 제공할 수 있을 것입니다.

업데이트 (2024-01-11): Eleventy가 이 글의 피드백을 참고하여 문제를 수정한 것으로 보입니다. 감사합니다! 🙏

"웹 개발은 빌드 단계가 필요하지 않다"

이 글의 거의 모든 내용은 2022년에 작성되었지만, 정리하는 과정에서 최근 저를 놀라게 했던 주장 한 가지를 더 추가하지 않을 수 없었습니다.

웹 개발에 대한 독단적 주장 열차의 마지막 정거장은 몇 번이나 나온 주제이지만 여전히 놀랍습니다. 제가 가장 최근에 마주한 형태는 다음과 같습니다. "우리는 너무 맹목적이고 고집스러워서 결국 엄청나게 복잡한 툴체인을 만들었지만, 빌드 단계 없이 웹 앱을 출시할 수 있어야 합니다."

대부분의 커리어 동안 컴파일 언어를 사용했던 사람으로서 빌드 단계 없이 진행하려는 열망은 놀랍습니다. 컴파일러 엔지니어가 하는 일들을 보면 놀랍습니다. 이들은 평범한 저의 코드를 알아볼 수 없고 미치도록 빠른 형태로 변환하며 최적화 위에 또 다른 최적화를 겹겹이 쌓아 올리는 천재들입니다. 오히려 저는 웹 개발에 이러한 컴파일러 마법이 많아졌으면 좋겠습니다.

물론 자바스크립트는 특정 작업에 대한 부작용을 정적으로 결정하기 어렵기 때문에 분명히 해결해야 할 과제가 있습니다. 그러나 컴파일 시점에 자바스크립트를 최적화하는 데는 아직 탐구할 여지가 더 많다고 생각합니다.

웹 개발자들은 이미지 에셋을 최적화하고 정적인 HTML 페이지를 미리 생성하는 것은 합리적이라고 생각하는 것 같은데, 왜 코드 에셋을 최적화하는 것에는 반대의 의견이 있을까요? 왜 빌드 시점에 함께 처리할 수 있는 계산과 I/O 작업을 런타임으로 미루어야 할까요? 적어도 저는 iOS 사파리를 비난하는 몇 메가바이트 분량의 주석을 매 요청마다 모든 사용자에게 보내고 싶지 않습니다.

2024년에는 아마 클라이언트 측 Rust/WASM 프런트엔드 프레임워크가 주목받기 시작할 것이고, 우리는 빌드 단계에 익숙해져야 합니다!

"내 블로그는 일반적인 웹 개발을 대표한다"

위에서 언급한 여러 주장은 "내 블로그는 일반적인 웹 개발을 대표한다"로 요약될 수 있습니다. 즉, 브라우저 엔지니어에서 웹 개발자로 전향한 후에 저를 놀라게 했던 웹 개발에 대한 대부분의 주장은 사람들이 저와 겹치지 않는 방식으로 웹에 대한 경험을 추정한 결과입니다.

약 4년 전 Mozilla를 떠난 이후로, 저는 대부분의 시간을 웹 앱 개발에 할애했습니다. 또한 이 블로그를 만드는데도 꽤 많은 시간을 할애했습니다. 놀랍게도 툴링, 아키텍처 또는 사용된 웹 플랫폼 기능에 관하여 둘 사이에 겹치는 점이 거의 없었습니다. 마치 블로그와 앱이 웹 개발 영역에서 완전히 다른 구석에 존재하는 것과 같았습니다.

제 앱은 타입스크립트 코드 덩어리이고, 제 블로그는 클라이언트 측 자바스크립트가 거의 없습니다. 제 앱은 양방향의 데이터 동기화로 인해 매우 복잡하지만, 블로그는 읽기 전용입니다. 제 앱은 웹팩, E2E 테스트를 위한 Playwright, 컴포넌트 프레임워크 그리고 상태 관리 라이브러리를 사용하지만 제 블로그는 이들 중 아무것도 사용하지 않습니다.

만약 당신이 둘 중 하나의 개발에만 주로 참여하고 있다면, 지금 하는 작업이 웹 개발 자체라고 생각하기 쉽습니다. 사실 웹 개발은 우리가 상상하는 것보다 훨씬 더 다양할지도 모릅니다.

결론

저에게 놀라웠던 몇 가지 다른 주장도 있지만 위의 공통된 주제는 우리의 웹 경험이 일반적인 웹 개발을 대표한다고 착각하기 쉽다는 것입니다.

브라우저 개발에서 웹 개발로 전환하면서 저는 겸손함을 배웠습니다. 왜냐하면 제가 알던 것보다 훨씬 넓고 깊었기 때문입니다. 웹 개발자, 특히 웹 앱의 성공 여부에 따라 생사가 갈리는 소규모 웹 시장과 스타트업의 웹 개발자들에게 존경을 표합니다.

만약 당신이 그렇다면, 이 글을 읽으면서 브라우저 엔지니어, 표준 에디터 그리고 기타 웹 개발자가 특정 방식을 주장하더라도 여러분은 제약 조건을 누구보다 잘 알고 있으며 잘 해내고 있다는 확신을 통해 자신감을 얻으셨길 바랍니다.