웹 개발에 대한 말말말 👨‍💻

Brian Birtles 님의 블로그를 의역/요약한 글입니다.

---

"2022년도 쯤에 썼던 글이지만, 2024년에도 유효한 내용이어서 끌올했습니다."

Mozilla를 퇴사한 후 웹 개발 전선에 뛰어들어 보니 놀라운 것들이 많았습니다. 웹 개발은 어렵고, 웹 개발자들은 사실 "개발잘알" 이었으며, 브라우저 개발자들이 비웃던 많은 프레임워크와 요행들이 아주 쓸만한 기술들이었습니다.

전부는 아니지만 많은 웹 개발자들이 웹 개발에 대한 선입견(?)을 가지고 있습니다. 브라우저 개발자였고 표준을 정의하는 개발자였던 저로써는 이해하기 힘든 내용이지만 몇 가지 공유하려고 합니다.

“웹 브라우저 개발자는 웹 개발에 대해 잘 안다”

웹 브라우저 개발자라면 웹 개발에 대해 1도 모르는게 없는 사람들이라고 생각하기 쉽습니다. 왜냐면, 브라우저를 만드는 사람들이니까요.

문제는, 웹 브라우저 만드는 게 정말 빡셉니다.

대부분의 브라우저 개발자들은 특정 영역을 아주 잘하는 사람들입니다. 그리고 대부분 C++이나 Rust와 하루 종일 씨름하고 있지 JavaScript는 거의 접할 기회가 없습니다. 심지어 엄청 큰 모노 레포지토리에 코드만 푸시 할 뿐, 그 이후의 일은 다른 사람이 맡아서 합니다.

그래서 브라우저 개발자들은 webpack과 씨름하는 것도, TypeScript 에러를 보는 것도, iOS Safari를 크롬처럼 길들이는 것도 (그 외 웹 개발자가 접하는 이슈 기타등등) 다 경험해본 적이 없을 겁니다. 그러니 브라우저 개발자들은 대부분의 웹 개발자들보다 찐 웹 개발에 대한 경험이 적습니다. 물론, 개발자 도구나 브라우저의 프론트엔드를 만드는 개발자들은 JS를 좀 더 많이 사용하기는 합니다. 다만, 이들도 현역 웹 개발자들의 문제를 모두 다 이해하는 것은 아닙니다.

웹 브라우저 개발과 웹 개발은 그냥 다른 영역입니다.

“웹 브라우저 표준을 정하는 사람들은 웹 개발을 정말 잘 아는 고수들 일거야”

표준을 정하는 건 법을 정하는 것과 같습니다. 둘 다 보이지 않는 수고가 많이 들어갑니다. 다만, 이 표준을 정하는 사람들도 대부분 브라우저 개발자들입니다.

웹 개발자 입장에서 하나의 표준이 무수히 많은 회의와 고수들의 정제된 토론 끝에 정해진다고 생각할 수 있습니다. 다만, 이 환상은 이 회의에 한번이라도 참여할 수 있다면 산산이 부서질 것입니다. 물론, 최선의 결과를 추구하는 것은 맞지만 때론 미팅에 참여한 누군가의 주도 아래 속전속결로 표준이 정해질 때도 많습니다. 심지어 자기 승진을 위해 표준에 넣을 기능을 배포하기도 합니다.

우선 욕만 하는 것 같아서 좀 덧붙이자면, 이 회의에 참여하는 개발자들은 모두 좋은 의도를 가진 선한 사람들입니다. 대부분 본인들과 속한 팀의 한계를 잘 알고 있고 그 속에서도 웹 개발자들의 의견을 최대한 수집하고 반영하고 소통하려고 합니다. 다만, 이를 잘 해내는 그룹은 아직까지 없었습니다.

두 번째로, 전 WHATWG 표준 (HTML과 DOM 표준)은 경험이 전무합니다. WHATWG는 표준을 정하는 방식이 비동기로 이루어지고 회의는 필요할 때만 한다고 알고 있습니다. 제 느낌 상 표준을 정하는 과정이 더 합리적인 쪽은 WHATWG였습니다. 하지만, 이들도 웹 개발에 대해 잘 알고 있다고 말하기 어렵습니다. 표준을 정하는 것과 웹 개발은 아주 다른 것이니까요.

“웹 개발자들은 웹 개발에 대해 잘 알 것이다”

브라우저 개발자 입장에서 새로운 기능을 배포하고 그 기능이 여기저기 기사로 실리고 개발자들이 X/트위터 같은 곳에서 인지도를 쌓는 것을 보면 흥분되고 보람찹니다. 이제 온 세상이 이 새로운 기능에 대해 알고 있다고 착각하기 쉽습니다.

현실은 그렇지 않습니다.

일본 Mozilla에서 개발하고 있을 때, 현직자 인터뷰를 한 적이 있습니다. 인터뷰 대상자들은 웹 개발자들이었습니다. 놀랍게도 그들은 10년 전에 배포된 CSS 기능도 모르고 있었고, 알려줬을 때도 뜨뜻미지근한 반응이었습니다. 이미 같은 기능을 jQuery와 WordPress로 잘 구현해서 쓰고 있었습니다.

오히려 개발자 도구에서 모바일 뷰를 볼 때, 옆에 아이폰 테두리가 안 뜨는 것에 대한 요구 사항이 있었습니다. 브라우저 개발자였던 저는 실망했지만 한편으로는 그들이 마주하는 현실을 깨닫게 되었습니다. 작은 스타트업에서 웹 앱 하나에 회사의 존망이 결정된다면, 새로운 웹 기능을 하나 하나 뜯어보고 있을 시간이 없습니다. 그들은 속도전을 하고 있고 하나라도 빠르게 개발하고 배포해야 하기에 이미 검증된 기술을 쓰지 새로운 기술을 실험해 볼 여유 따윈 없었습니다.

“브라우저는 SPA를 위해 만들어지지 않았다”

이 주장은 아마 초기부터 브라우저는 네트워크를 통해 컨텐츠를 로딩하고 점진적으로 배치한 후 렌더링하는 형태로 작동했기에 이쪽으로 최적화가 잘 되었고 SPA 처럼 동적으로 페이지를 조작하는데는 비효율적이라고 생각할 수 있습니다. 20년 동안 브라우저 개발자로 일해본 경험을 빗대어 보자면, 이제는 더 이상 유효한 주장이 아닌 것 같습니다. Firefox의 개발자 도구는 React와 Redux로 작성된 SPA입니다. 브라우저가 복잡하고 동적인 SPA에 최적화되지 않았다는 주장은 어불성설입니다.

물론, 모바일 브라우저에서 SPA를 위한 최적화가 되지 않았다 - 라는 주장은 어느 정도 수용할 수 있습니다. Firefox도 모바일에서는 성능을 위해 기존 HTML로 렌더링 하던 브라우저를 네이티브 브라우저로 바꿨기 때문입니다. 물론, 제가 해당 작업을 진행하지는 않아서 왈가왈부 할 입장은 아니지만 당시 기술 블로그에 따르면 앱 시작 시간 단축과 네이티브 제스쳐를 지원하기 위해 변경한 걸로 알고 있습니다.

“SPA는 결국 MPA로 대체될 거야”

View transition 표준에 참여했던 저로서는, 개인적으로 MPA를 흥미롭게 보고 있습니다. View transition은 사실 SPA를 염두에 두고 만들었지만, MPA도 유용하게 쓸 수 있습니다.

아무튼, “SPA는 결국 MPA로 대체될 거야”라는 주장으로 돌아와보면 사실 우리가 말하는 MPA가 뭔지 모르겠습니다.

제가 이해하기로 SPA는 하나 또는 두 개의 DOM 트리를 아주 오랫동안 JS로 조작하면서 앱을 만드는 형태고, MPA는 페이지 이동을 통해 서버에서 새로운 HTML을 받아오면서 앱을 조작하는 형태로 알고 있습니다. 이 네비게이션은 항상 최상위 네비게이션일 필요는 없고 iframe 같은 요소를 사용하고 있을 수 있습니다.

이 개념이 맞다면, 포토샵, 슬랙, 구글 맵, 피그마 같은 웹 앱들이 MPA로 어떻게 전환 될 수 있는지 상상이 안 갑니다. 이런 앱들을 MPA로 전환할 수 있다고 한들 - 개발 복잡도만 올라가고 사용자에게 실질적인 이득은 거의 없거나 SPA와 똑같을거라고 생각합니다.

지금 제가 만들고 있는 웹 앱도 MPA를 고려하지 않은 건 아니지만, 도저히 MPA로는 답이 안나와 SPA로 만들고 있습니다. “모든 앱이 MPA가 될거야” 라는 주장은 놀랍기만 합니다.

“모든 웹 사이트는 JavaScript 없이 돌아갈 수 있어야 해”

JavaScript 없이 웹 사이트 기능을 다 지원할 수 있다면 표준을 정말 잘 따르는 것이고 사실 이렇게 하기 위해 노력해야 하는 것은 맞습니다. 현존하는 모든 브라우저를 지원할 것이고 초기 렌더링을 막는 JS도 로딩할 필요가 없다는 뜻이니까요.

다만, 앞서 말한 것처럼 피그마나 포토샵이 JS 없이 어떻게 돌아갈지 상상이 가지 않습니다. 그리고 많은 사람들이 JS 때문에 접근성이 잘 고려되지 않는다고 생각하지만, 때론 접근성 기능을 넣는데 JS가 필요할 수도 있습니다.

Mozilla에 있을 때 배운 것 인데, Tab으로 요소를 이동한 뒤 화살표로 해당 요소 내에 있는 항목을 순회하는 것은 JavaScript가 없으면 구현할 수 없습니다. 심지어 저는 어떤 웹 사이트들은 JS를 더 (잘) 썼으면 좋겠습니다.

“웹 개발에서 빌드 과정은 필요 없다”

최근에 본 글 중에 이 같은 주장을 한 것을 봤습니다. 한평생 컴파일 언어로만 개발해온 저로서는 이해하기 힘든 부분입니다. 컴파일러는 대단한 기술입니다. 구닥다리 같은 내 코드를 몇 단계의 과정을 거쳐 컴퓨터가 수행할 수 있는 아주 효율적인 코드로 만들어주니까요.

물론, JavaScript 언어의 불완전함을 알고 있습니다. 컴파일 하기 까다로운 것도 이해합니다. 하지만, JavaScript 컴파일 단계도 분명 더 개선할 점이 있습니다.

이미지 에셋이나 정적인 HTML은 미리 빌드하는데 동의하는 웹 개발자들이, 코드를 정적으로 컴파일 해놓는 것에 반대하는 것은 저로서는 이해하기 조금 어렵습니다. 미리 컴파일 해놓을 수 있는데 왜 굳이 연산과 I/O를 런타임에서 하려고 하는 걸까요?

아무튼, 2024년에는 Rust/WASM 프레임워크들이 좀 더 각광을 받아서 이쪽 분야에서 두각을 나타냈으면 좋습니다.

“제 블로그가 웹 개발의 전형적인 예시”

브라우저 개발자에서 웹 개발자로 돌아온 저에게 웹 개발은 미지의 세계였습니다. 웹 개발자들이 주장하는 대부분의 것들이 놀라웠던 이유는 대부분 제가 직접 경험해보지 못했기 때문입니다.

Mozilla를 퇴사하고 지난 4년 간 저는 웹 개발자로 어떤 웹 앱을 만드는데 많은 시간을 할애했습니다. 그리고 동시에 이 블로그를 개발했습니다. 신기하게도, 이 블로그와 제가 만들고 있는 웹 앱은 웹 개발이라는 세계에서 양극단에 있는 것 같습니다. 서로 겹치는 기술이 없어요.

제가 하고 싶은 말은, 당신이 경험하고 있는 게 웹 개발의 전부는 아닐 겁니다. 웹 개발은 너무나 큰 세계고 우리의 상상을 아득히 뛰어넘는 곳입니다.

---

저도 제가 경험한 개발 세계는 극히 일부라고 생각하는데 비슷한 생각을 풀어낸 글이라 공유합니다. 비단 개발 뿐만 아니라 대부분의 영역이 여러 사람들의 집단 지성으로 이루어 졌을텐데, 한 개인이 그 영역을 다 이해하기란 불가능하다고 생각합니다. 물론 사람이 아니라 ChatGPT 같은 LLM이라면 가능할 수도? 😎

원글: https://birtles.blog/2024/01/06/weird-things-engineers-believe-about-development/#my-blog-is-representative-of-web-development-at-large