pickRAP 프로젝트가 종료된 지 몇 개월이 흘렀다.
백엔드 개발자가 되고자 다짐하고 가장 최선을 다해 그리고 재미를 느꼈던 프로젝트인 'pickRAP' 아쉬운 점과 성장한 점이 많기에 프로젝트 회고를 해보고자 한다.

pickRAP 백엔드 레포지토리

KPT 방법론 회고 방식에 따라 작성할 예정이다.

---

프로젝트 설명

해당 프로젝트는 KUSITMS 26기 밋업데이에서 진행된 프로젝트로, 필자는 백엔드 개발자로 참여하였다.

pickRAP, 내가 PICK한 것들로 재구성되는 공간

pickRAP은 '스크랩'을 통해서 사용자가 자신의 관심사와 취향을 분석한다. 이러한 스크랩했던 콘텐츠들 중 일부를 선택하여 '매거진' 형태로 제작하여 다른 사용자와 공유할 수 있다. 궁극적으로 스크랩과 매거진 제작의 모든 액션들은 사용자의 자아를 구성하고 탐색할 수 있도록 돕는다. 스크랩은 근본적인 수집 행위에 속하여 타인의 시선에 영향을 받는 영역이 아니기 때문이다. 따라서, 사용자는 pickRAP을 통해 원하는 정보를 수집하는 스크랩, 스크랩된 콘텐츠를 재구성하여 꾸밈없는 자신의 모습을 마주한다.

소셜 네트워크 서비스에서의 '보여주기식 콘텐츠'에 대해서도 피로감을 느끼던 나는 해당 프로젝트의 목표에 공감할 수 있었다. 공개적 장소에서 다루는 콘텐츠는 검열이 들어갈 수밖에 없기 때문이다. 기획 의도가 공감되니 이를 소프트웨어로 해결하고자 하는 움직임에 더 깊게 몰입하여 참여할 수 있었다.

프로젝트 기간 및 참여 인원

기간 : 2022.10 ~ 2023.03 (5개월)
인원 : PM 1명, 기획 2명, 디자인 1명, FE 2명, BE 3명

우리팀은 밋업데이까지 MVP를 목표로 하였고, 그 이후 서비스를 고도화했다. 고도화를 위한 프론트 인원을 추가 영입했다.

프로젝트 기능

Phase 1 (MVP)

• 스크랩
  • 이미지, 비디오, 텍스트, 링크 등 여러 공간에 분산되어 저장되는 다양한 정보와 콘텐츠를 수집하고 편리하게 관리할 수 있는 올인원 스크랩북 기능
• 매거진
  • 스크랩을 통해 축적한 정보 중 특별하게 기록하고 싶은 것들을 매거진 형태로 재구성하여, 나만의 감성과 생각을 담아낸 새로운 콘텐츠로 나를 기록하고 브랜딩하는 매거진 서비스

Phase 2 (Sub function)

• 프로필
• 나만의 매거진과 키워드로 정리한 프로필 페이지를 관리
• 매거진 탐색
  • 다른 사용자의 매거진 기록을 탐방할 수 있는 소셜 플랫폼 공간으로, 비슷한 관심사를 공유하는 사용자의 매거진을 추천받아 관심 세계를 넓혀가는 서비스
  • 좋아요와 같이 정량적 수치가 아닌 사용자에게 어울리는 '컬러 무드'로 소통하며 SNS 피로도를 감소
• 분석
  • 수집한 정보와 좋아한 콘텐츠를 기반으로 사용자의 관심사를 분석하여 알려주는 자기 탐색 서비스
  • 스크랩의 결과를 분석해주고 타 사용자들이 나의 매거진에 남긴 퍼스널 무드 반응을 분석

기술스택

• Spring Boot, Java, MySql
• Spring Data JPA, querydsl, Spring Security, Cookie, JWT, oAuth2
• AWS RDS, AWS EC2, AWS S3, AWS Route53, AWS Code Deploy, Docker, Nginx, Github Actions
• 부하테스트 및 모니터링 : Spring actuator, prometheus

내가 구현한 부분

매거진 제작 및 관리

• 매거진 제작, 조회, 삭제 (다중삭제 지원)
• 매거진 공개 범위 수정
• 사용자 매거진 목록 조회 (최근 생성 sorting)
• 매거진 관련 기능 Test Code 작성

매거진 검색 및 탐색

• 매거진 해시태그 기반 검색
• 매거진 탐색 정책에 기반한 사용자 맞춤 매거진 추천

Web server 연동

• Nginx를 활용하여 Rever Proxy 설정
• SSL 적용

무중단 배포 세팅

• AWS Code Deploy, S3, Github Actions, Docker를 활용해 green-blue 방식 무중단 배포

개발 방법론

• 애자일 스크럼
  • 10일 단위의 Sprint meeting 진행, 주별 백엔드 팀 meeting
• 우리팀의 커밋 컨벤션 및 브랜치 전략 위키 보러가기

---

KPT 회고

Keep

개발만 하지 않기

• 우리 프로젝트가 속한 비즈니스 도메인에 대해 함께 공부하고 더욱 몰입하려고 노력했다.

• 코드 짜는 기계가 아닌 소프트웨어로 문제를 해결하려는 자세로 임했다.

• 개발팀 리더를 담당하여 회의 주도, 팀 단위 일정 관리도 진행했다.

  • 

• 특히 신경 쓴 부분은 개발팀의 대화를 문서화한 회의록 작성

  • 이전 프로젝트에서도 기획자/디자이너가 '개발팀이 하는 얘기는 항상 멋있어.. 이해할 순 없지만..!'이라는 얘기를 다수 들었다.
  • 개발 용어가 익숙하지 않기에 그들이 진행 상황 파악에 어려움이 있는 것이라는 생각이 들었다.
  • 개발팀 외 팀도 모두 이해 가능한 용어로 작성하면서 이중 커뮤니케이션을 줄이려고 노력했다.
  • 회의에서 나온 기능적인 피드백도 놓치지 않고 정리하여 의견을 전달했다.
  • 

동료를 위한 소통하기

• 
• '개발팀'이기 이전에 '팀원, 동료'임을 항상 상기시켰다. 그래서 의견이 필요한 사안에 대해서는 주저 없이 생각을 밝혔고, 그 생각을 논리적이고 가독성 있게 전달하려는 노력을 많이 했다.
• 결과적으로 개발팀 안에서는 '정민이 없었으면 회의 진행이 어려웠을 것이다.'를 듣기도 하고, 기획팀에게는 '적극적으로 의견을 제안하고 해결해 줘서 고맙다.'라는 이야기도 들을 수 있었다.

코드 리뷰

• Github PR을 통한 동료들과의 온라인 코드 리뷰를 시행했다.

• 다른 동료의 코드를 읽어보며 내 코드에서의 수정 사항이 떠오르기도 해서 결과적으로 상호 긍정적인 영향을 준다.

• 상대의 코드를 효과적으로 개선하기 위해서 이것저것 공부하고 고민한 끝에 리뷰를 남겨주면서 기능에 대한 풍부한 이해가 가능했다.

• 또 내 코드의 리뷰를 최대한 적게 받고 싶어서(= 코드를 잘 작성하고 싶어서) PR을 날리기 전에 꼼꼼하게 검토하는 습관을 들일 수 있었다.

• 지속적이고 일관성 있는 코드 리뷰를 진행하고자 세부적인 규칙을 제안하여 수립했다.

  • 
  • 규칙에 의거하여 리뷰를 진행하다 보니 리뷰해야할 포인트가 더욱 명확했다.
  • 의미없는 쓰레기 리뷰가 발생하지 않아서 커뮤니케이션 과정에서도 효과적으로 작용했다.

• 실제 코드리뷰는 아래처럼 진행되었다.

  • 
  • 
  • 

test code

• 다양한 케이스에 대한 Service 단위의 test code를 작성했다.
• 단순히 API를 설계하고 구현하는 것보다 중요한 것은 실제 환경에서도 예측한 대로 API가 작동하는가가 더욱 중요하다는 것을 알았다.
• 여러 가지 케이스를 고민하고 그에 대한 test code를 작성하면서 배포 환경에서의 오류를 최소화했다. 이를 통해 반복해서 수정하고 배포하는 개발 공수를 줄일 수 있었다.
• test code는 코드의 의도를 설명해 주는 창구가 될 수 있다. 잘 작성한 test code는 내 기능을 문서화하는 일종의 방법이 된다는 것

근거를 갖춘 기술 도입

• Web server와 WAS를 분리하여 보안을 강화하기 위하여 nginx 제안
  • Nginx를 서버 앞단에 붙여주어 클라이언트가 직접적으로 스프링 서버에 접근할 수 없도록 구성했다. (reverse proxy) 80번 포트는 외부 요청을 포워딩하고, 실제 요청에 대한 작업은 내부 애플리케이션 서버(8080번 포트)에서 처리한다.
• 아키텍처를 작성할 때에도 사용자 관점에서 불편함을 겪지는 않을지, docker를 활용하여 관리의 효율성을 높일지 등 다양한 측면을 고려하였다.
  • 

Problem

너무 많은 툴과 정의되지 않은 역할

• Phase 1에 노션에 작성된 기능 명세를 기반으로 개발이 진행되다가 Phase 2에는 피그마에 스토리보드 형식으로 기능 명세가 제시되었다. 자연스레 노션 기능 명세는 업데이트가 중단되었는데 나는 노션을 보며 기능을 개발했다.
• 그래서 애써 만들어놓은 기능을 삭제, 수정하는 불필요한 시간 낭비가 발생했다.
• 이후에도 노션과 피그마를 번갈아보며 개발해야 해서 혼란이 커지기도 했다.

best case만 고려

• test code를 작성하면서 일반적인 상황 또는 최고의 상황만 고려하여 예외에 대한 대응을 제대로 못했다.
  • 매거진을 추천해 줄 때, 해시태그 기반으로 추천이 이루어지는데 사용자의 해시태그 데이터에 중복이 있을 수 있는 상황을 고려하지 못했다.
  • 데이터의 중복을 제거하지 않으니까 무한 select를 하는 지경에 이르렀고 결국 쿼리가 무제한 지연되면서 네트워크 오류가 발생했다.

Spring DI에 대한 이해 부족

• S3 파일 업로드 하는 코드를 유틸리티화 하고자 했다. 그 과정에서 Bean 주입 생성 순서가 맞지 않아 서버에서 오류가 발생했다.
  • S3 Config Bean 보다 S3 Util Bean이 먼저 주입되어, S3Client에 value 값이 주입되지 않은 것

Try

각 툴의 역할을 명확히 정의하기

• 노션은 문서화 자료 아카이빙, 피그마는 와프와 디자인, 슬랙은 소통 창구 등 프로젝트 초반에 각 툴에 대한 역할을 정확하게 명시하고 시작하기
  • 확실하게 정의하더라도 후반에 이것저것 섞일 수 있는데 한 번 더 상기하는 것도 좋은 방법
  • 기능 명세 같은 부분은 문서화하는 것이 베스트. 스토리보드 방식을 활용해서 화면 디자인과 함께 텍스트로 적어놓는 방법도 나쁘지는 않았지만 문서화된 텍스트보다 가독성이 떨어진다고 느꼈다.
  • 이해되지 않는 부분은 적극적으로 물어보는 자세도 필요하다. 스스로 예측하여 개발하는 건 최악

서버 로그는 반드시 남기고 적극적으로 검토하기

• 여러 가지 서버 이슈에 대해서는 초반 대처가 미흡했다.
• 로그를 잘 확인했다면 바로 대응했을 텐데 배포 환경에 미숙하다는 이유로 로그에 소홀했다.
  • 서버 이슈에 대해서는 로그만큼 솔직한 반응이 없으니 반드시 확인하기

Spring/Java 기술 지식 함양하기

• 백엔드 개발자를 바라면서 여태까지 API 짜기에만 급급하지 않았나 싶다.
• 치명적인 서버 에러가 Spring DI 때문이었다는 것을 알았을 때는 허무하기도 했다. 원리를 깊게 공부해야 한다.
• 개발하면서 가장 많이 사용한 Java 역시도 기초적인 문법 외에는 깊게 알고 있지 않아서 부족함이 크다고 느꼈다.
• 특히 코드 리뷰 과정에서 Interface를 사용하는 데 있어 능숙한 동료 코드를 보며 코드 레벨에서도 깊은 공부를 해야 효율적인 코드를 짤 수 있구나를 많이 느꼈다.

---

마치며

pickRAP 프로젝트는 나에게 있어 첫 배포 경험, 테스트 코드 작성 경험. 스프린트 도입 경험 등 다양한 도전을 했던 애정 깊은 프로젝트이다. 또 단순히 개발에 치중되지 않고 비즈니스적 고민들도 함께 해볼 수 있었던 프로젝트이기도 하다.

모든 팀원들이 바쁘다 보니 더 큰 목표를 가지기보다는 현실적으로 프로젝트 종료를 결정했지만 후회는 남지 않는다. 아쉬웠던 점을 보완하면서 더욱 노력하자.

백엔드 개발자로 한 단계 성장시켜준 pickRAP 회고 마침.