조건문(if), 반복문(for/while), 예외처리문(try/except) 등에서 else를 같이 사용할 수 있다.

python에 대한 많은 도서에서 else를 사용할 수 있는 구문에 대한 설명들을 보았을 때, else의 의미론적 공통점이 없다고 느꼈다.

예를 들어 다음과 같다.

• if 문에서 else는 해당하는 조건이 없을 때 실행됩니다.
• for/while 문에서 else는 break가 실행되지 않았을때 실행됩니다.
• try/except 문에서 else는 except가 실행되지 않았을 때 실행됩니다.

등이다.

마치 else는 각 구문에 따라 달라지며 공통된 의미론이 존재하지 않으며 각 구문에 따라 else의 용법을 달리 생각해야 한다고 느껴진다.

그러나 그렇지 않다고 생각한다. 만일 파이썬이 잘 만들어진 언어라면, else에 대해서도 세가지 모두의 구문에서 공통된 의미론이 존재해야 하며, 그렇지 않을 경우 else가 아닌 다른 구문이 존재했어야 한다고 생각한다.

파이썬은 잘 만들어진 언어라고 생각한다. 그리고 그랬으면 좋겠다. 그렇기에 내 나름대로 else의 공통된 의미론에 대해 기록해 보고자 한다.

else의 의미론은 '적용하는 구문에서 발생하는 핵심 이벤트의 미발생'이라 생각한다.

조건문을 살펴보자. 조건문 사용에 대한 핵심 이벤트는 참(True)인 조건 이다. 반복문을 살펴보자. 반복문의 핵심 이벤트는 반복의 중단점이다. 예외처리문을 살펴보자. 예외처리문의 핵심 이벤트는 예외의 발생이다.

이러한 관점에서 살펴보면 각 구문에서 사용하는 else의 공통 된 의미를 부여할 수 있다.

조건문의 의미관점에서 핵심 이벤트는 참인 조건을 찾기위한 것이기에, else 문이 실행된다는 것은 조건문의 핵심 이벤트가 발생하지 않았음을 의미한다.

반복문의 의미관점에서 핵심 이벤트는 반복의 중단점을 찾기 위한 것이므로 else문이 실행된다는 것은 반복문 구문내에 break라는 중단 이벤트가 발생하지 않았음을 의미한다.

예외처리문의 의미관점에서 핵심 이벤트는 예외를 잡아내는 것이기에 else문이 실행된다는 것은 해당 구문에서 예외가 발생하지 않았음을 의미한다.

이러한 관점에서 else문을 바라볼 경우 한 문맥으로 else를 이해할 수 있는 방법 중 하나가 될것이라 생각한다.

과연 각 케이스마다 else에 서로다른 의미를 부여하여 케이스스터디로 다루어야 하는가?

그저 터미널에서 사용자의 입력이 필요할 때 사용하죠. 단순히 '키보드 입력 받을 때 쓰는 함수'라고만 이해해선 안된다고 생각합니다. 어떻게 동작하는지 이해해야 input() 을 사용하는 프로그램을 다른 방식으로도 다룰 수 있습니다.

아마 처음 언어를 배우고 이것을 활용하기 위해 간단한 CLI 기반 게임을 많이들 만들 겁니다. 오목게임이라든가, 숫자 야구게임 등등...

이런 프로그램을 만들기는 쉽습니다. 사용자의 입력을 받고, 로직을 검사하고, 출력을 만들어내죠. 사용자의 입력은 input() 메서드를 통해 만들겁니다.

하지만 문제에 봉착하는 순간은, 이렇게 만든 프로그램에 대한 테스트 코드를 작성할 때 나타날겁니다.

프로그램 실행 시, 어떻게 터미널에 입력할 내용을 자동으로 주입할까??

input() 메서드를 통해 사용자 입력을 만드는건 아주 쉽습니다. 생각할 필요도 없죠. 하지만 테스트를 해야 한다면, 사람이 직접 터미널에 입력을 하는 것이 아니라, 시스템에서 자동으로 주어진 입력을 하도록 만들어야 합니다.

컴퓨팅 시스템을 왜 이해하는 것이 중요한 대목입니다. 사용자의 입력을 받는 함수가 어떻게 동작을 하는지, 어떤 컴퓨팅 자원과 시스템을 활용하는지 알아야 해당 문제에 접근하고 해결할 수 있을 것입니다.

컴퓨터 관점에서 사용자 입력은 어떤 동작으로 구성될까? 제 가정은 다음과 같았습니다.

• input() 메서드는 사용자의 키보드 입력(표준입력)을 기다리는 프로세스를 만든다.
• 사용자가 키보드를 통해 입력을 만들어 내면, 입력한 내용을 임시적인 버퍼에 담는다.
• 입력 프로세스는 입력 버퍼를 계속 감시하며, 버퍼에 엔터(\n)가 입력되는 순간 \n 전까지 입력된 내용들을 소비한다.

이 가정을 기반으로 input() 메서드에 사용자가 직접 입력하는 것이 아닌, 시스템상으로 자동으로 주입할 수 있을지 가정을 해봅시다.

• input() 프로세스가 표준 입력을 감시하며, 감시는 표준 입력 버퍼를 통해 이루어 진다면,
• 표준 입력 버퍼에 특정 텍스트를 강제로 주입.
• 알아서 input() 메서드는 해당 버퍼를 읽고 이것은 사용자가 입력한 텍스트다 라고 인식할 것이다.

한 번 이 가정을 토대로 코드를 만들어 봅시다.

먼저, 사용자의 입력을 받는 함수입니다.

def create_input():
    text = input("여기에 입력해 주세요 : ")
    return text


input_text = create_input()
print(input_text)

실행 시, 여기에 입력해 주세요 : 가 나타나며, hello를 입력 시, hello를 출력합니다.

이 함수를 자동으로 테스트 하기 위해서는 사용자가 직접 입력하는 것이 아닌, 코드상으로 자동으로 주입될 수 있어야 합니다. 제 생각엔 아마 표준입력 버퍼에 텍스트를 강제로 밀어넣은 상태라면, 알아서 읽지 않을까 합니다.

sys.stdin 모듈이 적합하겠군요. 파이썬의 표준입력에 대한 모듈입니다. 이걸 한번 이용해 봅시다.

import sys


def create_input():
    text = input("여기에 입력해 주세요 : ")
    return text


sys.stdin = "hello"


input_text = create_input()
print(input_text)

실행결과, AttributeError: 'str' object has no attribute 'readline' 이 발생합니다.

이럴수가, 실패했네요.

sys.stdin의 타입은 TextIO 입니다. 아마 버퍼를 읽는 과정에서 내부적으로 readline이 구현된 객체를 통해 입력을 처리하는가 봅니다.

그럼 텍스트가 아닌, TextIO와 호환되는 io.StringIO 객체에 텍스트를 넣은 상태로 sys.stdin에 주입해 봅시다.

import sys
from io import StringIO


def create_input():
    text = input("여기에 입력해 주세요 : ")
    return text


sys.stdin = StringIO("hello")


input_text = create_input()
print(input_text)

실행 시, 출력은 다음과 같습니다.

여기에 입력해 주세요 : hello

create_input() 메서드 호출하기 앞서서 stdin이 있어야 합니다. stdin이 뒤에 올 경우, input 함수는 그저 사용자의 입력을 받기 위해 무한히 대기하며 다음줄로 넘어가지 않기 때문입니다.

input() 을 통해 출력한 메시지인 여기에 입력해 주세요 : 와 String.IO를 통해 우리가 주입한 hello 라는 텍스트가 결합되어 출력된 것입니다. 예외가 발생하지 않고 잘 처리되었습니다. 사용자가 입력할 필요도 없이 알아서 주입되었습니다.

그렇다면 다중 입력이 필요한 경우는 어떨까요? 이제 create_input() 함수는 내부에 사용자 입력을 3번 받아야 하는 함수로 만들어 봅시다.

그리고 함수를 호출할때 자동으로 입력을 주입하기 위해서, 제 생각엔 String.IO 객체에 입력 텍스트를 \n으로 구분하여 "hello\nworld\n!" 로 주입하면, sys.stdin 버퍼에서 해당 텍스트를 \n 을 기준으로 소비하며, 소비한 내용은 버퍼에서 없애주지 않을까 합니다. 첫번째 소비는 hello 일 것이며, 두번째 소비는 world, 세번째 소비는 ! 하게 되지 않을까 합니다.

from io import StringIO


def create_input():
    text1 = input("여기에 입력해 주세요1 : ")
    text2 = input("여기에 입력해 주세요2 : ")
    text3 = input("여기에 입력해 주세요3 : ")
    return text1 + text2 + text3


sys.stdin = StringIO("hello\nworld\n!")


input_text = create_input()
print(input_text)

실행 시, 출력은 다음과 같습니다.

여기에 입력해 주세요1 : 여기에 입력해 주세요2 : 여기에 입력해 주세요3 : helloworld!

제가 직접 입력하지 않아도 자동으로 입력되었으며, 예상대로 잘 동작했습니다.

input 입력 문구들이 나란히 출력되는 이유는 아마 readline()함수가 텍스트를 읽음에 있어서 \n까지 읽고 \n은 없애버렸기 때문이지 않을까 싶습니다.

이제 터미널 기반 프로그램을 작성한다면, 이를 이용해 테스팅 모듈을 작성할 수 있을 것입니다. 사용자 입력을 받아야 한다면, 시스템상에서 자동으로 입력될 수 있도록 만들 수 있을 것입니다.

Django Message Framework

Django 메시지 프레임워크의 자세한 사항은 Django 공식 문서를 참고하는게 가장 좋습니다. https://docs.djangoproject.com/en/5.0/ref/contrib/messages/

해당 포스팅은 메시지 프레임워크에 대한 구체적인 설명이 아닌, 메시지 프레임 워크를 이용한 몇개의 커스텀 팁입니다.

Default Message Level 변경

Django의 메세지 레벨은 5개로 분류됩니다.

• DEBUG(value: 10)
• INFO(value: 20)
• SUCCESS(value: 25)
• WARNING(value: 30)
• ERROR(value: 40)

Django 에서의 기본 메시지 레벨은(Default level)은 INFO 이며, 따로 수정을 하지 않는다면, INFO 레벨 이상의 메시지만 출력합니다.

만일 DEBUG 레벨 메시지까지 출력하고자 한다면, 다음과 같이 설정할 경우 기본 메시지 레벨을 변경 할 수 있습니다.

#settings.py
if DEBUG:
    from django.contrib.messages import constants as message

    MESSAGE_LEVEL = message.DEBUG

View Endpoint 별 Massage Level 제어

프로젝트 전반적인 메시지 레벨을 설정하는 것 이외에, 각 view endpoint 마다 메시지 레벨을 커스텀 하게 변경해야 할 수도 있습니다. 이 경우, view 함수에서 django.contrib.messages 의 set_level(request, level) 함수를 통해 각 엔드포인트 마다 메시지 수준을 다르게 정의 할 수도 있습니다.

예를 들어, settings.py에 프로젝트 전반 메시지 수준을 DEBUG로 설정하였으나, 특정 view endpoint에서는 WARNING 이상의 메시지만 사용하도록 제어하고 싶다면, 다음과 같이 view 함수에 설정할 수 있습니다. 여기서는 index 라는 임의의 뷰 함수를 정의하였습니다.

from django.contrib import messages

def index(request: HttpRequest) -> HttpResponse:

    messages.set_level(request, level=messages.WARNING)

    messages.debug(request, message="디버그 메시지")
    messages.info(request, message="정보 메시지")
    messages.success(request, message="성공 메시지")
    messages.warning(request, message="경고 메시지")
    messages.error(request, message="에러 메시지")
    return render(request, "index.html")

messages.set_level(request, level=messages.WARNING) 이므로, 해당 엔드포인트는 WARNING, ERROR 레벨의 메시지만 전달 됩니다. 그 보다 수준이 낮은 레벨들은 사용할 수 없습니다.

전역으로 지정한 메시지 레벨에 대하여, 각 view 함수의 레벨을 상이하게 설정할 수 있습니다. 전역으로 지정한 메시지 레벨보다 view 함수의 messages.set_level(request, level) 이 우선합니다. 즉, 전역 레벨은 ERROR라도, view 함수에서 messages.set_level(request, DEBUG) 라면, Debug 레벨의 메시지를 담을 수 있습니다.

Message Tag Name 커스텀

HTML CSS 렌더링을 위해, 부트스트랩을 사용하며, alert 클래스를 통해 메시지를 화면에 출력하는 경우, 일부 메시지 태그는 부트스트랩 CSS가 적용되지 않을 수 있습니다.

장고 메시지 레벨은 debug, info, success, warning, error 임에 비하여, 부트스트랩 alert- 옵션은 primary, secondary, info, success, warning, danger 의 이름을 사용하기 때문입니다.

만일, django template에서 {{ message.tag }} 를 통해 메시지별 색상을 렌더링 하고자 한다면,

<div class="container">
  {% for message in messages %}
      <div class="alert
              {% if message.level_tag == "debug" %}
                  alert-secondary
              {% elif message.level_tag == "error" %}
                  alert-danger
              {% else %}
                  alert-{{ message.level_tag }}
              {% endif %}">
          {{ message.message }}
      </div>
  {% endfor %}
<div>

와 같이, if문과 elif 문으로 적절히 변경해주는 작업이 필요할 수 있습니다. 이 경우 시각적으로 복잡하며 아주 귀찮은 작업입니다. 가장 간단하게 해결하기 위해서는, 부트스트랩을 사용한다면 django-bootstrap 서드파티 라이브러리를 설치하고, {{ bootstrap_messages }} 를 사용하면 간단히 해결 가능합니다.

다음과 같이 태그를 적용해주면

<div class="container">
    <h1>Django Message Framework 테스트</h1>
    {% bootstrap_messages %}
</div>

과 같이 메시지가 쉽게 렌더링 됩니다.

또 다른 방법으로는 django.contrib.messages.constants.py 의 DEFAULT_TAGS를 오버라이딩 할 수도 있습니다. DEFAULT_TAGS 는 다음과 같이 정의되어 있습니다.

# django.contrib.messages.constant.py

DEFAULT_TAGS = {
    DEBUG: "debug",
    INFO: "info",
    SUCCESS: "success",
    WARNING: "warning",
    ERROR: "error",
}

한번 이걸 변경해 봅시다. debug는 부트스트랩 alert-primary와 매칭시킬 것이고, error는 부트스트랩 alert-danger와 매칭시킬 것입니다. 따라서 다음과 같이 변경해 봅시다.

# settings.py
if DEBUG:
    from django.contrib.messages import constants as message

    MESSAGE_LEVEL = message.DEBUG
    message.DEFAULT_TAGS.update({10: "primary", 40: "danger"})

DEFAULT_TAG 딕셔너리의 레벨에 대한 값을 변경한 것입니다. (django.contrip.messages.constants.py 에서, DEBUG 상수는 10, ERROR 상수는 40으로 세팅되어 있기 때문에, 키 값을 레벨 정수를 사용한 것입니다.)

이제, 부트스트랩 class 속성의 alert alert-{{ message.level_tag }} 는 다음과 같이 매칭 됩니다.

• DEBUG -> alert alert-primary
• INFO -> alert alert-info
• SUCCESS -> alert alert-success
• WARNING -> alert alert-warning
• ERROR -> alert alert-danger

아래와 같은 HTML은,

<div class="container">
    <h1>Django Message Framework 테스트</h1>
    {% for message in messages %}
        <div class="alert alert-{{ message.level_tag }}">{{ message.message }}</div>
    {% endfor %}
</div>

이렇게 부트스트랩 렌더링 됩니다.

디버그 레벨의 이름은 'primary'로 변경되어, alert-primary 로 렌더링 되었으며, 에러 레벨의 이름은 'danger'로 변경되어, alert-danger 로 렌더링 된 것을 확인할 수 있습니다.

RESTful Web API (부제: 웹 API를 위한 모범 전략 가이드)

레오나르도 리처드슨(Leonard Richardson), 마이크 애먼슨(Mike Amundsen), 샘 루비(Sam Ruby)

처음 웹 개발을 입문하고 나서 공부를 시작하는 과정에서 RESTful API라는 개념을 접하게 되었다. 많은 웹개발 회사에서 RESTful API에 대한 지식을 요구하고 있었기에, 해당 개념이 뭔지 블로그를 통해 찾아보기도 했던 기억이 난다.

블로그를 통해 이에 대한 깊이있는 지식을 습득하기란 쉽지 않았던 것으로 기억한다. 대부분은 그저 큰 그림과 개요에 불과하였으며, 무려 "RESTful API" 라는 엄청나 보이는 추상적인 개념에 비해 너무나 쉽고 짧게 요약된 몇가지의 규칙정도만 나열되어 있었던 것으로 기억한다.

나는 평소 서점을 들르는 것을 좋아한다. 서점에 들른 어느 날, 개발 관련한 책을 살펴보며 해당 책을 발견하였다. 제목부터가 강렬한 RESTful API. 뭔가 이 책을 읽으면 RESTful에 대해 깊이있는 지식과 체계적으로 습득할 수 있을것 같다는 생각이 들어 구매하게 되었다.

집에 오는 길에 책을 읽는데....

이상하다. 책이 읽히지 않는다. 나는 RESTful API를 알고 싶었는데, 앨리스가 광고판을 클릭해서 웹사이트를 여행하며, 갑자기 미로게임 API를 설명하고 처음 들어보는 'Maze+XML', 'Collections+JSON' 미디어 타입을 소개한다.

'의미체계', '하이퍼 미디어' 등 추상적인 개념이 더해지며, 책 자체가 상당히 추상적이라는 생각이 들었다.

내가 생각했던 RESTful API 가이드는,

1. RESTful한 URL은 이렇게 지으세요~
2. 이러이러하게 HTTP 메서드를 써야 RESTful한 거랍니다~ 같은 것을 기대했기 때문이다.

이런 것을 기대했다면 이 책은 적합하지 않다고 본다. 처음 책을 읽고 몇개월 방치 한 후, 다시 이 책을 진득하게 읽어나가기 시작했다.

지금 생각해도 상당히 추상적인 책이지만, 개인적으로 만족스럽다. 좋은 책이라고 생각한다.

이 책은 단지 RESTful API를 위한 공식을 나열하는 책이 아니다. 이 보다는 오히려 하이퍼 미디어, 리소스, 리소스의 표현 등 다소 추상적이지만 생각해 볼만한 것들이 존재한다. 대부분의 웹개발을 처음 시작하는 이들은 하이퍼미디어 리소스라 하면 그저 HTML에 익숙할 것이다. 그리고 생각의 범위는 HTML으로 쉽게 귀속되며 국한된다.

이 책은 하이퍼 미디어 유형 중 하나일 뿐인 HTML에 귀속되지 않는다. 다양한 하이퍼미디어 타입을 소개하며 그저 HTML이 아닌, 하이퍼 미디어 자체에 대해 생각하게 해준다. RESTful API에 대해 리소스, 리소스의 표현, 의미체계(Semantic), 하이퍼미디어 유형 등 다소 추상적이라 할수 있는 개념들에 대해 생각 하고 고민해 볼 수 있는 시간을 선사한다.

그렇기에 좋은 책이라 생각한다. HTML이라는 나무에서 멀어져 하이퍼 미디어 라는 숲을 보게 도움을 주는 책이다. 처음 접했을 때에 너무 난해하여 읽다 말았지만, 어느정도 공부를 하고 이런저런 잡지식을 많이 쌓고 나서 다시 읽으니 좋은 책이라는 생각이 든다. 애초에 RESTful API의 개념 자체가 단순한 규칙의 집합이 아니며, 철학과 담론을 담고 있기에 추상적이다. RESTful이 그저 '코딩 컨벤션'과 같은 규칙의 나열이 아니기 때문이다.

웹에 대해 처음 접하는 이들에게 좋은 책은 아니라 생각이 든다. 이 경우 오히려 'HTTP 완벽가이드'와 같은 책이 훨씬 유익하며 도움이 될 것이다. HTTP라는 프로토콜, 동작, 상태코드 등 HTTP에 대한 기본 지식이 있는 상태에서 이 책을 읽는것이 보다 유용할 것이라 생각한다.

내가 이 책을 읽고나서, 웹어플리케이션을 작성함에 있어서 엄청나게 RESTful한 개념을 적용해서 멋진 뭔가를 해낼 수 있다는 생각은 들지 않는다. 그러나, '리소스', '리소스의 표현', '프로토콜의 의미체계(Protocol semantic)', '애플리케이션 의미체계(Application semantic)' 등에 대해 고민하고 생각할 수 있을 것이다.

공기라는 개념을 배우지 못했다면 그리고 생각해 본 적도 없다면, 허공에 팔을 휘저음에 있어서 미약한 공기의 저항에 대하여 무언가가 존재한다는 것을 생각 조차 할 수도 없지 않겠는가?

도서 평을 보면 '번역'에 대해 불만을 가지는 평이 보이곤 하지만, 번역의 문제보다는 추상적인 개념들이 많기에 그럴 수 밖에 없다고 생각한다. 'Semantic', 'Representation of resource'과 같은 다소 추상적인 개념을 어떻게 완벽히 이해할 수 있는 한국어 단어로 표현할 수 있겠는가?

이 책은 RESTful API의 이름을 달고 나왔으나, RESTful에 대한 비중이 높다고 생각하진 않는다. 그렇기에 RESTful 자체를 파고드는 책이라 생각하고 구매한다면 실망스러울 것이라 생각한다. HTML 이라는 하이퍼 미디어 중 하나에 불과한 하이퍼 미디어 개념을 벗어나, 하이퍼 미디어에 대한 보다 넓은 개념과 이것이 지니는 의미론에 대해 고민해보고 싶다면 좋은 책일 것이다.

뷰 에서 장고 폼 객체를 사용하여, 데이터의 유효성 검증하는 로직은 장고를 통해 간단한 웹어플리케이션을 만들어 보았다면 익숙할 것이다.

주로 Fucntion Based View를 통해, 포스트(POST) 방식으로 전송된 데이터를 장고 폼 객체의 데이터로 바운드 시킨 후에, 데이터의 유효성을 is_valid()로 검증을 하곤 한다.

여기서 장고 폼이 내부적으로 어떻게 필드의 유효성을 검사하는지에 대한 동작이 궁금해졌다. 따라서, 해당 포스팅을 통해 내부적으로 장고 폼이 유효성을 검사하는 로직에 대해 소개하고자 한다.

먼저 장고 BasedForm 의 is_valid() 내부 구현을 살펴보면 다음과 같다.

class BasedForm(RenderableFormMixin):
    ...
    def is_valid(self):
        return self.is_bound and not self.errors
    ...

우리가 폼 데이터 유효성 검사를 위해 is_valid() 를 호출할 경우,

1. 바운드 된 모델이 있는지(self.is_bound),
2. 유효성 검증 후 발생한 에러를 가지지 않는지(not self.errors) 를 확인한다.

여기서, errors의 로직은 다음과 같이 @property 로 정의되어 있다.

    @property
    def errors(self):
        if self._errors is None:
            self.full_clean()
        return self._errors

즉, BasedForm 객체의 필드로 정의되어 있는 _errors가 비어있을 경우(Form 객체 생성시 None으로 초기화 되어있음), full_clean() 메서드를 호출하게 된다. full_clean() 메서드가 유효성 검증 로직을 담당하며, 이 과정에서 ValidationError가 발생 시, 발생한 에러를 self._errors 에 추가하여, errors는 수집된 에러들을 반환하는 것이다.

그럼 이제 full_clean() 메서드의 내부구현을 살펴보자.

def full_clean(self):
    self._errors = ErrorDict()
    if not self.is_bound:  # Stop further processing.
        return
    self.cleaned_data = {}
        if self.empty_permitted and not self.has_changed():
            return

    self._clean_fields()
    self._clean_form()
    self._post_clean()

full_cleaned() 메서드는 내부에 self.clean_data 딕셔너리를 포함하며, 여기에 유효성이 검증된 데이터를 필드이름과 값의 키-값 으로 저장할 것이다.

그렇다면, 어떻게 self.cleaned_data에 값을 저장하는가?

self._clean_fields(), self._clean_forms(), self._post_clean() 을 차례대로 호출하면서 유효성 검증 결과를 채워나가는 것이다. 즉, full_clean() 메서드는 각 필드의 유효성 검증 순서를 정의하며, 유효성이 검증된 데이터를 관리한다.

우리가 view 에서 form.is_valid() 호출 후, 유효성이 검증된 데이터 사용을 위해 cd = form.cleaned_data 사용할 수 있는 것은,

1. is_valid() 호출 시, 내부적으로 errors 호출
2. erorrs 호출 시 내부적으로 full_clean() 호출
3. full_clean() 내부 self.cleaned_data 정의 및 유효성이 검증된 데이터를 추가.

하는 단계를 거친다는 것이다.

full_clean() 메서드가 포함하는 clean 함수들 중 추가적으로 알아 볼만 한 것은 _clean_fields() 이다. 해당 코드는 다음과 같다.

def _clean_fields(self):
    for name, bf in self._bound_items():
        field = bf.field
        value = bf.initial if field.disabled else bf.data
        try:
            if isinstance(field, FileField):
                value = field.clean(value, bf.initial)
            else:
                value = field.clean(value)
            self.cleaned_data[name] = value
            if hasattr(self, "clean_%s" % name):
                value = getattr(self, "clean_%s" % name)()
                self.cleaned_data[name] = value
        except ValidationError as e:
              self.add_error(name, e)

해당 로직이 각 필드를 조회하여 유효성을 검증하는 로직을 가지며, 이 과정에서 유효성 검사가 실패할 경우, self._errors에 발생한 에러를 추가하고 그렇지 않을 경우 self.cleaned_data에 유효성 검증 완료 된 값을 추가한다.

조금 더 알아볼만한 것은, 커스텀 필드 유효성 검증 또한 해당 로직에서 담당한다는 것이다.

예를 들어, Form에 email 필드가 정의되어 있으며, 해당 이메일은 중복되어서는 안된다고 해보자. 우리는 이 경우, Form 객체에 에 다음과 같은 커스텀 유효성 검증 로직을 추가할 수 있을 것이다.

class MyForm(forms.Form):
    email = forms.EmailField()

    def clean_email(self):
        ## 이메일 중복 검사 로직
        return <email 값>

이와 같이 cleand_<field name>() 함수를 정의하여 커스텀 유효성 검증 로직을 추가할 수 있는 것은, cleaned_fields() 에서

if hasattr(self, "clean_%s" % name):
    value = getattr(self, "clean_%s" % name)()
    self.cleaned_data[name] = value

로직이 존재하기 때문이다.

따라서 우리는 특정 필드에 유효성 검증 로직을 커스텀 제어하고자 할 경우, clean_<field name>() 함수만 정의하면 내부적으로 알아서 해당 코드에 대한 유효성검증 로직이 수행된다는 것이다.

Form의 유효성 검증 과정 요약

• is_valid() 호출 시, 내부에서 errors property logic을 호출
• erros 프로퍼티는 내부에서 full_clean() 호출
• full_clean() 은 내부에 self.cleaned_data 딕셔너리를 포함
• full_clean() 은 내부에 _cleand_field() 등 유효성 검증 로직을 수행
• _cleand_field() 등이 실제 유효성 검증 로직을 수행하며, 유효성을 만족할 경우 해당 데이터를 self.cleaned_data에 추가

+ clean_<field name> 과 같이 커스텀 유효성 검증 함수를 추가할 수 있는 것 또한 _clean_field() 가 이를 인식할 수 있도록 만들어졌기 때문.

@login_required 데코레이터는 어떻게 동작할까?

root endpoint (http://localhost:8000/) view에 @login_required 를 적용한다고 해보자.

이 경우, http://localhost:8000/ 은 로그인 하지 않은 상태에서는, @login_reqired에 의해 http://localhost:8000/accounts/login/?next=/ 으로 리다이렉트 된다.

난 로그인에 대한 그 어떤것도 작성하지 않았음에도, @login_required를 적용하면 /account/login/?next=/ 로 자동으로 페이지가 이동하는 것이다.

이유가 뭘까?

먼저, @login_required는 settings.py에 정의된 LOGIN_URL 값을 참조하여 url을 생성하여 해당 url로 이동하게 된다.

django.conf.global_settings.py를 보면, 다음과 같이 Default LOGIN_URL이 정의되어 있다.

LOGIN_URL = "/accounts/login/"

따라서, login url에 대한 어떤 사용자 정의가 없어도, 해당 url(http://localhost:8000/accounts/login/)로 이동하는 것이다.

그렇다면, ?next=/ 쿼리 스트링은 무엇인가?

해당 엔드포인트가 @login_required로 인해, 로그인 하지 않은 상태에서는, login 페이지로 자동으로 이동하게 된다. 로그인에 성공할 경우, 원래 접근하고자 했던 endpoint(http://localhost:8000/)로 다시 돌아갈 수 있어야 하는 것이 타당할 것이다. 이를 위해 next 라는 쿼리스트링을 자동으로 추가하여,로그인 후 처음에 접근하고자 했던 엔드포인트로 돌아가도록 만드는 것이다.

예를 들어, http://localhost/aaa/ 엔드포인트가 @login_required로 보호된다고 해보자. 이 경우 엔드포인트 접근 시, 자동으로 http://localhost/accounts/login/?next=/aaa 로 리다이렉트 되며, 해당 로그인 페이지에서 로그인이 성공할 경우, next=/aaa 쿼리스트링을 통해 다시 http://localhost/aaa 로 리다이렉트 되는 것이다.

Class Based View인 LoginView 또한 내부적으로 url의 next 쿼리스트링으로 로그인 성공시 이동하는 페이지를 제어가능하다.

next 쿼리스트링이 존재하지 않을 경우, django.conf.global_settings.py에 정의 된

LOGIN_REDIRECT_URL = "/accounts/profile/"

로 이동하나, url에 next 쿼리스트링이 존재할 경우, 이것이 우선한다. 즉, next 쿼리스트링을 통해 로그인 후 이동할 페이지에 대해 사용자 제어 가능하다는 것이다.

LoginView를 사용할 경우, next는 템플릿 변수로 템플릿에 전달되며, html에서 {{next}}를 통해 사용 가능하다. 로그인 폼 html 페이지에서,

<input type="hidden" name="next" value="이동하고자 하는 위치" />

를 추가할 경우, 로그폼과 함께, next 변수는 '이동하고자 하는 위치'로 전달되며, ListView는 next 변수 대로, 이동하도록 할 수 있다. 즉, 로그인 후, http://localhost/이동하고자-하는-위치 로 리다이렉트 시킬 수 있는 것이다.

나는 처음에 Django 에서 next 변수를 왜 사용하는지 잘 이해가 되지 않았다. 이제는 좀 알것같다. 그리고 이것을 통해 보다 유용하게 Django를 사용할 수 있을것 같다.

Django에서의 규칙이 존재할 경우, 이를 잘 활용할 수 있으며 적극적으로 이용해야 한다고 생각한다.

@login_required를 정리해 보자면,

• 해당 엔드포인트 접근 시, settings.py 에 정의된 LOGIN_URL 로 이동. (login page의 url 에는 로그인 성공 시 원래 페이지로 돌아가기 위한 next 쿼리스트링이 존재.)
• 로그인 성공 시, next 쿼리스트링에 포함된 페이지로 리다이렉트.
• settings.py의 LOGIN_REDIRECT_URL 과 next 쿼리스트링 중 next 가 우선.

대부분의 Django 기초 혹은 입문 책과 강의를 접하여 학습 하는 과정에서, 대개 TextField의 max_length 옵션을 제한하지 않고 비워 둔 채로 사용하는 것을 심심찮게 경험하였다. 나 또한 아무 생각없이, TextField가 필요하다면, 그저 some_field = models.TextField()로 정의하여 사용하였다.

그러다, 김성렬님의 '백엔드 개발을 위한 핸즈온 장고' 책을 학습하던 중,

"TextField는 기본적으로 DB에 따라 다르나 최대 1GB 까지 저장 될 수 있다."

라는 내용을 보고, TextField를 사용함에 있어 엄격하게 max_length 옵션을 사용해야 한다는 생각이 들었다.

만일 Model 객체가 TextField를 포함하며, max_length 옵션이 지정되지 않았다면?

악의적인 사용자 가 존재할 경우, 해당 텍스트 필드가 허용하는 최대한 길의의 무의미한 텍스트를 전송하여, _의도적으로 Server 리소스를 낭비_시킬 수 있을 것이다.

이에 대해 간단히 테스트를 해보았다.

title(CharField)과 description(TextField) 를 가지는 Post 객체를 만들어, sqlite3 DB에 대용량의 텍스트 데이터를 저장하는 테스트를 하였다.

파이썬 쉘을 통하여, 다음과 같은 텍스트를 DB에 저장해 보았다.

>> text = 'a' * (10**8)
>> post = Post(title='Test Title', description=text)
>> post.save()

생성 된 Data를 확인 해 보니, 실제 DB에서는 약 200KB 의 데이터가 저장되었음을 확인하였다. String을 Byte로 변환하여 저장하므로, 예상한 String의 크기보다 적은 용량이 저장되었다.

그렇다면, byte type text data를 전송 및 저장한다면? 저장할 텍스트를 바이트 데이터로 변경하여 저장 해보았으며. 1byte 크기 byte문자를 약 800MB 사이즈로 저장해 보았다.

>> text = b'a' * (8*10**8)   # byte 문자열 800MB
>> post = Post(title='Test Title', description=text)
>> post.save()

실제 DB에서도 약 800MB 사이즈의 크기를 가진 row 데이터가 생성되었으며, 프로젝트 폴더의 크기가 단 한개의 row를 가짐에도 불구하고, 800MB의 크기를 가지는 것을 확인하였다. (sqlite 사용시 프로젝트 폴더 내, db 파일을 통해 데이터를 저장하므로)

만일 프로젝트가 max_length를 엄격하게 적용하지 않은 TextField 를 사용하는 경우, 악의적인 의도로 byte data를 1GB까지 꽉 채워서 서버에 저장하도록 할 수 있다는 것이다. 1000개만 보내더라도, 1TB의 저장공간을 간단하게 소모시킬 수 있을 것이다.

'강건한' 서버를 염두한다면, TextField 의 사용 또한 엄격하게 적용해야 할 것으로 생각된다. 나 또한 이 점을 기억하고 프로젝트를 함에 있어 엄격히 적용해야 함을 느끼게 되었다.

Client 측에서 입력 데이터의 크기를 제한할 수도 있을 것이나, 만약 변경에 의해 그러한 중요한 사항이 누락 된다면? Server의 책임을 단지 Client에게 책임을 전가할 수 없을 것이다.