<div id="readability-page-1" class="page"><div><p><h2 id="e483">프론트엔드는 무엇인가?</h2></p><p><h2 id="3ca4">Web Application의 패러다임은 어떻게 되는걸까?</h2></p><p id="5b58">처음에는 PHP, JSP, ASP 같은 아이들이 있었다. 웹 페이지를 만드는 템플릿 언어들을 활용해서, DB 와 템플릿을 바로 연결하고 세션, 쿠키 같은 걸 템플릿 언어에서 바로 관리하는 식의 프로그래밍을 했었다.</p><p id="6f7c">클라이언트에서 사용할 수 있는 리소스가 많아지고 (= 컴퓨팅 파워가 그만큼 강해지고), 브라우저에 그에 따라 발전해나가면서 클라이언트 자바스크립트가 가지는 힘은 굉장히 강력해졌다. 적어도 요즘 자바스크립트 메모리가 부족해서 개발이 불가능한 상황은 자주 발생하지는 않는다. 예전에는 꽤 흔한 일이었다.</p><p id="7ddf">웹 애니메이션을 구현할 때 60 FPS 를 보장해줄 수 없어서 애니메이션을 포기하는 일도 꽤 흔하게 일어나던 일이다. jQuery 에서 사용하던 <code>animate</code> 라는 메서드는 <code>setTimeout</code>으로 특정 시간만큼을 프레임화시켜서 애니메이션을 구현하는 식으로 만들었다. CSS Transition 이나 Transform이 없던 시절의 일이다.</p><p id="3f4c">어쨌든 시대는 바뀌었고, <code>requestAnimationFrame</code> 같은 브라우저 내장 메서드로 애니메이션을 요청할 수도 있게 되었고, <code>$(selector)</code> 는 <code>querySelector</code> 같은 DOM API로도 충분히 제어 가능해졌다.</p><h2 id="fd60">다시 돌아가서</h2><p id="7bc0">Deno 에서 얼마전에 <a href="https://fresh.deno.dev/" rel="noopener ugc nofollow" target="_blank">Fresh</a> 라는 이름의 웹 프레임워크가 1.0 버전으로 출시되었다. Fresh를 보면서 든 생각은 우리의 패러다임이 다시 과거로 회귀하고 있다는 사실이었다. 그리고 그것이 꼭 나쁜 것만은 아니라는 사실도 말이다.</p><p id="bdeb"><a href="https://nextjs.org/" rel="noopener ugc nofollow" target="_blank">Next</a> 나 <a href="https://astro.build/" rel="noopener ugc nofollow" target="_blank">Astro</a> 같은 MPA (Multi-Page Architecture) 가 대두되는 데에는 여러가지 이유가 있겠지만, 나 개인으로서는 Server-side 는 우리가 제어 가능한 레이어지만 Client-side 는 우리가 제어할 수 없는 영역이기 때문이라고 생각한다.</p><p id="40a2">서버는 애초에 우리가 설정해서 적절한 환경을 제공할 수 있지만, 클라이언트는 유저가 어떤 환경에서 접근할 지 판단할 수 없다. 나는 지금 맥북 프로 13인치 M1 모델을 쓰고 있지만, 어딘가의 누군가는 10년 전의 맥북 에어로 접근하고 있을 수도 있다.</p><p id="8d60">SSR은 하나의 거대한 흐름이지만, 또 한편으로는 과거에 했던 일을 다시 회귀하는 일이기도 하다. 클라이언트가 가지고 있는 한계 상황들 (어쩔 수 없는 보안 문제, 어쩔 수 없는 성능 편차)을 어떻게든 해결하기 위한 기법이기도 하다.</p><p id="8db5">다만 그렇다고 하여 SPA가 언제나 문제인 것은 아니다. 나는 여전히 백오피스같은 관리 도구를 만들 때에는 SPA가 더 유용하다고 생각하고 있다.</p><h2 id="a721">그래서 Frontend는 무엇인가?</h2><p id="d7dd">솔직히 말하자면 잘 모르겠다. 웹에서 화면에 보이는 영역을 담당한다- 라는 것을 전제로 하고 있지만 화면에 보이는 영역을 만들기 위해서는 그것만으로는 끝나지 않는다.</p><p id="c786">다양한 인터랙션을 만드는 것도 프론트엔드 개발자의 역량이고, 디자인 시스템을 만들어서 사내의 UX를 어느정도 일치시키는 것도 프론트엔드 개발자의 역량이겠지만, API를 잘 설계해서 데이터를 주고받는 행위를 용이하게 만드는 것도 프론트엔드 개발자의 역량이고, 더 나아가 DB와 연결해서 SSR을 구축하는 것도 프론트엔드 개발자의 역량이라고 생각한다.</p><p id="a963">한편으로 프론트엔드도 그 내부에서 점점 전문화 되어가고 있다고 생각한다. UX Engineer 라는 직군이 생겨나는 것도 괜히 생겨나는 것은 아니라고 생각하고, No-Code 도구를 만드는 프론트엔드 엔지니어, API &lt;&gt; Client 간 연동을 바탕으로 웹 애플리케이션을 만들어내는 프론트엔드 엔지니어 등 다양한 관심사를 바탕으로 다양한 결과물을 만들어내고 있다.</p><p id="2818">특히 No Code 도구에 대해서는 생각이 깊다. 앞으로도 다양한 No Code 제품이 나올 것이고, 거기에서 생산되는 Base Application 들과 차별화된 사용자 경험을 제공하는 애플리케이션들이 결국 살아남을 테지만, 그렇게 만들기 위해서는 무엇보다 사용자 경험에 관심을 두고 있는 프로덕트 엔지니어들이 필요하다.</p></div></div>

Stories by 조은, Eun Cho on Medium

choeun

Web Application의 패러다임은 어떻게 되는걸까?
처음에는 PHP, JSP, ASP 같은 아이들이 있었다. 웹 페이지를 만드는 템플릿 언어들을 활용해서, DB 와 템플릿을 바로 연결하고 세션, 쿠키 같은 걸 템플릿 언어에서 바로 관리하는 식의 프로그래밍을 했었다.
클라이언트에서 사용할 수 있는 리소스가 많아지고 (= 컴퓨팅 파워가 그만큼 강해지고), 브라우저에 그에 따라 발전해나가면서 클라이언트 자바스크립트가 가지는 힘은 굉장히 강력해졌다. 적어도 요즘 자바스크립트 메모리가 부족해서 개발이 불가능한 상황은 자주 발생하지는 않는다. 예전에는 꽤 흔한 일이었다.
웹 애니메이션을 구현할 때 60 FPS 를 보장해줄 수 없어서 애니메이션을 포기하는 일도 꽤 흔하게 일어나던 일이다. jQuery 에서 사용하던 animate 라는 메서드는 setTimeout으로 특정 시간만큼을 프레임화시켜서 애니메이션을 구현하는 식으로 만들었다. CSS Transition 이나 Transform이 없던 시절의 일이다.
어쨌든 시대는 바뀌었고, requestAnimationFrame 같은 브라우저 내장 메서드로 애니메이션을 요청할 수도 있게 되었고, $(selector) 는 querySelector 같은 DOM API로도 충분히 제어 가능해졌다.
다시 돌아가서
Deno 에서 얼마전에 Fresh 라는 이름의 웹 프레임워크가 1.0 버전으로 출시되었다. Fresh를 보면서 든 생각은 우리의 패러다임이 다시 과거로 회귀하고 있다는 사실이었다. 그리고 그것이 꼭 나쁜 것만은 아니라는 사실도 말이다.
fresh - The next-gen web framework.
Next 나 Astro 같은 MPA (Multi-Page Architecture) 가 대두되는 데에는 여러가지 이유가 있겠지만, 나 개인으로서는 Server-side 는 우리가 제어 가능한 레이어지만 Client-side 는 우리가 제어할 수 없는 영역이기 때문이라고 생각한다.
서버는 애초에 우리가 설정해서 적절한 환경을 제공할 수 있지만, 클라이언트는 유저가 어떤 환경에서 접근할 지 판단할 수 없다. 나는 지금 맥북 프로 13인치 M1 모델을 쓰고 있지만, 어딘가의 누군가는 10년 전의 맥북 에어로 접근하고 있을 수도 있다.
SSR은 하나의 거대한 흐름이지만, 또 한편으로는 과거에 했던 일을 다시 회귀하는 일이기도 하다. 클라이언트가 가지고 있는 한계 상황들 (어쩔 수 없는 보안 문제, 어쩔 수 없는 성능 편차)을 어떻게든 해결하기 위한 기법이기도 하다.
다만 그렇다고 하여 SPA가 언제나 문제인 것은 아니다. 나는 여전히 백오피스같은 관리 도구를 만들 때에는 SPA가 더 유용하다고 생각하고 있다.
그래서 Frontend는 무엇인가?
솔직히 말하자면 잘 모르겠다. 웹에서 화면에 보이는 영역을 담당한다- 라는 것을 전제로 하고 있지만 화면에 보이는 영역을 만들기 위해서는 그것만으로는 끝나지 않는다.
다양한 인터랙션을 만드는 것도 프론트엔드 개발자의 역량이고, 디자인 시스템을 만들어서 사내의 UX를 어느정도 일치시키는 것도 프론트엔드 개발자의 역량이겠지만, API를 잘 설계해서 데이터를 주고받는 행위를 용이하게 만드는 것도 프론트엔드 개발자의 역량이고, 더 나아가 DB와 연결해서 SSR을 구축하는 것도 프론트엔드 개발자의 역량이라고 생각한다.
한편으로 프론트엔드도 그 내부에서 점점 전문화 되어가고 있다고 생각한다. UX Engineer 라는 직군이 생겨나는 것도 괜히 생겨나는 것은 아니라고 생각하고, No-Code 도구를 만드는 프론트엔드 엔지니어, API <> Client 간 연동을 바탕으로 웹 애플리케이션을 만들어내는 프론트엔드 엔지니어 등 다양한 관심사를 바탕으로 다양한 결과물을 만들어내고 있다.
특히 No Code 도구에 대해서는 생각이 깊다. 앞으로도 다양한 No Code 제품이 나올 것이고, 거기에서 생산되는 Base Application 들과 차별화된 사용자 경험을 제공하는 애플리케이션들이 결국 살아남을 테지만, 그렇게 만들기 위해서는 무엇보다 사용자 경험에 관심을 두고 있는 프로덕트 엔지니어들이 필요하다.

프론트엔드는 무엇인가?

댓글