2주차 멘토링

질문과 답변

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

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

2. 개인정보 관련 궁금증

• https://github.com/boostcampwm-2022/web25-SCOPA/issues/26

• 약관을 추가하여 너의 닉네임과 이메일을 어디에 사용하겠다 ~ 라고 명시

• 개인정보 약관 관련 질문은 멘토링하면서 처음 받아보았다

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
• Typescript enum 관련해서 Tree-shaking 관점에서 좋지 않아서 enum 을 사용하지 않는 것을 권장하는 글을 봤습니다.
  • 실제로 현업에서도, enum 을 사용하지 않고 있나요?
  • 만약 사용하지 않고 있다면, enum 과 같은 열거형 상수를 필요로 할 때 어떤 방식으로 사용을 하시는지 궁금합니다.
• 모노레포?
  • 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 도입하기에 안정적일 경우