23.06.15
DEVOTEE를 활성화 시키면
지금 작성한 커뮤니티 글에 대해 1개의 댓글을 달아줍니다.
버튼을 누르면 글 수정 시 ChatGPT가 작성한 댓글이 수정됩니다.
| 컨텐츠 유형 | 제목 | 저장일 | 삭제 |
|---|
본인인증 로그인에 실패하였습니다.
회원이 아니시거나 본인인증 등록이
완료되지 않은 사용자입니다.
이번 포스팅에서는 현대 앱 개발에 쓰이는 주요 아키텍쳐를 설명해보고자 합니다.
저희 팀에서 올해부터 FastAPI, React 스택으로 평가 모니터링 시스템을 맡게 되었는데요.
관련 입문 서적은 많지만, 전반적인 아키텍쳐를 설명해주는 자료는 없어서 직접 정리해봤습니다.
아래 키워드 목록 봐보시고, 궁금하다 싶으면 읽어주세요~
#Backend #Frontend #Model # View #Controller #MVC #Flux #Redux #Microservices #MSA
하나의 서비스는 백엔드 / 프론트엔드로 나눌 수 있습니다.
날씨 서비스를 만든다고 합시다. 이 서비스는 UI와 날씨 데이터, DB로 구성되어 있습니다.
화면을 구성하는 UI 부분이 프론트엔드, 날씨 데이터는 백엔드가 담당합니다. 날씨 데이터를 데이터베이스에 쌓을 수 있습니다.
데이터베이스는 간단히 엑셀시트를 떠올리면 됩니다. 기본적으로 테이블 형식입니다.
백엔드에서는 프론트엔드에서 쓸 데이터를 만들어줍니다. 사용자 요청에 따라 DB에서 데이터를 찾고 프론트엔드에서 쓰기 쉽게 가공해 응답합니다. 주로 json 포맷으로 주고 받습니다. (Read)
사용자 요청에 따라 데이터를 DB에 생성하고, 기존 데이터를 수정하거나 삭제도 가능합니다. (Create, Update, Delete)
CRUD : Create Read Update Delete
프론트엔드에서는 백엔드에서 받은 데이터를 가지고 화면(*UI)을 꾸며줍니다. 주로 웹 (HTML, CSS)으로 결과물을 만듭니다. 이외에도 MFC 나 QT, ATOM 등 다양한 UI를 활용해 만들 수 있습니다.
UI : User Interface
백엔드에서는 주로 복잡한 로직을 처리하고, 프론트엔드에서 쓸 데이터를 관리합니다.
날씨와 외출 관련된 서비스를 만들어 본다고 합시다. (외출몬 🌞☔👕 )
외출몬 서비스를 예시로 들면, 백엔드에서는 아래 역할을 할 수 있습니다.
1. 날씨와 의류 데이터를 이용해 날씨에 맞는 의류 추천하는 로직
2. 이번 주 날씨를 바탕으로 세차 지수를 계산
3. 이번주 날씨 데이터 기상청에서 파싱
데이터와 관련된 작업을 하고, DB와 연결되어 CRUD 작업도 진행합니다.
DB와 연결하는 방식은 SQL문을 직접 작성하거나, 각종 라이브러리에서 제공하는 ORM을 이용하면 됩니다.
ORM은 프로그래밍 언어의 변수와 DB 데이터를 연결해주는 문법으로 이해할 수 있습니다.
ORM : Object Relational Mapping
백엔드를 구현할 수 있는 프레임워크로는 Spring Boot, Django REST Framework, FastAPI가 있습니다.
Backend 구조는 MVC 패턴을 많이 이용합니다. MVC 개념을 이해하면 비슷한 패턴도 이해하기 좋습니다.
현대 앱 개발에서는 데이터가 중심입니다. 모델은 이 데이터를 정의하는 부분입니다.
엑셀 테이블을 만들 때, 첫번째 행에 열 정보를 입력하죠. Model은 축약하면 열 정보로 이해할 수 있습니다ㅎㅎ
외출몬의 models.py 장고 코드를 예시로 살펴보겠습니다.
from django.db import models
class Weather(models.Model):
class Summary(models.TextChoices):
SUNNY = "sunny", "sunny"
CLOUD = "cloud", "cloud"
RAIN = "rain", "rain"
SNOW = "snow", "snow"
location = models.CharField(max_length=500)
temperature = models.IntegerField()
summary = models.CharField(max_length=100, choices=Summary.choices)
time = models.DateTimeField()
location, temperature, summary, time 열을 정의했습니다.
summary 열의 경우처럼 모델에 제약사항을 걸어둘 수 도 있습니다. (SUNNY, CLOUD, RAIN, SNOW 4가지 중 하나)
이렇게 모델을 정의하면 이 정보를 바탕으로 프레임워크가 DB에 테이블을 만듭니다. (ORM이나 SQL 이용)
백엔드에서는 프론트엔드에 데이터를 보내게 되는데요. 뷰에서는 데이터를 어떻게 보낼지 작성할 수 있습니다. 주로 json 형식으로 보내게 됩니다.
먼저 model을 통해 사용자 요청에 맞는 데이터를 DB에서 받고, 이를 json 포멧으로 가공해 응답합니다.
왼쪽 그림에서는 json 형태로 입력을 하여 instance를 생성하고 있습니다. (POST)
오른쪽 그림을 보면 Weather 테이블에서 2번째 instance를 읽었습니다. (GET)
사용자가 이에 대해 삭제나 수정을 할 수 있습니다. (DELETE, PUT)
백엔드와 프론트엔드는 이 4가지 HTTP Method을 통해 데이터를 주고 받습니다.
여기서 200 OK, 404 Not Found, 500 Error 같은 HTTP status code도 확인할 수 있습니다.
(json 형태의 데이터를 주고 받음)
컨트롤러는 복잡한 로직을 처리하고 이를 뷰에 전달합니다.
사용자 요청에 따라 모델, 뷰 업데이트가 필요하면 컨트롤러에 해당 코드를 작성합니다.
외출몬의 장고 코드를 예시로 살펴보겠습니다.
from rest_framework import viewsets
from weather.serializers import WeatherSerializer
from weather.models import Weather
def get_fahrenheit(celsius):
return (celsius - 32) / 1.8
class WeatherViewSet(viewsets.ModelViewSet):
serializer_class = WeatherSerializer
def get_queryset(self):
queryset = Weather.objects.all()
temperature_format = self.request.query_params.get('temperature_format')
if temperature_format is not None and temperature_format.startswith('F'):
for query in queryset:
celsius = query.temperature
query.temperature = get_fahrenheit(celsius)
return queryset여기서 get_fahrenheit 함수는 섭씨 온도를 화씨 온도로 바꿔주는 역할을 하는데요. 이처럼 로직이 있는 부분을 컨트롤러에 모으면 좋습니다.
백엔드 MVC 구조에 대한 설명드렸습니다.
사실 장고에서는 MVC가 아닌 MTV (Model, Template, View) 패턴을 쓰는데요, MVC를 이해하고 나면 MTV 패턴도 쉽게 이해가 됩니다.
프론트엔드에서는 백엔드에서 데이터를 받고 UI를 구성해 화면으로 표현합니다.
백엔드, 프론트엔드 구분 전에는 View 하나에 해당했습니다. 백엔드에서 json 형태로 view를 제공하는게 아닌, HTML, CSS 형태로 view를 제공했습니다.
그러나 사용자와 상호작용이 중요해지면서, view에서 해야할게 많아졌습니다. 모바일, 패드와 같은 디바이스의 다양화도 백/프론트 구분을 앞당겼습니다.
관련 키워드: #SPA (Single Page Application) #responsive web design
프론트엔드에서도 MVC 패턴을 이용해 구조화할 수 있습니다. MVC 구분 자체는 백엔드에서와 유사합니다.
모델은 json을 반환하는 백엔드 뷰에서 데이터를 받고, 이를 자바스크립트 object로 바꿉니다.
과거에는 XML 포멧을 이용했는데 현재는 json 포멧을 이용합니다.
키워드: #AJAX (Asynchronous JavaScript and XML)
모델에서 데이터를 받고 HTML, CSS을 이용해 화면으로 표현합니다.
Javascript로 사용자 요청을 받고 이에 따라 모델, 뷰의 변화를 관리합니다.
예시로, 날씨 불러오기 버튼을 누르면 자바스크립트 코드가 실행되면서 모델, 뷰가 업데이트 됩니다.
SPA 웹의 규모가 커지게 되면 Controller 마다 많은 Model, View 가지고 있게되어 복잡해집니다.
출처: https://medium.com/hcleedev/web-react-flux-패턴-88d6caa13b5b
멋진 UI를 표현해야 하기 때문에 복잡성이 늘어나는데, 이를 관리하기 위해 단방향 구조로 바꿨습니다.
MVC에서는 사용자의 상호작용(Action)은 Controller가 담당했습니다.
Action이 들어오면 어떤 Store에 할당할지 Dispatcher가 판단합니다.
Store는 상태 관리를 하는 곳입니다. Action에 의해 상태가 변경되면 View에서 변경점을 표현해줍니다.
View에서는 다시 Action을 받을 수 있습니다.
Redux는 Reduce + Flux 의 합성어입니다. 여기서 Reducer는 순수함수 역할을 합니다.
순수함수는 "동일한 인자가 주어졌을 때 항상 동일한 결과를 반환", "외부의 상태를 변경하지 않는 함수" 를 뜻합니다. (출처: 링크의 순수함수 문단)
Flux의 Dispatcher 는 사라졌는데, 이는 Store 한개로 전부 관리하기 때문입니다.
Store는 불변상태를 저장합니다. 변경이 일어나면 변수의 복사본을 새로 저장합니다.
Redux는 React와 함께 자주 쓰입니다.
Frontend에서는 MVC, Flux, Redux 패턴을 이용할 수 있습니다.
여기까지 백엔드/프론트엔드 구분과 MVC, Flux, Redux 구조를 알아봤습니다.
마이크로서비스는 복잡성 관리 차원에서 같이 이해하면 좋습니다.
하나의 서비스는 여러 개의 마이크로서비스로 분리 가능합니다. 이 때 각각의 마이크로서비스 재사용성을 고려해서 분리합니다.
각 마이크로서비스마다 Backend / Frontend / Database 가 있습니다. 이 마이크로서비스는 그 자체로 동작 가능합니다.
외출몬 서비스가 날씨, 의류, 회원가입/로그인/인증, SNS 알림 서비스를 이용합니다.
이렇게 마이크로서비스로 구성하면, 다른 앱을 만들 때 재활용하기 좋습니다.
예를 들면, 의류쇼핑몰 서비스를 만들 때, 외출몬에서 만들었던 의류, 회원가입/로그인/인증 서비스를 재활용할 수 있습니다.
마이크로서비스는 전사 차원에서 개발이 이뤄지면 좋습니다. 위 구조를 보면 외출몬 하나의 팀만 마이크로서비스로 개발할 수 없습니다.
의류쇼핑몰팀, 기프티콘팀 등 다른 팀에서도 외출몬팀에서 개발한 서비스를 일부 그대로 이용할 수 있어야 합니다.
외출몬 팀도 다른 부서에서 만든 마이크로서비스를 재활용 해야됩니다.
반대로 다른 부서에서 또 다른 날씨/의류 데이터 서비스를 만들게 된다면 실패입니다 😅
다른 부서에서 잘 만들어놓은 SNS 알림 서비스 기능을 몰라서, 외출몬팀에서 새로 만들어도 실패입니다 😅
이런 실패는 부서간 소통과 연결이 잘 되면 해결할 수 있겠죠😃 그러니 공유를 잘 합시다!
DEVOTEE를 활성화 시키면
지금 작성한 댓글에 AI가 댓글을 달아줍니다.