하루에 하나씩 기술 아티클 읽기

일일 아티클 2021.02.28 ~ 2021.05.31
일일 아티클 2021.09.01 ~ now

2021년

6월

• 6월 1일(화) ajax, fetch, xhr 비동기통신 이해하기

  • form 태그에 action, method 속성을 사용한 get요청이 구식 방법인가 찾아보다가 발견한 글

  • form

    • 비동기 통신이 나오기 전 서버와 통신하기 위해 사용하던 태그라고 한다.
    • form 작성, submit, 응답(새로운 페이지). 데이터는 query string으로 넘어간다.

  • XHR

    • 필요한 부분만 서버에 요청하고, 해당하는 내용만 받는게 가능하다.
    • 대역폭 낭비를 줄이고 서버와 '상호작용'을 할 수 있다.

  • AJAX

    • XHR을 사용하는 비동기처리 기술
    • 단, 자바스크립트에서 AJAX를 사용해서 비동기처리 통신을 하기엔 너무 복잡했다.
    • 그래서 JQuery에서 AJAX를 간단하게 사용할 수 있는 ajax()를 만들었다.
    • 하지만 ES6에서 fetch가 등장하며 사용 빈도가 줄어들었다.

  • fetch

    • 브라우저에 내장되어 있으며, 라이브러리 없이 비동기 통신이 가능하다.
    • URL, Option을 인자로 받고 Promise를 반환한다.
    • Option은 HTTP Method, headers, body 등을 설정할 수 있다.
    • response.json()은 응답을 JSON 형태로 파싱한다.

  • Axios

    • 모든 브라우저, Node.js에서 사용 가능한 Promise API를 활용하는 비동기 통신 라이브러리.
    • 응답시간 설정, json 자동 변환 등을 지원한다.
    
    

• 6월 2일(수) Clean Code #2 의미 있는 이름

  • 네이밍은 언제나 고민이지..
  • 의도가 분명한 이름. 좋은 이름을 짓는데 시간이 걸리지만, 좋은 이름으로 절약하는 시간이 더 많다.
  • 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하지 말자.
  • 너무 유사한 이름(특히 길어서 더 복잡한 경우)은 지양하자. 구분하기 어렵다.
  • 연속된 숫자, 불용어(noise word, 의미 없는 단어) 사용을 지양하라. Data, info 등은 의뫼로 불분명한 불용어이다.
  • 발음하기 쉬운 이름을 사용하라
  • 검색하기 쉬운 이름을 사용하라.
  • 인코딩을 피하라
    • 헝가리식 표기법. (접두어나 _ 등을 붙이는 방식) 지양
  • 자신의 기억력을 자랑하지 마라. (반복 횟수를 나타내는 i, k, j등은 몰라도, 나머지는 줄여쓰지 마라)
  • 클래스는 명사, 함수는 동사, 기발한 이름은 피해라.
  • 한 개념에 한 단어만 사용하라(manager, controller, driver등 비슷하지만 다른 이름 x 통일하라!)
  • 맥락을 고려하라.
    

• 6월 3일(목) 배민 오픈서비스, 혁신, 그리고 내 피같은 세금

  • 기술 아티클은 아니지만, 카카오 100 프로젝트에 있길래 한 번 보았다.

  • 배민의 비즈니스 모델 변천사? 수수료 0% 선언 후 울트라콜/슈퍼리스트 광고 상품으로 수익 실현, 흑자 전환과 고객 수 증대 성공

  • 다만 슈퍼리스트가 업주들의 경쟁을 과열 시킨다는 지적에 폐지, 울트라콜은 자금력 있는 업주들이 중복 등록하며 상권 독점하는 문제가 발생했다.

  • 결국 오픈서비스를 시작, 주문이 성사되는 건에 대해 5.8% 수수료 적용

  • 배달의 민족이 점주들의 고혈을 짜는 나쁜 기업이라는 이미지가 형성됨.

  • ... 요약하다가 그냥 쭉 읽어보았다. 기술적인 글은 아니지만, 배민이라는 회사는 가장 관심 가지고 있으니..

  • 배달 시장은 이 글 이전에도 계속 커졌으며, 코로나 이후로 급격하게 성장했다. 간혹 욕을 먹기도 하지만 이익을 추구하는 기업의 입장을 고려하지는 않는 목소리 같다.

  • 코로나가 해결되면 급격히 성장한 배달앱 시장이 조금 줄어들지? 궁금하기도 하고 배민이 배달 외에 하고 있는 사업들을 어떻게 풀어갈지도 궁금해진다.

    
    

• 6월 4일(금) React 상태가 불변성인 이유

  • React에서 상태값이 불변성을 유지해야하는 이유는 크게 두 가지다

    • 불변성을 유지하지 않는 경우, 특정 객체를 변경하면 이를 참조하고 있던 객체도 변경된다(Reference type). 이 경우 side-effect가 발생할 확률과 프로그램 복잡도가 높아진다.
    • 불변성을 유지하는 경우, 변경이 일어난 객체의 프로퍼티만 비교암으로서 React 최적화가 가능하다 (shouldComponentUpdate)

  • shouldComponentUpdate의 경우 이전 상태값과 이후 상태값을 !==로 비교하는데, 불변성을 유지하지 않았다면 비교 결과가 의도치 않게 동작할 수 있다.

  • react addon인 shallowCompare / PureRenderMixin은 최상위 오브젝트의 레퍼런스가 다른 경우에도 그 하위 오브젝트 1depth가 같다면 화면을 다시 그리지 않는다

  • 근데 useState의 setState의 경우에는 아닌거 같은데..? 무조건 렌더되는데.. 좀 더 찾아봐야겠다.

    
    

• 6월 5일(토) [FE] 프론트엔드 3대장 비교와 주관적인 최신 웹 동향에 대해 (feat. React를 기반으로)

  • React만 공부해본 입장에서 타 프레임워크도 한 번 훑어보고, 그럼으로써 왜 리액트를 쓰는지 좀 더 구체화해보자.

  • Angular

    • MVC 모델을 기반으로 하는 프레임워크로 출발
    • 어플리케이션을 어떻게 구성해야하는지에 대한 강제가 비교적 엄격함
    • 양방향 데이터 바인딩을 통해 화면-모델을 연결
    • 프레임워크 자체가 이미 구성에 대한 강제가 엄격하기에 대규모 웹 어플리케이션 개발에 적합하다는 평가가 많다 (엄격할수록 협업에는 유리한 면이 있다.)
    • 의존 관계에 놓인 객체가 서로 상호작용 하지만, 서로에 대해 잘 모른다 (의존성 약화)
    • 데코레이터(Decorator)를 사용한다. 이를 통해 의존성을 주입한다

  • React

    • 리액트는 라이브러리인가? 프레임워크인가?
    • 시작은 라이브러리였고, 여전히 라이브러리로써 사용되기도 하지만 오늘날은 react-router-dom이나 react-redux, cra 등을 조합하는 개발 환경에서 정해진 구성을 강제하는 프레임워크 성향을 가진다.
    • 이처럼 view 외의 기능은 외부 라이브러리에 주로 의존하는데, React에서 자체 지원하는 기능이 아니기 때문에 React의 버전이 업데이트 되면 해당 라이브러리들도 그에 맞춰 업데이트가 이루어져야하는 문제점을 안고 있다.
    • 핵심은 재사용 가능한 UI 생성, 가상 DOM을 이용한 렌더링. 그리고 단방향 데이터 흐름이다
    • React Native로 모바일 환경도 구성할 수 있으나 여러 문제(버전업이 느리다, 주축 메인 개발자가 한 명 밖에 남지 않았다는 루머, 호환성 및 성능, flutter의 존재감 등..)
    • Electron으로 데스크탑 프로그램도 개발 가능. (엄밀히 말하면 React에 속한건 아님)

  • Vue

    • 비교적 쉽게 배울 수 있다.
    • UI 구성이 html을 기반으로하는 평범한 템플릿이라서, React의 JSX나 Angular의 독자적인 쓰임법과는 달리 입문자의 러닝 커브가 낮다
    • 시기적으로 두 프레임워크보다 늦게 나와서 장점만 흡수할 수 있었다.
    • 양방향 데이터 바인딩을 지원한다. 다만 단방향을 주로 유지한다.
    • 용량이 가벼워 성능정으로 더 빠른 렌더링 가능.
    • React와 달리 데이터 불변성에 접근하는 방식이 다르기 때문에! (Vue는 데이터 직접 변경 용인)

  • Svelte

    • 사실은 컴파일러지만 암튼 프레임워크라고 해보자
    • 가상돔을 사용하지 않지만 매우, 매우 빠르다.
    • 같은 내용의 컴포넌트를 만들 때 더 적은 코드량을 요구한다
    • 번들링 된 크기가 매우 작다. 대표적인 번들러는 webpack, rollup, parcel
    • 자체 컴파일이 가능하기에 전체 앱을 번들링하여 제공 하는 방식 대신, 개발 서버에서 해당 파일에 대한 요청이 오는 즉시 모듈을 제공할 수 있다.

  • PWA(Progressive Web Applications)

  • Web Assembly(WASM)

    
    

• 6월 6일(일) React 상태 관리의 과거, 현재, 그리고 미래

  • UI, 서버 캐시, 폼, URL 상태 / 상태 기계 등의 용어가 있다. 정의는 본문 참조

  • 과거 React 컴포넌트는 고유한 로컬 상태를 가졌으나, 웹 어플리케이션이 복잡해지면서 컴포넌트간 로직을 쉽게 공유할 수 있는 솔루션들이 등장하게 됨

  • Redux

    • Flux 아키텍처의 구현체로서 만들어짐.
    • UI 상태와 서버 캐시 상태의 관리를 통합, 현재도 가장 널리 사용되는 라이브러리

  • 서버 캐싱 작업은 까다롭다. 서버 캐시 상태와 관련된 라이브러리가 다루는 문제들

    • 주기적인 폴링(Polling), 포커스시 재검증, 네트워크 회복 시 재검증, 지역적 상태 변경, Error Retry, 페이지네이션/스크롤 위치 복구 등.. (SWR 공식 문서 발췌)

  • contextAPI 자체는 상태 관리가 아니지만, useReducer와 함께 함으로써 상태 관리 솔루션이 된다.

  • 2021년 현재, 특정 문제 상황 해결에 중점을 둔 세부적인 라이브러리들이 등장하고 있다

    • Valtio : 값을 직접 변경하는식의 API를 제공하고자 Proxy 사용
    • Jotai : '계산된 값'과 비동기 액션에 최적화
    • Zustand : 모듈 상태에 특히 중점을 둔 매우 가벼운 라이브러리
    • Recoil : 데이터 흐름 그래프를 사용한 실험적 라이브러리

  • 반드시 상태 관리 라이브러리를 사용하라는 것은 아니다. 확실히 필요한 상황이 아니면 굳이 사용하지 말자

  • 상태의 가변성 vs 불변성 논란.

  • immer와 같은 코드는 코드는 가변적이지만 실행은 불변적이다.

  • URL 상태는 새로고침해도 브라우저 값을 관리하기에 동일한 UI를 볼 수 있으며, 다른 사람에게 URL을 공유함으로써 같은 화면을 볼 수 있다.

  • 대형 어플리케이션의 경우 Context만으로는 과도한 리렌더링 이슈가 있다. 이에 대한 대안으로 useSelectedContext Hook이 등장했다.

  • 프로젝트 규모별 폼 상태, UI 상태 추천 해결책은 본문 참조

  • 서버 캐시 상태는 SWR, React Query가 완벽한 솔루션이다.

    
    

• 6월 7일(월) 자바스크립트에서 switch (true) 패턴 사용하기

  • swtich에 true를 넣는 방식? 궁금하니 한 번 읽어보자

  • swtich true 패턴의 기본 원리는 값 뿐만 아니라 표현식과도 비교할 수 있다 는 것이다. 즉 case의 표현식 결과가 true라면, switch(true)와 일치하게 되어 해당 case문이 실행된다.

  • 종종 복합한 if/else문 대신 사용 가능하다

  • 데이터 유효성 검사에 유용하다. 본문 참조!

  • is~ 함수로 유효성 검사를 추상화하면 더 나은 가독성을 얻을 수 있다.

  • 누군가는 오히려 가독성이 떨어진다는 의견도 있다. 취향의 차이일지도? OR이 많은 조건문 사용시 if/else보다 switch true 패턴이 가독성이 좋다고도 한다. case는 break, return, throw 등이 없으면 아래 case문도 실행되니까 중복할 수 있다. (본문 참조!)

    
    

• 6월 8일(화) Mistakes | 주니어 리액트 개발자인 내가 실수하고 있었던 것

  • 이전 상태를 기반으로 새로운 상태를 세팅하기
    • 함수형 업데이트를 하라는 이야기이다. 단순 값 전달로 업데이트하면 batch 과정에 묶여서 한 번만 실행되기 때문에.
  • state 얕은 복사 금지
    • 이중 이상의 참조 데이터 구조일 때는 그 분기점마다 스프레드 연산자를 사용해야 한다.
    • 얕은 복사는 불필요한 리렌더, 최적화 방해 등의 요지가 있다.
    • 데이터 구조가 복잡해진다면 Immer.js를 사용해보자.
  • ??, || 연산자
    • 음, 이 사람은 ||와 &&를 아주 정확하게 이해하고 있는건 아닌거 같다 좌측, 우측으로 설명하는거 보니.. 정확한 의미는 '해당 표현식의 결과를 결정짓는 요소'가 리턴되는건데 ..
  • JSON Mock data 만들 때
    • 일일히 "를 사용해서 만들지 말고 객체를 만든 후 JSON.stringfy 하자
  • 컴포넌트 props 전달시 boolean true 표시, string 브라켓 하지 말 것
  • 여러 API 동시에 완료 시키기
    • Promise.all, Promise.allSettled 등으로 한 번에 처리
    • Promise.all은 중간에 하나라도 reject되면 모든 request 실행이 중단된다.
    • Promise.allSettled는 하나가 reject되더라도 모든 request를 실행하고 결과를 return한다.
    • async await와 함께 쓸 때, await Promise.all([함수 배열]) 형식으로 사용
  • 네스팅보다 early return을 고려하기
    • loading처럼 삼항연산자로 return 값을 달리하는 구조에서, 오히려 early return하는게 더 깔끔하다
    
    

• 6월 9일(수) npx create-react-app ... 그래서 npx가 뭐길래?

  • cra를 설치할 때는 npx로 설치하고, npm i와 달리 node_modules에 설치되는게 아니라 지정한 루트에 설치하곤한다. 뭐가 다른걸까?

  • npx는 npm5.2 버전부터 새로 추가된 도구로, 레지스트리에서 호스팅되는 CLI 도구 및 기타 실행 파일을 쉽게 사용할 수 있다.

  • 언제 사용하나?

    • 로컬로 설치된 도구들을 npm run scripts 없이 사용할 때. 직접 경로, shell을 사용하는 것보다 훨씬 편리하다.
    • 한 번만 사용할 커맨드를 실행할 때. npm으로 global하게 설치하면 여러 문제가 생기지만 npx로 설치하면 최신 버전 패키지 설치, 실행 후 해당 패키지를 삭제한다.
    • 다른 Node.js 버전들로 커맨드를 실행할 수 있다. node-bin은 nvm, nave, n과 같은 버전 관리자를 사용하지 않고 서로 다른 노드 버전을 사용할 수 있게 해준다. 테스트 라이브러리가 특정 node 버전에서 파손된 경우에 유용하다
    • 인터렉티브한 npm run 스크립트들을 개발할 때.
    • gist에 기반한 스크립트를 친구와 공유할 때. npx는 npm 자체에서 허용하는 모든 특정자를 받아들이므로, 단일 명령으로 사용자가 직접 호출할 수 있는 요점을 만들 수 있다.
    
    

• 6월 10일(목) 타임존과 moment isBetween('어제', '오늘')

  • 전 세계의 다양한 시간대를 표시하는 방법 타임존. 이 타임존이 필요한 이유와 역사, 프런트에서 타임존을 어떻게 지원하는지. 개발자라면 한 번은 꼭 부딪치는 타임존!

  • 우리나라는 가로 너비가 좁아서 시간대를 나누지 않아도 불편함이 없다. 중국은 가로가 넓음에도 불구하고 하나의 시간대를 쓴다. 반면 미국은 타임존을 나누어 사용 한다. 동-서부가 3시간 정도 차이남

  • 타임존은 경도에 따라 절대 바뀌지 않는 시간 오프셋을 지정하는 다른 표현이다.

  • 타임존을 변경하는 기능은 ECMAScript 명세에도 없어서, 브라우저나 Node.js는 설치된 OS에 설정된 타임존을 따르도록 구현되어있다. 따라서 브라우저에서 다른 나라의 타임존으로 바꾸려면 OS 설정을 바꿔야한다.

  • 타임존은 데이터베이스를 기반으로 변경 내역을 관리해야한다. 가장 신뢰가는건 IANA Time Zone Datebase.

  • ECAMScript에 타임존 정의가 모호하고, 브라우저가 이 DB를 갖고 있지 않아서 Date 타입만으로는 타임존을 변경할 수 없다.

  • 해결 방법은 웹 페이지에 타임존 데이터베이스 내장 또는 Intl.DateTimeFormat 사용

  • moment.js 라이브러리가 좋은 대안이었으나, 이제 유지보수만 하게 되어 dayjs, luxon, date-fns 등이 새로 나타났다.

    
    

• 6월 11일(금) Uinx/Linux: Shebang과 env에 대한 설명 (#!/usr/bin/env)

  • npx로 수제 cra를 설치시키려는 시도 중 얻게 된 키워드 shebang. 최근 맥과 윈도우라는 OS 차이로 인해 개발에 어떤 영향이 있나 몸소 체험중이다..

  • 킹갓맥 생태계인거 같다..

  • shebang(쉬뱅), #! 는 2Btye의 매직넘버로 이 스크립트를 실행시켜줄 프로그램의 경로를 지정하는 역할을 한다. html의 <!DOCTYPE>과 비슷한 역할인듯

  • 하지만 프로그램의 경로는 시스템 환경에 따라 달라진다. 그렇기에 env를 지정한다

  • 내가 작성한 js 스크립트를 node로 읽으라는 명령을 위해 #! usr/bin/env node를 상단에 입력했는데, 윈도우에서는 동작하지 않고 무시돼서 에러가 발생했다.

  • 물론 이후 알아보니 이것만의 문제는 아니었지만.. OS의 차이를 조금은 실감하게 되었다

    
    

• 6월 12일(토) 트리 쉐이킹 되는 UI 라이브러리 만들기 ㄱ부터 ㅎ까지

  • UI 라이브러리를 만들기 위한 방법 소개.
    - 트리쉐이킹 : 웹팩에서 JS 모듈을 번들링 할 때, 사용하지 않는 코드는 제거하는 최적화 과정. 라이브러리의 경우 사용자는 그 중 일부만 사용하고자 할 수 있다. 따라서 모든 라이브러리를 사용하지 않고, 원하는 부분만 사용함으로써 용량을 줄여 가볍게 사용하는 전략인 듯
    - 절반도 이해 못 한 것 같다.. 아주 복잡하다.

  • 단순히 동작하는 것을 떠나서 사용자가 사용하기 쉽게, 그리고 "가볍게" 사용할 수 있도록 노력하는 흔적이 보인다.

    
    

• 6월 13일(일) 독서가 내게 가져다 준 것들

  • 사실 학교를 졸업할 때 개발 관련 도서 7권 정도를 지원 받았는데 아직 한 권도 제대로 다 읽지 못했다.

  • 공부를 안 하는건 아니고 아침부터 새벽까지 하고는 있는데 책을 통한 공부는 잘 안 하게 되는거 같다. 일단 다 읽는데 부담도 있고 당장 필요한지 (일일 아티클도 뭐 그렇긴한데 부담은 적으니까) 싶어서..

  • 그런 의미에서 제목에 이끌려 읽어보았다.

  • 나 또한 군대에서는 책을 많이 읽다가 전역 후에(사실 병장쯤부터) 책과 다시 멀어진 케이스다. 더 쉽고 재밌는 소비제가 넘쳐나니... 짧게 만들어진 습관은 금방 사라지는거 같다.

  • 영상 매체에 익숙해져 긴 글, 깊은 사고를 하기 힘들어졌다는 말에 너무 공감한다. 그래서 틱톡같은 짧은 영상 매체가 인기를 끄는걸지도.. 사람들은 생각하기 싫어하는 쪽으로 세뇌되고 있ㄸ ㅏ..

  • 안 되는 이유부터 말할 것인가, 어떻게든 되게 해볼 것인가?? 사실 안 되는건 생각보다 없다..

  • 글을 읽다보니 18년도에 토론 모임을 하고 내 생각에 대해 고민하던 때가 떠올랐다. 지금은 공부에만 집중하다보니 하지 못하고 있는 일들. 책을 읽으며 넓어진 세계관. 현실적으로 당장 독서를 시작하기엔 힘들거 같지만 노력은 해봐야겠다.

    
    

• 6월 14일(월) 바벨과 타입스크립트의 아름다운 결혼

  • 최근 수제 CRA를 만들면서 동작한다 싶었는데 ts-loader만으로 커버하기엔 한계가 명확하다. 특히 import React from 'react' 생략하기는 ts-loader만으로는 안 되는거 같다.

  • 바벨 7 이전에는 TS로 컴파일한 JS를 다시 바벨로 컴파일하곤 했지만 7 이후로는 그럴필요 없다.

  • 바벨은 TS 코드 어떻게 처리하는가?

    • 모든 TS를 제거하고 일반 JS로 바꾸고 진행한다.
    • 이는 매우 빠르다. TS 컴파일러는 코드를 하나만 수정하고 저장해도 한참의 컴파일 과정을 거친다. 그러다 오타라도 있으면 다시 수정하고 컴파일해야한다..

  • 전체적으로 그냥 번역기를 돌린 듯한 내용이라 아쉽다 NHN처럼 큰 회사에서 이런식으로 글을 관리한다니.. 번역돌리다 문제가 생긴건지 깨진 텍스트도 있고..

    
    

• 6월 15일(화) 당신은 이미 펑터Functor를 알고 있다

  • 이 글의 시작은 map의 TypeScript 타입을 지금 바로 써낼 수 있느냐? 이다. 나는 할 수 없었기에, 이 글을 읽어보기로 했다.

  • TypeScript에는 그저 타입만 만족하는 잘못된 구현이 존재한다. 즉 타입만 통과한다고 다가 아니다.

  • functor라는 개념이 나온다. 굉장히 수학적인 내용같은데.. '함자'라고 해서

    • 제네릭한 타입을 품을 수 있다.
    • 자신이 품고 있는 값에 함수를 적용할 수 있다.

  • 대표적으로 Array가 제네릭을 품을 수 있고, map이라는 메서드로 원소에 함수를 적용할 수 있다.

  • 이후 글은 너무 어렵다..! TS 공부를 기초부터 제대로 싹 해야겠다.

    
    

• 6월 16일(수) Github Action 사용법 정리

  • Github Action이라는게 있는건 아닌데, 정확히 어떤 기능일까 궁금하니까 알아보자

  • workflow를 자동화 할 수 있도록 도와주는 도구이다.

    • Test Code
      • 특정 함수 return값이 어떻게 나오는지 확인
      • 타입 확인
      • 변수값에 특정값이 들어가는지 확인
      • 쿼리를 날리고 응답이 제대로 오는지 정합성 체크
    • 배포 자동화
    • 기타 자동화하고자 하는 스크립트
      • 주기적으로 데이터 수집 및 처리 등..
    • 다양한 버전(node, python 등..)에서도 동작하는지 체크

  • 무료 / 유료 버전이 있다. action 개수, 시간, 용량등 제한이 있다

  • Github Action을 이해 하기 위해 workflow, event, job, step, action, runner에 대해 알아야 한다. 자세한 설명은 본문참고

  • 스케줄 설정은 가능하나 즉시 실행은 아직 없는 듯

  • 이미 만들어진 action을 마켓에서 가져다 쓸 수 있는 듯.

    
    

• 6월 17일(목) 글자가 그려지는 애니메이션

  • 오늘 빰빰이 언급한 svg로 글자 그리는게 마침 벨로그 상단에 떴길래 오늘은 요걸로

  • svg는 벡터 기반. 크기 조절해도 이미지가 깨지지 않음.

  • svg의 text 태그에 각 글자를 넣고 css에서 스타일 변경 가능. stroke-width, stroke, fill등

  • stroke-dasharray

    • 외곽선을 대쉬 형태(- - -)로 만든다
    • 수치가 길어질수록 대쉬 길이가 늘어난다. 글자 길이(750?)으로 지정하는게 최대인듯

  • stroke-dashoffset

    • 어느 지점에서부터 대쉬가 시작할지 결정한다.

  • 즉 대쉬 길이를 글자 길이로 고정하고 dashoffset을 조정한다.

  • keyframes로 중간값까지 디테일하게 조정하면 더 깔끔!

  • animation-delay값을 달리해서 더 그럴듯하게 조정

    
    

• 6월 18일(금) [Recoil] Recoil 200% 활용하기

  • 드디어 공부하기 시작한 리코일을 알아보자..
  • 왜 Redux가아닌 Recoil인가!
    • Flux 아키텍쳐에 맞는 라이브러리가 Redux였으나 간단한 상태 하나를 관리하더라도 많은 양의 코드를 필요로 하며, React에 최적화된 라이브러리가 아니다.
    • 사용량은 제일 높지만 만족도는 상당히 낮다.
    • Recoil은 소개부터 "A state Management library for React"이다. hooks를 사용한 개발자라면 누구나 쉽게 사용할 수 있다.
  • atom으로는 비동기 처리를 할 수 없기 때문에 selector를 사용한다.
  • 컴포넌트에서 비동기 처리 후 atom에 저장하는 방식을 selector에서 한 번에 처리 가능! 특히 캐싱기능이 자체 탑제되어있다!
  • selector는 반드시 순수함수여야한다. 또한 read-only학 RecoilValueReadOnly객체로, return값만 가질 수 있으며 스스로를 set 할 수는 없다.
  • selector로 비동기 처리 중에 보여줄 UI는 React.Suspense / Recoil의 Loadable로 처리
  • 아직 신생 기술이라 생태계가 작고, 그만큼 예제 코드나 자료도 부족하지만 현재 데이터 계층 도구 중 가장 관심 받고 있는 기술이며, hooks를 사용하는 방식이 React 개발자에게 아주 친숙한 기술
    
    

• 6월 19일(토) 어떤 개발자가 될까?

  • 최근 우테캠 자소서, 면접 등을 준비하면서 어떤 개발자가 되고 싶은가에 대한 질문에 선뜻 대답하기 어려웠다. 그래서 이 글의 제목이 끌렸던것 같다

  • 이 분은 위코드가 광고를 가장 적게해서 좋았다고 한다. 나도 코드스쿼드를 선택한 이유 중 하나가 과장광고를 하지 않는다는 것이었다. 가장 큰 이유는 우형, 네이버 등에서 믿고 맡기는 교육업체이기 때문이었지만..

  • 하루에 두 번 감사를 표한다. 뭔가 훈련소에서 시켰던 일이 떠오른다..

  • 어떤 개발자가 될까. 누군가 나를 "함께 일하고 싶은 개발자"라고 생각하길 바란다고 한다. 뻔한 대답같지만, 좋은 대답이기도 하다. 나도 그렇게 생각하니까 흠..

    
    

• 6월 20일(일) [개발상식] JSON과 JavaScript Object의 차이점

  • json은 API 통신을 하면서 특히 많이 쓰게 되는 데이터 타입이다.

  • JavaScript Object는 JS Engine 메모리 안에 있는 데이터 구조이고, JSON은 객체의 내용을 기술하기 위한 text 파일이다.

  • JSON은 모든 키를 따옴표로 묶어야하며 string 타입이고, 함수를 값으로 할당할 수 없다(문자열이니까)

    
    

• 6월 21일(월) 신입 개발자 혼자 어디까지 만들 수 있을까?

  • 이 제목을 보고 어떻게 안 볼수가 있을까..

  • 10월에 본격적으로 공부해서 12월에 인턴, 1월 정규 채용이라.. 대단하다!!

  • 사수 없는 개발이라.. 기회일 수도 있지만 나는 가능하면 사수가 있었으면 한다. 혼자 우여곡적을 겪는 것또한 경험이겠지만 너무 삽질을 하거나, 운이 나쁘거나? 잘못하면 성장 기대치가 낮아질 것 같다.

  • 다양한 기능을 아주 흥미롭게 개발한거 같다. 로직 정리를 중요시해서 메모장에 각 케이스와 예외처리까지 미리 정리하고 개발을 진행한게 본받을 점인 것 같다.

  • "리팩토링은 다 끝내고 하는게 아니라 그냥 매일 하는 것"

  • 사수없이 혼자 해낸 노력에 박수를 보낸다..

    
    

• 6월 22일(화) 개발자가 블로그를 운영해야 할 이유

  • 1. 정확한 지식을 얻을 수 있다.
    • 고무 오리 디버깅.. 누군가에게 설명하는 행위 자체만으로도 도움이 된다.
    • 블로깅은 기억을 오래 보존하고, 보다 정확한 지식을 쌓는데 도움이 된다.
    • 글쓰기 실력이 느는 것은 덤
  • 2. 좋은 동기가 된다.
    • 포스팅 주기를 정해두면 소재를 찾게 되면서 학습 활동의 계기가 된다.
  • 3. 새로운 기회가 된다.
    • 나 정도의 재능을 가진 사람은 어디에든 있다. 블로그는 좋은 홍보 수단이 될 수 있다.
    • 어떤 글을 쓰느냐에 따라 생각지도 못한 기회를 얻을 수도 있다.
  • 4. 의외의 부수입으로 이어질 수 있다.
    • 번역 / 교육 / 특정 주제 글 / 등의 의뢰를 받을 수도 있다.

  • 어떤 글을 쓰면 좋을까?

    • 번역
    • 배운 것 정리
    • 간단한 것 (anchor 태그의 download 속성에 관한 글)
    • 고생한 내용

  • 내가 블로깅을 하는 이유는 학습한 내용을 더 구체화해서 정리하고, 다른 사람들에게 공유하기 위해서?

    
    

• 6월 23일(수) 누구나 원하는 개발자되기

  • 이력서를 통해 어떤 기술을 사용했고, 채용 대상 기술셋에 맞는지

  • 사전 과제를 통해 실무 능력을

  • 기술 면접에서 기술의 이해, 경험에 대한 깊은 질문으로 검증

  • "이력서라면 글을 통해, 사전 과제라면 코드를 통해, 면접이라면 말을 통해" 보여주자

  • 이력서는 주기적으로 업데이트하면서 관리하자

    • 프로젝트 목록이 가장 중요하다
    • 단순히 경험을 구구절절 늘어놓지 말고, 역량을 어필할 포인트를 작성하자

  • 자신의 성과를 파악하자. "단순히 기술을 나열하기보다는 성과라는 스토리를 담도록 노력하자"

  • 사전 과제에서 보고 싶은건 정상 동작이 아니라 어떤 코드인가 이다. (정상 동작은 당연하다)

  • 잘 알고 있다고 생각하는 것도 말로 설명하려면 어려운 경우가 있으니, 설명하는 연습을 충분히 하자.

    
    

• 6월 24일(목) 🧐 아무도 가르쳐 주지 않는 것

  • 비슷한 내용의 책이 있는데 아직 읽어보진 않았다. 흥미로운 제목이다.

  • Log

    • 간단한 프로젝트를 하더라도 logging을 꼭 하자. 사용자 분석에 도움이 된다.
    • Exception 발생 시 error log를 남기는게 중요
    • log의 용량을 무시하지 말자. log를 잘 남기고, 지우며 관리하자. log rotation

  • ENV

    • Node를 다룰 때 많이 접한다.
    • 다양한 서버를 구성할 때 필요하다.

  • config

    • local, dev/prod 서버 어디서 실행될 건지
    • 어떤 환경에서?

  • Test

    • (나랑 같은 생각을 하네.. 테스트 코드는 어떻게 테스트, 검증 하지?)
    • TDD가 중요한가 아닌가는 의견이 분분하지만, 중요하다는 의견이 더 강해지는 듯?

  • Git

    • gitflow, workflow 협업에 중요하다. branch를 어떻게 구성하고, 어떤 역할인가. branch 전략
    • git kraken. git flow를 소스 트리처럼 시각화해준다. 눈으로 확인하거나 rebase하는 용도로 쓰임. 배터리 많이 먹음

  • CI/CD

    • git commit, git push로 테스트, 배포를 자동화할 수 있다.
    • 간단하게 해보고 싶으면 Heroku 무료 버전 사용하자.
    • Gitlab, Digital Ocean도 있다. (유료)

  • AMP / Analytics

    • 배포한 앱이 잘 동작하는지, 사용자 정보에 대한 분석 등을 한다.
    • Sentry, pm2 monitor, google analytics / firebase

  • Debugging / Profiling

    • 가장 중요하고 잘 해야하는 것..일지도..
    • 디버깅은 문제가 생겼을 때
    • 프로파일링은 함수의 실행 시간, 이벤트 발생 빈도 등을 측정해서 프로그램 성능을 높이고자 한다.
    • Flow, Lighthouse, Artillery
    
    

• 6월 25일(금) 2020년 회고

  • 우테캠 합격 기념, 코쿼 졸업 기념해서 찾아보다가.. 가볍게 읽어보자

  • 이제보니 코쿼 초반에 읽었던 글이다. 이 글에서 블랙커피 스터디를 처음 알게 되었지.. 상당히 의미있는 글이네?

  • 프론트엔드 공부를 시작한지 얼마 되지 않은 사람이 우테캠에 합격하고, 진행한 공부들에 대한 글이다. 노력 많이 하셨다..

  • 노력한 점 / 잘한 점 / 아쉬운 점으로 나뉘어져있어서 좋았다.

    
    

• 6월 26일(토) babel-loader와 ts-loader의 빌드 결과가 다른 현상

  • ts-loader는 핫 모듈 리플레이스먼트(HMR)을 지원하지 않는다. 필수적인건 아니지만 익숙해지면 없는게 불편하다.

  • babel-loader 바벨 버전7부터는 TS를 지원한다. 다만 ts-loader와 빌드 결과가 좀 다르다.

  • 클래스의 필드가 undefined로 초기화 된다.

    • 상속 구조의 클래스에서 발생하며, ts-loader에서는 예상대로 동작하지만 babel-loader는 그렇지 않다.
    • 필드 선언(Filed declaration)은 아직 실험적 기능(stage-3)이기 때문에 이를 사용하려면 @bebel/plugin-proposal-class-properties 플러그인을 추가해야한다.
    
    

• 6월 27일(일) 서버리스는 서버가 없다?

  • 서버리스는 서버가 없다는 얘기가 아니다. 그런건 불가능하다.

  • 백엔드이지만 직접 서버를 관리하지 않는 경우를 말한다.

  • 하드웨어를 직접 관리하지 않고 외부에 맡기게 된다 (AWS E2, 클라우드)

  • 소프트웨어 또한 직접 관리하지 않고 코드를 서버에서 분석, 함수 단위로 쪼개서 우리가 직접 관리하지 않아도 되는 서버에 올린다 (AWS lambda, 서버리스)

  • 서버리스의 장점

    • 요청이 들어오면 필요한 함수만 깨워서 호출하고 작업 처리, 요청이 끝나면 다시 수면.
    • 가격이 저렴해짐 (24시간 서버를 띄울 필요 X). 요청 건당 처리된다.

  • 서버리스의 단점

    • 플랫폼에 종속적이다.
      • 기존 서버들은 코드를 다른 서버에 옮기는게 쉬웠으나, 서버리스는 타 서버로 마이그레이팅이 힘들다.
      • 어플리케이션의 구조가 바뀌고
      • 서버에 대한 통제를 잃어버린다.
    • 1ms 남짓한 시간이더라도 호출에 시간이 더 오래 걸린다.
      • 함수 단위로 쪼개서 필요할 때 호출하기 때문에
    
    

• 6월 28일(월) 상태관리 라이브러리 mobx

  • 리덕스에 비해 비교적 단순하다

  • 상태(state), 데리베이션(derivation), 액션(action)

  • 상태(state)

    • 어플리케이션의 상태를 담고 있는 값

  • 데리베이션(derivation)

    • 상태의 변화에 반응하는 것(UI, 데이터, 백엔드와의 연동 등..)
    • 계산된 값(computed values), 리액션(reactions)로 분류할 수 있다.
    • 계산된 값은 순수 함수를 사용한다. (타이머 시간 경과 => 화면에 출력할 값 변경)
    • 리액션은 사이드 이펙트를 만든다. (타이머 시간 경과 => 화면에 출력할 값 변경 => 돔 조작)

  • 액션(actions)

    • 데리베이션을 유도하기 위해 상태를 변경하는 역할을 한다. (상태에 값 할당)
    • strict mode에서는 action에서만 상태를 변경하도록 강제하지만 실제 프로젝트를 할 때는 상태 변수에 할당하는 것만으로 잘 동작. 리덕스에 비해 장점이라 생각

  • 원자적 / 동기적 데리베이션

  • 원자적 : 상태 변경 요청이 여러번 오더라도 단 한 번만 반응한다.

  • 동기적 : 모든 데리베이션은 동기적으로 갱신되기에 액션이 상태를 변경하고 곧장 상태값을 조회해도 변경된 값을 보장한다.

  • 계산된 값은 느리게 갱신된다. 계산된 값은 사용되어야만 동작하고, 모든 상태 변화에 반응하는 것은 아니다.

  • 모빅스를 리액트에서 사용하기 위해서 상태 변화에 따라 리액트 렌더 사이클을 돌려주는 역할이 필요하다 (redux의 connect) react-mox 패키지가 그 역할을 한다.

    
    

• 6월 29일(화) HTML5 폼 검증에 대해 정리해 보자

  • 폼은 웹 개발에서 반드시 다루어야할 필수 기술이다.

  • 폼 관련 라이브러리는 브라우저가 자동으로 처리하는 폼 검증 기능을 끄고(novaildate) 사용한다.

    • 앵귤러 ngForm
    • 뷰 vee-validate
    • 리액트 antd

  • input 태그의 속성 required는 브라우저가 해당 폼을 필수 입력으로 인지하고 값을 검증하게 한다.

  • HTML5 입력 요소는 7가지 검증 속성(validation attributes)을 제공한다.

    • required: 필수
    • minlength / maxlength : 최소/최대 길이
    • min / max : 최소/최대 상수
    • type : 타입(이메일, 패스워드 등..)
    • pattern : 패턴(정규표현식)

  • css의 가상클래스 :valid, :invalid를 통해 규칙에 맞는/맞지 않는 값을 입력했을 경우 해당 input 태그의 css를 컨트롤 할 수 있다.

  • HTML5 스펙을 따르는 모던 브라우저의 폼 입력 값 처리 프로세스

    • 사용자가 값 입력
      • 검증 결과에 따라 :valid/invalid 가상 클래스 추가
    • 사용자가 폼 데이터 전송 시도
    • 규칙에 따라 입력값 검증
      • 통과하면 데이터를 서버로 전송
      • 불통과시 서버 전송 차단
      • 오류 문구 노출

  • 더 나은 ux/ui를 위해서 js로 오류 메세지를 적절하게 보여주기 (본문 참조)

  • constraint validation API. 오류 메세지를 요구사항에 맞게 커스터마이징 할 수 있다. (본문 참조)

  • 오류 메세지의 스타일링 또한 커스터마이징 할 수 있다.

    
    

• 6월 30일(수) 패스포트 동작 원리와 인증 구현

  • 로그인으로 등록된 사용자임을 확인하기 위해 노드에는 passport 패키지를 많이 사용한다.

  • 웹 어플리케이션에서 인증을 구현하기 위한 방법으로 세션, 쿠키가 있다.

    • 서버 : 접속한 브라우저 정보를 세션에 저장, 세션 아이디를 브라우저에 쿠키로 전달
    • 브라우저 : 쿠키에 담신 세션 아이디를 저장, 다음 요청부터 헤더에 세션 아이디를 담아 서버로 전송
    • 서버 : 헤더에 담긴 세션 아이디로 접속한 브라우저를 식별

  • express를 사용해 로그인 로직을 만들고 MyPassport 클래스도 만드는 글이다. 코드를 복붙해오긴 그러니까 본문을 참조하자

  • myPassPort 클래스는 미들웨어 함수를 반환하는 메소드를 가지고 있고, 싱글톤 객체를 생성한다.

  • session 메소드로 세션에 저장된 로그인 정보를 이용해 유저 객체를 찾는다.

  • 로그인에 성공한 유저만 접근할 수 있는 엔드포인트를 만들고 처리한다

  • 로그아웃은 세션에 저장한 데이터를 삭제하면 된다.

  • passport 라이브러리 사용 방법도 나와있음!

  • passport 라이브러리는 유저네임/비밀번호를 이용한 인증 뿐 아니라 auth, jwt 인증 등도 가능하다. 공통 인증 로직은 passport가 처리하고 구체적인 방법을 전략{strategies) 이라는 개념으로 분리해 놓았다.

    • 유저네임/비밀번호 : passport-local
    • 페북/트위터 등 : passport-facebook, passport-twitter
    • jwt : passport-jwt
    • 필요한 패키지를 npm으로 설치해서 사용할 것

  • 자세한 사용 방법은 본문 참조

    
    

7월

• 7월 1일(목) 파일명 컨벤션과 웹팩/노드 오류

  • Git, MacOS에서 카멜케이스/파스칼케이스는 가끔 오류를 발생시킨다.

  • 파일명을 fooBar.js에서 FooBar.js로 변경하면 깃이 이 변화를 감지하지 못 한다던가, MacOS에서는 문제 없지만 리눅스 배포환경에서는 문제가 생긴다던가.. (import시)

  • 깃은 대소문자를 무시하기 때문에 대소문자를 변경해도 인지하지 못한다. 파일명 대소문자를 바꾸고 코드에서 해당 모듈을 바뀐 이름으로 찾으려고하면 에러를 발생하는 코드가 된다. not found

  • MacOS 또한 파일명 대소문자를 무시한다. node에서 require('FooBar.js')든 require('foobar.js')든 상관 없다. 하지만 리눅스 환경에서는 대소문자를 구분하기에 맥에서 동작하던것이 리눅스에서 동작하지 않을 수 있다.

  • 깃의 경우 변경된 파일명을 깃에게 직접 알려주는 방식으로 해결할 수 있다

    git mv fooBar.js FooBar

  • 운영체제에 따른 차이(MacOS, 리눅스..)는 처음엔 웹팩 플러그인으로 해결했다. 웹팩을 사용하지 않는 환경에서는 파일 컨벤션을 오해의 소지가 없도록 카멜케이스에서 케밥 케이스로 변경하거나 소문자만 사용하는 방식으로 변경하는게 편하다.

  • npm의 패키지들을 유심히 살펴보면 모두 케밥케이스를 사용한다. 이런 이유가 있었던 것이다. (아마 대문자가 애초에 막힌 걸로 기억한다.)

    
    

• 7월 2일(금) 컴포넌트의 역할 분리

  • 이 글을 보고 컴포넌트 설계 방식을 많이 참고했다고 한다.

  • 컨테이너는 어떻게 움직이는지 / 프리젠터를 어떻게 보여지는지를 담당한다.

  • 상태가 없는 프리젠터는 재활용이 가능하다.

  • FooterSaveButton을 컨테이너/프리젠터로 리팩토링하는 예시는 본문 참고

  • 게시판 페이지 예제도 본문에 있다.

  • 익숙해지면 처음부터 컨테이너/프리젠터로 나누겠지만 처음에는 하나의 컴포넌트로 "동작하는 버전"을 만들고 리팩토링한다.

  • 프리젠터는 주로 외부에서 UI 구성에 필요한 상태값만 받아서 JSX를 구성한다. 필요하다면 내부에 넣을 children을 외부에서 받아서 사용한다. 이를 통해 재사용성을 높인다.

  • 동작을 담당하는 컴포넌트(컨테이너)에서 render시 프리젠터 컴포넌트를 호출해서 사용하는 구조이다.

    
    

• 7월 3일(토) 깃(Git) 개념과 상황별 팁

  • 늘 사용하기 어려운 깃, 막상 좀 알겠다 싶으면 모르는 에러가 나오는 깃을 한 번 더 알아보자..

  • 스테이징. 변경사항 중에 저장하고 싶은 부분만 선택해서 임시 저장하는 개념

  • git status는 "현재 폴더의 변경 상태를 전부"보는 명령어다. 현재 트래킹 중인(add로 스테이징)한 파일도 볼 수 있다.

  • git commit은 스테이징 상태의 변경 내용을 저장한다.

  • git commit -am은 git add . git commit -m을 동시에 하는 것과 같다.

  • 커밋을 만들지 않고 이전 커밋에 변경사항을 추가하고 싶다면 git commit --amend를 사용하자. 깜박하고 하나 수정하거나 할 때 조을 듯

  • 상황별 팁

    • 필요한 라인만 커밋하고 싶을 때
      • git add -p
      • 변경한 라인만 스테이지에 넣는 옵션 -p
      • 변경된 파일을 하나씩 열어서 스테이징 할지 말지 결정한다.
    • 커밋의 변경내용을 자세히 보고 싶을 때
      • git show
    • 커밋하기는 좀 그렇고 변경사항을 임시 저장하고 싶을 때
      • git stash / git stash pop
    • 히스토리를 예쁘게 보고 싶을 때
      • git log --graph --abbrev-commit (해쉬값을 앞에 7자만 보여줌) --pretty=oneline (한줄만 보여줌) --all(모든 브랜치와 태그를 함께 보여줌)
    • 히스토리를 변경하고 싶을 때
      • git rebase -i
    • 브랜치간의 변경사항을 보고 싶을 때
      • git log main..develop
    • 원격 저장소와 연결하고 싶을 때
      • fetch / merge / pull --rebase
    • 원격 저장소를 여러개 관리하고 싶을 때
      • git remote add upstream
    • 원격 저장소 주소 변경하고 싶을 때
      • git remote set-url {변경할 저장소 주소}
    • 원격 저장소 이름 변경하고 싶을 때
      • git remote -m {기존 저장소 이름} {신규 저장소 이름}
    
    

• 7월 4일(일) 인터페이스만 사용하다가 클래스를 다시 보았다

  • TS를 프론트엔드 개발에 적용하면 함수 전달 인자의 타입을 강제할 수 있어서 안정성 있는 코드를 작성하는데 도움이 된다.

  • interface는 새로운 객체 생성, 폼으로 받은 유저 데이터 검증, XHR 호출시 페이로드에 유저타입 사용 등으로 활용할 수 있다.

  • 하지만 어느 순간부터 인터페이스를 맞췄음에도 불구하고 코드가 눈에 잘 들어오지 않기 시작했다고 한다.

    • 복잡도가 증가하면 코드 관리가 어려움.
    • 각 역핳자들 사이에서는 인터페이스로 약속하고 개발하면 된다 생각했지만 귀찮음.

  • 인터페이스로 객체를 만들 때에는 매번 초기값을 설정해야한다. 하지만 클래스는 생성자가 초기화 역할을 대신한다.

  • 클래스의 장점은 관심사가 비슷한 함수를 메소드로 모을 수 있다는 점이다.

    
    

• 7월 5일(월) 구글 코리아 면접후기

  • 결론적으로 구글 면접에서 탈락했지만, 용기와 행동력으로 구글 면접까지 간 경험은 값지고 대단한 것 같다. 영어도 잘하시나보다.. 부럽..

  • "원서 접수하는데 돈드는건 아니니까!"

  • 구글의 코테는 어떤 느낌일까 글에 나와있ㄴㄴ GOCC india는 처음 들어보고.. 비트연산.. 트리..

  • 구글 면접으로 유명한 창의력을 요구하는 질문이 나오지는 않았다고 한다. 단순히 문제를 빠르게 푸는게 아니라 면접관과 소통하면서 자신의 생각, 논리를 표현하는게 중요하다.

  • 가장 맛있는 타코집 질문 예시는 본문 참조

  • 우테캠에 합격하셔서 함께 활동하게 되었다!

    
    

• 7월 6일(화) HTTP 메소드의 멱등성? 그게 뭔데?

  • 멱등성이란 수학에서 사용하는 용어로, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 뜻한다.

  • POST를 제외한 GET, PUT, DELETE는 모두 멱등성이 보장되어야 한다

  • 멱등성은 요청의 효과를 보고 판단한다.

    • 같은 행위를 여러 번 반복하더라도, 동일한 효과를 가져야 한다.
    • 같은 행위에 대해 '다른 응답을 하더라도, 그 요청이 의도한 효과를 발휘할 때, 멱등성이 유지됨을 뜻한다'

  • 안전한 메소드

    • GET, HEAD와 같이 서버측의 상태 정보를 변경하지 않는 메소드이다.
    
    

• 7월 7일(수) 인터넷은 어떻게 동작하는가?

  • 모든 컴퓨터를 연결하고 어떤 일이 일어나도 연결 상태를 유지할 수 있는 방법을 찾는 방법

  • 무선(이터넷 케이블), 유선(WiFi, Bluetooth)로 연결되어야 한다.

  • 각 컴퓨터가 모두 연결되기보다, 라우터를 통해 좀 더 효율적으로 연결된다.

  • 하나의 라우터보다 라우터에서 라우터로.. 무한히 확장할 수 있다.

  • 아주 먼곳에 케이블을 연결하는건 너무 힘들지만, 이미 전화기 시설은 전세계가 연결되어 있기에 이를 이용하고자 하는데 모뎀이라는 장비가 필요하다. 모뎀은 네트워크 정보 <-> 전화 시설이 처리 가능한 정보로 상호 변경한다.

  • ISP가 네트워크 - 네트워크를 연결한다.

  • 네트워크에 연결된 모든 컴퓨터는 IP 주소가 존재한다.

  • IP 주소를 기억하기 어려워 도메인을 사용한다.

  • 인터넷은 '수십억 컴퓨터를 모두 연결하는 기술 인프라'이다.

  • 웹은 그 인프라 기반 위에 구축된 서비스이다.

  • 이메일, IRC 등도 또 다른 서비스이다.

    
    

• 7월 8일(목) 웹페이지, 웹사이트, 웹서버 그리고 검색엔진의 차이는 무엇일까요?

  • 웹 페이지 : 브라우저에서 보여지는 문서
    • 스타일, 스크립트, 미디어 자원을 포함한다.
    • 모든 웹 페이지는 유일한 주소를 통해 접근할 수 있다.
  • 웹 사이트 : 다양한 방식으로 그룹으로 묶이거나 연결된 웹 페이지의 모음.
    • 유일한 도메인 이름을 같이 사용하는 연결된 웹 페이지 모음
    • 하나의 웹 페이지만 가진 웹 사이트(SPW). 요즘은 웹 어플리케이션(SPA)라 한다.
  • 웹 서버 : 인터넷에 한 개 이상의 웹 사이트를 호스팅하는 컴퓨터
    • 호스팅은 모든 웹 페이지, 자원을 컴퓨터에서 이용할 수 있게 한다.
    • 웹 사이트와 웹 서버를 혼동하지 마라.
  • 검색 엔진 : 다른 웹 페이지를 찾게 도와주는 웹 사이트
    • 브라우저와 혼돈하지 마라. 브라우저는 웹 페이지를 검색하고 보여준다.
    • 검색 엔진은 다른 웹 사이트에서 웹 페이지를 찾도록 도와주는 웹 사이트이다.
      
      

• 7월 9일(금) 웹 서버란 무엇일까?

  • 이 아티클에서 웹 서버는 HTTP 서버로 국한한다.

  • 하드웨어 측면에서, 웹 서버 소프트웨어와 관련 파일(html, css, js...)을 저장하는 컴퓨터이다. 웹 서버는 인터넷으로 연결된 다른 기기들이 웹 서버의 데이터를 주고 받을 수 있게 한다.

  • 소프트웨어 측면에서, 웹 사용자가 어떻게 호스트 파일들에 접근하는지 관리한다.

  • HTTP 서버는 URL과 HTTP의 소프트웨어 일부이다.

  • 정적 웹 서버/스택 은 HTTP 서버가 있는 컴퓨터로 구성되어 있다. 서버가 요청된 파일을 요청 브라우저에 전송하기 때문에 '정적'이라 부른다

  • 동적 웹 서버는 정적 웹 서버 + 추가 소프트웨어(대부분 어플리케이션 서버, 데이터베이스)로 구성되어 있다. 요청된 파일을 브라우저에 전송하기 전에, 어플리케이션 서버가 업데이트 하기 때문에 '동적'이라 부른다

  • 웹 서버는 컴포넌트 파일(HTML, CSS, JS, 이미지, 비디오, 폰트 등..)을 저장하고, 제공해야 한다. 그러기 위해

    • 항상 실행 중, 항상 인터넷에 연결, 항상 같은 IP주소, 제 3자에 의해 유지

  • 웹 서버는 HTTP를 지원한다.

    • HTTP는 이전의 통신을 기억하지 않기 때문에 저장 기능을 대신 해줄 어플리케이션 서버가 필요하다
    • 오직 클라이언트만이 HTTP 요청을 만들어 서버에 보내고(request), 서버는 오직 클라이언트의 HTTP 요청에 응답할 수 있다.
    • 클라이언트는 HTTP로 파일을 요청할 때, 반드시 URL 파일을 제공해야 한다.
    • 서버는 모든 HTTP 요청에 최소한의 에러 메세지를 포함해서 응답해야 한다.

  • "정적"은 있는 그대로를 제공하는 것이다

  • "동적"은 서버가 컨텐츠를 처리하거나, 데이터베이스로부터 컨텐츠를 생성하는 것을 의미한다.

    
    

• 7월 10일(토) 애자일을 대충 알고 있는 당신을 위하여

  • 애자일은 프로젝트를 더 작은 반복 주기로 나누는 소프트웨어 개발 방식이다.

  • 폭포수 모델을 사용한 업부 프로세스의 한 예.. 본문을 참조하자.

  • 스프린트. 애자일은 전체 프로젝트를 마감 기한에 맞춰서 일정한 크기로 더 작게 나눈다. 이를 반복 주기 또는 스프린트라고 부른다.

  • 첫 번째 반복 주기를 "반복 주기 0"이라 하는데, 이 때 스토리를 만든다. 스토리는 프로젝트에 들어갈 기능 목록, 즉 개발자가 개발해야하는 기능이라 보면 된다.

  • 애자일은 폭포수 모델과 달리 요구 사항 분석, 아키텍쳐 수립, 설계, 구현 작업이 끊임없이 반복되어 일어난다.

  • 애자일은 빠르게 나아가는게 아니라 우리가 얼마나 망했는지를 최대한 빨리 아는 것이다.

  • 스프린트는 해당 기간 동안 전력 질주를 해야한다는 의미는 아니다. 평균 1~2주 기간 동안 개발팀이 충분히 해낼 수 있을 정도의 업무를 진행한다.

  • 프로젝트를 마친 뒤 왜 망했는지 반성하고, 다음엔 어떡하면 덜 망할지 분석. 성공했다면 왜? 다음엔 또 어떻게? 마찬가지다. 이를 회고라 하고 KPT는 수 많은 애자일 회고 방법론 중 하나이다.

    • Keep : 현재 만족하고, 계속 이어갔으면 하는 부분)
    • Problem : 불편하다고 느끼고, 개선이 필요하다고 생각하는 부분
    • Try : Problem의 해결책, 다음 회고 때 판별할 수 있고 바로 실천 가능한 부분

  • Try가 가장 중요하다.

    
    

• 7월 11일(일) [번역] 아토믹 웹 디자인 (Atomic Web Design)

  • 아토믹 디자인은 코드스쿼드 진행 중에 들어보기만 하고, 다른 팀이 사용해보았다는 얘기만 들었다. 직접 해본적도 없고, 제대로 알아 본적도 없었으니 이번기회에 슬쩍 알아보자

  • 아토믹 디자인은

    • 인터페이스는 하위 컴포넌트들로 이루어져있으며
    • 이 인터페이스를 기초적인 구성 요소로 해체하여 거기서부터 작업할 수 있다

  • 디자인 시스템을 만드는 방법론으로, 다섯 가지 수준이 존재한다. Atoms, Molecules, Organisms, Templates, Pages

  • Atoms

    • 가장 작은 기본 구성 요소로, label, input, button같은 HTML태그나
    • 색상 팔레트, 폰트 같은 추상요소, 애니메이션 같은 인터페이스의 양상일 수 있다.
    • 독립적으로 크게 유용하진 않지만, 글로벌한 스타일을 볼 수 있게 해주는 레퍼런스가 된다.

  • Molecules

    • atom의 조합으로 각자의 속성을 지니고 디자인 시스템의 뼈대를 이룬다
    • form + label + input + button을 사용해 하나의 입력 폼을 만드는 예시가 있다
    • "하나의 일을 하고, 그 일을 제대로 해라"

  • Organisms

    • molecules의 조합으로 웹 인터페이스의 분명한 구역을 담당한다.
    • header라는 organism는 logo, navigation, search from등의 molucules로 구성될 수 있다.

  • Templates

    • organism의 조합으로 클라이언트가 이해하기 쉽고 실제 결과물과 밀접한 언어가 사용된다.
    • 여기서 디자인이 완성되고, 레이아웃의 실체를 볼 수 있다.

  • Pages

    • template의 특정한 인스턴스이다. placeholder는 실제 콘텐츠로 대체되며, 최종적으로 유저가 보게 될 화면이 묘사된다.
    • 가장 구체적이고, 정확도가 높은 레벨이다
    • 디자인 시스템의 효율성을 테스트하는 곳이다.
    
    

• 7월 12일(월) AJAX의 모든 것

  • AJAX

    • JS를 이용해 XML 방식으로 서버와 비동기적으로 통신하는 기법
    • 페이지 전체 리소스를 다시 불러오는게 아닌 필요한 데이터만 요청해서 응답받은 후 클라이언트에서 데이터에 대한 처리를 할 수 있다
    • 이로 인해 웹 서버 사이에서 교환되는 데이터량 감소, 웹 서버의 데이터 처리량 감소가 가능하다. 따라서 응답 반응 경험이 개선된다.
    • GET 요청은 전달할 데이터 값을 URL에 쿼리스트링or파라미터 형태로 전달한다
    • POST 요청시 form에 있는 데이터 값을 전부 가져오는데 formData, serializeObject를 사용한다.
      • 비동기로 파일 업로드를 하는 경우에는 formData만 쓸 수 있다. serialize는 input 데이터를 쿼리스트링으로 변환하기 때문인데, binary data는 변환 되지 않기 때문
    • AJAX의 장단점은 본문 확인

  • XML

    • XML은 데이터를 저장하고 전달할 목적으로만 만들어진 언어이다
      • 데이터 이름, 실제 데이터, 데이터 단위를 구분해서 표현 가능
    • 요즘은 JSON 포맷을 더 많이 사용한다.

  • XMLHttpRequest(XHR)

    • 비동기 통신을 담당하는 자바스크립트 객체
    • 서버에 특정 데이터를 요청해서 받아옴
    • DOM 조작 가능

  • JSON

    • XML을 대체하는 새로운 데이터 양식
    • 클라이언트가 사용하는 언어와 관계 없이 통일된 데이터를 주고 받을 수 있는 문자열 형태
    • 문법 오류에 민감하고 주석을 지원하지 않음. 데이터타입을 강제할 수 없음.
    
    

• 7월 13일(화) 모던 웹 브라우저 - 크롬 브라우저 뜯어보기

  • 컴퓨터/스마트폰 어플리케이션이 시작하면 OS에 따라 CPU/GPU가 앱을 실행한다
  • 앱을 실행하면 프로세스 생성, 경우에 따라 스레드도 생성한다
  • OS는 프로세스에 메모미를 할당해서 앱의 모든 고유 상태 정보를 고유 메모리 공간에 저장할 수 있게 한다.
  • 앱이 종료되면 프로세스가 사라지고 OS가 메모리를 해제한다
  • 프로세스는 다른 프로세스가 별도 작업을 수행하도록 OS에 요청할 수 있다
  • 프로세스간 통신은 IPC(Inter Process Communication)을 이용한다.
  • IPC는 워커 프로세스가 무응답 상태에 빠져도 다른 프로세스를 종료할 필요 없이, 해당 프로세스만 재시작할 수 있다.
  • 크롬 브라우저 동작 방식
    • 브라우저 프로세스
      • 최상위 프로세스 / 다른 프로세스 조율
      • 어플리케이션 크롬 / 네트워크 요청 / 파일 액세스 등 브라우저 권한 제어
    • 렌더러 프로세스
      • 탭 안의 모든 것을 담당
      • 최근까지 각 탭마다 별도 프로세스를 할당했으나 현재는 사이트별로 프로세스를 가지도록 변경(사이트 격리)
    • 플러그인 프로세스
      • 웹 사이트가 사용하는 플러그인 담당(플래시 같은)
    • GPU 프로세스
      • 타 프로세스와 분리된 GPU 작업 제어.
      • 여러 앱의 요청 제어, 동일한 표면에 표시
  • 너무 받아쓰기만 되는거 같아서 이후로는 읽으면서 키워드만 남기기로!
  • 사이트 격리
  • 브라우저 렌더링 과정
    • 입력 처리 (UI 스레드) 검색인가 url인가 파싱
    • 네트워크 요청 초기화
    • 응답 읽기 (네트워크 스레드)
    • 렌더러 프로세스 찾기
    • 탐색 수행
    • 초기 로딩 완료
  • Service Worker
    • 코드에 네트워크 프록시를 작성할 수 있는 수단
  • 렌더러 프로세스 웹 컨텐츠 처리
    • 파싱
      • DOM 생성
      • 추가 리소스 로딩
    • 스타일
    • 레이아웃
    • 페인트
    • 합성(compositing)

<br/>

• 7월 14일(수) 왜 비동기적 프로그래밍을 해야하는가?

  • JS는 싱글 스레드 언어이기에 한 번에 한 가지 일만 할 수 있으며, 그 일이 무겁고 오래걸리면 뒤의 일을 실행할 수 없다. 이를 Blocking 되었다고 한다.

  • 현대 웹 페이지를 보다 유동적으로, 효율적으로 움직이기 위해 비동기 프로그래밍이 필요하다

  • 비동기 프로그래밍을 위한 JS의 방법들

    • callback
      • callback 지옥
    • Promise
      • 성공적으로 동작(reslove), 실패나 에러 (reject)로 구분된다. pending 상태로 대기한다.
    • then, catch
      • 콜백지옥 없이 연속적으로 비동기 동작을 하는 코드 작성 가능

  • Promise, then, catch 모두 Promise를 반환한다.

    • Promise와 then, catch가 쌓이면서 반환값이 중간에 꼬여버리면 가독성이 떨어지며 디버깅이 어려워진다.

  • async / await

    
    

• 7월 15일(목) 좋은 커밋을 작성하는 법

  • 커밋 메세지를 잘 작성한다면

    • 팀원들이 변경 내용을 쉽게 알 수 있다.
    • 코드의 의도를 알 수 있다.
      • git의 blame : 코드의 라인 별로 커밋 메세지를 보여주는 기능
    • 코드 리뷰가 쉽다.

  • 좋은 커밋을 작성하는 법

    • 간결하면서도 분명하게
      • 둘 중 하나를 고르라면 분명하게
      • 무엇을 바꾸고, 왜 필요한지
    • 같은 커밋의 변경 사항은 논리적으로 관련성 있게
    • 꼭 필요한 변경 사항만 커밋
      • git add .은 머리에서 잊어라
      • 대신 git add -p : 변경 사항 중 어느것을 stage할지 일일이 고를 수 있는 기능
      • 같은 파일의 변경 사항이어도 의도된 게 아니라면 커밋x
    • 이슈 트래커의 티켓 번호 기록
    • 테스트를 거친 코드만 커밋
      • git hook 기능을 통해 방지 가능 (테스트 코드 작성 필요)
    
    

• 7월 16일(금) [Javascript] 비동기 개념 학습

  • 썸네일에 홀려 들어왔다. 잌쿠..!
  • 게임에 비유해서 설명하는 방식이 아주 마음에 든다. 리신 궁플을 비동기로 설명하다니 세상에나... 이 사람은 천재일까?
  • 비동기 자체는 최근에도 많이 보았고, 어느정도 공부해서 내용 정리는 생략!
  • 본문보다는 오히려 댓글을 보다가 논블로킹과 비동기의 차이에 대한 설명이 자세히 나와있어서 읽어보았다.
    • 논블록/블록은 한줄로 구분하자면 "비동기 호출 결과를 받기 전까지 다른 동작을 할 수 있는가 / 없는가"
    • 롤캐릭으로 비교하면 스킬을 사용하면서 무빙도 할 수 있으면 논블로킹(신드라, 오리아나), 아니면 블로킹
    • 논블록킹은 콜백과도 연관 있다. 비동기 호출 성공 후 실행될 함수(callback)를 해당 API에게 넘긴다
    • 이벤트 핸들러 / 비동기 함수 / AJAX가 이에 해당하며, Web API가 이를 처리한다.
    • 즉, 넌블록은 비동기 호출 완료시점을 직접 감지하지 않아도 된다 해당 API에게 위임했으니! 콜백의 호출 주체가 해당 API가 되었다! 자바스크립트 이벤트 루프가 이러한 방식이다.
    • 
      

• 7월 17일(토) [Web] HTTP 개념 학습

  • 문서를 전송하기 위한 OSI 7단계인 Application Layer 프로토콜이다.
  • 클라이언트가 요청하고, 서버가 그 요청에 맞는 리소스를 응답하는 구조를 2-tier 아키텍처, 클라이언트-서버 아키텍처라고 한다.
  • 여기에 데이터베이스가 추가되면 3-tier 아키텍처라고 한다.
  • 서버가 클라이언트에게 리소스를 잘 활용할 수 있도록 가이드를 제공하는걸 인터페이스, API라고 한다.
  • URL Uniform Resource Locator
    • https 같은 통신 방식 Scheme,
    • velog.ig같은 웹 서버의 이름, 도메인, IP Hosts,
    • @jjunyjjuny같은 웹 서버 / 도메인에서 해당 리소스까지의 경로 URL-Path로 구분된다.
  • URI Uniform Resource Identifier
    • URL + query, bookmark 등을 포함한다.
  • DNS Domain Name System
    • 호스트의 도메인 이름을 IP주소로 변환하거나, IP 주소를 도메인 이름으로 변환하는 데이터베이스 시스템
      
      
      

• 7월 18일(일) [MySQL] MySQL 사용법

  • 최근 백엔드 개발도 해야하다보니 백엔드 지식의 부재를 체감하고 있다. 당장 필요한 지식을 습득해보자 ..

  • 음 딱히 옮겨적을 건 없고 북마크해두고 두고두고 보자. 여러 경우에 맞는 쿼리문이 적혀있어서 도움이 되는거 같다. 각각의 키워드에 대해서는 좀 더 검색해봐야 겠지만?

    
    

• 7월 19일 (월) Package.json과 Package-lock.json의 차이를 아시나요?

  • node 환경에서 협업하다보면 모듈 버전 차이로 문제가 발생할 수 있다.

  • 팀원끼리 사용하는 모듈 버전이 다르다면

    • node modules 삭제
    • npm cache 삭제
    • npm install 명령어로 다시 dependencies 설치

  • 이럴 수 있지만 효율이 떨어진다.

  • package-lock.json은 node_modules 또는 package.json이 수정될 때 자동으로 생성된다.

  • package-lock.json이 존재하면 npm install시 우선적으로 package-lock.json을 사용해서 node_modules를 생성한다.

  • package.json에 정확한 버전명을 명시하지 않은 이유는 해당 패키지의 중요한 버그 수정이 이루어질 때마다 package.json의 버전도 바꿔줘야 하기 때문이다. package.json의 version range는 이런 경우를 방지하기 위해 사용해야한다.

    
    

• 7월 20일 (화) Get과 Post의 차이를 아시나요?

  • TL;DR 이라는 걸 이전에도 봤다가 까먹었는데 too long did` read. 너무 길어서 안 읽었음/읽지마 대충 요런 뜻인가보다

  • GET/POST의 가장 큰 차이는 서버의 상태를 바꾸는가. 즉, 멱등성 유무라고 할 수 있다.

  • 멱등성이란 연산을 몇 번 하든 결과가 달라지지 않는 성질이다. 순수함수같은 개념

  • GET은 읽기/검색 등 정보 요청을 서버로부터 요청하기

    • 불필요 요청을 제한하기 위해 캐시될 수 있음
    • 파라미터에 내용이 다 노출되기에 중요 데이터를 다룰 때 사용하면 안 됨
    • GET 요청은 브라우저에 기록이 남음
    • GET 요청을 북마크에 추가할 수 있음!?
    • 데이터 길이에 제한이 있음
    • GET 요청은 idempotent하다

  • POST는 리소스 생성/업데이트를 위해 서버에 데이터 보내기

    • 캐시, 브라우저 기록, 북마크 추가 x
    • 데이터 길이 제한 없음. 대용량 데이터 o
    • http body 사용 Content-Type으로 바디의 타입 지정
    • GET보다 안전한거 같지만 개발자 도구로 다 볼 수 있음 (암호화 필요)
    • POST 요청은 idempotent하지 않음
    
    

• 7월 21일 (수) "Modal"에 관한 간단한 고찰

  • 스크린은 두 종류만 존재한다. Modal, Non-Modal

  • 대부분의 Modal 스크린은 쉽게 식별 가능. Main Window를 덮기 때문에

  • 모바일은 스크린 크기가 제한적이라 모달이 모든 화면을 잡아먹어서, Non-Modal과 차이가 없어짐

  • 가장 큰 차이점은 유저 - 스크린이어떻게 상호작용하느냐

  • Non-Modal의 가장 뚜렷한 시각적 구별은 네비게이션의 표시여부 앞뒤 이동

  • Modal은 취소, 닫기, 확인 등

  • 모달은 사용자의 각각의 단일 작업에 집중하게 한다.

  • 모달은 닫기가 중요하다.

    
    

• 7월 22일 (목) 스크롤은 부드럽게, 글자에는 이미지를 넣어보자!

  • scroll-behavior을 사용한 부드러운 스크롤

  • background-clip 글자에 이미지 넣기

  • 신박한 애니메이션이다. a태그로 특정 돔 id로 이동하되, scroll-hebavior : smooth를 사용해서 한 번에 뚝 이동하는게 아니라 transition을 적용한 것과 같은 동작을 하게 만들었다!

  • transparent 부모값을 상속하는 그런 느낌의 이름 같지만. 투명한 이라는 뜻의 단어일 뿐..

  • 글자 투명, 배경에 이미지 적용, 텍스트에 이미지 적용 background-clip : text

    
    

• 7월 23일 (금) RESTful API를 알아봅시다

  • API는 Application Programming Intergace. 소프트웨어 프로그램 내부에 존재하는 기능 및 규칙의 집합

  • 커뮤니케이션 계약이라 볼 수 있음.

  • 웹 개발에서 개발자가 어플리케이션을 통해 웹 브라우저(어플리케이션)와 상호작용 하기 위한 코드(web API, DOM API 같은 것들), 사용자 컴퓨터내 소프트웨어/하드웨어/서드파티 웹사이트 등의 집합을 뜻함

  • API는

    • 서버 - 데이터베이스에 대한 출입구 역할을 함
    • 어플리케이션과 기기의 원활한 통신을 하게 함
    • 모든 접속을 표준화한다.

  • REST는

    • 소프트웨어 개발 아키텍처의 한 형식이다.
    • 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용한다
    • URL을 통해 자원(Resource) 명시
    • HTTP Mehhod를 통해 자원에 대한 CRUD Operation 적용
    • 즉, 중심에 Resource(자원)가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐

  • REST의 특징

    • Uniform.
      • 모든 플랫폼에서 사용 가능.
      • 특정 언어, 기술에 종속되지 않는다.
    • Stateless.
      • 무상태성.
      • HTTP가 무상태이기에 REST도 마찬가지.
      • API는 그저 각 요청에 대해 정해진 로직대로 처리하기에 이전 요청과 다음 요청 처리가 연관되어서는 안 된다.
    • Cacheable.
      • HTTP라는 웹표준을 그대로 사용하기에 **웹에서 사용하는 기존 인프라를 그대로 활용 가능하다.
      • 따라서 HTTP의 Last-Modified, E-Tag를 사용한 캐싱이 가능하다.
      • 캐싱으로 응답시간이 빨라져서 REST Server 트랜잭션이 일어나지 않음
      • 결과적으로 전체 응답시간, 성능, 서버 자원 이용률 향상
    • Self-descriptiveness
      • 자체 표현 구조
      • REST는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있도록 자체 표현 구조로 되어 있다.
    • Client - Server 구조
      • Rest 서버는 API 제공, 비즈니스 로직 처리, 저장
      • Client는 사용자 인증/컨텍스트등을 직접 관리하는 구조로 역할이 확실히 구분됨
    • 계층형 구조
      • 보안, 로드 밸런싱, 암호화 계층, PROXY, 게이트웨이 등
    • Code-On-Demand

  • 장단점. 너무 받아쓰기 같다. 본문을 다시 보자...

    • 간단히 장점은 HTTP 덕분에 별도 인프라 구축 필요 없음 / 범용성 / 의도가 명확
    • 단점은 표준 없음 / 메소드 4개 뿐 / 구형 브라우저 지원 부족 / history.pushState() 불가
    
    

• 7월 24일 (토) deploy 브랜치 전략 활용 방법

  • 당근마켓의 브랜치 전략

  • 이전에는 작업 후 테스트한 코드를 develop 브랜치에 merge, 서비스 배포시 develop 브랜치를 master 브랜치에 merge 하는 방식을 사용함.

  • 규모가 커지고 다양한 기능 개발을 동시에 진행하다보니 브랜치 전략이 필요해짐

  • master / develop / feature / release / hotfix 5개 브랜치로 나눔

  • master : stable한 코드여야한다. 바로 배포가 가능하게!

  • develop : release와 featuredml base가 되는 브랜치. deplay-ready 상태. develop에 들어오는 코드는 테스트가 완료되고 언제든 배포해도 되는 코드

  • feature : 작업 브랜치. develop을 기준으로

  • release : 배포가 나갈 때 생성하는 브랜치. develop으로부터 생성. 배포/모니터링이 끝나면 develop, master로 merge한다

  • hotfix : master에 release가 merge된 후 문제가 발생했을 경우 master를 기준으로 생성해서 문제를 해결하고 develop, matser로 merge한다

  • 당근은 release, hotfix는 사용 안 했다.

  • 각 feature마다 서버가 있다면 문제 없지만 보통은 다른 사람의 테스트를 기다려야하는 문제 발생

  • deploy 브랜치 전략. gitflow와 비슷하지만 테스트 서버 배포를 위한 전용 브랜치를 이용한다 (deplay/{month})

  • 결국은 dev같은 feature 통합 브랜치를 하나 더 파서 거기서 테스트한다는거 같은데..

    
    

• 7월 25일 (일) 하루에 1000번 배포하는 조직 되기

  • 뱅크 셀러드의 배포 시스템

  • Background

    • 버전 관리는 GibHub로
    • MSA(Microservice Architecture)로 비즈니스 도메인별 여러 서비스 운영
    • Docker로 모든 서비스 containerze
    • 모든 Docker image는 Docker Hub로 관리
    • Kubernetes 환경에서 운영
    • Slack

  • 이전 (Old Process)

    • Git-Flow
      • dev를 기준으로 feature 만들어서 작업하고 완료후 dev로 merge
      • dev에서 release 만들어서 배포에 필요한 문서 작성 / 버그 수정 등을 함
      • release 준비가 끝나면 main(master), develop에 merge
      • 모든 merge는 PR을 통해 코드리뷰 받음
      • PR에 대한 Lint, Test등의 Continuous Integration은 travis CI 사용
    • 그 외에 tag Based Deployment, ChatOps 사용
    • Git-flow는 5번의 branch switch, 6번의 PR, 코드리뷰를 요구한다. 배포 귀찮아짐

  • 뱅크셀러드 새로운 배포 시스템

    • master 외에 모든 브랜치 삭제
    • master를 base로 새로운 branch(작업 내용을 명확하게 설명하는) 생성
    • master에 PR해서 Lint, unit test 통과, 서비스 오너 한 명 이상의 approve를 받으면 merge 가능
    • merge는 squash and merge 사용
    • master에 merge한다고 다 배포하는게 아님.
    • travis CI 대신 GitHub Actions 사용
      • Build. lint 검사, test 테스트, build docker image 빌드. 이 세과정을 통과하지 못 한 commit은 merge될 수 없음
      • Deploy. 위 Build가 성공해야지만 실행.

  • 개발 조직에서 배포 횟수는 비즈니스 요구를 충족시키는 역량과 비례한다.

  • 배포는 자신감있고 자연스럽게 이루어져야한다.

    
    

• 7월 26일 (월) 개발자도 알면 좋은 UI 디자인

  • 초기 디자인이란 페이지에 들어갈 기능을 모두 정의하는 것을 의미한다.

  • 초기 디자인은 목업과 와이어 프레임으로. 아이콘 같은 구체적인 것까지 할 필요 없다

  • 빠르게 만들고 빠르게 문제를 마주하자

  • 폰트, 컬러, border-radius 등으로 디자인 컨셉을 잡는다

  • 디자인 시스템으로 선택지를 어느정도 제한한다.

  • 디자인 시스템으로 미리 지정해둘만한 요소

    • 폰트 크기, 두께 / 라인 높이 / 색상 / 마진 / 패딩 / 너비 / 높이 / 박스 쉐도우 / 테두리 반경 / 테두리 두께 / 투명도
    
    

• 7월 27일 (화) git rebase를 이해하기

  • 언제나 할 때마다 좀 햇갈리는 rebase... 복습해보자..

  • git remote -v로 원격 저장소 확인

  • git remote add upstream ${주소}

  • git fetch upstream ${target branch}

  • git rebase upstream/${target branch}

  • git push origin master

  • 이 순서가 맞지만 사실... 충돌이 안 날 수가 없지..

  • -i 옵션을 넣으면 interactive 모드로 rebase의 동작을 잘게 쪼개서 실행한다고 보면 된다. 되돌아갈 시점을 선택할 수 있다.

  • git rebase -i --root 후 돌아갈 시점의 pick을 edit으로 변경

  • git commit --amend -m "커밋 메세지 변경"

  • git rebase --continue 돌렸던 시간 원상 복구

  • 이러고 push를 하면 에러가 발생하곤 하는데, 이는 base가 변경되었을 때 발생한다.

    
    

• 7월 28일 (수) HTTPS에 대해 알아야 할 것들

  • ssl 인증서 구매해서 서버에 설치하는 것 뿐 아니라 작동 방식을 알고 적절히 사용하자는 취지

  • HTTPS로 가야하는 이유

    • 인증. 인증서를 통해 해당 url로 접속한 곳이 진짜임을 증명해준다
    • 무결성. 웹사이트-사용자 통신 사이에 침입자가 끼어드는걸 막는다
    • 기밀성. 웹사이트-사용자 통신을 칩임자가 감시 감청할 수 없게 한다
    • 신기술. 새로운 프로토콜, 최신 API 등에서 실행 허가가 필요한데 HTTPS가 실행 허가에 중요한 요소이다.
    • 기타. 색인, SEO

  • HTTP

    • HTTP는 TCP 핸드셰이크 후 HTTP요청/응답으로 서로 데이터 주고받음
    • 통신은 평문으로, 중간자 HTTP 데이터를 보거나 변조 가능

  • HTTPS

    • HTTP over TLS.
    • TCP 핸드셰이크 후 TLS 핸드셰이크 진행 후 암호화 통신으로 데이터 주고 받음

  • TLS 핸드셰이크 프로토콜

    • 매개변수 교환 / 동의
    • 서버인증
    • 키 교환
    • 암호화 통신 시작 알림 / 변조여부 체크

  • TLS 핸드 셰이크 resumption

    • 끊어진 session을 재연결
    • 일단 연결이 완료된 TLS Session 정보 ID에 대해 캐시 연결시 캐시된 정보를 이용해 세션을 다시 연결하는게 아니라 연결을 복구함

  • SSL 취약점 역사? 본문 확인

    
    

• 7월 29일 (목) HTTP/3는 왜 UDP를 선택한 것일까?

  • 1, 2와 다르게 TCP가 아닌 UDP 기반 프로토콜 QUIC를 사용한다.

  • HTTP와 같은 프로토콜은 규약이기 때문에 언어, 프레임워크와 달리 소프트웨어 제조사 간 합을 맞추는 기간이 필요하다. 그런데 2가 나온지 4년만에 3가 나오다니?

  • TCP / UDP

    • 신뢰성. 높음 / 낮음 (송신 데이터가 모두 수신측에 온전히 도달하는가)
    • 속도. 느림 / 빠름
    • 전송 순서. 보장 / 보장하지 않음
    • 패킷 교환. 가상 회선 방식 / 데이터그램 방식
    • 연결형 / 비연결형

  • TCP는 3 Way Handshake라서 느리다 (자세한 내용 본문)

    • HTTP1은 매 요청마다 핸드 쉐이크를 거쳤지만 2에서는 단일 TCP 연결을 유지하면서 여러 요청을 처리한다

  • HTTP3부터는 UDP를 사용하며 이 핸드쉐이크 과정을 날리고 다른 방법으로 신뢰성을 확보한다

  • HOLB(Hand Of Line Blocking)

    • 패킷이 중간에 유실 또는 수신측 패킷 파싱 속도가 느려서 통신에 병목현상이 생기는 것
    • TCP의 전형적인 문제

  • UDP (User Datagram Protocol)

    • 패킷간 순서가 존재하지 않는 독립적 패킷 사용
    • 핸드쉐이크 과정 필요 없음
    • 커스터마이징에 용이함
    • UDP는 데이터 전송 외에 어떤 기능도 정의되어 있지 않아서 자체 신뢰성이 낮고, 빠르다.

  • HTTP/3가 UDP를 사용해서 나아진 점

    • 연결 설정시 레이턴시 감소
    • 패킷 손실 감지에 걸리는 시간 감축
    • 멀티플렉싱 지원
    • 클라이언트 IP가 바뀌어도 연결이 유지됨
    
    

• 7월 30일 (금) 만화로 보는 DNS over HTTPS

  • DoH(DNS over HTTPS). DNS의 데이터 노출 문제를 종식시키기 위해 새롭게 제안하고 있는 기능

  • HTTP 요청이 클라이언트 - 서버로 지나갈 때 여러 경로를 지나는데 요청 전에 그 경로를 알 수 없고, 경로 중간에 꺼내보거나 응답 내용을 바꿀 수도 있다.

  • 이 문제를 해결하기위해 HTTPS가 등장. 모든 메세지에 자물쇠를 건다.

  • 자물쇠를 여는 비밀번호는 브라우저와 서버만 알고 있다.

  • 데이터 노출은 서버와 커넥션을 맺는 단계에서 일어난다.

  • 도메인 네임 입력시, resolver(리졸버)는 IP주소를 찾아 준다.

  • Root DNS에 톱레벨 도메인 묻기 / 톱레벨 도메인 네임 서버 / 해당 주소의 네임 서버 (authoritative server) /

  • 이렇게 찾은 IP를 운영체제(OS)에 전달

  • OS는 기본적으로 네트워크가 알려주는 리졸버를 사용한다

  • DNS 요청시 방문하는 각 서버는 우리가 어떤 사이트를 찾는지 알 수 있고 그 경로에 있는 서버도 알 수 있다. 이 정보로 우리가 누군지 알 수 있다.

  • 트래킹(tracking)과 스푸핑(spoofing)

  • 트래킹 : DNS서버와 경로 서버(라우터)가 내 정보와 내가 요청한 사이트에 대한 정보를 수집함

  • 스푸핑 : 우리와 DNS 사이의 누군가가 DNS의 응답을 변경하는 것. 웹사이트 방문을 막거나 스캠 웹사이트를 보여줄 수 있다.

  • 문제 정리

    • 신뢰할 수 없는 리졸버를 사용하는 경우 우리의 요청을 추적하거나, DNS 서버 응답을 변조한다
    • 라우터 또한 그럴 수 있다.
    • DNS 서버가 우리의 요청을 추적할 수 있다

  • TRR(Trusted Recursive Resolver)를 사용한다.

    • Cloudflare는 24시간마다 사용자 식별 데이터를 폐기, 제 3자에 제공. 규정대로 폐기되었음을 증명하는 감사 자료 제공
    • 신뢰할 수 있는 리졸버 확보

  • DoH를 사용함으로써 경로 상에서의 도청을 방지한다.

    • DNS 패킷 전달 과정에서 HTTPS를 사용해서 도청을 막음

  • 최소한의 데이터만 전송해서 사용자를 식별하지 못하게 한다.

    • 상대하는 DNS 서버에 따라 꼭 필요한 일부 정보만 전달. QNAME minimization

  • TRR, DoH를 쓴다 해도 데이터 유출 위험은 있다.

    • 초기 요청에는 SNI(Serve Name Indication)가 있으며 어떤 사이트에 접속하고자 하는지 담겨있다. 암호화 되어있지 않음
    • 초기 연결 후 해당 서버가 제공하는 다른 사이트에도 연결을 유지할 수 있다. HTTP/2 커넥션 합치기.
    
    

• 7월 31일 (토) 로우 레벨로 살펴보는 Node.js 이벤트 루프

  • Nodejs에서 이벤트 루프에 대한 잘못 알려진 개념들
    • 이벤트 루프는 자바스크립트 엔진 내부에 있다. (x)
      • 이벤트 루프는 nodejs, 브라우저. 즉 런타임 환경에 있다.
    • 이벤트 루프는 하나의 스택/큐로만 동작한다. (x)
      • 이벤트 루프에 작업을 담아놓는 스택 같은 것은 존재하지 않음
      • 여러 개의 큐를 사용함
    • 이벤트 루프는 여러 개의 스레드에서 실행된다. (x)
      • 단일 스레드로 모든 것을 처리한다
      • 자바스크립트 실행 / 이벤트 루프 담당하는 두 개의 스레드가 있다고 착각하지 말자
    • setTimeout은 일부 비동기 OS API와 관련있다 (x)
      • setTimeout 딜레이가 끝나도 OS, 커널 등이 콜백을 작업 큐로 넘기는게 아니다
    • setImmediate 콜백은 작업 큐 가장 첫번째에 위치한다. (x)
      • 큐는 무조건 선입선출이다.
      • 작업 큐가 여러개일 뿐!
  • 이벤트 루프 흐름
    • Timer phase : 이벤트 루프 시작. 타이머의 콜백을 해당 큐에 저장
    • Pending I/O callbak phase. pending_queue에 들어있는 콜백 실행
    • Idle, Prepare phase. 매 tick마다 / 매 polling마다 실행
    • Poll Phase. 가장 중요! 새로운 수신 커넥션, 데이터 허용
    • Check Phase. setImmediate 콜백만을 위한 페이즈
    • Close callbacks. close 이벤트 타입 핸들러 처리
    • 다시 Timer phase
  • Thread-pool
    • Node.js가 아닌 libUV(비동기 작업 처리 라이브러리)의 기능
  • setImmedate는 Timer phase에서 타이머 실행 시간이 되었는지, 콜백을 실행해야하는지 검사하는 몇 가지 작업이 없다. 따라서 setTimeout(()=>{},0) 보다 훨씬 빠르다.
    
    
    

• 8월 1일 (일) [JWT] 토큰(Token) 기반 인증에 대한 소개

  • 토큰 기반 인증 시스템을 선택하는 이유

    • Stateless 서버
      • Stateful 서버는 클라이언트 요청을 받을 때 마다 클라이언트의 상태를 유지, 이 정보를 서비스 제공에 이용한다
      • 대표적으로 세션을 유지하는 웹서버
      • Stateless 서버는 상태 유지를 하지 않아서 클라이언트 요청으로만 작업을 처리한다. 클라이언트-서버 연결 고리가 없기에 확장성 높아짐
    • 모바일 어플리케이션에 적합
      • 쿠기보다 더 안전한 API 만들기 가능
    • 인증정보 다른 어플리케이션에 전달
      • OAuth가 대표적 예시
    • 보안

  • 서버 기반 인증

    • 서버측에서 유저 정보 기억해야 함(세션)
    • 서버 확장이 어려워짐
    • 유저가 늘어나면 세션 처리를 위해 서버에 부담이 커짐
    • DB에 저장해도 마찬가지
    • 확장하기(프로세스/서버 컴퓨터 늘리기) 어려움
    • CORS

  • 토큰 기반 인증

    • 서버가 상태를 유지하지 않기에 위의 문제점들이 없음.

  • 토큰 기반 시스템 구현 방식(일반적으로)

    • 유저가 로그인(아이디/비밀번호)
    • 서버에서 계정 정보 검증
    • 계정 정보가 정확하다면 유저에게 signed 토큰을 발급
      • signed란 해당 토큰이 서버에서 정상적으로 발급된 토큰임을 증명하는 signature를 지니고 있다는 뜻
    • 클라이언트는 전달받은 토큰을 저장하고, 요청시 토큰을 함께 서버에 전달
    • 서버는 토큰을 검증하고, 요청에 응답

  • 확장성! 세션은 그 세션을 가지고 있는 서버에만 요청해야하지만 토큰은 디코딩 방식만 가지고 있으면 어느 서버든 상관없다.

  • 쿠키보다 더 보안성 좋음

  • 서버 확장 뿐 아니라 로그인 정보가 사용되는 분야 또한 확장 가증하다.

  • 디바이스/도메인 상관 없이 토큰만 유효하면 되니까 cors를 모두 허용해도 된다.

  • jwt는 웹표준이다.

    
    

• 8월 2일 (월) 백엔드가 이정도는 해줘야 함 - 1. 컨텐츠의 동기와 개요

  • 이 시리즈를 작성하기 전 필자가 과거에 어떤 식으로 개발했는지, 그렇기에 어떻게 작성해나갈 건지 안내(?)하는 글

  • 물리 서버를 한 대만 둔 것에 대한 문제, 테스트 코드 없는 서버 운영의 문제, 협업 과정의 문제, log가 없다면 서버 에러를 인지할 수 없다, 쿼리문 등..

  • 백엔드를 조금이라도 해봤다면 아래와 같은 내용 정도는 쉽게 진행하겠지만..

    • 사용자를 어떻게 인증할지
    • 암호화는 어떻게
    • API 문서 작성 요령

  • 그렇지 않다면 뭐가 필요한지조차 깨달을 경로가 적다

    • 백엔드는 언어/프레임워크 선택지가 너무 다양하다
    • production level 코드를 뜯어볼만한 기회가 없다. github에 올릴 일 없는 분야도 많다..
    • 백엔드는 코드 뿐 아니라 배포, 배포패턴, 모니터링, 로깅, 스토리지, 트래픽 변동 등 코드 외적인 부분도 신경써야한다
    • 엄청난 트래픽이라던가 경험할 일이 적어서 캐싱의 필요성 같은걸 깨닫기 힘들다.
    
    

• 8월 3일 (화) 프론트엔드 개발자와 UX

  • UX란 사용자가 원하는 것을 미리 파악하고 대응하여 사용자가 원하는 서비스를 만드는 일

  • UX는 디자이너에 종속된 개념이 아니라 서비스를 만드는 모든 직군에게 통용되는 개념이다

  • 프론트엔드 개발자의 UX

    • input 태그 입력 vaildation해서 에러 안내문 보여주기
    • 스켈레톤 로딩
    • 무한 스크롤 등

  • 사용자는 급하고, 사이트는 빨라야한다

    • 최적화!
    
    

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

  • 예상 가능한 에러

    • 서버 API로부터 전달받은 에러 중 status 코드가 명확한 경우 미리 대응할 수 있다.

  • 예상 불가능한 에러

    • 500대 에러는 예측할 수 없다. 서버에서 어떤 이유에서든 응답할 수 없는 에러가 발생한 것인데, 클라이언트는 그 원인을 알 수 없다
    • 네트워크 환경에 따라 발생할 수 있는 에러
    • 사용자의 브라우저에 따라 발생할 수 있는 에러

  • 사용자가 에러 상황을 이해하고 해결 가능한 에러

    • 인증/권한 에러.
    • 로그인을 해야 접근 가능한 페이지의 경우 로그인 페이지로 유도한다
    • 특정 권한이 필요한 페이지에 접근시 관리자에게 권한을 요구하는 페이지로 유도한다

  • 사용자가 에러 상황을 알아도 해결 불가능한 에러

    • 저사양 기기, 브라우저 관련 에러는 사용자가 해결할 수 없다. 다른 기기, 브라우저를 사용하라는 메세지,,, 정도..?

  • 예상 x / 해결 o

    • 네트워크 에러.
    • 네트워크 환경에 따라 언제든 발생할 수 있고 / 일시적 에러임을 알려서 액션을 다시 시도하게끔 유도
    • 실패 영역에 대해서만 회복 가능하도록 처리가 필요함

  • 예상 x / 해결 x

    • 고객센터로 문의하게 유도
    • 개발자 제어권 밖 에러. 모니터링 필요(Sentry)

  • 예상 o / 해결 x

    • 놓친 에러가 있다는 뜻
    • 보안상 허점. 악의적인 공격인 경우(해결할 의지가 없는 사용자)
    • CORS, XSS

  • 예상 o / 해결 o

    • 대부분 비즈니스 로직의 일부로 개발자가 이미 알고 있는 에러
    • 401 404 등 코드로 나타낼 수 있음
    • 사용자에게 명확한 가이드를 줘야한다.

  • 에러는 최대한 작은 범위에서 catch해야한다. (에러 전파 방지)

  • 10개 중 하나만 에러가 났는데 전체가 에러 화면을 보이면 사용자 경험을 해친다

    
    

• 8월 5일 (목) 데이터 검증 (Data Validation)은 언제, 얼마나 해야 할까?

  • 의견 1

    • 클라이언트 : 간단한 검증. ex) 글자수
    • 서버 라우터/컨트롤러 : 별다른 검증은 없지만 데이터를 변형, 구조화, 파싱한다
    • 비즈니스 레이어(서비스) : 견고한 검증. 데이터 포맷, 범위, 값, 내부상태, 사용자 역할 및 권한 등 / 검증시 사용자의 입력 값보단 데이터베이스의 값을 사용한다.
    • 데이터 접근(DAL, DAO) : 데이터 접근이 중요하지 검증은 별로..
    • 데이터베이스 단계: 데이터 자체 일관성을 위해 강력한 검증 필요.

  • 의견 2

    • validation 관련 된 것들을 따로 모아서 언제 어디서든 필요할 떄 호출해서 사용할 수 있는 단계가 필요하다.

  • 의견 3

    • presentation/UI
      • 검증 간단히
      • 입력 포맷이 잘못되면 진행하지 않음
    • logic
      • 비즈니스 로직, 인증
      • 사용자가 허용되지 않는 행동을 하지 못하도록
      • 파생된 속성, 상태를 이 단계에서 다룬다
    • Data
      • 핵심 데이터 레이어
      • 필요 없는 값을 저장하는건 무조건 거부
      • DB 자체적으로 포맷 강제

  • 데이터는 어디서든 검증될 수 있다.

  • 목적과 대상 사용자에 따라서 구분하여 검증하자

  • 브라우저 단계

    • 사용자의 경험을 더 낫게 하는데 의의를 두고 검증한다
    • 서버 입장에서는 요청으로부터 받은 데이터를 전혀 신뢰할 수 없기 때문에 자체 검증이 반드시 필요하다. (패킷은 언제든 조작될 수 있다)
    • 즉 브라우저의 검증은 실제 유효할지에 대한 의의는 그렇게 중요하지 않다.

  • API 인터페이스, 컨트롤러, 라우팅 단계

    • 비즈니스 로직 호출 전 단계
    • 자체 검증 뿐 아니라 사용자의 역할, 권한도 검증해야 함
    • 악성 사용자 고려

  • 비즈니스 로직 단계

    • 이 단계는 검증 단계를 따지지 않고 모든 것을 대상으로 한다

  • Database

    • 검증 대상은 주로 개발자가 입력한 값이다.
    • 따라서 Type 시스템이 유용하다
    • 검증 목적은 데이터베이스의 신뢰성 및 일관성 유지
    
    

• 8월 6일 (금) 세션 기반 인증 방식과 토큰 기반 인증(JWT)

  • 세션 기반 인증은 토큰 기반 인증이 없던 방식이다. (서버 세션 사용)

    • 클라이언트 로그인 / 성공시 서버가 유저 세션 생성 및 저장 / 클라언트에 세션 ID 제공 / 쿠키에 저장
    • 중앙 세션 관리 시스템 필요
    • 없으면 시스템 확장에 어려우 생긴다. 다만 장애가 생기면 시스템 전체 문제
    • 메모리 낭비

  • JWT : 필요한 정보를 토큰 body에 저장해서 클라이언트가 가지고 있다가 증명서처럼 사용

    • header.payload.signature 로 구성
      • header : JWT 토큰의 유형, 사용된 해시 알고리즘 정보가 base64URL로 인코딩 되어 있음.
      • payload : 클라이언트에 대한 정보, meta Data 등이 base64URL로 인코딩 되어 있음.
      • JWT는 해독 가능함으로 중요한 데이터를 넣어선 안 된다
      • signature : header에 지정한 알고리즘, secret 키, 서명으로 payload, header를 담음
    • secret 키가 노출되면 JWT 정보가 노출/수정 될 수 있는 보안 위험 존재
    • 짧은 수명이 안전하지만 유저에게 재로그인을 계속 요구해야함

  • access 토큰 만료시 refresh 토큰을 사용해서 재발급 받는다

  • JWT를 스토리지 / 쿠키 어디에 저장할까

  • 스토리지는 XSS에 약하고 CSRF에 강하다

  • 쿠키는 반대로 CSRF에 약하고 XSS에 강하다

  • CSURF로 예방이 가능하고, secure, httpOnly 옵션등으로 추가적인 보안이 가능하므로 쿠키를 사용하는게 권장된다

    
    

• 8월 7일 (토) 한글은 노토산스, 영문/숫자는 다른 폰트로 해주세요...👀 (feat. unicode)

  • 어떤 원리로 font가 분리되어서 적용되는지에 대한 아티클

  • CSS문(CSS statement)은 At-rules / 중첩문 Nested statements(그 안에 Rulesets)로 구성된다

  • Rulesets은 우리가 흔히 사용하는 선택자에 의해 기술된 조건을 연결짓는 규칙집합이다

  • At-Rule은 @로 시작해서 statement의 마지막에(블록 다음) ;가 오거나 다음 블록의 끝까지 계속 실별자가 뒤따른다

    • 메타 데이터 정보 (@charset, @import)
    • 조건부 정보 (@media, @document)
    • 설명 정보 (@font-face)

  • 중첩 문은 조건부 그룹 규칙의 특정 부분집합에서 사용될 수 있는 문이다

    • at-Rule의 @media는 브라우저가 돌아가는 장치가 표현된 조건과 일치하는 경우에만 동작
    • @document는 현재 페이지가 일부 조건과 일치하는 경우에만 적용 (아직 실험 단계)

  • @font-face : 사용자 정의 글꼴 지정

    • 사용자 컴퓨터에서 글꼴을 찾거나 / url()로 글꼴 리소스를 다운로드해서 사용
    • url()과 local()을 함께 사용하는게 일반적 local() 우선, 없으면 url()

  • 본제로 돌아와서 css에 정의된 글꼴정보가 글자에 적용될 시점에, 특정 문자는 필터하면서 적용되길 바란다면

    • 글자에 글꼴을 정의하는건 @font-face 블록 내부에서 선언
    • 특정 문자 필터링을 위해 범위 지정이 필요, @font-face의 속성 중 unicode-range 사용
    • unicode-range로 숫자, 영문, 특수문자의 범위를 알아내서 해당 범위에 다른 폰트를 지정한다

  • 유니코드 : 전 세계 모든 문자를 컴퓨터에서 일관되게 표현, 다루도록 설계된 산업 표준

  • 실제 @font-face에서 적용하는 방법은 본문 참고

  • 다르게 적용할 문자마다 css를 적용하는게 아닌 동일한 font-family 이름으로 하되 url을 달리할 폰트로 바꾸고 unicode-range를 적용하는 또 하나의 @font-face를 만들면 된다.

    
    

• 8월 8일 (일) 브라우저 쿠키와 SameSite 속성

  • 서버의 응답에 Set-Cookie 헤더가 포함되면 normal이라는 이름의 쿠키에 yes라는 값이 저장된다.
  • 이전에는 쿠키에 세션 ID를 넣어두고 어떤 사용자의 요청인지 판단하는 방식으로 로그인을 구현했다.
  • Domain 속성에 해당 쿠키가 유효한 사이트를 지정할 수 있다. 지정하지 않으면 기본적으로 쿠키를 보낸 서버의 도메인으로 설정된다.
  • 이렇게 설정된 도메인을 기준으로 First-party cookie와 Third-party cookie로 나눈다.
  • 퍼스트 파티 쿠키
    • 사용자가 접속한 페이지와 같은 도메인으로 전송되는 쿠키
  • 서드 파티 쿠키
    • 사용자가 접속한 페이지와 다른 도메인으로 전송되는 쿠키
    • Referer헤더와 쿠키에 설정된 도메인이 다른 쿠키
  • CSRf(Cross Site Reqeust Forgery)
    • 사용자가 A라는 사이트에 대한 쿠키가 있는 상태에서
    • 공격자는 사용자가 유사한 사이트(유사 은행 사이트 같은)에 접속하도록 유도한다 (링크)
    • 사용자가 이 사이트에 접속하거나 / 접속해서 어떤 동작을 하면 그 사이트는 사용자의 브라우저에 있는 쿠키(서드 파티 쿠키)를 이용해 HTTP 요청을 해서 공격자가 원하는 동작을 수행한다.
  • SameSite 쿠키
    • 서드 파티 쿠키의 보안적 문제를 해결하기 위해 Cross-site 전송시 쿠키 전송을 제한한다
    • None, Lax, Strict 세 종류의 쿠키 정책이 있다.
    • None은 SameSite 쿠키 이전과 동일하다. 서드 파티 쿠키도 전송함.
    • Lax는 중간 보안 정책으로 대체로 서드 파티 쿠키는 전송되지 않지만 몇 가지 예외적인 요청에는 전송된다.
    • Strict는 가장 보수적인 정책으로 Cross-site 요청에는 서드 파티 쿠키를 전송하지 않고, 오직 퍼스트 파티 쿠키만 전송한다.
  • Lax
    • 같은 도메인은 당연히 전송(퍼스트 파티 쿠키)
    • Top Level Navigation(웹페이지 이동)의 경우 전송
      • a 링크 태그 클릭
      • window.location.replace 등 자동으로 이뤄지는 이동
      • 302 리다이랙트
    • 안전한 HTTP 메서드 요청의 경우 전송
      • GET은 서버 상태를 변경하지 않으니 안전하고, POST, DELETE, PUT은 안전하지 않다. 즉 멱등성을 지키는 메소드만 가능하다
    • Lax는 현재 크롬만 기본값으로 사용하고 있다.
  • Secure
    • Samesite 속성으로 None을 사용하려면 해당 쿠키는 반드시 Secure 쿠키여야 한다. 즉 HTTPS가 적용된 요청이어야 한다.
    • 이 정책을 구현하는 브라우저는 크롬 뿐이다.
      
      
      

• 8월 9일 (월) 실시간으로 깃허브 알림 받기, Gitify 2주간 사용기

  • 깃허브에서 풀리퀘 댓글이나 멘션 언급, 코드리뷰 추가 커밋 등의 실시간 알림을 해주는 오픈소스 프로그램에 관한 이야기

  • 가볍게 읽었는데 참여한 프로젝트가 적다면 괜찮을거 같다. 프로젝트마다 설정할 수도 있고.. 아니면 오히려 퇴근후에.. 알림울리면 불-편 하려나..?
    깃허브 모바일에서도 알림이 가능하다는데 아직 사용 안 해보았다.

    
    

• 8월 10일 (화) 5년차 프론트엔드 개발자 이직 후기

  • 경력 이직 후기이긴 하지만, 벨로그 상단에 아주 눈에 띄게 있어서 읽어보았다. 다양한 회사 면접 후기와 질문들을 추려서 작성해주셨다.

  • 나는 약 한달 후에 전환 면접을 볼텐데 면접 경험이 없어서 걱정이 된다..

  • 기술질문에서 트러블 슈팅 경험 외에는 다 어느정도는? 대답할 수있는??(정말?) 질문이다. 즉 와 이런걸 물어봐? 같은 내용은 없지만 어떻게 대답하느냐가 중요하겠지?

  • 면접은 실력도 중요하지만 타이밍도 중요하다

    
    

• 8월 11일 (수) [면접]백엔드와 밀접한 네트워크 용어 정리

  • 자세한 글은 아니라서.. 오늘은 가볍게 읽는 것으로 !

    
    

• 8월 12일 (목) 짧게 써보는 웹 프론트엔드의 역사

  • HTML / CSS / PHP,ASP,JSP / ajax(XMLHttpRequest) / jQuery

  • angular.js 상태기반 양방향 바인딩! 그려져야할 모양을 우선 선언해두고 데이터만 바꿔주면 된다!

    • 데이터가 변경되었는지 어떻게 알아내는가가 react, vue, angluar, svelte간의 결정적 차이를 만들어낸다.

    • Angular는 막무가내로 주기적으로 계속 확인한다

  • React. 컴포넌트 단위 개발!

    • 데이터 변경을 '감시'하지 않고 '렌더해라'라는 명령으로만 동작한다.
    • Virtual DOM으로 렌더링 성능 개선

  • Angular

    • 기존 방식을 버리고 새로 만든 앵귤러 1버전과 전혀 호환되지 않는다
    • Zone.js / 데이터가 변경될 때 가능성이 있는 모든 핸들러에 감시를 붙인다

  • Vue

    • React는 템플릿이 없기 때문에 angular.js에 익숙한 사람이 불만이 있었다.
    • 컴포넌트 베이스 구조에 / prop,state를 쓰면서 / VDOM을 사용하면서 / 템플릿을 사용한다

  • Svelte

    • VDOM도 사용하지 않고 Zone 방식도 사용하지 않는다.
    • 개발자가 js코드를 쓰는게 아니라 Svelte 문법으로 작성된 .svelte를 컴파일한다
    
    

• 8월 13일 (금) [CS] 운영 체제 개념 학습

  • 운영체제 : 시스템 자원, 응용 프로그램을 관리하며 하드웨어가 원활히 작동하도록 시키는 주체

  • 운영체제는 응용 프로그램이 실행되면 시스템 자원을 활용할 수 있는 권한/사용자를 관리한다. 모든 사용자가 시스템 자원에 접근하면 문제가 발생하니까

  • 권한을 받은 응용 프로그램은 운영체제가 제공하는 기능, 시스템 콜(System Call) 을 사용할 수 있다.

  • 시스템 콜은 응용 프로그램이 시스템 자원을 사용할 수 있도록 운영체제가 제공하는 인터페이스이다.(API)

    • 예를 들어 워드프레서(응용 프로그램)이 프린터 사용(시스템 자원)을 하려면 프린터 드라이버(인터페이스)가 필요하다

  • 프로세스 : 운영체제에서 실행 중인 하나의 어플리케이션(프로그램)

    • 운영체제로부터 메모리를 할당 받는다

  • 스레드 : 프로세스 내에 존재하며 하나의 작업을 실행하기 위해 순차적으로 실행한 코드의 이어짐

  • 멀리 프로세스 / 멀티 스레드

    • 프로세스는 각자 Heap을 가지고 프로세스간 통신(IPC)이 어렵다.
    • 스레드는 하나의 Heap을 공유하며 서로 통신하는게 IPC보다 간단하다.
    • 시스템 처리량. 멀티 스레드 > 멀티 프로세스
    • 자원 소모. 멀티 프로세스 > 멀티 스레드
    • 멀티 스레드가 다 좋아보이지만 공유하는 자원(Heap) 에 대해 고민해야 한다. 서로 다른 스레드가 같은 Heap에 접근/수정/삭제 등을 하면 꼬일 수 있다

  • 시분할

    • 각 스레드를 시간에 따라 분할, 여러 스레드가 일정 시간마다 돌아가면서 실행하도록 하는 것
    • 동시에 돌릴 수 있는 멀티 스레드 수 === CPU 코어 수
    • 동시성(Concurrency)은 여러 스레드가 시분할 방식으로 동시에 수행되는 것처럼 보이는 것이고
    • 병렬성(Parallelism)은 실제로 스레드가 동시에 실행되는 것이다.
    
    

• 8월 14일 (토) [week2] CSR vs SSR 누가 더 좋아?

  • CSR : 최초 한 번 서버에서 필요한 정적 데이터를 모두 받아서 페이지를 로딩하고 이후에는 JS를 이용해 추가 데이터를 받아서 클라이언트 단에서 렌더링하는 방식

    • HTML 다운로드 (텅빔)
    • link된 JS파일 다운로드 (소스코드, 라이브러리/프레임워크 등)
    • 데이터 다운로드 (JSON 등)
    • 데이터+로직으로 사용자에게 화면 제공

  • SPA : CSR방식으로 페이지 Reload 없이 서버로부터 필요한 데이터만 받아와서 화면을 갱신한다.

    • 트래픽 감소 : 필요한 데이터만 변경하게 되어 서버 부담 덜함
    • 사용자 경험 : 첫 로딩 이후 빠르게 렌더된다
    • 첫 화면 렌더 느림
    • SEO 불가능 : 검색엔진은 첫 화면 HTML을 기반으로 동작하는데 HTML이 비어있어서 검색엔진에 노출되지 않음.

  • SSR : 서버에서 필요한 데이터를 모아 HTML파일을 만들어서 동적 제어 소스코드(JS)와 함께 클라이언트에 제공

    • 서버에서 필요한 데이터를 이용해 필요한 파일을 생성한다
    • 생성한 파일 + 동적 소스 코드를 클라이언트에 전달한다
    • 클라이언트는 이를 가지고 사용자에게 제공한다.
    • CSR보다 첫 로딩이 빠르다
    • SEO가 효율적이다. HTML에 이미 모든 정보가 담겨 있기 때문에
    • 단, 요청마다 새로고침이 일어나고, 서버에 리소스를 요청해서 부담이 증가한다(서버 과부화)
    • 인터렉팅 미반응 : 화면은 보이지만 기능이 바로 실행되지 않을 수 있음 (JS파일을 서버에서 받아오는 과정에서)
    • 따라서 사용자가 많고, 인터렉션이 많은 웹은 적절하지 않음
    
    

• 8월 15일 (일) 애니메이션에서 불필요한 속성 하나가 브라우저 렌더링 성능에 끼치는 영향

  • 크롬 개발자 도구 perfomance에서 Start profiling and reload page를 통해 성능을 측정한다.

  • Loading / Scripting / Rendering / Painting 시간을 측정한다

  • Idle, System 시간은 제외

  • 애니메이션 갯수를 대폭 늘려서 실험한 결과 오히려 Rendering 시간이 늘어났다는데 그 이유에 대해서는 언급되지 않았다

  • 그럼에도 약 2~30%의 성능 개선을 이룸. (border-radius 속성을 없앤 것만으로)

  • LightHouse로 performance report 받기.

  • layout, paint, composition을 다시 트리거하는 CSS 속성을 주의하자

    
    

• 8월 16일 (월) [TIL] git merge vs git rebase

  • merge는 3-way-merge로 각각 다른 브랜치를 병합한다.

  • 3-way-merge는 각 브랜치의 마지막 커밋 2개 / 베이스의 커밋을 이용해서 병합하는 방법이다

  • 만일 base가 없다면 비교 대상이 없어서 커밋을 결정할 수 없다.

  • git rebase -i에서 -i 명령어는 필요한 커밋만 남겨서 새로운 커밋을 만들 수 있는 명령어다

  • -i 명령어로 실행시 vi 편집기 상단에 있을 수록 오래된 커밋이다.

  • pick을 s로 바꿔주면 스쿼시 커밋이 된다.

  • 오래된 커밋을 중심으로 새로운 커밋을 만들어야한다. 중간의 커밋부터 하면 이전 커밋이 무시되어 그 이력이 소실된다

    
    

• 8월 17일 (화) [리액트 문서 읽기 1] - 엘리먼트와 렌더링

  • 리액트 엘리먼트는 리액트 앱의 가장 작은 단위

  • 엘리먼트는 type, props, children을 받는다.

  • 엘리먼트는 ReactDOM.render에 의해 실제로 렌더링된다.

  • diffing 알고리즘

    • 기존 엘리먼트 트리 - 새로운 엘리먼트 트리 비교
    • 엘리먼트의 타입과 key prop을 통해 동일한 엘리먼트인지 비교
    • 동일한 엘리먼트라면 변경된 속성만 갱신
    • 동일하지 않으면 노드를 새로 변경
    
    

• 8월 18일 (수) 썸네일 메이커(Thumbnail Maker) 만들기 | Toy Project

  • 선택지를 줄여 사용자의 고민을 덜어주는 것. 좋다.

  • HTML2CANVAS - HTML내 특정 DOM 요소의 영역 캡쳐, 이미지 포맷으로 출력, 저장하는 라이브러리

  • 목표를 정하고 필요한 기능을 정의해서 진행한 모습이 좋다.

  • CORS 문제나 의견을 받아 지속적으로 개선하는 모습도! 개인 프로젝트로 간단하지만 굳굳..

    
    

• 8월 19일 (목) [week1] Web Storage? 무엇을 저장해?

  • 쿠키의 단점. 매 HTTP 요청마다 쿠키를 담아 보내고 받는 것은 상당한 트래픽을 발생시킴 / 보안 이슈

  • 이를 해결하기 위해 세션 등장

  • 쿠키의 문제점 보완 및 사용자 인증 가능

    • 일시적 데이터 저장
    • 관리자/사용자 여부
    • 사용자 수에 비례해서 서버 데이터를 차지함
    • token을 쓰자

  • web storage의 용량은 약 5mb! 쿠키는 4kb ...

  • web storage는 key-value / 쿠키는 string

  • 그러나 web storage는 보안 문제, 과도한 지속성 등의 문제로 지양하게 됨

  • Service worker가 제공하는 cache storage API / indexedDB 등의 대안!

  • 사실 나는 http only 쿠키를 주로 사용한다.

    
    

• 8월 20일 (금) 뱅크샐러드는 어떻게 레거시 서비스를 박살 내는가

  • 빠른 성장에 집중해서 미진한 복잡도 제어 대처

  • 핵심 비즈니스 로직이 거대한 모놀리식(monolithic) 서버가 됨. 추가/수정하기 어려움

  • 더 심각한 문제는 이 레거시 서비스의 비즈니스 로직을 정확히 하는 사람이 없다는 것

  • 이 거대한 레거시 서비스를 분해(decomposition)하는 방법 채택

  • 내가 확실히 알고 있는 무언가로부터 시작 우리 조직

  • 콘웨이의 법칙. 소프트웨어의 구조는 이 소프르웨어를 만들어낸 조직의 커뮤니케니션 구조를 따른다.

  • 뱅크샐러드는 '스쿼드'체계로 움직임.

  • 프로젝트의 복잡도 제어 문제 단순화(레거시-신규 응답 일치 측정) / 목표가 아닌 것을 분명히해서 원칙에 집중 / 매일 필요하다면 두시간에 한 번씩 만나 자주 상황 공유

  • 섀도잉. 같은 요청에 대해 기존 서비스와 새로운 서비스의 응답이 일치하는지 비교하는 방법 => 키바나(kibaba) 사용. 사람 대신 기계에게 비교를 맡긴다

  • 테크 스펙 문서를 분명하게 작성해서 해야할 일 / 하지 않아도 될 일을 명확히 구분

  • 장애없이 레거시 서비스를 빠르게 분해하는 것이 목표

  • 매일 15씩 스탠드업 미팅. 어제 한 일 / 오늘 할 일 / 일처리에 겪는 어려움 등

    
    

• 8월 21일 (토) 주소 인식을 위한 삽질의 기록

  • 안전을 위해선 무엇이든 한다! 그게 삽질이라도

  • 당근 마켓은 중고거래 사기의 발생을 방지하기 위해 택배거래보다 직거래를 권장하며, 직거래 또한 공공장소에서 하길 권한다. 이 때문에 채팅 중 주소와 관련된 채팅을 인식해서 관련 안내메세지를 띄우는게 중요하다고 판단하는 듯 하다

  • 정규식을 도입하면 간단하지만, 결국 엣지케이스가 발생한다.

  • 도로명 주소 관련 자체 데이터도 없고, 오픈 API도 별다른게 없었다. 정부 도로명주소 사이트에서 하나하나 다운 받아서 합치는 수작업을 거침.

  • 구글 스프레드 시트로 옮기고 csv로 받아서 스크립트로 검증

  • 아직도 해야할 일이 많다!

    
    

• 8월 22일 (일) 프로세스와 스레드의 차이

  • 파일이 저장 장치에 저장되어 있지만 메모리에는 올라가 있지 않은 상태

  • 프로세스 : 운영체제로부터 자원을 할당받은 작업의 단위. 프로그램이 메모리에 올라가 있는 상태

  • 스레드 : 프로세스가 할당받은 자원을 이용하는 실행 흐름의 단위. 프로세스에서 자원을 서로 공유한다.

  • 운영체제 관점에서는 프로세스가 최소 작업 단위이며, CPU 입장에서는 스레드가 최소 작업 단위이다.

  • 멀티테스킹은 하나의 운영체제, 여러 프로세스 / 멀티스레드는 하나의 프로세스, 여러 스레드

  • 멀티스레드에서 가장 중요하게 고려할 사항은 바로 동기화이다. 자원을 공유하다보니 발생할 수 있는 문제

    
    

• 8월 23일 (월) 프론트엔드와 백엔드가 소통하는 엔드포인트, RESTful API

  • 사용자가 엔드포인트와 메소드만 봐도 API에게 기대하는 동작/서버에서 실제 수행하는 동작이 명확하게 일치해야한다.

  • 클라이언트-서버가 API 통신을 통해 주고 받는 것들은 리소스 그 자체가 아니라 서버가 데이터베이스에 저장된 원본 데이터의 현재 상태를 JSON으로 표현한 것이다. REST의 REpresentational state!

  • 원본 리소스는 데이터베이스에 하나의 row로 존재하지만, 이것 자체를 전달해주는게 아닌 표현데이터를 전달해 주는 것이다!

    • 리소스가 어떻게 표현되는지 REST
    • 어떤 리소스인지 URI
    • 어떤 행위인지 - HTTP Method

  • URI에 복수형을 쓰는 이유는 해당 리소스가 특정한 하나의 객체가 아니기 때문이다. user(x) users(o)

  • 결국 우리가 고민해야 할 문제는 특정 유저의 프로필 사진이라는 리소스를 포함하는 상위 계층 리소스가 “유저가 더 명확하냐”, “프로필 사진이 더 명확하냐”인 것이다.

  • URI에는 행위가 표현되면 안 된다. HTTP Method로 행위를 표현하자

  • PUT은 수정으로 오해하기도 하지만 실제로는 해당 리소스를 요청 바디에 담긴 것으로 대체하는 것이다.

  • 일부 수정은 PATCH로한다.

  • 하지만 진짜 중요한 차이는 PUT은 멱등성을 보장하지만 PATCH는 멱등성을 보장하지 않을 수도 있다는 것이다

  • 멱등성이란 어떤 대상에 같은 연산을 해도 결과가 달라지지 않는 성질이다.

  • 엔드포인트만 봐도 어떤 동작을 하는 API인지 바로 이해할 수 있을 정도로 명확한 API가 가장 좋은 API라고 생각한다.

    
    

• 8월 24일 (화) 주니어, 미드레벨과 시니어 개발자의 차이점

  • 디자인패턴/아키텍처/테스트자동화/성능/보안 등.. 명백하게 시니어가 더 많이 안다.

  • 코드는 컴퓨터와 커뮤니케이션하는 것같지만, 사실은 앞으로 작업하게 될 다른 개발자들이 이해할 수 있는 코드여야한다. 이전 코드를 본적없는 사람이 새로운 기능 추가 / 버그 수정이 가능해야 함!

  • 주니어는 코드를 자주 동작시킨다. 동작하는 소프트웨어 === 좋은 소프트웨어라고 여긴다.

  • 주니어는 간단한 코드보다 멋진 코드를 작성한다. 복잡한 추상화..

  • 시니어는 유지보수/확장성을 염두한다.

  • 주니어는 경험이 없기에 미드레벨이 되기 위해서는 전체 개발 과정을 최소한 두 번 반복해야한다

  • 디버깅/모범사례를 통한 아키텍처,성능,보안에 대해서 공부해야한다

  • 시니어는 무엇을 자르고, 어떤 것은 자르면 안 되는지 알고 있다.. 아무도 모르는 작업을 할 수 있어야 한다.

    
    

• 8월 25일 (수) 지라를 활용해 결혼 준비하며 배운 것

  • 결혼을 ..? 뭐로 관리한다고..?

  • 지라를 사용할 때 가장 먼저 해야하는 일은 티켓을 만드는 것

  • 가급적 미리 한 번에 만들어서 모두 백로그로 만들어두는게 이상적

  • 다만 진행하다보면 예측하지 못 한 이슈가 발생. 이 예측이 가장 중요하고 어렵다

  • 지라는 의존성(무슨 일이 먼저 수행되어야하는지, 태스크 간 관계)을 표시/시각화하는 데 탁월하다.

  • 지라 티켓은 담당자와 협업자 항목이 있다.

  • 정기적으로 멈춰서 우리가 맞는 방향으로 가고 있는지 확인해야한다.

    
    

• 8월 26일 (목) 새 버전에 맞게 git checkout 대신 switch/restore 사용하기

  • switch, restore가 checkout을 대신하면서 git --help에도 checkout이 나오지 않는다!

  • checkout이 대체된 이유는 하나의 명령어임에도 기능이 많아서이다

  • switch : 브랜치를 변경하기만 함. 브랜치 생성/이동을 동시에 하는 옵션은 -c이다

  • restore : 워킹 트리의 파일을 복원한다.

    • git checkout -- {filename} 대신 git restore {filename}
    • git add로 stage에 넣은 내용을 빼려면 git reset HEAD {filename} => git restore --staged {filename}
    
    

• 8월 27일 (금) 우리는 코드 리뷰를 잘하고 있을까요?

  • 개발자 많아짐 => 커뮤니케이션 비용 증가 => 생산성 저하. 릴리즈를 거듭할 수록 소프트웨어는 거대해진다.

  • 거대한 소프트웨어는 아키텍처/코드/설계가 좋아야 생산성이 유지된다.

  • 코드리뷰는 새로운 기능이 버그 없이 의도대로 동작하는가 / 아키텍처를 잘 따른는가 / 다른 사람이 읽는데 문제 없는가 / 올바르게 설계 되었는가

  • 피드백을 주고 받으며 팀 전체 성장

  • 코드리뷰 기법

    • 린트 등으로 스타일 자동화해서 코드리뷰할 내용 제거
    • 템플릿등 이용해서 가이드 만들기
    • 코드리뷰는 가능한 빨리
    • 고수준=>저수준으로 진행 인터페이스 설계/복잡한 함수 분리 => 변수이름, 주석 등
    • 명령아닌 요청
    • 원칙에 근거해서.
    • 한 번에 아니라 조금씩 좋아지기를 기대하자
    • PR과 무관한 요청 x
    • 칭찬
    • 교착 상태는 가능한 빨리 해결.

  • 코드리뷰는 문화다.

    
    

• 8월 28일 (토) V8 엔진은 어떻게 내 코드를 실행하는 걸까?

  • V8 작동 원리

    • 소스코드를 parser에서 분석 후 AST(Abstract Syntax Tree)로 변환
    • AST를 Ignition 인터프리터로 전송해서 JS를 바이트코드로 변환
    • 바이트 코드로 변환함으로써 다시 파싱할 필요 없고, 코드양 줄고, 코드 실행 메모리도 절약한다
    • 바이트 코드를 실행하면서 작동하고, 자주 사용되는 코드는 TurboFan으로 보내져서 최적화된 코드로 다시 컴파일 된다. 사용이 덜 되면 다시 해제되기도 함
    • V8 - 8기통 엔진 / Ignition - 엔진에 시동거는 점화기 / TurboFan - 과열을 식혀주는 팬 .. 네이밍 센스!

  • Parsing. 컴퓨터가 분석하기 쉬운 형태인 추상 구문 트리(AST)로 변경하는 작업

  • Ignition. 고급 언어 소스코드를 가상머신이 쉽게 읽을 수 있도록 중간 코드로 컴파일한다

    • 기존의 Full-codegen는 컴파일시 전체 소스코드를 한 번에 컴파일했다. Ignition은 이를 완벽히 대체하며 코드 한줄 한줄이 실행 될 때마다 해석하는 인터프리트 방식을 채택했다.
      • 메모리 사용 감소 / 파싱시 오버헤드 감소 / 컴파일 파이프라인 복잡성 감소의 이득을 얻었다!

  • 레지스터(Register). CPU가 가지고 있는 고속 메모리

  • 누산기(Accumulator) 계산한 중간 결과를 저장하는 레지스터

  • TurboFan. 최적화 담당

    
    

• 8월 29일 (일) prettier 2.0에서 달라진 옵션 살펴보기

  • 이제 Node 10버전 이전에서 지원 안 됨.

  • .prettirerc 파일이 overried 가능해짐

  • trailingComma default가 none => es5

  • arrowparens defualt가 avoid => always (화살표 함수 단일 파라미터에 괄호를 붙일지 말지)

  • endOfLine defualt auto => if

  • prettier.geetSupportInfo의 version 파라미터 삭제

  • options/option 제거

  • prettier.util API 추가

  • search 결과 캐싱

    
    

• 8월 30일 (월) 어서 와, SSR은 처음이지? - 도입 편

  • 네이버 블로그 모바일 서비스가 어떻게 Node.js 기반 SSR로 전환을 결정했는지.

  • SSR은 모든 데이터가 매핑된 서비스 페이지를 클라이언트에 바로 보여줄 수 있다.

  • SEO도 장점!

  • SPA로 전환하면서 프론트/백 영역 구분이 필요했다. angular 사용

  • FULL STACK을 지향했으나 프론트의 생태계 빠르게 변화하면서 어려워졌다

  • 네이버 블로그는 사용자가 방문하는 블로그 세션 / 네이버 검색, 메인을 통해 노출되는 블로그 글 영역으로 구분 됨

  • CSR만 지원하는 angular로는 콘텐츠를 빠르게 소비하는 사용자 요구 사항을 충족시킬수 없었다. 네트워크 상황이 좋지 않다면 사용자는 글을 보기 전 상당 시간 흰 화면을 봐야할 수도 있다

  • CSR의 문제를 해결할 수 있는 렌더링 기법도 있지만 React 기반 SSR을 하는걸 채택.

    • universal language의 장점과 성장한 React 생태계를 이용할 수 있게 되었다.
    • SSR로 인해 프론트/백 영역을 완전히 분리 => 생산성 높임
    • SSR 아키텍처를 구성하면 다른 여러 가지 대안을 활용할 수 있는 토대가 됨 => 필요에 따라 CSR로만 구성할 수도 있고, prependering을 함께 사용할 수도 있다.
    • SSR 도입 이후 프론트/백엔드 커뮤니케이션은 API 명세에 대한 것으로 국한되고 각 작업의 완성도 및 이슈 대응 생산성도 높아짐
    
    

• 8월 31일 (화) 어서 와, SSR은 처음이지? - 개발 편

  • 레거시를 한 번에 다른 환경으로 옮겨 오픈하는 건 개발 기간도 오래 걸리고, 리스크 관리 측면에서도 위험하다. 특히 24시간 사용되는 서비스라면 더욱

  • 점진적으로 오픈,확인,경험을 쌓는 방법.

  • 점진적 배포를 위한 방법 => URL 단위의 배포 => reverse proxy 구조

  • 사용자의 요청이 프록시 서버 => 웹서버 => 처리한 응답을 다시 프록시 서버를 통해 클라이언트로 전달

  • reverse proxy가 Node.js SSR로 전환이 완료된 페이지의 요청인지, 아닌지 구분해서 서빙한다

  • URL 단위로 개발하려면 URL이 존재하지 않는 공통 영역에 대한 준비를 먼저 해야한다. 예를 들어 상단 메뉴나 헤더 등등.. URL과 상관없는 공통 컴포넌트 같은 것들

  • Node.js기반 SSR 환경 구성 방법

    • 가장 간단한건 Next.js를 사용하는 것! React 공식 가이드에서도 명시되어 있다.
    • 단 네이버 모바일 블로그에서는 사용하지 않음.
      • 뷰 전용 라이브러리가 아닌 서비스 플로우 전체를 담당하는 프레임워크를 블랙박스로 관리하기엔 운영 리스크가 컸다.
      • 빠르게 변하는 프론트엔드 생태계를 Next.js에 의존해야 했다
      • => SSR 환경 자체 구축 결정
      • NextJS 9.x부터 나아짐.

  • 라이브러리, 프레임워크는 개발 생산성 향상을 위해 사용한다.

  • NodeJS는 단일 스레드로 조회성 서비스에 훌륭한 성능/안정성을 자랑한다

  • inkedin은 Ruby on Rails를 Node.js로 전환함으로써 30대를 운영하던 서버를 3대로 줄일 수 있었고, PayPal은 Java를 Node.js로 전환함으로써 기존보다 35% 이상 평균 응답 속도를 줄일 수 있었다.

  • 성능 테스트는 어플리케이션과 서버 환경의 최적의 환경을 찾는 것과 최적 환경에서 어느정도 부하를 견딜 수 있는지 시스템의 가용량을 확인이다.

  •