프로젝트 회고

[까막noon] DND 6기 활동 후기 & ios 앱 프로젝트 회고

ohyujeong 2022. 3. 1. 15:26

프로젝트 내용

 

까막noon
글쓰기 루틴화를 위한 글쓰기 어플리케이션

 

팀원
개발4(프론트2,백2) / 디자인 2

 

전체 프로젝트 기간
2022.01.05 ~ 2022.02.27


개발 기간
2022.01.15 ~ 2022.02.27
(와이어프레임이 나오고 본격적인 개발은 1월 28일부터 시작했다. 약 4주가량 기능개발을 한 것 같다.)

 

 

아키텍처 및 기술스택


클라이언트 - Swift
백 - NestJS, MongoDB, Mongoose

 

협업 툴
Figma, Notion, Swagger

 

구현 API 

  • 챌린지 API
    • 매일 자정 12시에 새로운 키워드를 업데이트 
    • 유저가 진행중인 챌린지 현황 조회
    • 키워드에 대한 글쓰기 기능 구현
    • 키워드로 글을 썼을 때, 스탬프 증가 (스탬프는 하루에 한 개만 찍힘)

  • 나의 글 API
    • 유저가 작성한 모든 글(비공개글,공개글,릴레이글,자유글쓰기,챌린지글쓰기)을 조회
    • 챌린지/자유/릴레이 별로 분류해서 조회하는 기능
    • 자유글쓰기 기능 구현

  • 피드 API
    • 전체 피드에서 공개된 모든글들 조회
    • 인기순, 최신순, 태그별로 필터링해서 조회
    • 댓글 기능 구현
    • 스크랩/좋아요 기능 구현
    • 유저 구독하기 기능 구현
    • 구독한 유저들의 글만 볼 수 있는 구독 피드 기능
    • 제목, 내용, 제목+내용으로 검색 후 검색 결과 인기순,최신순으로 필터링 조회 기능

(팀원이 구현한 API 목록)

  • JWT 회원가입 및 로그인
  • 함께쓰기 기능(릴레이 방을 개설하고, 참여 신청 후 글쓰기)
  • 마이페이지 조회 (팔로워, 팔로잉 수 확인 및 스크랩 글들 확인, 카테고리 생성 등)

 

배운 점

  • NestJS와 TypeScript
    이번 프로젝트를 통해서 NestJS 프레임워크와 TypeScript 언어를 처음 사용해봤다.
    Nest는 Node와 Spring의 중간지점 같은 프레임워크라는 생각이 들었다.. 구조가 Spring이랑 상당히 비슷한 느낌!
    Nest는 비슷한 기능을 하는 컨트롤러, 서비스 등을 묶어서 하나의 모듈로 관리하는데, 이게 객체지향에서의 캡슐화와 같아서 구조적으로 안정적인 느낌을 많이 받았다. 그리고 Node는 진짜 커스텀 구조라는 느낌이 많이 들었는데, Nest는 어느정도 정형화된 구조가 있어서(컨트롤러,서비스) 그 규칙을 따라야 한다. 그래서 팀 프로젝트 할 때, 팀원의 코드를 보기에도 좋은 것 같음.. 아무래도 정형화된 구조가 있으니까 이해하기가 더 쉽다.
    컨트롤러에는 엔드포인트들과 라우터를 작성하고, 서비스에서는 비즈니스 로직들을 작성해준다. 이 때 이번 프로젝트에서는 Repository Pattern 을 사용해서 Data에 직접 접근하는 로직과 단순 비즈니스 로직을 분리해줬다. 이런 패턴들을 사용한 이유에 대해서는 나중에 다시 정리해봐야겠지만.. 코드의 가독성을 높이고, 각각의 레이어들이 역할분리를 확실히 하기 위해서다. 암튼.. NestJS를 쓰면서 의존성 주입에 대한 개념도 공부하고 처음부터 Spring 배웠을 땐 아;;이거 뭐지 했던 것들이 Nest 한 번 쓰니까 좀 이해되기 시작한다. 역시.. 이론 백 번 보는 것보다 그냥 한 번 프로젝트로 해보는게 빨리 습득이 되는 것 같음. 부딪히면서 배우는 게 체질인 것 같다.. 
  • 커서 페이지네이션 
    보통 강의에서 페이지네이션을 가르칠 땐, 페이징 페이지네이션만 가르쳐준다. 안 그런 강의도 있겠지만 내가 들은 강의는 일단 다 그랬음. 이번엔 피드가 인스타그램 피드처럼 무한스크롤로 계속 내리는 방식이다보니..커서 페이지네이션을 처음 해봤는데, 처음 해보면서 커서 페이지네이션도 처음 안 개념이었다. ㅋㅋㅋㅋ 페이징 페이지네이션은 직관적으로 이해가 됐는데, 커서 페이지네이션은 이해하는 데 조금 걸림..^^ 그래서 대체 한 번 보내줄 때 보내는 Data개수가 '한 화면에 보이는 글들 기준' 인 건지.. 그니까 예를 들어, 한 화면에 3개의 글까지만 보인다 하면, 한 번 보내주는 데이터는 3개만 보내줘야 하는건지. 한 화면에 얽매일 필요가 없는지 이게 약간 헷갈렸다. 아무래도 페이징 페이지네이션에 생각이 얽매여서 그랬던 것 같음. 페이지는 무조건 한 페이지당 보이는 글 기준이니까. 그리고 커서 페이지네이션은 다음 커서로 유니크한 필드값을 보내줘야하는데, 맨 처음 페이지를 로딩할 때는 커서값을 모르는데 어떻게 데이터를 보내주지?? 이것도 2차 고민이었다. 그럼 커서가 null일 때, 백에서 맨 처음 보내주는 기준 DB를 찾아서 그거 기준으로 보내주면 된다. 암튼.. 커서 페이지네이션도 새롭게 배워갑니다..
  • CronTab 사용
    매일 자정에 새로운 키워드도 업데이트 해주고, 자정마다 유저의 '오늘의 챌린지 수행 여부'도 업데이트 해줘야했다. 그니까 일정한 시간마다 매일 같은 작업을 하는건데,, 이걸 하기 위해 프로젝트에서 처음으로 CronTab을 사용해봤다. 리눅스 배울 때 배운 개념을 프로젝트에 직접 적용해보니까 약간 신기했다 ㅎㅎ 리눅스 진짜 재밌게 배웠는데 백엔드 포지션으로 개발하니까 리눅스에서 배운 거 이것저것 사용해볼 수가 있어서 너무 좋다.
    암튼, 이 반복 예약 작업도 처음에는 CronTab을 못떠올려서.. 이리저리 하고 리팩토링을 거듭하면서 CronTab 사용하게 됐다.. 매일매일 조금씩 깔끔해지는 코드를 보며 혼자 뿌듯해했다.. ㅋㅋㅋㅋㅋㅋㅋㅋ
  • CI/CD
    아직 이걸 구축한 건 아닌데,, 이 개념을 DND 프로젝트를 통해서 처음 알았다. DND 프로젝트에서는 아니고 다른 프로젝트 하면서 와 배포자동화 진짜 중요한거구나;;를 몸소 느끼는 중.. 특히 수정이 잦은 프로젝트에서는 진짜 꼭 필수... 클라이언트랑 백이 매번 같은 시간에 작업을 하는 게 아니니까, 코드가 업데이트 되면 알아서 배포되는 게 너무 필요한 듯. 암튼 이 중요한 개념을 DND 와서 처음 알았고요..? 너무 감사합니다.. 클래스101에서 백엔드 강의를 듣고 있었는데, 거기서 docker 얘기가 나온다. 그 때는 아 그냥 그렇구나~ 했는데 프로젝트 하면서 CI/CD를 직접 적용해보려고 하니까 또 그 강의가 새롭게 다가오더라.. 암튼 여기서 배운걸 토대로 다른 프로젝트에서는 docker로 배포를 진행하고 있다. (자동화는 아직.. ^^)
  • 좀 더 체계적인 Swagger 사용
    Swagger는 이전에도 사용해봤지만, 좀 더 체계적으로 Swagger를 사용하게 됐다. Response Type같은 것도 하나하나 명시해주기.. 중요.. 정말 Swagger에 API 하나하나를 자세히 설명해서 이것만 봐도 소통이 원활하도록!! 그렇게 쓰게 된 것 같다.
  • GitHub 기능 더 활용하기 Fork, Git Branch 전략
    이 전에는, 원격에 레포를 파고 그 레포트를 바로 clone해와서 프로젝트를 진행했는데 이제는 원격 레포를 내 레포로 fork -> 내 레포를 clone. 그리고 pull request로 원격 레포에 코드를 업데이트 하는 식으로 프로젝트를 진행하게 됐다. Fork기능 이렇게 쓰는 거였구나..^^ 처음엔 이것도 이해가 좀 안 돼서 같이 동아리 하는 언니랑 우당탕탕.. 연습해봤다. github master가 되기 위한.. 그리고 pr하면서 코드리뷰도 해보게 됐고!! 브랜치 전략도 이전에 블로그에 쓴 것처럼 기능별로 브랜치를 나눠서 작성하는 걸로 프로젝트를 진행했다.
    그리고 Github의 project 기능도 처음 사용해봤고.. 이걸로 이슈관리도 해봤다.
    진짜 Git이랑 github 활용하면 할수록... 2학년 때 Git 특강 듣다가 10분만에 gg쳤던 과거가 생각나서 감회가 새롭다..^^

 

DND 활동후기

이렇게 많은 걸 배우고 갈 수 있게 해준 DND 활동 후기는요..두구두구두구..

체계적으로 프로젝트를 하고 싶은 사람들에게 추천한다. 확실히 개발 가이드라인이 제공되어 있어서, 알았던 건 조금 더 체계적으로 알게 돼고, 몰랐던 것도 많이 알아가는 것 같다. 가이드라인 덕분에 아키텍처도 처음 그려봤고, CI/CD같은 중요한 개념도 처음 알게 됐으니..ㅎㅎ 근데 가이드라인은 가이드라인일뿐이니까 가이드라인 기간(?)에 개발을 맞추지 않았으면 좋겠다.. 가이드라인 상에서는 5주차부터 개발을 시작하는 걸로 되어있는데, 1주차~4주차 가이드라인을 빨리빨리 끝내고 얼른 개발을 시작하는 게 좋은 것 같다. 사실 IOS 앱 프로젝트를 진짜 해보고 싶었는데, DND 덕분에 좋은 기회를 얻었고, 많은 걸 얻어갈 수 있던 프로젝트를 해볼 수 있어서 좋았다. 8주내에 배포까지는 못했지만, 팀원들과 모여서 조금 더 디벨롭을 한 뒤에 배포까지 할 예정이다!