프론트 주니어 2022 상반기 회고

 

 

벌써 여름이라니! 

내가 프론트 개발자 주니어라니!

벌써 입사한지 약 1년이 되어간다. 그간 많은 변화가 있었지만 정리가 너무 안되어 있어 쓰는 글✏️

 

목차

| 신규 서비스 오픈

• ⚙️ 기술적인 고민들

  1. 웹 앱간 interface 정리 및 처리
  2. 크로스 브라우징 이슈
  3. react-query 도입

• 🙏 협업의 고민

| 코드스쿼드 프론트엔드 리뷰어

| 개발 기초 다지기

• 🍿 출퇴근길에 보는 유튜브 모음

• 📒 모자스 다시 읽기

| 건강한 마음과 몸 만들기

• 🏋️ 습관적 헬스

• 🥜 심심풀이 땅콩 독서

 

 

 

 

🚀 신규 서비스 오픈

 

지난 달에  webview 신규 서비스를 오픈했다. 

중고거래에 필요한 노하우나 관련 지식에 대해 소개하는 커뮤니티형 서비스였는데 

댓글 기능과 2depth의 카테고리 22종이 포함된 6페이지 정도의 웹앱 프로젝트였다.

기술 스택	페이지 구성
TypeScript react-query recoil	메인  검색  카테고리 상세 댓글 정정 요청

기존 인원 퇴사 후, 하루가 다르게 신규 인원이 들어왔고, 나는 인수인계와 프로젝트 리드에 정신이 혼미했다.

 

코로나에 걸렸지만 프론트 개발 산정 회의에 참여해야 했고, (이거라도 안했으면 FRONT분량이 어디까지 팽창할 수 있을지 궁금하긴 하다.)

처음엔 프론트 담당자가 나 혼자였기 때문에 타 팀에서는 일정 산출과 기술적 한계들을 질문했다.

실시간 회의에서 아래 질문들이 비동기적으로 날아왔기 때문에, 실 서비스 개발 경험이 없었던 나로서는 매우 혼란스러웠다.

• 해당 기능이 기술적으로 구현 가능한지
• 가능하다면 언제까지 가능한지

나중에 팀장님께 help요청해 신규 입사 2분이 투입해주셨고, due 데이트가 촉박한 상황에서 히스토리 관리와 인수인계까지 관리하니까 정말 신이나서 혼났다.

 

 

⚙️ 기술적인 고민들

이 프로젝트는 기획 상 webview로만 노출되는 서비스였고, 그로 인해 다양한 이슈가 있었다.

 

1. 웹 앱간 interface정리 및 처리

웹뷰 페이지 공통 Header의 뒤로가기가 진입 시점에 따라 분기처리 되야 했다.

 

이 서비스는 webview에 한정적이라 진입점이 몇가지로 좁혀졌는데,

 

1. 네이티브 앱 화면에서 퀵메뉴로 접근
2. 네이티브 앱 상품 상세에서 관련 문서 상세 버튼으로 접근
3. 네이티브 앱 검색에서 문서 검색으로 접근
4. 카카오톡 공유하기를 통한 문서 상세 접근 

1) 2)

3) 4)

 

webveiw의 Header는 webview공통으로 모든 곳에서 사용되고 있었기 때문에 

기존의 기능을 가지고 있으면서도 조건에 맞는 분기처리가 필요했다.

 

 

 

기존 

react-router-dom의 history.goBack 을 사용

import { useHistory } from 'react-router-dom';

const { history } = useHistoryHook();

  const goBack = () => {
    history.goBack();
  }

 

history goback은 web에서의 뒤로가기 기능으로 동작하는데 

 

🤔 만약 내가 서비스 메인이 아닌 앱의 특정 화면에서 진입했다면?

 

위 예시중  "2. 네이티브 앱 상품 상세에서 관련 문서 상세 버튼" 으로 접근 상황이라 가정하자

사용자의 시나리오는 아래 두가지로 나뉘기때문에

 

1. 네이티브 앱 상품상세 -> wiki 문서 상세 -> (뒤로가기) -> 앱 상품상세
2. 네이티브 앱 상품상세 -> wiki 문서 상세 -> 다른 문서 *10 -> (뒤로가기 *11 ) -> 앱 상품상세

뒤로가기가 단순히 web의 뒤로가기가 아니라 webview를 끄고 다시 앱으로 돌아가는 기능도 있어야 한다.

 

 

변경

뒤로가기 후에도 변화가 없다면 closewebview interface를 쏘도록 변경했다.

history length를 이용하려고도 했지만 뒤로가기로 인해 length가 변하는 것이 아니기 때문에 해당 방법으로 진행했고,

추후 더 좋은 방법을 찾을 예정

  const goBack = () => {
    history.goBack();

    const prevPage = window.location.href;

    setTimeout(() => {
      if (window.location.href === prevPage) {
        AppInterface.closeWebView();
      }
    }, 200);
  };

 

 

 

2. 크로스 브라우징 이슈

1. flex gap 의 Safari on iOS 14버전 이하 호환 문제 

iOS 14버전 이하에선  flex gap 사용을 지원하지 않는다 ..^^

출처: https://caniuse.com/?search=gap

 

2. safari의 new Date는 (yyyy-mm-dd) 포맷을 지원하지 않는다

경과 시간을 나타내는 getElapsedTime 의 인자가 yyyy-mm-dd 를 받고 있었는데

Safari 브라우저에서는 new Date가 (yyyy/mm/dd )의 형태를 받아야 하는 것이다.

 

따라서 - -> / 로 replace하는 과정을 추가했다.

 

기존

export const getElapsedTime = (date: string): string => {
  const createdTime = new Date(date);
  const current = new Date();
  const gapMin = Math.floor(
    (Number(current) - Number(createdTime)) / 1000 / 60,
  );

변경

export const getElapsedTime = (date: string): string => {
  const createdTime = new Date(date.replace(/-/g, '/'));
  const current = new Date();

  const gapMin = Math.floor(
    (Number(current) - Number(createdTime)) / 1000 / 60,
  );

 

3.  iOS와 Android의 scroll 위치 기억 방식

상세 내용 같은 경우 내용이 길어질 때를 대비하여 더보기 접기 기능이 있고 default는 펼쳐져 있는 상태였다.

 

문제는 더보기와 접기를 할 때 안드로이드와 iOS가 스크롤 위치를 저장하고 발현하는 방식이 다르다는 것이다.

 

안드로이드는 접기를 누르면 콘텐츠가 가감된 상태의 스크롤 상태를 기억해서 해당 위치로 이동되는 한편

iOS는 컨텐츠 길이와 상관 없이 지금 내.위치에 머무른다는 것.

 

아래 첨부한 이미지를 보면 이해하기에 용이하다.

 

 

 

 

기존

버튼 클릭 시 상세 설명 영역을 토글하는 기능만 있었다면,

  const handleDescMoreBtn = () => {
    setIsDescOpen(!isDescOpen);
  };

변경

접기 click시 user 기기 관계 없이 개요 영역으로 가도록 설정했다.

  const handleDescMoreBtn = () => {
    setIsDescOpen(!isDescOpen);

    // 개요 '접기' click 시 개요로 이동
    if (isDescOpen && descRef.current)
      window.scrollTo(0, descRef.current.offsetTop);
  };

 

 

 

4. iOS의 long touch 막기

iOS의 경우 특정 요소를 길게 누를 경우 해당 web의 미리보기가 열리는데, 이건 원하지 않는 기능이었다.

관련 이슈는 아래 게시글을 통해 정리했다.!

 

https://rrecoder.tistory.com/230

webview long touch 막기( 미리보기 끄기) - iOS/Safari disable touch-callout information

 

 

 

3. react-query 도입

기존에는 useAxios라는 hook을 따로 만들어 사용할 page단에서  hook으로 api 요청하는 방식이었는데,

전체적인 web 최적화를 진행하며,  react-query의 장점을 느낀 바 시범적으로 신규 서비스에 먼저 도입하기로 결정했다.

 

• 프론트와 서버 데이터의 상태 분리
• cache 등 다양한 option을 통한 최적화

 

react-query는 간단히 설명하자면,

 서버에서 받아온 데이터를 queryClient에 캐싱해놓고 필요에 따라 component에서 전역 상태처럼 그 값을 가져와 사용할 수 있는 서버 상태 관리 라이브러리이다.

 

🔗 참고 https://react-query.tanstack.com/overview

Overview

 

 

다양한 기능을 가진 댓글 페이지 구현

 

react query를 본격적으로 도입하면서,아래 기능을 가진 댓글 페이지를 구현해야했다

 

• 무한 스크롤
• 로그인 여부 체크 후 네이티브 앱 로그인 요청 interface
• 댓글 type에 따른 filtering
• 공백 ( Enter , Space만 불가) , 글자수 1000자 제한

 

 

문제는 댓글은 사용자의 입력에 따라 새롭게 페이지를 refetch 해야하는 경우가 많고

댓글 type(3가지)이 바뀔 때마다  infinite scroll을 다시 보여주지만 뒤로가기 시 직전에 가져온 scroll 값은 기억해야 하듯이 

 

✨ 캐싱할 부분과 하지 않아야 할 부분의 구분이 확실해야했다.

 

 

 

마주한 문제점들

 

1. 사용자가 댓글을 수정,삭제 했을 때 페이지에 바로 반영되지 않음
2. 댓글페이지가 아닌, 단순히 댓글이 1개라도 포함된 페이지의 캐싱여부도 신경써야 함
3. 무한 스크롤때 요청할 type과 page에 따른 query key관리를 잘해야 함

 

해결 방안

1. 사용자가 댓글을 수정,삭제 했을 때 페이지에 바로 반영되지 않음
   • 사용자의 댓글  CRUD가 있는 경우 queryClient의 invalidateQueries 를 이용해 query 캐시 invalidate 을 설정함 
2. 댓글페이지가 아닌, 단순히 댓글이 1개라도 포함된 페이지의 캐싱여부도 신경써야 함
   • 사용자의 댓글 CRUD가 있는 경우에 해당 페이지에 새로운 내용이 바로 보여져야 할 경우를 모아 캐시 invalidate 설정
3. 무한 스크롤때 요청할 type과 page에 따른 query key관리를 잘해야 함
   • react-query는 data요청을 query key로 구분하기 때문에 type과 page를 구분값에 정확히 넣어줘야 함

 

>> invalidateQueries  예시

// 댓글 수정 요청 handler
 const handleCommentEditrequest = async () => {
  	// put요청
    await putWikiInfo({
      }),
    });

    queryClient.invalidateQueries(['wikiComment', documentSeq, curCommentType]);

    history.goBack();
  };

 

 

이처럼 react-query는 다양한 query option을 통해 캐싱 값을 가져올지, 서버 상태를 다시 가져올지를 결정할 수 있으며, 

queryClient를 직접 조정할 수 있어 팀 내에서도 긍정적인 결론을 얻었다. 물론 고생은 했다 .

 

 

 

 

 

협업의 고민

이번 프로젝트를 리딩(?)하면서 뼛속 깊이 배운 점들이 있다.

 

❓ 타 부서와 협업 시 개발 공수에 대한 질문은 어떻게 응답해야 할까?

그 자리에서 단언하지 않고 적당한 시간을 가진 후에 구체적으로 협업 tool을 이용해 전달하자

나는 아직 정확하게 일의 공수가 확인되지 않는 초심자임을 잊지 말자, 그리고 습관적으로 확실하지 않은 일정을 단언하다 보면 분명 오차가 반복적으로 발생할 것이고,  나에 대한 신뢰도도 떨어지기 마련이다. 

 

 

❓ 큰 프로젝트의 공수는 어떻게 분리해서 일정을 짤까?

페이지를  크게 세가지로 나누자  그리고 각 일정을 짜는것

 

• UI
• 로직
• 리팩토링 

 여기서 주의할 것은 해당 페이지에 새로운 기술을 도입하는지, user 유효 체크와 같은 회원 정보가 필요한지를 파악하는게 중요하다.

기획 변경과 api 개발의 딜레이는 언제든지 발생할 수 있다는 점 명심!

 

 

❓업무적 의사통은 어떻게 하는게 좋을까?

 

몇번의 미팅을 거치며 서로의 업무 방식을 공유했고 각자가 일하는 방식에 대해 이해하게 되었다.

 

실제로 기존에는 디자인팀과 개발팀은 실질적으로 어떻게 일하고 있는지 공유가 되지 않았다.

그로 인해 별다른 공유 없이 figma의 디자인 시안이 변경되면 개발팀에서 놓쳤고,

또  몇몇 개발 우선순위에 대한 공유가 부족해 디자인팀에서는 우선순위가 낮은 페이지부터 디자인을 시작해 일정 이슈를 겪었다.

 

또 디자인팀과의 의사소통 시에는 백마디 data구조와 설계보다 하나의 시각적인 자료가 훨씬 효율적이라는걸 깨달았고

이는 디자인 팀에만 적용되는게 아니라

의사 소통 시에는 상대의 이해도와 상태를 파악하고 해당 팀에서 사용하는 용어 위주로 소통하는 것🎁 이 좋은 배려라는걸 배웠다.

 

 

 

 

 

 

 

 

🚀  코드스쿼드 프론트엔드 리뷰어

나는 2021 코드스쿼드 프론트엔드 마스터즈 졸업생이다! 

내가 졸업한 것도 엊그제 같은데 벌써 2022 교육생들이 있다는게 너무 놀라웠는데,

마스터즈 졸업생 중에 코드리뷰어를 모집한다는 소식을 보고 지원하여   약 3개월 정도 활동했다.

 

 

리뷰어 활동을 통해 느낀점

리뷰어 활동을 하면서 내가 배운게 정말 많으 느낌이다.

해당 시기에 내가 어떤 마음가짐을 가지고 있었는지 알기 때문에 교육생 분들의 불안하고 지쳤던 마음이 이해가 가고,

그만큼 또 열정적일 수 있는 시기라는걸 알기에 리뷰 활동에서 다양한 내용을 공유하기 위해 노력했다.

 

 

리뷰 내용은 교육생 분들의 질문 혹은 코드 전체에 대한 개선사항과 느낀점 위주였는데,

확실하지 않은 내용은 전달하기를 지양하되, (어쩌면 가장 궁금할) 현업에서의 경험을 녹여내는 방식으로 리뷰의 방향성을 정했다.

 

정말 나조차도 잊고 있었던 기본적인 개념같은 것들을 질문을 많이 해주신 덕분에,

프론트엔드 개발자로서 당연하게 생각해왔던 것들에 물음표를 던질 수 있는 기회였다.

 

 

추가로 코드스쿼드 정말 추천하기도 입아플 정도로 좋은 경험이라서 링크도 남깁니다 🎁 

 

https://codesquad.kr/

https://codesquad.kr/

코드스쿼드 후기 : https://rrecoder.tistory.com/217

프론트 스타터 2021회고 - 어쨋든 frontEND!

 

 

 

 

🚀  개발 기초 다지기

최근에 자바스크립트에 대한 공부가 현저히 부족하다는 점을 느꼈다.

출퇴근길 (물론 30분정도로 얼마 안됨^^) 을 활용해보기로 결심했다.

 

원래도 출퇴근길에 뭐 개발 관련 가벼운 영상을 하나씩 보는걸 목표로 했었는데,

영상 리스트는 대부분의 주니어 개발자들이 보는 유튜버 스승님들을 보거나, 혹은 간혹 회사에서 진행하는 신규 프레임워크에 대한 설명이나 소개 영상을 보곤 했는데, (아래 링크 참고!)

 

출퇴근길에 보는 유튜브 모음

• 얄팍한 코딩사전

얄팍한 코딩사전

• 앨리의 드림코딩

드림코딩

• 코딩애플

코딩애플

• 노마드 코더

노마드 코더 Nomad Coders

 

 

 

📒 모자스 다시 읽기

 

언제부턴가 뭘 볼지 고민하는등의 불필요한 시간낭비가 되는 것 같고 학습 과정이 가시화 되는걸 보고 싶어서

아이패드로 모던 자바스크립트 딥다이브를 읽기 시작했다.

 

모자스는 사실 전에 스터디하면서 읽었었는데, 다시 읽어보니 새롭게 이해되는 부분이 많아서 놀라웠다.

사실 그 당시에는 정말정말 무슨 말인지 모르겠고, 하나를 공부하려 해도 연관된 지식들 전부를 몰라서 꼬리를 무는 학습에 지쳤었다.

근데 다시 마음을 가볍게 먹고 차분히 읽어보니 훨씬 이해가 잘되는 것이다! 

마치 어린왕자 소설처럼, 시간을 두고 읽어줘야 하는 서적인 듯 하다.

 

 

 

모자스 읽으면서 웃겼던 점..

나의 떠나보낸 자식들에게 매우 미안한 부분이다...

 

 

 

 

 

🚀  건강한 마음과 몸 만들기

 

🏋️‍♀️습관적 헬스

최근에 운동을 열심히 하고 있다.

사실 PT는 진작부터 했었는데 열심히 안하다가, 갑자기 열심히 해보고 싶어서

식단도 좀 하고, 운동도 주4일정도 갔더니 체지방이 1키로 빠졌다.!!!!

 

좀 느리게 빠지는 중이긴 하지만 열심히 하기로 마음 먹으니, 평생 헬스를 하고 싶은 마음이 생겨서

스스로도 지치지 않게 완급조절을 하고 싶은 마음이다.

 

운동할 때마다 붙여주는 포도알

 

 

가장 최근에 달성한 일은 스텝밀 40분이다!

처음에 10분도 올라가기 힘들었는데, 어느 샌가 40분이나 올라가는 걸 보면서 신기하고 재밌었다.

진짜 꾸준히의 힘이 중요함을 느낀것! 

 

 

코쿼인들과 애플워치 활동기록을 공유하고 있는데 

각자 운동링 채워지는게 알람오면  응원의 멘트 보내주기를 암묵적으로 하고 있다.

 

 

 

이건 일주일 7번 운동 달성 기념 !!!!!

 

 

 

🥜 심심풀이 땅콩 독서

꾸준히 하고 싶지만 쉽진 않음

독서는 그냥 목표를 두고 하지 않는중 ,, 아예 무조건 이 책은 이기간안에 다 읽을거야! 하니까 더 읽기 싫어지는 것 같고 해서

침대 옆에 두고 걍 심심할 때 5페이지 정도씩 읽는게 좋은 것 같다.

 

 

또 더현대 가서 산 무지개색연필이 있는데,

내가 좋았다 느끼는 구절에 밑줄칠 때 쓰면 그 질감과 색이 오묘해서 나름의 소소한 행복이 있다.

 

요즘 읽었던 좋은 구절!

 

 

 

 

 

🤔 그래서 나의 상반기를 요약하자면..

 

• 신규 프로젝트를 책임지면서 힘들었지만 지나고 나니 추억이었다..! 
  • 일정관리와 개발가능성에 대해 이야기 하는법.
  • 일정 산출은 시간을 두고 디테일하게 말하기. 일정에 대한 이유가 있다면 기간은 충분히 협의될 수 있다.
  • 진행하는 프로젝트에 대한 문서화는 그때그때 하기! -> 나중에 한번에 정리해야지! === 안한다!
• 협업 하는 과정을 치열하게 배운 것 같다.
  
  • 상대방의 입장과 상황을 고려하여 말하기
  • 내가 아는건 상대가 모르고 상대가 아는건 내가 모를 수 있다를 명심하기
• 번아웃이 오지 않게 나만의 방법을 만들어 가는 중
  • 정신이 힘들땐 몸을 힘들게 하기(?)
  • 그리고 운동은 재밌어!