Playlist - 개인 개발 리포트

고급 - 개인 개발 리포트

---

 

1. 프로젝트 개요

• 제목 : 모두의 플리
• 부제 : 대규모 트래픽이 예상되는 글로벌 컨텐츠 평점 및 큐레이션 플랫폼
• 소개 : 영화, 드라마, 스포츠 등 다양한 콘텐츠를 큐레이팅하고 공유하며, 실시간 같이 보기 기능까지 제공하는 소셜 서비스로, 사용자들은 자신만의 플레이리스트를 만들고, 다른 사용자와 소통하며 콘텐츠 경험을 확장할 수 있는 서비스

 

---

 

2. 핵심 기능 : 

• 사용자 관리
  •  소셜 로그인 연동을 통한 간편한 회원가입 시스템
• 콘텐츠 데이터 관리
  • 외부 Open API 연동을 통해 대량의 컨텐츠를 배치 기반으로 수집 및 관리
• 콘텐츠 평가 및 큐레이팅
  • 콘텐츠 평점 및 의견 작성을 통한 컨텐츠 평가 기능
  • 개인 플레이리스트 생성 및 사용자간 플레이리스트 구독을 통해 공유 가능
• 실시간 같이 보기
  • 웹소켓 기반 사용자 정보, 시청 세션 실시간 확인 기능 및 실시간 채팅
• 프로필 관리
  • 사용자 프로필 조회를 통한 현재 시청중인 콘텐츠 / 플레이리스트 / 구독 정보 확인 기능
  • 웹소켓, SSE 기반 사용자간 실시간 채팅 기능
• 알림
  • SSE 기반 알림 기능
    • 권한 변경 / 팔로우, 구독 / 플레이리스트 변경 / DM 수신 / 사용자 활동과 같은 다양한 기능

 

---

 

3. 담당한 작업

• 관리자 권한을 통한 콘텐츠 데이터 관리 기능
  • 콘텐츠 데이터 등록(썸네일, 이름, 설명, 타입, 태그)
  • 모든 콘텐츠 데이터 수정 기능
  • 모든 콘텐츠 데이터 삭제 기능(플레이리스트, 리뷰와 연동하여 함께 삭제)
• WebClient 기반 Open API 연동
  
  • TMDB API : 영화,  드라마 콘텐츠 수집
  • The Sports DB API : 스포츠 경기 콘텐츠 수집
• Spring Batch 기반 배치 작업 관리
  • 관리자가 등록하는 콘텐츠 데이터를 제외한 모든 콘텐츠 데이터를 Spring Batch를 통해 관리
  • Spring Actuator를 통한 실시간 모니터링 기능

 

 

---

 

4. 기술적 성과

• 기술 스택
  • Bean Validation을 활용한 입력 데이터 유효성 검사
  • 구조적 커스텀 예외 설계를 통한 체계적인 애플리케이션 오류 관리
  • MDC를 활용한 요청 단위 로깅(요청 ID, IP 기록) 및 응답 헤더 반영
  • 테스트 주도 개발(TDD)을 통한 Red-Green-Refactor 사이클을 준수하여 코드 구현, 단계별 커밋 메시지 관리
  • JaCoCo를 활용한 테스트 커버리지 관리
  • Git Actions를 활용한 CI/CD 파이프라인 구축
  • PR 생성 시 자동 테스트 커버리지 검증, 파이프라인을 통한 AWS 자동 배포
  • Spring Batch를 통한 모든 콘텐츠 데이터 및 플레이리스트 관리
  • Spring Actuator를 통해 배치 작업의 커스텀 메트릭 정의 및 모니터링
  • Docker Compose를 활용하여 로컬 환경에서 다중 서비스로 구성된 분산 환경 구축 및 테스트
• 주요 구현 기능
  • 사용자 관리 및 인증 : 회원가입, 로그인, JWT 기반 인증/인가, 소셜 로그인 연동(Google, Kakao), 계정 잠금 / 권한 변경
  • 프로필 및 소셜 기능 : 프로필 조회 / 수정, 팔로우 / 언팔로우, 실시간 활동 정보 확인
  • 콘텐츠 평가 및 큐레이팅 : 큐레이션 생성 / 관리, 플레이리스트 구독, 평가 / 평점 작성 기능
  • 콘텐츠 수집 및 관리 : TMDB / SportsDB Open API 연동, Spring Batch 기반 콘텐츠 자동 수집 / 갱신
  • WebSocket 기반 실시간 기능 : 콘텐츠 실시간 시청 공유, 실시간 채팅, DM 실시간 메시지 송수신
  • SSE 기반 알림 시스템 : 팔로우 / 구독 / DM / 콘텐츠 활동 등 다양한 이벤트 알림 제공
  • 인프라 : 커서 기반 페이지네이션, 정렬, 캐싱 전략, 로깅 정책, 데이터 보존 및 운영 환경 구성

---

 

5. 문제점 및 해결 과정

• 느낀 점

 초급, 중급을 거쳐 고급 프로젝트를 진행하며 전체적인 작업 분위기가 정적으로 변했다는 것을 느꼈습니다. 이는 단순히 경직되었다는 느낌이 아닌  '정제'되었다는 느낌에 가깝습니다. 필요한 부분은 무엇이며 버려야 할 것은 어떠한 것인지  명확하게 파악하고 진행하는 과정에서 제대로 따라가는 제가 있었습니다. 상류에서부터 유유히 흐르는 강물처럼 천천히, 하지만 제대로 된 방향으로 빠르게 가는 것처럼 주어진 요구사항을 팀원과 분업을 통해 작업했습니다.

 일련의 과정에서 팀원간 트러블이 없었던 것은 아닙니다. 보이지 않는 갈등도 분명 있었으며 서로 작업하는 과정에서 불편하지 않은 부분이 없진 않았을 것입니다. 저 또한 마찬가지였습니다. 팀원이지만 사람들이며 나와는 다른 스타일, 습관 등이 주요한 원인이들이라고 생각합니다. 웹 개발자로서 논리적으로 작성하는 능력, 스프링 활용법을 익힌 뒤에는 이러한 부분들이 더욱 크게 다가왔습니다. 같은 소프트웨어와 언어를 함께 사용하지만, 각자가 받아들이는 방식은 다르니까요. 저는 이 부분을 이번 프로젝트에서 가장 커다란 과제라고 여겼습니다. 자연스러운 팀플레이를 어떻게 이어갈 것인가?

 결과적으로 저는 이 문제를 해결하는 데 실패했습니다. 고급 프로젝트라는 이름 아래에 주어진 요구사항을 나만의 힘으로 해내겠다는 욕심이 일을 그르쳤습니다. 팀 전체 분위기가 내려앉은 것을 깨달았으며 이는 근본적으로 팀플레이와 동떨어지는 행동이었다는 것을 뒤늦게 알았습니다. 요구사항을 풀어가는 데 작고 커다란 이슈들이 있었지만, 이를 공유하지 않고 혼자 해결하는 제가 있었고 팀원들과 소통도 자연스럽게 멀어졌습니다. 이렇게 시간이 지나간다면 저는 이전과 같은 사람이 되는 것입니다. 이 스프린트를 완주한 이유가 없어지는 것입니다.

 프로젝트 중후반에 이를 깨달은 저는 방향을 크게 틀었습니다. 팀원과 적극적으로 소통하기 위해 과제를 진행하며 사소한 이슈, 행동, 커밋 하나, PR 하나도 공유하며 행동했습니다. 이런 작은 행동들이 작지만 매우 커다란 변화를 주었다는 것을 깨달았습니다. 전체적인 팀 분위기가 다시금 바뀌었고 팀원들의 이슈도 알아가며 프로젝트 상황을 이해할 수 있게 되었으며, 내가 현재 어디까지 진행했는지 공유함으로 팀원들도 내 상황을 파악할 수 있게 되었습니다.

 이번 프로젝트를 통해 단순한 커밋, PR을 통한 이슈 공유가 아닌 상호간의 교류를 통한 소통이 더욱 중요하다는 것을 깨달았습니다. 분명 우리는 백엔드 개발자가 될 것이며 반드시 그렇게 될 것이지만, 근본적으로 사람과 사람간의 '협업'이다보니 갈등은 생기기 마련이고 충돌은 피할 수 없으며 피하면 오히려 독이 되어 더욱 커다란 문제로 번질 수 있습니다.

 개발자는 새로운 로직을 꾸준히 생각하는 사람이고, 문제를 해결하는 사람입니다. 논리적인 생각을 근간으로 개발력과 문제해결 능력이 뛰어난 능력은 중요합니다. 하지만 그 전에 사람은 서로를 의존하며 살아가는 것이 당연하며, 가장 아름답다고 생각합니다. 이러한 생각이 현실로 다가와 사실이 되는 순간이 바로 이번 프로젝트였으며, 이번 스프린트였습니다.

 

• 배운 점

 기술적으로는 기업이나 데이터를 수집하는 곳에서 만든 API를 다루는 법에 대해 익숙해졌습니다. json을 분석하여 어떠한 기술을 사용할 것인지에 대한 생각을 떠올렸으며, 이를 실천했습니다.

 Spring Batch에 대한 제 이해도도 높아졌습니다. '배치'에 대한 이해부터 단순 스케줄링과의 차이, 그리고 스케줄링에서 배치로 이어지는 일련의 과정을 직접 작업하며 브라우저 - API - 서비스 - DB로 이어지는 로직이 머릿속에서 관통하며 프론트엔드와 백엔드의 데이터 흐름을 깨닫고 머릿속에 자리잡았습니다.

 하지만 이보다 중요한 점은 협업하는 과정에서 팀원과의 소통은 꾸준히 진행해야하며, 이슈는 사소한 것이라도 공유해야하며, 이 일련의 과정은 귀찮은 것이 아닌 자연스럽게 이루어져야 하는 사람간의 관계가 개발자 사이에서도 이루어져야 한다는 것을 깨달은 것입니다. 인생에서 가장 중요한 것 중 하나를 얻어갑니다.

 

• 피드백

  팀 컨벤션을 준수하기 위해 많은 노력을 기울였습니다. 초급, 중급 프로젝트에서는 notion이나 git 사용법도 제대로 알지 못해 컨벤션이 엉망진창이었지만 이번 고급 프로젝트는 특히 이 부분을 신경써서 팀원간 통일성을 중시했습니다. 이를 통해 팀원간 피드백과 문서 관리가 편해졌으며 전체적인 팀 과제를 진행함에 있어 이슈에 대한 명제를 명확하게 파악할 수 있었습니다.

 팀원과 공유하는 공간도 주기적으로 확인했고, 이슈가 생기면 즉각적으로 반응했습니다. 비록 많은 도움이 되지 않을 수 있지만 이러한 행동 자체가 팀원들의 짐을 덜어 줄 것이라고 기대했으며 실제로 제 마음 또한 한결 가벼워졌습니다. 멀리 있지만 팀원과 함께 한다는 기분을 몸소 느낄 수 있게 되었습니다. 하지만 이러한 노력은 커뮤니케이션의 '기본'이 되어야 합니다. 이를 넘어 반응뿐만이 아닌 과정에서의 문제를 공유한 것에 대한 이해, 그리고 이와 관련하여 내 직무에는 어떠한 영향이 있는지 서로 공유해야 합니다. 사람은 잘 바뀌지 않는다지만, 이때까지의 제 노력을 되돌아면 충분히 할 수 있을 것이라는 자신감이 듭니다.

 

---

 

6. 코드 품질 및 최적화

 프로젝트를 진행하며 제가 구현한 것들을 잘게 쪼개서 커밋 횟수를 늘려 분석 및 리뷰를 용이하게 했습니다. PR 과정에서 내가 어떤 것을 구현했는지, 그 과정은 어떠했는지를 커밋을 통해 구현함으로 나는 물론이고 팀원들도 보기 편하게끔 구성했습니다.

 내가 어떤 메서드를 어떠한 의도로 작성했는지, 객체는 어떤 용도로 만들었는지를 명확하게 하기 위한 네이밍 신경을 많이 썼습니다. 조금 길어지더라도 '이 메서드는 이렇게 쓰는 거구나' 를 확실하게 하기 위해 노력했습니다. 이를 통해 콘텐츠를 외래키로 갖는 다른 엔티티 개발자 분들로 하여금 인터페이스를 편하게 하여 팀원간 이슈를 줄였을 것이라 기대합니다.

 클래스, 메서드간 책임을 최소한으로 하기 위해 노력했습니다. 핸들러 - 서비스 - DB 세 부분에 걸쳐 로직을 짜는 과정에서 면밀하게 과정을 분석하고, 역할 분담을 명확하게 하였습니다. 이로 인해 문제가 발생했을 때 빠른 피드백이 가능했으며 추후 리팩토링 과정도 굉장히 수월하게 이루어졌습니다.

 스케줄링된 서비스를 배치처리하는 과정에서 Job과 Step, Execute, 그리고 Service의 역할에 대해 고민했으며 이는 명확하게 구분해야 한다고 생각했습니다. 분명 Execute 안에 모든 Service를 집어넣어도 로직은 돌아가지만 유지보수 면에서 보기 안좋을 수 있습니다. 속히 '아름답지 않다'가 될 수 있다고 생각했습니다. 따라서 과정 중간에 Execute와 Service를 분리하려는 노력을 했으며

실제로 구현에 성공하여 배치 과정에서 문제가 생기면 이슈를 빠르게 파악할 수 있습니다.

 

---

 

8. 향후 개선 사항 및 제안

  콘텐츠 데이터 방면으로는 캐싱 로직을 명확하게 설계하여, 문제가 발생하면 어떤 엔지니어가 와도 해결 가능하게끔 로직을 리팩토링하고 싶습니다. 서비스 계층이 조금 어지럽다보니 핸들러를 따로 구성하여 역할을 더욱 세분화하고 싶습니다. 로깅 전략을 더욱 적극적이고 효율적으로 활용하여 문제 해결을 용이하게 하고 싶습니다.

 개인적으로는 프로젝트를 진행하며 실시간 기능, 예를 들어 채팅이나 알림, 몇명의 사용자가 보고 있는지 등에 대한 관심이 매우 많습니다. 제가 직접 구현하고 싶은 마음이 크기 때문에 시간이 된다면 개인 프로젝트에서 구현해보고 싶습니다.

 마지막으로, 라즈베리파이를 활용한 Postgre 서버를 구축하여 돌려보고 싶습니다.