프론트엔드 아키텍처

프론트엔드 아키텍처 개념부터 개발 프로젝트까지
프론트엔드 x 백엔드 스쿨

프론트엔드 아키텍처란

프론트엔드 아키텍처란 정리된 책장과 비슷합니다. 처음 책장에 책을 정리할 땐 내 맘대로 정리해도 크게 문제 되지 않습니다. 다만 책장에서 시작해서 서재, 도서관으로 커진다면 기준 없이 정리된 책은 다시 찾아보기 어렵겠죠. 개발할 때 규칙 없이 코드를 만들다 보면 규모가 커지는 순간 불편함이 생기고 정리가 어려운 시점이 생깁니다. 처음부터 특정한 규칙을 만들어서 개발할수록 편리하다는 것을 알게 됩니다. 규칙을 하나씩 만들어가며 개발을 하다 보면 하나의 특정 패턴이 만들어집니다. 이러한 패턴들을 모두가 이해하고 따를 수 있도록 하는 구조를 아키텍처라고 부릅니다.

아키텍처 설계의 중요성

책 클린 아키텍처에서는 “나중에 아키텍처를 개선한다고 하는 개발자 중 실제로 나중에 개선하는 사람은 보지 못했다’고 기술되어 있어요. 특히 기술 트렌드가 빠르게 변화하는 프론트엔드 아키텍처에서 초기 설계를 신경 쓰지 않는다면, 시간이 지날수록 새로운 기능을 추가하기 어려워집니다. 이미 존재하는 소스 코드를 바꾸는 데 시간이 오래 걸리기 때문이죠.

일반적인 서비스를 구성할 때는 간단하게 다음과 같이 아키텍처를 설계할 수 있습니다.

프론트엔드에서는 클라이언트가 접근할 수 있도록 웹 서비스를 구축하고 백엔드에서는 서버를 구성하고, 서버는 DB에 접근하여 클라이언트가 요청한 내용에 대해 응답해 주는 방식이죠.

큰 틀에서 아키텍처를 구성했다면 애플리케이션 부분의 소프트웨어 아키텍처를 생각해야 합니다. 하나의 컴포넌트(혹은 모듈)에 모든 코드를 담아내는 나쁜 코드를 만들 게 아닌, 컴포넌트마다 역할을 분명히 하여 추후 프로젝트를 확장하거나 유지 보수를 해야 하는 상황이 올 때, 쉽게 해결할 수 있도록 말이죠. 이런 설계를 통해 코드를 만들게 되면 코드적인 부분에서 디자인 패턴을 적용하여 해당 컴포넌트 내부 코드를 깔끔하게 구현해 내는 것이죠.
단순한 구조의 아키텍처만 구성하여 개발을 진행해도 되는데 요즘에는 왜 아키텍처가 더 복합적으로 변하고 있는 걸까요?

서비스를 이용하는 사용자 수가 적은 초기 프로젝트에는 기업에서 자체 서버를 두어 운영하는 온프레미스(on-premise)방식으로도 충분히 대응이 가능하지만 시간이 흐를수록 서비스의 사용자 수가 늘어나게 되면서 서버에 과부하가 걸려 죽는 현상이 나타나기 시작합니다.

이때, CPU, Memory 같은 요소들을 서버에 더 많이 장착시켜 서버 스펙을 향상시켜 대응할 수 있게 됩니다. 이를 Scale-Up이라고 합니다. 하지만 이런 수직 확장을 하게 되면 해당 서버에 문제가 생길 경우 서버가 복구 될 때 까지 서비스를 중단해야 하는 최악의 상황이 생길 수 있게 됩니다. 이를 해결하기 위해 동일한 사양의 서버를 다량으로 배치하는 Scale-Out 방식이 생겨나게 됩니다. 수평 확장을 통해 하나의 서버가 죽어도 다른 서버가 대응해줄 수 있는 좋은 방식이 생긴 거죠.

하지만, 서버가 여러 군데로 나뉘어져 있어 데이터 일관성이 유지되지 않아 관리의 어려움이 있습니다. 그래서 애플리케이션 개발과 무관한 인프라 관련된 작업을 하는 AWS 클라우드 서비스가 등장하였습니다. 개발에만 집중하고 싶지, 로드밸런싱이나 서버 스케일링같은 인프라적인 부분에 시간을 빼앗기고 싶지 않은 개발자의 마음을 잘 이해했던 AWS는 성공하게 되었죠.

이제 우리는 효과적인 인프라를 이용하여 더 광활한 아키텍처를 구성하여, 우리 서비스에 추후 들어올 대규모 트래픽에도 무너지지 않는 좋은 설계를 하는 것이 중요해졌어요!

그럼 실제 프로젝트에서는
아키텍처를 어떻게 구성했을까?

프론트엔드 스쿨과 백엔드 스쿨 수강생이 협업하여 진행한 To:gather 프로젝트를 함께 살펴볼까요?
프로젝트 To:Gather는 하고 싶은 프로젝트를 찾고 함께 할 팀원을 구하는 커뮤니케이션 웹 서비스입니다. 누구나 자신의 기술 스택에 따라 팀프로젝트를 구하거나 팀원을 모집해 프로젝트 별 채팅방에서 실시간 채팅으로 소통할 수 있습니다. ‘프로젝트 팀원을 구하는 서비스에 이러한 기능이 있으면 조금 더 편하고 좋지 않을까?’ 라는 생각부터 시작되었다고 합니다. :)

해당 팀 프로젝트는 아키텍처 설계에 대한 고민의 흔적이 보이는 설계도였어요.
프론트엔드는 React를 이용하여 클라이언트 서비스를 빠르게 구축할 수 있고 백엔드는 Spring을 이용하여 서버를 구축하고 DB는 MariaDB를 이용하여 채팅 내용을 저장하는 기능을 가지고 있습니다.
내부적으로는 rabiitMQ와 redis를 이용하여 채팅 메시지 동기화를 진행하고 있네요. 또한 서버의 부하를 대비하여 오토스케일링 할 수 있도록 EC2로 구성해두어 스케일 아웃 시 인스턴스를 자동으로 생성하도록 했습니다. GitHub로 프로젝트 관리는 당연하고, git action으로 프로젝트를 테스트, 빌드 후 S3에 배포를 자동화 하는 CI/CD 파이프라인도 잘 구축되어있습니다. AWS 인프라를 적극적으로 활용하여 확장성 및 서비스 규모를 고려한 서비스 아키텍처가 인상 깊습니다.

개발자 취업 준비를 시작하고 4개월차에 진행된 프로젝트임에도 현업에서 생각하는 아키텍처를 도식화해내고 이에 맞게 구현하여 놀랐어요. 프론트엔드든, 백엔드든 개발자로 취업을 하게 된다면 주어진 업무에 대한 output을 내는데 집중해야 하기에 해당 프로젝트처럼 다양한 기능을 접해볼 기회가 많이 사라지게 됩니다. 취업의 관점에서 아키텍처를 이야기 해보자면, 다양한 아키텍처를 설계해보는게 개발을 배워나가는 입장에서 좋은 방향이 되어 줄 거라 생각합니다. 여기에 추가로 서비스에 필요한 아키텍처를 도식화하고 설계하는 과정에서 힘들었거나 좋은 설계로 개선해낸 경험이 있다면 면접에서도 좋은 점수를 받을 수 있을 거에요.

제로베이스 스쿨에서 프로젝트를 함께 진행하며 다양한 기술을 경험해보는 것이 나중에 좋은 개발자로 성장하는데 중요한 초석이 될 거라 믿습니다.

더 자세한 프로젝트 내용은 영상에서 확인하실 수 있어요. :)

개발자로 취업하려면 꼭 필요한 프로젝트 경험
프론트엔드, 백엔드 협업부터 실전 배포까지
제로베이스에서 새출발할 여러분을 기다립니다.

개발자를 꿈꾸는 누구나
>> 프론트엔드 스쿨 바로가기
>> 백엔드 스쿨 바로가기

추천 컨텐츠