1. 프로젝트 개요

프로젝트 명: PP Project (PlayPalace)

기능

사용자 인증 기능

회원가입 기능: 새로운 사용자는 ID와 비밀번호를 이용해 서비스에 가입할 수 있다. 비밀번호는 암호화되어 저장된다.
로그인 및 로그아웃 기능: 사용자는 자신의 계정으로 서비스에 로그인하고 로그아웃할 수 있다.

프로필 관리

프로필 수정 기능: 사용자는 자신의 이름, 한 줄 소개 등의 기본 정보를 조회하고 수정할 수 있다. 비밀번호 수정 시에는 비밀번호를 한 번 더 입력받는 과정이 필요하다.

게시물 CRUD 기능

게시물 작성, 조회, 수정, 삭제 기능: 게시물 조회를 제외한 나머지 기능은 인가(Authorization) 개념이 적용되며, 이는 JWT와 같은 토큰으로 검증된다. 사용자는 자신이 작성한 글만 삭제할 수 있다.
게시물 작성, 수정, 삭제 시 새로고침 기능: 게시물 작성, 수정, 삭제를 할 때마다 조회 API를 다시 호출하여 최신의 게시물 내용을 화면에 보여준다.

뉴스 피드 기능

뉴스 피드 페이지: 사용자는 다른 사용자의 게시물을 한 눈에 볼 수 있는 뉴스 피드 페이지를 이용할 수 있다.

댓글 CRUD 기능

댓글 작성, 조회, 수정, 삭제 기능: 사용자는 게시물에 댓글을 작성하고, 자신이 작성한 댓글을 수정하거나 삭제할 수 있다. 인가(Authorization) 개념이 적용된다.
댓글 작성, 수정, 삭제 시 새로고침 기능: 댓글 작성, 수정, 삭제를 할 때마다 조회 API를 다시 호출하여 최신의 댓글 목록을 화면에 보여준다.

2. keep (제목 : 설명 느낌)

1 체계적인 Git 사용: Fork 기능을 처음 사용하면서도 이상 없이 잘 활용해, Git 관련 문제가 거의 발생하지 않았다.

2 역할 분담의 효율성: 각자 맡은 기능에 대해 책임감을 가지고 작업함으로써, 프로젝트 진행에 있어서의 효율성을 높였.

3 투명한 의사 소통 유지 : 각 팀원의 생각과 의견 명확하게 공유하여 다양한 의견 수렴 및 프로젝트 질 향상.

4 시간 존중 : 미팅 시간 정확히 지키고, 꾸준한 학습을 통해 개인 전문성 향상에 집중.

5 진행 상황 확인 : 정기적으로 프로젝트의 진행 상황 체크하여 필요한 점이나 개선 점 신속하게 파악 및 대응.

6 적극적인 자세 유지 : 현 상황에 확실히 알고 정확한 판단으로 팀이 함께 나아갈 방향 찾기

7 피드백 문화 구축 : 지속적인 피드백 공유를 통해 서로의 오류를 찾아주고 발전해 나아가는 문화 구축

8 목적 지향적인 커밋 관리: 기능별로 커밋을 관리하여, 프로젝트의 진행 상황을 명확하게 추적하고 관리할 수 있었다.

9 꾸준한 기록 유지: TIL 작성 및 오류 해결에 관한 기록하기

3. problem

백엔드와 프론트엔드 연결 시 발생하는 문제들
◦ 문제: 프로젝트에서 백엔드와 프론트엔드의 연동 과정에서 여러 기술적 문제가 발생했습니다. AJAX 요청 처리, 데이터 동기화, 인증 및 인가 처리 등에서 어려움
◦ 원인:

• 비동기 통신에서의 데이터 처리 미숙,
• JWT 인증 및 인가 로직의 복잡성,
• 프론트엔드와 백엔드 간의 인터페이스 불일치
  ◦ 해결 방안: 좀 더 공부하는게 답이긴하지만 백엔드에 좀더 집중하며 탐색

CRUD 기능 구현 중 데이터베이스 저장 문제
◦ 문제: 게시물 및 댓글의 CRUD 기능 구현 시 데이터베이스에 데이터가 제대로 저장되지 않는 문제가 발생
◦ 원인:

• 데이터 모델과 DTO 간의 매핑 오류
• 데이터베이스 연결 설정의 불안정성
• 예외 처리 미흡으로 인한 오류 발견 지연
• 해결 방안: 혼자만 고민하는 것이 아닌 내가 보지 못한 코드들을 볼수있도록 팀원과 문제상황 공유

테스트 부족으로 인한 기능 문제

• 문제: 프로젝트 종료 직전에 기능상 문제 발견.
• 원인: 개발 후 적절한 테스트 부족으로 인한 기능 검증 미흡.
• 해결 방안: 각 기능 구현 후 즉시 테스트 진행하여 문제점을 초기에 발견하고 수정.

깃 포크와 풀 리퀘스트 관리

• 문제: 풀 리퀘스트 후 바로 머지하는 과정에서 발생한 문제.
• 원인: 포크 설정과 코드 리뷰 과정의 체계적 관리 부족.
• 해결 방안: 풀 리퀘스트 시 코드 검토를 철저히 하고, 머지 전에 팀원 간의 리뷰와 승인 과정 강화.

API URL 주소 설정 문제

• 문제: API URL 주소 설정이 불완전하여 기능 구현에 장애 발생.
• 원인: 빠른 진행을 위한 서둘러진 결정 및 부족한 소통.
• 해결 방안: 중요한 설정 사항은 속도보다 정확성을 우선시하고, 팀원 간 충분한 소통과 합의를 통해 결정.

4. try

프로젝트를 진행하면서 여러 문제점들을 발견하게 되었습니다. 그럼에도 불구하고 팀원들은 상황을 개선하고 더 나은 협업 환경을 만들기 위해 다음과 같은 방안들을 시도했습니다.

백엔드와 프론트엔드 연결 개선을 위한 시도:

• AJAX 요청과 응답 처리 로직을 개선하여 데이터 처리의 정확성을 높임
• JWT 인증 및 인가 로직을 단순화하고 문서화하여 이해도를 향상시킴
• 프론트엔드와 백엔드 간의 API 명세를 명확히 하여 인터페이스 일치성 확보

주석 작성:

• 코드의 이해를 돕기 위해 모든 코드에 주석으로 설명 추가.

CRUD 기능의 데이터베이스 저장 문제 해결을 위한 시도:

• 데이터 모델과 DTO 간의 매핑 로직을 철저히 검토하고 테스트를 강화
• 데이터베이스 연결과 관련된 설정을 재검토하고 안정성을 개선
• 예외 처리 메커니즘을 강화하여 오류 발생 시 즉시 파악 및 대응 가능하도록 조치

기능 검증을 위한 체계적 테스트 도입

• Postman 또는 유사한 테스트 도구를 활용하여 개발된 기능의 정확성 검증.
• 개발된 기능에 대한 신뢰성 강화와 오류 최소화.

풀 리퀘스트 및 머지 과정의 효율적 관리

• 깃허브에서 풀 리퀘스트 승인 및 머지 시, 팀원과 함께 컨플릭트 해결 방법 논의.
• 코드 통합 과정에서 발생하는 문제를 최소화하고, 팀원 간의 협력 강화.

API 명세서 작성 및 소통 강화

• 프로젝트 초기에 각자 API 명세서 작성 후, 팀원들과 비교하며 소통하여 최종 명세서 결정.
• 백엔드와 프론트엔드 간의 인터페이스 일치성을 확보하고, 상호 이해도 향상.

5.각자의 느낀점

진유록

이번 프로젝트는 백엔드와 프론트엔드를 혼자서 처리하며, 전체적인 웹 개발 스킬을 다루는 큰 도전이었던것 같습니다. 특히, 게시물 및 댓글의 CRUD 기능에 인가 메커니즘을 적용하는 과정은 JWT 토큰을 활용하여 사용자의 권한을 검증하고 보안을 유지하는 데 많은 시간을 할애했습니다.
이 과정에서 백엔드 서버의 보안성과 효율성을 높이는 방법에 대해 깊이 고민하고 실제로 구현해보는 기회를 가졌습니다.프론트랑 연결은 힘들다...메모...

프론트엔드와의 연동은 또 하나의 큰 학습 곡선이었습니다. AJAX와 JavaScript를 활용해 비동기 통신을 구현하고, 사용자 경험을 고려하여 페이지 새로고침 없이 동적으로 컨텐츠를 업데이트하는 방법을 계획은 완벽했습니다...누구나 그럴싸한 계획은 있다..맞기전까지.... 게시물과 댓글을 작성하거나 수정, 삭제할 때마다 실시간으로 화면을 갱신하는 과정에서 프론트엔드 개발의 미묘한 부분들을 다루며 능숙해지고 샆었지만 결국 실패했습니다.

다른 팀원과의 백엔드 협업에서는, 코드의 통합과 버전 관리에 대한 중요성을 배웠습니다. Git을 사용한 버전 관리와 협업은 코드의 안정성을 보장하고, 변경 사항을 효율적으로 관리하는 데 큰 도움이 되었습니다. 또한, 문서화의 중요성을 깨닫고, RESTful API 설계에 대한 실습을 통해 백엔드 개발자로서의 협업능력을 한층 더 끌어올릴수 있었다고 보여집니다.

이 프로젝트를 통해, 백엔드와 프론트엔드의 전체적인 흐름을 이해하고, 두 영역 간의 연결점에서 발생할 수 있는 문제점들을 파악하고 해결하려고 이것 저것 시도해보며 많은것을 배웠습니다. 무엇보다, 문제에 직면했을 때 이를 해결하기 위한 독자적인 접근 방법과 해결책을 찾는 능력을 기를 수 있었습니다. 이러한 경험들은 향후 개발자로서의 경력에 있어 소중한 자산이 될 것입니다.

최재석

이번 프로젝트에서 저는 회원관련쪽(가입,로그인,회원정보수정,인증)쪽을 담당 했는데 저번 개인과제의 사항과 많이 비슷하지만 저번과 다르게 리프레시 토큰 방식,로그아웃,회원정보 수정을 추가 했습니다.
리프레시 토큰은 액세스 토큰이 만료일시 리프레시 토큰을 통해 액세스 토큰을 재발급 받도록 하는건데 코드 구현 작업 다 마치고 나서 왜 이렇게 했지? 생각든 부분이 있습니다.
일단 처음이라 액세스 재발급 받을때 직접 클라가 재발급 받는 url요청을 하도록 했는데 생각해보면 액세스 토큰 인증 필요한 api요청시 액세스 토큰 만료면 자동으로 리프레시 토큰 검사후 액세스 토큰 재발급 하는게 보통의 경우 아닌가? 생각 들어서 다음에도 리프레시 토큰 방식 한다면 이렇게 해볼겁니다!
그리고 로그아웃은 처음에 "Jwt는 서버에서 액세스 토큰의 정보를 저장하지 않고,액세스 토큰 정보 필요한 api요청시 토큰 검사후 시큐리티컨텍스트에 넣고 요청한 api작업이 끝나면 자동으로 시큐리티 컨텍스트에서 사라지는 방식인데 로그아웃이 존재하나??!" 생각이 들었는데
그래도 안전을 위해 리프레시 토큰만 로그아웃시 블랙리스트로 등록 하자해서 DB에 리프레시 토큰 정보 등록하는 방식으로 했습니다. 그리고 이부분을 알아보니 Redis라는 것을 사용한다는데 시간이 부족해서 일반 DB테이블을 이용했습니다.
이렇게 리프레시 토큰,로그아웃을 처음 도전해 보니 예외처리 해야 하는 경우가 좀 있어서 복잡했지만 JWT랑 시큐리티에 대해 다시 복습해서
저번 개인과제때보다 더욱 이해가 잘 됐고,회원 정보 수정쪽에서 변경시 왜 DB에 적용 안되나 문제 일어났는데 영속성 컨텍스트의 더티체킹쪽도
다시 복습하고 해결해서 이번엔 여러 가지 복습 위주를 한 것 같습니다.
예외로 저희팀은 애초에 다른팀과 다르게 저 포함 3명 이였는데 한분은 아프셔서 참여 못 하시고 2명에서 작업해서 선택이나 도전사항은 못하고
필수쪽만 했던게 약간 아쉽긴 했지만 둘이서만 이렇게 온 것도 잘 한 거구나 느꼈습니다.