HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
🐣
프론트엔드 데브코스 3기 교육생
/
🎀
동영팀
/
☕
1월 8일 커피챗
☕

1월 8일 커피챗

날짜
Jan 8, 2023
요약
유형
커피챗

🍲 저녁

  • 분짜 하노이 땅땅땅

🔥 순요님 근황

  • 적응을 잘 해서 다닐만 하다.
  • 특별히 어려운 점은 없다.
  • 아직 회의할 때 못알아 듣는 내용이 많이 있는데, 그러려니 하고 지나가고 있다. 👍🏻

🐛 멘토님은 버그 해결사~

  • 3명 제외하고 미국 가셨다..
    • 사내 해커톤 마냥 프로젝트 하고 있다!
    • flutter 기반으로 하고 있다.
  • js도 점점 파편화가 되어간다.
    • 파이썬 생태계가 이미 그러하다.
  • react native 는 네이티브와 연결해주는 브릿지 역할
  • flutter 는 엔진이 있고 엔진이 페인트해주기 때문에 덜 종속적이다.
  • 성능을 생각하면 react native가 더 좋지만, 그런걸 감안해도 flutter가 빠르다.
👀
멘토님 왈 ) 기술은 쉽게 죽지 않는다. 2G도 일상 속에 살아이따..크..

💻 맥북으로 바꿔야할까?

  • 굳이 내 돈으로 바꾸지 않아도 된다.
  • 나중에 회사에서 윈도우 vs 맥 선택할 수 있다.
  • but 내 돈 주고 사기 비싸니까.. 기왕이면 회사에서 맥북을 받아서 익혀라!
  • 결론 : 회사에서 받아서 적응하자!

🌼 사이드 프로젝트에 관하여

  • 사이드 프로젝트의 프론트엔드 리드를 하고 있다.
    • 이왕 제대로 하고 싶은데.. 3분다 잘하시는 분이라 기술적으로 주도적으로 할 수 있는 것이 없다.
    • 작업이 생기면 주도적으로 분배하고, 회의 진행을 한다.
    • 작업 밀리는 것 같으면 관리를 한다.
  • 매니징 관련하여 여러 레퍼런스가 있다. (리드에는 여러 유형이 있다.) 각자 맞는 리더가 있다.
      1. 행동형 리더
      1. 전략형 리더
      1. 지원형 리더
      등등..
  • 사람마다 이 팀에 얼마나 영향을 끼칠 수 있는지가 다르다.
  • 멘토님 생각은 주영님이 부족한 점을 잘 보완하고 있다.
  • 주영님이 리더로써 역할을 하지 않았을 때 어떤 문제가 발생할건지를 생각해보자!
  • 시너지를 높이기 위해 각 팀원들의 장점을 살려 업무를 분배시키고, 세 사람의 작업이 배가 될 수 있도록 했다.
  • 잘한 일
    • 적극적으로 기술 논의를 하는 팀이다.
    • 이런 논의를 슬랙으로 하고 있었다. ⇒ 날라감.
    • 인수인계가 잘 되어야 하는 조직인데, 깃헙 레포 디스커션을 도입했다.

📊 플로우차트

  • 플로우 차트는 너무 구체적이다.
  • 기능 하나가 달라지면 쓸모가 없어진다.
  • 추상화 정도(레벨)를 맞추기가 어렵다.
  • 스크린 플로우 (화면 이동 설계) / 구조도 (아키텍처)를 그려라!

🗂 라이브러리

  • 라이브러리를 직접 만들어야겠다고 생각했다.
  • 어떨 때 라이브러리를 써야할지
  • 어떨 때 직접 구현하는게 좋을지
  • 라이브러리 도입 시 고려해보면 좋을 것들
    • 다운로드 수
    • 최근까지 잘 유지관리가 되고 있는지
  • 라인 면접 때 받은 질문이었다.
    • 라이브러리를 선택하는 기준이 있는가?
      1. 릴리즈 주기
      1. 출시돼서 얼마동안 운영되고 있는지 (기간)
      1. 메인터넌스 주기 (릴리즈가 한달에 한번 되는지 등)
          • 마스터를 보면 어제인데, 가장 최근 릴리즈를 보면 어제
          • 결국 릴리즈가 중요하다. (퍼블리시가 되어야 함)
          • 마스터를 가져오려면 클론해서 직접 빌드해야한다.
          • 패키지 관리에 있어 신경써야하는 포인트가 하나 더 들어나는 것이다.
      1. 팀원들의 러닝커브도 고려해야 한다.
      1. 서비스에 적합한 라이브러리
      1. 소프트웨어 라이선스를 잘봐야 한다.
          • GPL : 이 라이브러리를 가져다 쓰면 프로젝트를 전부 전체 공개를 해야 한다.
          • 회사에서 가져다쓰면
      1. 우리의 요구사항들을 다 만족시키는가
  • 팀에서 쓰는지, 개인으로 쓰는지에 따라 다르다.
    • 개인은 핫한 것들,
    • 팀에서는 좀 더 보수적 접근해야 한다.
  • Husky
    • 라이선스 관련해서 크게 논란이 있었다.
    • 6버전 라이선스를 바꿨는데, 기업에서 쓰려면 유료버전으로 써야한다.
    • 그래서 멘토님은 회사에서 쓸 때 5버전으로 내렸다..
  • github unlicense 코드들은 가져다 쓰면 안된다.
    • 명시적으로 물어보고 허락을 구해야 한다.
  • 토스
    • 라이브러리 도입할 때 장단점을 논의한다.

    상태관리에 관하여

    • 전역 상태관리에 의존하기 시작하면 안티패턴을 만들 수 있다.
    • 리액트의 장단점이 잘 들어나는 문제이다..
    • context
      • 보통 2개를 세트로 만든다.
      • 상태를 업데이트하는 함수가 있는 context / 상태를 업데이트하는 context
    • 모두가 쓰니까 나도 쓸 수 있어야한다도 맞는 말이고, 모두가 쓰기 때문에 안쓰고 구현하는 방법도 알아야 한다.