개발 페러다임의 변화, 백엔드에서 프론트엔드로
저는 개발의 패러다임이 백엔드에서 프론트엔드로 바뀌는 중이라고 생각합니다. 물론 백엔드 기술이 중요하지 않다거나 사라진다는 이야기는 전혀 아니구요. 개발의 무게 중심이 이전에는 백엔드였다면 이제는 프론트엔드로 이미 꽤 많이 넘어왔고 앞으로 더욱 넘어올 것이라 생각합니다.
이미 개발되어 운영되고 있는 플랫폼들은 당연히 이전에 설계된 백엔드와 인프라를 확장하면서 성장해 나가겠지만 신규 플랫폼들은 프론트엔드 중심의 개발 프로세스와 새롭게 등장하고 있는 자동화된 인프라를 활발하게 차용하여 빠른 시장 진입과 제약 없는 트래픽 확장의 혜택을 누릴 것이라 생각합니다. 이에 대한 과거와 현재, 미래를 잇는 저의 관점을 정리해보겠습니다.
20년 전에는 드림위버 같은 에디터로 HTML을 만드는 퍼블리셔의 역할이 있었고 디자이너가 이 작업을 병행하기도 할 정도로 난이도가 낮은 업무였습니다. 대다수 PC 사용자가 윈도우 OS를 사용했으므로 인터넷 익스플로러에만 대응을 하면 되고 코드는 FTP로 서버에 싱크를 했으며 퍼블리셔의 업무는 프로그래밍이라기 보다는 디자인 파일을 HTML 에디터에서 불러와 그 위에 적절한 코드를 조립하는 위지윅 에디팅 작업에 가까웠습니다.
백엔드 개발자라는 직군이 따로 없고 웹 개발자라는 직군이 퍼블리셔의 작업물에 PHP, JSP, ASP 등의 서버 코드를 입히고 데이터베이스 쿼리를 작성하고 아파치 서버에 올렸습니다. 서버 하드웨어는 호스팅 업체로부터 임대하기도 했지만 가격이 비쌌기 때문에 데이터센터의 공간과 네트워크 망만 임대하고 서버를 직접 구매하여 봉고차에 수십대를 싣고 가서 설치하고 테스트하는 작업을 하는 시스템 엔지니어의 역할이 중요했습니다.
2007년 전후로 맥북 판매량이 늘고 파이어폭스, 오페라, 크롬 등의 브라우져가 출시되어 인터넷 익스플로러와 점유율 경쟁을 시작했고, 페이스북, 구글 등 웹 2.0 서비스들이 크게 성장하면서 웹표준 개념이 퍼졌습니다. table 태그를 무분별하게 사용했던 이전과 같은 퍼블리싱 방식으로는 인터넷 익스플로러 이외의 브라우져에서 화면이 깨졌습니다.
HTML과 CSS로 컨텐츠와 디자인을 분리하고 다양한 브라우져에서 동일하게 보일 수 있도록 웹표준 가이드가 나오게 되었고 퍼블리싱은 좀더 사고력과 숙련도가 필요한 프로그래밍의 영역에 가까워졌습니다. 이후로 Prototype.js, jQuery 등 간단한 스크립트로 AJAX 처리를 하게 되어 화면 리프래시 없는 화면 변경이 가능해지고 구글 지도나 지메일이 단순 웹페이지를 넘어선 웹 애플리케이션 개념을 구현해 내었구요.
이런 개념들을 차용해 백엔드와 프론트엔드를 구분하지 않고 한번에 개발하는 루비온레일즈, 파이썬의 장고, 자바의 스프링 등 풀스택 개발 프레임워크들이 웹개발의 주력으로 자리잡았습니다. 퍼블리셔와 백엔드 서버 개발자가 협업하기도 하고, 풀스택 개발자가 디자이너의 결과물을 직접 구현하는 방식도 공존했습니다.
2007, 2008년에 아이폰과 안드로이드가 최초로 출시되었고 대중화가 된 2010년 전후로 아이폰, 안드로이드 앱 개발 수요가 많아졌고, 이 당시는 하이브리드앱에 적합한 웹 프레임워크가 출시되기도 전이고 스마트폰 성능도 지금의 10분의 1보다도 못한 수준이었기 때문에 무조건 네이티브앱으로 제작해야 했습니다.
자연스럽게 아이폰의 Objective-C와 안드로이드의 Java로 클라이언트를 구성하고 데이터를 클라이언트로 보내고 데이터베이스에 저장하기 위한 백엔드 구축도 필수가 되어 다양한 웹개발 프레임워크들이 API 서버 역할로 사용되었습니다. 아이폰 개발자, 안드로이드 개발자, 서버 개발자가 협업을 했고 AWS 등의 클라우드와 다양한 서버 호스팅의 선택지가 있었기 때문에 서버를 직접 설치하고 관리하는 시스템 엔지니어의 역할이 축소되었습니다.
클라이언트와 서버의 역할 분리를 통해 API 서버 구축이라는 개념이 널리 퍼지게 되었고 2013년에 페이스북이 프론트엔드에 집중한 리액트를 출시하였습니다. 이전에는 동작이 복잡하고 데이터가 많은 웹 애플리케이션을 만들기 위해서는 AJAX 호출 코드와 이벤트 핸들링 코드, DOM 변경(화면 변경) 코드를 굉장히 많이 작성해야 했는데, 리액트는 이를 훨씬 간단한 구성으로 구현할 수 있게 해주었습니다.
리액트가 확산되면서 백엔드는 풀스택 프레임워크 대신 파이썬의 Flask, FastAPI나 Node 기반의 Express와 이를 활용한 다양한 API 프레임워크들이 사용되었습니다. 특히 Node 기반의 기술들은 리액트와 같은 자바스크립트 언어가 쓰이면서 기존의 다양한 언어를 숙지해야했던 풀스택 개발의 난이도를 감소시켰습니다.
리액트로 개발된 웹사이트는 자바스크립트가 실행되어야지만 컨텐츠가 표시되고 검색엔진은 (과거에는) 자바스크립트를 이해하지 못했으므로 검색 최적화가 불가능했었습니다. 검색엔진이 리액트 페이지 컨텐츠를 긁어갈 수 있도록 서버사이드 렌더링 기술이 나왔고 이것이 Next.js의 시작입니다. 사실상 Node 기반의 서버이기 때문에 서버 API로도 사용될 잠재력이 있었지만 초반에는 SEO라는 소박한 목표로 시작했습니다.
Next.js를 만든 Vercel은 서버리스 호스팅 업체입니다. 리액트 개발자들이 폭발적으로 성장하는 것을 보면서 Vercel은 Next.js를 풀스택 프레임워크로 발전시켰습니다. 이전에 풀스택 프레임워크가 백엔드 중심이었다면, Next.js는 리액트 프론트엔드 중심이면서 필요한 API를 추가해 구축할 수 있는 개념이었습니다. 프론트엔드와 백엔드가 합쳐져 있으면서 Vercel 인프라 위에 쉽게 배포할 수 있게 만들면서 개발자 입장에서는 프론트, 백엔드, 인프라를 쉽게 관리할 수 있게 되었습니다.
백엔드는 필수적으로 데이터베이스와 연결이 되어야 하는데, 데이터베이스 언어인 SQL은 자바스크립트 뿐만 아니라 자바, 루비, 파이썬, PHP와는 완전히 다른 언어이다보니 프론트엔드 개발자에게 데이터베이스가 장벽일 수 있었는데요, 다행히 Prisma나 TypeORM 등이 ORM이라는 개념을 통해 SQL을 거의 알지 못해도 데이터베이스 연동을 넘볼 수 있었습니다.
그런데 여기서 끝이 아니라 Firebase, Supabase 등 데이터베이스, 파일 저장, 로그인 인증 등을 대신 처리해주는 API 서비스들이 등장했고 사용량에 따라 돈만 내면 알아서 인프라를 확장해줍니다. AWS도 매우 훌륭한 서비스이지만 보안을 신경쓰면서 효율적으로 이용하려면 허들이 높은데요, AWS 위에 올라가 있는 Vercel과 Supabase를 이용하면 아주 쉽게 서버와 데이터베이스를 세팅하고 연동할 수 있습니다.
리액트의 단점을 보완한 Vue와 Svelte는 각각 Nuxt와 Sveltekit으로 리액트와 Next.js 구조를 그대로 가져왔고, Vercel은 Svelte의 창시자를 채용하고 Svelte 개발에 전폭적인 지원을 하면서 프론트엔드 프레임워크들이 모두 급성장하게 되었습니다.
더불어 스마트폰 성능의 향상과 프론트엔드 프레임워크의 발전으로 하이브리드앱의 성능이 네이티브앱을 따라잡게 되었고 굳이 난이도가 높은 아이폰과 안드로이드 네이티브 언어로 개발하지 않고 리액트나 스벨트로 개발한 후 웹뷰로 감싸면 동일한 기능을 훨씬 빠르고 저렴하면서도 자바스크립트 개발자 혼자서 만들 수 있게 되어 프론트엔드 개발자의 수요는 더 증가하였습니다.
앞으로는 어떻게 될까요? 프론트엔드는 점점 더 쉬워질 것입니다. Angular보다 쉬운 리액트가 나왔고 그보다 쉬운 Vue가 나왔고, 그보다 쉬운 Svelte가 나왔습니다. Svelte는 그냥 HTML와 자바스크립트이고 HTML과 자바스크립트 기초만 배우면 입문할 수 있습니다. 서버 인스턴스를 신경쓰지 않아도 되는 서버리스 호스팅이 나왔고 협업과 권한 관리, 트래픽 확장, CI/CD도 가능합니다.
백엔드 언어는 프론트엔드와 같은 자바스크립트이고 개발 로직도 프론트엔드와 백엔드가 크게 다르지 않습니다. 사용자에게 공개되면 안 되거나 권한에 따라 분기해야 하는 로직만 백엔드에서 처리하고 나머지는 거의 프론트엔드에서 처리해도 됩니다. 백엔드와 프론트엔드의 언어와 기술이 거의 동일하고 역할만 나뉩니다.
데이터베이스, 인증, 스토리지 등도 자체 인증 시스템이나 AWS RDS, S3를 셋업할 필요 없이 서비스형 API를 사용하면 되고 선택지는 더욱 늘어날 것입니다. 프론트엔드 자체도 쉬워지는데 그 이외의 기술도 프론트엔드에 맞추어 사용하기 쉬운 것들이 쏟아져나오고 있습니다. 이전에는 사용량에 따른 자동 확장을 위해 AWS의 다양한 툴을 활용해 설계해야 했다면 지금은 설계가 필요 없고 그냥 Vercel과 Supabase를 쓰면 됩니다.
인공지능과 접목되면 어떻게 될까요? GPT 4는 프론트엔드 코드를 매우 잘 작성합니다. 이미 OpenAI의 GPT 4 시연 영상에서 손으로 그린 기획서를 동작하는 코드로 자동으로 변환되는 영상을 볼 수 있습니다. 저희도 코드 작성과 수정에 GPT 4를 적용해보고 있습니다. 기획서나 디자인 시안을 프론트엔드 코드로 자동으로 만들어주는 게 가능해진다면 개발 과정 전체가 자동화되지는 않더라도 상당히 많은 개발 리소스를 줄일 수 있게 됩니다.
그래서 저희가 핑거를 통해 지향하는 것이 프로젝트를 프론트엔드 중심으로 관리하면서 코드 작성과 견적 계산에 AI를 활용하고 데이터베이스와 인프라를 서비스형 클라우드에 자동으로 배포하여 전체 개발 과정을 단순화, 자동화하여 리스크를 줄이고 외부 파트너 개발자들도 안전하게 개발할 수 있도록 코드량과 코드 퀄리티를 측정하여 회사 규모에 관계 없이 확장 가능한 앱/웹 개발 구조를 만드는 것입니다.
여기까지 프론트엔드 중심으로 개발 패러다임이 바뀌어 간다고 생각하는 저의 생각을 정리해보았습니다. 이견이 있으시거나 궁금한 점이 있으시면 언제든 알려주시기 바랍니다!
