프론트엔드 개발에 대한 생각

개인적으로 공통단에 대해서 관심이 많다. 개발을 처음 독학으로 시작할때 부터 어지간한 프로그램을 이해하는데 큰 어려움이 없었고 어지간한 것들은 그 내부를 보지 않고도 어떻게 구현해야할지 직관이 가능했는데(분야에 상관없이 허와 실을 직관하는데 재능이 있는 편이다.) 그래서 그런지 처음부터 개발을 하면서 클린코드나 설계등에 대해서 꾸준히 관심을 가지고 관련해서 공부도 해보고 나름대로 이해도 하고 직접 적용해보고 응용도 하는 등 꾸준히 행해왔다.

더욱이 웹이라는 고수준으로 추상화된 환경에서 보편적인 기능을 개발하는데 특이한 경우가 아니라면 사실 특출난 알고리즘이나 최적화를 통한 성능적인 고려를 할 필요가 거의 없고 문제 없는 설계에 집중하는 것 만으로도 성능을 어느 정도 잡아 낼 수 있었기에 더욱 그러했다.(클린코드? 또는 리팩토링이라는 책에 비슷한 내용이 있는데 개인적으로 공감한다.)

즉, 잘못된 방식이 아닌 코드를 짜기만 해도 추상화된 내부에서 자동으로 성능 등의 요소를 최적화 해주니 거의 대부분의 경우에서 클린코드만 신경써도 성능을 고려할 필요가 없는데다가 클린코드를 통해서 생산성이나 전체적인 소프트웨어 품질을 올릴 수 있다.

그냥 간단히 말하면 기본에만 충실하면 특별한 기교 없이도 균형 잡힌 소프트웨어를 만들 수 있다는 것. 그리고 본질적으로도 그게 맞다. 고수준으로 추상화된 레이어에서 그 아래 레이어와 동일한 관심사를 가진다는건 사실 설계적인 측면에서부터 잘못된 것이니까. 정 최적화가 필요한 사항이 있다면 추상화된 블랙박스를 직접 열어서 하위 레이어로 내려가야하는게 맞는거지 다른 추상화 단계에서 주로 고수준 언어의 경우 성능 최적화나 메모리 관리등을 자동화하고 가독성등 다음 단계에 집중하는데 거기서 추상화 레벨이 다른 소스가 존재한다는게 정상적이라고 볼 수 있을까? 애초에 처음부터 그런 목적을 가진 경우가 아니라면...(물론 사고의 위험은 항상 존재하며 언제나 블랙 박스를 열어야 할 수 있지만)

개인적으로 그런 상황이다보니 전문화로 택한 프론트엔드에서 역시 공통이나 설계에 대한 노력을 많이 투자 하는 편이다.
아키텍쳐에 대해서 자료를 찾아보고 분석하고 고민하고, 디자인 패턴들의 장단점을 비교 분석하고 그런 것들. 웹프론트 자체가 기본적으로 HTML, CSS, JS를 베이직으로 전반적인 개발이 이루어지기에 기본적인 CSS와 HTML 기본기 그것도 퍼블리셔(UI개발자)적인 부분보다는 프론트엔드가 집중해야 할 DOM이나 CSSOM등 렌더링에 관련 된 요소들 특히 HTML의 경우 시맨틱 마크업을 하려고 노력하는 편이다.

왜냐하면 DOM 구조가 프론트엔드 입장에서는 자료구조와 같기에 렌더링 성능이나 DOM 조작 성능이 당연하게도 DOM 구조에 영향을 받는다. 그렇기에 불필요한 요소는 최대한 덜어내고 견고하고 안정적인 DOM을 짜는 것이 가장 기본적이다. 주로 그러자면 해당 구성을 정확히 정의를 내려야하고 그러자면 시맨틱을 지키는게 합리적이다. 그게 웹 컴포넌트 개발로 넘어오면 거기다 컴포넌트 구조(js) 라는 부분 까지 추가된다. 퍼블리셔가 존재한다면 퍼블리셔가 CSSOM과 DOM을 고려하고 웹프론트엔드가 컴포넌트 위주로한 렌더링을 주로 보겠지만 결국 웹페이지 성능에 영향을 주는 요소로 JS뿐 아니라 HTML과 CSS의 영향이 큰편이기에 전문성을 위해서는 프론트엔드도 해당 부분에 대해서 잘아는 것이 좋다.(위에서 말한 것 처럼 추상화 레벨이 다르긴 하지만 하위 레이어가 어떻게 돌아가는지 잘 아는건 실력에 도움이 된다.)

그리고 CSS 역시 HTML 과 마찬가지로 렌더링에 영향을 준다. 리플로우와 리페인트 라는 개념이나 GPU를 사용하는 속성들 그를 사용하지 않는 속성들 같은 간단한 수준과 중복되는 것들을 관리해서 CSSOM을 최적화 하는(사실 크게 중요한 부분은 아니라고 보이지만) 것 등 다양한 부분들, 그리고 이런 것들을 기반으로 깔고 웹 컴포넌트로 가서 흔히 아는 최적화를 진행한다.

웹 프론트에서는 시맨틱이라는 개념이 많이 나오는데 사실 본질적으로는 벡엔드도 이와같다. 보통 클린코드라는 용어로 지칭하고 있을뿐. 사람이 알아보기 쉽게 시맨틱하게 코드를 짜는 것. 다만 벡엔드와 차이가 있다면 벡엔드는 개발자만이 코드를 확인 하지만 프론트는 웹사이트를 이용하는 사용자까지 코드를 어떤식으로든 접하게 된다는 것이다. 검색엔진의 크롤러 봇들이 웹사이트의 구조를 이해하는데도 영향을 주고(SEO) 일반 사용자 같은 경우에도 해당 하지만 특히 스크린 리더등 기기를 이용하는 사용자의 경우에는 코드의 구조 자체가 해당 사이트의 컨텐츠를 이해하고 이용하는데 직접적인 영향을 주게 된다.(접근성)
물론 스크린 리더등 접근성에 대한 고려는 단순히 시맨틱 마크업으로 끝나는 것은 아니다. HTML의 추가적인 속성들과 디자인적인 요소를 고려해야하는데 디자인 요소로는 이미지에 대한 것이나 CSS에 대한 것들이 존재하고 대부분 디자인 부분의 경우 svg 등 특수한 경우가 아니라면 프론트엔드 개발자 입장에선 CSS에 대한 것을 중점적으로 고려하게 되는데 CSS의 경우 HTML과 js와 밀접하게 연관성을 가지며 이 역시 시맨틱을 고려하는게 좋다.

여기서 말하는 시맨틱은 결국 두가지 측면을 가지는데 하나는 봇(또는 스크린 리더)등의 컴퓨터 입장에서의 시맨틱 또 하나는 개발자 입장에서의 시맨틱이다. 보통은 전자를 지키다 보면 자연히 후자도 지켜지게 된다.
봇이 이해하기 쉬운 구조가 사람이 이해하기 쉬운 구조보다 복잡하지 않아서 그런거 같다.

웹 프론트엔드 개발자의 경우 위의 것들을 포함해서 전체적으로 UI/UX에 중점을 두고 개발을 하게되는데 일반적으로 크롤러에 의한 파싱(SEO)나 스크린리더 사용자 같은 접근성 고려 그리고 다양한 최적화나 사용자 경험을 중점적으로 다룬다. UI 즉 사용자 인터페이스와 UX 사용자 경험을 중점적으로 고려하다보니 개인적으로는 벡엔드보다 클린코드라는 개념이 조금 더 중요시 되는 편이라고 생각된다.

실제로 같이 작업하는 벡엔드 개발자가 아니라 크롤러나 실제 사용자가 보는 문서 영역이 노출되어 있기에 더 많고 다양한 사용자가 여러 방식으로 자신이 작성한 코드의 결과물을 보게된다. 프론트엔드 개발자가 UI를 개발한다는 것에는 대부분 사람들이 동의 하지만 UX를 다룬다는 것을 인지하지 못하는 사람들이 꽤 있는데 UI와 UX는 애초에 순수한 디자인 영역의 개념이 아니며 디자인 + 엔지니어 측면이 결합된 개념으로 프론트엔드 개발자의 경우 UI/UX의 엔지니어적인 측면을 다룬다고 볼 수 있다.

프론트에서 일반적으로 고려하는 UX 적인 요소를 몇가지 예를 들어보자면 초기렌더링 속도를 통해서 사용자 이탈을 방지한다거나, 레이아웃 시프트 등 인터렉션 등을 최적화를 하는 등의 작업이 UX를 다루는 부분이다. 개인적으로 얼마전에 UX는 프론트가 아닌 디자이너 영역이 아니냐는 질문을 받은 적이 있는데 그런 사람은 사실 프론트 개발이 뭔지 깊이 이해를 못하고 있다고 볼 수 있다. 또 반대로 프론트엔드 개발자가 디자이너의 영역까지 해야한다고 생각 하는 사람도 존재하는데 그런 사람도 프론트의 역할에 대해서 이해가 부족한걸로 볼 수 있는데 안타깝게도 두 경우 모두 아직까지는 의외로 자주 보이는 편인 것 같다.

개인적으로는 프론트엔드와 UI/UX디자이너가 아직까지 역사가 비교적으로 짧고 보편적으로 볼 수 있는 직군이 아니라서 아직 성숙한 문화? 같은게 덜 이루어진게 아닌가 라는 생각을 조금 가지고 있다. 실력자가 없는 것은 아니지만 늘 이바닥은 그런 실력자가 부족하다고 아우성이니 정상적인 현상인가? 어쨌든 위와 같은 이유로 공통단과 UX에 대한 관심이 많아서 요즘 개인적으로 오픈소스 디자인 시스템이라는 것을 소소하게나마 개발을 진행하고 있다.

그리고 해당 디자인 시스템의 컨셉으로 시맨틱 UI와 시맨틱 CSS를 잡았다. 동양의 음양오행설을 기본 베이스로 삼아서 이전부터 생각해왔던 방식으로 조금씩 시행착오를 겪으면서 개발을 조금씩 진행하고 있는데 흔히 말하는 디자인감각에 의존하는 것이 아닌 철학적인 관계(음양오행의 상생상극)으로 스타일링을 표현 할 수 있을거 같다. 라는 생각에서 진행중이다. 그런 과정에서 디자인 토큰이나 디자인 시스템에 대한 자료들을 찾아보고 막연히 알고 있던 점들에 대한 이해도를 높여가고 있는데 규모가 너무 커서 그런지 귀찮기도 해서 그런지 진척이 느린편이긴 하지만 어느 정도 완성되고 나서 공개해봐야겠다.

사실 이건 예전부터 기획하던 오픈소스 중 하나 였고 업무를 하면서 디자이너가 아니다보니 디자인 감각은 없지만 이상하게 디자인들을 작업하면 크롬 라이트하우스로 볼때마다 디자인적인 요소로 인해서 접근성 이슈가 뜨는데(보통 색대비) 디자인적으로는 이쁘긴하지만 반대로 말하면 디자인적으로만 이쁘고 관습적으로 몇가지 룰을 다루는걸 제외하고 본인의 경험에 의존해서 UI/UX를 이론적인 것 없이 하는게 아닌가?라는 의문과 라이트하우스에서 그런 오류를 지적한다는 것은 그런 것 까지 고려하는 UI/UX가 최소한 구글레벨에서는 존재한다는게 아닌가? 라는 의구심을 해소하려는 시도이기도 하다.