프론트엔드와 백엔드 분리: 웹 개발 구조의 장단점 분석
프론트엔드와 백엔드 분리 구조가 웹 개발에 미치는 영향과 이를 채택했을 때의 장점과 단점을 소개합니다.
선 결론
프론트엔드와 백엔드를 반드시 분리할 필요는 없습니다. 프로젝트의 특성(상황, 확장성, 유연성, 유지 보수 등)과 요구사항을 고려하여 결합 혹은 분리를 하는 것입니다. 선호의 차이는 있겠으나 일반적인 정답은 없습니다.
일장일단(一長一短)이에요.😊
프론트엔드 / 백엔드
와 는 현대 웹 개발에서 업무와 영역을 구분하는 단어입니다. 사용자 인터페이스를 담당하는 영역을 프론트엔드(이하 프론트)라 하며, 데이터를 처리하는 영역을 백엔드(이하 백)라 합니다.
사실 언제부터 명확하게 구분했는지는 모릅니다. 초기에는 프론트와 백이 분리되지 않고 사용자 인터페이스와 데이터 처리가 혼합되어 있었어요. 그러다 웹 기술의 발전과 ajax 같은 기술의 등장으로 프론트와 백의 역할이 점점 명확해지며 전문화된 것으로 알고 있습니다.
전통적인 방식의 웹 개발
1990년대 후반에 등장한 서버 측 스크립팅 언어를 사용해 개발하는 것을 전통적인 방식이라 하겠습니다. 대표적으로 ASP, PHP, JSP를 사용하는 일반적인 방식을 말하며 이들은 프론트와 백을 강하게 결합하는 의 특징을 띠고 있습니다.
모놀리식 아키텍처는 프론트와 백을 명확히 구분하기 어렵습니다. 프론트 개발자는 서버 측 코드 블록(<% ... %>)으로 뒤덮인 소스 코드를 마주해야 하며, 백 개발자도 서버 측 코드를 작성하기 위해 HTML에 접근해야 합니다. 결과적으로 각자의 영역 이외의 부분을 다뤄야만 합니다. 전통적인 방식은 이렇게 혼합된 구조로 프론트와 백을 명확하게 분리했다고 말하기 어렵습니다.
단점만 있는 것은 아닙니다. 하나의 코드베이스codebase에 모든 코드가 집중되어 있기 때문에 유리한 부분이 분명 있고, 프론트와 백이 동일한 서버에서 실행되기 때문에 서버 간 통신 비용도 발생하지 않습니다.
프론트엔드와 백엔드를 분리하면?
프론트엔드 프레임워크를 사용했다고 가정합니다.
프론트와 백을 분리해서 생기는 대표적인 장점은 본인의 영역만 알아도 개발하는 데 전혀 지장이 없다는 거예요. 프론트 개발자는 코드 블록으로 뒤덮인 서버 측 코드를 다룰 필요가 없고, 백 개발자도 HTML 코드를 다룰 필요가 없습니다. 같은 파일을 다룰 일이 없으니 편해지는 것은 덤이고요.
또 다른 장점으로는 사용자 경험이 향상되는 것입니다. 현대적인 프론트엔드 프레임워크는 기호에 따라 렌더링 방식을 선택할 수 있습니다. 예를 들면 이나 을 선택해서 사용할 수 있어요. 전통적인 방식에서 CSR을 사용하기란 쉽지 않은데 말이죠. 이 외에도 확장성, 유연성 등 전통적인 방식에 비해 좋은 점이 많아요. 두 영역을 독립적으로 개발하기 때문에 전문성이 올라가고, 좋은 사용자 경험을 제공하는 것은 분명한 장점입니다.
날이 갈수록 사용자 경험에 대한 기대가 높아지면서 프론트 개발자의 역할이 더욱 중요해지고 있어요. 따라서 높은 숙련도를 요구하게 되었는데요. 예전에는 웹 디자이너가 프론트 개발을 담당하는 경우도 있었는데 지금은 어림도 없어요. 아니, 이제는 웬만한 백 개발자들도 프론트 코드를 해석하기 매우 힘들어할 정도죠. HTML을 포함한 JSX, 컴포넌트 관리, 상태 관리, 데이터 흐름 관리 등 다양한 개발 기술에 대한 이해가 필요해졌기 때문이에요.
프론트와 백을 분리하면 서버 간의 통신이 필요해집니다. 이로 인해 네트워크 비용이 발생하고, 전체적인 응답 시간이 늘어나기도 해요. 또한 통신 프로토콜, 데이터 형식, 엔드포인트endpoint 등을 정의하고 문서화해야 하는 작업이 추가됩니다. 즉 전통적인 방식에 비해 고려해야 할 요소가 훨씬 많아지는 것은 단점이 분명해요.
그래서 무엇이 더 좋은가?
네이버와 같이 매우 거대한 플랫폼도 초기에는 프론트엔드와 백엔드를 강하게 결합했을 것으로 예상합니다. 서비스의 규모가 커지면서 유지 보수의 문제, 확장성 문제, 개발 팀 간의 독립성, 유연성 문제가 발생했을 것이고 상황에 맞게 더 유연한 아키텍처로 전환했을 것입니다.
항상 생각하는 것이지만 최근 방식이 더 우수하다고 단언하기는 어렵습니다. 현대의 방식보다 고전적인 방식이 더 좋을 때도 있으니까요. 최근에 클래식 ASP를 이용하는 프로젝트가 있었는데, 이 언어는 오래되었어도 원하는 기능을 충분히 구현할 수 있었어요. 스크립트 언어이기 때문에 수정 사항 반영도 매우 편리했고요.
결론입니다.
프론트엔드와 백엔드를 분리하는 것은 선택사항입니다. 다만 프로젝트의 특성을 잘 고려해야 해요. 개발자의 능력을 고려해야 할 수도, 비용을 절약해야 할 수도, 유지 보수 비용을 고려해야 할 수도 있습니다. 혹은 매우 큰 규모의 서비스를 개발하거나, 매우 작은 규모의 서비스를 개발할 수도 있습니다.
정답은 없으니 상황을 종합적으로 판단하여 최선의 선택을 하는 것이 중요하지 않을까요? 😊