[항해 99] 8주차 WIL - Weekly, I Learned

WIL - Weekly, I Learned

2022-11-7 ~ 2022-11-13

 

말도 많고 탈도 많은 일주일이었다. 순조롭게 진행되는 듯 하던 실전 프로젝트는 기획 단계에서 세심함이 부족했던 이유인지 중간 중간 팀회의에서 많은 시간과 감정을 소모시켰다. 아무래도 팀원 모두가 그동안 일주일이라는 짧은 프로젝트라고도 하기 부끄러운 프로젝트만 하다가 6주라는 긴 시간이 주어지자 분위기가 루즈해진 느낌이 들었다. 게다가 디자이너님과의 첫 협업이다 보니 아이스브레이킹의 시간도 필요했고 기획 부분에서 신경 쓸 것이 많았다. 기술 구현만 하면 될 줄 알았던 기획 단계에서의 안일한 생각이 만들어낸 상황 앞에 뼈저리게 후회했다. 그래도 저번주에 비해 나름 성장했다고 생각 되는 점은 기획하는 단계에서 부터 재활용을 할수 있는 부분을 짚어내 컴포넌트화 한뒤 파일 구성을 짜서 진행했다는 점! 우리가 기획한 중고거래 서비스의 게시물 작성 부분과 책정된 가격이 마음에 들지 않을때 작성하는 이의제기 게시물의 작성 부분이 재활용성이 높기에 이를 컴포넌트화 하여 재활용하였다. 또한 CRUD의 Create부분 부터 재활용을 하니 Update와 Delete는 마찬가지로 너무 쉬웠고 Read부분은 카테고리별로 재활용까지 하여 코드를 구성하는데 생각하는 시간을 많이 사용하여도 전체적인 기술 구현 부분에서 많은 시간을 단축할 수 있었다. 물론 중간에 BE에서 이슈가 있어서 계획한 예정대로 진행되고 있진 않지만 문제 해결 대책 방안을 찾았기에 금방 기술 구현을 마치고 css및 챌린지 부분(실시간 채팅 및 실시간 알림 등 웹소켓 사용 부분)을 진행할수 있을 것이라 생각된다.

 

 

 

▶ 기간 : 2022.11.4 ~ 2022.12.16
▷ 실전 프로젝트

 

지난주 주제 선정에서 많은 시간과 감정을 소모하는 바람에 기획부분에서 소홀했던 느낌이 있었는데 이번 주에 뼈저리게 후회했다... 특히 CRUD 부분을 구현하는데 집중해 정작 우리 서비스 나름의 차별점인 가격책정 부분의 상세 내용을 정하지 않은 부분이 크게 다가왔다. 사실 이 부분은 그 데이터를 FE에서 처리해서 넘겨주는 방식과 BE에서 처리해서 리스트를 받아다가 다시 넘겨주는 방식에서 의견이 나뉘어 멘토링을 받은 후에 결정하기로 했던 부분이었는데 멘토링을 통해 BE에서 처리하는 것이 맞다는 답변을 받았다.( 뒤에 따로 언급할 예정) 이에 BE에서 데이터를 처리를 하는 것으로 결정했음에도 그 상세 항목을 결정하는데 2시간이 넘는 시간이 걸렸다. (이렇게 간단한 내용을 결정하는데도 오랜 시간이 걸리는 데 현업에선 얼마나 많은 시간이 걸릴지 벌써부터 걱정이 된다...) 기획이 착착 진행되고 바로바로 기술을 구현하고 디자이너님과 소통하여 디자인적으로 완벽한 서비스를 만드는 꿈을 꾸었던 내가 정말 꽃동산에 살고 있었구나 라는 생각을 것을 뼈져리게 느꼈다... ㅋㅋ

물론 이 과정에서 많은 것을 얻어가야 하며 많은 교훈을 얻었다.

첫째. 데드라인은 일단 무조건 짧게 잡아야한다!

길게 잡아도 어차피 그안에 못만든다. (지극히 개인적인 생각입니다 ㅋㅋㅋ) 앞부분에서 최대한 많이 뽑아놔야 뒤에 디테일 부분에서 많은 시간을 쓰며 서비스의 퀄리티가 증가한다고 생각한다.

둘째. 절대 계획대로 되지 않는다! 

계획대로 진행되는 방법은 하나 뿐이지만 이를 방해하는 요소는 수십, 수만가지다. 하다못해 간단한 오류로 프로젝트가 엎어질수도 있다고 생각한다. 계획이 완벽할수록 좋겠지만 완벽할수만은 없기에 플랜B, 플랜C 등도 생각해 놓아야 한다고 생각한다.

셋째. 소통이 정말 정말 정말 중요하다!

개인적으로 오전 회의, 오후 회의, 하루에 두번씩이나 회의를 해야하나 라는 생각을 했었다. 하지만 이는 해야만 한다라는 생각으로 바뀌었다. 결국 우리는 정해진 시간 내에 결과물을 내야하고 이를 위해선 협업하는 과정에서 모든 사람이 맡은 바를 모두 해내야 한다. 이를 체크하는데 많은 방법이 있겠지만 프로젝트 마일스톤을 체크하는 것만큼 좋은 방법이 없다고 생각된다. 물론 불편할수도 있고 나도 아직 불편하지 않다면 거짓말이겠지만 협업이 필수인 개발자에겐 익숙해져야 하는 부분이라고 생각한다. 그 과정에서 협업 툴을 사용하는 방안이 있을테고 우리 팀도 Jira라는 협업 툴을 사용하고 있다.

 

 

 

팀프로젝트 노션 링크: https://shine-industry-2cc.notion.site/1-2048c4aab357410e922fe426d5c24c99

1조 팀프로젝트 - 중고 거래 가격 측정 사이트

 

 

 

▶ 기간 : 2022.11.12
▷ 실전 프로젝트 기술 멘토링 (기술 멘토링 사전 노트)

 

이번주 우리 조 FE가 멘토님께 멘토링 받고 싶은 내용은 크게 세가지였다.

 

첫째. 가격책정 리스트(select option list)를 백엔드(데이터 확장성, 데이터 관리 vs 잦은 api 통신)에서 처리하는 것이 나을지, 프론트엔드(html 무거워지고 비효율적, 데이터를 일일이 수동 관리 → 스토어에다 따로 배열화도 고려 but, DB와의 순서가 일치가 필요 vs 렌더링 속도는 빨라짐)에서 처리할지를 결정하는 것.

 

둘째. 게시글 전체조회 시 api가 토큰 있을 때와 없을 때(로그인 했을 때와 안 했을 때) 다른 로직이 필요한데 어떤 식으로 프론트엔드에서 처리하면 좋을지였다.

 

셋째. 이미지 파일을 업로드 하는데 S3서버를 FE에서 관리하는 것과 BE에서 관리하는 것 중에 어떤 것이 적절한지였다.

 

일단 첫째에 대한 답변은 단호 그자체였다. 무조건. 백에서 처리해야 한다였다. 어찌보면 당연한 일이었다. 간단하고 가벼운 데이터는 프론트에서 처리하는 방법이 더 적절한 상황도 있겠지만 여러 옵션들을 골라서 그에 맞는 데이터를 넘겨주어야 하는 우리의 상황에선 모든 리스트를 백에서 관리하는 것이 당연했다. ( 나중에 생각해보니 이런 질문을 했다는 것이 살짝 부끄러웠다...) 또한 질문할때 언급했던 내용처럼 데이터 확장성(새로운 내용이 추가 되었을 때)을 생각 한다면 당연히 BE에서 처리 하는 것이 맞는 결정이었다. 특히나 정해진 짧은 시간안에 결과물을 만들어야 하는 우리와 같은 상황에선 FE에서 데이터 처리에 신경 쓸 시간에 다른 부분에 더 심혈을 기울여야 한다는 대답도 들었다. 

 

둘째에 대한 답변은 토큰에 대해선 워낙 많은 방안이 있기에 정답은 없고 상황에 맞게 사용하면 된다는 것이었다. 그리고 우리의 상황(글을 보여줄때 해당 게시물에 내가 찜을 한 것인지 아닌지를 판단해서 보여줘야 함)에 맞게 로그인 상황과 로그아웃 상황에 따라 다른 api로 get을 해오기로 결정했다.

 

마지막으로 셋째에 대한 대답도 너무 단호하게 말씀하셔서 당황했다. 셋째 질문의 답은 S3 서버에 대한 처리는 BE에서 하는 것이 맞다는 답변이었다. 이유는 다음과 같았다. 가능하다면 FE는 BE이랑만 통신하는 것이 가장 좋다. 즉 FE에서 외부서버와 통신해야만 하는 경우엔 FE에서 처리하는 것이 좋지만 우리과 같은 상황(오로지 이미지 파일을 저장하기 위한 S3서버)에선 FE에선 BE과만 통신을 하고 나머진 BE에서 처리해주는 것이 좋다는 것이었다. 그 결과 이미지 파일을 저장하기 위한 S3서버는 BE에서 관리하기로 하였다.

 

그 외에도 FE에선 카멜케이스 보단 파스칼 케이스를 사용하는 것이 좋다는 것과 같이 가벼운 내용부터 테일윈드를 왜 사용하기로 했는지 사용했을때 어떤 장점이 있는 지 등 면접에서 들을 법한 질문에 아침부터 식은 땀을 흘리기도 했다. 라이브러리를 사용할때 왜 그것을 선택했는지 어떻게 활용할지 등을 고민하고 고려해서 내 것으로 만드는 것이 중요해 보인다.

 

 

 

◆이번 WIL의 키워드

실전 프로젝트를 진행하며 기술적으로 막혔던 부분. 

 

이번 주엔 기술구현 부분에서 두가지의 처음 시도해보는 기능이 있었다.

일단 첫번째는 회원가입시 이메일 인증 방식이었다. 이 방식에 대해선 두가지 접근 방법이 있는데 한가지는 FE에서  Firebase 라이브러리를 사용하여 구현하는 방법이고 두번째는 FE에선 BE에 Email만 보내주고 response로 인증코드를 받아서 BE에서 Thymeleaf 라이브러리를 사용하여 구현하는 방법인데 이번 프로젝트에선 후자인 BE에서 처리하는 방식으로 진행하기로 하여 이메일 인증 회원가입에선 내가 하는 일은 전과 다를게 없었다.

두번째로 소셜로그인 이라는 처음 시도해보는 기술을 구현하는 과정에서 예상보다 많은 시간을 소요했다. 아무래도 외부 api를 처음 사용해보다 보니 redirect uri를 설정하는 것도 낯설고 내 코드에서 적용하는 것도 쉽지 않았다. 이를 해결하는 과정에서 구글 검색을 통해 다른 사람들이 기록해 놓은 블로그들을 참고한 것이 많은 도움이 되었다. 물론 나와 똑같은 라이브러리와 프로그램들을 사용한 사람이 없어서 많이 헤맸지만 결과적으로 해냈을 때의 성취감은 이루 말할수 없다.