[SKN FAMILY AI CAMP]/주간

🐉 SKN FAMILY AI CAMP 13기 16주차 후기 (2025.07.07 ~2025.07.11)

ki-june 2025. 7. 11. 10:38

 

📍 간단 후기

 

 

🏷️ 수업

Django 수업을 시작했다. 프로젝트를 만들 때의 구조와 views.py, urls.py, templates 파일 등이 어떤 관계가 있고 어떻게 관리하면 효율적 일지에 대한 수업을 진행했다. Django 수업도 css와 js의 연장선으로 많은 태그들의 기능을 활용해 봤다. 또 저번주에 배운 bootstrap을 Django에 적용시켜 보는 연장선도 경험할 수 있었다.

대체적으로 Django UI 설정에 대한 전반적인 수업을 진행했다.

 

 

 

🏷️ 코딩테스트 스터디

약 3주만에 진행한 코테스터디이다. 이번 주차는 DFS/BFS관련 문제들과 스택/큐 관련 문제들로 해서 총 7문제를 풀어왔다. 이번에는  기존에 사용하던 프로그래머스와 Leetcode라는 사이트를 이용해서 스터디의 다양성을 넓혔다. 다들 전공자라 그런지 몰라도 잘 풀어와서 풀이할 문제들은 많이 없었다. 우리 팀 목적 자체가 '풀어보면서 개념 정리하기' 이기 때문에 각자 코드 리뷰에만 중점을 두었다.

 

 

https://leetcode.com/problemset/

 

 

 

 

 

🏷️ 공모전

산업통산자원부에서 주최하는 공모전에 지원하려고 한다. 저번 공모전에 떨어진 만큼 더 만반의 준비를 해야 될 것 같아서 기획서 초안을 엄청 구체적으로 작성했다. 실현 가능성을 제대로 보여주려면, 디자인이나 데이터 분석이 중요하다고 느꼈다.

이번 공모전에서는 AI 기술을 제대로 구현하기 위해 최근 자료 및 기술들을 많이 찾아봤다. 그래서 그런지 준비 기간에도 많은 것을 배울 수 있었다.

 

 


 

 

📍 좋았던 점

 

  • Model 클래스를 이용한 CRUD

 

필드 타입 별 다양한 조건을 사용할 때에는 '_'를 2개 붙여 '__'로 사용한다.

 

 

 

 

filter와 exclude는 SELECT의 WHERE 조건을 지정한다. 반면 OR 조건의 경우 Q() 함수(django.db.models.Q)를 사용한다.

 

 

  • 테이블 간의 관계

 

 

 

자식 모델에서 부모 모델 조회 : Choice객체.question

부모 모델에서 자식 모델 조회 : Question객체.choice_set

 

 

reverse_name 이름 충돌 문제

 

하나의 모델을 여러 모델이 참조하는 경우 발생하는 것이 바로 reverse_name 충돌 문제이다. 이름이 충돌날 경우 makemigrations 시 오류가 발생한다.

 

***ORM을 사용하지 않고 SQL문 사용할 때는 모델. objects.raw(‘sql문‘)으로

 

 

  • View

 

View는 사용자의 요청을 처리하여 응답하는 작업을 한다. 이는 views.py에서 작업을 진행한다. 어떤 url이냐에 따라 어떤 view가 보일지 mapping 하는 작업이 주된 업무이다.

 

View 구현 방법은 2가지로 나뉜다.

  • 함수 기반 View : 각 기능을 함수 별로 구현 / 요청에 따른 처리 구현을 직접 다 해야 함
    • 함수 구문 : def 함수이름(request [, path파라미터 변수]) : 처리내용 구현
  • 클래스 기반 View : 역할별로 그 기능을 미리 구현한 View를 상속받아 클래스로 구현함

특징만 봐도 알 수 있듯이, 클래스 기반 View를 많이 사용할 것이다.

 

*** redirect() : HTTP 요청 처리 후 클라이언트를 다른 URL로 리디렉션(재요청) 하도록 지시하는 Django의 단축 함수(shortcut)

 

*** render() : template을 실행해서 그 결과로 HttpRequest를 반환

 

 

 

  • template

 

template: 사용자에게 응답할 화면을 구현한 컴포넌트 / HTML 기반으로 작성하며 Template문법을 이용해 동적 처리코드를 HTML 중간중간에 작성한다. / 출력: {{변수}}

template 엔진: Django template 스크립트를 해석하여 사용자에게 응답할 최종 HTML 생성(Rendering) / View에서 전달된 데이터들을 이용해 사용자에게 응답할 화면을 동적으로 생성

 

***HTML과 Template은 별개!!!

 

Django는 app/templates 형태로 곧바로 인식(자동으로 찾음) 하기 때문에 app1/templates/app1/create.html의 형식으로 구조를 정리한다. 이는 구분하기 쉽게 정리하는 방법 중 하나이다. 이렇게 쉽게 정리하기 위해서는 settings.py의 TEMPLATES 내 DIRS를 [BASE_DIR/"templates"]로 설정해야 한다.

 

주석 종류는 다음과 같다.

  • {# 내용 #} : 장고에서 한 줄 주석
  • {% comment %} 내용 {% endcomment %} : 장고에서 template block 주석
  • <!-- 내용 --> : html에서 주석

+++주석은 항상 세세하게 적어두자!+++

 

template에서의 필터 = 함수

변수와 필터를 "|"를 사용해 연결한다. -> {{변수 | 필터}} / {{변수 | 필터:argument}}

 

 

extends 활용 예시

 

extends를 통해 block 단위를 상속받을 수 있다. 다른 html 파일을 extends를 사용하여 공통부분은 그대로 사용하되 변경되는 영역만 재정의 해서 템플릿을 만들어 사용할 수 있다. 위 이미지와 같이 block의 시작과 끝을 지정해 주어 기존에 사용하던 내용은 유지할 수 있다.

 

 

  • Paging

Paging 예시

 

Paginator 모듈을 통해 몇 개로 paging 할지 나눌 수 있다.

 


 

 

📍 부족한 점

 

 

  • Django - 사용자 관리

 

Django 회원가입 화면 구현 예시

 

 

ModelForm: 가입 / 수정 / 탈퇴 / 조회 중 가입과 수정 시 사용

  •  UserCreationForm : 가입 / Username과 Password를 등록
  •  UserChangeForm : 정보 수정
  •  PasswordChangeForm : Password 변경 / 보안을 위해 암호화하여 저장되기 때문에 패스워드 변경은  정보 수정과 다른 process로 진행한다.

 

Generic View: 재사용 가능한 클래스 기반의 View

  •  CreateView : 가입
  •  UpdateView : 수정
  •  DetailView : 정보 조회
  •  DeleteView : 탈퇴
  •  PasswordChangeView : Password 변경

 

User 모델 확장의 4가지 방법

  • AbstractUser: 기본 사용자 모델을 상속받아 새로운 필드들을 추가한다.
  • AbstractBaseUser: 기본 사용자 모델을 사용하지 않고 새로운 User 모델을 정의한다.(필드들과 기능들을 모두 새로 정의)
  • OneToOne: 기본 User모델과 1:1로 연결되는 자식 모델(테이블)을 만들어 새 필드들을 추가
  • Proxy: User 모델의 스키마는 그대로 사용하고 기능을 변경/추가

 

  • Django 전체 Directory 구조

 

myproject/ ← 프로젝트 루트 디렉토리
├── manage.py ← Django 프로젝트 실행 및 관리 명령어 진입점
├── myproject/ ← 프로젝트 설정 디렉토리 (settings.py 포함)
│ ├── init.py
│ ├── asgi.py ← 비동기 서버 게이트웨이 설정
│ ├── settings.py ← 프로젝트 전체 설정 파일
│ ├── urls.py ← 프로젝트 전역 URL 라우팅
│ └── wsgi.py ← 웹서버 게이트웨이 설정
├── myapp/ ← 앱 디렉토리 (앱 이름은 자유롭게 지정 가능)
│ ├── init.py
│ ├── admin.py ← Django 관리자(admin) 인터페이스 설정
│ ├── apps.py ← 앱 설정 클래스
│ ├── migrations/ ← 마이그레이션 파일 저장 폴더
│ │ └── init.py
│ ├── models.py ← 데이터베이스 모델 정의
│ ├── tests.py ← 테스트 코드
│ ├── views.py ← 뷰 로직 정의
│ ├── urls.py ← 앱 내 URL 라우팅 (수동 생성 필요)
│ └── forms.py ← 폼 정의 (선택적 생성)
├── templates/ ← HTML 템플릿 저장 폴더 (전역 또는 앱별로 관리)
│ └── ...
├── static/ ← 정적 파일(css, js 등) 저장 폴더
│ └── ...
└── db.sqlite3 ← 기본 SQLite DB (다른 DB 사용 시 변경됨)

 

 

기본적으로 settings.py에 app 이름 자체를 추가해주어야 한다.(Installed_Apps에 추가) 그리고 활용할 함수들은 views.py에 저장해 두고, urls.py의 path함수를 통해 연동시켜 준다. 클래스를 정의하고 싶으면 새로운 python 파일을 생성해 추가한 후 사용한다.

몇 줄 안 되지만, 잠깐 설명만 하더라도 많은 파일들을 이동해야 한다. 시각화를 위해 html 파일도 관리해야 하므로 이번 Django 수업을 들으며 가장 크게 느낀 점은 '디렉토리 구조의 이해'이다. 구조를 이해하지 못하고 Django 앱을 만드려 한다면, 무한 Error에 빠지게 된 자신을 보게 될 것이다. Django를 시작하는 분들은 어느 폴더에 어느 파일이 있는지 머릿속에 꼭 넣어두고 Django 앱을 만들기 바란다.

 


 

 

📍 성찰 및 마무리

 

 

이번 주는 잠을 줄인 한 주라고 정리한다. 운동, 공모전, 프로젝트, 코테 스터디, 수업을 전체적으로 아우르다 보니 잠을 줄여야 시간을 더 잘 쓰게 될 것이라 생각했다. 열심히 움직인 만큼 뿌듯함도 있었다.

 

기대했던 Django 수업은 대체적으로 UI 수업이 많아서 아쉬운 부분도 있었다. 무한 태깅... 그 자체였다. 그래도 기능 추가하는 방법 등 얻은 점도 많다. 위에서도 말했지만, '디렉토리 구조의 이해'이다. 대학교에서 프로젝트를 진행할 때는, 뭔지도 모르고 그냥 무작정 시작하려다 보니 에러가 하도 많이 떠서 결국 Flask API를 썼던 기억이 있다(그놈의 404....!!). 많은 오류를 겪어보고 잘 쓰는 방법은 무엇인지 깨달아서 뿌듯한 배움이라고 생각한다.

 

공모전에 힘을 많이 준 것 같다. 저번 공모전에서는 어떻게 써야 할지, 분량에 맞춰 작성은 어떻게 해야 할지 배운 느낌이라면, 이번에는 확실하게 보여줘야겠다는 생각밖에 안 들었다. 약간 오기? 가 생긴 것 같다. 아이디어가 가장 중요하다고 생각한다. 그렇지만 그를 실현하기 위한 계획이 가장 중요하다는 점을 기획안에서 제대로 보여줘야 한다는 것을 깨달았다. 또 이번 AI 관련 공모전 기획안을 쓰다 보니, 최근 기술 동향 및 어떻게 활용하면 좋을지 판단하는 것에서 많은 것을 알게 됐고, 재밌게 느껴졌다. 열심히 한 만큼, 좋은 결과가 있길 바란다.