Skip to content

2주차 멘토링

Ji Yoon Choi edited this page Nov 16, 2022 · 19 revisions

질문과 답변

1. recoil 로 설정한 전역 상태 값이 외부에 탈취될 가능성이 있을까요?

  • 100% 탈취된다
  • Github Action 등의 방법으로 캐싱 해야함
  • 로그인할 때 사용되는 ID 등의 개인정보는 최대한 막되, 백엔드 측에서 마스킹 등을 해서 정보를 은닉하여 내려줘야 한다
  • AUTO_INCREMENT 되는 키를 ID로 사용한다면 => 전역 상태로 저장되는 것은 나쁘지 않으나 브루트포스 공격에 당할 위험이 있다
    • 일반 사용자가 보기에는 아무 의미없는 숫자라서 프론트엔드 측에서 저장하는 것도 상관없어 보임
    • 브루트포스 공격을 막고 싶다면 UUID를 생성하여 사용하는 것을 추천 (AUTO_INCREMENT 아닌 완전 랜덤한 문자열)
    • AUTO_INCREMENT를 쓰는 경우 => 게시판에서 게시글이 1부터 올라가는 경우 (Public 하게 공개되기 때문에 노출되어도 상관없는 데이터)

2. 개인정보 관련 궁금증

3. Next.js 관련 궁금증

  • Next.js의 장점?
    • 첫 화면을 SSR로 구현하려고 할 때, Next.js를 사용하는 것이 좋을지?
    • 사용에 대한 조언? 적용해도 좋을지?
  • SSR을 배우기 위해 Next.js 를 배우기엔 시간이 촉박한 것 같다
  • 자료조사 까진 OK, 다만 진입장벽이 좀 있음
  • 어느 정도 완성된 프로젝트에 Next.js를 도입하는 것이 괜찮은 선택일까? 아니면 처음부터 Next.js를 도입해서 작성하는 것이 나은가?
    • getServerSideProps 에 관해 공부하는 것을 추천
    • SSR로 렌더링을 하면 기존에 요청-응답으로 받아오던 데이터가 Serverside props에 전부 들어감
    • Next.js 는 Serverside Props를 한번에 받아서 페이지에 전부 넣어 렌더링하는 방식으로 동작하므로, 관련된 이해가 좀 많이 필요하다
    • SSR 쪽에서 받아올 데이터와 CSR로 받아올 데이터를 명확히 나누는 것이 중요하다 (모든 데이터를 서버 쪽에 박는 것이 능사는 아니다) => 서버 쪽 처리가 오래 걸리면 어차피 첫 화면 표시까지 오래 걸린다
    • 이런 정책을 세우고, Next.js를 공부하는 데 들어가는 시간이 생각보다 많을 것이다 (우리는 이제 한달뿐이다)
  • Next.js의 이점: 라우팅을 더 쉽게 해준다

4. 현업 CI 과정에서 테스트를 진행할 때, 전체 코드에 대한 테스트의 커버리지 퍼센트를 넘지 않으면 push 가 안되도록 하는 단계가 있나요? 있으면 어떻게 하는지 궁금합니다.

  • push를 막는 것을 본 적은 없는데, 있을 수는 있다
    • 모든 코드를 테스트할 수 있는 것은 아님 (현실적으로 테스트를 못 하는 코드가 있음 => 이걸 테스트해보겠다고 억지로 짜는 건 더 손해)
    • Real 환경에서만 작동되는 코드가 있다면, 개발환경에서 테스트가 아예 안 되듯이
    • 따라서 어떠한 커버리지를 넘지 않으면 머지를 안 하는? 옵션은 위의 예시처럼 반례가 존재할 것 같다
  • github action coverage report 참고
    • 컨벤션 수준으로 맞추는 것과, 커버리지 숫자가 증가 추세에 있다는 것만 보이면 된다

5. CD를 위한 Github actions 를 작성해봤는데 현재 약 18분정도가 걸리고 있는데, 이 시간을 줄이는 방법에 대한 조언을 받고 싶습니다.

  • Github Action Cache
  • npm i가 오래 걸릴 것
    • 지금은 액션 명령들이 직렬로 짜여져있어서, 병렬로 분할하는 것을 추천
    • 프론트엔드 - 백엔드 별개의 Workflow, 또는 별개의 Job으로 분리하면 병렬로 동작할 것
  • runner가 nCloud 하나밖에 없어 병렬 실행이 안 될듯
    • 병렬 실행은 runner가 2개 이상이어야 함
  • 해결법
    • self-hosted를 쓰지 말 것
    • 빌드는 깃허브에서 제공하는 runner를 사용
    • 빌드 결과물을 깃허브에 임시 저장 (github actions artifact upload)
    • nCloud는 artifact에 저장된 내용물을 갖다 쓰기만 하고, 빌드는 github에서 제공하는 runner를 사용하면 병렬 빌드로 시간을 많이 줄일 수 있다
    • nCloud CPU 사양 (개수 등) 설정이 가능 => CPU 개수가 늘어나면 속도가 좋아질 것이다
    • CPU 성능 문제로 느린 것일 수도 있다
  • CI/CD는 어렵구나!!!

6. 백엔드와 클라이언트에서 공용으로 사용하는 공용 상수를 어떻게 관리해야 하는지 궁금합니다.

  • https://github.com/boostcampwm-2022/web25-SCOPA/issues/25
  • 모노레포?
    • yarn workspace monorepo
    • 클라이언트가 서버 share 폴더를 참조할 수 있고, 서버가 클라이언트 share 폴더를 참조할 수 있다
  • 현재 파일구조로는 아마~ 참조는 할 수 있음
    • 단 현재 파일구조에서는 shared 폴더는 어떤 컨벤션을 따를지, 어떤 typescript 버전을 쓸 지 알 수 없는 상황이다 (클라이언트 - 서버 구조가 분리되어 있는 편)
    • 루트 경로에 eslint, tsconfig, prettier 등을 배치해서 컨벤션과 타스 버전을 맞춰놓고, 하위 폴더를 클라이언트 / 서버로 분리하는 구조로 해야 할 듯

7. 프론트엔드에서 기술적으로 눈에 띄일 수 있는 추가 기능으로 무엇이 있을지 고민됩니다

  • 기술적으로 도전할만한 요소가 있을까요?
  • 반응형 웹 => PC, 모바일을 하나의 컴포넌트로 처리하기 (이것만으로도 쉽지 않을듯)
  • 페이징, 상태관리는 이미 적용해봐야 하는 기술일 듯
  • 이정도면 Next.js를 도입해볼 만도 할 것 같고
  • 채팅?
    • server sent event: 서버와 클라이언트간 연결이 계속 열려있고, 서버에서 이벤트가 발생하면 계속 응답을 주고, 클라이언트는 계속 그 응답을 받음
      • 단방향 으로밖에 통신이 이루어지지 못함
      • 서버 쪽에서도 기술 검증이 좀 필요해보임
    • push API 는 어떨까요? => 서버 - 클라이언트간 연결이 계속 열려있진 않고, 구글 서버를 중간 브로커로 두고 브라우저에 이벤트를 쏘는 방식
    • 프론트엔드에서 10초에 한 번씩 추가 채팅이 있는지 백엔드에 찔러보는 것도 하나의 방법이며 매우 간단한 방법 중 하나 (마지막으로 읽은 쪽지의 ID 등을 서버에 계속 찔러주는 방식)
    • 시간이 남는다면 채팅 정도는 구현해볼 만 할 것 같아요
  • 이런 기술들도 다 사용할 때가 있다
    • 동시 접속 문제 등 하위에 파생되는 문제점과 그걸 해결하는 과정으로도 많이 배울? 수 있음
  • 채팅의 변형판 => 쪽지? 댓글?

소켓을 도입한다면 서버를 분리해야 하나요?

  • 이번 프로젝트에서는 그럴 필요까진 없을듯
  • 실제 서비스라 가정하면 분리하는 것이 좋다는 것을 염두에 두고 이야기를 해보는 것이 바람직함
    • scale-out
    • 두 서버 중 한 쪽이 죽는다고 해서 다른 한 쪽이 죽으면 안 되므로?
  • 지금 프로젝트에서 그것까지 구현하는 건 오버스펙이다
    • 현실적인 한계
    • 서버비가 없음

Next.js 도입 이유?

  • 서버사이드 로직을 직접 구현하기에는 레거시가 너무 커짐 + 관리비용이 큼
  • Next.js는 검증된 라이브러리, star 수가 많고 전세계적으로 널리 이용됨
  • Next.js가 지원하는 SSG 도입하기에 안정적일 경우
  • 나 이거 해봤다 보다는 어떤 생각과 어떤 경험을 하는지, 어떤 어려움이 있었고 극복했는지가 더 중요하다
    • 위에서 시키는 사람 아무도 없지만 각자 주도적으로 할 일을 찾아 작업하는 태도가 더욱 중요하다

현업에서의 merge 충돌 해결 방법

  • 맡을 부분을 명확히 나누는 것이 1차 => 컴포넌트 레벨에서는 충돌이 나지 않을 것
  • presentational 부분에서는 같이 충돌 제거
  • 같이 쓰게 될 데이터나 데이터를 담는 인터페이스 등 => 시니어가 먼저 작업해서 전부 올려둠
    • 같이 작업하면 1000% 충돌남, 먼저 작업을 해서 올려놔야 분업 후에도 참고해서 작업함
  • 위의 내용은 원론적인 얘기; 그때그때 의사소통이 중요
  • 공통으로 사용할 요소들을 각자 만들다가 share로 올리는 등

Typescript enum

  • Typescript enum 관련해서 Tree-shaking 관점에서 좋지 않아서 enum 을 사용하지 않는 것을 권장하는 글을 봤습니다.

    • 실제로 현업에서도, enum 을 사용하지 않고 있나요?
    • 만약 사용하지 않고 있다면, enum 과 같은 열거형 상수를 필요로 할 때 어떤 방식으로 사용을 하시는지 궁금합니다.
  • const enum을 사용하면 용량을 조금 더 줄일 수 있다

  • 예전과 달리 네트워크 성능와 압축 기술이 좋아짐

    • HTTP2에서는 용량을 이미 줄이고 있음
  • 자바스크립트 코드가 압축 후에도 MB 단위로 나온다면? 그 때는 트리쉐이킹을 체크해야 함

    • lodash 라이브러리에서 이 문제가 좀 발생하기 때문에 이를 위한 웹팩 설정 작업 등을 해야 할 것
  • enum 이 찝찝하면 const enum, 이것마저도 찝찝하면 객체 상수로 만들어 사용

  • readonlyArray 는 잘 안 쓰는 방식인데, 써도 나쁠 건 없을듯

    • 어떤 함수에서 값을 수정해버리면 side-effect가 발생할 수 있는데, 이런 실수를 막는 차원
    • 다만 이 함수를 전달할 때 readonly를 전부 붙여줘야 한다는 단점이 있음 (코딩 효율 저하?)
    • 그래서 일반적으로는 잘 안 씀
  • 기술 도입 또는 리팩토링 시에 자료조사, 예시, 우리 팀에 도입하면 어떤 장점이 있을지 설명, 일부 코드만 리팩토링해서 시연 등 필요

    • 왜 썼는지가 더 중요하다는 뜻
    • 기술 도입 또는 리팩토링에 부정적인 생각을 갖는 사람들도 설득시킬 수 있을 정도로 설명을 잘 해야한다

얼리버드

프로젝트

개발일지

스프린트 계획

멘토링

데일리 스크럼

데일리 개인 회고

위클리 그룹 회고

스터디

Clone this wiki locally