Application의 기본 구조
MVC 모델과 소프트웨어 구성의 기초
프론트엔드와 백엔드 그리고 HTML의 구조를 간단하게 살펴보고, 자신의 웹페이지도 만들어 보았습니다.
그렇다면 실제 우리가 자주 사용하는 앱(application)이나 웹사이트는 어떻게 다를까요?
기본적인 구조에 있어서는 크게 다를 것이 없습니다.
하지만 기능이 많아지고, 환경 조건이 복잡해짐에 따라 세부적인(그러나 정말 큰) 고려 사항들이 기하급수적으로 증가하게 됩니다. 예를 들어 지난번 아주 간단하게 HTML과 CSS만으로 웹페이지를 만들었다면, 실제 웹 서비스에서는 python, php 등을 이용하여 회원 로그인 같은 여러 기능들을 만들고, MySQL 등을 이용하여 회원 데이터베이스(DB)를 관리해야 합니다.
또한 기존에 우리가 이용했던 github의 웹페이지 호스팅이 아닌 다른 상업적 서버 호스팅 서비스(AWS, Azure, 카페24 등)를 이용하거나 직접 서버를 구축(엄청 비싼 컴퓨터를 사야하는...)하는 작업도 고려 대상에 오르게 됩니다.
오늘은 이처럼 실제 앱은 어떤 구조로 만들어지는지에 대해서 알아보려고 합니다.
다만, 앱의 구성 방법론은 무수히 많고 그 자체로 하나의 기술 영역이기 때문에 가장 보편적인 내용을 정리하였다는 것을 염두해 두고 읽어주시면 감사하겠습니다.
먼저 앱을 만들 때 사용되는 다양한 소프트웨어(또는 언어)에 대해서 알아보겠습니다.
사용되는 소프트웨어들은 그 쓰임새에 따라 역할이 정해져 있습니다. 그리고 각각의 것들을 취사 선택하여 앱을 만들게 됩니다. 특히 'LAMP'로 알려진 소프트웨어의 조합이 대표적입니다. LAMP란 Linux, Apache, MySQL, PHP를 나타내는 말로, 운영체제는 Linux, 웹서버는 Apache, 데이터베이스는 MySQL, 프로그래밍 언어는 PHP를 의미합니다. 이처럼 운영체제, 웹서버, 데이터베이스, 백엔드 프로그래밍을 고려해야지만 실제 앱(또는 웹 서비스)를 제작할 수 있습니다.
조금 자세히 살펴보면
OS에는 우리에게 가장 친숙한 Windows부터 서버에서 가장 많이 사용되는 Linux, 그리고 Linux 계열의 운영체제로 우분투와 센트OS가 있습니다. OS는 서버를 가동하는 가장 기본적인 소프트웨어 입니다.
Web Server에는 대표적으로 아파치(apache)와 엔진엑스(nginx)가 있으며, 인터넷을 통해 HTML, CSS를 비롯하여 리소스가 되는 이미지 파일, 그리고 서버 사이드(백엔드) 언어를 전달하는 역할을 합니다. 또한 Web Server 외에 아파치 톰캣(apache tomcat) 같은 WAS(Web Application Server)라는 중간자(미들웨어)를 별도로 설치하여 운영하는 사례도 많습니다.
DB는 우리가 흔히 말하는 데이터베이스입니다. 앱에서 관리되는 여러 데이터를 구조화하여 저장하고, 요청에 따라 조합하여 제공하는 역할을 합니다. DB에는 크게 관계형 데이터베이스인 MySQL, Oracle Database, (국내 데이터베이스인)Tibero와 비관계형 데이터베이스인 MongoDB, Cassandra, Redis가 대표적입니다.
Back-End는 서버 사이드 프로그래밍 언어로 친숙한 여러 언어들이 있습니다. Java, Python을 비롯하여 PHP, Ruby, Perl, C++ 등이 있습니다. 또한 각 언어를 조금 더 활용하기 쉽게 정리한 프레임워크도 있습니다. Java의 Spring, Python의 django, PHP의 Laravel, Ruby의 Rails이 대표적입니다. 해당 언어를 통해 실제 기획한 여러 기능들을 구현하게 됩니다.
Front-End는 화면에 보이는 비주얼적인 요소를 개발하는 작업을 뜻했지만, 최근에는 javascript가 광범위하게 활용됨에 따라 일부 백엔드의 기능도 함께 부담하고 있습니다(아주 간단한 서비스의 경우 javascript 만으로도 개발이 가능합니다). 우리가 공부했던 HTML과 CSS 만으로도 구현이 가능하며, Wordpress라는(백엔드의 많은 기능들을 쉽게 활용할 수 있는) 유용한 프로그램도 있습니다. 최근에는 javascript 프레임워크인 Vue, Angular, React 등이 활발하게 활용되고 있는 추세입니다.
<Software Architecture>앱의 구성에 대해서 간단하게 알았으니 이제는 실제 앱을 기획하고 개발할 때 어떤 방식으로 구조를 나누는지를 살펴보겠습니다.
앱은 개발한 후에 실제 서비스가 되고, 유지보수가 되는 것을 고려해야 하기 때문에 앱을 구성하는 영역의 목적에 따라 구분하여 개발하는 것이 일반적입니다. 아래는 가장 대표적인 MVC 모델입니다.
<MVC Model>MVC 모델이란 Model, View, Controller로 이루어진 구성을 뜻합니다. 이 구성에서는 앱 내에서 화면에 표현되는(표현하는) 요소인 View, 데이터의 입력과 출력을 담당하는 요소인 Controller, 실제 내부의 비즈니스 영역 또는 기능적인 영역 요소인 Model로 나뉘어집니다.
이렇게 구성 영역을 나누는 이유는 서비스 운영 및 유지보수 측면에서 필요하기 때문입니다. 각 영역들이 완전히 독립적일 수는 없겠지만 이렇게 나눔으로 인해서 화면 구성만 바꾸어야 하거나, 화면 구성은 그대로인데 일부 로직(또는 기능)을 바꾸어야 하는 경우 보다 효율적으로 작업이 이루어질 수 있습니다.
조금 단순화시켜 생각해보면 다음의 예를 떠올릴 수 있을 것 같습니다. HTML과 CSS만으로 멋드러진 홈페이지를 만들었는데, 금방 실증이 나서 화면을 수정하려고 할 때
1) CSS 요소를 HTML 문서 내에 그리고 태그 내 인라인으로 작업을 한 경우
2) HTML과 CSS를 구분하여 작업하고, CSS파일을 HTML 내에서 참조한 경우
위 두 경우 중 1번 보다는 2번의 경우가 수정작업을 하기에 훨씬 더 쉽다는 것을 생각하면 이해하기가 편할 것 같습니다.
이처럼 앱의 구성을 이해하고, 각 영역별로 필요한 언어 또는 프로그램을 조합하여 개발할 수 있는 엔지니어를 우리는 Full-Stack 개발자라고 부릅니다. 우리 모두가 full-stack 개발자가 되기는 힘들겠지만, 대략적으로 앱이 어떻게 구성되어 있고 우리 팀의 엔지니어가 어떤 일을 맡고 있는지, 엔지니어가 왜 그토록 안 된다는 말을 자주 하는지에 대해서 생각해볼 수 있는 기회가 됬으면 좋을 것 같습니다.
