오늘 학습 내용 ✅

• 오늘의 목표

  • 질문등록 파트 api 구현
    • url이 본 api랑 겹치기 때문에 spec url 수정
  • 기능 테스트까지 완료
  • 가능하면 질문조회 specapi까지 작성 완료

SpecAPI 확장

      [요구사항 분석] → [Spec API 작성] → [Spec API를 팀에서 검토 · 확정] → [실제 기능 개발] →
                                                                   - Validation 
     [테스트 코드 작성] → [리뷰 → Merge]                                - 비즈니스 로직 
                                                                   - DB 처리

• SpecAPI 목적

  • 프론트엔드가 먼저 API 모양을 확인할 수 있게 하고
  • 팀원들이 Request/Response 형태를 합의하고
  • 실제 기능 개발 전에 오류를 줄이기 위해서
  • Swagger/OpenAPI 기반 문서 자동화에도 사용됨

• Spec API로 먼저 명세 작성 → 그걸 기반으로 실제 기능 개발

• 1. SpecAPI 단계 — “명세서(API Contract) 작성하기”

• 2. 실제 기능 개발 단계 — Spec을 기반으로 구현하기

  • Request 데이터 Validation 추가 (Serializer에서 처리)
  • 비즈니스 로직 수행 (DB 저장, 권한 체크 등)
  • Spec과 동일한 Response 형태로 응답

• 3. Test Code 작성

  • Spec API는 테스트 필요 없음 (Mock이니까)
  • 실제 기능 API는 반드시 테스트 필요
    • 정상 케이스 / 유효성 실패 케이스 / 권한 실패 케이스

---

test code

• Django TestCase + APIClient

---

새롭게 알게된 내용 ✅

원격에 푸시된 커밋을 “rebase 이후 내용으로 다시 푸시”하는 방법

# 1) develop 브랜치로 이동
git checkout develop

# 2) 최신 develop 가져오기
git pull origin develop

# 3) 다시 작업 브랜치로 이동
git checkout feature/브랜치명

# 4) develop 기준으로 rebase 수행
git rebase develop

# 5) conflict 있으면 해결 → add → 계속 진행
git add .
git rebase --continue

# 6) rebase 완료되면 강제로 push
git push origin feature/브랜치명 --force

• --force 가 필요한 이유

  • rebase는 커밋 hash 자체를 다시 만든다
  • 기존 remote 의 히스토리와 달라짐 그래서 일반 push는 안 되고 강제 push (--force) 필요

---

어려운 내용(추가 학습 필요) ✅

---

오늘 발생한 문제(발생 했다면) ✅

• python manage.py migrate 오류
  • psycopg2.errors.DuplicateTable: relation "users" already exists
• 원인 1 — DB는 초기화 안 됐는데, migrations는 초기 상태라고 생각함
  • DB 안에는 users 테이블이 이미 존재 (이전에 로컬에서 만듬)
  • 하지만 Django는 user 앱의 0001_initial을 처음 실행한다고 착각해서
    • 이미 존재하는 테이블을 또 만들려고 함
• 해결방법
  • 로컬 DB 완전 초기화 후 마이그레이션

docker compose -f docker-compose.local.yml down -v
docker compose -f docker-compose.local.yml up -d
python manage.py migrate

---

• 로컬에서는 poetry run black . 통과했지만 CI(GitHub Actions)에서는 black에 잡힘
• 원인
  • 로컬에서는 poetry run black .을 그냥 실행(자동 수정)
    • black이 자동으로 파일을 고쳐줌
    • 그래서 실행 후에는 모두 포맷이 맞음 → 성공
  • CI(GitHub Actions)에서는 poetry run black . --check
    • (수정하지 않고 "형식이 맞는지"만 검사) 를 실행
    • black이 자동 수정은 하지 않음, “어떤 파일이 수정되어야 하는지”만 검사
    • spec/views.py, models.py 두 파일이 black 규칙에 맞지 않음
• 해결방법

poetry run black .
git add .
git commit -m "chore: format code with black"
git push

---

• poetry run dmypy run -- . 오류
  • 테스트 함수는 반환값이 없으므로 -> None 추가

def create(self, validated_data):
			↓
from typing import Any, Dict

def create(self, validated_data: Dict[str, Any]) -> Question:

from rest_framework.request import Request
from rest_framework.response import Response

def post(self, request: Request) -> Response:

• 해결: 각각 타입 지정

---

• 문제: develop를 리베이스 하고나서 아래의 문장 뜸

You have 2 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): courses.

• 원인
  • 리베이스를 하면 develop 브랜치에 존재하는 모든 변경사항(코드 + 마이그레이션 파일)을
    • feature 브랜치에 재적용함
  • 로컬에서는 적용되지 않은 courses 앱의 마이그레이션 파일이 develop 브랜치에 존재했었기 때문에
    • 리베이스 과정에 그 파일이 내려온 것
• 해결
  • python manage.py migrate
  • 이미 develop 브랜치에 있는 migration이기 때문에 makemigrations는 안해도 됨
    • 오히려 하면 불필요한 migration 파일이 생길 가능성 있음
    • 팀 프로젝트에서 migration 충돌 위험 증가