프로젝트 소개

• 어떤 기능을 하는 프로젝트인가요?
• 타 비슷한 프로젝트에 비해서 장점이 무엇인가요?
• 프로젝트의 핵심 목표는 무엇인가요?

추천 로직

• 추천 로직이 어떻게 되나요? (홈 + 챗봇)
• 추천 시스템에서 사용한 알고리즘은 무엇인가요?
• 추천 결과의 정확도를 어떻게 평가했나요?

갈등 해결

• 프로젝트 진행 중 갈등이 발생한 적이 있나요?
• 갈등을 어떻게 해결했나요?
• 팀원 간 의견 충돌이 있을 때 어떻게 조율했나요?

맡은 역할

• 프로젝트에서 맡은 역할은 무엇인가요?
• 맡은 역할에서 가장 중점을 둔 부분은 무엇인가요?
• 프로젝트를 진행하면서 배운 점은 무엇인가요?

데이터베이스 설계 (ERD)

• ERD를 설계할 때 고려한 사항은 무엇인가요?
• 주요 테이블과 그 관계에 대해 설명해주세요.
• 성능 최적화를 위해 어떤 노력을 했나요?

기술 스택

• 어떤 기술 스택을 사용했나요?
• 각 기술을 선택한 이유는 무엇인가요?
• 프로젝트에서 사용한 주요 라이브러리나 프레임워크는 무엇인가요?

AWS 서버 배포

• AWS 배포 과정은 어떻게 진행했나요?
• 사용한 AWS 서비스는 무엇인가요? (EC2, S3, RDS 등)
• 서버 모니터링과 유지보수는 어떻게 했나요?

Docker 활용

• Docker를 사용했나요? 사용했다면 어떻게 적용했나요?
• Docker Compose를 활용했나요?
• Docker 이미지 빌드 및 배포 과정에 대해 설명해주세요.

프로젝트 버전 관리

• 프로젝트에서 git 컨벤션을 어떻게 정했나요?
• PR 규칙 및 브랜치 전략은 어떻게 운영했나요?
• 프로젝트 협업 과정에서 git을 어떻게 활용했나요?

코드 리뷰

• 코드 리뷰를 진행했나요?
• 코드 리뷰에서 중요하게 생각한 부분은 무엇인가요?
• 코드 리뷰를 통해 개선된 사례가 있다면 설명해주세요.

1. 프로세스의 개념과 구성 요소

• 프로세스 정의
  • 실행 중인 프로그램을 의미 각 프로세스는 독립된 메모리 공간과 실행 상태를 가짐
• 프로세스 제어 블록(PCB)
  • 프로세스의 상태, 프로그램 카운터, 레지스터, 메모리 관리 정보, I/O 상태 등의 정보를 저장하는 자료구조
  • PCB는 운영체제가 프로세스를 관리하고 스케줄링할 때 핵심적인 역할을 함

2. 프로세스 생성과 종료

• 프로세스 생성
  • fork: 기존 프로세스를 복제하여 새로운 프로세스를 생성하는 시스템 호출. 부모와 자식 프로세스는 독립적으로 실행. 자식은 부모의 메모리 상태를 복사함
  • exec: 생성된 프로세스가 다른 프로그램을 실행하도록 덮어쓰는 방식으로 사용. fork와 함께 자주 사용됨
• 프로세스 종료
  • 프로세스가 실행을 마치거나 오류 발생 시 종료. 운영체제는 종료된 프로세스의 PCB를 해제하고, 관련 자원을 반환

3. 프로세스 상태와 전이

• 주요 프로세스 상태
  • 생성(New): 프로세스가 생성되어 준비되는 상태
  • 준비(Ready): CPU 할당을 기다리는 상태. 여러 프로세스가 이 상태에서 대기
  • 실행(Running): CPU를 할당받아 명령어를 실행 중인 상태
  • 대기(Waiting): I/O 요청이나 특정 이벤트를 기다리는 상태
  • 종료(Terminated): 프로세스 실행이 완료되거나 강제 종료된 상태
• 상태 전이 과정
  • 프로세스는 실행 중 I/O 요청이나 이벤트 대기로 인해 준비 상태에서 대기 상태로, 이벤트가 완료되면 다시 준비 상태로 돌아감 즉 상태 간의 전이가 이루어짐

4. CPU 스케줄링과 알고리즘

• 스케줄링의 목적
  • CPU를 여러 프로세스 간에 효율적으로 분배하여 시스템 자원 활용도를 높이고, 응답 시간을 최소화함
• 주요 스케줄링 알고리즘
  • FCFS(First-Come, First-Served):
    • 도착 순서대로 프로세스에 CPU 할당. 단순하지만 평균 대기 시간이 길어질 수 있음
  • SJF(Shortest Job First):
    • 실행 시간이 짧은 프로세스 우선. 평균 대기 시간이 짧아지지만, 예측이 어려울 경우 부적합
  • 라운드 로빈(Round Robin):
    • 각 프로세스에 고정된 시간(타임 슬라이스)을 할당하며 순환적으로 CPU를 분배. 공정성이 높지만, 타임 슬라이스의 크기에 따라 성능이 좌우됨
  • 우선순위 스케줄링:
    • 프로세스마다 우선순위를 부여하여 높은 우선순위를 가진 프로세스에 CPU를 우선 할당. 우선순위 역전 문제 등이 발생할 수 있음
  • 멀티 레벨 큐 스케줄링:
    • 프로세스들을 여러 큐로 분류한 후, 각 큐에 다른 스케줄링 알고리즘을 적용하여 관리. 서로 다른 특성을 가진 프로세스들을 효율적으로 처리

5. 문맥 교환(Context Switching)

• 문맥 교환의 정의
  • CPU가 한 프로세스에서 다른 프로세스로 전환할 때 현재 프로세스의 상태(레지스터, 프로그램 카운터 등)를 저장하고 새로운 프로세스의 상태를 불러오는 과정
• 문맥 교환의 오버헤드
  • 빈번한 문맥 교환은 CPU 시간을 소모. 스케줄링 알고리즘 설계 시 오버헤드를 최소화하는 것이 중요함

6. 인터프로세스 커뮤니케이션(IPC)

• IPC의 필요성
  • 여러 프로세스가 서로 데이터를 교환하거나 협력 작업을 수행하기 위해 필요
• IPC 기법들
  • 파이프(Pipe): 한 프로세스의 출력이 다른 프로세스의 입력으로 연결되는 방식
  • 메시지 큐: 프로세스 간에 메시지를 보내고 받을 수 있도록 지원하는 큐 구조
  • 공유 메모리: 여러 프로세스가 동일한 메모리 공간을 공유하며 빠른 통신을 가능하게 함
  • 소켓: 네트워크를 통한 프로세스 간 통신에 사용.

7. 동기화와 경쟁 조건 문제

• 동기화 필요성
  • 여러 프로세스나 스레드가 동시에 공유 자원에 접근할 때 데이터 무결성을 보장하기 위한 방법
• 주요 동기화 기법
  • 뮤텍스(Mutex): 상호 배제를 통해 한 번에 한 프로세스만 공유 자원에 접근하도록 제한
  • 세마포어(Semaphore): 프로세스 동기화와 자원 관리를 위한 카운터 기반의 기법
  • 모니터(Monitor): 데이터와 그 데이터를 조작하는 절차를 하나로 묶어 동기화를 자동으로 처리

1. 운영체제의 개념과 역할

• 운영체제(OS)의 정의
  • 컴퓨터 하드웨어와 응용 프로그램 사이에서 자원을 효율적으로 관리하는 소프트웨어
  • 사용자와 하드웨어 간의 인터페이스 역할 수행
• 주요 역할
  • 프로세스, 메모리, 파일, 입출력 장치 등 시스템 자원 관리
  • 시스템의 안정성과 효율성 보장

2. 프로세스 관리

• 프로세스와 스레드
  • 프로세스: 실행 중인 프로그램으로, 독립적인 메모리 공간을 가짐
  • 스레드: 프로세스 내에서 실행되는 작업 단위, 같은 프로세스 내 여러 스레드는 메모리 공간을 공유
• 프로세스 상태
  • 생성, 준비, 실행, 대기, 종료 상태로 구분되며, 각 상태 전환 과정을 통해 프로세스가 운영됨
• 스케줄링
  • CPU 할당을 위한 알고리즘: FCFS(선입선출), SJF(최단 작업 우선), 우선순위, 라운드 로빈 등이 있음
  • 각 알고리즘은 작업의 종류와 시스템 환경에 따라 장단점이 있음

3. 메모리 관리

• 주기억장치와 보조기억장치
  • 주기억장치: RAM, 휘발성 메모리로서 프로세스가 실행되는 동안 데이터를 저장
  • 보조기억장치: HDD, SSD 등 비휘발성 저장 장치로 데이터를 영구 보관
• 메모리 할당 방식
  • 연속 할당: 단순하지만 외부 단편화 문제 발생
  • 비연속 할당: 페이징과 세그멘테이션 기법을 통해 메모리 효율성 증대
• 가상 메모리
  • 실제 메모리보다 큰 주소 공간을 제공하여, 디스크의 일부를 메모리처럼 사용하는 기술
  • 페이지 교체 알고리즘(예: LRU, FIFO)을 통해 효율적인 메모리 활용

4. 파일 시스템

• 파일의 개념과 관리
  • 데이터를 논리적 단위(파일)로 관리하며, 디렉토리 구조를 통해 조직화
  • 파일 접근 권한 및 보안을 위한 관리 필요
• 파일 시스템의 종류
  • FAT, NTFS, ext4 등 각 운영체제에 맞는 파일 시스템이 존재
  • 각 시스템은 성능, 안정성, 보안 측면에서 차이가 있음
• 파일 입출력
  • 파일 생성, 읽기, 쓰기, 삭제 등의 기본 작업 수행
  • 버퍼링, 캐싱 등 성능 최적화 기법도 학습 필요

5. 입출력 장치와 장치 관리

• I/O 장치 관리
  • 다양한 입출력 장치(키보드, 마우스, 프린터, 네트워크 장비 등)를 효율적으로 제어
  • 장치 드라이버를 통해 하드웨어와 소프트웨어 간 통신을 담당
• 입출력 방식
  • 인터럽트 기반, DMA(Direct Memory Access) 등 하드웨어 효율성을 높이는 방식 적용

6. 동시성 제어와 데드락

• 동기화 문제
  • 여러 프로세스나 스레드가 동시에 공유 자원에 접근할 때 발생하는 문제 해결
  • 뮤텍스, 세마포어, 모니터 등의 기법을 사용하여 충돌 방지
• 데드락(Deadlock)
  • 두 개 이상의 프로세스가 서로 자원을 기다리며 무한 대기 상태에 빠지는 현상
  • 예방, 회피, 탐지 및 회복 기법으로 관리

7. 보안과 접근 제어

• 사용자 인증 및 권한 관리
  • 시스템 자원에 대한 접근을 제어하여, 무단 접근이나 악의적 행위를 방지
  • 파일 권한 설정, 암호화, 방화벽 등 다양한 보안 기법 적용

1.

다른 조들의 발표를 경청하면서 모두가 정말 열심히 준비했다는 걸 느꼈다. 각 팀이 각자의 방식으로 고민하고, 개발하고, 완성해가는 과정이 고스란히 발표에 담겨 있어서 감탄스러웠다. 다만 A, B 발표장이 나뉘어 있어서 다른 발표장의 조들이 어떤 발표를 했는지 직접 듣지 못한 점은 조금 아쉬웠다. 다른 팀들의 발표도 직접 보고 싶었는데, 녹화 영상이 있다면 꼭 챙겨봐야겠다고 생각했다.

2.

우리 팀의 발표도 무사히 끝났다. 20여 분이라는 짧은 시간이었지만, 프로젝트의 핵심 내용을 전달하는 데에는 큰 무리가 없었던 것 같다. 사실, 개발하는 동안 다양한 기능을 추가하고 싶었지만, 발표 시간 내에 모든 걸 보여주기는 어려웠다. 하지만 핵심적인 기능과 프로젝트의 방향성을 효과적으로 전달했다고 생각하니 뿌듯했다.

또한, 협력사 분들께서 질의응답 시간에 피드백을 주셨다는 점이 인상적이었다. 실무에서 바라보는 시각과 우리가 개발하면서 놓쳤던 부분들을 짚어주셔서 정말 큰 도움이 되었다. "이 기능을 더 발전시키면 이런 활용이 가능할 것 같다"는 말이 기억에 남는다. 앞으로 추가적인 기능을 고민할 때 참고해야겠다고 생각했다.

3.

발표가 끝나고 저녁 시간에는 다양한 분들이 다가와 프로젝트에 대한 이야기를 나누었다. 몇몇 튜터님들과 외부 손님들도 프로젝트에 대한 질의응답을 해 주셨고, 피드백을 남겨주셨다. 심지어 추가적인 멘토링 기회를 얻게 된 것도 있었다. 이 과정에서 느낀 것은, 우리가 만든 프로젝트가 단순한 학습 과제를 넘어서 실제로 유용한 가치를 가질 수도 있겠다는 점이었다.

특히 "이런 기능이 추가되면 정말 좋겠다", "서비스로 발전시키면 사용자들이 관심을 가질 것 같다"는 피드백을 들었을 때, 단순한 팀 프로젝트로 끝내기엔 아깝다는 생각이 들었다. 우리가 만든 기능이 사용자들에게 실제로 어떤 가치를 줄 수 있을지 더 깊이 고민해봐야겠다는 다짐을 하게 되었다.

4.

1월 한 달 동안 열정적인 팀원들과 함께 프로젝트를 하면서 정말 많은 걸 배웠다. 단순히 코드를 짜는 것이 아니라, 협업의 과정에서 커뮤니케이션이 얼마나 중요한지, 예상치 못한 이슈를 해결하는 과정에서 어떤 태도를 가져야 하는지를 배울 수 있었다.

물론 힘든 순간도 많았다. 일정이 촉박한 상황에서 예상보다 오래 걸리는 기능 구현, 예상치 못한 버그, 그리고 팀원들 간의 의견 조율까지. 하지만 이러한 과정이 있었기에 더 성장할 수 있었고, 마지막에 프로젝트가 완성되었을 때의 희열은 오랫동안 남아 있을 듯 하다 !

5.

마지막으로...

🔹 Django 공식문서 기반 쿼리 최적화

Django는 ORM을 사용하여 SQL 쿼리를 자동 생성하지만, 잘못된 사용은 성능 저하를 유발할 수 있음.
Django 공식 문서에서 추천하는 쿼리 최적화 방법을 정리.

✅ 1. select_related() 사용 (JOIN 최적화)

• ForeignKey, OneToOneField 관련 데이터를 함께 조회하여 N+1 문제 방지

  # N+1 문제 발생 (비효율적)
  games = Game.objects.all()
  for game in games:
    print(game.genre.name)  # 매번 genre를 조회하는 추가 쿼리 발생
  

최적화된 코드

games = Game.objects.select_related("genre") # JOIN 수행하여 한 번에 조회

#### ✅ 2. `prefetch_related()` 사용 (ManyToMany, ForeignKey 역참조 최적화)
- **ManyToMany, OneToMany 관계에서 여러 개의 추가 쿼리를 미리 가져옴**
```python
# N+1 문제 발생 (비효율적)
games = Game.objects.all()
for game in games:
    for tag in game.tags.all():
        print(tag.name)  # 여러 개의 쿼리 발생

# 최적화된 코드
games = Game.objects.prefetch_related("tags")  # 미리 가져와서 쿼리 수 감소

✅ 3. only()와 defer()로 불필요한 필드 로딩 방지

• 필요한 필드만 가져와 성능 최적화

  # 모든 필드 조회 (비효율적)
  game = Game.objects.get(id=1)
  

특정 필드만 조회 (최적화)

game = Game.objects.only("id", "name") # 나머지 필드는 필요할 때까지 조회되지 않음 game = Game.objects.defer("large_text_field") # 특정 필드 제외하여 조회

#### ✅ 4. `exists()`를 사용하여 불필요한 데이터 로딩 방지
- **데이터 존재 여부만 확인할 때 `count()` 대신 `exists()` 사용**
```python
# 비효율적인 방식
if Game.objects.filter(name="Cyberpunk 2077").count() > 0:
    print("게임이 존재합니다.")

# 최적화된 코드
if Game.objects.filter(name="Cyberpunk 2077").exists():
    print("게임이 존재합니다.")  # 더 빠르고 메모리 절약 가능

✅ 5. bulk_create()와 update() 사용하여 다수의 데이터 처리 최적화

# 여러 개의 객체를 한 번에 저장
games = [
    Game(name="The Witcher 3"),
    Game(name="Elden Ring"),
]
Game.objects.bulk_create(games)  # 여러 INSERT 쿼리를 하나로 합침

✅ 6. annotate()를 활용한 집계 연산 최적화

from django.db.models import Count

# 각 게임이 가진 리뷰 개수 가져오기 (JOIN + GROUP BY)
games = Game.objects.annotate(review_count=Count("reviews"))
for game in games:
    print(f"{game.name} - {game.review_count}개 리뷰")

✅ 7. iterator()를 사용하여 대량 데이터 효율적으로 처리

• 대량 데이터 조회 시 메모리 사용량을 줄이기 위해 iterator() 사용

  for game in Game.objects.iterator():
    print(game.name)  # 메모리 최적화됨

🔹 정리

1. select_related(), prefetch_related() → N+1 문제 해결
2. only(), defer() → 불필요한 필드 로딩 방지
3. exists() 사용 → count() 대신 존재 여부만 체크할 때 사용
4. bulk_create() → 다량의 데이터 저장 시 성능 최적화
5. annotate() 사용 → ORM에서 직접 집계 연산 수행
6. iterator() 활용 → 대량 데이터 메모리 절약

🚀 Django ORM을 잘 활용하면 성능 최적화가 가능하며, 불필요한 SQL 쿼리 실행을 줄일 수 있음!

🔹 verbose_name이란?

• verbose_name은 Django 모델 필드의 사람이 읽기 쉬운 이름을 정의하는 옵션.
• 기본적으로 필드명이 snake_case일 경우, Django는 자동으로 _을 공백으로 변환하여 UI에서 표시.
• 하지만, 보다 직관적인 필드명을 제공하기 위해 직접 verbose_name을 지정하는 것이 일반적.

✅ verbose_name의 장점

1. 관리자(admin) UI 개선
   • Django Admin에서 필드명을 보기 좋게 표시
2. Form 및 ModelSerializer에서 명확한 라벨 제공
   • API 응답, Django Form에서 더 직관적인 필드명 제공
3. 다국어 지원
   • gettext_lazy를 사용하면 다국어(Localization) 처리 가능

🔹 예제

from django.db import models
from django.utils.translation import gettext_lazy as _

class Game(models.Model):
    name = models.CharField(max_length=255, verbose_name=_("게임 이름"))
    release_date = models.DateField(verbose_name="출시일")

• verbose_name=_("게임 이름") 을 사용하면 다국어 지원 가능
• Django Admin에서 release_date 필드가 "출시일"로 표시됨

더보기 !

1️⃣ 코드 레이아웃

• 들여쓰기: 4칸의 스페이스(space) 사용, 탭(tab) 사용 금지
• 라인 길이: 최대 79자 (긴 줄은 \ 또는 괄호로 감싸서 줄바꿈)
• 빈 줄: 최상위 함수·클래스 앞에 2줄, 메서드 간 1줄

2️⃣ 임포트 스타일

• 순서: 표준 라이브러리 → 서드파티 → 로컬 모듈 (각 블록 사이 한 줄 띄움)

• 형태:

  import os
  import sys
  
  from django.conf import settings
  from my_project.module import MyClass

• 와일드카드 임포트 금지: from module import *는 지양

3️⃣ 네이밍 컨벤션

• 함수, 변수, 속성: snake_case (소문자+언더스코어)
• 클래스: PascalCase (대문자로 시작)
• 상수: ALL_CAPS (대문자+언더스코어)
• 비공개: _private_variable (접두어 _ 사용)

4️⃣ 공백 사용 규칙

• 괄호 안 공백: spam(ham[1], {eggs: 2}) ✅ (spam( ham[1] , { eggs: 2 } ) ❌)
• 쉼표 후 공백: a, b = 1, 2 ✅ (a,b=1,2 ❌)
• 연산자 주위 공백: x = a + b ✅ (x=a+b ❌)

5️⃣ 문서화 (Docstrings)

• 모든 모듈, 클래스, 함수에 docstring 추가
• 예시

  def add(x, y):
      """두 수의 합을 반환합니다."""
      return x + y

6️⃣ 조건문, 루프

• 한 줄 if문 지양

  if x == 42:
      print("정답입니다.")  # ✅

• 불필요한 비교 연산 지양

  if my_list:  # ✅ 빈 리스트 체크 (`if len(my_list) > 0:` ❌)

7️⃣ 예외 처리

• try-except 사용 시 특정 예외를 잡도록 권장

  try:
      value = my_dict["key"]
  except KeyError:
      value = "default"

🔗 더 보기: PEP 8 공식 문서

1. 사용하지 않는 파일 삭제

• 프로젝트에 사용하지 않는 파일이 깃허브에 업로드되어 있어 관리 효율성이 떨어짐
• 조치: 사용하지 않는 파일과 코드를 확인 후 삭제

2. 모델 필드 설명 방식 개선

• 모델의 주석 대신 verbose_name 속성을 사용하여 각 필드의 역할을 명확히 설명하는 Django 권장 방식을 따름
• verbose_name은 모델 필드에 대한 가독성을 높이고 관리자를 포함한 여러 UI에서 더 직관적인 필드명을 제공

3. View를 가볍게 유지하기 위한 리팩토링

• "Fat Model, Thin View" 원칙을 적용하여 뷰를 최대한 단순화
• 조치 방향:
  • 복잡한 비즈니스 로직을 모델의 메서드 또는 별도의 유틸리티 함수로 이동
  • 예: ReviewAPIView에서 annotate와 관련된 정렬 로직을 모델 메서드로 추출

4. DB 성능 최적화를 위한 db_index 활용

• 검색 및 필터링이 자주 사용되는 필드에 db_index=True를 설정
• 예시:
  • Review 모델의 app_id 필드
  • Game 모델의 name 필드

5. Django 서브쿼리 활용

• View에서 반복적으로 호출되는 쿼리를 최적화하기 위해 Django ORM의 서브쿼리를 사용
• 적용 대상:
  • GameDetailAPIView에서 my_review 필드 로직

6. PEP8(파이썬 스타일 가이드) 준수

• import 순서를 정리하고, 그룹별로 나누어 가독성을 향상
• 조치:
  • 표준 라이브러리, 서드파티 라이브러리, 로컬 앱 순서로 구분

7. 에러 메시지 커스터마이징

• 에러 메시지 커스터마이징
• API의 에러 응답(error response) 스타일을 내맘대로 핸들링

8. 소프트 삭제 도입

• 데이터 삭제 시 실제로 데이터베이스에서 제거하지 않고, Boolean 필드를 사용하여 삭제 상태를 관리
• 적용 이유:
  • 삭제된 데이터를 복구하거나 로그를 추적할 수 있도록 보장
• 구현 방향:
  • is_deleted = models.BooleanField(default=False) 필드를 추가하고, 쿼리셋에서 기본적으로 필터링

참고 자료

• Django 문서: verbose_name
• Django 문서: 데이터베이스 최적화
• PEP 8 스타일 가이드
• 소프트 삭제 vs 하드 삭제
• 에러응답 커스터마이징
• Fat model 추천
• 모델 리펙토리시 참고: Meta

변경 코드

import environ
import requests
from django.core.management.base import BaseCommand
from django.db import transaction
from accounts.models import (
    Account,
    SteamProfile,
    SteamReview,
    SteamPlaytime,
)

from bs4 import BeautifulSoup


class Command(BaseCommand):
    help = "Steam 프로필/리뷰/플레이타임 정보를 가져와 DB에 반영"

    def handle(self, *args, **options):
        # 1) 환경 변수에서 API 키 불러오기
        env = environ.Env()
        api_key = env("STEAM_API_KEY")  # .env에 STEAM_API_KEY=... 설정

        # 2) steamId가 비어있지 않은 Account를 모두 조회
        accounts = Account.objects.exclude(steamId="")

        for account in accounts:
            steam_id_str = account.steamId.strip()

            # 3) 전체 프로필 공개 여부 API로 확인
            visibility_public = self.check_profile_public(api_key, steam_id_str)

            # 일단 기본값 False
            is_review = False
            is_playtime = False

            if visibility_public:
                # (A) 리뷰 크롤링 (최대 3개) - BeautifulSoup 이용
                review_data = self.fetch_top3_reviews(steam_id_str)
                if review_data:
                    is_review = True

                # (B) API로 플레이타임 조회 (상위 2개)
                playtime_data = self.fetch_top2_playtime_api(api_key, steam_id_str)
                if playtime_data:
                    is_playtime = True

                # (C) DB 저장
                with transaction.atomic():
                    sp, _ = SteamProfile.objects.get_or_create(account=account)
                    sp.is_review = is_review
                    sp.is_playtime = is_playtime
                    sp.save()

                    # 기존 리뷰/플레이타임 삭제 후 재생성 (중복 방지)
                    SteamReview.objects.filter(account=account).delete()
                    SteamPlaytime.objects.filter(account=account).delete()

                    if is_review:
                        for rd in review_data:
                            SteamReview.objects.create(
                                account=account,
                                app_id=rd["app_id"]
                            )
                    if is_playtime:
                        for pd in playtime_data:
                            SteamPlaytime.objects.create(
                                account=account,
                                app_id=pd["app_id"]
                            )
            else:
                # 프로필이 Private -> is_review=False, is_playtime=False
                with transaction.atomic():
                    sp, _ = SteamProfile.objects.get_or_create(account=account)
                    sp.is_review = False
                    sp.is_playtime = False
                    sp.save()

                    # 기존 리뷰/플레이타임 삭제
                    SteamReview.objects.filter(account=account).delete()
                    SteamPlaytime.objects.filter(account=account).delete()

        self.stdout.write(self.style.SUCCESS("Steam 데이터 처리 완료."))

    # -------------------------------------------------------
    # 1) 스팀 프로필이 Public인지 판별 (communityvisibilitystate == 3)
    # -------------------------------------------------------
    def check_profile_public(self, api_key, steam_id_str):
        """
        64비트 steam_id_str이 공개 상태인지 확인.
        """
        url = "https://api.steampowered.com/ISteamUser/GetPlayerSummaries/v2/"
        params = {"key": api_key, "steamids": steam_id_str}
        try:
            resp = requests.get(url, params=params).json()
        except Exception as e:
            print(f"Error checking profile public: {e}")
            return False

        players = resp.get("response", {}).get("players", [])
        if not players:
            return False

        player = players[0]
        vis_state = player.get("communityvisibilitystate", 1)
        return (vis_state == 3)

    # -------------------------------------------------------
    # 2) 리뷰 페이지 크롤링 (상위 3개 'Recommended')
    # -------------------------------------------------------
    def fetch_top3_reviews(self, steam_id_str):
        """
        Selenium 없이 HTML만 파싱하여 상위 3개의 추천 리뷰(app_id) 가져오기.
        """
        url = f"https://steamcommunity.com/profiles/{steam_id_str}/recommended"
        headers = {
            "User-Agent": (
                "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                "AppleWebKit/537.36 (KHTML, like Gecko) "
                "Chrome/87.0.4280.66 Safari/537.36"
            )
        }

        try:
            response = requests.get(url, headers=headers, timeout=10)
        except Exception as e:
            print(f"Error fetching reviews page: {e}")
            return []

        # 상태 코드 확인 (비공개거나 오류 발생 시)
        if response.status_code != 200:
            return []

        soup = BeautifulSoup(response.text, "html.parser")
        review_boxes = soup.select(".review_box")

        recommended = []
        for box in review_boxes:
            try:
                # '추천' 리뷰만 필터링
                title_elem = box.select_one(".vote_header .title > a")
                if not title_elem or "Recommended" not in title_elem.text:
                    continue

                href = title_elem.get("href", "")
                if "/recommended/" not in href:
                    continue

                app_id = href.split("/recommended/")[1].split("/")[0]
                recommended.append({"app_id": app_id})

                if len(recommended) >= 3:
                    break
            except Exception as e:
                print(f"리뷰 박스 처리 중 오류: {e}")
                continue

        return recommended

    # -------------------------------------------------------
    # 3) 플레이 타임 조회 (상위 2개)
    # -------------------------------------------------------
    def fetch_top2_playtime_api(self, api_key, steam_id_str):
        """
        GetOwnedGames API로 플레이타임이 가장 많은 상위 2개 게임(app_id) 반환.
        """
        url = "https://api.steampowered.com/IPlayerService/GetOwnedGames/v1/"
        params = {
            "key": api_key,
            "steamid": steam_id_str,
        }
        try:
            resp = requests.get(url, params=params).json()
        except Exception as e:
            print("Error fetching owned games:", e)
            return []

        games = resp.get("response", {}).get("games", [])
        if not games:
            return []

        game_data = []
        for g in games:
            app_id = g.get("appid")
            pt_min = g.get("playtime_forever", 0)
            pt_hr = round(pt_min / 60.0, 2)  # 시간 단위 환산 (소수점 둘째 자리)
            game_data.append({"app_id": str(app_id), "playtime": pt_hr})

        # 플레이타임 내림차순 정렬 후 상위 2개
        sorted_data = sorted(game_data, key=lambda x: x["playtime"], reverse=True)
        return sorted_data[:2]

주요 변경 사항

1. Selenium 전면 제거

   • webdriver.ChromeOptions(), driver.get(), WebDriverWait 등 모든 관련 코드를 삭제했다.
   • 헤드리스 크롬을 구동하지 않으므로 CPU 부담이 크게 줄어든다.

2. 리뷰 크롤링 로직(fetch_top3_reviews)

   • requests와 BeautifulSoup만 사용한다.
   • 받은 HTML에서 .review_box를 찾아 “Recommended” 텍스트가 있는 리뷰만 걸러내고, 최대 3개까지 app_id를 추출한다.

3. 커스텀 URL 변환 로직 제거

   • steam_id_str가 항상 64비트 ID라고 가정하므로 resolve_vanity_url 함수는 완전히 삭제했다.
   • check_profile_public 등에서 steam_id_str.isdigit() 관련 분기나 vanityurl 호출도 제거

4. 게임 목록 공개 여부(check_owned_games_public) 제거

   • 필요 없다고 했으므로 해당 함수를 삭제했다.

5. DB 저장 로직 동일

   • SteamProfile의 is_review, is_playtime 여부를 갱신하고
   • 기존 SteamReview, SteamPlaytime 전부 삭제 후 새로 생성한다(중복 방지)

• AWS 서버에서 Selenium을 이용해 리뷰를 크롤링하는 코드를 실행했더니 CPU 사용량이 100%에 근접하는 현상이 발생하였다.
• EC2 같이 스펙이 낮은 서버에서 헤드리스 크롬(Chromedriver)을 구동할 경우, 브라우저 엔진이 동작하면서 리소스 사용량이 크게 늘어날 수 있다.

2. 문제 원인

1. Selenium 자체의 무거운 동작 방식
   • Selenium은 실제 브라우저(크롬 등)를 띄워서 페이지 로딩, JavaScript 실행 등을 처리한다.
   • 이 과정에서 CPU와 메모리를 많이 사용하게 된다.
2. EC2 인스턴스 환경
   • 일반적으로 작은 EC2 인스턴스는 CPU 자원이 제한적이라, 브라우저를 다수 실행하거나 연속 크롤링 시 CPU 사용량이 급증하기 쉽다
3. 페이지 내용이 이미 HTML에 포함
   • Steam의 “Recommended” 리뷰는 자바스크립트 없이도 정적 HTML로 되어 있는 경우가 많다
   • 즉, 굳이 실제 브라우저로 렌더링하지 않아도 requests + BeautifulSoup 같은 간단한 방식으로 충분히 파싱 가능하다

3. 해결 방안

3.1. Selenium 제거 및 BeautifulSoup으로 전환

• requests와 BeautifulSoup만 사용해 HTML을 가져오고, 필요한 요소를 파싱한다.
• 브라우저 엔진을 구동하지 않으므로 CPU 사용량이 매우 낮아진다.

수정 전 핵심 흐름

1. webdriver.Chrome으로 헤드리스 브라우저 실행
2. driver.get(url)로 페이지 열기
3. 필요한 셀렉터(.review_box)로 요소 찾기
4. driver.quit()로 브라우저 종료

수정 후 핵심 흐름

1. requests.get(url)로 HTML을 텍스트 형태로 받아오기
2. BeautifulSoup(html, "html.parser")로 DOM 파싱
3. .select(".review_box") 등 원하는 요소에 접근
4. HTML 내 리뷰가 보이는지 확인 후 app_id 등을 추출

3.2. 코드

import requests
from bs4 import BeautifulSoup

def fetch_top3_reviews(steam_id_str):
    url = f"https://steamcommunity.com/profiles/{steam_id_str}/recommended"
    headers = {
        "User-Agent": (
            "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
            "AppleWebKit/537.36 (KHTML, like Gecko) "
            "Chrome/87.0.4280.66 Safari/537.36"
        )
    }

    # HTML 가져오기
    response = requests.get(url, headers=headers, timeout=10)
    if response.status_code != 200:
        return []

    # 파싱
    soup = BeautifulSoup(response.text, "html.parser")
    boxes = soup.select(".review_box")

    recommended = []
    for box in boxes:
        try:
            title_elem = box.select_one(".vote_header .title > a")
            if not title_elem or "Recommended" not in title_elem.text:
                continue

            href = title_elem.get("href", "")
            if "/recommended/" not in href:
                continue

            app_id = href.split("/recommended/")[1].split("/")[0]
            recommended.append({"app_id": app_id})

            if len(recommended) >= 3:
                break
        except Exception as e:
            # 에러 발생 시 로그 남기고 다음 박스로 진행
            print(f"리뷰 박스 처리 중 오류: {e}")
            continue

    return recommended

• 기존에 WebDriverWait, driver.find_elements 등을 사용하던 부분이 사라졌고, 대신 BeautifulSoup을 통한 단순 HTML 파싱으로 변경되었다.
• 최대 3개까지만 리뷰 데이터를 가져오며, 각 리뷰에서 app_id를 추출한다.

3.3. 적용 효과

• CPU 사용률 감소: 브라우저 엔진을 구동하지 않으므로 EC2에서 CPU 부하가 크게 줄어든다.

4. 트러블슈팅 요약

• 문제: Selenium으로 인한 브라우저 구동 → CPU 사용량 100% 근접
• 원인: 실제 브라우저 엔진이 동작하면서 리소스 사용량 급증
• 해결: 정적 HTML 파싱 가능하므로 requests + BeautifulSoup 도입
• 결과: CPU 부하 감소, 코딩 구조 단순화

1. 스팀 계정 연동 시 서버 CPU 사용률 증가 트러블

문제 상황:

• Selenium을 사용한 크롤링 과정에서 헤드리스 브라우저가 예상보다 많은 메모리를 사용했습니다.
• 동시 접속 시 CPU 사용률이 100%까지 치솟아 서버가 불안정했습니다.

해결 방법:

1. RAM 스왑 설정:

    - 하드디스크의 일부를 RAM처럼 사용하도록 스왑 파일을 **생성 및 활성화**했습니다.
    - 2GB 크기의 스왑 파일로 메모리 부족 문제를 **완화**했습니다.

    # 스왑 파일 생성
    sudo dd if=/dev/zero of=/swapfile bs=1M count=2048

    # 스왑 파일 권한 설정
    sudo chmod 600 /swapfile

    # 스왑 영역 설정
    sudo mkswap /swapfile

    # 스왑 활성화
    sudo swapon /swapfile

2. 로컬에서 프로덕션 서버로 데이터베이스 마이그레이션 실패

문제 상황:

• Django 기본 마이그레이션 도구로 데이터 이전 중 PostgreSQL 버전 차이와 외래 키 제약 조건 문제가 발생했습니다.
• 복잡한 데이터 구조로 인해 마이그레이션 도중 데이터 손실이 발생했습니다.

해결 방법:

• DBeaver 도구 활용:
• 로컬 DB 데이터를 CSV 파일로 추출 후, 프로덕션 서버에 직접 임포트했습니다.
• 복잡한 외래 키 구조를 임시로 비활성화 후, 데이터 로드 완료 시 다시 활성화를 했습니다.

3. 환경 변수 관리 및 CORS 문제

문제 상황:

• .env 환경 변수 관리가 배포 환경에서 꼬이는 문제가 발생했습니다.
• API 통신 중 CORS 에러가 빈번하게 발생하며, 프론트엔드와의 연결이 실패했습니다.

해결 방법:

1. Django CORS 설정:

• CORS_ALLOWED_ORIGINS에 개발 및 배포 환경의 도메인 추가:

    CORS_ALLOWED_ORIGINS = [
      "http://ai-watson.com",
      "http://52.78.197.80:8000",  # AWS IP 추가
    "http://127.0.0.1:5173",  # localhost에서 발생하는 요청도 허용"
    ]

2. 환경 변수 관리 개선

1. 기존 코드의 문제점

• 모든 데이터 반환: 검색 결과를 한 번에 모두 반환하여, 결과가 많아질 경우 성능 문제가 발생할 가능성이 있었습니다.
• 페이징 정보 부족: 클라이언트가 데이터를 어떻게 나눠서 보여줄지 판단할 수 있는 정보가 부족했습니다.
  • 다음 페이지가 존재하는지(has_next) 여부나 현재 페이지 번호(current_page) 같은 메타데이터가 없었습니다.

2. 개선된 코드의 핵심 변경 사항

a. Django Paginator 도입

• Django의 Paginator를 사용해 페이지네이션을 간단하고 효율적으로 구현.
• page와 limit를 기반으로 특정 페이지의 데이터를 반환.

b. 메타데이터 추가

• 클라이언트가 페이지를 탐색하기 쉽게 응답에 다음 정보를 추가:
  • current_page: 현재 페이지 번호
  • has_next: 다음 페이지 존재 여부

c. 불필요한 예외 처리 제거

• EmptyPage 예외 처리를 제거하고, Paginator의 기본 동작으로 페이지 요청을 처리
• 검색 결과가 없을 경우 404 Not Found를 반환하도록 간결하게 수정

3. 개선된 코드 구조

from django.core.paginator import Paginator

class ReviewSearchAPIView(APIView):
    """
    리뷰 검색 API
    """

    def get(self, request):
        """리뷰 검색"""
        keyword = request.query_params.get("keyword", "").strip()
        if not keyword:
            return Response(
                {"detail": "검색어를 입력해주세요."}, status=status.HTTP_400_BAD_REQUEST
            )

        # 검색 결과 필터링
        game_ids = Game.objects.filter(name__icontains=keyword).values_list(
            "appID", flat=True
        )
        reviews = Review.objects.filter(
            Q(content__icontains=keyword)
            | Q(categories__icontains=keyword)
            | Q(app_id__in=game_ids)
        ).distinct()

        if not reviews.exists():
            return Response(
                {"detail": "검색 결과가 없습니다."}, status=status.HTTP_404_NOT_FOUND
            )

        # 페이지네이션 처리
        page = int(request.query_params.get("page", 1))
        paginator = Paginator(reviews, 10)
        page_obj = paginator.page(page)

        # 응답 생성
        serializer = ReviewSerializer(page_obj, many=True)
        return Response(
            {
                "reviews": serializer.data,
                "has_next": page_obj.has_next(),
                "current_page": page_obj.number,
            },
            status=status.HTTP_200_OK,
        )

4. 응답 구조 변화

기존 응답

모든 데이터를 한꺼번에 반환:

[
    {
        "id": 1,
        "content": "리뷰 내용 1",
        "categories": "액션",
        "app_id": 12345
    },
    ...
]

개선된 응답

페이지네이션 메타데이터를 포함:

{
    "reviews": [
        {
            "id": 1,
            "content": "리뷰 내용 1",
            "categories": "액션",
            "app_id": 12345
        },
        ...
    ],
    "has_next": true,
    "current_page": 1
}

5. 장점

• 효율적인 데이터 로드: 요청마다 필요한 데이터만 반환하여 서버 부담을 줄이고 클라이언트의 로딩 시간을 단축
• 명확한 탐색 가능: 페이지 정보(current_page, has_next)를 제공하여 클라이언트가 다음 페이지 여부를 쉽게 판단
• 데이터 과다로 인한 성능 문제 방지: 대량의 데이터를 한꺼번에 보내는 일을 방지하여 서버와 클라이언트의 성능 최적화

• 요구사항: 리뷰 목록에서 특정 리뷰를 클릭했을 때, 게임 상세 페이지에서 해당 리뷰를 눈에 띄게 표시하고 나머지 리뷰와 구분하여 관리하고 싶었습니다.
• 현상: 기존 API 구조가 이를 지원하지 않았습니다. review_id를 통한 클릭한 리뷰의 강조가 필요하다고 생각했습니다.

해결

1. API 뷰 수정

   • 기존 뷰를 수정하여 review_id를 쿼리 파라미터로 받아 해당 리뷰를 강조(clicked_review)로 분리하여 동작하고자 설계했습니다.
   • 나머지 리뷰 목록에서 클릭한 리뷰를 제외하여 중복을 방지했습니다.

2. URL 수정

   • URL 패턴에서 game_id를 쿼리 파라미터로 처리하도록 변경했습니다.
   • 쿼리 형식: /api/game/?game_id={game_id}&review_id={review_id}

기존 코드

class GameDetailAPIView(APIView):
    """
    Game 상세 페이지 API
    """
    permission_classes = [AllowAny]

    def get(self, request, app_id):
        # Game 객체 가져오기
        game = get_object_or_404(Game, appID=app_id)

        # 리뷰 가져오기
        reviews = Review.objects.filter(app_id=app_id)
        my_review = None  # 기본값 설정

        # 사용자가 인증된 경우에만 자신의 리뷰 필터링
        if request.user.is_authenticated:
            my_review = reviews.filter(user_id=request.user.id).first()  # user_id로 매칭
            reviews = reviews.exclude(user_id=request.user.id)

        # 직렬화
        game_serializer = GameSerializer(game)
        my_review_serializer = ReviewSerializer(my_review) if my_review else None
        other_reviews_serializer = ReviewSerializer(reviews, many=True)

        return Response({
            "game": game_serializer.data,
            "my_review": my_review_serializer.data if my_review else None,
            "reviews": other_reviews_serializer.data
        })

수정된 코드

1. API 뷰 (views.py)

class GameDetailAPIView(APIView):
    """
    Game 상세 페이지 API
    """

    permission_classes = [AllowAny]

    def get(self, request):
        # 쿼리 파라미터에서 game_id와 review_id 가져오기
        game_id = request.query_params.get("game_id")
        review_id = request.query_params.get("review_id")

        # game_id가 없을 경우 에러 반환
        if not game_id:
            return Response({"error": "game_id is required."}, status=400)

        # Game 객체 가져오기
        game = get_object_or_404(Game, appID=game_id)

        # 리뷰 가져오기
        reviews = Review.objects.filter(app_id=game_id)
        my_review = None
        clicked_review = None

        # 사용자가 인증된 경우, 자신의 리뷰 필터링
        if request.user.is_authenticated:
            my_review = reviews.filter(user_id=request.user.id).first()
            reviews = reviews.exclude(user_id=request.user.id)

        # review_id가 있는 경우, 해당 리뷰를 clicked_review로 설정
        if review_id:
            try:
                clicked_review = reviews.get(id=review_id)
                reviews = reviews.exclude(id=review_id)
            except Review.DoesNotExist:
                clicked_review = None

        # 직렬화
        game_serializer = GameSerializer(game)
        my_review_serializer = ReviewSerializer(my_review) if my_review else None
        clicked_review_serializer = (
            ReviewSerializer(clicked_review) if clicked_review else None
        )
        other_reviews_serializer = ReviewSerializer(reviews, many=True)

        return Response(
            {
                "game": game_serializer.data,
                "my_review": my_review_serializer.data if my_review else None,
                "clicked_review": clicked_review_serializer.data
                if clicked_review
                else None,
                "reviews": other_reviews_serializer.data,
            }
        )

2. URL 패턴 (urls.py)

path("game/", views.GameDetailAPIView.as_view(), name="game_detail"),

테스트

요청 예시 1: 클릭한 리뷰가 있는 경우

• URL: /api/game/?game_id=12345&review_id=67890

응답 데이터:

{
    "game": {
        "id": 12345,
        "name": "Game Title",
        "description": "Game description..."
    },
    "my_review": {
        "id": 111,
        "content": "My review content...",
        "rating": 4
    },
    "clicked_review": {
        "id": 67890,
        "content": "This is the clicked review...",
        "rating": 5
    },
    "reviews": [
        {
            "id": 22222,
            "content": "Another review...",
            "rating": 3
        },
        {
            "id": 33333,
            "content": "Yet another review...",
            "rating": 4
        }
    ]
}

요청 예시 2: 클릭한 리뷰가 없는 경우

• URL: /api/game/?game_id=12345

응답 데이터:

{
    "game": {
        "id": 12345,
        "name": "Game Title",
        "description": "Game description..."
    },
    "my_review": {
        "id": 111,
        "content": "My review content...",
        "rating": 4
    },
    "clicked_review": null,
    "reviews": [
        {
            "id": 67890,
            "content": "Another review...",
            "rating": 5
        },
        {
            "id": 33333,
            "content": "Yet another review...",
            "rating": 4
        }
    ]
}

요약 표

API 명세서 링크

# steam_data.py 

import environ
import requests
from django.core.management.base import BaseCommand
from accounts.models import Account, SteamProfile, SteamReview, SteamPlaytime
from selenium import webdriver

class Command(BaseCommand):
    help = "전체 DB의 스팀 정보를 일괄 갱신"

    def handle(self, *args, **options):
        env = environ.Env()
        api_key = env("STEAM_API_KEY")
        accounts = Account.objects.exclude(steamId="")

        # WebDriver 준비
        driver = webdriver.Chrome()

        for account in accounts:
            # (A) 프로필 공개 여부 확인
            # (B) 리뷰, 플레이타임 조회
            # (C) SteamProfile/SteamReview/SteamPlaytime 저장
            # ...

        driver.quit()
        self.stdout.write(self.style.SUCCESS("Steam 데이터 처리 완료."))

기존 로직(전체 DB를 일괄 업데이트하는 커맨드)으로는 새로 가입한 유저가 스팀을 연동했을 때 즉각적으로 DB에 반영되지 않는 문제가 있었다. 이를 해결하기 위해 신규 유저가 스팀 계정을 연결하자마자 DB에 정보를 저장할 수 있도록 별도의 모듈 함수를 만들고 기존 회원가입 로직과 스팀콜백 로직에 반영하여 해결했다.

문제 상황 (Trouble)

1. 전체 일괄 업데이트 로직:

   • 기존에는 steam_data.py에 있는 Django Management Command를 통해, DB에 등록된 steamid가 필드에 존재하는 모든 유저를 한번에 스팀 정보(프로필, 리뷰, 플레이타임)를 갱신했다.
   • 이는 crontab을 이용한 정기적 작업이나 대규모 업데이트에는 유용하지만, ‘새 유저가 스팀을 방금 연동한 순간’에는 곧바로 DB에 반영되지 않는 문제가 있었다.
   • 새로 스팀 연동을 마친 유저 입장에선, 자기 스팀 리뷰나 플레이타임 정보를 즉시 확인하고 싶지만, 전체 작업이 실행될 때까지 기다려야 했다.

2. 즉각적 반영 불가:

   • 새 유저가 스팀 계정을 등록해도, 다음에 해당 커맨드를 수동/자동으로 실행하기 전까지 DB에 갱신된 정보가 들어오지 않는다.
   • 결과적으로, 사용자 경험(UX)이 떨어지고, “가입 시점에 곧바로 프로필·리뷰·플레이타임 확인” 같은 기능이 구현 어려웠다.

해결 방안 (Solution)

# steam_service.py

import environ
import requests
from django.db import transaction
from selenium import webdriver
from accounts.models import Account, SteamProfile, SteamReview, SteamPlaytime

def sync_new_steam_user_data(account):
    """
    새 유저(특정 account)에 대해 프로필/리뷰/플레이타임 정보를 즉시 DB에 반영.
    """
    # 1) Steam API 키 불러오기
    env = environ.Env()
    api_key = env("STEAM_API_KEY")

    # 2) 프로필 공개 여부 확인
    if not check_profile_public(api_key, account.steamId):
        # 비공개면 is_review=False, is_playtime=False
        sp, _ = SteamProfile.objects.get_or_create(account=account)
        sp.is_review = False
        sp.is_playtime = False
        sp.save()
        return

    # 3) 리뷰/플레이타임 조회
    # ...
    # 4) DB에 즉시 저장
    # ...

1. 단일 유저 대상 함수 sync_new_steam_user_data 생성:
   • steam_service.py로 별도 모듈을 만들고, sync_new_steam_user_data(account) 함수를 정의했다.
   • 이 함수는 단 한 명의 Account(특히 스팀 ID 보유)를 입력받아, 리뷰/플레이타임/프로필 공개 여부를 크롤링/조회 후 DB에 즉시 반영한다.
   • 기존 “전체 유저 갱신” 로직을 재활용해서, 개별 유저만 빠르게 처리 가능하도록 최적화했다.

@api_view(["POST"])
def signup(request):
            #...
            steam_id = request.data.get("steam_id")
            if steam_id:
                # DB에 리뷰공개 여부/플레이타임/리뷰 데이터 동기화 다음에 하기 할 때 제외하는 로직
                sync_new_steam_user_data(user)

            return

@api_view(["POST"])
def steam_callback(request):
            #...
            # DB에 리뷰공개 여부/플레이타임/리뷰 데이터 동기화
            sync_new_steam_user_data(account)

            return

2. View 에서 새 유저 연동 시점에 호출:

   • 새 유저가 회원가입 완료 후, 스팀 로그인 콜백 등을 통해 steamId를 등록하는 즉시, sync_new_steam_user_data(account)를 호출한다.
   • 결과: 스팀 프로필이 Public이라면, 즉시 리뷰·플레이타임을 DB에 저장. Private이면 is_review=False, is_playtime=False로 처리.
   • 사용자 입장에선, 연동 직후 리뷰 목록이나 플레이타임 정보를 볼 수 있게 된다.

3. 기존 커맨드(steam_data.py)는 유지:

   • 배치 작업 또는 정기 갱신 시에는 여전히 전체 DB를 순회할 수 있는 기존 커맨드를 사용.
   • 새 모듈(steam_service.py)과 커맨드에 있는 로직이 중복되지 않도록, 공통 함수를 활용하거나 로직 구조를 최대한 비슷하게 맞췄다.

요약

• 트러블: 기존엔 전체 DB 단위 배치만 존재해서, 새 유저가 스팀 연동해도 즉시 DB 저장이 불가능했다.
• 해결: 단일 유저용 함수를 만들어, 스팀 연동 순간 DB에 곧바로 반영하도록 개선했다.

수정 함으로써 신규 유저가 스팀을 연동하는 시점에 즉각적인 리뷰·플레이타임 DB 등록이 가능해졌다. 기존 배치 로직(전체 일괄 갱신)은 그대로 유지하되, 새로 가입한 유저에 대해서만 개별로 빠르게 동기화하는 최적화를 시행했다.

즉, 전체 업데이트용 커맨드와 신규 유저 즉시 반영용 서비스 함수를 동시에 운영함으로써, 기존 DB 갱신과 실시간 반영을 모두 처리할 수 있게 되었다.

문제

새 리뷰를 생성할 때, POST 요청에 포함된 content 값이 데이터베이스에 저장되지 않는 문제가 발생했습니다. 이와 동시에 차단된 사용자의 리뷰를 조회할 때 내용을 블러 처리하는 기능을 구현하려고 했습니다. 하지만 두 기능이 충돌하면서 아래와 같은 문제가 발생했습니다:

1. content 필드가 SerializerMethodField로 설정되어 있었습니다.
   • 문제: SerializerMethodField는 읽기 전용 필드로, 요청 데이터를 받아들이지 않기 때문에 새 리뷰 생성 시 content 값이 무시되었습니다.
2. 블러 처리 로직이 content 필드와 연결되어 리뷰 생성과 조회 기능 간의 혼란이 발생했습니다.
   • content 필드가 저장되지 않아 블러 처리 이전에 기본 동작부터 실패했습니다.

원인 분석

1. SerializerMethodField의 읽기 전용 특성

   • SerializerMethodField는 데이터를 직렬화할 때 get_<field_name> 메서드의 반환값만 사용하며, 모델 필드와 연결되지 않습니다.
   • 결과적으로, POST 요청에서 content 데이터를 저장하지 못했습니다.

2. 블러 처리와 데이터 저장의 충돌

   • content 필드를 블러 처리 로직과 동일하게 처리하려다 보니, 읽기와 쓰기가 충돌했습니다.
   • 블러 처리 로직은 데이터 조회 시 적용되어야 하지만, 데이터 저장 로직에 영향을 미쳤습니다.

해결 방안

1. 읽기와 쓰기를 분리

   • content 필드는 데이터 저장용으로 유지하고, 차단된 사용자 리뷰를 숨김 처리하는 블러 처리 로직은 content_display라는 추가 필드로 분리했습니다.
   • content: 원본 리뷰 데이터를 저장하고 반환.
   • content_display: 차단된 사용자의 리뷰 내용을 숨김 처리하여 반환.

2. 직렬화 및 로직 구현

   • content_display는 SerializerMethodField를 사용하여 읽기 전용으로 설정.
   • content는 모델 필드와 연결하여 리뷰 생성 시 데이터를 저장.

수정된 코드

1. ReviewSerializer

class ReviewSerializer(serializers.ModelSerializer):
    """Review 모델 직렬화"""
    nickname = serializers.SerializerMethodField()  # 사용자 닉네임 반환
    content_display = serializers.SerializerMethodField()  # 차단된 사용자 콘텐츠 처리
    comments = ReviewCommentSerializer(many=True, read_only=True)  # 연결된 댓글들
    total_likes = serializers.IntegerField(read_only=True)  # annotate로 계산된 값
    total_dislikes = serializers.IntegerField(read_only=True)  # annotate로 계산된 값
    game_name = serializers.CharField(read_only=True)
    header_image = serializers.CharField(read_only=True)


    class Meta:
        model = Review
        fields = [
            'id', 'user', 'nickname', 'content', 'content_display', 'app_id', 'game_name', 'header_image', 'score', 'categories',
            'created_at', 'updated_at', 'comments', 'total_likes', 'total_dislikes'
        ]
        read_only_fields = [
            'id', 'created_at', 'updated_at', 'comments', 'total_likes', 'total_dislikes', 'game_name', 'header_image', 'categories', 'content_display'
        ]

    def get_nickname(self, obj):
        """유저 닉네임 반환 (유저가 없으면 '알수없음')"""
        return obj.user.nickname if obj.user else "알수없음"

    def get_content_display(self, obj):
        blocked_users = self.context.get('blocked_users', [])
        if obj.user and obj.user.id in blocked_users:
            return "이 사용자의 리뷰는 차단되어 표시되지 않습니다."
        return obj.content

2. ReviewDetailAPIView

class ReviewDetailAPIView(APIView):
    def get(self, request, pk):
        """특정 리뷰 조회"""
        review = get_object_or_404(Review, pk=pk)
        blocked_users = Block.objects.filter(blocker=request.user).values_list('blocked_user', flat=True) if request.user.is_authenticated else []

        serializer = ReviewSerializer(review, context={'blocked_users': list(blocked_users)})
        return Response(serializer.data, status=status.HTTP_200_OK)

해결 결과

1. 리뷰 생성 시 content 저장 정상화

   • POST 요청 시 content 데이터가 Review 모델에 정상적으로 저장됩니다.

2. 블러 처리 기능 분리

   • content_display 필드가 차단된 사용자의 리뷰를 숨김 처리하여 반환합니다.
   • 원본 데이터(content)는 변경되지 않고, 필요할 때 블러 처리 로직만 동작합니다.

3. 코드의 명확성과 확장성 증가

   • 데이터 저장과 블러 처리 로직이 분리되어 각 기능이 독립적으로 유지됩니다.
   • 블러 처리 로직을 유저별로 다르게 설정하거나 조건을 추가하는 등의 확장이 용이해졌습니다.

1. 알림 유형 구분의 어려움:

   • 알림 유형을 숫자(int)로 관리하다 보니, 코드에서 의미를 직관적으로 파악하기 어려움
   • 예: type=1이 무엇을 의미하는지 명확하지 않음

2. 알림 상태 관리의 불편함:

   • 알림의 읽음 여부(is_read)를 별도로 관리하지 않아, 사용자가 읽은 알림을 처리하는 로직이 복잡해질 가능성이 있음

3. 확장성 부족:

   • 새로운 알림 유형을 추가하려면, 기존 코드의 모든 type 관련 부분을 수정해야 하는 구조적 문제가 있음

해결 방안

1. choices 필드를 활용한 유형 정의:

   • TYPE_CHOICES를 도입해 알림 유형의 의미를 명확히 하고, 새 유형 추가 시 수정 범위를 최소화
   • 각 알림 유형에 대해 상수(TYPE_GENERAL, TYPE_FRIEND_REQUEST 등)를 정의해 코드 가독성을 높임

2. 읽음 여부 관리:

   • is_read 필드를 추가해 알림의 상태를 관리
   • 사용자가 알림을 읽었는지 여부를 직관적으로 확인하고 처리할 수 있도록 개선

3. 모델 기본값 및 정렬:

   • type의 기본값을 지정하고, 생성일 기준 정렬을 기본으로 설정해 데이터 조회 성능 향상

최종 수정 모델

class Notice(models.Model):
    user_id = models.ForeignKey(
        settings.AUTH_USER_MODEL, on_delete=models.CASCADE, related_name="accounts"
    )
    TYPE_GENERAL = 1
    TYPE_FRIEND_REQUEST = 2
    TYPE_COMMENT = 3

    TYPE_CHOICES = [
        (TYPE_GENERAL, "일반 알림"),
        (TYPE_FRIEND_REQUEST, "친구 요청 알림"),
        (TYPE_COMMENT, "댓글 알림"),
    ]

    type = models.IntegerField(choices=TYPE_CHOICES, default=0)
    content = models.CharField(max_length=50)
    is_read = models.BooleanField(default=False) # 읽음 여부
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

변경

1. TYPE_CHOICES로 알림 유형 관리:

   • 숫자 값 대신 상수(TYPE_FRIEND_REQUEST 등)를 사용해 가독성을 높이고, choices를 통해 유효성을 보장.

2. is_read 필드 추가:

   • 알림의 읽음 여부를 쉽게 확인하고, 클라이언트와 서버 간 상태 동기화를 용이하게 만듦.

모델 변경에 따른 영향

1. 직렬화 코드 변경:

   • NoticeSerializer에서 추가적인 변경 없이 동작 가능:

     class NoticeSerializer(serializers.ModelSerializer):
         class Meta:
             model = Notice
             fields = ['id', 'type', 'content', 'is_read', 'created_at', 'updated_at']

   • get_type_display()를 활용하려면 추가 필드를 정의 가능:

     class NoticeSerializer(serializers.ModelSerializer):
         type_display = serializers.CharField(source="get_type_display", read_only=True)
     
         class Meta:
             model = Notice
             fields = ['id', 'type', 'type_display', 'content', 'is_read', 'created_at', 'updated_at']

2. 조회 및 업데이트 로직 변경:

   • 알림을 읽음 처리하거나 삭제하는 API를 간단하게 구현 가능:

     # 읽음 처리
     notice = get_object_or_404(Notice, id=notice_id, user_id=request.user)
     notice.is_read = True
     notice.save()

   • 읽은 알림 삭제:

     Notice.objects.filter(user_id=request.user, is_read=True).delete()

3. 확장성 향상:

   • 새로운 알림 유형 추가 시, TYPE_CHOICES에 값을 추가하기만 하면 쉽게 확장 가능:

     TYPE_LIKE = 4
     TYPE_CHOICES.append((TYPE_LIKE, "좋아요 알림"))

피드백

1. 가독성과 유지보수성:

   • choices와 상수를 활용하면 코드를 더 직관적이고 관리하기 쉽게 만들 수 있다

2. 데이터 상태 관리:

   • 상태 필드(is_read)를 추가해 클라이언트와 서버 간의 데이터 동기화가 원활해짐

3. 확장 가능성:

   • 구조적으로 개선된 모델은 새로운 요구사항이 추가되더라도 최소한의 수정만으로 대응할 수 있다

앞으로의 계획

실시간 알림 지원:

• WebSocket이나 Django Channels를 통해 알림을 실시간으로 전달하는 구조를 검토할 예정

• 상황: 초기에는 type 필드를 활용하여 요청 상태를 0(대기), 1(수락), -1(거절)로 관리하려 했습니다. 그러나 데이터베이스에 거절된 요청을 계속 유지하는 방식은 복잡성을 증가시키고, 성능 저하 가능성이 있었습니다

• 해결:

  1. 거절된 요청은 데이터베이스에서 삭제
  2. 요청 수락 시, 요청을 삭제하면서 Friend 모델에 친구 관계를 저장

• 변경 후 코드:

  if new_type == 1:  # 수락
      Friend.objects.create(user_id=request.user, friend_id=friend_request.user_id)
      Friend.objects.create(user_id=friend_request.user_id, friend_id=request.user)
      friend_request.delete()  # 요청 삭제
  elif new_type == -1:  # 거절
      friend_request.delete()  # 요청 삭제

2. 문제: 중복 요청 처리의 혼란

• 상황: 기존 요청이 거절(type=-1)된 상태에서 새로운 요청을 처리할 때, type 상태를 업데이트하는 방식이 프론트엔드와의 통신에 복잡함을 초래

• 해결:

  1. 모든 요청은 수락 또는 거절 시 삭제
  2. 새로운 요청은 언제든지 새롭게 생성 가능하도록 설계

• 변경 후 코드:

  def post(self, request):
      """친구 요청 생성"""
      friend_request, created = FriendRequest.objects.get_or_create(
          user_id=request.user, friend_id=friend,
          defaults={"type": 0}
      )
      if not created:
          return Response({"message": "이미 대기 중인 친구 요청이 있습니다."}, status=status.HTTP_400_BAD_REQUEST)

3. 문제: 요청 ID와 사용자 ID 혼동

• 상황: 프론트엔드에서 친구 요청을 수락/거절할 때 friend_request_id가 아닌 요청 보낸 사람의 user_id를 보내 혼란 발생

• 해결:

  1. friend_request_id를 요청 고유 식별자로 사용
  2. 프론트엔드가 GET 요청으로 받은 id를 그대로 PUT 요청에 사용하도록 설계

• 변경 후 코드:

  def put(self, request):
      """친구 요청 상태 변경"""
      friend_request = get_object_or_404(FriendRequest, id=request.data.get("friend_request_id"), friend_id=request.user)
      # 수락 또는 거절 처리

4. 문제: 친구 요청과 친구 관리 로직의 혼합

• 상황: 친구 요청(FriendRequest)과 실제 친구 관계(Friend) 로직이 혼재되어 있어 유지보수가 어려움

• 해결

  1. FriendRequestAPIView는 요청 생성/조회/상태 변경만 처리
  2. FriendAPIView를 별도로 만들어 친구 목록 조회 및 삭제 관리

• 변경 후 구조:

  class FriendRequestAPIView(APIView):
      # 친구 요청 생성, 조회, 수락/거절 처리
      ...
  
  class FriendAPIView(APIView):
      def get(self, request):
          """친구 목록 조회"""
          friends = Friend.objects.filter(user_id=request.user)
          ...
  
      def delete(self, request):
          """친구 삭제"""
          Friend.objects.filter(user_id=request.user, friend_id=request.data.get("friend_id")).delete()

최종 결과

• 변경된 로직은 다음과 같은 특징을 가집니다:
  1. 친구 요청과 친구 관리의 명확한 분리:
     • FriendRequestAPIView: 요청 생성, 조회, 상태 변경
     • FriendAPIView: 친구 목록 조회, 친구 삭제
  2. 거절된 요청 삭제:
     • 데이터베이스가 깔끔하게 관리되며 성능 최적화

배운 점

1. 데이터 설계는 유연하면서도 간단해야 함:
   • 복잡한 상태 관리(type=-1 유지)를 피하고 삭제를 통해 단순화.
2. 클라이언트와의 통신은 명확해야 함:
   • 고유 ID(friend_request_id)를 활용하여 혼란 방지.
3. 로직 분리는 유지보수의 핵심:
   • 친구 요청과 친구 관리를 명확히 분리하여 역할을 구체화.

처음에는 친구 요청과 친구 관리를 단순하게 처리하려 했으나, 구현 과정에서 여러 경우의 수를 고려해야 했습니다:

• 친구 요청 상태 관리 (type 필드):
  • type=0: 대기 중
  • type=1: 수락(친구 관계 형성)
  • type=-1: 거절
• 친구 요청과 친구 관리의 분리:
  • 친구 요청과 실제 친구 목록을 구분해 설계해야 함을 깨달았습니다.

2. 의사결정 변화

1. 친구 요청 상태 관리 방식

   • 초기 설계: type=-1로 상태를 유지하고 데이터베이스에 남겨두기.
     • 문제점: 거절된 요청이 데이터베이스에 쌓이면서 관리가 복잡해지고, 성능 저하 우려
     • 결정: 거절된 요청은 삭제하는 방식으로 변경

2. 친구 관계 형성

   • 초기 설계: type=1로 요청 상태를 업데이트한 뒤, 별도로 친구 관계를 처리하지 않음
     • 문제점: 요청 상태를 업데이트하는 것만으로는 명확히 친구 관계를 관리하기 어려움
     • 결정: 요청 수락 시 요청을 삭제하고, 별도의 Friend 모델로 관계 관리.

3. 중복 요청 방지

   • 초기 설계: type 상태를 활용해 요청을 중복 생성하지 않도록 함
     • 문제점: 같은 요청을 재활용할 경우 클라이언트와의 통신이 복잡해짐
     • 결정: 요청은 삭제하되, 언제든 새로운 요청을 생성 가능하도록 설계

4. 프론트엔드 연동 고려

   • 초기 설계: 프론트엔드에서 user_id 기반으로 요청 처리
     • 문제점: 여러 요청이 있을 경우 특정 요청을 구분하기 어려움
     • 결정: 요청 고유 ID(friend_request_id)를 사용해 명확히 처리

3. 최종 설계

1. 친구 요청 로직 (FriendRequestAPIView)

   • 친구 요청 생성:
     • 이미 친구이거나 대기 중인 요청이 있는 경우 요청 불가
   • 요청 조회:
     • 현재 사용자가 받은 대기 중 요청만 반환
   • 요청 상태 변경:
     • 수락 시:
       • 요청 삭제.
       • Friend 모델에 관계 생성
     • 거절 시:
       • 요청 삭제.

2. 친구 관리 로직 (FriendAPIView)

   • 친구 목록 조회:
     • 현재 사용자의 친구 목록 반환
   • 친구 삭제:
     • 양방향 관계를 모두 삭제

4. 배운 점

1. 로직을 명확히 분리해야 유지보수가 쉬움:

   • 친구 요청과 친구 관리를 분리하여 각각의 책임을 명확히 함

2. 데이터베이스 정리의 중요성:

   • 거절된 요청을 삭제하여 불필요한 데이터가 쌓이는 것을 방지
   • 삭제를 통해 요청을 재활용할 필요가 없으므로 로직 단순화

3. 프론트엔드와의 협업:

   • 고유 ID(friend_request_id)를 사용하여 요청을 명확히 처리함으로써 클라이언트와의 통신 간소화

4. 의사결정은 반복적이고 점진적인 과정:

   • 초기 설계에서 부족했던 부분들을 구현과 테스트 과정을 통해 보완

5. 개선 방향

1. 알림 기능 추가:
   • 친구 요청 수락/거절 시 알림을 통해 사용자 경험 개선
2. 친구 추천 기능:
   • 친구 목록을 기반으로 게임 추천 기능 구현

우리 프로젝트의 주요 요구사항 중 하나는 사용자가 차단한 유저의 리뷰를 블러 처리하는 기능이었습니다. 이 기능은 사용자 경험을 개선하기 위한 중요한 요소로, 리뷰를 조회할 때 차단된 사용자의 리뷰를 숨기거나 대체 메시지로 표시해야 했습니다.

구현 목표

1. 회원: 차단한 사용자의 리뷰를 블러 처리.
2. 비회원: 모든 리뷰를 정상적으로 표시.
3. 일관된 동작: 모든 리뷰 목록 조회 및 상세 조회 API에서 동일한 블러 처리 로직 적용.

구현 과정

1. 의사결정: Serializer 활용

리뷰를 블러 처리하기 위해 선택한 접근 방식은 Serializer를 활용하는 것이었습니다. 이 방법을 선택한 이유는 다음과 같습니다:

• 재사용성: 여러 View에서 동일한 ReviewSerializer를 사용하여 로직의 일관성을 유지할 수 있습니다.
• 간결성: Serializer는 데이터를 직렬화하는 과정에서 로직을 포함할 수 있으므로, 블러 처리 로직을 효율적으로 추가할 수 있습니다.

2. 블러 처리 로직 추가

ReviewSerializer에 다음과 같은 로직을 추가했습니다:

• SerializerMethodField:
  • content 필드를 오버라이드하여 블러 처리 여부를 결정.
• get_content 메서드:
  • 현재 사용자가 차단한 사용자의 리뷰인 경우 "이 사용자의 리뷰는 차단되어 표시되지 않습니다." 메시지를 반환.

ReviewSerializer 코드

class ReviewSerializer(serializers.ModelSerializer):
    content = serializers.SerializerMethodField()  # 블러 처리된 콘텐츠 반환
    nickname = serializers.SerializerMethodField()  # 사용자 닉네임 반환

    def get_content(self, obj):
        blocked_users = self.context.get('blocked_users', [])
        if obj.user and obj.user.id in blocked_users:
            return "이 사용자의 리뷰는 차단되어 표시되지 않습니다."
        return obj.content

3. View에서 context 전달

Serializer가 블러 처리 로직을 실행하려면, 차단된 사용자 목록(blocked_users)을 context로 전달해야 했습니다. 이를 위해 ReviewAPIView와 ReviewDetailAPIView에서 context를 설정했습니다.

ReviewAPIView 수정

class ReviewAPIView(APIView):
    def get(self, request):
        blocked_users = Block.objects.filter(blocker=request.user).values_list('blocked_user', flat=True) if request.user.is_authenticated else []
        reviews = Review.objects.all()
        serializer = ReviewSerializer(reviews, many=True, context={'request': request, 'blocked_users': list(blocked_users)})
        return Response(serializer.data, status=status.HTTP_200_OK)

트러블 슈팅

문제 1: 블러 처리가 작동하지 않음

증상: 차단된 사용자의 리뷰가 여전히 원본 내용으로 표시됨.
원인: SerializerMethodField를 누락하여 get_content 메서드가 호출되지 않음.
해결: content = serializers.SerializerMethodField()를 추가하여 get_content 메서드가 호출되도록 수정.

문제 2: 비회원의 경우 블러 처리 로직 동작

증상: 비회원 사용자가 조회했을 때도 블러 처리 로직이 작동.
원인: request.user.is_authenticated 검사를 누락.
해결: request.user.is_authenticated를 조건으로 추가하여 비회원 사용자는 블러 처리 로직을 무시하도록 수정.

def get_content(self, obj):
    if not self.context.get('request').user.is_authenticated:
        return obj.content
    ...

최종 결과

1. 블러 처리 성공: 차단된 사용자의 리뷰가 "이 사용자의 리뷰는 차단되어 표시되지 않습니다."로 표시됨.
2. 비회원 접근 처리: 비회원은 모든 리뷰를 원본 그대로 확인 가능.
3. 일관된 동작: 모든 View(API)에서 동일한 블러 처리 로직을 적용.

Block 기능

• 특정 유저를 차단하거나 차단 해제할 수 있도록 API를 제공
• 차단된 유저의 리뷰가 블러 처리되거나 제외됨
• 차단된 유저와의 채팅 제한

2. 의사결정 과정

2.1 차단 모델 설계

처음에는 Django의 Many-to-Many 필드를 사용하려고 했습니다. 하지만 아래와 같은 이유로 명시적인 Block 모델을 설계하기로 결정했습니다:

1. 추가 메타데이터 저장 필요성: 차단 시점(created_at)이나 차단 사유(reason)를 저장하려면 Many-to-Many 필드만으로는 한계가 있음
2. 명확한 관계 표현: blocker(차단자)와 blocked_user(차단된 사용자)의 비대칭적 관계를 명확히 하기 위해 중간 모델이 더 적합
3. 확장성: 추후 차단 상태 변경 이력 기록, 통계 분석 등의 기능을 고려

최종 모델

class Block(models.Model):
    blocker = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
        related_name="blocked_users"
    )
    blocked_user = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
        related_name="blocked_by_users"
    )
    created_at = models.DateTimeField(auto_now_add=True)

    class Meta:
        unique_together = [('blocker', 'blocked_user')]
        ordering = ['-created_at']

2.2 Serializer 필요 여부

초기에는 요청과 응답 데이터 처리를 위해 Serializer를 추가할지 고민했습니다. 하지만 구현 초기에 Serializer를 생략한 이유는 다음과 같습니다:

1. 단순한 데이터 처리:
   • 차단/차단 해제 요청은 단일 필드(blocked_user_id)로 이루어짐
   • 유효성 검증은 get_object_or_404로 충분히 처리 가능
2. 직렬화할 데이터가 적음:
   • 클라이언트에게 반환하는 데이터는 간단한 상태 메시지와 차단된 유저 목록

하지만, 추후 확장성을 고려하여 Serializer를 추가하는 방안을 열어둠

2.3 차단 로직 구현

APIView를 기반으로 차단, 차단 해제, 차단된 유저 목록 조회 기능을 구현했습니다.

주요 고려사항

1. 중복 차단 방지:
   • Block.objects.get_or_create를 사용하여 동일한 유저를 중복 차단하는 경우를 방지
2. 차단 해제 처리:
   • Block 레코드 삭제 시 삭제된 레코드가 없으면 적절한 에러 메시지를 반환
3. 목록 조회:
   • select_related를 사용해 쿼리 최적화를 고려

최종 뷰 코드

class BlockedUserAPIView(APIView):
    permission_classes = [IsAuthenticated]

    def get(self, request):
        blocked_users = Block.objects.filter(blocker=request.user).select_related('blocked_user')
        data = [{"id": block.blocked_user.id, "nickname": block.blocked_user.nickname} for block in blocked_users]
        return Response(data, status=status.HTTP_200_OK)

    def post(self, request):
        blocked_user_id = request.data.get("blocked_user_id")
        blocked_user = get_object_or_404(Account, id=blocked_user_id)
        block, created = Block.objects.get_or_create(blocker=request.user, blocked_user=blocked_user)
        if not created:
            return Response({"message": "이미 차단된 사용자입니다."}, status=status.HTTP_400_BAD_REQUEST)
        return Response({"message": "유저를 차단했습니다."}, status=status.HTTP_201_CREATED)

    def delete(self, request):
        blocked_user_id = request.data.get("blocked_user_id")
        blocked_user = get_object_or_404(Account, id=blocked_user_id)
        deleted, _ = Block.objects.filter(blocker=request.user, blocked_user=blocked_user).delete()
        if not deleted:
            return Response({"message": "차단된 유저가 아닙니다."}, status=status.HTTP_400_BAD_REQUEST)
        return Response({"message": "유저 차단을 해제했습니다."}, status=status.HTTP_204_NO_CONTENT)

2.4 리뷰 차단 처리

차단된 유저의 리뷰를 블러 처리하거나 목록에서 제외하는 방안을 결정했습니다.

방법

1. 블러 처리:
   • 리뷰 내용 직렬화 시, 차단된 유저의 리뷰라면 "차단된 사용자가 작성한 리뷰입니다."를 반환
2. 리뷰 제외:
   • ReviewAPIView에서 차단된 유저의 리뷰를 필터링

2.5 URL 구성

API 뷰를 다음 URL에 연결:

• GET /accounts/block/ : 차단된 유저 목록
• POST /accounts/block/ : 유저 차단
• DELETE /accounts/block/ : 유저 차단 해제

3. 테스트

POSTMAN을 사용하여 다음 시나리오를 테스트:

1. 유저 차단: 동일 유저 중복 차단 방지 확인
2. 유저 차단 해제: 차단되지 않은 유저 해제 시 에러 반환
3. 차단된 유저 목록 조회: 올바른 데이터를 반환하는지 확인

4. 느낀 점 및 개선 방향

• 현재의 단순 로직은 충분히 작동하지만, 차단 사유나 차단된 상태의 리뷰를 확인하는 버튼과 같은 추가 기능을 고민할 필요가 있음
• 추후 차단 상태를 기준으로 알림, 채팅 제한 기능을 확장할 계획