[프로젝트] 메인 프로젝트 마무리 회고 & 앞으로의 계획

구현 중인 반응형 웹 맛보기 ~~

매칭으로 끝내지 않는 과외 매칭 및 관리 서비스 '과외차이' 구경오세욥!

github

🟢 메인 프로젝트 목표 점검

1. 기획부터 디자인, 개발, 배포까지 ! = 우리 팀만의 어플리케이션 개발

🍀 사용자 요구사항 정의서

기획을 할 때만 해도 점점 기능들이 많아지는 걸 보면서... 이거.. 되겠지..? 반신반의했었는데 백로그로 미뤄두기로 한 '실시간 채팅' '실시간 알림'기능만 제외하면 거의 모든 기능을 구현하는 데 성공했다.

당연히 나 혼자의 힘으로 해냈다기 보다는 모든 팀원들의 피 땀 눈물이 담겨져 있지만! 모쪼록 메인 프로젝트도 잘 마무리한 것 같아 뿌듯하다.

🍀 서비스 소개 PPT 일부 발췌

서비스를 처음부터 구상한다는 게 쉬운 일은 아니었는데, 백엔드 팀원 중 한 분이 자신의 과외 경험을 공유해주시면서부터 기획의 가닥이 잡혔다.

과외 매칭 서비스에 과외 관리 서비스까지 합쳐보자!

그리고 그 외의 자잘한 사항들은 개발을 해나가면서 조금씩 바뀐 부분도 있지만 큰 틀은 바뀌지 않았다.

기획을 할 때 중요한 건 내가 하는 말을 상대방이 제대로 이해했는지, 상대방이 한 말을 내가 제대로 이해했는지를 끊임없이 확인하는 것 같다. 그것만 잘 확인해도 삽질할 확률이 반으로 준다. 🥹

🍀 고민했던 것들

과외는 학생들이 많이 이용하지만, 과외를 진행하는 동안 경과나 진도를 확인하고자 하는 것은 학생의 보호자들이 될 것을 생각해서 여러 사람이 한 계정을 함께 사용할 수 있도록 사용자 계정에 딸린 '프로필'이라는 걸 만들게 되었다. 팀원들과는 이 프로필을 넷플릭스의 프로필과 같은 기능으로 이해하고 만들었다.

학부모의 자녀가 여러명일 수 있으므로 한 학부모가 계정을 만들어서 여러 자녀들 각각에 대한 프로필을 만들어서 사용할 수도 있을 것이고, 성인인 튜티의 경우에는 여러 프로필을 만들어서 매칭된 과외 별로 프로필을 관리할 수도 있을 것이다. 튜터 계정 역시 여러 프로필을 만들 수 있으므로 여러 과목을 과외하는 경우 프로필 별 관리가 가능해진다.

서비스가 이 프로필 위주로 돌아가다 보니 서비스를 사용하기 전 프로필을 사용자들에게 어떻게 꼭 입력해야만 하는 것으로 인식하도록 만들지에 대한 고민이 있었다.

프로필과 더불어 꼭 필요한 것이 '튜터'인지 '튜티'인지 회원을 구분하는 것이었는데, 이 두 가지를 첫 회원가입과 동시에 강제로 입력하기 위해서 아래와 같은 플로우를 따르게 했다.

회원가입 후 최초 로그인 시 위와 같은 모달을 띄운다.
여기서 취소를 누르면 로그아웃이 된다.
즉, 사용자는 회원 필수 정보들을 제대로 입력해야 서비스를 제대로 이용할 수 있다.

회원 필수 정보를 입력하고 나면 프로필 전환 모달이 뜨게 되는데,
회원 가입한 사용자에게는 기본적으로 기본 프로필이 하나 생성되어 있다.
그러나 이 기본 프로필으로 바로 공고를 올릴 수 있는 건 아니다.

헤더의 내 프로필을 통해 들어갔을 때 볼 수 있는 화면인데, 좌측 하단에 보면 공고 상태에 대한 설명이 있다. '공고 상태 수정은 프로필 필수 항목 작성이 완료되면 가능합니다.'라는 설명과 같이 기본 프로필을 수정하고 난 뒤에 공고가 가능하게 된다.

이런 플로우가 사실 UX적으로 좋을지에 대한 고민이 남긴 했지만... 초반 기획을 해치지 않으면서 만들 수 있는 최선의 방법이었다고 생각해본다.
구현하고자 하는 바를 잘 구현한 점도 만족스럽다.

2. 비전공자 쪼렙 개발자인 내가 메인 프로젝트에서는 팀장님?!

프리 프로젝트를 마무리하면서 팀 프로젝트 내에서 내 역할이 어땠는가를 고민했었다. 나는 어차피 늘 열심히 하는 팀원일 것이고, 성장에 대한 욕구도 많은 편이라 새로운 것에 도전해보는 걸 좋아한다. 일정 관리나 계획을 짜는 것도 좋아하고 잘 한다. 프리 프로젝트 때에는 나의 이런 장점들을 잘 살리지 못한 것 같아 메인 프로젝트에서는 팀장으로써 역할도 맡아보는 건 어떨까 하는 생각을 했었다.

팀장을 하겠다고 지원했지만 팀원들을 모아두고 보니 다들 정말 멋진 분들이라 내가 이 쟁쟁한 팀원들 사이에서 팀장을 해도 되는 걸까 하는 걱정도 들었지만, 나만이 할 수 있는 것들이 분명히 있을 거라고 생각하며 나아가기로 했다.

큰 탈이 없이 프로젝트가 마무리되었지만 아쉬운 점들이 당연히 있는데

우선, 팀장으로서의 기능이 단지 '조금 더' '많이' 하는 것만이 아닐 수도 있겠다는 생각이 들었다. 다른 사람들이 하기 싫어하는 일이나, 번거로운 일들을 자원해서 했던 건 좋았지만 단순하게 일을 많이 하는 걸 떠나서 어떻게 효율적으로 일을 할 수 있을지에 대해서 조금 더 고민해보았다면 어땠을까 싶다.

예를 들어 프론트엔드 팀원들의 경우 회의 시간이 아니더라도 함께 구글밋에 모여있곤 해서 자잘하게 대화를 정말 많이 했는데, 그동안 결정되거나 수정되는 사항들이 정말 많았다. 틈틈이 메모를 하기는 했지만, 그 메모했던 사항들이나 바뀐 사항들을 잘 정리해서 매일 매일 공지해두었다면 다른 팀원들이 좀 더 편하게 업무를 진행할 수 있지 않았을까? 또 새롭게 공부한 라이브러리에 대한 정보들을 잘 정리해서 두었다면 팀원들이 참고하기에 좋지 않았을까... 뭐 그런 생각들. 코드 컨벤션이나 커밋 컨벤션들도 좀 더 세세하게 정해두는 편이 좋았을 것 같다.

일이 휘몰아쳐서 일단 이거부터 하자! 했던 것들이 없잖아 있었던 것 같다. 물론 한 달이라는 정해진 시간이 있었으므로 바빴던 것도 사실이지만 많은 노력을 쏟았던 SRS나 User Flow가 개발 중 얼마나 도움이 되었는가를 생각해보면 역시 초반에 품을 많이 들여서 틀을 잘 잡는 게 중요하다는 거...

그리고 또 아쉬운 점은 좀 더 백엔드 팀장님과 긴밀하게 소통하지 못했던 점이다. 그 소통이라는 게 단순하게 어떤 업무가 잘 되고 있나에 대한 소통 뿐 아니라 팀원들이 어떻게 일을 진행하고 있는지, 어떤 방식으로 업무를 분배하고 있는지, 힘들어하는 팀원은 없는지, 잘 따라오는지와 같은 팀원 개개인에 대한 소통도 포함했어야 한다는 생각이 든다. 팀 프로젝트이다보니 아무래도 기여도가 잘 분배되는 것이 중요했는데, 그런 부분들을 잘 고려하지 못한 점이 많이 아쉽다. 팀원 중 한 분이 회고 회의 때 좀 더 기여를 하지 못해서 아쉽다고 말씀하신 부분이 속상하기도 했고... 왜 그것까지 생각하지 못했는지 자신한테 화가 나기도 했다.

사실 왜 그렇게까지 생각하지 못했냐고 묻는다면 답은 간단하다. 일단은 이런 프로젝트에서 팀장이 되어 본 적이 없었고, 그리고 솔직히 업무를 끝까지 따라가고 챙기는 것만 해도 버거웠기 때문이다...그래서 결국 감기 몸살에게 삼켜지지 않았던가..ㅠ 이번 일을 계기로 깨달은 것이 많으므로 앞으로 어떤 곳에서 팀장 역할을 할 일이 있다면 꼬옥 여러가지 방면으로 소통을 잘 해봐야겠다. 건강도 잘 챙기고!

3. 기능 구현 내에서 도전 과제 설정 및 수행

초반에는 마크업이나 단순한 API 연결이 바빠서 도전 과제 설정에 대해서 생각할 겨를은 없었던 것 같고, 이후 기본적으로 기능을 구현하고 나서 차차 도전 과제들을 설정해나갔던 것 같다.

아래와 같은 (심화) 도전 과제들을 설정했었고, 앞으로 반응형 웹 구현을 완성하고 나면 현재 쪽지 기능과 비슷하게 구현되어 있는 채팅 기능을 실시간 채팅으로 바꾸고, 알림 기능도 구현해볼 생각이다. PWA, 외부 API 사용은 일단 생각은 해보고 있는데 하게 된다면 채팅이나 노티 기능보다는 좀 더 후반 작업이 되지 않을까 싶다.

• recoil로 모달 리팩토링
• CI/CD
• https
• 모바일 뷰포트 고려 (반응형 웹)
• 웹 소켓을 이용한 실시간 채팅 기능
• 웹 소켓을 이용한 실시간 알림 기능
• PWA
• 외부 API 받아와서 사용하기

4. 단순한 기능 구현을 넘어 클린 코드 작성, 효율적 코드 작성에 신경쓰기

이게 아마 제일 못 지킨 목표가 아닐까 싶은데...

초반 마크업 때 쓴 코드를 지금 보면 왜 이렇게 씀?;;;;; 이라는 생각이 절로 든다. 그리고 기능 구현을 할 때에도 최소한의 코드 컨벤션은 지켰지만 다른 팀원이 보기에 좋은 코드를 내가 작성했는가?를 생각해보면... 그다지 그렇지 않았을 것 같다는 생각이 든다.

오히려 팀원 중 코드를 깔끔하게 쓰는 분을 보면서 많이 배웠고, 그 분의 코드를 많이 참고해서 사용했었다. 아직도 배울 점이 더 많을 거라는 생각이 들어서 프로젝트가 끝났더라도 차근차근 처음부터 코드를 살펴보는 시간이 필요할 것 같다.

5. as always 소통에 힘쓰자

프로젝트를 하면서 팀원들과 소통을 정말 열심히 했고, 그렇게 소통을 하기 위해서 아래와 같은 방법들을 사용했다.

• 매일 아침 9시 / 저녁 6시 스탠딩 회의
  : 각 파트별 진행 상황 및 이슈 공유를 기본으로 하루 두 번 회의 진행
  아침에는 금일 진행할 Task 공유, 저녁에는 진척도 공유

• 개발은 모각코와 함께
  : 프로젝트 진행 중 90% 이상의 개발 시간을 모각코로 진행
  개발 중 발생한 이슈나 기능 이상에 대한 빠른 공유 가능
  파트 전체에서 해결해야되는 이슈의 경우 LiveShare, Code With Me 등의 실시간 코드 공동 작업 도구 적극 활용

• 각 파트의 멘토링 내용은 일지로 공유
  : 팀 노션 페이지에 멘토 일지 작성
  해결하기 어려운 문제나 조언이 필요한 경우 멘토님께 여쭤보고, 결과를 공유하는 역할

6. 매주 일지 남기기

이건 진짜 쓰기 싫을 때도 지켰던 사항이라... 그냥 칭찬을 마구마구 해주겠다. 😆

🟢 tasks

⭐️ https 연결 (AWS cloud front, certificate manager 이용)

https 적용시 참고한 블로그

AWS certificate manager를 사용하면 S3 버킷을 사용하고 있을 때 인증을 해주기 때문에 https를 위한 인증 자체는 어렵지 않다. (무료!)

발급받은 인증서를 cloud front에 적용해주어야 하는데, cloud front는 AWS에서 제공하는 CDN으로 서버에 업로드된 페이지를 캐싱해서 데이터 센터에 뿌려주는 기능을 한다. (콘텐츠 제공자와 사용자 간 지리적으로 떨어져 있는 환경에서 콘텐츠를 빠르게 제공하기 위한 기술)

CDN의 경우에는 캐싱 시간이 서비스에 따라 정해져있는데 AWS는 24시간마다 캐싱한다. 이렇게 되면 배포한 파일을 바로 바로 페이지에 적용이 되지 않는 문제점이 있다.

cloud front에는 '무효화'라는 기능이 있어서 이런 캐싱을 무효화해줄 수 있다. 이 기능을 적용해서 배포를 할 때마다 캐싱을 새롭게 하도록 설정했다.

cloudFront Invalidation 참고

//cache를 위해 yml 파일에 추가한 내용

 - name: Invalidate CloudFront Cache
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_FE_ACCESS_KEY }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_FE_SECRET_KEY }}
          AWS_EC2_METADATA_DISABLED: true
        run: aws cloudfront create-invalidation —distribution-id [CloudFront distribution 아이디] —paths "/index.html" "/static/*"

cloudFront distribution 아이디는 아래와 같이 CloudFront로 들어가서 찾을 수 있다

⭐️ github actions job

workflow에서 job을 나누면 독립적인 처리를 하게 됨 = 병렬적으로 처리된다.
단순히 순차적으로 실행이 필요하다면 step을 나누어 처리하는 게 맞음.

github actions job 참고 블로그

⭐️ 배포 페이지 새로고침 시 404 문제 해결

CloudFront, S3로 정적 페이지 배포를 하고 나면 맨 처음 새로고침시 404에러가 뜨곤 했는데, cloudfront 오류 페이지 설정으로 수정 가능했다.

응답 코드를 200으로 설정해주고, 오류 페이지를 index.html으로 설정해주면 됨.

⭐️ 반응형 웹 구현

• breack point 를 잘 잡는 게 중요하다 : 1048px, 768px, 480px 기준으로 잡았다.

• 반응형의 기본은 '가변값'이므로 가능하면 width나 height 값을 줄 때 고정값을 주지 말고 가변값을 주는 게 좋다. 초반에 멘토님께서 '반응형 구현하실 거면 초반부터 조금씩 신경쓰시는 게 좋을 거'라고 하셨던 게 어떤 건지 피부로 느끼지 못했었다. 근데 지나고 보니 이거... 진짜 미리부터 고민했어야 했구나 싶고, 그 고민이라는 게 거창한 거라기 보다는 앞에서 말한 가변값 사용하기, 그리고 뷰포트가 줄어들었을 때 숨겨질 메뉴는 어떤 것들인지를 고려해서 작업하는 정도일듯. 폰트 같은 자잘하고 세세하게 잡아줘야 하는 것들은 이후에 고려해도 되지만... 큰 틀들은 정말 미리미리 생각해두는 게 나았지 싶다.

⭐️ Grid 너는 신세계...

grid에 대해 잘 알려주는 블로그

flex를 정말 자주, 많이 사용했었는데 flex만으로는 부족한 부분들이 점점 생겨나기 시작했고, 특히나 반응형 구현 시에 더 그랬다. 팀원 중 한 분이 grid를 적용해보는 게 어떠냐는 의견을 내주셨다.

대표적으로 Grid를 사용했던 건 공고 피드 부분이었다.

이렇게 예쁘게 4열 => 3열 => 2열로 만드는 게 flex만으로는 부족했다.
flex wrap을 사용해 width를 넘어가는 요소를 다음 줄로 넘겨줄 수는 있었지만, justify-content를 flex-start로 놓게 되면 너무 왼쪽으로 붙어버리거나, center를 먹이면 아래처럼 검색 기능 을 이용해서 하나~세 개의 결과나 나왔을 때 중간으로 몰려버리는 문제점이 생겼다.

물론 flex-start를 이용하고, margin을 먹여주거나 할 수도 있었겠지만, grid를 이용하면 훨씬 더 간편하고 예쁘게 해결할 수 있었으므로... 아래와 같이 grid를 사용해서 특정 width를 기준으로 columns 수를 4개 -> 3개 -> 2개로 줄이는 방법을 선택했다.

그리고 뭣보다 grid를 사용하면 영역을 기본적으로 stretch로 채워주기 때문에 별도로 내부 요소를 꽉 차게 늘려줄 필요가 없다는 점도 좋았다.

.feedContainer {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  grid-auto-rows: minmax(320px, auto);
  gap: 8px;
  margin-bottom: 16px;

  @media screen and (max-width: 768px) {
    padding: 0 8px;
    grid-template-columns: repeat(3, 1fr);
  }

  @media screen and (max-width: 480px) {
    padding: 0 8px;
    grid-template-columns: repeat(2, 1fr);
  }

}

아직 Grid를 마스터했다! 할 정도로 잘 아는 건 아니기 때문에 더듬더듬 찾아가면서 해야하긴 하지만 아무튼 grid에도 발을 살짝 걸쳐보았으니 세계가 더 확장된 것이라고 할 수 있겠다.

⭐️ CSS 컨벤션?

우리 프론트팀이 작성했던 CSS 코드를 보면 CSS를 사용하는 방법에 대한 통일성이 떨어진다. 이전에 퍼블리셔로 일하셨던 팀원이 계셔서 이런 문제점을 짚어주셨다. 코드 컨벤션에 포함되어야 했을 부분이지 않았을까 싶다.

🤔 What's After Like?

• 과외차이 백로그 - 프로젝트 일정에 따라
• TypeScript, Next.js 공부 - 매일 조금씩
• JS, React 심화 (딥다이브 책, 사놓은 강의) - 매일 조금씩
• 코테 준비 다시 시작 (프로그래머스 2~3단계까지는 해야함) - 매일 조금씩
• 개인 프로젝트나 팀 프로젝트 최소 하나 더 하기 - 주말 Or 과외차이 백로그 이후
• 쿠키 투 두 리스트 리팩토링 해보는 것도 좋겠다 - 주말
• CSS 공부 더 해야할 필요성 - 매일 조금씩
  프론트엔드 개발자로서 CSS라는 건 뗄레야 뗄 수 없는 부분이라는 걸 이번 프로젝트를 통해 많이 느꼈다. 단순히 어떤 CSS 기능을 검색해서 가져다 쓰는 게 아니라, CSS로 일종의 로직이 존재하고, 그 로직을 잘 이해하고 있으면 이럴 때는 이렇게 쓰면 된다와 같은 식의 사고가 되는 모양. (이런 기본적인 지식들도 공부 필요)
• 올해 취업을 목표로 차근차근 준비 : 기술 면접 준비 필요, 주변 현직자들 귀찮게 하자

취업하고 싶은 곳

• 사수가 있는 곳 : 신입 적응에 신경을 많이 써주는 곳
• 회사내 스터디 존재하는 곳
• 성장할 수 있는 곳, 성장을 독려하는 곳