당장 주말에 정보처리기사 실기가 있기도 했고, 코테 준비, 프로젝트 준비, 공모전 등 ..
공모전은 내가 벌인 일이지만 (왜 그랬니.)
할 일이 많은데 할 일은 계속 늘어나고 그 중 50%도 제대로 하는 게 없다는 생각에 슬쩍 번아웃 기운이 올라왔다.
하지만 이럴 때일수록 더 중요한 게 나 자신 가스라이팅(?)
아무튼 할 수 있다!!! 아무튼 ... 아무튼..
71일차
날짜 : 2025-04-13
오전에는 치료를 받고 왔다. 2-3회차부터 효과가 있을 거라고 하시더니 진짜 효과가 나타나고 있다.
신기하다
Four F’s of Active Reviewing
Facts : 저번 주 금요일에 클론해 둔 레포의 django_exam03 브랜치에서 작업을 이어서 나갔다. uv로 가상환경 세팅, Django와 gunicorn을 선치한 뒤 gunicorn을 8005 포트에 바인딩해서 앱이 정상 작동하는 것을 확인했다. Nginx를 설치하고 8081포트에서 Nginx -> Gunicorn 리버스 프록시 구조도 완성했다. 오후에 Question, Choice 모델을 작성하고 migration 및 superuser 생성을 진행했으며, MySQL DB를 연결하고 CSRF 설정을 추가했다. views.py, setting.py, urls.py를 설정해가면서 전반적인 백엔드 -> 프론트 반영 과정을 배울 수 있었다.
$
Feelings : gunicorn과 Nginx가 실제로 연결되어 화면이 뜨는 걸 확인하는 게 재밌었다. 배포 구조가 감이 안 잡혔었는데, 실제 포트 흐름으로 배우니까 좀 더 익숙해진 것 같다.
실시간으로 답변이 들어간다..!
Findings :
- Web Server : 웹 브라우저(크롬, 엣지, ... 등) 같은 클라이언트로부터 HTTP 요청을 받고 웹페이지(HTML문서)를 반환하는 컴퓨터 프로그램 - WAS(Web Application Server) : 웹서버에서 요청을 받으면 서버에 로직을 실행하여 다시 웹서버로 반환해주는 소프트웨어
WAS, WSGI/ASGI, Gunicorn의 차이
WSGI(Web Server Gateway Interface)
- gunicorn은 Python WSGI(Web Server Gateway Interface) 애플리케이션 서버로 동기적인 방식으로 작동함. 요청이 처리될 때까지 블록되어 한 요청이 처리된 후에 다음 요청을 처리한다. worker 프로세스를 여러 개 띄워서 동시에 여러 요청을 처리할 수도 있음 (예. --workers 3). 단일 worker 기준으로는 동기적이지만, worker가 여러 개면 병렬 처리가 됨 -> Django, Flask 프레임워크에서 사용 - Django도 기본적으로 WSGI 기반이고 gunicorn 배포가 일반적임
ASGI(Asynchronous Server Gateway Interface)
- cf. ASGI(Asynchronous Server Gateway Interface)는 비동기적으로 동작함. 여러 요청을 동시에 처리 가능해서 실시간 기능이 필요한 어플리케이션에 더 적합하다. 웹 소켓을 비롯하여 실시간 기능, 이벤트 기능을 지원해 실시간 채팅 같은 앱에 유용함 -> Django(uvicorn이나 daphne같은 ASGI 서버 별도로 사용), FastAPI 같은 프레임워크에서 비동기적으로 동작하는 앱 지원할 때 사용 - Nginx는 앞단에서 클라이언트 요청을 받아 gunicorn으로 전달하는 리버스 프록시 역할을 함 - 정적 파일은 Django를 거치지 않고 Nginx가 직접 서빙한다 - `collectstatic`은 여러 앱에 분산된 정적 파일을 STATIC_ROOT 경로 하나로 모아주는 명령으로, Nginx의 alias 지시자가 해당 경로를 바라보게 된다. Linux 서버에서 Nginx가 www-data 계정으로 실행되기 때문에 정적 파일 디렉터리 소유자는 www-data로 변경해줘야 하고, Mac에서는 Nginx가 본인 계정으로 실행되므로 chmod 755만으로 충분함 - CSRF 설정에서 CSRF_TRUSTED_ORIGINS에 실제 접속 도메인을 명시해야하는 이유는 Nginx를 거쳐 들어오는 요청의 Origin이 Django가 기대하는 값과 달라질 수 있기 때문임
Future : 우분투에서 동일한 구조 재현하는 연습하기. WAS, WSGI, ASGI, gunicorn은 개념 다시 정리해서 포스팅하기!
72일차
날짜: 2025-04-14
Four F’s of Active Reviewing
Facts: 전날 구축한 Nginx-Gunicorn-Django 구조 위에서 기능을 이어붙였음. SSH 터널을 열어서 강사님 MySQL DB에 접속해서 데이터가 잘 들어가는 것을 확인함. Django 템플릿 엔진으로 질문 목록과 상세 페이지를 구현했음. <int:question_id>/와 detail 뷰를 연결했고, get_object_or_404로 존재하지 않는 질문 접근을 처리했다. 이후 choice_create와 vote 뷰를 추가해 선택지 등록과 투표 기능까지 완성하고, Bootstrap 카드 레이아웃으로 UI도 붙였다. 게시판을 Docker로 연동하는 작업을 시작했고, channels와 daphne를 설치해 WebSocket 연동 준비를 시작했다. WebSocket의 핸드셰이크 방식도 간단히 개념을 배웠다.
Feelings: 전날 배운 구조 위에 CRUD 기능이 하나씩 붙어가는 게 재밌었다. 결국 이 모든 것들을 Docker 컨테이너로 프론트, 백엔드를 나눠서 구축할 수 있다는 걸 계속 상기시켜주셔서 좋았다.
Findings:
오늘 배운 내용 흐름
- Django 템플릿 언어는 Jinja2 문법을 기반으로 함. - {{ 변수 }}로 값을 출력하고 {% %} 태그로 조건문, 반복문을 처리함 - get_object_or_404는 DB조회 실패 시 자동으로 404 응답을 반환해주는 Django 단축 함수로 뷰 코드를 간결하게 유지하도록 해줌
역참조 구조
- choice_set은 Django ORM의 역참조 기능으로 ForeignKey로 연결된 Choice 객체들을 Question 인스턴스에서 바로 조회할 수 있게 해줌 - ORM(Object-Ralational Mapping)은 파이썬 객체와 DB 테이블을 연결해주는 계층 SQL을 안 써도 파이썬 코드로 DB를 조작할 수 있게 해줌
# SQL 직접 쓰는 방식
SELECT * FROM encore_question WHERE id = 1;
# Django ORM 방식
Question.objects.get(pk=1)
- app_name과 name 파라미터 설정시 {% url 'encore:vote' choice.id %} 형식의 네임스페이스 URL을 템플릿에서 사용할 수 있음 -> URL 하드코딩 방지 - daphne는 Django 채널의 공식 ASGI 서버임 -> HTTP와 웹소켓을 모두 처리할 수 있음 - 웹소켓은 최초 연결 시 HTTP 핸드셰이크로 시작해 프로토콜을 업그레이드 하는 방식으로 동작함
Future: Docker와 Django 채널, 웹소켓 연동하기
73일차
날짜: 2025-04-15
백준 서버가 곧 종료한다는 소식을 듣고 크롤링을 결심한 날..
배운 내용은 알차게 써먹는 편 ~
트래픽 문제 안 생기게 텀을 좀 길게 설정해뒀더니 느려서 nohub으로 백에서 돌아갈 수 있도록 3분할해서 병렬로 돌려줬다 👍
그리고 이 날 특강을 들었는데, 지금까지 들은 특강 중에 가장 알찼다.
AI 동향이나 앞으로 어떤 것들을 준비해야할지 궁금했던 부분에 대한 답을 들을 수 있었고, 프로젝트 아키텍처나 기술적인 부분도 꼼꼼히 피드백 해주실 것 같은 강사님이셨어서 최종 플젝 멘토님이 되어주셨으면 ... 하는 바람도 생겼다!
Four F’s of Active Reviewing
Facts: Django ORM 실습 진행 - models.py에 skn25, Student 모델을 작성하고 class Meta로 테이블명, 컬럼명 커스터마이징 - django-extensions와 ipython을 설치해 shell_plus에서 ORM CRUD를 직접 구현해보았음 - production과 test server를 분리해서 구현을 한 뒤 production DB에 연결해 데이터 입력, 댓글, 투표, 기능 작동을 확인함
그 와중에 스낵님 아이디로 다수의 아이스크림이 들어가 있어서 웃겼다 ㅋㅋㅋㅋ 얼마나 많이 드시려고!
Findings: - Django models.py의 class Meta는 테이블명(db_table), 정렬 기준(ordering), 복합 유니크 제약(unique_together) 등 DB 수준의 옵션을 선언적으로 지정하는 내부 클래스임 - filter()는 조건에 맞는 QuerySet을 반환하고, get()은 단일 객체만 반환함 - QuerySet 상태에서 수정은 update()로, 단일 객체 수정/저장은 .save()로 처리함 - auto_now_add는 생성 시점에만 타임스탬프를 기록하고, auto_now는 save() 호출 시마다 갱신됨 => 그래서 QuerySet.update()로 수정 시 auto_now 필드가 갱신되지 않음 - setting.py를 base, development, production으로 분리하면 환경별 DB와 DEBUG 설정을 독립적으로 관리할 수 있음
Future: DRF Serializer 개념 정리하기
74일차
날짜: 2025-04-16
정처기 벼락치기 + 복습 + 코테 공부 + 역량검사 등 다양한 이유로
월 - 수 수면 시간이 약 4시간 정도였더니, 집중도가 좋지 못했던 하루.
잠은 정말 중요하다.
하루 요약 :
게시판에 등록할 수 있는 글
Four F’s of Active Reviewing
Facts: FBV와 CBV 개념을 정리하고 FBV 방식으로 Post 모델 기반의 블로그 CRUD를 구현함. models.py, forms.py, views.py, urls.py, 템플릿 작성 -> localhost:8001/blog/에서 글 목록, 등록이 정상 작동하는 것을 확인함
Feelings: 전날까지 배운 ORM, 템플릿, URL 라우팅이 FBV 구조 안에서 하나로 엮여서 전체 그림을 한 번에 이해할 수 있어서 좋았다. CBV는 클래스로 구현해서 더 깔끔한 거 같으면서도 FBV에 비해 낯설어서 더 공부해봐야 할 거 같다.
Findings: - FBV는 함수 하나에 요청 처리 로직을 직접 작성하는 방식으로, 흐름이 선형적이라 읽기 쉽고 예외 처리가 많은 경우에 유리하다. - CBV는 클래스 상속과 믹스인으로 코드를 재사용하는 구조로, ListView, DetailView, CreateView 같은 제네릭 뷰가 CRUD 보일러플레이트를 자동으로 처리해준다. - forms.ModelForm은 모델과 연결된 폼을 자동 생성하고, form.is_valid()로 유효성 검사 후 form.save()로 DB에 바로 저장할 수 있다. - Django 템플릿의 {% extends %}와 {% block %}은 공통 레이아웃을 base.html에 두고 각 페이지가 상속받아 필요한 부분만 채우는 구조로, 중복 HTML을 줄여준다.
Future: FBV, CBV 코드 비교
75일차
날짜: 2025-04-17
정처기 시험 준비로 쉬어갑니다 ~
📖 주말 복습
- 정처기 시험 보고 나서 현타가 와서 토요일은 쉬었다 ㅇ<-< ''.join() 문제 틀린 게 너무 충격적이었다.. 다음 시험은 준비하면서 자료구조부터 체계적으로 좀 더 배우고 시험에 임하고 싶다.
- 일요일엔 미뤄뒀던 3차 프로젝트 디벨롭을 진행했다. vision 모델로 pdf를 text 문자 그대로 읽어오는 전처리를 진행했다. gpt-4-mini 모델을 사용했는데, 그래도 오타가 있어서 모델을 올려서 성능을 올려야할지 아니면 후처리를 해야할지 고민 중에 있다. 다음 주에 고민해봐야지~
댓글