찬스맨의 프로그래밍 스토리

이력서 초안

Chansman — Mon, 25 Aug 2025 15:20:56 +0900

이력서 수정안 (강사님 feedback 요함)

Chansman — Mon, 25 Aug 2025 15:09:21 +0900

Profile

한국과 뉴질랜드에서 영업·운영·서비스 등 다양한 업무를 경험하며, 문제를 구조화하고 협업으로 해결하는 방식을 체득해 왔습니다.

AI 기술이 빠르게 발전하면서 개발에 대한 진입 장벽이 낮아지고, 나도 직접 무언가를 만들어 볼 수 있겠다는 확신이 생겼습니다.
이를 계기로 백엔드 개발자로 전향해, 실제 데이터를 수집·처리·제공하는 서비스를 구현해보며 역량을 키우고 있습니다.

귀국 후 국가지원 부트캠프 ‘오즈코딩스쿨’에서 Django와 FastAPI 기반의 API 개발, 자동화 스케줄링, 크롤링, 배포까지 아우르는 백엔드 실습을 수행하며 개인·팀 프로젝트를 완주했습니다. 4번의 팀프로젝트의경우 3번의 팀장을 맡았으며 1번은 개인프로젝트로 진행하였습니다. 팀프로젝트의 경우 팀원들과의 소통 스케쥴링 이탈자가 발생하지않게 관리하였으며 개인프로젝트를 통하여 백앤드의 전체흐름을 이해하는데 주력하였습니다.

학습에 관한 내용정리 및 학습 중 마주한 에러와 트러블슈팅 과정을 정리해 공유하기 위해 기술 블로그를 운영 중입니다.
https://chansman.tistory.com/

찬스맨의 프로그래밍 스토리

안녕하세요! 코딩을 시작한 지 얼마 되지 않은 초보 개발자 찬스맨입니다. 이 블로그는 제 학습 기록을 남기고, 다양한 코딩 실습을 통해 성장하는 과정을 공유하려고 합니다. 초보자의 눈높이

chansman.tistory.com

githudb 의 경우 아래와같이 관리되고있습니다.

https://github.com/rainsos

Project Experience

블로기는 오즈코딩스쿨에서 팀 프로젝트로 2인으로 진행하였고, 백엔드에서 프론트까지 실제로 모두 구현해보았던 사례입니다.
실제로 배포를 진행하였고 7일간의 블로그 운영을 통해 수익화를 이루어냈으며, AI 콘텐츠 자동화 서비스를 목표로 직접 기획해 진행한 프로젝트입니다.
Django와 FastAPI를 역할별로 분리하고, 스크래핑 → 생성 → 검수 → 게시까지의 전체 백엔드 파이프라인을 구축했습니다.

https://blogi.store/

역할 구조

Django (B): 사용자 인증, 관심 키워드 관리, 키워드 클릭 로그, 생성 콘텐츠 저장 및 관리자 기능 전담
FastAPI (A): 기사 수집(Playwright), 이미지 수집(Kakao API), HyperCLOVA X 연동, 내부 API 통한 결과 반환
공통: PostgreSQL, Redis, Docker, NCP 서버, Github Actions 기반 배포 및 모니터링

주요 구현 기능

Django: 공개/관리/내부 API로 모듈 분리, 관리자 대시보드와 사용자 결과 UI 제공
FastAPI: 키워드 기준 기사 본문 스크래핑, 이미지 수집, AI 글 생성, 프리뷰·PDF·복사 기능 지원
Playwright: 키워드 기반 뉴스/블로그 본문 스크래핑, 네이버 API 백업 로직 탑재
HyperCLOVA: 프롬프트 구성 및 생성 요청 전송, 실패 로그/리트라이 핸들링 구현
배포: Docker Compose + Nginx + Gunicorn으로 NCP 배포

문제 발생 및 해결 사례 — Playwright CPU/메모리 폭주

문제 요약
기사 수집 과정에서 Playwright가 다수의 Chromium 프로세스를 동시에 생성하면서, 일부 프로세스가 종료되지 않고 좀비 상태로 남아 메모리 누수 및 CPU 100% 점유가 반복됨.

평균 메모리 사용량: 4.3GiB 이상
CPU 점유율: 최대 101%
크래시 발생: 1회/4회 실행 중 발생
컨테이너 장애 → 결과 생성 실패율 상승(약 30%)

해결 방안

Playwright 실행 구조 변경: 브라우저 1개 + 컨텍스트 풀 방식으로 일원화
세마포어(최대 동시 실행 2~4개) 적용 → 동시 생성 수 제한
n건마다 브라우저 재기동 → 세션 누적 방지
모든 실행에 try/finally close() 강제 적용 → 좀비 프로세스 완전 제거
docker-compose.yml에 메모리 상한(6GiB) 설정 추가

결과 수치

CPU 점유율 최대 101% → 56%로 감소 (-45%)
메모리 사용량 4.3GiB → 평균 2.1GiB로 절반 이하
좀비 프로세스 발생 0건, 타임아웃·크래시 7일간 0건
실패율 30% → 0%로 안정화, 기사 수집 성공률 100% 유지

Django/DRF pk vs id 파라미터 불일치로 인한 500 오류 — 원인과 해결

Chansman — Mon, 18 Aug 2025 21:06:31 +0900

Django/DRF pk vs id 파라미터 불일치로 인한 500 오류 — 원인과 해결

프론트 저장(복사) 버튼 클릭 시 500 발생 → 원인: URL 파라미터명(pk)과 뷰 시그니처(id) 불일치.

TL;DR

증상: 프론트에서 AxiosError: 500, 백엔드에서 TypeError: PostCopyAPIView.post() got an unexpected keyword argument 'pk'.
원인: urls.py에서 posts/<int:pk>/copy/로 등록 → resolver가 {'pk': 376}을 전달. 그러나 뷰는 def post(self, request, id)만 받음 → 이름 불일치(TypeError)로 500.
해결:
1. URL 통일: posts/<int:id>/copy/로 되돌림.
2. 방어 패치(선택): 뷰에서 id/pk 모두 수용(kwargs).
검증: resolve/inspect로 최종 매칭 파라미터와 로딩된 시그니처 확인.
재발 방지: 파라미터명 일관 가이드, 단위 테스트/CI 가드, 중복 경로 제거, 캐시/오토리로드 주의.

배경 & 환경

프론트: 저장(=복사) 버튼 클릭 시 백엔드 /api/posts/<post_id>/copy/ 호출.
백엔드: Django/DRF, 함수/클래스 혼용. 일부 경로에서 <int:id>/<int:pk>가 혼재.
관찰 로그(요약):
- 초기 401(비로그인 상태의 POST) → 로그인 후 재호출은 200.
- 복사 시도 시 500: TypeError: ... unexpected keyword argument 'pk'.

에러 로그 스냅샷

AxiosError: Request failed with status code 500
...
TypeError: PostCopyAPIView.post() got an unexpected keyword argument 'pk'

Django resolve 결과(로컬/배포 동일):

resolve('/api/posts/376/copy/').kwargs == {'pk': 376}

실행 중 뷰 시그니처(초기 상태):

PostCopyAPIView.post -> (self, request, id)

원인 분석 (한 줄 요약)

URL은 pk 라벨로 값을 전달 ({'pk': 376})
뷰는 id 라벨만 받도록 구현 (def post(..., id))
파라미터 이름 불일치로 Python이 unexpected keyword argument 'pk' 예외 발생 → DRF에서 500으로 응답.

참고: <int:...>에서 int는 타입이고, 진짜 중요한 건 **라벨 이름(pk/id)**입니다.

재현 절차

urls.py에 다음 경로가 존재:
path("posts/<int:pk>/copy/", PostCopyAPIView.as_view(), name="post-copy")
뷰 시그니처가 다음과 같음:
def post(self, request, id): ...
/api/posts/376/copy/ 호출 시 resolver가 {'pk': 376} 전달 → 뷰는 id만 받음 → TypeError.

해결 전략

A) URL 통일(권장)

urls.py 수정:

- path("posts/<int:pk>/copy/", PostCopyAPIView.as_view(), name="post-copy"),
+ path("posts/<int:id>/copy/", PostCopyAPIView.as_view(), name="post-copy"),

B) 뷰 방어 패치(선택, 환경 무관 안정성)

class PostCopyAPIView(APIView):
    permission_classes = [IsUser]
    serializer_class = CopyLogSerializer

    def post(self, request, *args, **kwargs):
        post_id = kwargs.get("id") or kwargs.get("pk") \
                  or request.data.get("id") or request.query_params.get("id")
        try:
            post_id = int(post_id)
        except (TypeError, ValueError):
            return Response({"detail": "post id missing"}, status=400)

        user = request.user
        post = get_object_or_404(GeneratedPost, id=post_id)

        # 1회만 복사 로그 생성 (중복 방지하려면 get_or_create 권장)
        copy_log = CopyLog.objects.create(user=user, post=post)

        # DB 레벨에서 copy_count +1
        GeneratedPost.objects.filter(id=post.id).update(copy_count=F("copy_count") + 1)

        # 필요 시 serializer.data 반환 가능
        return Response({"message": "복사 기록이 저장되었습니다."}, status=200)

실무 팁: 팀원이 다시 pk로 바꿔도 안 터지도록, 방어 패치는 유지해도 좋습니다.

적용 코드(최종 상태)

urls.py
path("posts/<int:id>/copy/", PostCopyAPIView.as_view(), name="post-copy"),
views.py (방어형 그대로 유지)
def post(self, request, *args, **kwargs): post_id = kwargs.get("id") or kwargs.get("pk") \ or request.data.get("id") or request.query_params.get("id") ...

검증 방법

파라미터 매칭 확인

python manage.py shell -c "from django.urls import resolve; print(resolve('/api/posts/376/copy/').kwargs)"
# 기대: {'id': 376}

실행 중 시그니처/소스 확인

python manage.py shell -c "import inspect; from django.urls import resolve; VC=resolve('/api/posts/376/copy/').func.view_class; print(inspect.getfile(VC)); print(inspect.signature(VC.post))"
# 기대: (self, request, *args, **kwargs)

캐시 정리 & 완전 재기동(필수)

find . -name "__pycache__" -type d -exec rm -rf {} +
find . -name "*.pyc" -delete
# runserver 재시작 또는 컨테이너 재기동

엔드포인트 호출 체크(로그인 필요)

# 예: curl -H "Authorization: Bearer <token>" -X POST http://localhost:8000/api/posts/376/copy/

왜 어떤 때는 서버에서 안 터졌나? (FAQ)

URL 중복/등록 순서: 동일 패턴이 id/pk 두 버전으로 정의되어 있거나, DRF Router 포함 순서에 따라 먼저 매칭되는 쪽이 달라질 수 있음.
캐시/오토리로드: 개발 서버/컨테이너가 이전 아티팩트를 들고 있어 일시적으로 다른 경로가 적용된 상태였을 가능성.
결론: 구조적으로 잠복 버그였고, 이번에 URL 통일 + 방어 패치로 영구 해소.

재발 방지 체크리스트

urls.py 전체에서 파라미터명 일관성 유지 (<int:id> 권장)
DRF Router(detail=True) 사용 시, 뷰에서 *args, **kwargs 패턴으로 수용 후 내부에서 pk/id 정규화
중복 경로 제거 (같은 URL 패턴이 2번 등록되지 않도록)
단위 테스트 추가
from django.urls import resolve def test_post_copy_uses_id_kwarg(): match = resolve('/api/posts/123/copy/') assert match.kwargs.get('id') == 123
CI 가드(선택):
# pk 버전 사용 금지 가드 예시 grep -R "posts/<int:pk>/copy/" -n django_app && { echo "Do not use pk for copy URL"; exit 1; } || true
코드 주석으로 팀 합의 명시: "게시글 라우트 파라미터는 id로 통일"

부록: 관련 커맨드 모음

# 현재 매칭 파라미터 확인
python manage.py shell -c "from django.urls import resolve; print(resolve('/api/posts/376/copy/').kwargs)"

# 실행 중 시그니처/소스 경로 확인
python manage.py shell -c "import inspect; from django.urls import resolve; VC=resolve('/api/posts/376/copy/').func.view_class; print(inspect.getfile(VC)); print(inspect.signature(VC.post))"

# 중복 클래스 탐색
grep -R "class PostCopyAPIView" -n django_app/apps

# 중복 경로 탐색
grep -R "posts/<int:" -n django_app/apps | grep "/copy"

# 캐시 삭제
find . -name "__pycache__" -type d -exec rm -rf {} +
find . -name "*.pyc" -delete

마무리

이번 이슈는 파라미터 이름 불일치라는 작지만 치명적인 설정 차이에서 시작됐습니다.
URL 통일 + 방어 패치 + 검증/가드 절차로 동일 유형의 문제를 확실하게 차단할 수 있습니다. 팀 규칙에 “게시글 라우트 파라미터는 id로 통일”을 명문화해 주세요.

NCP 서버 모니터링 안됨 현상

Chansman — Mon, 18 Aug 2025 16:34:18 +0900

NCP 서버 모니터링 안됨 현상

1. 문제 상황

서버를 강제 종료 후 다시 켜니, NCP Cloud Insight 대시보드에서 CPU/메모리 사용량이 표시되지 않는 문제가 발생했습니다.
콘솔에는 아무런 오류 메시지가 없었지만, 지표가 갱신되지 않아 원인 파악이 필요했습니다.

2. 원인 추측

NCP 고객센터 답변에 따르면, 서버 모니터링 지표는 Cloud Insight Agent가 동작해야 수집됩니다.
강제 종료 과정에서 이 Agent 프로세스가 비정상 종료되었을 가능성이 크다는 안내를 받았습니다.

3. 확인 과정

SSH로 서버 접속 후, Agent 프로세스 존재 여부를 확인했습니다:

ps -ef | grep agent

결과: agent.py, agent_updater.py 프로세스가 보이지 않고, grep 명령어만 출력됨 → Agent 미동작 상태 확인

4. 해결 방법

설치 경로(/home1/nbpmon/agent_controller_linux/)로 이동 후 재시작 스크립트 실행:

cd /home1/nbpmon/agent_controller_linux/
./restart_agent.sh

이후 다시 확인:

ps -ef | grep -E "agent.py|agent_updater.py" | grep -v grep

✅ 결과:

/home1/nbpmon/.../agent_updater.py
/home1/nbpmon/.../agent.py

→ Agent가 정상적으로 기동됨을 확인.

하드 리셋 및 설치방법

# 0) 경로 이동
cd /home1/nbpmon/agent_controller_linux

# 1) 완전 중지(실패해도 무시)
chmod +x stop_agent.sh start_agent.sh restart_agent.sh uninstall_agent.sh install_agent.sh || true
./stop_agent.sh || true
pkill -9 -f "agent.py|agent_updater.py" || true

# 2) 찌꺼기(pid/로그) 제거
find install_folders -name "*.pid" -delete 2>/dev/null
rm -rf logs/* 2>/dev/null

# 3) 재설치 → 기동
./uninstall_agent.sh || true
./install_agent.sh
./start_agent.sh

# 4) 프로세스/로그 즉시 확인
ps -ef | grep -E "agent.py|agent_updater.py" | grep -v grep
tail -n 120 logs/agent.log

5. 후속 조치

NCP 콘솔 확인
약 1~3분 후 Cloud Insight 대시보드에서 CPU/메모리 지표가 정상적으로 표시됨.
자동 기동 설정
서버 재부팅 시 자동 실행되도록 systemd 서비스 등록:
cd /home1/nbpmon/agent_controller_linux cp nsight-agent.service /etc/systemd/system/nsight-agent.service systemctl daemon-reload systemctl enable --now nsight-agent
로그 확인 (문제 발생 시)
cd /home1/nbpmon/agent_controller_linux/logs tail -n 200 agent.log tail -n 200 agent_updater.log

6. 정리

문제: 서버 강제 종료 이후 모니터링 지표 미표시
원인: Cloud Insight Agent 프로세스 종료
해결: restart_agent.sh 실행 후 프로세스 정상 기동
후속 조치: systemd 자동 기동 등록 + 로그 모니터링

결론: Cloud Insight 지표가 안 잡히면, 우선 Agent 상태부터 확인하자!

이제 같은 문제가 생겨도 위 순서대로 점검하면 빠르게 복구할 수 있습니다

서버에서 Playwright 좀비 프로세스(headless_shell) 확인 및 삭제 방법

Chansman — Fri, 15 Aug 2025 21:36:24 +0900

서버에서 Playwright 좀비 프로세스(headless_shell) 확인 및 삭제 방법

FastAPI + Playwright 기반 스크래핑 환경에서는 브라우저 컨텍스트 종료 누락이나 부모 프로세스 미회수로 인해 headless_shell <defunct> 프로세스가 남아 서버 메모리/CPU를 잠식하는 경우가 발생할 수 있습니다.
이 글에서는 좀비 프로세스 확인 → 종료 → 재발 방지 → 모니터링까지 정리합니다.

1. 현재 좀비 프로세스 확인

좀비 프로세스는 상태 코드(STAT)가 Z로 표시됩니다.

ps -eo pid,ppid,stat,cmd | grep 'Z' | grep -v grep

예시 출력:

170750  169780 Z    [headless_shell] <defunct>
170751  169780 Z    [headless_shell] <defunct>

PID : 좀비 프로세스 ID (kill 불가능, 부모 종료 시 정리됨)
PPID: 부모 프로세스 ID
[headless_shell] <defunct> : Playwright 브라우저 잔여 프로세스

2. 부모 프로세스 확인

ps -p <PPID> -o pid,ppid,stat,cmd

예:

ps -p 169780 -o pid,ppid,stat,cmd

PID     PPID STAT CMD
169780  169758 Ssl  /usr/local/bin/python3.12 /usr/local/bin/uvicorn app.main:app --host 0.0.0.0 --port 8000

여기서 부모가 FastAPI(Uvicorn) 프로세스임을 확인할 수 있습니다.

3. 좀비 프로세스 제거 방법

(1) FastAPI 컨테이너 재시작

docker compose restart fastapi

또는

docker restart fastapi

→ 부모 프로세스 재시작 시 하위 좀비들이 정리됩니다.

(2) 전체 프로세스 종료 후 재기동

docker compose down
docker compose up -d

4. 메모리/CPU 상태 확인

실시간 모니터링

htop

또는 간단 확인:

free -h

출력 예:

Mem:           15Gi       4.0Gi       10Gi       0.5Gi       1.2Gi       12Gi
Swap:            0B          0B          0B

CPU 사용량 상위 프로세스 확인

ps -eo pid,ppid,%cpu,%mem,stat,cmd --sort=-%cpu | head -n 20

5. 좀비 프로세스 재발 방지

브라우저 컨텍스트 종료 철저→ 키워드 처리 후 반드시 컨텍스트 닫기
from app.features.internal.fetch_article.scraper.playwright_browser import close_all_contexts await close_all_contexts()
브라우저 주기적 재가동→ N회 처리마다 브라우저 자체를 재시작
from app.features.internal.fetch_article.scraper.playwright_browser import recycle_browser await recycle_browser()
FastAPI 종료 이벤트에서 정리
@app.on_event("shutdown") async def _on_shutdown(): await recycle_browser()

6. 좀비 감시 스크립트 예시

#!/bin/bash
while true; do
    echo "==== $(date) ===="
    ps -eo pid,ppid,stat,cmd | grep 'Z' | grep -v grep
    free -h
    sleep 60
done

/root/check_zombies.sh 로 저장
실행: bash /root/check_zombies.sh

✅ 정리

Z 상태 프로세스 = 좀비 (kill 불가, 부모 종료 필요)
부모 확인 후 재시작으로 제거
컨텍스트/브라우저 종료 로직 철저하게 유지
정기적인 모니터링으로 재발 방지

서버에서 CPU/메모리 사용량 확인 및 점검 방법

Chansman — Thu, 14 Aug 2025 19:54:46 +0900

서버에서 CPU/메모리 사용량 확인 및 점검 방법

서버 운영 중 CPU나 메모리 사용량이 갑자기 높아지면 성능 저하나 서비스 중단이 발생할 수 있습니다.
아래 방법을 사용하면 SSH로 접속해 실시간 모니터링과 원인 파악을 빠르게 할 수 있습니다.

1️⃣ CPU 사용량 확인

실시간 보기

top -o %CPU

CPU 사용률 기준으로 내림차순 정렬됩니다.
%CPU가 높은 프로세스를 확인하세요.

상위 20개만 보기

ps aux --sort=-%cpu | head -n 20

CPU를 많이 쓰는 프로세스만 빠르게 확인할 때 유용합니다.

CPU + 메모리 같이 보기

ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head -n 20

CPU와 메모리 점유율을 동시에 확인해 종합적으로 판단할 수 있습니다.

2️⃣ 메모리 사용량 확인

실시간 보기

top -o %MEM

메모리 사용량 기준으로 내림차순 정렬됩니다.
RES(실제 메모리)와 %MEM(비율)을 참고하세요.

상위 20개만 보기

ps aux --sort=-%mem | head -n 20

메모리를 많이 쓰는 프로세스만 출력합니다.

CPU + 메모리 같이 보기

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head -n 20

메모리와 CPU 사용량을 한 번에 체크할 수 있습니다.

3️⃣ Docker 컨테이너별 자원 사용량

docker stats --no-stream

각 컨테이너의 CPU·메모리 사용량을 확인할 수 있습니다.

4️⃣ 불필요한 프로세스 종료

확인 후 불필요한 프로세스는 PID를 이용해 종료합니다.

kill PID

또는 강제 종료:

kill -9 PID

팁

CPU 폭주 원인은 보통 무한 루프나 비정상 대기 중인 스크립트, 크롤러(headless_shell, playwright, python 등)입니다.
메모리 폭주는 캐시, DB 서버, 또는 종료되지 않은 대형 프로세스가 원인입니다.
평소에 top과 docker stats 명령을 익혀두면 장애 대응 속도가 크게

서버에서 Playwright/Chrome 좀비 프로세스 청소하기

Chansman — Thu, 14 Aug 2025 19:52:34 +0900

서버에서 Playwright/Chrome 좀비 프로세스 청소하기

서버 환경(리눅스)에서 Playwright/Chrome 기반 크롤링이 오래 돌다 보면, headless_shell 프로세스가 남아서 CPU와 메모리를 계속 점유하는 경우가 있습니다.
이 상태가 지속되면 서버 성능이 저하되고, 다른 서비스에도 영향을 줄 수 있습니다.

아래 방법을 사용하면 서버 내부에서 좀비 프로세스 정리 + Docker 컨테이너 종료 + 캐시 삭제까지 한 번에 할 수 있습니다.

1️⃣ headless_shell / Playwright / Chrome / Python 종료

서버 SSH 접속 후:

# 부드럽게 종료
pkill -f headless_shell || true
pkill -f "chrome --headless" || true
pkill -f playwright || true
pkill -f python || true
pkill -f uvicorn || true
pkill -f gunicorn || true
pkill -f "manage.py" || true

# 3초 후 남아있으면 강제 종료
sleep 3
pgrep -f "headless_shell|chrome|playwright|python|uvicorn|gunicorn|manage.py" | xargs -r kill -9

2️⃣ Docker 컨테이너까지 멈추기

docker stop $(docker ps -q) 2>/dev/null

3️⃣ Playwright 캐시 삭제

rm -rf ~/.cache/ms-playwright/* 2>/dev/null || true

4️⃣ 서버 전용 정리 스크립트 만들기

자주 쓴다면 아래처럼 스크립트로 저장해 두세요.

cleanup_server.sh

#!/bin/bash
echo "  Killing zombie processes..."
pkill -f "headless_shell|chrome|playwright|python|uvicorn|gunicorn|manage.py" || true
sleep 2
pgrep -f "headless_shell|chrome|playwright|python|uvicorn|gunicorn|manage.py" | xargs -r kill -9

echo "  Stopping Docker containers..."
docker stop $(docker ps -q) 2>/dev/null

echo "  Cleaning Playwright cache..."
rm -rf ~/.cache/ms-playwright/* 2>/dev/null || true

echo "✅ Done."

실행 권한 부여:

chmod +x cleanup_server.sh

필요할 때:

./cleanup_server.sh

결론:

서버에서 headless_shell 같은 좀비 프로세스가 남아 있으면 성능 저하가 발생합니다.
위 방법으로 정리하면 메모리와 CPU를 회수하고, 서버 안정성을 높일 수 있습니다.
주기적으로 점검하거나, 크론탭에 등록해서 자동 실행하는 것도 좋은 방법입니다.

컴퓨터 느려질 때 WSL + Playwright 좀비 프로세스 청소하기

Chansman — Thu, 14 Aug 2025 18:41:07 +0900

컴퓨터 느려질 때 WSL + Playwright 좀비 프로세스 청소하기

WSL 환경에서 Playwright/Chrome 기반 크롤링을 오래 돌리다 보면, headless_shell 프로세스가 메모리를 잡아먹고 안 내려가는 경우가 있습니다.
이 상태가 오래 지속되면 Windows에서 vmmemWSL 프로세스가 수 GB~수십 GB까지 커져 PC 전체가 느려집니다.

아래 방법을 따라 하면 좀비 프로세스를 정리하고, 필요하면 WSL 전체 메모리 반환까지 할 수 있습니다.

1️⃣ 현재 메모리·CPU 점유 확인

Windows PowerShell에서:

# CPU/메모리 많이 쓰는 순서로 보기
Get-Process | Sort-Object CPU -desc | Select-Object -First 20

여기서 vmmemWSL이 크면 WSL 내부에서 무언가 메모리를 많이 쓰고 있는 것입니다.
chrome, headless_shell, python 프로세스가 보이면 크롤링/스크래핑 작업이 원인일 확률이 높습니다.

2️⃣ WSL 내부 좀비 프로세스 확인

PowerShell에서 WSL 진입:

wsl

WSL 안에서:

# 메모리 점유순 보기
top -o %MEM

# 크롤링 관련 프로세스만 보기
ps aux | egrep 'python|playwright|headless_shell|chrome|chromium' | grep -v grep

3️⃣ 좀비 프로세스 종료

WSL 안에서:

# 부드럽게 종료
pkill -f headless_shell || true
pkill -f "chrome --headless" || true
pkill -f playwright || true
pkill -f python || true
pkill -f uvicorn || true
pkill -f gunicorn || true
pkill -f "manage.py" || true

# 3초 후 남아있으면 강제 종료
sleep 3
pgrep -f "headless_shell|chrome|playwright|python|uvicorn|gunicorn|manage.py" | xargs -r kill -9

4️⃣ Docker 컨테이너도 종료

docker stop $(docker ps -q) 2>/dev/null

5️⃣ 메모리를 바로 반환하고 싶을 때

좀비 프로세스를 정리했는데도 vmmemWSL이 큰 상태라면, PowerShell에서:

wsl --shutdown

WSL이 완전히 종료되면서 메모리가 Windows로 반환됩니다.
⚠ 주의: WSL 내부에서 실행 중이던 모든 서버/컨테이너가 중단됩니다.

6️⃣ 한 줄 정리 스크립트 (WSL 내부)

매번 타이핑이 귀찮다면 WSL에 아래 스크립트를 저장해 두세요.

cleanup_zombies.sh

#!/bin/bash
echo "  Killing zombie processes..."
pkill -f "headless_shell|chrome|playwright|python|uvicorn|gunicorn|manage.py" || true
sleep 2
pgrep -f "headless_shell|chrome|playwright|python|uvicorn|gunicorn|manage.py" | xargs -r kill -9

echo "  Stopping Docker containers..."
docker stop $(docker ps -q) 2>/dev/null

echo "  Cleaning Playwright cache..."
rm -rf ~/.cache/ms-playwright/* 2>/dev/null || true

echo "✅ Done."

실행 권한 부여:

chmod +x cleanup_zombies.sh

필요할 때:

./cleanup_zombies.sh

결론:

크롤링/스크래핑 작업 중 headless_shell가 좀비처럼 남아 있으면 메모리 폭주가 발생합니다.
위 방법으로 WSL 내부에서 프로세스를 정리하면 Windows 전체 속도가 개선됩니다.
정기적으로 실행하거나, 자동화 스크립트로 등록해 두면 더 편합니다.

프론트? 백앤드? react vs django

Chansman — Sat, 9 Aug 2025 19:26:15 +0900

1. DOM

React: 브라우저가 HTML을 객체화한 구조 → 화면에 보이는 최종 결과물
Django: 템플릿(.html)이 서버에서 렌더링되어 브라우저에 도착한 상태
DOM은 백엔드에서 내려준 HTML과 비슷하지만, 프론트에서는 이를 동적으로 계속 변경 가능.

2. 컴포넌트 (React) ↔ 템플릿 + include (Django)

React 컴포넌트: 버튼, 카드, 드로어 등 재사용 가능한 UI 조각
Django: {% include 'header.html' %}처럼 재사용 가능한 템플릿 조각
차이: Django 템플릿은 서버에서 조립, React 컴포넌트는 브라우저에서 조립.

3. 훅(Hook) ↔ 서비스/헬퍼 함수(or View 로직 일부)

React 훅: 화면 없이 로직·데이터·상태를 관리 (useGenerateFlow)
Django:
- services.py에 만든 비즈니스 로직
- 또는 View 함수/클래스 내부의 데이터 처리 부분
  공통점: 직접 UI를 만들지 않고 데이터·동작만 준비
  차이: Django는 서버에서 실행, React 훅은 브라우저(클라이언트)에서 실행.

4. Pages ↔ View + URLconf

React Pages: Home.js, About.js 등 URL에 따라 전체 화면 렌더링
Django:
- View 함수/클래스(home_view, about_view)
- urls.py로 URL 매핑
  공통점: URL 요청 시 어떤 화면/응답을 보여줄지 결정
  차이: Django View는 서버에서 HTML/JSON 응답, React Page는 브라우저에서 UI 렌더링.

5. API 클라이언트 ↔ Django APIView

React API 파일 (src/api/*.js):
- generatePost(keywordId) → POST /generate/
- getPostDetail(postId) → GET /posts/:id/
- copyPost(postId) → POST /posts/:id/copy/
- getPdfUrl(postId) → GET /posts/:id/pdf/
Django:
- /generate/ → GeneratePostAPIView
- /posts/<id>/ → PostDetailAPIView
- /posts/<id>/copy/ → PostCopyAPIView
- /posts/<id>/pdf/ → PostPdfAPIView
  역할: 프론트와 백엔드의 HTTP 연결 포인트.

6. 전체 구조 비교표

React (프론트)Django (백엔드)역할

DOM	렌더링된 HTML 응답	최종 결과물
컴포넌트	템플릿 조각 ({% include %})	재사용 가능한 UI
훅(Hook)	Service 함수 / View 로직 일부	공통 로직, 데이터 처리
Pages	View 함수/클래스 + URLconf	URL 단위 화면/응답
API 파일	APIView + urls.py	HTTP 통신 연결 포인트

블로기 프로젝트 예시

useGenerateFlow = Django의 services/post_service.py (비즈니스 로직)
GenerateResultDrawer = Django 템플릿(drawer.html)
Home.js = Django의 home_view + home.html
DOM = home.html이 최종 렌더링된 모습

✅ FastAPI vs Django 구조 비교

Chansman — Wed, 30 Jul 2025 15:23:39 +0900

✅ FastAPI vs Django 구조 비교

역할 구분	Django 기준	FastAPI 기준	설명
URL 매핑	urls.py	router.py 또는 routes/*.py	어떤 경로로 요청을 받을지 결정
View / Logic	views.py (함수형 or APIView)	router.py에서 직접 또는 service.py	요청 처리 로직을 담당
로직 분리	views.py 내부 함수 / class	service.py	비즈니스 로직 분리 (가독성/유지보수)
Serializer	serializers.py	schema.py	요청/응답 구조 정의
Model	models.py	models.py (ORM에 따라 다름)	DB 모델 정의

✅ 예시로 보면 더 쉽게 이해돼요:

Django에서는:

# urls.py
path('articles/', ArticleListView.as_view())

# views.py
class ArticleListView(APIView):
    def get(self, request):
        ...

FastAPI에서는:

# router.py
@router.get("/articles", response_model=ArticleListSchema)
async def list_articles():
    return await get_articles()

# service.py
async def get_articles():
    # DB에서 조회

실무에서는 보통 이렇게 분리합니다:

schema.py: 요청/응답 구조
router.py: API 정의 (@router.get/post/...)
service.py: DB 조회, API 호출 등 로직
client.py: 외부 API 연동 (예: Bing 이미지 API)
model.py: ORM 모델 (Tortoise / SQLAlchemy 등)