2026/01/05 MainProject - 발표 / 마무리

김기훈·2026년 1월 5일

TIL

목록 보기

103/191

2025/12/05 ~ 2026/01/05

발표 준비 🟥

발표 내용 가이드

1. 의사결정 과정 (주제 선정 이유, 협업 방식, 미팅 로그 등)
1. 기획안 공유
1. 팀원 역할 분담
1. 랜딩 페이지 주요 기능 시연 (gif)
1. 프로젝트에서 만족 한 부분 (KEEP)
1. 잘 되지 않았거나 문제가 있었던 내용 (Problem)
1. 개선점 (Try)

PPT

훈련기관명
- 넥스트러너스
프로젝트의 제목
- “통합 교육 플랫폼(LMS) 개발 프로젝트”
프로젝트 소제목
- “커뮤니티 기능 담당 1팀”, “질의응답 기능 담당 2팀”
모든 팀원 명단 (FE | BE)
담당 멘토 (멘토링을 받지 않은 경우 생략 가능)

프로젝트 개요

익스턴십 기획 선정 배경
프로젝트 내용 (서비스 소개)
- 프로젝트 구현 내용, 목적, 컨셉 및 기능 구조 소개에 대해 작성하기
활용 장비 및 재료 (기술 스택)
- 개발환경 및 언어, 사용 한 프레임워크 소개 (아키텍처)
프로젝트 구조
- 프로젝트의 전반적인 기능 및 플로우에 대한 설명을 작성해 주세요.
활용방안 및 기대효과
- 프로젝트가 어떤 상황에서 활용될 수 있고, 기대되는 효과는 무엇인지 작성해 주세요.

팀 구성 및 역할

팀원 소개
- 프로제그에서 각 팀원이 맡은 주된 역할을 구체적으로 작성해 주세요
멘토 소개
- 담당 멘토님이 어떤 역할을 했는지

기억에 남는 트러블 슈팅

[ 🔴 문제: AttributeError: 'NoneType' object has no attribute 'method' ]
def get_authenticators(self):
    if self.request.method == "GET":
        return []
서버는 정상 실행은 되었지만 Swagger 페이지 접속 시 바로 에러 (딱 Swagger만 터짐 )

[ 🟡 원인: Swagger는 실제 HTTP 요청 없이 View를 분석하는데,
그 과정에서 self.request가 없는 상태로 get_authenticators()를 호출 ]

스웨거는 실제 http요청이 없어서 request 객체 생성안함 즉, self.request 없음 (None)
if self.request.method == "GET":
Swagger 시점에서 self.request == None 즉, 버그가 아닌 설계 문제 

get_authenticators()는 request가 항상 있다고 가정하면 안되는 메서드

[ 🔵 해결: None-safe 처리 ]
def get_authenticators(self):
    request = getattr(self, "request", None)
    if request and request.method == "GET":
        return []
    return super().get_authenticators()

Swagger 단계: request is None → 조건 통과 ❌ → 에러 ❌
실제 요청 단계: request 존재 → 정상 분기

get_authenticators를 오버라이딩해서 GET 요청일 때만 인증을 풀도록 구현했는데,
- 서버 API는 잘 동작하는데 Swagger 문서 페이지에 접속할 때만 500 에러가 발생했습니다.
AttributeError: 'NoneType' object has no attribute 'method'
- Swagger는 실제 HTTP 요청을 보내는 게 아니라, 뷰 클래스를 정적으로 분석해서 문서를 만드는 것이었습니다.
  - 실제 요청이 없으니 당연히 request 객체도 생성되지 않았기 때문에 500
이를 해결하기 위해 getattr을 사용하여 request 객체가 없을 때도 안전하게 넘어가도록
- None-safe 처리를 했습니다.
- 덕분에 문서 생성 단계와 실제 서비스 단계를 모두 만족시키는 방식을 알 수 있게 되었습니다.

특정 메서드(GET)에서만 인증을 제외하려고 코드를 짰는데,
- Swagger 페이지가 먹통이 되는 이슈가 있었습니다.
- 원인은 Swagger가 코드를 분석할 때는 실제 요청이 없어 request 객체가 None이라는 점을 몰랐습니다.
- request가 없으면 빈 리스트를 반환하지 않고 넘어가는 예외 처리를 추가하여 해결했습니다.
- 라이브러리가 내부적으로 어떻게 뷰를 분석하는지 이해하게 된 계기였습니다.

회고

여태 프로젝트를 진행하면서 거의 기능구현만을 목표로 했던것 같다.
하지만 이번 프로젝트를 진행하면서 질문 등록에 대한 기능구현을 완료하고 테스트까지 완료한 후애
기분좋게 첫 PR을 올리고 승인을 기다렸지만, 무수한 조교님과 코치님의 리뷰가 달렸다.
리뷰의 내용은 기능의 동작여부가 아닌 코드들의 위치였다.
나는 권한처리 / 유효성 검사 등등의 로직을 전부 view에 넣어버렸다.
- 그 결과 코드는 길어지고 가독성은 떨어졌다.
코치님과 조교님의 리뷰를 바탕으로 시간을 들여 역할분리에 대하여 공부를 하고 코드를 수정했다.
- permissions.py를 만들어 권한 로직을 위임하고
- 데이터 검증은 시리얼라이저에게 온전히 맡겼다
- 뷰는 이제 '요청을 받아 적절한 처리를 위임하고 응답을 주는' 교통정리 역할만 하게 되었다.
코드를 분리에 대하여 공부를 진행하고 실제로 수정까지 하고 나서 확인한 결과
- 역할 분리의 중요성 / 재사용성 / 유지보수 에 대하여 많은것을 배웠다.

회고 2

이번이 처음 프론트와 함께 진행한 프로젝트였는데 생각보다 양측의 대화가 전혀 없던것이 아쉬웠다.
서로 작업을 하다가 궁금한점 / 애매한 부분을 찾게 된다면 바로 의견을 주고받으면 좋을텐데
- 서로가 처음 합동 프로젝트를 진행하다보니 어떤식으로 해야하는지 적응하지 못한 느낌이다.
결과적으로 내가 구현한 기능대로 프론트가 만들어지지 않은점이 많은 아쉬움으로 남는다.
- 나는 카테고리 필터를 사용할때 대분류 / 중분류 / 소분류 전부 선택하지 않아도
- 대분류만 필터하거나 중분류까지만 필터를 진행해도 필터링이 가능하게 구현하였으나
  - 결과적으로 3가지의 카테고리를 전부 체크해야만 기능이 작동했다.
    - 이건 프론트팀분들의 능력여부와 관계없이 프론트팀원분들께
    - 이 코드에 대한 의도를 전하지 못했다는게 원인이라고 생각한다.
다음 마지막 프로젝트도 합동 프로젝트인데 이번에는 서로 대화를 많이 주고받으며
- 서로가 만족할만한 결과물이 나왔으면 좋겠다.