Flask 웹 애플리케이션의 구조와 동작 원리

백앤드

 

백엔드는 사용자가 직접 접근하지 않는 서버 측 시스템을 의미하며, 데이터 처리, 비즈니스 로직, 인증, API 제공 등을 담당한다.

백엔드 프레임워크란?

• 백엔드 프레임워크는 웹 애플리케이션 개발을 쉽게 만들기 위한 라이브러리와 도구 모음이다.
• 개발자는 이를 통해 요청을 처리하고, 보안 및 데이터베이스 작업을 쉽게 구현할 수 있다.

💡 웹 프레임워크를 사용하면 좋은 점

• ✅ 반복적인 작업 감소 → 요청 라우팅, 데이터 검증 등을 자동화
• ✅ 개발 속도 향상 → 기본적인 기능이 제공됨
• ✅ 디버깅과 테스트 도구 제공 → 오류 찾기가 쉬움

어떤 프레임워크를 고를지 고려사항

• 프로젝트 규모와 복잡도
• 프레임워크 확장 가능성
• 커뮤니티
• 라이선스 정책

Flask

• 장점
  • 간결하고 가볍다. 불필요한 기능이 없어, 필요한 기능만 추가해서 사용 가능
  • 자유도가 높다. 강제적인 구조 없이 개발자가 원하는 방식으로 구현 가능
• 단점
  • 복잡한 개발에는 적합하지 않는다. 기본 제공 기능이 적어서, 큰 프로젝트에서는 설정할 게 많아짐

 

백앤드를 위한 디자인 패턴

 

디자인패턴: 소프트웨어 설계에서 자주 발생하는 문제에 대한 일반적인 해결책으로 유지보수성과 확장성을 고려한 여러 디자인 패턴이 사용

MVC패턴: Model - View - controller

• 모델: 데이터와 비즈니스 로직 관리
• 뷰: 레이아웃과 화면 처리
• 컨트롤러: 명령을 모델과 뷰 부분으로 라우팅

플라스크 MVC 구조

• Model: ORM사용한 DB구조
• View: Jinja 템플릿
• Controller: @app.route()로 정의된 함수들

project/
│
├── app/
│   ├── models/       ← Model (SQLAlchemy 모델 등)
│   ├── views/        ← View (Jinja 템플릿)
│   ├── controllers/  ← Controller (Flask route 함수들)
│   ├── static/       ← 정적 파일 (CSS, JS 등)
│   └── __init__.py   ← 앱 팩토리. 비어있는 파일. 작성해도 되고 안해도 됨.
│
├── config.py
└── run.py

 

웹 서버, WAS, WSGI 

 

웹 서버 (Web Server): 정적 파일을 제공하는 서버

• 대표적인 웹 서버: Nginx, Apache
• HTML, CSS, JavaScript 같은 정적인 파일을 제공하는 역할
• 하지만 Flask/Django 같은 동적 웹 애플리케이션은 직접 실행하지 못함
• 그래서 동적 요청 처리를 위해 WAS가 필요하다.

 

WAS (Web Application Server): 동적 웹 애플리케이션을 실행하고 요청을 처리하는 서버

• (Java 환경): Tomcat, JBoss, WebLogic
• (Python 환경): Gunicorn, uWSGI (WSGI 서버)
• 클라이언트 요청을 받아서 비즈니스 로직을 처리하고, DB 조회 후 응답을 생성
• WAS가 웹 애플리케이션을 실행하고 요청을 처리하는 역할을 담당

 

WSGI(Web Server Gateway Interface)

• 파이썬에서 웹 프로그램을 개발하기 위한 표준 인터페이스, 웹서버와 파이썬 애플리케이션이 통신하기 위한 규약
  • 인터페이스: 서로 다른 시스템이나 프로그램이 공통된 형식으로 소통할 수 있도록 정한 규칙
  • REST API에서 JSON 형식으로 요청을 주고받는 것 → 서로 다른 시스템이 같은 형식으로 데이터를 주고받을 수 있도록 만든 인터페이스
• 웹 애플리케이션(예: Flask, Django 등)과 웹 서버(예: Gunicorn, uWSGI, Nginx)는 서로 다르게 동작하는데, 이 둘이 서로 소통할 수 있도록 중간에서 연결해주는 규약이 WSGI
  • WAS(웹 애플리케이션 서버) = 웹 애플리케이션을 실행하고 요청을 처리하는 서버
  • 파이썬에서는 WAS 대신 WSGI 서버(Gunicorn, uWSGI 등)를 사용
• Nginx, Apache와 같은 서버들은 django, flask로 작성한 웹 어플리케이션을 인식하지 못한다.
• 이 때 WSGI를 이용해 웹 서버와 애플리케이션이 서로 통신할 수 있게 됨

 

Java 환경

• 웹 서버: Nginx, Apache
• WAS: Tomcat, JBoss
• 웹 애플리케이션: Spring Boot, JSP

Python 환경

• 웹 서버: Nginx, Apache
• WSGI 서버 (WAS 역할): Gunicorn, uWSGI
• 웹 애플리케이션: Flask, Django, Fast API

 

WSGI 서버가 동작하는 방식

서버 구성: Nginx + Gunicorn + Flask

1. 사용자가 http://example.com에 접속
2. Nginx가 요청을 받음 → 정적 파일이면 직접 응답
3. 정적 파일이 아니라면 요청을 Gunicorn(WSGI 서버)으로 전달
4. Gunicorn이 Flask 애플리케이션을 실행하고 비즈니스 로직 처리
5. Flask가 DB 조회 등 처리 후 응답을 Gunicorn에 반환
6. Gunicorn이 응답을 Nginx에 전달
7. Nginx가 최종적으로 클라이언트(브라우저)에게 응답

👉 Nginx는 정적 파일 처리, Gunicorn은 동적 요청을 처리하는 WAS 역할

 

 

Flask

 

파이썬 가상환경 생성

# pip로 최초 가상환경 생성
python -m venv myvenv

# 가상환경 활성화
source myvenv/bin/activate

# 가상환경 비활성화
deactivate

 

가상환경에서 플라스크 설치

# pip 업그레이드
$ python -m pip install --upgrade pip

# flask 설치
$ pip install flask

# 플라스크는 app.py를 시작파일로 인식하여 실행이 시작 
$ flask run

# flask run --debug 명령을 실행해 디버깅이 가능하도록 설정
$ flask run --debug

 

python app.py vs flask run

 

• python app.py
  • Flask 애플리케이션을 직접 실행하는 방식
  • if name == "main": app.run() 코드가 포함된 파일을 직접 실행해야 하며, Flask의 기본 내장 서버가 구동된다.
  • 디버그 모드 활성화: app.run(debug=True)를 코드에 직접 추가해야 한다.
• flask run
  • Flask의 CLI를 이용해 실행하는 방식이다.
  • FLASK_APP 환경 변수를 기반으로 Flask 애플리케이션을 실행하며, CLI에서 다양한 설정을 추가할 수 있다.
  • 디버그 모드 활성화: flask run은 실행할 때 flask run --debug 옵션을 붙이면 되며
    • .flaskenv 같은 환경 파일을 활용할 수 있어, 보다 확장성이 높고 실무에서 선호된다.
• 결론적으로, python app.py는 작은 프로젝트에서 간단히 실행할 때 적합하고, flask run은 환경 변수 설정 및 다양한 옵션을 활용할 수 있어 더 유연한 방식이다.
• 나는 항상 장고나 fast api 프레임워크를 사용할 때 flask run 을 사용하는 편이다.

 

# test.py - 기본적으로는 app.py 라는 파일을 시작점으로 해서 나머지 파일을 읽는다.

from flask import Flask

# Flask 어플리케이션을 생성하는 코드
# 이 파일에 다른 파일 경유 없이 test.py를 통해 실행된다면 __name__ 변수에는 'test'라는 문자열이 담김
app = Flask(__name__)

# URL과 FLASK코드를 매핑하는 Flask 데코레이터
@app.route('/')
def hello():
    return 'Hello'


if __name__ == '__main__':
    app.run()

• python test.py로 실행하면 name 값이 'main'이 되어 app.run()이 실행된다. 즉, Flask 애플리케이션이 직접 실행된다.
• flask run을 실행하면 Flask는 기본적으로 app.py를 찾지만, 만약 파일명이 test.py라면?
  • Flask는 test.py를 모름❌
  • FLASK_APP=test.py 환경 변수를 설정하면 test.py를 실행할 수 있다.
• 맥에서는 기본적으로 Flask 애플리케이션이 실행될 때 FLASK_APP 환경 변수를 통해 시작 파일을 지정할 수 있다.
• 따라서 .zshrc 파일에서 export FLASK_APP=test.py를 설정하면, flask run 명령을 실행할 때 test.py파일이 시작점으로 실행

 

Flask 구조

 

flask나 django나 fast-api나 똑같다.

• models.py
  • 데이터베이스 관련 작업을 처리하는 역할
  • Flask에서는 ORM을 지원하는 파이썬 데이터베이스 도구인 SQLAlchemy를 사용하여 데이터베이스와의 상호작용을 쉽게 관리
  • 데이터베이스 테이블과 모델을 정의하고 데이터를 삽입, 수정, 삭제 및 조회하는 기능을 담당
• forms.py
  • 웹 브라우저에서 서버로 전송된 폼 데이터를 처리
  • Flask에서는 WTForms라는 라이브러리를 사용하여 폼을 모델 기반으로 처리
  • 사용자가 입력한 데이터를 검증하고 서버로 전송할 수 있는 폼을 정의
• templates 디렉터리
  • 웹 애플리케이션에서 사용되는 HTML 파일이 저장
  • Flask에서는 Jinja2 템플릿 엔진을 사용하여 동적인 콘텐츠를 HTML 파일에 렌더링할 수 있다.
• views 디렉터리
  • 화면을 구성하는 함수들로 구성된 뷰 파일들이 저장
  • 프로젝트의 기능에 따라 여러 개의 뷰 파일을 만들 수 있음
  • 각 뷰 파일에는 URL 경로에 대한 처리가 담겨 있고 해당 경로에 대한 HTML을 반환하는 역할을 한다.
• static 디렉터리
  • 웹 애플리케이션에서 사용되는 정적 파일(CSS 파일, JavaScript 파일, 이미지 파일)들을 저장
  • 정적 파일은 웹 페이지의 스타일이나 동작을 제어하며 한번 업로드된 후에는 수정되지 않고 고정
• config.py
  • config.py 파일은 프로젝트의 설정을 관리
  • 환경 변수, 데이터베이스 연결 정보 등 프로젝트 전반에 걸친 설정을 기록
  • ex) 데이터베이스 URI, 비밀 키, 환경 설정 등을 이 파일에서 정의하고, Flask 애플리케이션이 실행될 때 이를 참조하여 설정을 적용

 

Blueprint

• 문제 상황

create_app함수 안에 새로운 URL 매핑이 필요할 때마다 라우팅 함수들을 계속 추가한다면, create_app함수는 점점 길고 복잡해진다. 애플리케이션의 규모가 커짐에 따라 관리가 어려워지고, 새로운 기능을 추가할 때마다 기존 코드를 수정해야 하는 문제가 발생한다.

• Blueprint의 역할

Blueprint를 사용하면 애플리케이션을 여러 개의 독립적인 모듈로 나눌 수 있다. 각 모듈은 자체적으로 라우팅, 뷰 함수, 템플릿 등을 관리하고, 나중에 메인 애플리케이션에 통합하여 사용할 수 있어서 이를 통해 애플리케이션을 기능별로 나누어 관리할 수 있다.

• Blueprint의 특징

1. 기능별 분리
   • Blueprint를 사용하면 애플리케이션을 기능별로 나누어 관리할 수 있다. 예를 들어, "회원가입", "게시판", "관리자 페이지" 등으로 나눠서 각 기능에 대한 라우팅과 뷰 함수들을 별도의 블루프린트로 관리할 수 있다.
2. 애플리케이션의 확장성 향상
   • 각 Blueprint는 독립적으로 동작하기 때문에, 애플리케이션을 확장하거나 기능을 추가할 때 기존의 코드에 영향을 주지 않고 새로운 기능을 추가할 수 있다.
3. 재사용 가능
   • 한 번 만든 Blueprint는 다른 애플리케이션에서도 재사용할 수 있다.
4. 유지보수 용이
   • 각 기능을 별도의 모듈로 관리하므로 기능을 수정하거나 새로운 기능을 추가할 때 다른 부분에 영향을 주지 않고 작업할 수 있다.

 

이제 Flask 애플리케이션에서 Blueprint를 활용한 라우팅 모듈화해보자

myproject/
│
├── blueprints/
│   ├── __init__.py
│   ├── product.py
│   └── user.py
│
└── app.py

 

 

blueprints/product.py

from flask import Blueprint, jsonify

# Blueprint 생성 (이름: product_bp, URL 프리픽스: /product)
product_bp = Blueprint('product', __name__, url_prefix='/product')

@product_bp.route('/list')
def product_list():
    return jsonify({"message": "Product List Page"})

@product_bp.route('/detail/<int:product_id>')
def product_detail(product_id):
    return jsonify({"message": f"Product Detail for ID {product_id}"})

• 제품과 관련된 라우트를 관리 
• ex) 제품 목록을 보여주는 페이지와 개별 제품 세부 정보를 보여주는 페이지를 제공
• product_bp는 /product URL 프리픽스를 가진 라우트를 정의 
• /product/list와 /product/detail/<int:product_id> URL에 대한 라우팅을 처리

 

blueprints/user.py

from flask import Blueprint, jsonify

# Blueprint 생성 (이름: user_bp, URL 프리픽스: /user)
user_bp = Blueprint('user', __name__, url_prefix='/user')

@user_bp.route('/profile')
def profile():
    return jsonify({"message": "User Profile Page"})

@user_bp.route('/settings')
def settings():
    return jsonify({"message": "User Settings Page"})

• 사용자와 관련된 라우트를 관리, 사용자 프로필과 설정을 보여주는 페이지를 제공
• user_bp는 /user URL 프리픽스를 가진 라우트를 정의 
• /user/profile와 /user/settings URL에 대한 라우팅을 처리

 

 Flask 애플리케이션에 Blueprint 등록

from flask import Flask

from blueprints.product import product_bp
from blueprints.user import user_bp

# Flask 애플리케이션 생성
app = Flask(__name__)

# Blueprint 등록 (user_bp와 product_bp)
app.register_blueprint(user_bp)
app.register_blueprint(product_bp)

@app.route('/')
def hello():
    return 'Hello'


if __name__ == '__main__':
    app.run()

이제 app.py 파일을 만들어서 각 Blueprint를 Flask 애플리케이션에 등록하여 애플리케이션이 각 Blueprint에서 정의한 URL 라우트를 자동으로 사용할 수 있게 한다.

• app.py에서 user_bp와 product_bp를 임포트하여 Flask 애플리케이션에 등록
• @app.route('/')는 기본 페이지. 애플리케이션이 실행되면 'Hello'를 출력

실행 결과

이제 애플리케이션을 실행하면, 각 Blueprint에서 정의한 URL 라우트에 접속할 수 있다.

• /product/list: 제품 목록 페이지
• /product/detail/<int:product_id>: 특정 제품 세부 정보 페이지
• /user/profile: 사용자 프로필 페이지
• /user/settings: 사용자 설정 페이지

 

팩토리 패턴

 

Flask 애플리케이션 생성 방법

from flask import Flask

app = Flask(__name__)

@app.route('/')
def home():
    return 'Hello, Flask!'

if __name__ == '__main__':
    app.run()

이 방식의 단점

• 앱이 하나의 고정된 인스턴스(app)에 종속됨
• 개발 환경, 테스트 환경, 운영 환경별로 다르게 설정하려면 코드가 복잡해짐
• 앱을 초기화할 때 확장 라이브러리들을 따로 등록해야 함

 

팩토리 패턴

from flask import Flask

def create_app():
    app = Flask(__name__)
    
    # 설정 적용
    app.config.from_object('config')

    # 블루프린트 등록 (예: auth 관련 블루프린트)
    from app.blueprints.auth.routes import auth_bp
    app.register_blueprint(auth_bp)

    return app

이 방식의 장점

1. 환경별 설정을 쉽게 분리 가능
2. Blueprint와 같은 기능을 모듈화하기 쉬움
3. 테스트하기 용이

 

개발/운영 환경 설정을 쉽게 바꿀 수 있음

import os

def create_app():
    app = Flask(__name__)

    # 환경 변수에 따라 설정 파일 다르게 로드
    env = os.getenv('FLASK_ENV', 'development')
    
    if env == 'development':
        app.config.from_object('config.DevConfig')
    elif env == 'production':
        app.config.from_object('config.ProdConfig')

    return app