🔍 프론트와 백의 구분- 무한한 확장성의 시작

자 그럼 우리 본격적으로 어플리케이션의 개발을 진행하기에 앞서 우리의 어플리케이션이 어떤 아키텍쳐를 가지고 세상에 나오게 될지 계획하게 될 것입니다.

프론트엔드와 백엔드를 분리시켜 보는 것은 어떨까요?

🔍 프론트와 백의 구분

프론트엔드와 백엔드를 분리시킨다는 얘기는 그렇게 이해하기 어려운 내용은 아닙니다. 최종적으로 구현하여 탄생하는 결과물은 같지만 그 속을 뜯어보면 내부에 보이는 구조가

a) 프론트엔드, 백엔드가 분리되어 서로 따로 동작하는 경우
b) 둘이 통합되어 있는 경우

로 나뉘어 있죠.

후자(b)에 설명한 경우가 일체형 구조(Monolithic architecture; 모놀리식 아키텍쳐)이고 전자(a)가 우리가 구현할 구조입니다. 뭐하러 번거롭게 구분지어서 생각하는 것인가 싶죠?

어플리케이션 개발에 있어서 초기 단계에 프로젝트의 정확한 규모를 예상할 수 없는 경우가 있습니다. 이런 경우에 우리가 최종적으로 구현할 투두 어플리케이션은 이러한 상황을 가정하고 필수적으로

💡"무한한 확장성"

을 열어둘 것입니다. 프론트엔드와 백엔드의 분리는 바로 그 첫 단추입니다.

🔍 일체형 구조의 문제점

전통적인 형태였던 일체형 구조는 소프트웨어에서 구성된 컴포넌트들이 하나로 통합이 되어있는 구조입니다. 소프트웨어가 복잡해지고 규모가 커짐에 따라 코드량이 늘어나고 이를 한번에 관리하기 어려운 문제가 발생을 하죠. 일부분의 오류를 수정하기 위해서 전체 코드를 뒤지고 또 뒤져서 ✏️유지보수에서 심각한 비효율이 일어나는 것이죠.

유지보수 측면뿐만 아닙니다. 서버 리소스는 기업 입장에서 소중한 자원입니다. 일체형 구조의 서버에서 어플리케이션이 동작할 때 데이터베이스와 통신 후에 데이터를 가공, 맵핑, 렌더링 이라는 과정을 수행하죠. 반면 프론트엔드와 백엔드 서버를 분리한다면 렌더링 과정 없이 프론트엔드에 JSON 포맷을 전송하기만 하면 됩니다.
아무튼 결론적으로 '✏️서버 리소스를 효과적으로 아끼지 못한다.'이 말이죠.

마지막으로 가장 중요한 부분은!!!

✏️일체형 구조는 다른 기능을 추가하고 기술을 전환하는 과정이 상당히 비효율적입니다. 코드가 길어지면서 빌드 시간이 늘어나고 코드 최적화에 대응이 느려질 수 밖에 없죠.

이해됐나요? 이런 모든 문제점을 해결하는 방법이 프론트엔드 서버와 백엔드 서버를 불리시키는 소프트웨어 아키텍쳐랍니다.

🔍 여기서 잠깐! 물론 만능은 없다.

소프트웨어 개발은 같은 기능을 개발해도 다른 상황이 펼쳐지기 마련이에요. 즉 매사에 정답이 없다는 뜻입니다. 요구사항이 적고 간단한 구조의 소프트웨어라면 일체형 구조가 분리된 구조보다 더 좋은 효율을 낼 수 있어요.

더 자세한 내용은 아래 포스팅을 참고해주세요. 이해가 잘되게 정리되어 있습니다.ㅎㅎ

back과 front의 분리

0개의 댓글