일일 아티클 ( 09.01~ now )

2021년

9월

• 9월 1일(수) React Query로 서버 상태 관리하기

  • react-query는 서버상태를 관리하는 라이브러리다.

  • 서버 상태는

    • 원격 위치에 저장 / 앱이 소유하거나 제어하지 않는다
    • 비동기 API로 데이터를 CRUD한다
    • 다른 사람과 함께 사용한다 => 내가 모르는 사이에 업데이트 될 수 있다.
    • 앱에서 사용하는 데이터가 유효 기간을 지닐 가능성이 있다.

  • 필요한 작업

    • 캐싱
    • 서버 데이터 중복 호출 제거
    • 만료된 데이터를 백그라운드에서 제거하기
    • 데이터가 언제 만료되는지 알고 있기
    • 만료된 데이터는 가능한 빨리 업데이트하기
    • 페이지네이션, 레이지 로딩 데이터의 성능 최적화
    • 서버 상태의 메모리 관리 및 가비지 콜렉션
    • 쿼리 결과의 구조 공유를 통한 메모이제이션

  • react-query는 이런 기능을 사용하도록 도와준다!

  • redux와 달리 서버 상태를 다른 장소에 저장할 필요 없다. 함수형 컴포넌트에서 hooks 형태로 사용!

  • useQuery 훅에 파라미터를 통해 API 데이터의 만료 시간 / 리프레쉬 간격 / 데이터를 캐시에서 유지할 기간 / 브라우저 포커스시 데이터 리프레쉬 여부 / 성공 or 에러 콜백 등 제어 가능

  • 자세한 사용법은 본문을 다시 읽자

  • useQuery는 queryKey, queryFunction, options를 파라미터로 갖는다

    
    

• 9월 2일(목) alert() 가 사라진다?

  • alert(), confirm(), prompt()를 크롬에거 제거할 계획 발표!

  • 해당 기능으로 팝업되는 대화 상자는 브라우저 자체 UI처럼 보일 수 있고, spoofing에 악용될 수 있다.

  • 대부분의 개발자가 반대하고 있다고 한다. 여러 이유가 있지만 구글이라는 하나의 회사가 웹이라는 플랫폼을 건드리는 것에 반대하고 있는 듯.

    
    

• 9월 3일(금) 개발팀이 일을 매듭 짓는 방법

  • 기획 / 디자인 / 개발 / QA / 배포
  • QA는 “Quality assurance”의 약자로 품질 보증을 의미한다. 해당 제품이 정의한 수준의 품질을 보증할 수 있도록 배포 전 테스트, 검수하는 작업
  • QA는 최소한의 업무 평가 기준을 제시한다. QA가 예측 범위 내에 문제 없이 잘 처리 되었다 => 프로젝트가 시작부터 끝까지 별탈 없이 진행 되었다
  • 초반에는 러프하게 필요한 경우에만 QA를 진행했지만, 어느정도 안정화가 된 이후에는 신기능/수정 사항 모두에 QA 진행
  • 유저 스토리 작성, 노션 테이블로 만들어서 테스트
  • 앱 배포는 IOS는 심사 단계가 있고, 안드로이드도 스토어에 반영되는 시간이 있는데다가 유저가 업데이트를 해야 반영이 되기 때문에 QA가 매우 중요하다
  • 웹과 서버는 바로바로 반영이 가능하다
  • 배포 시 문제가 터질 수도 있다는 두려움이 배포를 망설이게 한다. QA를 충분히 거친다해도 놓친 부분이 있을 수 있다.
  • 코드 퀄리티 관리는 프로젝트 시작 단계부터 시작한다.
  • 개발자가 기획, 아이디에이션 단계에 적극 임한다
  • 
    

• 9월 4일(토) 웹 성능을 위한 이미지 최적화

  • 웹 페이지의 대부분의 용량을 차지하는건 당연히 이미지이므로, 최적화를 해야한다

  • 빨라지고 / 서버 공간 절약 / SEO 모바일 응답성 점수 증가

  • 1. 불필요하게 큰 이미지 폭 조절. 일반적을 가로 1000px 이상은 불필요함
    • 4032x3024 - 2.7MB
    • 800 x 600 - 133KB
  • 2. 이미지 포맷
    • 카메라로 찍은 실제 사진은 JPG / 만들어진 이미지는 PNG가 용량이 작다
    • JPEG / WebP / AVIF 등 고려하자
    • 브라우저가 AVIF를 지원하면 AVIF를 사용하고, 그렇지 않은 경우 WebP, 그렇지 않은 경우 PNG 또는 JPEG의 사용.
    • picture / source / img 태그 활용
  • 3. 이미지 고정값
    • 치수가 없는 이미지는 Reflow를 발생시킨다.
    • width/height 속성을 항상 포함하거나, aspect-ratio를 잡아야 한다.
    • 이 방법을 사용해서 이미지가 로드되는 동안 브라우저가 문서의 공간을 미리 할당한다. (같은 크기의 스켈레톤 UI)
    • 반응형의 경우 width/height 고정값 대신 비율값을 사용하는데 이미지 다운로드가 시작되고 브라우저 크기가 결정되는 경우에만 가능하다.
  • 4. 여러 버전의 이미지 제공
    • img 태그의 srcset, sizes 속성을 사용하자
    • 브라우저가 지원하지 않으면 fallback으로 src 속성이 동작한다.
    • 일반적으로 3~5개의 다른 크기의 이미지를 준비한다
  • 5. 이미지 크기 조절 툴
    • sharp npm package / ImageMagick CLI tool 등을 사용
    • 서버에서 이미지를 제공할 때 사용
  • 6. Image CDNs
    • 이미지 파일 크기를 40 ~ 80% 줄일 수 있다!
    • CND은 이미지 변환/최적화/전송 전문
  • 7. Css Sprite
    • 첫 로딩 속도를 줄여주는 방법 중 요청 횟수를 최소화하는 것
    • 주로 아이콘/버튼 이미지는 자주 쓰이기 때문에 한 번에 받아오고 배경 이미지로 사용해서 position값을 조절해서 사용한다
  • 8. Lazy loading
    • 페이지 로드시 모든 이미지가 아니라 당장 필요없는 자원 요청을 미루고, 필요할 때 받아오는 것
    • 데이터 낭비를 막고 브라우저 렌더 시간을 줄인다.
    • img 태그에 loading="lazy"을 사용한다.
    • 이 경우 이미지 영역의 크기를 지정하는 것이 권장된다.
    • 지정하지 않으면 해당 영역 크기를 알 수 없어서 처음 크기를 0x0로 인식하기에 로드가 이미지되면 layout shift가 일어날 수 있다.
    • 첫페이지 시작부터 보이는 이미지에는 loading="lazy" 사용 금지
    • background-image에서는 적용 안 됨
    • 혹은 intersection Observer API 사용

  • 웹사이트 성능/속도 분석 사이트

    • Pingdom / Google PageSpeed Insights / Google Lighthouse
    
    

• 9월 5일(일) { tsconfig.json } 제대로 알고 사용하기

  • 이전에 한 번 공부했던 tsconfig.json에 대해 복습겸 훑어보자

  • tsc는 tsconfig.json이 없어도 사용할 수 있다. tsconfig.json을 설정하는 이유는 매번 tsc 명령어에 옵션 주기도 힘들고, 프로젝트에서 일정한 설정을 유지하기 위해서이다.

  • vscode 에디터 상에는 에러가 나오지 않지만 정작 tsc를 통해서 컴파일을 시도하면 에러가 날 수도 있고 그 반대의 상황이 나올 수도 있다.

  • files : 원하는 파일만 tsc의 대상으로 지정

  • include/exclude : 원하는 파일 목록의 패턴을 지정/제외 할 수 있다.

  • lib는 typescript가 그런 문법과 기능이 있다는 것을 알게 해주는 것이지 runtime에 해당 기능을 추가해주는 것이 아니다.

  • babel-loader는 tsconfig.json를 필요로 하지 않고 자체적으로 컴파일한다. 컴파일 옵션을 따로 줄 때 isolatedModules 는 꼭 true로 설정해야한다

    
    

• 9월 6일(월) 야 너두 자동 배포 할 수 있어 with AWS CodeDeploy

  • 우테캠 종호님이 작성하신 아티클을 읽어보자!

  • AWS CodeDeploy의 장점 4가지

    • 배포 진행 상황을 모니터링 할 수 있다
    • (거의) 무료다
    • 가동 중지 시간을 최소화 시킬 수 있다
    • 동시 배포를 할 수 있다.

  • Blue-Green deployment. 라이브 환경을 Blue, 새로운 환경을 Green이라 해서 Green에 배포하고 에러 검출이 되지 않으면 traffic을 Green으로 옮기는 배포 전략

  • 1. CodeDeploy 사용을 위한 EC2 IAM 인스턴스 프로파일 생성
  • 2. EC2에 CodeDeploy agent 설치
  • 3. CodeDeploy 애플리케이션 생성
  • 4. Github Action workflow 를 위한 yml 파일 생성
  • 5. CodeDeploy Action을 위한 appspec.yml, script 파일 추가
    
    

• 9월 7일(화) 베일 벗은 카카오웹툰, 혁신과 낯섦 사이에서

  • 혁신은 기대를 충족시키지 못 하면 그저 구호화가 되는 단어이다.

  • 멘탈모델 : 인터페이스가 어떠한 방식으로 작동할 것이라 유추하는 인간의 사고 과정

  • 웹툰 IP가 드라마/영화화 되는 등 2차 콘텐츠로 제작 되고 있다. 웹툰이 정적인 모습을 고수할 이유가 사라졌다!

  • 유저는 유사한 서비스에서 기존의 멘탈모델과 유사한 UX를 기대한다. 즉 멘탈 모델은 혁신적인 UX의 걸림돌이 된다.

  • 카카오웹툰은 멘탈모델을 꽤 벗어나면서 낯설지 않은 UX를 만들어냈다.

  • Y축 이동은 사용자에게 불편함을 줄 수도 있지만, 특정 부분이 아닌 앱 전반에 Y축에 대한 고민/적용이 있기에 UX 콘셉을 만들 수 있었다.

    
    

• 9월 8일(수) AWS 1755만원 요금폭탄 맞았다..!

  • AWS 과금 폭탄이 발생?하면 고객센터에서 전화가 온다.. 국제전화라고 무조건 안 받기보다 내가 AWS를 사용중이라면 한 번쯤 받을 생각을 해야 할지도..

  • 무조건 환불해주는건 아닌가보다. 100만원 어치 과금받고 환불 받지 못 한 케이스도 있는 듯..

  • 역시나 개인키 노출로 인한 문제! 이분은 결국 잘 해결된거 같다. AWS 사용시 개인키 노출을 절대로 절대로 조심하자

    
    

• 9월 9일(목) Typescript 4.4에 추가된 기능

  • alias 된 조건문과 판별문 흐름 분석을 컨트롤
    • typeof를 사용해서 해당 변수의 타입을 확인 한 경우 이후에서 그 타입을 인지하는 기능이 추가 되었다.
    • const argIsString = typeof arg === "string" 이후에 argIsString으로 분기 처리를 한다면, true인 경우 그 안에서 arg의 type은 string이 된다.
  • 인덱스 서명에 Symbol과 Template String 패턴을 사용할 수 있음
    interface Array<T> { index: number } : T. 이전까지 인덱스 서명은 string/number만 가능했는데 이제 Symbol/Template String도 추가 됨
  • strict 옵션이 켜졌을 때 try-catch의 err의 기본 타입이 unknown
    • 기존에는 any였다!
  • Exact Optional Property Types
    • ?를 사용해서 optional한 프로퍼티의 경우 undefined로 인식을 한다. 이것이 undefinded라는 "값"을 갖는 것인지 / 아예 존재하지 않는 것인지 (delete keyName)을 명확히 해주는 옵션
  • Class에서 static 블록 지원
  • inlay hint 지원
  • 자동 import가 목록에서 실제 경로를 보여줌
    
    

• 9월 10일(금) 프론트엔드 개발자라면 반드시 알아두어야 할 32가지의 UI 요소 (번역)

  • 32가지 UI에 대한 글. 옮겨적기보단 한 번 쓱 감상하자

  • UI는 크게 4가지로 나뉜다

    • Input Controls : 유저가 시스템에 정보를 입력
    • Navigation Components : 유저의 제품/웹사이트 이동을 안내한다
    • Informational Components : 유저에게 정보를 제공한다
    • Containers : 관련 컨텐츠를 묶는 역할을 한다.
    
    

• 9월 11일(토) 리액트 useEffect: 개발자가 알아야 할 네가지 팁

  • useEffect는 하나의 기능만 담당하도록 분리해야한다

  • 커스텀훅 내부에서 상태까지 관리하는 구조를 생각해본다.

  • useEffect의 callback 함수가 return하는 함수는 cleanUp 함수이긴하지만, early return을 해도 상관 없다

  • 의존성 배열을 비우는 경우는 가급적 피해야한다. 코드가 더 확장되거나, 변경 사항이 있을 때 추적하기가 힘들다. (깨진 프롭 or 클로저)

  • useEffect 콜백 함수 내부의 디펜던시는 반드시 의존성 배열에 추가하고, early return을 통해 해결하는게 옳은 방법이다.

    
    

• 9월 12일(일) 웹 서비스가 사용자를 판별하는 법

  • 일반적으로 인증을 원하는 주체는 사용자이며, 로그인시 발급받은 토근으로 사용자를 인증, 서버에서 데이터를 받는다. 쿠키 등을 통해 stateless하더라도 동일한 사용자인지 알 수 있다.

  • 인증이 필요 없고 사용자가 자신을 노출하고 싶지 않은 경우, 익명 브라우징(크롬 시크릿 탭 같은)을 사용할 수 있다. 서버 입장에서 동일한 사용자인지 알 수 없지만, 여전히 IP address 등은 노출되어있다. 이것마저 막으려면 VPN 등을 사용한다

  • VM 등을 통해 익명화 된 여러 요청을 하나의 사용자로 인지하기 위한 기술로 Device fingerprinting을 사용한다

  • 공격 뿐 아니라 개인 맞춤형 광고를 위해서 사용할 수도 있다.

  • webGL fingerfrinting.

    • Canvas의 WebGL 기능을 활용한다
    • Canvas에서 entropy가 비교적 높은 이미지를 렌더링 할 때 폰트 정보, 이미지 패턴 정보들에 약간의 차이가 있는데, 이 값을 hash 값으로 뽑아낸 것이 WebGL이다.
    • 다른 디바이스더라도 이 차이 없이 동일한 경우도 있으나, 확률이 낮다 (대략 1%이하?)
    • 현재는 속도 문제로 사용하기 어려울 수 있는 복잡한 패턴도 디바이스 성능 향상 / 머신러닝 등을 활용해서 해결할 수 있을 것으로 전망된다.
    • 물론 그 만큼 이 기술을 막는 Tor browser, 기능을 무력화하는 플러그인 등도 발전한다
    • 애플에서 사용자 정보 추적 금지가 default가 되었다. 그만큼 사용자 판별은 광고에 있어서 중요한 이슈이다.
    
    

• 9월 13일(월) 이미지 최적화의 모든 것, 최고의 완벽 가이드 - 1부

  • 볼품없는 디자인보다, 느린 사이트가 웹 서비스 이탈율에 더 큰 영향을 미친다

  • 세계적인 비즈니스를 지향한다면, 생각보다 많은 나라의 인터넷 속도가 평균 이하라는 것을 인지해야한다.
    -또한 사용자는 여러 대의 기기를 동시에 사용해서 웹 서비스를 소비한다. 그렇기에 디바이스별 최적화 이미지도 중요하다

  • 이미지는 페이지의 서버공간 46%를 차지한다는 통계가 있다.

  • 모바일 우선 인덱싱이 SEO에 큰 영향을 미치고, 이는 이미지 최적화도 관련되어있다.

  • 이미지 크기 줄이기 / 파일 크기 줄이기

  • 파일 크기 줄이기는 무손실 이미지 압축을 목표로 한다.

  • 이미지 파일은 이미지 자체보다 더 많은 데이터가 포함되어 있는데, JPEG/PNG의 경우 메타데이터, 기타 정보 등이 있다. 이 추가 데이터들을 제거/최소화한다. 단 이는 표면적인 방법이다

  • 웹 페이지의 이상적인 전체 이미지 크기는 1~2MB 사이다.

  • 무손실 압축은 이미지 표시에 필요하지 않은 데이터만 제거하고, 손실 압축은 페이지에 이미지를 표시하는데 사용되는 데이터까지 제거한다. 대부분의 경우 무손실은 되돌릴 수 있지만, 손실은 불가능하다

  • 크로마 서브 샘플링(Chroma subsampling)

    • 인간의 눈이 이미지 색상 세부 사항보다 이미지 휘도에 더 민감함을 이용함을 이용한다
    • 휘도는 이미지 흑백 콘텐츠를 말한다
    • 색상, 크로마 관련 일부 데이터를 제거하지만 인간의 눈으로 차이를 인식하기 힘들다.

  • 허프만 코딩(Huffman coding)

    • 알고리즘을 사용한 무손실 압축
    • 파일의 코드 구성이 간소화되어 비효율적인 코드로 인한 초과 파일 크기가 제거

  • 파일 형식

    • 래스터 이미지(Raster images)
      • 인간이 지각할 수 있는 수준을 고려해서 dpi를 조정한다
      • 사진, 스캔한 그림, 기타 예술 작품, 매우 상세한 그래픽 이미지 등에 적합하다
      • 필요하면 벡터로 변환 가능
      • PNG, APGN, JPEG, JPG, JPEG 2000, JPEG XR, JPEG XL, GIF, HEIC, WebP, PSB, BMP 등
    • 벡터 이미지(Vector images)
      • 수학 공식으로 표현된 이미지
      • 축소, 확대에 품질 변화가 없다.
      • 그래프, 차트, 단순한 선, 아이콘 등의 이미지에 적합하다
      • SVG, VSTM, AI, XAR, CDR 등
    
    

• 9월 14일(화) 이미지 최적화의 모든 것, 최고의 완벽 가이드 - 2부

  • 온라인 이미지 최적화 도구

    • 편리하지만 개발측에서 서비스를 종료하면 더 이상 사용할 수 없다.
    • 압축 결과에 제한적일 수 있다.
    • TinyPNG / Optimiailla / Compressor / Compressnow / SVGminify / Squoosh /

  • 독립형 최적화 앱

    • 장치에 다운로드 해서 사용할 수 있다.
    • 압축률이나 최적화 매개변수를 더 효과적으로 제어 가능하다
    • 단, 무료일 가능성이 낮다.
    • PNGGauntlet / ImageOptim /

  • 이미지 소프트웨어 내 최적화

    • 이미지 소프트웨어 자체 최적화 기능을 사용하는 것
    • 플러그인 / 애드온

  • CMS(콘텐츠 관리 시스템) 내에서 최적화

    • CMS의 대표적인 예시로 WordPress가 있다.
    • WordPress의 각종 플러그인 EWWW / Imagify / Optimole / Shortpixel / Smush / WebP Converter for Media

  • 대량(일괄) 이미지 크기 조정 도구

    • 위에 언급한 도구들도 대량 이미지 처리가 가능하지만, 그 보다 더 많은 작업을 수행할 수 있는 이미지 도구들
    • Bulk Resize Photos 같은 경우 한 번에 최대 150개의 이미지를 처리할 수 있다.

  • 이미지 축소 도구

    • CLI / Gulp / Webpack / Parcel
    
    

• 9월 15일(수) 국제화(i18n) 자동화 가이드

  • 일반적으로 gettext를 활용한 라이브러리, i18next 등을 사용해서 key를 받아 번역된 문자열을 리턴하는 함수를 이용했다.

  • key를 사용하는 방식은 번역할 문자열이 많아지면 개발,기획,번역 간의 협업 비용이 많아지고 배포마다 진행해야하는 불편함이 있다.

  • 기존 국제화 프로세스에서 수작업이 필요한 과정은

    • key 관리 모듈에 key 직접 추가해야 함.
    • 추가된 key를 엑셀에 직접 추가, 번역가에게 해당 파일을 메일로 전달
    • 번역된 파일을 메일로 전달받아 번역된 문자열을 copy & patse 해야함. 언어의 종류만큼

  • 구글 스프레드를 사용하면 파일을 메일로 주고 받을 필요가 없다. 이를 기반으로 자동화 도구를 추가해서 반복적인 작업을 자동화한다

  • 소스 코드에서 key를 스캔, 추가된 key를 구글 스프레드 시트에 업로드

  • 소스 빌드 시 스프레드 시트에서 번역된 문자열 다운받아서 빌드

  • 자세한 방법은 본문을 참조하자.

    
    

• 9월 16일(목) Preload의 개념, 그리고 올바른 사용법

  • 웹 사이트 방문시 필요한 리소스를 동시에 요청하고, 서버는 요청 순서가 아닌 처리 완료 순서로 응답을 한다.

  • 이 때 특정 리소스를 빠르게 로딩하기 위해 우선순위를 부여하는 방법을 preload라고 한다.

  • HTML파일의 head 태그에 rel="preload" 속성을 추가하면 된다.

  • 단 preload로 선언하면 해당 소스를 실제로 사용하지 않더라도 무조건 서버로부터 요청, 다운로드 한다. 반드시 초기 로드에 사용되는 요소에만 적용하자

  • 그렇다고해서 초기 로드에 필요한 요소를 모두 preload로 하는 것도 좋은 방법은 아니다. preload는 전체적인 웹 성능 향상을 위해서 사용하는게 아니라, 비즈니스에 따라 빠르게 로딩해야 하는 특정 리소스만을 위해사용 하는 것임을 명심하자

  • 예를 들어 SEO 최적화 중 하나로 Core web vitals의 LCP 수치를 높이기 위해서는 페이지 내 가장 큰 컨텐츠 요소를 빠르게 로딩시키는 것이 중요하다. 이를 위해 큰 영역을 차지하는 이미지만 preload한다면 비즈니스적 이점을 얻을 수 있다.

  • 이런 SEO가 중요한 서비스가 아니라면, webfont에 preload를 걸기도 한다.

    
    

• 9월 17일(금) [2021.06.11] Production Environment에서 SourceMap 보안 이슈 해결

  • 일반적으로 배포 버전에는 sourceMap을 포함하지 않는게 정석이다.

  • Next.js 환경에서 유저 환경에서 Error 발생시, sentry를 통해 어떤 부분에서 에러가 발생했는지 확인할 필요가 있다. 따라서 Sentry 환경에 sourceMap을 업로드한다. 이를 위해 SentryWebpackPlugin를 사용해서 SoureceMap을 임의로 생성하는데, 이 때 Sentry 환경 뿐 아니라 Production 환경까지 올라가서 보안 이슈가 발생한다

  • 해결 방법으로 build 디렉토리 내의 .map 확장자를 찾아 삭제하는 script 명령어를 추가한다

  • S3, CloudFront에 따라 위 방법만으로 해결되지 않을 때 S3에서도 script를 실행하고, 캐시도 제거하는 작업까지 추가한다.

    
    

• 9월 18일(토) [Browser] Reflow와 Repaint

  • 브라우저에서 화면을 다시 그리는 Repaint(Redraw) / Reflow(layout)에 대해

  • Reflow. 화면의 구조가 변경되었을 때, 뷰포트 내 렌더 트리의 노드의 정확한 위치, 크기를 계산하는 과정

  • Reflow 최적화 방법

    • 1. 스타일을 변경할 경우, 가장 하위 노드의 클래스를 변경한다.
    • 2. 인라인 스타일을 사용하지 않는다.
    • 3. 애니메이션이 있는 노드는 position을 fixed 또는 absolute로 지정한다.
      • 이렇게 하면 해당 노드만 Reflow가 발생하도록 제한할 수 있다.
    • 4. 퀄리티 - 퍼포먼스의 타협점을 찾는다
    • 5. table 태그 사용을 지양한다.
      • table은 모든 요소가 로드되고 테이블 너비를 계산해서 그려낸다. 콘텐츠의 작은 부분만 변경되어도 테이블 전체를 다시 계산한다.
    • 6. IE의 CSS 표현식을 사용하지 않는다.
    • 7. CSS 하위 선택자를 최소화한다.
    • 8. 숨겨진 노드의 스타일을 변경한다.
    • 9. 클래스를 혹은 cssText 사용하여 한 번에 스타일을 변경한다.
    • 10. DOM 사용을 최소화한다.
    • 11. 캐시를 활용한다.

  • Repaint는 화면의 변화가 있을 때.

    
    

• 9월 19일(일) 자바스크립트 검색엔진 최적화(SEO) 가이드 총 정리

  • 자바스크립트는 무엇이고 어떻게 사용되는가
    • 우클릭 후 '페이지 소스 보기'는 초기 HTML이고, '요소 검사'는 JS로 동적 업데이트 된 구조이다.
  • 구글은 자바스크립트를 인덱싱 할 수 있을까?
    • 평균적으로 25%의 JS 콘텐츠가 Google에 의해 인덱싱 되지 않는다. 단, 이 문제는 웹 서비스가 자체적으로 해결 가능하다.
    • JS가 포함된 웹을 크롤링하는건 복잡하다.
      • JS 파일 구문 분석, 컴파일, 실행은 시간이 많이 걸린다.
      • 일반적으로 웹사이트가 완전 렌더링 될 때까지 구글봇은 콘텐츠 인덱싱을 할 수 없다.
      • 동적으로 생성되는 링크에 대해서 구글이 발견하지 못 하는 경우가 많다
      • 크롤링 예산 : Google bot이 크롤링 하기 원하고, 할 수 있는 페이지 수. 이는 제한적이며, 중대형 웹 사이트에서 중요하다.
    • Google bot은 실제 브라우저처럼 작동하지 않는다
      • 일반 사용자가 접속하는 것과 비슷하지만, 사용자 권한 요청을 거부한다
      • 쿠키, 로컬, 세션 저장소 등을 사용하지 않는다
      • 사용자의 브라우저는 항상 모든 리소스를 다운로드하지만, Google bot은 그렇지 않을 수 있다.
  • 성공적인 JavaScript SEO의 기초
    • 크롤링 가능성 / 렌더링 가능성 / 크롤링 예산
    • Google Search Console를 사용해서 구글이 JS 콘텐츠를 정확히 렌더링 하는지, 콘텐츠가 Google에서 색인이 생성되었는지 확인
    • 구글 검색에 site:{url}을 통해 색인 되었는지 확인가능
  • Google에게 자바스크립트 콘텐츠를 제공하는 다양한 방법
    • 서버 사이드 렌더링
    • 동적 렌더링.
      • 사용자에게 모든 기능을 갖춘 JavaScript 웹 사이트를 제공, 동시에 서버는 Googlebot(및/또는 기타 봇)에 웹사이트의 정적 버전을 보낸다.
      • Google에서 공식적으로 지원하는 접근 방법
    • 구글 크롤러는 트위터/페이스북/링크드인 같은 소셜 미디어에서는 JavaScript를 실행하지 않는다.
      • 따라서 초기 HTML에 콘텐츠를 담아야한다.
  • JavaScript 웹 사이드의 흔한 함정
    • Google bot용 JS/CSS 파일 차단하지 말 것
    • 페이지네이션은 click 이벤트가 아닌 a 태그를 사용해야 크롤러가 다음 페이지를 확인한다.
    • URL에서 해시를 사용하지 말 것.
    • JS 리다이렉션 주의!
    
    

• 9월 20일(월) 다크모드의 의의와 웹환경에서의 구현

  • 다크모드의 장점

    • 시인성이 높아짐
    • 눈의 피로가 줄어듦

  • 웹 환경에서 구현하는 방법

    • 미디어 쿼리 속성 중 prefers-color-scheme라는 속성은 사용자의 시스템이 라이트/다크테마를 사용하는지 감지한다
    • 루트 요소에 attribute를 설정해서 사용자가 테마를 선택하도록 한다. html[data-theme='dark'] {}
    • styled-components를 사용할 경우 ThemeProvider를 사용한다
    
    

• 9월 21일(화) 실제 웹사이트에서 Web Vitals 디버깅하기

  • Lab tools는 각종 조건을 흉내내는 시뮬레이션 환경에서 페이지를 로드한다. lighthouse

  • Field tools는 실제 사용자로부터 크롬이 수집한 데이터를 기반으로 작성된 크롬 사용자 경험 보고서 같은 도구를 말한다.

  • Field tools가 더 정확한 데이터를 제공하지만, Lab tools가 문제를 찾고, 수정하기 더 용이한 경우가 많다

  • lighthouse는 문제를 찾고 어떻게 개선하면 되는지 구체적으로 제안하지만, 페이지를 로딩할 때 발견되는 성능 이슈에 국한되어 있다. 사용자의 클릭, 스크롤 같은 이벤트의 상호작용에서 발생하는 문제는 탐지하지 않는다.

  • 따라서 현장에서 실제 사용자의 Web Vitals 매트릭 데이터에 대한 디버그 정보를 어떻게 알아낼 수 있는가라는 질문이 생긴다.

  • CLS는 페이지 전체 수명에 걸쳐 수집되므로, 디버그 시 주요 정보는 사용자가 페이지에 상호작용함으로써 레이아웃 변경, 요소 변경이다.

  • CLS는 Field Data와 Lab Data가 상당한 차이를 보인다.

  • 본문에서 레이아웃 변경과 변경된 요소를 로깅하는 예제 코드를 참고하자. 단 이 코드의 목적은 모든 변경을 감지하는게 아닌, 가장 많은 사용자에게 영향을 미치는 변경을 찾아내서 CLS를 개선하고자 함이다.

  • LCP를 디버그할 때 주요 정보는 해당 페이지를 로드할 때 어떤 요소가 가장 큰 요소인가(LCP 후보 요소)이다. 그 요소는 같은 페이지일지라도 사용자마다 다를 수 있다. 그 이유로는

    • 각기 다른 스크린 해상도로 인해 뷰포트마다 보이는 요소가 다르고,
    • 때로는 해당 페이지의 스크롤 위치가 사용자마다 다를 수 있고,
    • 개인화 된 콘텐츠가 제공될 수 있기 때문.

  • 마찬가지로 본문에서 LCP 후보요소를 찾는 코드를 확인하자

  • FID 디버그시 중요한 점은 FID가 첫 입력 이벤트 시간의 지연시간만을 측정한다는 점이다. 즉 사용자가 무엇과 상호작용 했는지는 중요하지 않다.

  • 하이드레이션.

  • Web Vitals 보고서를 사용해서 시각화하자.

    
    

• 9월 22일(수) 버튼에 타입을 쓰는 이유 (button type="button")

  • button 태그의 type 디폴트 값은 submit이다. 따라서 form태그 내부에서 submit 목적의 버튼이 아니라면 type을 button으로 변경시켜주는 것이 좋다. IE 10 이하 버전에서는 엔터를 누르면 애꿎은 button이 실행되는 문제도 존재한다

  • button type의 input 태그는 과거의 산물이다. button 태그에 비해 자식 태그를 가질 수도 없고, css의 가상 선택자로 꾸미는 것도 불가능하다. 그니까 button태그를 쓰자.

    
    

• 9월 23일(목) JPEG vs. PNG: 적절한 이미지 포맷 선택하기 (1) - JPEG편

  • 복잡한 이미지/사진은 JPEG, 단순하거나 투명 표현이 필요하면 PNG

  • JPEG(Joint Photographic Experts Group)는 JPG와 같은 확장자이다. DOS 시절 확장자 글자수 제한 때문에 JPG로 줄여쓴 게 이어져 온 것

  • JPEG 2000은 비손실 압축도 가능하는 등 JPEG보다 뛰어나지만 이전 버전과의 호환성 때문에 잘 쓰이지 않는다. (메모리도 많이 사용함). 참고로 JPG는 손실 압축이다.

  • 트루 컬러(풀컬러). 사람이 볼 수 있는 모든 색을 표현한다.

  • 서브 샘플링. 휘도(밝기 정보)는 두고 색차 정보를 줄여서 압축하는 것. 크로마 서브 샘플링, 다운 샘플링이라고도 한다.

  • DCT & 양자화. 사람의 눈이 고주파 명도 변화에 둔감하다는 점을 이용한다.

  • 주파수란 '신호가 얼마나 자주 변하는가'를 나타낸다. 즉 이미지에서 인접한 픽셀의 색 차이가 적은 부분이 저주파, 큰 부분이 고주파이다.

  • 보통 사진의 경우 보통 인접한 픽셀의 색상은 비슷할 확률이 높다. 따라서 사진은 저주파 성분이 많은 이미지이다

  • 반대로 인위적인 이미지는 고주파 성분이 많은 이미지가 많다.

  • 그렇기에 사진은 JPEG로 저장하고(고주파를 날려버리기 때문에), 문자, 선, 세밀한 격자, 인위적 이미지는 주로 PNG로 저장한다.
    결론적으로, JPEG 압축 알고리즘은 색상이 매끄럽게 변화하는 사진, 그림에 적합하다

    
    

• 9월 24일(금) JPEG vs. PNG: 적절한 이미지 포맷 선택하기 (2) - PNG편

  • PNG(Portable Network Graphics)는 인터넷에서 표현될 이미지를 염두하고 개발된 확장자이다.

  • 따라서 RGB만 지원하며 CMYK는 지원하지 않는다.

  • JPEG와 다르게 알파채널(A)을 통한 투명도를 지원한다

  • GIF를 대체하기 위해 등장했다. (PNG IS NOT GIF)

  • 무손실 압축으로 용량보다 품질을 우선시한다.

  • LZ77 압축 알고리즘은 현재 압축하고자하는 데이터가 이전에 존재했는지 파악해서 반복 여부를 표시한다.

  • 허프만 부호화로 데이터 문자의 출현 빈도를 파악해 순서대로 짧은 접두어 코드를 부여한다.

  • 따라서 단순한 이미지, 투명 표현이 필요한 이미지에 적합하다.

    
    

• 9월 25일(토) CSS-in-JS, 무엇이 다른가요?

  • CSS 라이브러리간의 가장 큰 차별화 요소는 스타일을 얼마나 동적으로 작성할 수 있는가이다.
    • JS 변수를 사용할 수 있는지
    • 사용할 수 있다면 그 범위는 어디까지인지
  • 이 특징을 중심으로 CSS-in-JS를 4세대 + a 로 구분할 수 있다.
  • 1세대
    • *.module.css 파일을 생성, CSS pre-processor를 사용해서 css module 형태로 사용
    • runtime에서의 동작이 없기 때문에 zero runtime css-in-js의 특징을 갖는다
  • 2세대
    • JS 변수를 활용해 CSS를 작성한다. Radium같은 라이브러리 등장
    • 컴포넌트에서 스타일을 제어할 수 있지만 inline-style을 사용한다.
    • 따라서 :before, :nth-child 등의 pseudo selector, 즉 모든 CSS Spec을 사용할 수는 없다
  • 3세대
    • aphrodite, glamor 등장
    • JS 템플릿 형태로 CSS를 작성하면 빌드 과정에서 <style> 태그를 생성, 주입한다
    • 모든 CSS Spec을 사용할 수 있으나 동적으로 변경되는 스타일은 정의하기 까다로웠다
  • 4세대
    • styled-components 등장
    • runtime 개념을 도입해서 JS 코드로 제어하는 동적인 스타일링을 해결했다.
    • prop가 변할 때 마다 스타일을 동적으로 생성한다. build 타임이 아닌 runtime에서 활용 가능하다
    • runtime에서 스타일을 생성하는 방식은 대부분 문제 없으나 스타일 계산 비용이 커서 스타일이 복잡한 컴포넌트에서 차이가 발생한다
  • • a 세대
    • runtime에서 복잡한 스타일 컴포넌트 연산비용을 해결하기 위해 다시 zero runtime으로 돌아간다.
    • Linaria 라이브러리. babel plugin과 webpack loader를 사용해 사용된 CSS 코드를 추출해서 정적인 스타일시트를 생성한다.
    • 단 1세대에서 불가능했던 prop, state에 따른 동적 스타일링이 가능하다.
    • Linaria가 내부적으로 css variable을 사용하고 있기 때문에 가능하다.
  • Critical CSS
    • 현재 화면에서 필요한 CSS만 효율적으로 먼저 로딩하는 방법
    • styled-components
      • 현재 페이지에서 사용되는 스타일만 별도의 스타일 시트로 생성
      • 최초 렌더링 이후 props/state에 의해 변경되는 스타일은 style tag에 동적으로 삽입
    • emotion
      • styled-components와 비슷하게 초기 페이지 렌더링에 필요한 critical css를 추출, 이후 동적 스타일은 runtime에 생성
    • linaria
      • 빌드시 critical css 추출
  • Performance
    • runtime이 반드시 성능 저하를 초래하는 것은 아니다.
    • runtime css-in-js
      • css를 parsing하는데 blocking 되는 시간을 줄이는 노력이 필요
      • DOM 트리는 두고 CSSOM만 수정하는 방식으로 해결
      • 단 development mode에서는 DOM을 수정한다.
    • zero runtime css-in-js
      • 병목을 일으키는 부분에 부분적으로 zero-runtime을 도입한다.
    • styled-components와 linaria의 퍼포먼스 비교는 linaria가 우세하지만 도구의 한계가 명확해서 신중히 고려해야한다.
  • stitches (near-zero runtime)
    • styled-components와 유사한 api를 표방하지만 runtime 대신 near-zero runtime을 표방한다
    • component prop에 의한 interpolation을 최소화하는 방향의 API 제공
    • styled-components에서는 prop에 의한 완전 동적 스타일링이 가능하지만, stitches는 사전에 정의한 variants에 의한 스타일링만 가능하다
  • css-in-js 외의 방법
    • Atomic CSS
    • tailwindcss
    • tailwind + twin.macro
    • stiches.js
    
    

• 9월 26일(일) 기술부채가 쌓여있는 상황에서 서비스 성능 임팩트 있게 개선하기

  • 보통 레거시 코드들은 1년이 지날 즈음부터 변화에 대한 비용이 급격하게 증가한다. 코드 작성자가 퇴사하거나, 퇴사하지 않았더라도 기억이 나지 않는 경우가 많아서!

  • 어떤 지표를 개선할 것인가를 정하고 하나씩 해결하는 전략을 취함

  • 구글의 Core Web Vitals를 사용.

    • Lighthouse보다 지표가 적음 (6개 / 3개)
    • UX에서 연역적으로 도출된 지표
    • DataDog에서 측정 가능 (RUM 사용)

  • 데일리 배포 / 기능 추가 책임을 엔지니어가 담당하는 형태

    • 크고작은 장애 발생
    • 서비스 성장에 따라 장애들로 인한 피해 증가
    • QA 프로세스 정립

  • Critical Rendering Path.

    • 현재 사용자 작업과 관련된 콘텐츠 표시의 우선순위를 지정하는 것
    • script태그의 async, defer 옵션과 link 태그의 DNS Prefetch, Preconnect 옵션 사용

  • DNS prefetch는 link 태그를 이용해서 해당 도메인에 해당하는 IP 주소를 미리 알아내는 것이다. (DNS resolution 요청을 미리 하는 것)

  • preconnect는 TCP 연결을 미리 맺어두도록 하는 것. 클라이언트 리소스를 사용하는 것이기에 남용해서는 안 됨.

  • defer loading은 렌더에 필요하지 않은 스크립트를 defer하게 받아올 수 있도록 하는 옵션 스크립트 다운을 백그라운드에서 진행한다. 파서가 block되지 않음

  • async executing는 다운로딩이 아닌 실행에 관련된 옵션이다. 다운로드가 완료된 순서대로 스크립트가 실행 된다. 따라서 번들링된 핵심 서비스 코드를 먼저 실행할 수 있다.

  • 이미지 lazy loading은 LCP에 악영향을 미친다. 따라서 처음 보는 화면에서는 lazy loading을 하지 않는게 좋다.

  • 번들 용량을 줄이는건 성능 최적화에 항상 거론되는 주제이다. chunk를 사용해서 공유 코드를 나눈다.

  • import 되고 사용되지 않는 코드를 제거하면 번들 용량을 줄일 수 있다.

  • 
    

• 9월 27일(월) 브라우저에서 미디어 권한을 다루는 간단 tip

  • 웹 서비스가 마이크나 비디오 등에 접근 권할을 요청하는 걸 종종 볼 수 있다.
  • 핵심은 사용자가 특정 미디어 권한에 대해 어떤 결정을 내리는가에 따라 적절한 대응을 해주는 것이다. 권한읠 변경하더라도 서비스 차원의 적절한 대응 필요
  • Permission API
    • 현재 컨텍스트 기준으로 브라우저 내 권한과 관련된 쿼리를 보낼 수 있는 API
    • 사용자가 특정 권한을 허용/거절 했는지 확인할 수 있다.
    • navigator.permissions.query 사용.
    • IE / 사파리는 지원하지 않는다!
  • MediaDevices API
    • 카메라, 마이크, 공유 화면 등 현재 연결된 미디어 입력 장치에 대해 접근할 수 있다.
    • navigator.mediaDevices.getUserMedia 사용
    • 이 API는 사파리에서 지원하지만 IE에는 여전히 지원하지 않음
  • enumerateDevices
    • 접근 가능한 미디어 입출력 기기 리스트를 확인할 수 있다.
    • navigator.mediaDevices.enumerateDevices 사용
  • device change event
    • navigator.mediaDevices.addEventListener('devicechange', callback)으로 리스너 등록
    • 
      

• 9월 28일(화) Airbnb의 Server-Driven UI

  • Server-Driven UI. 말 그대로 화면에 보여지는 UI 렌더링을 클라이언트가 아닌 서버 위주로 진행하는 것
  • 이러한 니즈는 앱에서 즉각적인 UI 변경을 적용하기 위해 웹을 사용해서 서버 데이터에 따라 UI를 변경시키는 방법론이 되었다.
  • Ghost Platform. Airbnb에서 Web/iOS/Android가 동일한 backend response로 클라이언트를 처리한다. 동일한 GraphQL schema 사용. 즉 모든 플랫폼이 동일한 응답을 이용해서 처리가능한 universal schema
  • Section. 가상 원시적인 구성 요소. UI component를 표현하는 데이터로 어떤 데이터가 표현될지 함께 가지고 있음. 클라이언트는 단지 이 값을 UI에 렌더링 할 뿐
  • Screen. 어떻게 화면과 레이아웃이 보여질지 명시. 이 값들을 이용해 Section을 처리한다.
  • Section data model이 하나의 유니크한 렌더링을 한다. 어떠한 context 없이도 렌더링 되기에 특정 기능에 종속되는 비즈니스 로직이 필요 없음.
  • Sections / Screens / Actions
  • 이러한 구조는 다양한 커스터마이징 니즈 때문에 흐지부지 되기 마련인데 Airbnb는 어느정도 잘 구현한 듯. 아직 실험단계이긴 하다.
  • 이러한 Server-Driven UI가 대세가 될 것이냐, 하면 그렇지 않다. SDUI는 고려할게 많고 단점도 있다. 플랫폼벌 통일 UI가 중요하거나 빠른 개선을 통해 MVP를 찾아가거나 하는 등의 서비스라면 고려할만 함.
    
    

• 9월 29일(수) Generalist

  • 스페셜리스트 전에 제너럴리스트가 먼저 되어야 한다?
  • 프론트엔드 개발자이기 이전에 웹 개발자이다.
  • 브라우저별 특성 / 자바스크립트 언어적 특성 / 브라우저 렌더링 방식 / DOM / HTML과 표준 / CSS / HTTP (Req, Res, HTTP Status Code) / HTTPS / 정적 서버, CDN / 호스팅 서버 / Docker / RESTful API / React / Fetch API / Web Rendering / 에러 처리
  • 스페셜 리스트가 되기 위해 HTML/CSS/JS를 깊게 파고드는게 나쁘진 않지만 거기에 정신이 팔려 웨 전체의 기술에 대해 이해하지 못 하는 것은 좋은 상황이 아니다.
  • 
    

• 9월 30일(목) CSR 앱에서 SSR + CSR 환경으로 이주하기

  • CSR에 SSR을 도입하면서 얻게 되는 이점

    • 프론트엔드 개발자가 서버 코드도 개발할 수 있어서, 자유도가 높아진다
      • SSR은 프론트 서버를 따로 둔다는 것이므로, 프론트에서 서버 자원을 관리할 수 있다.
      • refresh token을 프론트 개발자가 관리할 수 있기 때문에 프론트의 토큰 전략을 백엔드와의 논의하지 않고 수정할 수 있다.
    • SEO가 향상된다.
      • 뻔한 이야기이긴 하지만.. 검색 엔진은 하이퍼 링크, 즉 a태그를 통해 문서를 이동하기 때문에 HTML 문서가 이미 완성되어 있는 SSR이 SEO가 좋다. 단 구글 검색 엔진의 경우 CSR에서도 JS를 해석해서 어느정도 SEO를 보장할 수 있지만, 다른 검색엔진(네이버, 다음 등..)은 아직 불가능하다.
    • 페이지 초기 렌더링이 빨라진다.
      • 빈화면 -> 추가 JS 가져오기 -> 추가 데이터 요청-> 화면 그리기 등 과정에서 바로 완성된 HTML 문서를 받아오기 때문에 시간이 크게 단축된다.

  • reverse proxy

    • 웹서버를 한 번 거쳐서 웹어플리케이션 서버(WAS)와 연결하는 방식
    • 외부 사용자들에게 WAS가 어떤 포트에서 동작하는지 숨겨서 보안적으로 강화할 수 있다.

  • ReactDOMServer.renderToString를 사용해서 <App /> 컴포넌트를 렌더한다.

  • renderToString은 리액트가 컴포넌트 구조를 파악하고 HTML string으로 바꾼다.

  • CSR에서는 ReactDOM.render()를 사용하지만 SSR에서는 ReactDOM.hydrate()를 사용해서 리액트가 SSR에 의해 일부 렌더링 되고, 나머지 부분만 CSR로 채운다고 생각하고 이벤트 리스너만 등록하거나, 렌더링 되지 않은 나머지 부분을 추가 렌더링해주는 등 효율적인 동작을 한다.

  • 이미 로그인된 상태의 화면을 가져올 수도 있다.

  • HTML 문서에 script 태그를 포함하는 방법으로 access token을 담아서 응답한다.

  • XSS에 취약할 수 있으나 이 방법으로 간단하게 해결할 수 있다. script 태그에 정보를 담을 때 JSON.stringify 대신 serialize-javascript 같은 라이브러리를 사용하자. JSON.stringify로 넘기는 정보에 악의적인 스크립트 태그가 있을 수 있기 때문

    
    

10월

• 10월 1일(금) REST 및 베스트 프랙티스

  • Representational Safe Transfer는 2000년 로이 필딩이 2000년 논문에서 소개한 네트워크 기반 아키텍처이고, Representational State HTTP 표준만 따르면 어떤 기술이든 사용할 수 있는 인터페이스 스타일이다. 사실 말장난같기도하고, 굳이 구분해야하나 싶기도하다. 우리가 개발하면서 자주 언급하는 REST는 주로 후자를 지칭한다.

  • HTTP + JSON 조합으로 구현하는 OPEN API.

  • REST는 크게 리소스, 메서드, 메세지로 구성된다.

  • "이름이 Terry인 사용자를 생서앴을 때'

    • 리소스 : 생성되는 사용자. URI로 표현된다
    • 메서드 : 생성한다는 행위. HTTP METHOD로 표현된다.
    • 메시지 : Terry. JSON으로 표현된다.

  • 멱등하지 않은 메소드(POST)는 REST API를 다른 API와 함께 호출하다가 실패할경우 트랜잭션 복구를 위해 기존 상태를 저장했다가 다시 원상 복구시켜주어야 한다

  • REST는 유니폼 인터페이스로, HTTP+JSON 표준만 따르면 웹/안드로이드/IOS 등 플랫폼을 가리지 않고 사용할 수 있다.

  • REST는 HTTP를 기반으로 하기에 웹의 인프라 (로드 밸런서, SSL, 캐싱) 등을 적용할 수 있다.

  • 캐싱은 HTTP의 가장 강력한 기능 중 하나이다. 일반적인 서비스에서 60~80% 가량의 트랜잭션이 SELECT와 같은 조회성 트랜잭션임을 고려하면, HTTP의 웹 캐싱은 이점이 많다

  • Last-Modified, E-Tag를 이용해 캐싱 구현 가능

    • HTTP GET 요청을 Last-Modified 값과 함께 보내면, 콘텐츠 변화가 없을 경우 REST 컴포넌트는 304 Not Modified를 반환하며 클라이언트는 자체 캐시값을 사용한다.

  • REST는 API 메세지만으로도 예측할 수 있는 형태여야한다. 최소한의 문서의 도움만으로 API 자체를 이해할 수 있어야한다

  • REST 안티 패턴

    • GET/POST를 이용한 터널링하는 것. (메소드에 맞는 목적으로만 사용하라)
    • 자체 표현 구조를 해치는 것
    • HTTP 응답 코드를 사용하지 않는 것. 본문에 구글, 넷플릭스 등 예시 참고!

  • 에러는 적절한 상태코드와 메세지를 담아서 디버깅하기 쉽게 한다.

  • 에러 발생시 스택 정보를 포함시킬수는 있지만, 이는 대단히 위험하다. 내부 코드 구조, 프레임워크 구조를 외부에 노출하기 때문이다. 다만 내부 개발 중일 때에는 유용하다. 프로덕션 환경과 개발 환경을 구분하자

  • API 버전 관리 예시

    • api.server.com/account/v2.0/groups

  • 페이징

    • 반환 리스트가 1억개라면 하나의 HTTP 응답으로 처리하는 것은 서버 성능, 네트워크 비용도 문제지만 비현실적이다. 페이징 필수

  • 응답 메세지에 모든 필드를 포함할 필요 없다. 필요한 필드만 부분 응답 처리한다.

  • API 서버가 물리적으로 분리되어 있더라도, 단일 URL을 사용하는 것이 좋다

    • HAProxy, Reverse Proxy를 사용하는 방법이 있다.
    • api.apiserver.com/user/는 user.apiserver.com으로 라우팅하고 api.apiserver.com/car/는 car.apiserver.com으로 라우팅하도록 구현하면 된다.
    
    

• 10월 2일(토) [CSS] width 속성과 너비 결정 매커니즘

  • 절대값으로 지정하면 부모 엘리먼트를 삐져나올지언정 절대 변하지 않는다

  • 상대값은 가용 너비를 기준으로하며, 가용 너비는 박스 모델 상 부모 엘리먼트의 컨텐츠 박스 크기를 말한다.

  • auto는 width의 기본값으로, 브라우저 자동으로 계산한다. 계산 알고리즘은 가용 너비 - margin이다.

  • min/max-content는 가용 너비가 아닌 담고있는 컨텐츠에 의해 width 값을 결정한다. min/max content는 해당 엘리먼트의 너비를 줄일 수 있는 만큼 최소/최대로 만든다. max의 경우 텍스트의 배경색을 적용할 때 유용하다. 텍스트 길이에 딱 맞기 때문에.

  • fit-content는 min/max-content의 하이브리드 모드로, 가용너비가 넉넉하면 max, 부족하면 auto처럼 동작한다.

    
    

• 10월 3일(일) SVG 아이콘 백그라운드 이미지로 활용하기

  • SVG는 <img>, <embed>, <object>, <iframe>, <svg> 등으로 표현할 수 있다.

  • SVG 파일을 에디터에서 연 후, DTD, version, xmlns는 반드시 필요한 속성은 아니니 제거해도 좋다.

  • SVG 압축 도구로 "웹 SVGOMG"를 사용한다.

  • Data URI 형태로 변환한다.

    • data: 스킴으로 시작하는 URL
    • 작은 파일을 인라인으로 임베드 가능하며, HTTP 요청 및 헤더 트래픽이 필요하지 않음
    • data:[<mediatype>][;base64],<data>
    • base64는 간단히 말해 이미지를 문자열로 인코딩하는 과정이다. 원리는 본문 참고!
    • 인코딩 하면 크기가 더 커지며, 캐싱되지 않는다. 다만 아이콘은 크기도 작고 재사용할 일이 많아서 이미지 요청을 여러번하기보다 Data URI로 사용하는게 나을 수도 있다.

  • IE 크로스 브라우징을 고려한다면 <를 %3C로, >를 %3E로, #를 %23으로 치환하면서 캐릭터 셋을 utf8로 지정하는 과정을 거치는게 좋다.

  • 
    

• 10월 4일(월) 2021년 검색엔진 최적화(SEO) 변경 사항 6가지 및 순위에 미치는 영향

  • 1. 페이지 경험 신호는 순위에 영향을 미친다
    • 모바일 친화성부터 웹 사이트 보안 프로토콜 까지
    • 콘텐츠 2.5초 이내 로드 / 첫 번째 입력 지연 100밀리 초 이하 / 누적 레이아웃 이동 0.1 미만
  • 2. 지역 검색의 경쟁력이 높아질 것이다.
    • 구글 검색 46%가 지역 목록에 대한 정보를 찾는 사용자.
    • 제로 클릭 검색이 증가할 것. 검색 결과 자체에서 원하는 답변을 얻기 때문에 웹 사이트에 방문하지 않는 것.
  • 3. 미국 성인 1/3이 스마트 스피커 소유 중이며 25년까지 75%까지 증가할 것으로 예상
    • 따라서 음성 검색이 순위에 영향을 미칠 것.
  • 4. 검색 의도는 다른 모든 것을 능가한다.
    • 구글 검색 엔진은 점점 사용자의 검색 의도를 잘 파악하고 있으며, 이를 기반으로 먼저 제공할 콘텐츠의 유형 (위키 백과인지, 특정 사이트인지 등..)을 제공한다.
    • 기술적 SEO 관행보다 콘텐츠가 검색 의도와 일치하는지가 더 중요해질 것이다.
  • 5. 모바일 우선 인덱싱이 기본값이 된다.
    • 검색의 절반 이상이 모바일 에서 수행된다. 구글은 모든 웹 사이트에 대해 모바일 우선 색인 생성을 기본으로 설정한다.
  • 6. "EAT"테스트를 충족하는 긴 형식의 콘텐츠가 더 잘 수행된다.
    • 전문성 / 권위 / 신뢰성을 나타내며 신뢰성은 정량화하기 어려워서 아직 직접적인 순위 요인은 아니다.

  • 결론적으로, 구글의 우선순위는 사용자 경험을 개선하는 것이다.

    
    

• 10월 5일(화) Headless UI Library란?

  • UI를 컴포넌트로 만들기 전에 고민할 세가지

    • UI가 내포하고 있는 상태는 무엇인지
    • 상태를 관리하기 위해 적절한 자료구조는 무엇인지
    • 컴포넌트를 사용하는 인터페이스는 어떻게 노출할 것인지

  • UI 라이브러리들을 둘러보면 ‘스타일’이 포함되어있는 경우가 많아 바로 사용하기 곤란한 경우가 많다. 이런 귀찮은 문제를 잘 해결할 수 없을까?

  • 대부분의 스타일 재정의는 CSS Override로 쉽게 제어가 가능하지만 몇 가지 단점이 있다

    • 오버라이드한 class가 다른 class로 변경되면 오버라이드한 스타일이 제대로 동작하지 않는다.
    • 우선순위 이슈 때문에, 오버라이드한 스타일이 내부적으로 오버라이드 할 수 없게 되는 케이스가 발생.
    • CSS-in-JS 방식이면 postcss라도 설치해서 css를 별도로 컴파일해야 함
    • 리소스는 한정적이지만 처음부터 만드는 것보다 손이 많이 갈 수 있음
    • 결론적으로 관리가 힘듦.

  • Headless는 스타일링을 담당하는 부분을 과감하게 제외하고 상태와 관련된 부분만 다루는 것이다.

    • 관심사의 분리. 스타일링 코드와 비즈니스 로직은 별도로 관리되어야 한다.
    • 유지보수가 용이해진다.

  • React 공식문서의 Higher-Order Components의 내용을 참고해서 만들 수 있을 것이다.

  • 본문의 달력 예시를 참고하자

    
    

• 10월 6일(수) 브라우저 핑거프린팅(Browser Fingerprinting)이란?

  • 디바이스 핑거프린팅은 식별을 위해 수집된 원격 컴퓨팅 기기의 하드웨어/소프트웨어 정보를 말한다.

  • persistent 쿠키를 읽을 수 없거나 / 클라이언트 ip가 숨겨져 있거나 / 한 기기에서 다른 브라우저를 사용해 접근하는 경우 등에서 사용자를 식별하기 위해 사용된다.

  • 위조 ID / 신용카드 등 사용을 막는 목적도 있지만, 마케팅 개인화를 위해 사용되기도 한다

  • 광고를 목적으로 하는 회사는 어떻게든 개인 데이터를 수집하려하고, 브라우저는 사용자에게 좀 더 private한 환경을 제공하기 위해 노력한다. (그럼 구글은..? 크롬과 광고 사이에서...?)

  • 웹 브라우저 발전사 / 핑거프린팅 기법 / 방어 기법 등 설

  • 동일한 텍스트는 운영체제 / 폰트 라이브러리 / 그래픽카드 / 그래픽 드라이버 / 브라우저에 따라 다른 컴퓨터에서는 다르게 렌더링 될 수 있다. 일련의 과정(본문참조)를 통해 hash 값을 추출, 유용한 식별자로 사용 가능하다.

  • 브라우저 익스텐션을 통해 특정 URL 또는 DOM 변경을 통해 특정 익스텐션이 설치되었는지 확인하거나 / 가짜와 존재하는 익스텐션에 대해 쿼리를 실행, 요청 간으 시간차를 측정해서 익스텐션을 파악한다고 한다.

  • 그외에도 JS 엔진의 컴파일을 이용하거나 / 특정 브라우저의 유니크한 CSS 속성 prefix / 기기의 CPU, GPU capabilities 벤치마킹 / 배터리 충전량을 통해 식별하기도 한다..

  • 이러한 핑거프린트 방어에 다양한 기법이 있지만 주로 모던 웹 브라우저의 기능을 제한하거나, privacy를 높이는 것 사이의 균형을 맞추는 것에 가깝다.

  • 다양한 방법들은 본문을 참고하자.. 너무많다..

    
    

• 10월 7일(목) [React] CORS요..? 제 잘못,,, 인가요?

  • 프론트엔드로서 CORS를 마주할 때! (백엔드.. 문제..아닌가요..? 근거를 대자..)

  • 헤더에 약속된 토큰을 넣어주고 / withCredentials : true가 설정되어 있다면 프론트가 할 일은 다 한것이다? (진짜?)

    
    

• 10월 8일(금) 프론트엔드 개발자에게 가장 중요한 역량은?

  • 사용자, 사용자! 사용자 경험을 중요시하는 마인드 셋

  • 사용자가 서비스가 살아있다고 느끼는게 중요하다. 누적 신청자 수를 라이브로 보여주기 애니메이션. 간편한 퍼널

  • 제품에 대해 오너십을 갖는다

  • 개발 뿐 아니라 제품 전반에 대한 이해가 필요하다. 주도적으로 제품을 만드는데 기여할 수 있다.

  • 다양한 일의 맥락을 파악하고, 중요도와 우선순위를 판단한다. 한정된 시간 자원을 최대로 활용

  • 동료와 적극적인 소통을 통해 일 진행 정도를 공유한다

  • 빠르게 실험하고 사용자 반응을 본다. 그러기 위해 코드의 유지보수성을 고려해야한다. 수정은 당연하니까!

  • 웹을 앱처럼 보이도록 하는 웹 성능 최적화는 중요도가 높다.

  • 타 직군과 세부사항을 맞춰가며 소통하자

  • 새로운 것에 호기심을 갖자

  • 성장에 대한 열망

  • 왜?

  • 
    

• 10월 9일(토) Express만 하다가 Nest를 하고 느낀 점

  • Express는 구조적으로 짜임새가 있는 형태는 아니다. 빠르게 개발할 수 있을 뿐(?) 그래서 nestJS에게 자리를 넘겨줄지도..
  • Express의 불편함 4가지.
    • 라이프사이클을 개발자가 직접 조정해야 함
    • Route 경로가 꼬일 수 있음
    • TypeScript & async/await 지원이 제대로 되어있지 않음
  • Express에서는 Request가 Response로 나아가면서 거치는 모든걸 middleware라고 통칭하지만 사실 상세하게 나눌 필요가 있다
    • Guards / Interceptors / Pipes / Filters / Decotragtors
  • 미들웨어 순서는 온전히 개발자의 몫이지만, 사실 인증을 먼저해야하고, 유효성 검사를 우선 시행해야하며, logger 같은건 맨 마지막에 하는 등 정해진 순서가 존재한다.
  • Nestjs에서는 이 일련의 순서가 이미 라이프 사이클에서 자동으로 정해져있다.
  • Express는 TypeScript를 지원하지 않는다. 다만 커스텀 타입이나, 원래부터 JavaScript에 포함된 것들의 타입을 지정할 수 있을 뿐, Express 자체적으로 선언된 객체의 경우 타이핑하기 어려운 경우가 많다. (Any를 남발하게 된다. Body, Query, Params, Cookies 등..)
  • Express의 개발은 중지되었다(?)
  • Express는 async/await 또한 지원하지 않는다. 여기서 지원한다는건 Promise가 있든 없든 결과를 보장한다는 것을 의미한다.
    
    

• 10월 10일(일) 🤔 JWT, 정확하게 무엇이고 왜 쓰이는 걸까?

  • HTTP는 연결과 상태를 유지하지 않기 때문에, 로그인 구현시 자신이 누구인지 계속 인증해야한다.

  • 서버에서 사용자 인증을 유지하는게 세션, 클라이언트에서 하는 것이 토큰 방식이라 볼 수 있다. 토큰 방식은 서버 확장성을 가진다!

  • JWT는 header / payload / signature로 나뉜다

  • header는 JWT를 어떻게 검증하는지 / payload는 토큰에 담는 내용 / signature는 header와 payload를 합친 문자열을 서명한 값이다.

  • JWT 장점

    • 별도 인증 저장소가 없기에 서버와 커뮤니케이션을 최소화 한다.
    • 트래픽 부담이 적다
    • 세션가 달리 독립적이다

  • 단점

    • JWT가 커질수록 트래픽에 영향을 미치는 구조
    • 클라이언트에 저장되므로 DB가 변경되더라도 토큰에 직접 적용할 수 없음(재발급 필요)
    
    

• 10월 11일(월) Next.js - SSR이라고만 알고있었다.

  • Next.js가 해주는 것들
    • React를 사용하며 고려해야 하는 것들을 대신 해준다.
    • 번들링, 트랜스파일링, 코드스플리팅으로 production 최적화, 성능/SEO를 위한 pre-render
    • 직관적인 페이지기반 라우팅 시스템
    • Static generation. 빌드 타임때 각 페이지별 HTML을 미리 생성해두고, 요청이 들어오면 만들어둔 HTML을 반환한다. SSG라고 한다
  • SSR: 요청이 들어오는 순간 해당 HTML을 생성해서 반환한다.
  • SSG와 SSR은 다르다!
  • SSG는 외부 요청에 의해 변하지 않는 페이지를 미리 만들어두기 때문에, A사용자가 먼저 요청해서 만들어진 페이지가 있다면 B사용자가 같은 URL로 요청했을 때 미리 만들어둔 페이지를 반환만 하면 된다.
  • 공식문서에서는 데이터 변동이 빈번하게 일어난다면 CSR을 권장한다.
  • SSG의 pre-render를 위한 시나리오는 두 가지, 외부데이터에 의존하는 것이 페이지인가 / 페이지의 path인가로 구분된다.
  • getStaticProps는 빌드타임에 호출되어 fetch된 데이터를 해당 페이지의 props로 전달해서 pre-render한다.
  • getStaticPaths는 빌드타임에 요청을 보내 이에 따른 페이지들을 생성해야하기 때문에 그 결로들을 미리 정의한다.
    

• 10월 12일(화) React에서 선언적으로 비동기 다루기

  • 명령형으로 에러를 처리하는 try-catch를 사용하는 함수는 컴포넌트에서 그대로 가져다 쓰기 불편한 비동기 함수이다. 사용하기 위해서는 useState/useEffect 등을 사용해 상태 관리가 필요하다

  • try-catch를 통해 로딩/에러 상태를 정의하는 hooks를 사용하곤 한다 (본문참조)

  • 로딩/에러 상태를 매번 확인, 정의해야하고 수 많은 에러를 각 컴포넌트/hooks에서 처리하는게 번거롭다.

  • 선언적으로 에러를 처리하는 방법으로 Suspense와 ErrorBoundary를 사용한 비동기 컴포넌트를 사용하자

  • swr, react-query를 사용하면 간단하게 처리할 수 있다.

  • Suspense의 fallback 덕분에, 해당 컴포넌트는 호출 상태가 로딩인지 판단할 필요 없이 데이터가 로드된 시점만 고려하면 된다

  • Suspense는 SSR을 지원하지 않는다. 다만 Client환경 시점을 알아내기 위한 hooks를 섞는 방법으로 Suspense를 확장해서 구현 가능하다 (본문참조)

  • 이 방법으로 loading 값을 따로 관리하지 않아도 된다. 하지만 여전히 error 상황 처리를 하지 않았다

  • ErrorBoundary는 클래스형 컴포넌트이지만 확장한 후에 함수형 컴포넌트에서 사용할 수 있는 듯하다. 본문참조! 상당히 복잡하다.

    
    

• 10월 13일(수) 클라이언트의 사용자 중심 예외 처리

  • 에러는 크게 언제, 어떻게 발생할지 예상 가능/불가능한 에러로 구분할 수 있다.

  • API 응답 status code중 500대 이하 코드는 예상 가능한 에러로 볼 수 있다. 각자 상황에 맞는 코드를 부여하고, 그에 맞는 처리를 미리 작성해둘 수 있다.

  • 500대는 예측할 수 없는 에러로 분류한다. 서버의 예상 할 수 없는 상황, 사용자 네트워크, 브라우저 환경에 따른 에러는 예측하기 어렵다.

  • 또한, 환경이 아닌 사용자와의 상호작용으로 에러를 구분할 수도 있다. 사용자가 그 에러를 해결 가능한가/불가능한가

  • 해결 가능한 에러의 예시는 인증/권한 관련 에러이다. 로그인을 하거나, 동의를 해야한다거나, 권한을 요구해야한다거나 등 안내를 통해 사용자가 스스로 해결할 수 있도록 유도할 수 있다.

  • 해결 불가능한 에러의 예시는 사용자의 기기가 저사양이거나, 브라우저 문제 등이 있다. 다른 브라우저를 사용하라는 메세지를 줄 수도 있긴 하지만, 근본적인 해결은 되지 않는다.

  • 이를 통해 예상 OX, 사용자 해결 OX로 4가지 경우의 수가 나온다. 자세한건 본문을 참고하자

  • 예상 X 사용자 해결 O

    • 네트워크 에러
    • 에러의 영향 범위가 중요하다

  • 예상 X 사용자 해결 X

    • 놓치기 쉽지만 반드시 신경써줘야 한다
    • 모니터링이 중요하다

  • 예상 O 사용자 해결 X

    • 예상했음에도 사용자에게 해결을 넘겼다는건 애초에 잘못 된 상황이다.
    • 혹은 사용자가 해결 의지가 없거나(보안 공격). 보안과 관련된 에러가 주를 이룬다.

  • 예상 O 사용자 해결 O : 비즈니스 로직 일부로 개발자가 이미 알고 있는 에러들.

    • 로그인이 필요함, 잘못된 페이지 접근 등.
    • 가이드가 중요하다.

  • 하지만 현실적으로 딱 나누어지지는 않는다.

  • 예상 가능/불가능 에러를 판단할 기준, 에러 전파를 막을 장치, 모니터링을 위한 도구를 마련하자.

    
    

• 10월 14일(목) 선언적으로 에러 상황 제어하기

  • 예상했던 에러를 처리하기 위해서는 API에서 내려오는 status code 외에 에러를 구체화하기 위한 error code / flag 같은 값이 필요하다.

  • try catch의 catch에서 전달받는 error 객체가 예상 가능한 형태인지??

  • Sentry. 에러 모니터링 도구

  • AsyncBoundary로 감싸서 에러가 전역으로 퍼지는 것을 방지하자. (본문 참고!)

  • error가 catch 되었을 때 에러를 초기화함과 동시에 다른 곳에 캐싱된 값(react-query로 호출한 API의 에러는 react-query에 캐싱됨)들을 같이 reset해주어야 한다

  • 때로는 전역에서 처리해야하는 에러가 있다. 이 경우 비동기 컴포넌트를 감싸고 있는 AsyncBoundary에서 capture하지 않을 에러를 무시하는 로직이 필요하다 (ignoreError)

    
    

• 10월 15일(금) 서치엔진은 어떻게 작동할까?

  • 웹 크롤러는 문서(HTML)의 상태를 확인하기위해 각 URL을 가져오는데 문서에 에러코드가 출력되면 해당 문서의 어느 한 부분도 사용할 수 없다

  • 크롤러는 301/302 처럼 redirection status code를 발견하면 그 방향대로 낭가가고, 필요하면 컨텐츠를 다운 받으며 진행한다. 즉 다음 문서로 가기 위해 링크가 필요하다.

  • 크롤러는 즉각적으로 링크/버튼 등을 클릭하는게 아니라 나중에 방문하기 위해 queue에 URL을 쌓아둔다.

  • 새로운 URL을 방문할 때 쿠키/로컬스토리지/서비스워커 사용은 불가능하다

  • 크롤러가 문서를 검색하면 서치 엔진에게 컨텐츠를 넘기고, 서치 엔진은 문서를 렌더링한다. (인덱싱)

  • 서치 엔진은 keyward, title, link, heading, text 등을 본다

  • 서치 엔진은 단순히 키워드를 인덱스에 매칭하는 일 뿐 아니라, 최적의 정보를 주기 위해 문맥, 대체단어, 사용자 위치 등을 고려한다.

  • 
    

• 10월 16일(토) 🔎 검색 상단에 오르기 위한 SEO 최적화

  • lighthouse의 SEO 점수로 검색 우선순위 파악 가능

  • 도메인의 복잡성은 검색엔진에게 큰 의미가 없다. 검색엔진은 도메인의 국적, 연식을 더 중요시한다. kr보다는 com이 유리하며, 신생보다 오래된 도메인이 유리하다!

  • head 최적화

    • title은 매우 중요하다. 키워드마스터, KWFinder 같은 사이트에서 특정 검색어의 검색량을 확인하면 더 나은 타이틀을 정할 수 있다.
    • lang을 통해 사용자 국적에 맞는 검색어를 찾아준다
    • 각 페이지별로 Description을 사용하는게 유리하다
    • viewport를 통해 데스크톱/모바일 콘텐츠를 구분한다.
    • robots. 크롤링 허가 여부

  • 태그 최적화

    • h 태그는 검색 우선도가 높다. b, i보다 strong, em이 검색 우선도가 높다!
    • img는 alt, title 태그 유무
    • 검색 엔진은 사람이 읽는 것처럼 위에서 아래로, 좌에서 우로 크롤링하니 좌측상단에 우측하단 순으로 요소를 배치하는게 좋다
    
    

• 10월 17일(일) Next.js 100% 활용하기 (feat. getInitialProps, getStaticPath, getStaticProps, getServerSideProps, storybook)

  • CSR은 SSR에 비해 초기 렌더가 느리지만 페이지 이동 속도는 오히려 더 빠르다 추가 데이터를 필요한 만큼만 부르기 때문에. SSR은 중복 데이터를 불러와서 느리다
  • next에서 페이지는 SSR로 렌더하고, 동적 데이터 패칭은 CSR로 하는게 일반적인데 데이터가 페이지 로드와 동시에 패칭해야하면(pre rendering) getInitialProps, getStaticProps, getStaticPath, getServerSideProps 등을 이용한다.
  • ServerSide Cycle
    • Next Server가 GET 요청을 받는다.
    • 요청에 맞는 Page를 찾는다.
    • _app.tsx의 getInitialProps가 있다면 실행한다.
    • Page Component의 getInitialProps가 있다면 실행한다. pageProps들을 받아온다.
    • document.tsx의 getInitialProps가 있다면 실행한다. pageProps들을 받아온다.
    • 모든 props들을 구성하고, _app.js > page Component 순서로 rendering.
    • 모든 Content를 구성하고 _document.js를 실행하여 html 형태로 출력한다.
    • 즉, 전역 데이터 패칭은 _app.tsx에, 지역 데이터 패칭은 각 페이지에서 진행한다.
  • 하지만 위에서 언급한 getInitialProps는 만으로 데이터를 패칭하는건 next 9.3버전이전이고, 이후 버전에서는 getStaticProps, getStaticPath, getServerSideProps로 분화되었다.
  • 단, 여전히 전역 데이터 패칭은 _app.tsx에서 getInitialProps를 사용해야한다. 단, 이 경우 자동 정적 최적화가 비활성화되어 모든 페이지가 SSR로 제공된다. 그래서 9.3버전 이후에 getStaticProps, getServerSideProps 같은 것들을 추가한 것이다.
  • getInitialProps 내부 로직은 서버에서 실행 되기 때문에 클라이언트에서만 가능한 로직(window, document 등)은 피할 것!
  • getStaticProps
    • 빌드 타임에 / static generation을 위한 / pre-render 패치
    • 렌더가 매우 빠르다
    • 매 유저 요청마다 fetch할 필요 없는 데이터로 구성된 페이지 렌더에 유리하다
  • getStaticPaths
    • 동적라우팅 + getStaticProps를 원할 때 사용한다.
  • getServerSideProps
    • 매 요청에 대해 / SSR을 위한 / pre-render
    • 빌드와 상관없이 매 페이지 요청마다 데이터를 서버로부터 가져 옴
  • pre-rendering
    • 빈번하게 데이터가 update 될 때
    • SEO가 굳이 필요하지 않은 데이터
    
    

• 10월 18일(월) 모두의 네트워크 정리 (1)

  • 네트워크는 연결이며, 컴퓨터 네트워크는 2대 이상의 컴퓨터가 연결되어있는 상태를 의미한다.

  • 인터넷은 전세계의 크고 작은 네트워크를 연결하는 거대한 네트워크를 의미한다.

  • 패킷은 컴퓨터 간의 데이터를 주고 받을 때 네트워크를 통해 전송되는 데이터의 작은 조각을 말하며 큰 데이터도 작게 나누는 것이 규칙이다.

  • LAN(랜)은 좁은 범위의 네트워크로, 건물/특정 지역을 범위로 한다. 사무실 같은 곳에서 컴퓨터-프린터 연결하는 등

  • WAN(왠)은 인터넷 서비스 제공자(ISP)가 제공하는 구축된 네트워크. 랜과 랜을 연결한다고 생각해도 됨.

    
    

• 10월 19일(화) 모두의 네트워크 정리 (2)

  • 프로토콜은 규칙이며, A에서 B로 데이터를 전송하는 과정에서도 데이터를 작성하는 규칙, 보내는 규칙, 도착 후의 규칙 등등이 독립적으로 존재한다. 이 규칙은 서로 영향을 주지 않는다.
  • OSI 모델은 네트워크 기술의 기본이 되는 모델
    • 통신을 위해 7개의 계층(레이어)가 존재하며, 데이터는 송신할 때는 7계층부터 1계층으로, 수신할 때는 1계층부터 7계층으로 전달 된다.
    • 각 계층은 독립적이며, 전달 되는 동안 다른 계층의 영향을 받지 않는다.
  • TCP 모델은 OSI의 7계층을 4계층으로 줄였다. (합침)
  • 헤더
    • 송신 데이터를 전송하는데 필요한 데이터, 전달 받을 대상에 대한 정보
    • 송신 데이터 앞에 이 헤더를 붙이는 과정을 캡슐화라고한다
  • 캡슐화
    • 전송 데이터가 상위 계층에서 하위로 전달되면서 각각 필요한 헤더/트레일러를 추가해가는 과정
  • 역 캡슐화
    • 수신 데이터가 하위에서 상위로 전달되며 각 계층의 헤더를 제거하는 것
  • VPN (Virtual Private Network)
    • 가상 사설망.
    • 가상 통신 터널을 만들어 본사-지사 같은 거점간 연결을 가능하게 한다.
    • 인터넷 VPN / IP-VPN 이 있다
    
    

• 10월 20일(수) 모두의 네트워크 정리 (3)

  • 1계층 - 물리계층

    • 0, 1로 이루어진 비트열을 전기 신호로 변환 하는 계층
    • 컴퓨터의 랜카드가 0, 1을 전기 신호로 바꾼다

  • 데이터가 흐르는 물질적 선로

    • 유선은 트위스트 페어 케이블(랜 선, 우리 주변에 흔하게 보임) / 광케이블 등
    • 무선은 라디오파, 마이크로파, 적외선
    • 트위스트 페어 케이블이 가장 많이 사용된다.

  • 리피터

    • 전기 신호를 정형화하고, 증폭한다
    • 요즘은 다른 장비가 이 기능도 지원한다

  • 허브

    • 포트를 여러개 가진 리피터로 볼 수 있음
    • 여러대 컴퓨터에 연결할 수 있지만, 특정 포트로 들어오는 데이터는 나머지 모든 포트로 전송된다.

  • 스위치

    • 허브가 모든 포트에 강제 공유를 하는 문제를 보완한다.
    
    

• 10월 21일(목) 모두의 네트워크 정리 (4)

  • 이더넷. 랜의 데이터 링크 계층에서 가장 많이 사용되는 규칙.

  • 예를 들어 허브는 각 포트에 연결된 모든 컴퓨터에 데이터가 전송되기 때문에, A에서 B로 보낼 때 C, D ..등은 데이터의 내용을 보지 못 하게 하는 규칙이 있다.

  • 이더넷은 여러 컴퓨터가 동시에 데이터를 전송해도 충돌이 일어나지 않는 구조다.

  • 충돌을 막기 위해 시점을 늦추는 CSMA/CD 방법이 있었으나, 효율이 좋지 않아서 스위치라는 네트워크 장비를 주로 사용한다

  • MAC 주소(Media Aceess Control Address). 랜카드의 고유번호로, 전 세계에서 유일한 번호로 할당하려 하지만 종종 충돌 문제가 발생한다.

  • 이더넷 유형. 인터넷으로 전송되는 상위 계층 프로토콜의 종류로, 프로토콜 종류를 식별하는 번호가 들어간다.

  • 스위치.

    
    

• 10월 22일(금) 모두의 네트워크 정리 (5)

  • 라우터. 네트워크 계층에서 다른 네트워크로 데이터를 전송하기 위해 필요한 장비. 데이터의 목적지까지 어떤 경로로 가는 것이 좋은지 알려준다

  • IP 주소. 데이터의 목적지. IP 헤더에는 출발지 IP주소와 목적지 IP주소가 있다.

  • 라우팅. 목적지 IP 주소까지 어떤 경로로 데이터를 보낼지 결정하는 것

  • IPv4 / IPv6. IPv4 주소는 32비트로 되어 있어서 약 43억개의 주소를 만들 수 있다. 처음에는 충분하다 생각했지만 인터넷이 널리 보급되며 부족해졌다. IPv6는 128비트로 340간 개를 만들 수 있는데, 340간이란 340조 1조 1조를 말한다

  • 공인/사설 IP. IPv4 주소는 고갈되고 있기 때문에, 인터넷에 직접 연결되는 컴퓨터/라우터는 공인 IP 주소를, 회사나 가정의 랜에 있는 컴퓨터는 사설 IP주소를 할당한다.

    
    

• 10월 23일(토) 모두의 네트워크 정리 (6)

  • 전송 계층은 신뢰할 수 있는 데이터를 전달하는데 필요하다.

  • 오류를 점검하고, 전송된 데이터 목적지가 어떤 어플리케이션인지 식별한다.

  • 신뢰/정확한 데이터를 전달하는 통신을 연결형 통신, 효율적인 데이터를 전달하는 통신을 비연결형 통신이라고 한다

  • TCP. 전송 계층에 신뢰할 수 있는 정확한 통신을 제공하는 프로토콜

  • 3-way 핸드셰이크.

    • 클라이언트 => 서버에 연결 확립 허가 요청(SYN)
    • 허가한다는 응답(ACK) + 서버 => 클라이언트 데이터 전송 허가 요청 (SYN)
    • 전송을 허가한다는 응답(ACK)

  • 데이터 전송 후에도 연결을 끊기위한 요청을 교환해야한다.(FIN, ACK)

  • 3-way 핸드셰이크가 끝나고 실제 데이터를 주고 받을 때 TCP 헤더의 일련 번호/확인 응답 번호를 사용한다

    
    

• 10월 24일(일) 실무에서 느낀 점을 곁들인 Intersection Observer API 정리

  • 등장 이유. scroll 이벤트, 가시성 관찰에 사용되는 getBoundingClientRect의 문제점 때문에.

  • 스크롤 이벤트는 짧은 시간에 수 백, 수 천번의 이벤트가 동기적으로 실행될 수 있기 때문에, 메인 스레드에 큰 부하를 줄 수 있다.

  • getBoundingClientRect는 reflow를 발생시킬 수 있다.

  • 더불어 신뢰도 있는 공식 API의 필요성도 더해서, Intersection Observer API가 등장하게 되었다.

  • Intersection Observer API는 루트 요소/타겟 요소의 교차점을 관찰한다. scroll 이벤트와 달리 비동기적으로 실행되며, 가시성 구분 시 reflow를 발생시키지 않는다.

  • 요소의 모든 부분을 감싸는 가장 작은 사각형을 가정하고 교차성을 계산한다.

  • 인스턴스를 생성할 때 callback과 options를 받는다

  • Options

    • root.
      • 루트 요소이다. 반드시 타겟 요소의 조상이어야 한다.
      • null인 경우 브라우저 뷰포트가 기본이 된다.
    • rootMargin
      • 루트 요소의 범위를 확장할 수 있다.
      • 설정 단위를 꼭 입력해야한다.
    • threshold
      • 타겟이 루트 요소와 어느정도 교차했을 때 callback을 실행시킬 지에 대한 퍼센테이지 값 (단일 숫자 / 배열)

  • Callback

    • 타겟 요소의 관찰이 시작되거나, 가시성에 변화가 감지되면(threshold와 만나면) 실행된다
    • 메인스레드에서 처리되며 파라미터로 entries, observer를 받는다.

  • 대표적 용례

    • 페이지가 스크롤 되는 도중에 발생하는 이미지 / 다른 컨텐츠의 레이지 로딩
    • 무한 스크롤
    • 광고 수익을 계산하기 위한 광고의 가시성 보고
    • 사용자에게 결과가 표시되는 여부에 따라 작업/애니메이션을 수행할지 여부 결정하기

  • 한계점

    • 고속 스크롤링으로 인한 무의미한 광고 노출 방지, 광고 노출 보고를 모아서 보내는게 어렵다

  • 사용법은 따로 정리하지 않겠음!

    
    

• 10월 25일(월) 새로운 CSS 기능적인 의사 클래스 :is()와 :where()

  • :is() 선택자를 통해 선택자 중복을 줄일 수 있다!

    • h1 > b, h2 > b, h3 > b를 is(h1,h2,h3) > b로 줄일 수 있다!
    • button:is(.focus, :focus)

  • 브라우저 호환성도 나쁘지 않다. IE는 당연히 안 되지만, 사파리는 일부?만 된다

  • :is()가 할 수 있는 그룹화는 :where()도 할 수 있다.

  • 차이점

    • 명시도가 극명하게 다르다.
    • where은 명시도가 없다. 매개변수로 전달된 선택자 목록의 모든 명시도를 무시한다.
    • is는 가장 구체적인 선택자의 명시도를 따라간다. 즉 가장 높은 명시도가 그룹으로 묶인 다른 요소에도 적용되기 때문에 장점도, 단점도 될 수 있다
    
    

• 10월 26일(화) 웹 서비스 캐시 똑똑하게 다루기

  • HTTP 캐시를 효율적으로 관리하려면 Cache-Control 헤더를 섬세하게 조절해야한다.

  • 리소스. 브라우저가 HTTP 요청으로 가져올 수 있는 모든 종류의 파일

  • 브라우저가 서버에서 지금까지 요청한 적 없는 리소스를 가져오려고 할 때 완전한 HTTP 요청/응답을 주고 받는다. 리소스의 생명주기는 HTTP 응답에 있는 Cache-Control 헤더에 따라 결정된다.

  • 개발자도구 네트워크 탭에 General에서 from memory cache는 캐시 메모리에서 값을 가져왔다는 뜻.

  • 캐시의 유효시간이 지나도 캐시가 완전히 사라지는건 아니다. 이후 브라우저는 서버에 조건부 요청을 통해 캐시가 유효한지 재검증한다.

  • no-cache. 대부분 브라우저에서 max-age=0과 동일하다. 캐시는 저장하지만, 사용하려고 할 때마다 서버에 재검증 요청을 보내는 것

  • no-store. 해당 리소스를 절대 캐싱하지 않는다.

  • 캐시를 삭제하는 건 상당히 까다롭다. 브라우저 캐시는 쉽지만, 여러 CDN/중간 서버에 저장된 캐시는 각각 지워야한다. 따라서 max-age같은 값은 신중히 정해야한다.

  • public, private. CND/중간서버에서 특정 리소스를 캐시할 수 있는지

  • s-maxage. 중간서버에서만 적용되는 max-age값

  • HTML 파일은 새 배포가 이루어질 때 마다 바뀔 수 있기 때문에 불러올 때 마다 새로운 배포가 있는지 확인해야한다 따라서, max-age=0, s-maxage=31536000

  • JS/CSS 파일은 (토스의 경우) 빌드 결과의 버전 번호를 URL에 붙여서 고유하게 관리하기 때문에, 같은 URL에 대해 내용이 바뀔 경우가 없다. 따라서 리소스 캐시가 만료될 일도 없다.

  • 그렇기에 max-age=31536000 최대치로 설정한다!

    
    

• 10월 27일(수) 셀프서비스 디자인시스템 #1 – 디자이너 편

  • 우아한형제들 개발/플랫폼 조직은 도메인별로 구분되어 있다. 각 조직에 다양한 요구사항이 들어오는데, 이를 해결하는 방식, UX를 일관성있게 제공하기 어려웠다.

  • 어떤 종류의 기능은 항상 이렇게 동작하고, 어떤 종류의 정보는 항상 이렇게 표현한다.는 것을 정해두어 병렬로 업무를 처리하는 프로세스를 마련하고자 하는 목적

  • 디자인 시스템이 일관성을 부여하면서,

    • 기획자는 시스템 정책 정의에 더 집중할 수 있게 되었다.
    • 디자이너는 user flow를 그리는데 집중, UX 개선에 더 많은 시간을 투자할 수 있게 되었다.
    • 개발자는 기획 화면을 기반으로, 상세 디자인을 기다릴 필요 없이 개발을 진행할 수 있게 되었다.

  • 1년 후, 셀프서비스 팀 뿐 아니라 다른 서비스에서도 이 디자인 시스템을 공유하고 있음.

  • 공통디자인 TF 라는 조직 신설.

    
    

• 10월 28일(목) 셀프서비스 디자인시스템 #2 – 개발자 편

  • 디자인시스템의 시스템은 복잡한 사회적 체계의 맥락에서 구조와 행동을 통제하는 규칙들의 집합체에 가깝다.

  • 우형 셀프 서비스팀은 단순히 UI/UX 가이드라인이 정의된 UI 템플릿이 아닌, 프로토콜과 같은 매우 강력한 규칙으로 시스템을 만들었다.

  • 정보를 노출하는 원칙을 정하고, 이를 컴포넌트화해서 재사용성을 높이면 좀 더 효율적으로, 빠르게 개발할 수 있을 것

  • 코어 컴포넌트 / 코어 라이브러리 / 패턴 등으로 나눌 수 있다

  • 코어 컴포넌트

    • 대부분 추상 클래스, 이를 상속 받아 스택을 쌓아 올리는 구조
    • BaseComponent는 모든 컴포넌트가 상속 받아야한다.
      • 새로운 라이프 사이클 정의 (강제해야하는 메소드)
      • 이벤트 자동화 (컴포넌트가 마운트될 때 다양한 처리)
      • 로그 자동화 등을 수행한다. (자동 로그 전송)
    • PageContainer는 URL이 있는 모든 페이지가 상속 받아야한다.

  • 코어 라이브러리

    • CachedEntity. 캐시 관리 기법이 적용된 추상 클래스
    • Card, Form, Dialog 등..

  • 주로 객체지향 추상 클래스로 구성되어 있다.

  • 후기로는, 이제 함수형 컴포넌트만 쓰는가 싶었는데 여전히 클래스형 컴포넌트도 쓰이는 거 같다. 클래스형 컴포넌트에 대한 공부도 게을리해선 안 되겠다!

    
    

• 10월 29일(금) 배민쇼핑라이브를 만드는 기술: 채팅 편

  • 구매 인증 상황에서 분당 2만건도 넘는 메세지가..?

  • Sendird / FCM 같은 외부 메시징 서비스가 존재한다. 하지만 자체개발함!

    • 비용 / 인프라 / 단일 기기 최대 메세지 수 제한 등의 이유로

  • 과거 Thiiing을 만든 경험(DM)을 살린다.

  • WebFlux ?

  • 프론트엔드로서 방향성은 WebSocket을 최소한으로, RDB 직접 접근 배제

  • 너무 백엔드 얘기라서.. 이해는 잘 가지 않는..

    
    

• 10월 30일(토) node_modules로부터 우리를 구원해 줄 Yarn Berry

  • 기존 npm의 문제

    • 비효율적인 의존성 검색
      • node_modules 폴더를 이용하는 기존 방식(require.resolve.paths() 사용)은 npm이 검색하는 디렉토리의 목록을 반환한다.
      • 원하는 패키지를 찾지 못하면 계속해서 상위 디렉토리를 탐색하면서 느린 I/O 호출이 반복된다.
    • 환경에 따라 달라지는 동작
      • 위에서 언급한대로 상위 디렉토리를 계속 탐색한다는 건, 상위 디렉토리에 따라 해당 의존성을 불러올 수도, 아닐 수도 있음을 의미한다.
    • 비효율적인 설치
      • node_modules 디렉토리 구조를 만드는데 수 많은 I/O 작업이 필요하며, 수백 메가바이트의 큰 용량을 차지한다.
      • 의존성이 잘 설치 되었는지 검증하는데도 많은 I/O 호출이 필요하다. 따라서 yarn v1/npm은 기본적인 의존성 트리 유효성까지만 검증한다. 각 패키지 내용이 올바른지는 확인하지 않는다!
    • 유령 의존성
      • 중복 설치되는 node_modules를 아끼기 위해 패키지를 끌어올리는데, 이 과정에서 의존성 트리를 변경하게 되고 원래 require할 수 없었던 패키지지를 불러 올 수 있게 된다.
      • 이 경우 package.json에 명시하지 않은 패키지를 사용할 수 있거나, 다른 패키지를 제거하면 소리없이 같이 사라지기도 하는 혼란이 발생한다.

  • yarn berry는 plug`n`Play 전략을 이용해서 위 문제들을 해결한다

    • install시 node_modules를 설치하지 않고 .yarn/cache폴더에 의존성 정보를 저장하고 .pnp.cjs파일에 의존성을 찾을 수 있는 정보가 기록된다.
      • 디스크 I/O 없이 어떤 패키지가 어떤 라이브러리에 의존하는지, 각 라이브러리 위치는 어디인지 바로 알 수 있다.
    • Zip 아카이브로 의존성을 관리한다.
      • node_modules 디렉토리 구조를 생성하지 않기 때문에 설치가 빠르다
      • 중복을 피할 수 있고, 압축이기에 스토리지 용량을 아낄 수 있다
      • 파일 수가 적어서 변경 사항 감지/전체 의존성 삭제 등이 빠르다
    
    

• 10월 31일(일) MSW로 API 모킹하기

  • 서비스워커가 네트워크 요청을 가로채는 방식을 통해 mocking을 위해 어플리케이션 코드를 변경하지 않고 개발이 가능하다

  • 서비스워커가 네트워크 요청에 대해 method, URL을 기반으로 해당 사항이 있는 요청을 가로채서 MSW에 보내고, handler에 정의한 모의 응답을 받는다.

  • 서비스워커는 보안상의 이유로 HTTPS에서만 동작하고, 예외적으로 localhost만 허용한다.

    
    

• 11월 1일(월) SameSite Cookie란? 변경된 크롬 80 쿠키 정책

  • 크롬 80 (2020년 2월 경에 출시)부터 SameSite 기본값이 None에서 Lax로 변경되었다.
  • SameSite는 CSRF(Cross-Site-Request-Forgery) 공격에 대한 방어책으로 이전에는 개발자가 직접 취약성을 방지해야했다.
  • SameSite는 Strict / Lax / None 3가지 값이 존재한다
    • Strict. 가장 엄격하며, 도메인이 다를 경우 쿠키를 서버로 전송하지 않는다.
    • Lax. GET 요청처럼 특정한 경우에만 쿠키를 전송한다
      • a, link rel=prerender, form GET은 쿠키를 전송하지만 form POST, iframe, Ajax, img는 쿠키를 전송하지 않는다.
    • None. 도메인이 달라도 쿠키를 전송하지만, 쿠키에 Secure 특성을 태깅해서 HTTPS 연결이 필요함을 나타내야한다.
    
    

• 11월 2일(화) 공개적으로 학습하라!

  • 글쓰기 / 발표하기 / 스택오버플로우 등 공개적인 장소에 질문하고 답하기 / 영상 제작하기 / 소식지 만들기 / 만화 그리기 .. 등..

  • 좋은 영상을 보면 강사/발표자에게 감사를 전하고 궁금한 걸 물어보자

  • 오픈 소스에 기여하자

  • 나만의 라이브러리를 만들어보자

  • 좋아하는 것들을 따라 만들어보고, 어떻게 동작하는지 보자

  • 워크샵에서 강의하자

  • 컨퍼런스를 찾고 학습한 것을 요약하자

  • 가장 중요한 것은, 해결한 문제에 대해 문서화하자

    
    

• 11월 3일(수) 지금 당장 적용할 수 있는 '10가지 UI Tips'

  • 1. 삭제 전에는 반드시 확인을 받는다
  • 2. 예/아니오 라는 문구보다 '삭제하기'/'유지하기' 등 명확한 문구를 사용하자
  • 3. 삭제처럼 위험한 문구는 눈에 덜 띄게 하자
  • 4. 무엇을 눌러야 하는지 한눈에 알 수 있어야 한다. 화면 최하단이 아닌 스크롤과 상관 없이 CTA를 노출시키자
  • 5. 사용자에게 동작 이후에 대해 미리 알려주자
  • 6. 사람의 시선은 Z를 그림을 인지하고 레이아웃하자
  • 7. 불규칙한 요소를 정렬하자
  • 8. 더 나은 메뉴를 고민하자. 아이콘, 활성화 색상 등
  • 9. 소셜 로그인을 추가하자
  • 10. 디폴트 상태로 둘 템플릿을 만들자
    
    

• 11월 4일(목) 토스뱅크의 에러메시지에 동의하지 않습니다 - 에러메시지는 어떠해야 하는가

  • 에러메세지는 1. 사용자에게 에러의 내용을 충분히 설명하고, 2. 해결방안을 제시하는 것이어야 한다.

  • 프로그램의 에러메세지 자체를 일반 사용자에게 보여주는 건 가장 최악이다.

  • 개발 모드일 때의 사용자는 개발자이기 때문에 프로그램 에러를 보여주고, 프로덕션 모드에서는 일반 사용자라는 것을 명심하자

  • 에러 메세지는 격식체를 사용하자. 잘못했으면 격식을 차리자. 다만 '죄송합니다'같은 단어는 지양하자.

  • 금융 서비스라면 '돈을 옮기는 중' 보다는 '송금 중'이라는 단어가 제품의 신뢰도를 높인다. 사용자는 금융 전문가가 내 돈을 조심히 다뤄주길 바라기 때문. 즉 서비스마다 사용자가 우리 제품을 어떻게 생각하는지에 따라 적합한 단어를 선택해야한다.

  • 에러메세지라 해도 느낌표나 붉은색 경고 표시는 사용자의 긴장과 당황을 유발시키고 메세지를 읽지 않게 만들 수 있다.

    
    

• 11월 5일(금) [실무편] 회원가입을 쉽게 만드는 UI/UX 디자인은?

  • 사용자에게 꼭 받아야 하는 정보만 받는다. 이메일/전화번호/이름/나이/성별/직업 등은 서비스마다 필요한 내용이 다르다. 불필요한 정보를 요구함으로써 사용자가 이탈하는 상황은 피해야한다.

  • 간편 로그인을 제공하자. 모바일 유저의 경우 가상 키보드는 오타가 자주 발생하는 환경이기에 가능하면 가상 키보드를 사용하지 않게 하는 것이 좋다

  • 같은 이유로 생년월일도 키보드가 아닌 날짜피커를 통해 입력하도록 한다. (또는 숫자 키보드)

  • 사용자가 누르지 않았으면 하는 버튼(뒤로가기, 닫기 등)은 엄지영역에서 최대한 멀리 배치한다

  • 회원가입시 얻을 수 있는 이점을 짧은 문구로 설명한다

  • 한 화면에 너무 많은 선택지를 주면 사용성이 낮아진다. (로그인, 회원가입, 아이디찾기, 간편 로그인 등을 한 페이지에서...)

  • 섬세한 디자인으로 사용자가 불편하지 않게 한다.

  • 
    

• 11월 6일(토) 웹뷰 애니메이션 최적화 하기(FPS, Css hack, Throttle)

  • 애플은 주로 고해상도 사진, canvas 속성으로 애니메이션을 구현한다 => 인앱 웹뷰에서 좀 무리

  • 토스는 js보다는 videofmf 이용해서 애니메이션을 구현한다. 깔끔하고 반응이 좋지만 시간과 인력이 더 많이 들어가는 거 같다

  • 따라서 iframe + js + aos 프레임워크를 사용했다고 한다.

  • requestanimationframe 을 사용하자. 다음 리페인트가 진행되기 전, 해당 애니메이션을 업데이트하는 함수를 콜백한다. 실제 화면이 갱신되어 표시되는 주기에 따라 콜백 함수를 호출하기 때문에, 프레임 시작시 js가 실행되도록 보장한다. 즉 프레임을 유지한다.

  • 개발자 도구에서 command + shift + p를 누르면 프레임 확인이 가능하다!

  • will-change 해당 속성이 변환 될 속성이라는 것을 브라우저에게 미리 전달해서, 해당 레이어를 GPU를 통해 렌더링 하는 과정이다. 브라우저가 알아서 최적화를 한다.

  • 단, 브라우저는 이미 모든 것을 최적화하기 위해 다양한 시도를 하고 있다. 너무 많은 요소에 will-change를 적용하면 오히려 기기의 자원을 과도하기 소모하고, 페이지 속도가 느려질 수도 있다.

  • 스크롤 애니메이션은 매우 빈번하게 일어나므로 스로틀을 적용해서 최적화한다.

    
    

• 11월 7일(일) [Browser] Cookie 톺아보기

  • 쿠키는 세션 관리 / 개인화 / 트래킹. 크게 3가지 목적으로 사용한다

  • 브라우저는 서버가 응답에 설정한 set-Cookie 헤더를 보고 쿠키를 저장한다. 이후 같은 서버에 요청할 때 해당 쿠키를 포함해서 요청을 전송한다.

  • 단, 보안 정책 강화로 credential: 'include' / withCredential : true등으로 쿠키를 전송함을 알려야한다.

  • secure : HTTPS 요청일 경우에만 쿠키를 전송한다

  • httpOnly : 자바스크립트로 쿠키에 접근할 수 없다.

  • sameSite : None Lax Static 중 하나.

  • Domain : 쿠키의 도메인 유효 범위를 지정한다. 없으면 현재 서버 주소가 기본

  • Path : 쿠키의 디렉토리 유효 범위를 지정한다.

  • 퍼스트 파티 쿠키 : 사용자가 방문한 웹 사이트에서 직접 발행한 쿠키

  • 서드 파트 쿠키 : 다른 웹 사이트에서 발행한 쿠키. 구글은 23년 말까지 크롬에서 서드 파티 쿠키 지원을 중단하겠다고 발표했다. 보통 광고 서버에서 발행하는 쿠키

    
    

• 11월 8일(월) Template Literal Types로 타입 안전하게 코딩하기

  • Template Literal Type이란 기존 TypeScript의 String Literal Type을 기반으로 새로운 타입을 만드는 도구이다

  • type + type을 사용한 union도 만들 수 있다. 조합도 가능..!

  • Conditional Type과 더 강력한 추론가능. Conditional Type은 삼항 연산자와 비슷하다.

  • 
    

• 11월 9일(화) UX/UI의 10가지 심리학 법칙 ①

  • 
    

• 11월 10일(수) 2021년에 살펴볼 법한 브라우저 개발자 도구의 유용한 스타일 관련 기능

  • 
    

• 11월 11일(목) 타입스크립트 안전하게 활용하기

  • 
    

• 11월 12일(금) 브라우저 동작원리를 알아야 하는 이유가 무엇인가요?

  • 
    

• 11월 13일(토) 웹 성능 최적화를 위한 Tree Shaking 소개

  • 
    

• 11월 14일(일) 웹 성능 최적화를 위한 Image Lazy Loading 기법

  • 
    

• 11월 15일(월) WeakMap이 알고 싶다

  • 
    

• 11월 16일(화) 프로모션 없이 UX만으로 신규 가입 유저를 235% 늘리는 방법

  • 
    

• 11월 17일(수) [React] 리액트를 처음부터 배워보자. —01. React.js란 무엇인가?

  • 
    

• 11월 18일(목) [React] 리액트를 처음부터 배워보자. — 02. React.createElement와 React.Component 그리고 ReactDOM.render의 동작 원리

  • 
    

• 11월 19일(금) [React] 리액트를 처음부터 배워보자. — 03. React 의 Update 스케줄링 과정

  • 
    

• 11월 20일(토) [React] 리액트를 처음부터 배워보자. — 04. Functional Component와 useState

  • 
    

• 11월 21일(일) [React] 리액트를 처음부터 배워보자. — 05. Context API

  • 
    

• 11월 22일(월) [React] 리액트를 처음부터 배워보자. — 06. 합성 이벤트와 Event Pooling

  • 
    

• 11월 23일(화) [React] 리액트를 처음부터 배워보자. — 07. createRef와 useRef 그리고 useImperativeHandle

  • 
    

• 11월 24일(수)

  • 
    

• 11월 25일(목)

  • 
    

• 11월 26일(금)

  • 
    

• 11월 27일(토)

  • 
    

• 11월 28일(일)

  • 
    

• 11월 29일(월)

  • 
    

• 11월 30일(화)

  •