조용히 스며드는 프런트엔드의 가치 절하

원문: Josh Collinsworth, "The quiet, pervasive devaluation of frontend"

제가 주목하고 있는 동향이 있습니다. 아니, 최소한 그렇게 느끼고 있다고 생각합니다. 하지만 이건 확신하기 어려운 종류의 문제입니다. 정말 사실일 수도 있고, 아니면 단지 특정한 관점에서 바라보았을 때만 사실처럼 보이는 것일지도 모르죠.

제가 옳은 건지 아니면 임의의 잉크 얼룩에서 떠올린 형상들이 실제로 관찰한 대상보다 제 자신을 더 많이 드러내고 있는 건지는 알 수 없습니다.

어쩌면 둘 다일지도 모릅니다. 아마도 이 모든 것은 주관적인 회색 지대일 뿐이고 저는 단지 선을 긋기 위해 한 지점을 선택했을 뿐입니다.

결론은 여러분 스스로 판단하시기를 바랍니다.

프런트엔드 업무가 광범위하게 축소되고 있다는 느낌을 받습니다. 거의 어디를 보든 프런트엔드의 중요성은 과소평가되고, 프런트엔드만의 고유 과제는 대수롭지 않게 여겨지는 것 같습니다.

지금 당장은 이러한 현상이 보이지 않을 수도 있습니다. 그래서 반사적으로 그런 현상은 없다고 말할 수도 있겠죠.

어쩌면 그 말이 맞을지도 모릅니다. 어쩌면 그런 현상은 없을 수도 있고, 단지 제 작은 지하 사무실에서 작은 화면을 조금 덜 바라볼 필요가 있을지도 모르죠.

혹은 어쩌면 이건 단지 여느 무의식적 편견과 같은 건지도 모릅니다. 문제가 무엇인지 알기 전까지는 너무 당연하게 느껴져 미처 존재하지 않는 것처럼 보일 수도 있으니까요.

그러니 제가 본 것에 대하여 이야기해 봅시다. 아마 여러분도 보게 될지 모르니까요.

프런트엔드 언어를 이야기하는 방식에서 보는 프런트엔드의 가치 절하

CSS는 다음과 같은 특성들로 흔히 평가됩니다. 유지관리가 어렵고, 주관적이며, 혼란스럽고, 다루기 까다로우며, 예측 불가능하고, 스스로 발등을 찍는 도구며, 지나치게 복잡하고, 확장성이 부족하며, 그야말로 악몽이라는 것입니다.

(저는 대체로 이 모든 주장에 동의하지 않습니다. 그렇지만 저자가 형편없을 때 CSS가 그 책임을 떠안는 유일한 언어라는 점은 인정하는 편입니다.)

이런 평가에도 불구하고 또 한편으로 CSS는 "진짜 프로그래밍 언어가 아니"라고 여겨집니다. 많은 사람들이 온라인에서 이 주장을 강하게 내세우며, 때로는 밈(meme)까지 활용하기도 합니다. HTML 역시 비슷한 취급을 받고 있습니다.

CSS는 마치 기묘한 양자 상태에 존재하는 것 같습니다. 한편으로는 너무 복잡해서 사용하기 어려운 동시에 너무 단순해서 진지하게 받아들여지지 않는 상태인 거죠.

제가 생각하기에 대부분의 사람들이 실제로 말하려는 바는 이겁니다. HTML과 CSS는 스크립팅 언어가 아니라는 것이죠. 이는 a) 물론 맞는 말이지만, b) 그게 핵심은 아닙니다.

CSS는 프로그래밍 언어입니다. 왜냐하면 CSS를 작성할 때 바로 그 일을 하고 있기 때문입니다. 애플리케이션의 프레젠테이션 로직을 프로그래밍하는 거죠. 그리고 이건 매우 중요합니다. CSS는 소프트웨어의 사용성을 극대화하거나 반대로 완전히 망쳐버릴 수도 있는 강력한 도구이기 때문입니다. (정말 CSS만으로 웹에서 무엇이든 완전히 망치는 방법이 얼마나 많은지 알게 되면 깜짝 놀랄 겁니다.)

CSS는 여러 면에서 사용자 경험에 다른 어떤 언어보다 큰 영향을 미칩니다. 이 사용자 경험은 종종 성공 여부를 직접적으로 좌우합니다. 그런데도 CSS의 역할은 왜 이렇게 과소평가될까요?

HTML도 마찬가지입니다. 반복문과 조건문 같은 기능은 없지만 HTML은 여전히 프로그래밍 인터페이스입니다. 왜냐하면 UI를 프로그래밍하는 방식이기 때문이죠. 그리고 HTML을 잘하려면 다른 어떤 언어만큼이나 세심한 주의와 전문성이 필요합니다.

언어는 현실입니다

이 모든 말은 사소하게 들릴 수도 있습니다. 단지 온라인에서 벌어지는 일부 사소한 논쟁에서 제 입장을 주장하는 것처럼 보일 수도 있죠. 개발자들이 온라인에서 무슨 말을 하는지 누가 신경이나 쓰겠어요? (90년대에 우리가 종종 했던 말처럼) 여러분 인생이나 잘 사세요.

하지만 저는 사실 이 문제에 신경 써야 할 아주 중요한 이유가 있다고 믿습니다.

프런트엔드 언어가 프로그래밍 언어가 아니라는 주장은 프런트엔드 언어를 작성할 때 우리가 하는 일이 프로그래밍이 아니라 그저 다른 어떤 작업이라는 주장을 내포합니다.

아마도 명시적으로 말하지 않더라도 부인할 수 없는 암묵적인 의미를 담고 있습니다. 프런트엔드 언어는 무언가 덜 중요하다는 의미를요.

그리고 맞아요. 편견이라는 게 있다면, 프런트엔드 개발자에 대한 편견이 있다고 해도, 그것이 일상 사회에서 존재하는 수많은 다른 편견들보다 더 우위에 있다고 보기는 어렵겠죠...

... 그런데 이 편견이 사실 그 다른 편견들의 일부라면 어떨까요?

프런트엔드는 개발자들 사이에서 가장 다양한 직무 타이틀을 가진 분야입니다. 시스젠더 헤테로섹슈얼(cishet) 백인 남성이 아닌 사람들이 가장 많은 개발 분야를 찾으려 한다면 여러분은 프런트엔드를 선택하게 될 것입니다.

프런트엔드에 대한 언어가 단순한 우연으로 이렇게 다르게 자리 잡았다고 정말 믿으시나요?

업무를 이야기하는 방식에서 보는 프런트엔드의 가치 절하

어떤 일들은 중요하고, 존엄하며, 명예로운 것으로 평가받습니다.

의사, 변호사, 건축가, CEO, 소프트웨어 엔지니어.

어떤 직업은 "진지한" 일로 여겨지며, 이는 긍정적입니다. 다만 그 말은 암묵적으로 다른 직업들은 진지하지 않다는 의미를 내포하기도 합니다.

우리는 이 말을 직접 하지 않거나 심지어 그런 생각을 하지 않을 수도 있습니다. 그러나 어떤 사람들을 영웅으로 묘사할 때 우리는 다른 사람들을 조력자의 역할로 밀어 넣게 됩니다. 그들의 노동이 덜 중요하거나 성공으로 나아가는 데 덜 기여하는 일이 아님에도 불구하고 말이죠.

간호사, 법률 보조원, 인테리어 디자이너, 경영 지원가, 프런트엔드 개발자.

(첫 번째 그룹이 두 번째 그룹보다 더 남성적이라는 것은 우연일까요?)

다른 형태의 개발은 대체로 진지한 일로 간주됩니다. 중요하고 진짜 컴퓨터 과학입니다. (컴퓨터 과학 자체는 우리가 실질적이고, 진지하며, 중요하다고 여기는 더 높은 수준의 것들 중 하나입니다. 의학이나 법률만큼은 아니지만 어떤 분야에서는 그만큼 중요할 수도 있습니다.)

엔지니어링은 의심할 여지없이 어렵고 존경받는 일입니다. 다른 엔지니어들이 똑똑하다는, 심지어 우리보다 훨씬 더 똑똑하다는 생각은 너무 흔하고 진실처럼 여겨져 거의 의문을 제기하지 않습니다.

대개 실제로 아무도 프런트엔드가 덜 중요하거나, 덜 실질적이거나, 이를 수행하기 위해 덜 똑똑해야 한다고 말하지 않습니다. 하지만 암묵적으로는 자주 그렇게 여겨지는 것 같습니다.

이 인식의 기원을 추측해 본다면 그건 아마도 시각적인 요소에서 비롯되었을 것 같습니다. 프런트엔드 엔지니어는 숙련되기 악명이 높은 어려운 언어들로 작업하지만 배우기는 상대적으로 직관적인 언어들을 사용합니다. 많은 엔지니어들이 기본만 배우고 다른 것들로 넘어갑니다. 물론 그게 문제는 아닙니다.

하지만 저는 이것이 더닝-크루거 효과(Dunning-Kruger effect)를 초래한다고 봅니다. 즉 배워야 할 것을 배우지 않은 사람들은 실제로 그 위험한 간극을 결코 인지하지 못한 채, 익숙한 지식에 의존하여 이미 저질렀을 수도 있는 실수를 반복할 수 있다는 것입니다.

대부분의 엔지니어링 관리자와 개발자들을 책임지는 사람들이 HTML, CSS, JavaScript 정도는 알 것이라고 생각합니다. 이런 언어들은 많은 개발자들이 초기에 다루는 기본적인 것들이죠.

그런 그들이 프런트엔드 개발자를 바라볼 때 무의식적으로 "나도 할 수 있을 것 같다"라는 생각을 가지게 되는 것 같습니다.

우리의 결과물은 어느 정도 예술적입니다. 그리고 예술적인 것들은 단순히 간단하고 즐겁게 보이기 때문에 안타깝게도 그 가치를 폄하당한 오랜 역사가 있습니다.

예를 들어 우리의 작업 흐름과 결과물을 백엔드 개발자나 사이트 안정성 엔지니어와 비교해 보세요. 그들은 위협적인 터미널, 방대한 데이터, 난해하게 서로 얽힌 시스템 속에서 일합니다. 그들이 하는 일은 무서워 보이며, 나는 할 수 없고 하기 싫을 일인 것만 같습니다.

그들의 결과물은 손쉽게 측정할 수 있습니다. 새로운 API 기능, 더 효율적인 데이터베이스, 위기를 피하고 충돌을 예방하는 일들. 차트에 기록되고 이사회에 보고됩니다.

하지만 우리의 일은요? 훨씬 더 측정하기 어렵습니다.

대부분 사람들은 그저 비평할 뿐입니다.

예술처럼요.

이름 짓기는 어렵습니다

프런트엔드에 종사하는 사람의 직무가 명시적으로 소프트웨어를 개발하는 일이라는 것은 분명하지만, "소프트웨어 개발자"나 (어쩌면 훨씬 더 존중받는 "소프트웨어 엔지니어") 같은 존중받는 직함은 다른 의미를 아주 강하게 내포하고 있다는 사실을 알고 계셨나요?

우리 직함에 "엔지니어"라는 단어가 정말 포함된다면 그것은 거의 우리가 무엇을 엔지니어링하는지 확실히 명시하는 셈입니다. UI 엔지니어, 프런트엔드 엔지니어, 혹은 더 최근의 (그리고 어쩌면 더 적합한) 디자인 엔지니어일 수 있습니다.

하지만 아마도 다른 자격 조건이 없으면 "소프트웨어 개발자"나 "소프트웨어 엔지니어"라는 직함은 주어지지 않을 것입니다. 왜냐하면 그것은 암묵적으로 우리가 하는 일이 아니기 때문입니다.

그건 다른 누군가가 하는 일입니다. 우리가 하는 일은 기껏해야 그 일의 일부일 뿐입니다. (암묵적으로 그보다 덜한 일입니다.)

물론 이는 언어의 미묘한 뉘앙스고 이러한 직함들이 그 역할을 분명히 하기 위한 것이라는 점은 이해합니다. 아무도 어느 날 앉아서 이런 직함들을 만들어낸 것이 아니고, 악의적으로 그런 것도 아니죠. 그저 언어와 시간의 산물일 뿐이며, 이 직함들이 그렇게 된 방식은 아마 아무도 의도한 바가 아닐 것입니다.

그럼에도 불구하고 우리는 이제 언어가 우리의 인식을 어떻게 형성하고 그로 인해 우리의 행동에 어떤 영향을 미치는지에 대한 힘을 잘 알고 있어야 합니다.

이 언어는 인터페이스가 소프트웨어와 분리되어 있으며, 실제로 그것의 일부가 아니라는 인식을 암시합니다.

정의상 우리는 매일 소프트웨어를 엔지니어링하지만 그럼에도 불구하고 우리가 하는 일을 소프트웨어 엔지니어링으로 보지 않는 이유는 무엇일까요? 소프트웨어 엔지니어링과는 다르며, 그보다 더 부드러운 일이기 때문일까요?

물론 컴퓨터 과학 학위를 취득하거나 데이터 구조와 알고리즘에 관한 화이트보드 문제를 푸는 데 필요한 기술을 존중해야 합니다. 그러나 왜 그런 종류의 기술만을 존중해야 할까요?

왜 사람들의 일은 "더 많은" 것이어야만 할까요?

왜 모든 일이 그 자체로 중요하고 도전적일 수 없는 걸까요?

여성화된 프런트엔드 코드에서 보는 프런트엔드의 가치 절하

CSS를 작성하는 일은 마치 회의에서 회의록을 작성하는 일처럼 여겨지는 것 같습니다. 회의실에서 회의록 작성자의 역할은 분명히 중요한데도 그 중요성은 암묵적인 성차별과 함께 과소평가되곤 하죠.

프로젝트에 반드시 필요한 작업임에도 프런트엔드 작업은 이를 자신보다 하찮게 여기는 사람들에게 자주 무시당합니다 (대개 남성인 이 사람들은 노골적으로 무시하지는 않지만 은연중에 그런 태도를 드러냅니다). 프런트엔드 작업은 충분히 진지하지도, 충분히 중요하지도, 충분히 진짜 같지도 않다고 여겨지며, 너무 애매하고 말랑한 소프트 스킬처럼 취급되곤 합니다.

물론 프런트엔드 작업이 중요하다는 데는 누구나 동의합니다. 누군가는 반드시 해야 하는 일이니까요. 하지만 이 작업은 보통 더 크고 중요한 문제에 그들의 귀중한 관심을 쏟아야 한다고 여겨지는, 이른바 중요한 사람들에게 주어지지는 않습니다.

디자인은 일반적으로 프런트엔드와 동일시되며 오랫동안 "여성적인" 작업으로 특정되어 왔습니다. 프런트엔드 기능의 복잡한 기술 과제들은 종종 픽셀로 그림을 그리는 작업으로 오해를 받습니다. 제대로 작동하게 만드는 것보다 단순히 보기 좋게 만드는 일로 여겨지는 것이죠.

덧붙여 UI와 디자인 분야에 종사하는 사람들은 "더 기술적"으로 여겨지는 동료들에 비해 구조조정에서 더 큰 타격을 받는 경향이 있습니다. 마찬가지로 여성들이 남성들보다 해고될 가능성이 더 높습니다. 따라서 프런트엔드의 가치 절하와 성차별이 서로 얽혀 있다고 보지 않기는 어렵습니다. (물론 이 둘이 전혀 별개의 문제인지조차 불분명하지만 말이죠.)

프런트엔드 개발자를 이야기하는 방식에서 보는 프런트엔드의 가치 절하

프런트엔드는 복잡합니다. 이에 대해 이의를 제기할 사람은 거의 없을 겁니다.

그럼에도 불구하고 어떤 이유로 다른 형태의 엔지니어링의 어려움은 보통 컴퓨터 자체의 방대한 복잡성 때문이라고 간주되지만 (그리고 또 그 복잡성과 맞서 싸우는 사람들은 대개 경외의 시선을 받습니다), 프런트엔드가 복잡한 이유는 단지 프런트엔드 개발자들 스스로가 그렇게 만들었다는 근거 없는 믿음이 널리 퍼져 있습니다.

마치 우리가 단순히 몰라서 프레임워크, 컴파일러, 수많은 패키지를 프로젝트에 추가했다는 식으로 말이죠.

마치 과거, 현재, 미래의 가능한 모든 기기, 운영체제, 화면 크기, 브라우저, 사용자 선호도, 인터페이스를 지원해야 하는 거의 불가능한 작업이 너무 단순해서, 우리가 단지 심심해서, 그 모든 복잡성을 스스로 만들어낸 것처럼 취급받는다는 겁니다.

프런트엔드 개발자들에 대한 농담은 많습니다. 그 자체로는 전혀 문제가 없습니다. 오히려 그런 농담을 우리가 직접 만들기도 하고, 우리 자신을 대상으로 한 농담을 즐기기도 하죠. 게다가 다른 전문 분야에 대한 농담도 많으니 말입니다.

우리는 새로운 것에 대한 열정을 두고 농담하는 것을 좋아합니다. 우리가 항상 새로운 프레임워크를 만들어 내고, 언제나 최신 트렌드를 쫓아다닌다고 말이죠.

이런 농담은 적당한 선에서 끝난다면 괜찮습니다… 문제는 그 농담이 우리를 향한 실제 인식으로 굳어지기 시작할 때입니다. 우리의 명성이 농담으로 전락해서 점점 우리가 덜 진지하게 받아들여지게 되는 순간 말이죠.

프런트엔드 개발자 집단으로서 물론 우리는 새로운 것에 열광합니다. 하지만 왜 그 점이 우리가 호기심이 많고, 적응력이 뛰어나며, 탐구적이라는 의미로는 해석되지 않는 걸까요? 왜 우리는 배움의 기쁨을 즐기는 사람들로 평가받기보다 제자리에 머무르기를 거부한다고 폄하받는 걸까요?

왜 우리는 최소한의 신뢰조차 얻지 못하는 걸까요?

브라우저는 빠르게 변화하고 있으며 최근 몇 년 동안 전례 없는 속도로 발전해 왔습니다. 그런데도 프런트엔드 개발자들이 기술 선택에서 그렇게 고집스럽게 굴어야 한다는 전제는 도대체 어디에서 비롯된 것인지 의문입니다.

상황이 끊임없이 변화하고 있다면 우리는 당연히 끊임없이 재평가를 시도해야 하는 것 아닐까요?

변화에 발맞추고, 더 나아지고, 새로운 가능성으로 기존의 아이디어를 재해석하려는 노력이 당연한 것 아닌가요?

우리가 단지 반짝이는 것만 좇는 가벼운 까치 같은 존재로 치부되지 않을 자격이 있지 않나요?

우리의 책임에서 보는 프런트엔드의 가치 절하

(여러분의 경험은 물론 다를 수도 있겠지만) 제 경험상 프런트엔드 엔지니어들은 프로젝트에서 자주 "문제 해결사"로 배치됩니다. 우리는 접근성, 성능, 사용자 경험과 관련된 비용이 많이 드는 실수를 쉽게 발견할 수 있는 초기 단계에 포함되지 않는 경우가 많습니다. 대신 이미 모든 것이 구축된 후 더 이상 큰 변경을 할 수 없는 마무리 단계에 투입됩니다. 그때 우리의 역할은 단지 더 보기 좋게 만드는 일이 되어버립니다.

"여기요. 다른 사람들이 이미 만들어 놓은 거예요." (즉 진짜 중요한 작업은 이미 다 끝났다는 의미죠.) "이제 당신이 이걸 고쳐주기만 하면 됩니다."

그런데... 왜 이게 제대로 작동하지 않을까요?

왜 처음부터 잘못된 제품을 만들어 낸 과정을 점검하지 않는 걸까요?

우리의 기술이 조직 내 결함을 메우는 응급처치용 테이프 같은 가치가 있다면 왜 그 결함을 만들었던 계획과 의사 결정 단계에서는 가치 있는 기술로 인정받지 못하는 걸까요? 우리가 해당 결함을 미리 예방할 수 있었을 텐데요.

왜 우리는 끝나고 나서 조금 더 보기 좋게 꾸미기 위해 불려 오는 단순한 장식가로 취급될까요?.

(마치 장식가가 고급 페인트와 멋진 가구만으로 접근성이 전혀 없는 건물을 고칠 수 있다고 생각하듯 말이죠.)

우리에게 기대되는 것에서 보는 프런트엔드의 가치 절하

프런트엔드 엔지니어가 알아야 할 기술 목록은 끊임없이 늘어나고 있습니다. 몇 달 만에 HTML, CSS, JavaScript만 배워서 취업 준비를 마칠 수 있었던 시대는 이제 거의 지나갔습니다.

HTML만 해도 제대로 이해하려면 두꺼운 책 한 권 분량이 필요합니다. 그런데도 HTML은 종종 프런트엔드 개발자가 알아야 할 가장 기본적인 요소로 여겨집니다.

그다음은 CSS와 JavaScript 자체, 그리고 그 무수한 특이점들입니다. 당연히 프레임워크도 알아야 합니다 (보통 최소 두 개 이상의 프레임워크를 알아야 하며, 여기에는 회사에서 여전히 사용 중이고 결코 완전히 교체하지 않을 레거시 프레임워크도 포함될 것입니다). 또한 수많은 애드온, 플러그인, 패키지를 다루는 방법과 이 모든 것을 관리할 시스템도 필요할 것입니다.

접근성도 중요한데, 너무 복잡하고 세밀한 주제여서 거의 아무도 완벽하게 이해하지 못합니다. 그러나 프런트엔드에서는 그게 여러분의 일이기는 해도, 전부가 아니라 일부일 뿐입니다. 행운을 빌어요!

또한 SEO에 대한 지식도 필요하며, 이를 잘하려면 거의 전담해야 할 정도로 집중해야 합니다. 그러나 여러분은 그 시간의 일부만을 할애해 SEO를 관리할 것으로 기대받습니다.

물론 디자인도 알아야 하며, 사용자 인터페이스와 사용자 경험의 모든 원칙이 포함됩니다. 이 모든 것을 배우는 데는 몇 년이 걸릴 수 있습니다.

점점 더 법적 규정에 대해서도 알아야 하고, 마케팅 역시 하나의 대학 전공처럼 깊이 있는 지식이 요구됩니다.

최소한 약간의 TypeScript도 알아야 합니다. 그리고 생각해 보니, 아마 적어도 하나의 백엔드 언어도 배워야 할 것입니다. ("그래야 스스로 문제를 해결할 수 있죠"라는 이유가 주어지지만 "그래서 자신의 일뿐만 아니라 누군가의 일을 조금이라도 처리할 수 있도록"이 더 정확할 때도 있습니다.)

그 뒤에는 몇몇 애니메이션 라이브러리들이 추가될 수도 있습니다. 차트와 데이터 시각화, 테스트 및 검증 라이브러리, 커맨드라인 유틸리티, 쿠키, 캐싱 (그리고 캐시 무효화), DNS, 네트워크, 성능, 에지 컴퓨팅, 서버리스, GraphQL, AWS, Docker, 데이터베이스에 대한 최소한의 지식이 필요할 수 있습니다. 이메일에 대해 얼마나 알고 있나요? 정규 표현식은 얼마나 잘 작성할 수 있나요? 아, 그리고 마케팅 팀은 여러분에게 그들의 분석을 파헤쳐 보라고 합니다. 어쩌면 A/B 테스트도 진행해야 할 겁니다.

이 글의 이전 버전에서는 상태 관리 라이브러리와 보안에 대해 전혀 언급하지 않았습니다. XSS 공격을 방지하려면 어떻게 해야 할까요? CORS는요? 콘텐츠 보안 정책은 어떻게 적용하나요?

그 목록은 끝이 없습니다. 그럼에도 불구하고 이렇게 끊임없이 늘어나는 기술 목록에도 불구하고, 프런트엔드는 여전히 진짜 개발 작업이 아닌 사소한 일로 취급됩니다.

마케팅에서 보는 프런트엔드의 가치 절하

프런트엔드 도구들은 마치 프런트엔드가 아무도 하고 싶어 하지 않는 일이며, 꼭 필요한 수준 이상으로 신경 쓸 필요조차 없는 일인 것처럼 스스로를 마케팅합니다.

모든 도구는 프런트엔드를 간단하고 빠르게 만들어 준다고 약속합니다. 오직 그것만이 유일한 관심사인 것처럼요. 마치 제가 다섯 살 난 아이에게 백신 주사가 금방 끝나고 아프지 않을 거라고 안심시키듯 프런트엔드도 생각 없이 빨리 끝내야 할 필요한 절차로 여겨지게 만드는 겁니다.

그런데 언제부터 속도가 가장 중요한 관심사가 되었을까요? 그리고 왜 그렇게 되었을까요?

물론 "빠른 프로토타이핑"은 좋은 일입니다. 하지만 이제는 그것만이 전부인 것처럼 느껴지기도 합니다.

때로는 다른 개발자들이 그냥 무언가를 만들어내고 거의 바로 버려버리는 건 아닐까 하는 생각이 듭니다. 요즘은 아무도 작업물을 실제로 유지관리하지 않는 걸까요? 프런트엔드는 이제 단순한 조립 라인 작업이 되어버린 걸까요? 시간을 최소화하며 결과물을 극대화하는 것만이 성공의 유일한 기준이 된 건 아닐까요?

이렇게 급박한 속도를 추구하며 우리가 무엇을 희생하고 있는지, 누군가는 고민하고 있을까요? 가능한 한 빠르고 프로토타입에 가까운 인터페이스를 만들기 위해 달려가면서, 그 과정에서 품질, 좋은 아이디어, 접근성, 사용자 경험을 그냥 지나치고 있는 건 아닐까요?

그렇게 보이지 않습니다. 이런 속도를 자랑하는 도구들은, 이 도구들만 사용하면 다른 일들 (말로는 표현되지 않는 암묵적으로 "더 중요한 일들")로 넘어갈 수 있다고 약속합니다.

프런트엔드의 모든 문제는 그냥 워드프레스 플러그인 하나만 설치하면 해결되는 것처럼 말이죠.

여기에 AI 도구의 확산도 한몫하고 있습니다. 누군가는 백엔드를 자동으로 구축해 주는 AI 제품을 개발 중일지도 모릅니다 (이미 그런 제품이 시장에 나와 있을지도 모르죠). 하지만 그동안 저는 몇몇 프런트엔드용 AI 도구를 이미 본 적이 있습니다. 그들이 만들어 내는 코드는 접근성도 부족하고 설계도 제대로 되어 있지 않았으며, 이런 문제를 지적하는 데는 헌신적인 프런트엔드 엔지니어들이 필요했습니다. 그 도구를 만든 회사들은 그런 문제를 알지 못했거나 관심이 없었죠 (혹은 둘 다였을 수도 있습니다). 그들에게 중요한 것은 단지 화면에 무언가를 가능한 한 빠르고 쉽게 띄우는 것뿐이었으니까요.

목표가 "충분히 좋은"것이 되어버린 과정에서 보는 프런트엔드의 가치 절하

웹은 접근성 없는 코드로 정말 가득 차 있습니다. 그 특정한 문제가 현재 여러분에게 영향을 미치지는 않더라도 제출되지 않는 폼, 보이지 않는 버튼, UI에서 발생하는 오류, 완전히 깨진 레이아웃, 모바일 장치나 특정 브라우저에서 작동하지 않는 기능, 읽기 어려운 텍스트와 글꼴, 확대나 스크롤이 불가능한 인터페이스, 고장 난 상호작용, 무성의하거나 유용하지 않은 오류 메시지 등은 매일 혹은 거의 매일 마주치게 될 가능성이 큽니다.

물론 이는 웹의 동질화된 모습은 굳이 말할 필요도 없습니다. 똑같은 텍스트, 색상, 사용자 드롭다운 메뉴, 주의를 끌기 위해 표시된 작은 원과 그 안의 숫자, 마케팅 요소, 세 개의 컬럼으로 나뉜 레이아웃, 히어로 이미지와 커다란 버튼, 무언가를 클릭할 때마다 어김없이 나타나는 희미하게 깜박이는 스켈레톤 UI. 이런 요소들이 웹 곳곳에 넘쳐납니다.

미적으로 우아하고 기능적으로도 뛰어난 디자인을 갖춘 사이트는 안타깝게도 극히 드뭅니다. 이는 가능한 한 빠르게 제품을 출시하려는 우리의 추구가 가져온 직접적인 대가라고 저는 개인적으로 생각합니다.

이제는 더 이상 아무도 프런트엔드를 제품의 핵심적인 부분으로 여기지 않는 것 같습니다. 그저 제품을 담아내는 보기 좋은 상자 정도로만 취급합니다.

우리는 프레임워크가 필요합니다. 리액트면 충분하죠. 다른 걸 더 찾아볼 필요는 없어요.

그냥 예쁜 색상 하나와 쓸 만한 글꼴 하나만 고르면 됩니다. 아니, 커스텀 CSS를 작성할 필요도 없어요. Tailwind에서 제공하는 기본 설정만으로도 충분하니까요.

그저 다음 단계로 넘어가기만 하면 되는 거예요. 왜냐하면 이 프로젝트에서 진짜 중요하고 진지한 부분은 이게 아니니까요. 프런트엔드가 아니죠.

모든 사용자가 제품을 사용할 때마다 반드시 보고 상호작용하게 되는 바로 그 부분인데도 말입니다.

모든 곳에서 보이는 프런트엔드의 가치 절하

하지만... 그럼에도 또 어쩌면 그건 단지 제 생각일 뿐이겠죠.

제가 너무 자기 연민에 빠져 있는 걸 수도 있습니다. 그냥 지금 기분이 조금 우울한 걸지도 모르고요. 아니면 제가 가진 열등감 콤플렉스를 다른 모든 사람들에게 투영하고 있는 건지도 모르죠.

아니면... 이건 정말 사실일 수도 있습니다.

어쩌면 둘 다일지도요.

결국 이건 여러분이 판단할 문제입니다.

그렇지만 그냥 여러분의 눈을 한번 크게 떠 보세요. 알겠죠?

전에 놓쳤던 무언가를 여러분이 볼 수도 있으니까요.