프론트엔드와 백엔드 비교( +백엔드 개발자가 되고 싶은 이유)

 

 

 

프론트엔드와 백엔드 비교

 

 

 

소프트웨어 디자인 모델의 하나인 MVC 모델은 Model, View, Controller로 구성된다. 프론트엔드 개발자와 백엔드 개발자는 해당 구성요소들을 나누어 개발하게 된다.

 

 

프론트엔드

 

 

프론트엔드 개발자는 이 중 사용자와 소프트웨어가 직접 상호작용하는 요소인 View를 구현한다.

 

서버가 전송하는 데이터만을 통해 사용자와 소프트웨어의 상호작용이 불가능한 것은 아니다. 그러나 소프트웨어에 대한 지식이 없는 일반 유저의 입장에서 raw data를 직접 다루기는 어렵다. 따라서 일반 유저도 쉽고 편리하게 이용할 수 있도록 직관적인 화면과 조작 매개체(주로 버튼)를 구현하는 것이 프론트엔드 업무의 핵심이다.

 

프론트엔드의 핵심 관심사항인 UI(User Interface)는 이름 그대로 유저에게 제공되는 인터페이스이다. 인터페이스는 복잡한 세부사항을 배제하고, 해당 객체가 소유한 기능의 단순화된 사용설명서와 같은 역할을 한다. 즉 User Interface는 유저에게 해당 소프트웨어(유저가 상호작용하는 객체)가 어떤 기능을 소유하고 있는지 안내해 준다. 이로써 유저는 소프트웨어에 대한 지식이 다소 부족하더라도 문제없이 소프트웨어의 주요 기능을 이용할 수 있다. 프론트엔드 기술이 점차 발전하면서, 기존의 유용한 UI 구현을 넘어 타 소프트웨어와의 차별점을 부각할 수 있는 UX(User Experience,  소프트웨어를 이용하는 사용자의 전반적인 만족도)의 중요성이 부각되고 있다.

 

프론트엔드 구현의 핵심은 직관성과 편의성이다. 전통적으로 소프트웨어의 핵심인 백엔드단의 설계가 기업들의 주요 관심사였지만, 개발 기술이 발전하며 사용자의 편의를 도모하는 프론트엔드의 중요성이 점차 증대하고 있다. 화려한 시각적 디자인과 상호작용의 편리함은 고객의 전반적인 소프트웨어 만족도와 직결되어 수익에 막대한 영향을 미치는 요소이기 때문이다. 따라서 대부분의 기업에서는 기존의 백엔드(현재의 풀스택) 개발자가 하던 프론트엔드 업무를 따로 분리하는 것에 그치지 않고 디자인과 실제 구현 업무를 분리하여, 전문 디자이너와 개발자의 철저한 분업과 협업을 통해 고객에게 최상의 서비스를 제공하기 위해 경쟁하고 있다. 현재도 풀스택 개발자가 존재하긴 하지만, 기술의 발전이 심화되고 개발 관련 지식이 방대해지며 양쪽 모두의 깊은 전문성을 담보하기는 어려워진 것이 현실이다.

 

프론트엔드 개발자는 전문 디자이너가 완성한 세련된 디자인 결과물을 화면에 구현하여 유저의 시각적 만족감을 높이고, API(Application Programming Interface, 애플리케이션 간 상호작용하기 위한 인터페이스)를 통해 사용자의 요청값을 백엔드의 서버로 전송하고 응답값을 반환하여 유저의 목적 달성 과정을 시각화한다. 기획 담당자와의 요구사항 조율 또한 잦은 편이다. 이러한 중간자의 역할로서 폭넓은 업무 이해도와 원활한 협업능력이 요구되며, 소프트웨어 개발 구성원으로서의 중요성이 매우 크다.

 

프론트엔드 기술은 매우 빠르게 발전, 변화하고 있으며 앞으로도 그러할 전망이다. 따라서 프론트엔드 개발자로서 도태되지 않기 위해서는 신기술의 끊임없는 학습과 연구가 필요하며, 이는 역설적으로 숙련된 프론트엔드 개발자의 가치를 크게 높이는 결과를 낳았다.

 

 

백엔드

 

 

백엔드 개발자는 Model과 Controller를 구현한다.

 

Model은 소프트웨어의 심장으로서, 데이터의 요청과 응답을 다루는 핵심 비즈니스 로직을 통해 데이터를 조작하고, 이를 위해 데이터베이스의 table을 매핑한 entity를 구현한다.

 

비즈니스 로직은 현실세계의 문제를 소프트웨어를 통해 해결하기 위한 의사결정을 수행한다. 따라서 비즈니스 로직을 수행하는 Service layer는 해당 소프트웨어의 핵심 컴포넌트를 구성하며, 소프트웨어의 목적이자 존재 이유라 할 수 있다. 비즈니스 로직에 대한 보다 상세한 내용은 이전에 포스팅한 바 있다(https://hellmir.tistory.com/entry/%EB%B9%84%EC%A6%88%EB%8B%88%EC%8A%A4-%EB%A1%9C%EC%A7%81%EC%9D%98-%EC%9D%98%EB%AF%B8).

 

 

DDD 기반의 AOP에서 비즈니스 로직이 가지는 의미

 

 

Controller는 View와 Model의 중간 매개체로서, 양측의 작업 수행에 필요한 데이터를 양방향으로 전송하며 요구되는 수행사항을 지시하는 역할을 한다. 이전의 포스팅에서 Controller와 View, Model의 상호작용 과정에 대한 내용을 다룬 적이 있다(https://hellmir.tistory.com/entry/DDD%EC%97%90%EC%84%9C-Controller-Service-Repository%EC%9D%98-%EC%97%AD%ED%95%A0, Controller 부분).

 

 

DDD에서 Controller, Service, Repository의 역할

 

 

백엔드 개발 과정에서도 Thymeleaf 등의 템플릿 엔진을 이용하면 어느 정도의 화면 구현이 가능하고, 이를 통해 프론트엔드에 비해 직관성이 떨어지는 백엔드 개발 과정에서도 보다 직관적인 결과를 확인하며 개발할 수 있는 장점이 있다. 그러나 점차 프론트엔드와 백엔드 간 철저한 분업이 강조됨에 따라, 최근에는 주로 직관적인 HTML form 대신 데이터만을 주고받는 REST API를 기반으로 개발하는 추세이다. REST API에 관한 상세 내용은 이전 포스팅에서 다룬 바 있다(https://hellmir.tistory.com/entry/REST-API-%ED%8A%B9%EC%A7%95-%EC%A0%95%EB%A6%AChttpsrestfulapinet-%EC%B0%B8%EA%B3%A0).

 

 

REST API 특징 정리(https://restfulapi.net 참고)

 

 

짧게 요약하면 REST API는 프론트엔드, 백엔드 간 철저한 분업을 통하여 효율의 극대화를 추구하기 위한 API라고 할 수 있다.

 

REST API를 통해 프론트엔드와 백엔드 간 분업을 극대화해, 각자의 전문 분야를 깊이 연구하고 자신의 주요 관심사 개발에 온전히 집중할 수 있게 된다. UI(인터페이스)와 마찬가지로 REST API(인터페이스)를 통해 프론트엔드와 백엔드 개발자는 서로의 구현 로직을 자세히 알지 못해도, 원활한 상호작용이 가능하게 되기 때문이다.

 

 

 

백엔드 개발자가 되고 싶은 이유

 

 

 

개인적으로 논리적이고 분석적인 분야를 다루는 것을 선호한다. 비즈니스 로직은 이름처럼 기업이 추구하는 사업의 업무를 수행하기 위한 핵심 로직을 다룬다. 따라서 각각의 소규모 로직을 통해 화면의 부분들을 구성하는 프론트엔드와 달리, 백엔드는 요청값을 기반으로 데이터를 변경하거나 적절한 응답값을 반환하기까지 다수의 로직들이 유기적으로 연결되어 다소 복잡한 상호작용을 거친 후에야 최종 로직으로 완성된다. 이러한 로직들을 설계, 연결하고 구현하는 과정은 내가 백엔드 개발을 선택하지 않고는 견디기 어려웠을 정도로 골치 아프고 즐거운 과정이다.

 

또한 구현 결과물을 바로 확인할 수 있는 화면의 개발보다, 복잡하고 난해한 설계와 구현에 대해 최선의 방법을 연구하고 고민한 결과물이 마침내 제대로 작동하는 모습을 최종의 순간에 확인하는 것을 좋아한다. 나에게는 마지막 단계에서 모든 컴포넌트의 상호작용을 통해 하나의 완성된 로직이 구현되었을 때의 압도적인 성취감이 부분적인 성취감의 집합에 비해 크게 다가온다.