플레이데이터 백엔드 9기 조석근님의 13주차 회고
한줄 요약 : 프로젝트 어렵다.
3rd 프로젝트 기간 : 6/12(월) ~ 6/16(월)
전반적인 프로젝트 구조
Q1. 이번 프로젝트는 어떤 아키텍처 구조로 구성되어 있나?
이번 프로젝트는 Spring Cloud 기반의 마이크로서비스 아키텍처(MSA)로 구성되어 있으며
전체 시스템은 여러 개의 독립적인 서비스(user-service, study-service, comment-service 등)로 분리되어 있으며,
각 서비스는 Eureka Discovery Server를 통해 등록되고, Gateway를 통해 외부 요청을 수신한다. 설정 관리는 config-server를 통해 중앙화했고,
인증/인가 기능은 JWT 기반으로 처리, 이를 통해 각 서비스 간의 높은 유연성과 확장성, 그리고 독립적 배포가 가능하도록 설계하였다.
Q2. 본인이 맡은 서비스는 어떤 역할은?
내가 맡은 서비스는 [study-service]이며, 그 중에서도 스터디 개설 및 관리 도메인을 담당하였다.
주요 기능은 스터디 모집글 생성, 수정, 삭제, 상세 조회 등이며, 이를 위한 [Study]와 [StudyStatus] 엔티티를 설계했다.
도메인 계층은 [DTO], [Entity], [Repository], [Service], [Controller]로 계층 분리하여 유지보수성과 가독성을 높였고,
JPA와 Spring Data JPA를 활용해 데이터 처리를 효율적으로 구현하였다.
Q3. StudyService 클래스에서 핵심 로직을 설명.
[StudyService]: 비즈니스 로직을 담당하는 Service 계층으로, 주요 메서드는 다음과 같다
[createStudy]: 사용자 요청을 받아 Study 엔티티로 변환하고 저장
[updateStudy]: 존재 여부를 확인하고, 필드를 업데이트
[deleteStudy]: 스터디 삭제나 실제 삭제 처리
[getStudyById]: 특정 스터디의 상세 정보 조회
모든 로직은 예외 상황에 대비하여 StudyNotFoundException, StudyInvalidRequestException 등 커스텀 예외 처리도 함께 구현하였다.
Q4. Study와 StudyStatus는 어떤 관계이며, 왜 분리했나?
Study는 모집글 자체의 정보(제목, 설명, 카테고리 등)를 관리하고,
StudyStatus는 특정 사용자가 해당 스터디에서 어떤 상태인지(승인/대기/거절)를 관리한다.
이 둘은 성격이 다르기 때문에 분리했고, StudyStatus는 @ManyToOne 관계로 Study에 연결된다.
이를 통해 참여자 정보를 유연하게 확장하거나 관리할 수 있다.
Q5.Swagger와 Postman의 차이점은?
Swagger는 API 문서를 자동화하고, API 요청도 테스트할 수 있는 도구이다. Postman은 요청을 직접 작성해 테스트하는 데 더 특화되어 있고,
다양한 환경 설정과 테스트 케이스 관리가 쉽다. 프로젝트 초기에는 Swagger 설정보다 빠른 테스트가 중요했고,
Postman이 팀원 간 공유와 반복 테스트에 더 유용해서 사용하였다. 추후엔 Swagger 적용도 고려 예정.
Q6. 이번 프로젝트를 통해 배운 점은 무엇인가?
이번 프로젝트를 통해 MSA 아키텍처의 흐름, 그리고 Controller → Service → Repository 계층 구조를 체계적으로 익힐 수 있었다.
또한 Git 협업, API 문서화, DTO 분리, 예외 처리 등 실무에서 꼭 필요한 백엔드 개발 전반을 경험했고,
인증/인가 구조와 마이크로서비스 간 통신 방식에 대한 이해도가 크게 향상되었다.
무엇보다 실무처럼 팀 단위로 도메인을 나누어 맡아보며, 책임감 있게 기능을 구현하고 협업하는 능력을 키운 계기가 된것같다.
1. 좋았거나 내가 잘한 점
이번 프로젝트에서 나는 CRUD 기능 구현을 맡아 작업했다. JWT 인증 토큰, Spring Security, 서버 인증/인가 등
보안 관련 영역은 솔직히 아직 내게는 부담스러운 영역이었다. 그래서 이번에는 아예 손도 대지 않았다.
하지만 프로젝트를 시작하기 전부터 혼자서 강의와 책을 통해 공부한 시간들이 헛되지 않았다는 걸 느꼈다.
덕분에 프로젝트 구조나 코드 흐름이 한눈에 이해가 되었고, 팀원들의 작업 내용을 따라가는 데 큰 무리가 없었다.
이건 확실히 혼자 공부한 효과가 드러난 순간이었다. 이제 다음 단계는 명확하다.
내일부턴 본격적으로 서버 구현과 인증/보안에 대한 공부에 집중할 예정이다.
아직은 어렵게 느껴지지만, 이번 프로젝트처럼 계속 도전하다 보면 익숙해질 거라 믿는다.
2. 아쉬웠던 점
다만, 기획 단계의 미숙함은 여전히 아쉬움으로 남는다.
초반에 전체적인 설계 방향을 제대로 잡지 못해 중간중간 팀원들과의 소통이 매끄럽지 않은 부분도 있었다.
다음 파이널 프로젝트에서는 기획에 훨씬 더 많은 시간과 에너지를 쏟아야겠다고 느꼈다. 이번에 다양한 기획서 양식을 접하고 수집할 수 있었던 것은
큰 수확이었다. 다음 프로젝트에서는 그 자료들을 십분 활용해 체계적인 기획을 바탕으로 개발을 이끌어가는 것이 핵심이 될 것 같다.
3. 개선할 점
그리고 벌써 3개월이라는 시간이 흘렀다. 이제는 슬슬 파이널 프로젝트와 취업 준비라는 두 과제를 눈앞에 두고 있다.
막연히 바라보던 목표가 점점 현실로 다가오고 있다는 걸 느끼는 요즘이다. 앞으로는 더 실전적인 기술과 문제 해결 능력을 키우고,
부족한 부분은 하나씩 메워나가는 시간이 되어야 할 것 같다. Git Hub Main에 올라온 코드들을 Clone 해서 재 수정 하면서 리마인드가 필요할것 같다.
마지막으로 이번 프로젝트에서 느낀 경험과 아쉬움 모두를 다음 도약의 발판으로 삼을 것이다.
4. 다음 주 계획
- 정처기 실기 공부
- 서버 구현, JWT TOKEN, Security 공부
5. 주말 간 계획
☆★ 차주의 각오 ☆★
11주차도 화이팅.
석근님의 더 많은 이야기가 궁금하다면?
👉플레이데이터 백엔드 9기 조석근님의 블로그에서 확인해보세요!🚀 [ 블로그 바로가기 ]
3rd 프로젝트 기간 : 6/12(월) ~ 6/16(월)
전반적인 프로젝트 구조
Q1. 이번 프로젝트는 어떤 아키텍처 구조로 구성되어 있나?
이번 프로젝트는 Spring Cloud 기반의 마이크로서비스 아키텍처(MSA)로 구성되어 있으며
전체 시스템은 여러 개의 독립적인 서비스(user-service, study-service, comment-service 등)로 분리되어 있으며,
각 서비스는 Eureka Discovery Server를 통해 등록되고, Gateway를 통해 외부 요청을 수신한다. 설정 관리는 config-server를 통해 중앙화했고,
인증/인가 기능은 JWT 기반으로 처리, 이를 통해 각 서비스 간의 높은 유연성과 확장성, 그리고 독립적 배포가 가능하도록 설계하였다.
Q2. 본인이 맡은 서비스는 어떤 역할은?
내가 맡은 서비스는 [study-service]이며, 그 중에서도 스터디 개설 및 관리 도메인을 담당하였다.
주요 기능은 스터디 모집글 생성, 수정, 삭제, 상세 조회 등이며, 이를 위한 [Study]와 [StudyStatus] 엔티티를 설계했다.
도메인 계층은 [DTO], [Entity], [Repository], [Service], [Controller]로 계층 분리하여 유지보수성과 가독성을 높였고,
JPA와 Spring Data JPA를 활용해 데이터 처리를 효율적으로 구현하였다.
Q3. StudyService 클래스에서 핵심 로직을 설명.
[StudyService]: 비즈니스 로직을 담당하는 Service 계층으로, 주요 메서드는 다음과 같다
[createStudy]: 사용자 요청을 받아 Study 엔티티로 변환하고 저장
[updateStudy]: 존재 여부를 확인하고, 필드를 업데이트
[deleteStudy]: 스터디 삭제나 실제 삭제 처리
[getStudyById]: 특정 스터디의 상세 정보 조회
모든 로직은 예외 상황에 대비하여 StudyNotFoundException, StudyInvalidRequestException 등 커스텀 예외 처리도 함께 구현하였다.
Q4. Study와 StudyStatus는 어떤 관계이며, 왜 분리했나?
Study는 모집글 자체의 정보(제목, 설명, 카테고리 등)를 관리하고,
StudyStatus는 특정 사용자가 해당 스터디에서 어떤 상태인지(승인/대기/거절)를 관리한다.
이 둘은 성격이 다르기 때문에 분리했고, StudyStatus는 @ManyToOne 관계로 Study에 연결된다.
이를 통해 참여자 정보를 유연하게 확장하거나 관리할 수 있다.
Q5.Swagger와 Postman의 차이점은?
Swagger는 API 문서를 자동화하고, API 요청도 테스트할 수 있는 도구이다. Postman은 요청을 직접 작성해 테스트하는 데 더 특화되어 있고,
다양한 환경 설정과 테스트 케이스 관리가 쉽다. 프로젝트 초기에는 Swagger 설정보다 빠른 테스트가 중요했고,
Postman이 팀원 간 공유와 반복 테스트에 더 유용해서 사용하였다. 추후엔 Swagger 적용도 고려 예정.
Q6. 이번 프로젝트를 통해 배운 점은 무엇인가?
이번 프로젝트를 통해 MSA 아키텍처의 흐름, 그리고 Controller → Service → Repository 계층 구조를 체계적으로 익힐 수 있었다.
또한 Git 협업, API 문서화, DTO 분리, 예외 처리 등 실무에서 꼭 필요한 백엔드 개발 전반을 경험했고,
인증/인가 구조와 마이크로서비스 간 통신 방식에 대한 이해도가 크게 향상되었다.
무엇보다 실무처럼 팀 단위로 도메인을 나누어 맡아보며, 책임감 있게 기능을 구현하고 협업하는 능력을 키운 계기가 된것같다.
1. 좋았거나 내가 잘한 점
이번 프로젝트에서 나는 CRUD 기능 구현을 맡아 작업했다. JWT 인증 토큰, Spring Security, 서버 인증/인가 등
보안 관련 영역은 솔직히 아직 내게는 부담스러운 영역이었다. 그래서 이번에는 아예 손도 대지 않았다.
하지만 프로젝트를 시작하기 전부터 혼자서 강의와 책을 통해 공부한 시간들이 헛되지 않았다는 걸 느꼈다.
덕분에 프로젝트 구조나 코드 흐름이 한눈에 이해가 되었고, 팀원들의 작업 내용을 따라가는 데 큰 무리가 없었다.
이건 확실히 혼자 공부한 효과가 드러난 순간이었다. 이제 다음 단계는 명확하다.
내일부턴 본격적으로 서버 구현과 인증/보안에 대한 공부에 집중할 예정이다.
아직은 어렵게 느껴지지만, 이번 프로젝트처럼 계속 도전하다 보면 익숙해질 거라 믿는다.
2. 아쉬웠던 점
다만, 기획 단계의 미숙함은 여전히 아쉬움으로 남는다.
초반에 전체적인 설계 방향을 제대로 잡지 못해 중간중간 팀원들과의 소통이 매끄럽지 않은 부분도 있었다.
다음 파이널 프로젝트에서는 기획에 훨씬 더 많은 시간과 에너지를 쏟아야겠다고 느꼈다. 이번에 다양한 기획서 양식을 접하고 수집할 수 있었던 것은
큰 수확이었다. 다음 프로젝트에서는 그 자료들을 십분 활용해 체계적인 기획을 바탕으로 개발을 이끌어가는 것이 핵심이 될 것 같다.
3. 개선할 점
그리고 벌써 3개월이라는 시간이 흘렀다. 이제는 슬슬 파이널 프로젝트와 취업 준비라는 두 과제를 눈앞에 두고 있다.
막연히 바라보던 목표가 점점 현실로 다가오고 있다는 걸 느끼는 요즘이다. 앞으로는 더 실전적인 기술과 문제 해결 능력을 키우고,
부족한 부분은 하나씩 메워나가는 시간이 되어야 할 것 같다. Git Hub Main에 올라온 코드들을 Clone 해서 재 수정 하면서 리마인드가 필요할것 같다.
마지막으로 이번 프로젝트에서 느낀 경험과 아쉬움 모두를 다음 도약의 발판으로 삼을 것이다.
4. 다음 주 계획
- 정처기 실기 공부
- 서버 구현, JWT TOKEN, Security 공부
5. 주말 간 계획
☆★ 차주의 각오 ☆★
11주차도 화이팅.
석근님의 더 많은 이야기가 궁금하다면?
👉플레이데이터 백엔드 9기 조석근님의 블로그에서 확인해보세요!🚀 [ 블로그 바로가기 ]