본 크롬 확장프로그램은 사용자의 개인정보 및 민감한 데이터를 일체 수집하거나 처리하지 않습니다.

• 데이터 수집 및 공유 본 확장프로그램은 어떠한 형태의 사용자 데이터도 수집하지 않습니다. 개발사 및 제 3자와의 데이터 공유는 전혀 이루어지지 않습니다.
• 문의 안내 본 개인정보 처리방침과 관련하여 궁금한 점이 있으시면 언제든지 아래 이메일로 문의해 주시기 바랍니다. 성심껏 답변 드리겠습니다. 연락처: rlaqhqo9372@gmail.com

Privacy Policy - Chrome Extension

This Chrome extension does not collect or process any personal or sensitive user data.

• Data Collection and Sharing This extension does not collect any form of user data. No data is shared with the developers or any third parties.
• Contact Information If you have any questions regarding this privacy policy, please feel free to contact us at any time. We will be happy to assist you. Email: rlaqhqo9372@gmail.com

RAG 란?

RAG(Retrieval-Augmented Generation / 검색-증강 생성)는 대규모 언어 모델의 출력을 최적화하여 응답을 생성하기 전에 학습 데이터 소스 외부의 신뢰할 수 있는 지식 베이스를 참조하도록 하는 프로세스입니다.

이에 대해 자세히 알아보기 전에 '대규모 언어 모델'이 무엇인지 부터 알아보겠습니다.

LLM(Large Language Model / 대규모 언어 모델)은 은 지능형 챗봇이나 자연어 처리 애플리케이션을 지원하는 핵심 인공 지능 기술입니다. LLM은 굉장히 많은 양의 데이터 학습을 통해 높은 자연어 이해력을 지니고 있어, 언어의 구조와 의미를 이해하고 다양한 언어 관련 작업을 처리할 수 있습니다. 대표적인 모델로는 OpenAI의 GPT,구글의 Gemini, 메타의 LLAMA 등이 있습니다.

하지만 LLM에는 다음과 같은 단점이 존재합니다.

• 명확한 정보가 부족할 때, 부정확하거나 추정된 정보를 제공할 가능성이 있습니다.
  예를 들어, 제가 개발한 게임의 NPC에 관련된 질문은 일반적인 LLM은 정확한 답변을 할 수 없어 추정된 정보를 제공합니다.

• 사용자가 구체적이고 최신 정보를 요청할 때, 오래되었거나 일반적인 내용을 응답하여 기대와 일치하지 않는 답변을 줄 수 있습니다.
  예를 들어, 노벨문학상을 수상한 '한강' 작가의 노벨문학상 수상 정보는 비교적 최근의 정보이기에 정확한 답변을 하지 못할 수 있습니다.

RAG는 이러한 한계를 극복하기 위해 LLM이 답변을 생성하기 전에 특정 도메인에 대한 지식과 같은 외부 데이터 소스를 참조하여 생성 텍스트 출력을 더 잘 제어하고 답변의 정확도를 높이도록 합니다.

RAG의 동작 과정

1. 입력 쿼리 작성

• RAG 기술은 입력쿼리로 시작됩니다. 사용자는 특정 답변을 위한 질문 또는 작업 요청 텍스트를 입력합니다.

  입력:

  • "'알렉산드로 춘봉'의 나이는 몇살이야?"

2. 입력쿼리 벡터 임베딩

• RAG 기술은 LLM의 원래 학습 데이터 세트 외부에 있는 새 데이터 소스를 참조합니다. 텍스트, 이미지 등과 같이 다양한 형식의 외부 데이터는 벡터표현으로 변환되어 벡터 데이터베이스에 저장되어 있습니다. 이러한 외부 데이터와의 매칭을 위해 사용자 입력쿼리 또한 임베딩을 통해 벡터표현으로 변환합니다.

* _벡터 데이터베이스란? 벡터 데이터베이스는 정보를 벡터(데이터 객체의 수치 표현)로 저장하는 데이터베이스입니다. _

• 벡터 임베딩이란? 벡터 임베딩은 주제, 단어, 이미지 또는 기타 데이터를 숫자로 표현한 것입니다.

  벡터 데이터베이스에 저장된 정보:

  • "게임 '밥은 먹고 다니냐'의 NPC 정보"
  • NPC 알렉산드로 춘봉
    • 나이 : 32
    • 성별 : 남성
    • 직업: 여행자 겸 음식 평론가
    • 출신지: 남쪽의 바다 근처 작은 마을

3. 관련 자료 검색 추출

• 벡터표현으로 변환된 사용자 입력쿼리를 활용하여 외부데이터와 매칭하고, 관련있는 데이터 소스를 추출합니다. 관련성은 수학적 벡터 계산 및 표현을 사용하여 계산되고 설정됩니다.

  추출된 정보 :

  • 알렉산드로 춘봉, 나이 : 32

*4. LLM 프롬프트 확장 통신 *

• 검색된 관련 외부 데이터를 컨텍스트에 추가하여 사용자 입력쿼리를 보강합니다. 이렇게 보강되고 확장된 입력을 LLM과 통신하여 전달합니다. 이 단계에서는 신속한 엔지니어링 기술을 사용하여 LLM과 효과적으로 통신합니다.

  확장된 입력쿼리 :

  • [ 알렉산드로 춘봉, 나이 : 32 ] 라는 정보에서 알렉산드로 춘봉의 나이는 몇살이야?

5. 텍스트 답변 생성

• LLM은 전달받은 입력에 대해 답변을 생성하여 제공합니다. 확장된 프롬프트를 사용함으로 LLM은 사용자 압력쿼리에 대해 보다 정확하고 입력에 더 부합한 답변을 생성할 수 있습니다.

  생성된 답변 :

  • "알렉산드로 춘봉의 나이는 32세입니다."

RAG의 장점

*1. 비용 효율적 구현 *

• 기존의 LLM 학습 데이터 외부에 있는 데이터를 교육하기 위해 드는 계산 및 재정적 비용은 상당히 큽니다.

• RAG는 LLM에 새 데이터를 도입하기 위한 비용 효율적인 접근 방식입니다. 자체 LLM을 보유할 필요가 없어 필요한 컴퓨팅과 저장 공간이 더 적고, 모델을 미세 조정하는 데 시간과 비용을 들일 필요가 없습니다.

2. 보다 정확하고 입력에 부합한 정보 제공

• 위에서 언급했듯 기존의 LLM의 경우 훈련되지 않은 입력쿼리에 대해 부정확한 응답을 제공하는 경우가 있습니다.

• RAG는 관련 데이터 소스의 추가 참조를 근거로 하여, 모호한 문의에 더 정확하게 응답할 수 있습니다. LLM이 특정 질문에 대해 잘못된 정보 소스를 참조하는 경우 문제를 해결하고 수정할 수도 있습니다. 이를 통해 LLM을 활용한 생성형 인공 지능 기술을 보다 폭넓게 접근하고 사용할 수 있습니다.

  

3. 최신 정보 제공

• RAG는 외부 참조 데이터를 정기적으로 업데이트할 수 있으므로 모델이 가장 최근의 사실 및 관련 정보에 접근할 수 있습니다. 이렇게 하면 RAG가 생성하는 응답에는 사용자의 입력쿼리와 관련이 있는 최신 정보가 포함됩니다.

  

4. 사용자 신뢰 강화

• RAG는 외부 데이터 소스를 인용하고 답변에 소스에 대한 인용 또는 참조를 포함하여 사용자에게 제공함으로 응답을 뒷받침할 수 있습니다.

• 사용자는 추가 설명이나 세부 정보가 필요한 경우 데이터 소스 문서를 직접 찾아볼 수도 있습니다. 이를 통해 답변에 대한 사용자의 신뢰와 확신을 높일 수 있습니다.

RAG의 한계

1. 부정확한 정보의 가능성 RAG는 외부 데이터에 의존하여 동작니다. 벡터 데이터베이스에 저장된 정보, 검색된 정보가 올바르지 않으면 부정확한 결과가 나올 수 있습니다. 이를 위해 정기적으로 참조하는 외부 데이터를 업데이트 해야할 필요가 있습니다.

2. 비용적 문제 RAG에는 대규모 외부 데이터베이스를 검색하는 것이 포함됩니다. LLM에 새로운 데이터를 학습시키는 것보다 빠르고 비용적으로 효율적인 방법이지만, 여전히 컴퓨팅 측면에서 비용이 많이 들고 느립니다.

3. 사실적 정확성 기반 답변 RAG는 사실적 정확성을 기반으로 합니다. 기존의 LLM보다 상상력이 풍부하거나 허구적인 콘텐츠를 생성하는 능력은 떨어질 수 있습니다. 창의적인 콘텐츠 생성에는 사용이 제한되기 때문에 목적에 따른 사용 선택이 필요합니다.

정리

지금까지 RAG 기술의 정의, 동작 과정, 장점과 한계를 알아보았습니다. RAG 기술은 LLM의 한계를 보완해주는 창의적인 대안이고, 여러 분야에서 활용하기에 좋은 기술입니다.

하지만 최근 LLM 기술이 빠르게 발전하면서, 더 큰 컨텍스트를 처리할 수 있고 더 효율적인 LLM이 등장하고 있습니다. 이에 따라 RAG의 필요성은 점점 줄어들 것이라고 생각합니다.

참고

https://aws.amazon.com/ko/what-is/retrieval-augmented-generation/ https://www.elastic.co/kr/what-is/retrieval-augmented-generation

개요

데이터베이스(DB)는 서비스 개발에 있어 데이터를 저장, 관리하는 중요한 역할을 합니다. 이러한 DB는 다양한 기준으로 구분되며 업무 요구사항에 맞는 DB를 잘 선택해야 합니다. 오늘은 새로 시작하는 프로젝트에서 사용하게 된 MongoDB와 MySQL을 비교해보려고 합니다.

각 DB의 간단한 설명

MySQL 이란?

MySQL은 오픈소스 관계형 데이터베이스 관리 시스템입니다. 다른 관계형 데이터베이스와 마찬가지로 MySQL은 행과 열로 구성된 테이블에 데이터를 저장합니다. 사용자는 더 일반적으로 SQL이라고 하는 구조화된 쿼리 언어를 사용하여 데이터를 정의, 조작, 제어, 쿼리할 수 있습니다. MySQL은 오픈소스이므로 25년 넘게 사용자와 긴밀히 협력하여 개발한 다양한 기능이 포함되어 있습니다.

• 데이터베이스 타입 : 관계형 데이터베이스(SQL 데이터베이스)
• 데이터 저장 형식 : 행, 열로 구성된 테이블

MongoDB 란?

MongoDB는 오픈소스 비관계형 데이터베이스 관리 시스템입니다. 테이블과 행 대신 유연한 문서를 활용해 다양한 데이터 형식을 처리하고 저장합니다. 사용자가 다변량 데이터 유형을 손쉽게 저장하고 쿼리할 수 있는 탄력적인 데이터 저장 모델을 제공합니다. 이는 개발자의 데이터베이스 관리를 간소화할 뿐 아니라, 뛰어난 확장성을 갖춘 크로스 플랫폼 애플리케이션 및 서비스 환경을 구축합니다.

• 데이터베이스 타입 : 비관계형 데이터베이스(NoSQL 데이터베이스)
• 데이터 저장 형식 : BSON(Binary JSON) 형식의 컬렉션
  

MySQL vs MongoDB

MySQL은 대표적인 관계형 데이터베이스이고 MongoDB는 대표적인 비관계형 데이터베이스이기에, 두 데이터베이스의 차이점은 이런 테이터베이스 타입에 의한 차이점이 많습니다.

주요용어 대응

차이점

1 . 데이터 저장 방식

DB 설명에도 작성했듯 MySQL은 데이터를 고정된 행과 열 기반의 테이블에 저장합니다. 미리 데이터 타입, 제약조건 등의 정적스키마를 정의하고 정의에 맞게 데이터를 저장하는 것입니다.

CREATE TABLE students (
    id INT PRIMARY KEY,
    age INT,
    name VARCHAR(50)
);

INSERT INTO students (id, age, name) VALUES
(1, 20, 'Bobae'),
(2, 22, 'Momae'),
(3, 21, 'Jojae');

위는 MySQL에서 '학생' 데이터를 저장한 예시입니다. 만약 요구사항이 변경되어 학생의 '성적' 정보를 저장해야 한다면 어떻게 해야할까요? 스키마를 변경하여 'grade'컬럼을 추가해야 할 것입니다. 이처럼 유연성이 부족하여 MySQL은 요구사항이 변경될 때마다 스키마 자체를 변경해주어야 합니다. 이미 대량의 데이터가 존재하는 테이블의 스키마를 변경하게 되면 서버에 부담이 갈 수도 있을 것입니다.

MongoDB는 데이터를 BSON 형식의 컬렉션에 저장합니다. (BSON은 JSON 형식처럼 보이지만 디스크 사용량을 줄이기 위해 바이너리로 직렬화한 것.) 동적 스키마를 가지기 때문에 다양한 타입과 구조를 갖는 데이터를 저장할 수 있습니다.

{
    "_id": 1,
    "age": 20,
    "grade": "A",
    "name": "Bobae"
},
{
    "_id": 2,
    "age": 22,
    "name": "Momae"
},
{
    "_id": 3,
    "age": 21,
    "grade": "B",
    "name": "Jojae"
    "major": "Computer Science"
}

위와 같이 같은 "Students" 컬렉션이더라도 각 Document의 Field가 다양합니다. MySQL에 비해 유연성이 좋아서 특정 Document에 새로운 Field를 추가하는 것 또한 가능합니다.

2 . 중복

MySQL은 관계형 데이터베이스이기 때문에 데이터의 중복을 최소화하는 방향으로 정규화를 진행합니다.

중복이 줄어들고 일관성을 유지하기 좋다는 장점은 있지만, 이로 인해 테이블 간의 Join이 증가하게 되고 cpu사용량, 응답시간이 늘어나게 됩니다. 복잡한 Join이 Read 성능을 하락시키는 것입니다.

MongoDB는 비관계형 데이터베이스로 중복을 허용합니다. 관계형 데이터베이스처럼 외래키를 사용하지 않고, 중첩 JSON을 사용해서 데이터를 그대로 나타냅니다. (Document 생성 시 자동으로 생성되는 기본키, Object ID를 사용하기도 합니다.)

{
    "_id": 1,
    "age": 20,
    "name": "Bobae",
    "class": {
        "name": "A",
        "teacher": "Tom"
    }
},
{
    "_id": 2,
    "age": 22,
    "name": "Momae",
    "class": {
        "name": "B",
        "teacher": "John"
    }
},
{
    "_id": 3,
    "age": 21,
    "name": "Jojae",
    "class": {
        "name": "A",
        "teacher": "Tom"
    }
}

이때, 데이터 값이 변경되면 중복된 데이터들이 모두 최신 데이터를 유지할 수 있도록 업데이트, 관리해줘야 합니다. 일관성 측면에서 좀 더 신경써야한다는 것입니다.

3 . 확장성

데이터베이스에 Read, Write 요청이 증가하여 데이터베이스 서버의 확장이 필요한 경우가 생길 수 있습니다.

이때 MySQL은 Scale-Up으로 수직적 확장을 합니다. 데이터베이스 서버에 더 많은 리소스를 추가하여 성능을 향상시키는 것입니다. 이는 성능 향상에 따른 비용 증가의 폭이 큰 편이고, 하나의 서버에 부하가 집중되어 장애가 발생하면 그 영향이 크다는 단점이 있습니다.

다른 방법으로는 Replication 이 있습니다. 말 그대로 DB의 복제본을 만드는 것으로 복제본은 Read-Only(읽기전용)이 됩니다. 이는 Write 요청에 의한 부하를 해결할 수 없으며, 복제본이 원본보다 뒤쳐지는 문제가 발생할 수 있습니다.

MongoDB는 Scale-Out으로 수평적 확장을 합니다. 서버를 추가하여 기존 서버의 부하를 분담하는 방법입니다. 데이터가 여러 서버로 분산되어 Read, Write 성능을 최적화할 수 있습니다.

4 . 성능

MySQL은 여러 테이블간의 고성능 조인을 수행하도록 설계되어 많은 수의 데이터를 READ할 때 좋은 성능을 냅니다. 다만 데이터를 한 행씩 삽입하기에 Write 성능은 떨어집니다.

MongoDB는 많은 수의 데이터를 삽입하고 업데이트할 때 좋은 성능을 냅니다.

정리

두 데이터베이스는 각각의 장단점이 있고, 필요에 따라 사용해야 합니다. MySQL은 금융 시스템처럼 데이터의 일관성과 신뢰성이 중요한 경우 적합하고, MongoDB는 소셜 서비스처럼 비정형 데이터를 다룰 때, 또는 요구사항이 자주 바뀌거나 까다로울 때, 확장성이 중요한 경우 적합합니다.

두 데이터베이스 모두 널리 사용되고 있는 만큼 꼭 사용해보았으면 좋겠습니다.

참고

https://aws.amazon.com/ko/compare/the-difference-between-mongodb-vs-mysql/

https://wikidocs.net/book/4223

간단하게 핵심 내용이라고 생각한 부분만을 작성했다.

[ 1장 ]

• <1-03> 가상환경 만들기 → C:\venvs> python -m venv {가상환경 이름}

• <1-04> 쉽게 가상환경 이동하기 → “mysite.cmd” 생성

• <1-05> 장고 프로젝트 만들기(mysite) C:\projects{이름}>django-admin startproject config .

• <1-05> 인터프리터 가상환경 위치로 변경

• 서버실행 → (mysite) C:\projects\mysite>python manage.py runserver

• setting.py 에 언어설정, 시간설치 (시크릿 키 확인)

• 프로젝트 생성시 기본파일

  • manage.py: 프로젝트 관리 명령어를 실행하는 스크립트.
  • settings.py: 프로젝트 설정을 정의하는 파일.
  • urls.py: URL 패턴을 정의하는 파일.
  • wsgi.py: WSGI 호환 웹 서버를 위한 진입점 파일.
  • asgi.py: ASGI 호환 웹 서버를 위한 진입점 파일.

[ 2장 ]

<2-01>

• 앱생성 → (mysite) C:\projects\mysite>django-admin startapp {앱이름} 이건 http://localhost:8000/{앱이름} 요청시 응답

  • 앱 생성시 기본 파일
    • admin.py: Django 관리자 사이트와 관련된 설정을 정의하는 파일.
    • apps.py: 앱의 설정을 정의하는 파일.
    • models.py: 데이터베이스 모델을 정의하는 파일.
    • tests.py: 테스트 케이스를 작성하는 파일.
    • views.py: 뷰를 정의하는 파일.
    • migrations/: 데이터베이스 마이그레이션 파일을 저장하는 디렉토리.
    • 기타 초기화 파일(__init__.py 등).

• 프로젝트의 urls.py → URL과 앱의 뷰 함수간의 매핑 정의

                                     페이지 요청시 가장 먼저 호출

  즉, 1. URL 요청(웹 → 서버) / 2. urls.py 매핑확인 / 3. 매칭함수 결과(서버 → 웹)

**[urls.py]
from {앱} import views
urlpatterns = [
    path('{앱}/', views.{함수}),
]

----------------------------------
[views.py]
from django.http import HttpResponse

def index(request):
    return HttpResponse("ㅎㅇ.")

• urls.py - 프로젝트 성격 / views.py - 앱 성격 → 앱 바뀔때마다 프로젝트 파일 바꾸는 것 좋지X
• 앱 만의 URL 매핑 파일 생성 필요

[프로젝트의 urls.py]
from django.urls import path, include

urlpatterns = [
    path('{앱}/', include('{앱}.urls')), 
]
------------------------------------------
[앱의 urls.py]

from django.urls import path

from . import views

urlpatterns = [
    path('', views.{함수}),
]

• 이때 프로젝트의 urls.py 에서 {앱이름/} 매핑, 앱의 urls.py 에서 나머지 매핑되어 더해진 URL이 최종 URL

<2-02>

• 마이그레이션이란? DB데이터를 시스템에서 다른 시스템으로 이전하는 과정

• setting.py 에 데베에 관한 내용도 나오네

  우리 프로젝트의 BASE_DIR은 C:\projects\mysite

  SQLite는 소규모 프로젝트에서 사용되는 가벼운 파일 기반의 데베

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}

데이터베이스가 필요한 앱만 migrate가 필요하다.

• 모델 (테이블을 모델)

  장고 db models 를 가져와서

  각 모델을 클래스로 만들고? 이름 / 속성 작성

  여러가지 속성타입
  • https://docs.djangoproject.com/en/4.0/ref/models/fields/#field-types

• 테이블 가져오려면 프로젝트 setting.py에 앱의 apps파일을 INSTALLED APPS 로 설정해줘야 함.

INSTALLED_APPS = [
    'pybo.apps.PyboConfig',

• python manage.py migrate 하기 전에 모델 변경, 생성 시 python manage.py makemigrations 해줘야 한다.
• 장고 쉘 실행 → python manage.py shell

from pybo.models import Question, Answer - 모델 가져오기 from django.utils import timezone - 시간 라이브러리? 가져오기 테이블 데이터(튜플) 생성 q = Question(subject='', content='', create_date=timezone.now())
생성된 데이터 저장 q.save()

q.id - 값 조회 Question.objects.all() - 데이터 조회 Question.objects.filter(id=1) subject__contains='장고’ 등등 조건 확인 • https://docs.djangoproject.com/en/4.0/topics/db/queries/

• 모델에 특정 애트리뷰트 값을 데이터 조회 시 보이도록

• def* str(self): return self.subject

• 모델 수정 / 삭제 q = Question.objects.get(id=2) - 변수에 저장 q.subject = 'Django Model Question’ q.save() q.delete()

• • 외래키 존재 시 연결 객체 이용 a = Answer(question=q, content='~', create_date=timezone.now())

• *

• 연결 테이블 찾으려면* q.answer_set.all() a.question

<2-03> Admin

• 관리자 생성 → python manage.py createsuperuser http://localhost:8000/admin/ 접속
• 앱의 admin.py 파일
• 모델 등록*
• from* .models import Question admin.site.register(Question)
  
• 검색 클래스 class* QuestionAdmin(admin.ModelAdmin): search_fields = ['subject']
  
• 당연히 해당 클래스도 추가해야함* admin.site.register(Question, QuestionAdmin)
  
  

<2-04,5>

• 모델 사용 view 함수 이때 모델 값을 반환할 때는 딕셔너리 형태(아래코드의 context)로 넘겨줘야 한다.

from django.shortcuts import render, get_object_or_404

from .models import Question

def index(request):
    question_list = Question.objects.order_by('-create_date') // - 는 역순
    context = {'question_list' : question_list}
    return render(request, 'pybo/question_list.html', context)

• urls.py에서 값을 url에 주고 싶다면 <타입:변수명> → 이때 변수명은 views 함수의 인자명과 동일

urlpatterns = [
    path('', views.index, name = 'index'), -> 별칭은 view, 템플릿에서 사용
    path('<int:question_id>/', views.detail),
]

• urls.py에 네임스페이스 설정 가능 → view, 템플릿에서 사용

• 프로젝트의 urls.py path('pybo/', include('pybo.urls', namespace='pybo')),

• 앱의 urls.py app_name = 'pybo’

• 사용예시 <li><a href="{% url 'pybo:detail' question.id %}">{{ question.subject }}</a></li>

  
  
  #### <2-06>

• POST기능의 함수

def answer_create(request, question_id):
    question = get_object_or_404(Question, pk=question_id)
    question.answer_set.create(content=request.POST.get('content'), create_date=timezone.now())
    return redirect('pybo:detail', question_id=question.id)

request.POST.get('content') 이부분을 잘보면 템플릿의 post 타입 폼 답변 중 content 라는 데이터 값을 가져오는 것이다.

<2-10>

• 폼(Form) 이란?

  • 쉽게 말해 페이지 요청시 전달되는 파라미터들을 쉽게 관리하기 위해 사용하는 클래스
  • 필수 파라미터의 값이 누락되지 않았는지, 파라미터의 형식은 적절한지 등을 검증할 목적으로 사용한다.
  • (약간 모델에서 전달 부분만 가져 복제본 같은 느낌인가..?)

• 앱에 form.py 파일을 따로 만들어줘야 한다. 모델을 import하고 Meta로 필드지정

from django import forms
from pybo.models import Question

class QuestionForm(forms.ModelForm):
    class Meta:
        model = Question  # 사용할 모델
        fields = ['subject', 'content']

• view에서 해당 Form 클래스를 가져와서 사용한다. 이때도 마찬가지로 템플릿으로 넘겨줄 땐 딕셔너리 형태 이렇게 넘겨주면 템플릿에서 해당 필드의 html 코드를 자동으로 생성

from .forms import QuestionForm

def question_create(request):
    form = QuestionForm()
    return render(request, 'pybo/question_form.html', {'form': form})

• 템플릿의 form 태그는 ‘GET’, ‘POST’ 요청방식(method) 중 하나로 action URL에 요청을 보낸다.
  • 이때 action을 지정하지 않는다면? 현재 페이지로 요청을 보내게 된다.
  • 즉, 같은 view 함수에 대해 GET, POST 요청방식의 URL 요청을 받을 수 있고,
  • 요청방식에 따라 다르게 동작해야 할 수 있다.
  • (GET -처음 링크요청 / POST - 템플릿 form 의 submit)

def question_create(request):
    if request.method == 'POST':
        form = QuestionForm(request.POST)
        if form.is_valid():
            question = form.save(commit=False)
            question.create_date = timezone.now()
            question.save()
            return redirect('pybo:index')
    else:
        form = QuestionForm()
    context = {'form': form}
    return render(request, 'pybo/question_form.html', context)

• is_valid : form의 값이 유효한지 검사

• commit = False : 임시저장, 즉 DB에 저장X → form에는 전체 속성이 있는 것이 아니기 때

• Form의 위젯(부트스트랩 사용) / 레이블(속성 이름 설정) 도 있다. 필요할 때 코드를 찾아보기.

🪱 여기까지가 장고 기초 : 🪱

🪱 개념적으로 헷갈리는 부분이 많았다.🪱