나빼고다천재

find와 grep은 목적은 특정 파일을 찾는데 그 의의가 있는 명령어다

그렇다면 왜 굳이 이거 두개가 분리되어있을까?

find는 어떠한 기준을 제시하여 거기에 맞는 파일을 출력해준다

예시는 이렇다

find . -size +100M 라고 제시하면 리눅스에서는 "현재" 디렉토리에서 100메가 이상의 파일을 찾아준다

grep의 예시는 이렇다

grep "test" . 라고 실행하면 리눅스에서는 "현재" 디렉토리에서 test라는 문자열을 가진 파일을 전부 검색해준다

Q. 그렇다면 find로는 문자열 패턴을 검색 할 수 없나요

A.

이렇게 예시를 갈라두면 혹시나 처음보는 사람이 엥? 되는데? 라고 생각할 수 있으니 사족을 붙이자면 find와 grep을 혼용하여

사용하면된다는것이다

find . -exec grep -l "test" {} + 라고 치면 test라는 문자열을 가진 파일을 출력해준다.

Q. 엥 그러면 grep "test"와 ind . -exec grep -l "test" {} + 의 차이점은 뭐죠?

A. 출력되는 내용이 다릅니다.

우선 아래와 같은 파일이 있다고 가정해봅시다.

memo1.txt

test 메세지 입니다.

memo2.txt

test 코드입니다.

memo3.txt

text 파일입니다.

find . -exec grep -l "test" {} + 을 실행하면

memo1.txt

memo2.txt

grep "test"라고 검색하면 

test 메세지 입니다.

test 코드입니다.

두개의 차이점이 확느껴지지않는가?

뭐 2개가 합쳐진거지만 사소한 찐빠는 넘어가도록 하자

끗

어느날 아는사람이 where x = null 로 조회하니 결과가 안나오더라

where is null 은 조회가 된다는것이다

"null은 값이 없으니 비교가 안되죠" 라고하니깐 이해를 잘못하던데 좀 더 자세히 설명하려고 글을 썼다

NULL은 특수한 값입니다. 일반적인 비교 연산자(=)에는 작동하지 않습니다.

이 알수없는 값은 비교연산자에 들어가게 되는 순간 false를 반환하여 작동하지 않습니다.

즉 여기서 알수있는것은 true가 반환되어야 거기에 맞는 값이 반환되는것인데

null은 알수없는 값이 있는 유니크한 값이라 자동적으로 비교연산자가 false로 반환하기 때문에 값이 없는거다.

아래는 null 값을 검색하는 일반적인 권장방법이다.

select * from sample
where test is null

이렇게 IS NULL(혹은 is not null) 같은 형태의 명시적 방법이 권장됩니다.

객체지향 프로그래밍이 대세인지 모르겠지만 객체지향이라는 말을 요근래 자주 접하게 됬다.

자바스크립트는 그 태생부터 객체지향 언어였다. 

하지만 태생이 그렇다뿐이지 처음엔 객체지향에 적합한 언어는 아니였다.

그렇기에 초기에 많은(나도 그러하다)언어의 태생은 잊은채 명령형으로 자바스크립트를 다루기 시작했다.

const one = "hello";
const two = "world!";
cosnt plus = one + two;
console.log(plus); // helloworld!

우리가 지금도(나쁘다는뜻이 아니다)보는 일반적인 명령형 구조이다. 

위에서 아래로 구성되며 자연스레 읽힌다

하지만 많은 개발자들이 객체지향의 장점에 주목하기 시작했다. 

객체지향은 명령형과는 다른 견고함을 지녔으며 뛰어난 재사용성,유지보수성,확장성 등을 선보였다.

이러한 장점들에 반한 사람들은 자바스크립트의 태생을 주목하기 시작했고 

ES6부터 드디어 자바스크립트에도 객체지향이라는 봄이 찾아오기 시작했다.

- 자바스크립트에도 객체지향이라는 봄이 오는가

객체지향의 지원을 위해 많은 것들이 도입됬다. 

클래스,상속,모듈,화살표함수 등 이런 많은것들이 등장했다 아래를 살펴보자

// 명령형 코드로 배열에서 최댓값을 구하는 함수
function getMax(arr) {
  let max = arr[0];

  for(let i = 1; i < arr.length; i++) {
    if(arr[i] > max) {
      max = arr[i];
    }
  }

  return max;
}

console.log(getMax([1, 5, 2, 7, 3, 9])); // 9

위는 명령형으로 만들어진 함수이다. 일반적인 방법을 사용했고 으레 그렇듯 반복문을 활용해 배열안에 있는

숫자 중 가장 큰 수를 가져온다.

이런 단순 한번만 쓰자면 별 문제가 없어보인다. 문젠 이것을 확장하거나 재사용을 할때 문제가 생겨버린다.

최대값이 아닌 최솟값을 찾는 기능을 추가하자면?

다른 기능과 조합가는 경우에는?

순회하는 배열안의 원소들이 천개,만개를 넘어서면?

명령형이 생기는 문제들에 직면할수있다. 객제지향이 매력적으로 보고 싶다면 아래 코드를 보자

// 객체지향적으로 배열에서 최댓값을 구하는 클래스
class MaxFinder {
  constructor(arr) {
    this.arr = arr;
  }

  find() {
    return Math.max(...this.arr);
  }
}

const finder = new MaxFinder([1, 5, 2, 7, 3, 9]);
console.log(finder.find()); // 9

클래스로 MaxFinder를 만들고 안에 find라는 메서드를 만들고 메서드는 안에는 숫자를 파라미터로 받아

스프레드오퍼레이터를 활용해 받은 다음 큰 수를 받아낸다. 

정말 멋진 코드가 아닐 수가 없다.

하지만 이러한 객제지향은 가장 큰 난관은 프론트엔드의 관점에서 객체지향은 그저 이런게 있다라고 알고 

넘기는거 말고는 방법이 없다

객체지향을 처음 접하면 명령형에 비해 생산성이 떨어지는건 모두가 아는 사실

이것이 프론트엔드의 객체지향의 문제점이다 

프론트엔드의 귀결은 모두가 리액트(아마도)로 되기 때문에 선언형을 배우게 될텐데 선언형은 

객체지향과 다른 패러다임을 향하고 있기 때문에 굉장히 다르다.

아래의 코드를 보자

// 선언형 코드로 배열에서 최댓값을 구하는 함수
function getMax(arr) {
  return arr.reduce((acc, cur) => cur > acc ? cur : acc, arr[0]);
}

consleo.log(getMax([1, 5, 2, 7, 3, 9])); // 9

객체지향과의 차이점이 한눈에 보일것이라 생각한다. 

이러한 이유 때문에 프론트엔드의 객체지향은 잡힐듯 잡히지 않는 신기루 같은 존재가 되어버린거다.

물론 도입하자고 하면 도입할 수 있겠지만 프레임워크의 권장,표준 이라는것을 쉽게 무시할 수 없다

절대강자로 자리잡은 리액트의 선언형을 그 누가 객체지향으로 하겠는가?

혹시 모른다 구글이라면 가능할지도

SSR이라고 하니 마치 가챠게임의 등급같다. 

내가 해본 가챠게임의 처음이자 마지막은 판타지타워라는 게임이였는데...내 지갑을 훔쳐갔다.

망할

여튼 얼마전 글도 잘안쓰던놈이 SSR이 이렇다느니 저렇다느니 주절주절 쓰다보니 이것도 주제로 글을 쓰면

좋을것같아서 작성한다.

먼저 두개로 나누어 각각의 장점 단점과 결론으로 차이를 간추려 정리한 다음 글을 마무리할 예정이다.

1. CSR 

- CSR 두두등장

웹이 태동하며 어느정도의 구조 (즉 리액트나 앵귤러 뷰같은 프레임워크들이 정착되기전 별도의 라이브러리 없이 바닐라

만 사용한 일반적인 경우를 일컫는다)를 갖추게 되었을땐 모든것들이 좋아보였다. 그러다 2010년 즈음을 기준으로 

CSR이라 불리우는 기술이 조금씩 보편화 되었다 늘 그렇듯 최초의 타이틀은 대기업 구글의

AngularJs 프레임워크가 가져갔으며 뒤이어 나온 backbonejs,emberjs가 CSR 기술을 달고 나타났다.

이른바 대 CSR 시대가 도래했다. 한가지 공통점이라면 SPA라 불리우는 싱글 페이지 어플리케이션을 위해 

위의 도구들이 나타났는데 SPA이라면 으레 당연히 CSR이라 받아드려졌다.

이후 프레임워크 3대장이 등장하며 CSR은 개발자들 사이드에 스탠다드 개발 방법으로 굳어졌다.

- 장점

1. 속도가 굉장히 빠르다.

- 많은 사람들이 고작 첫번째로 내세운 장점이 속도냐고 반문하겠지만 웹의 속도는 웹이 궁극적으로 발전하고자 하는 방향

이다. 소모되는 자원을 줄이고, 양방향 통신을 지원하고 이런 모든 행위들이 웹의 속도를 향상시키기 위해 발전한것이다.

빠른 이유는 서버는 별도의 렌더딩을 하지 않고 파일만 전달하고 클라이언트가 렌더링을 진행하기 떄문이다

빠르다는건 더 나은 사용자경험,다양한 상호작용,빠른 초기 진입 속도를 보장한다는것이다.

그리고 사용자에게 모든것을 전달하는 SSR보다 CSR은 사용자가 필요로할때만 전달하기에 자원을 절약하고

더 빠른 응답속도를 얻었다. 초기에 웹들이(그러니깐 컴포넌트 기반이 아닌 SSR)검색,정렬,필터 등을 적용할떄마다

페이지 전체를 다시 불러와야하는 그 지옥같은 루프에서 해방됨을 의미했다. 

그렇기에 사용자가 검색을 요청한다면 검색과 관련된 컴포넌트 데이터만 요청하여 클라이언트라 렌더링하는

이른바 신세계가 열린것이다.

2. 서버의 부담이 줄다.

- SSR은 서버가 렌더링까지 부담해야되기 때문에 서버의 자원 사용이 더 증가하지만 CSR은 그렇지않다

그저 리소스를 던지기만 하면 클라이언트가 알아서 렌더링한다. 이러한 서버의 부담을 줄이는것은 다른 

요청의 응답에 더 빠르게 응답할수 있고 서버에게 다른 일을 시킬수 있으며 기업의 입장에서는 서버의

부담 감소는 비용을 절약시키고 언제고 뻗을 수 있는 물리적 서버가 어느정도의 리스크를 완화 시키는

결과를 불러왔다

- 단점

1. 초기 속도가 느려지다.

- 역설적이게도 대규모의 서비스가 구축되며 이 단점은 크게 부각되었다. 필요로 하는 모든 소스를 

받아와야하며 클라이언트가 렌더링까지 해야되기 때문에 초기 로딩이 지연되는 이슈가 등장했다.

이 단점은 쇼핑몰 같은 고객의 이탈율을 최소화해야하는 분야에서 더욱 더 단점으로 다가왔으며

후술할 추가 단점까지 물려 골치거리로 다가왔다.

2. SEO의 불가

- 쇼핑몰 혹은 트래픽의 증가가 수익으로 환전될 가능성이 있는 사이트들은 검색엔진의 상단에 

노출되길 희망하고 실제로 그러기 위해 굉장히 노력한다. 하지만 일반적인 검색엔진

(퍼블리셔건 프론트엔드 개발자건 검색엔진이 HTML 코드를 크롤링하고 색인하는것을 알고 있을 

것이다)은 CSR의 불안전한 HTML파일을 크롤링하여 색인할수 없기 때문에 SEO에 악영향을

주게된다. 왜냐하면 CSR은 렌더링의 주체가 서버가 아니라 클라이언트이기 때문에 

렌더링이 일어나지 않으면 정상적으로 노출되지 않기 때문이다.

3. 보안의 헛점

- 보안은 웹 환경에 꼭 필요한 조치이지만 CSR은 특히나 보안이 취약했는데

이는 CSR이 기본적으로 모든 처리를 클라이언트에게 위임했기 때문이다

대표적인 사례는 아래와 같다.(보다 자세한 사항은 각 항목마다 달린 링크를 참조하는게 더 좋다 

이 글은 CSR에 대한 글이지 아래같은 보안 사항에 대해 공부하는게 아니니깐)

XSS(Cross-Site Scripting)

https://nordvpn.com/ko/blog/what-is-cross-site-scripting/

CSRF 공격

https://owasp.org/www-community/attacks/csrf

2. SSR

- SSR 떠,떳냐?

※ 주의: 아래에서 설명하고자 하는것은 CSR 태동 이전의 SSR과 컴포넌트 기법을 바탕으로 하는 

SSR을 혼합해서 설명하고 있다

 위에서 언급한것처럼 CSR의 등장 이후 CSR은 개선을 거듭했지만 구조적인 단점은 계속해서 산재했다.

썩어도 준치라고 CSR 이전의 주류로써 간간히 그 명맥을 잇고 있었는데 PHP가 그러했고 JSP가 그러했다.

그러다 CSR의 단점을 지긋지긋하게 여긴 React가 React server라는 라이브러리를 공개했다

리액트 공식 홈페이지에선 0.12 .0 부터 (공식 홈페이지에선 그렇다는데...)

서버 사이드 렌더링 지원을 포함하며 서서히 컴포넌트 기반의 SSR이 태동하기 시작했다.

초기 SSR은 단점이 많았다. JSP나 PHP는 모든 기능들이 하나의 페이지에 묶여있었기 때문에 정보를 요청하고

다시 표현하기 위해서는 페이지를 다시 불러와야 했으며 사용자 경험을 하락시켰다.

하지만 컴포넌트 기반의 패러다임이 등장하며 모든 부분을 새로 고칠 필요 없이 필요한 부분은 요청하는것이 

대세가 되었다 SSR에게도 광명이 들기 시작한것이다.

- 장점

1. 속도도 빠르고! SEO 최적화도 되고!

- 웹의 발전을 동거동락한 SSR답게 규모가 크고 작건 서버에서 렌더링을 해서 전달하기 때문에 대규모의 CSR에 

비해 일정부분 속도가 보장되었으며 트래픽이 매출과 연결되는 기관들은 SEO최적화를 할수있다는 

장점을 얻었다. 이는 SSR이 서버측에서 이미 렌더링을 하여 완성된 HTML,CSS 파일들을 보여주기 때문에

서치엔진이 크롤링하여 인덱싱을 할 수 있기 때문이다.

2. 보안개선

위에 언급된 보안 취약점들을 대부분 해결할 수 있다 이는 서버가 모든걸 렌더링하고 최종적으로 HTML 파일을

생성해 클라이언트 전달하기 때문에 마음대로 조작하는건 CSR에 비해 굉장히 어렵다.

3. 효율적인 캐싱 

서버 사이드 렌더링은 서버측에서 캐싱된 HTML 파일을 제공하여 사용자가 캐시된 파일을 다시 요청하지 않아도

재사용 할 수 있어 서버의 자원을 감소 시키고 서버의 비용을 감소 시킬 수 있다.

- 단점

1. 비용의 증가

- 서버 사이드 렌더링은 서버가 일을 더 해야하기 때문에 서버에 가해지는 부담은 필연적으로 증가할 수 밖에 없다.

이는 서버의 비용을 증가시키고 서버를 관리해야될 인력이 추가로 필요로 할 수 있기 때문에 전체적인 관리

비용을 증가시킨다

2. 크지않은 CSR 기반의 웹페이지보다 초기 속도가 느릴 수 있다.

- CSR이 초기 각광받았던것은 중,소규모 웹페이지의 속도가 빨랐기 때문이다. 엄연히 SSR은 가벼운 CSR보다 

속도가 느리다.

3. 어렵다

- 어쨋건 지금의 SSR은 CSR보다 어렵다 이는 생각보다 나름 중요한 문제인데 필자만봐도...

- 차이점

1. 렌더링의 주체가 SSR은 서버 CSR은 클라이언트

2. SEO 최적화은 CSR은 불가능 SSR은 가능

3. 보안적으로 뛰어난건 SSR 취약한건 CSR

4. 서버 부담은 CSR이 낮고 SSR이 높다

- 잡설

- SSR은 컴포넌트 기반의 개발 패러다임이 등장하며 꾸준히 발전해 지금의 CSR보다 좋다(개인적으로?)

CS탭을 신설했다.

글을 보는 사람 중 롤악귀들은 (내가 그렇다) 미니언 막타? 라는 생각을

굉장히 연로한 FPS 유저라면 카운터스트라이크를 떠올리겠지만 

애석하게도 재미없는 컴퓨터 과학 이야기가 될것이다.

얼마전 HTTP1.1 / 2.0의 차이가 무엇일까요? 라는 질문을 받았다. 

내 대답은 심플했다.

"메이저 업데이트가 있었나 보네요"

이렇게 대답하면 실력없는거 티 나는데..이제부터 아는척이라도 해야겠으니 먼 과거의 기억과 구글을 더듬으며

정리해보겠다.

HTTP1.1과 2.0의 차이 알기전에 이글부터봐라

https://developer.mozilla.org/ko/docs/Web/HTTP

윗 링크에는 여러 목차들이 있는데 전부 볼 필요는 없다 하지만 보면 좋다

1. 설계 방식의 변경

서로 통신을 행할땐 1.1은 요청과 응답이 순차처리되는 방식이였다.

여러개의 요청이 접수되어도 요청 -> 응답 -> 요청 -> 응답 .... 같은 방식을 가지고 있었고

요청이 여러건이 있어도 응답이 오지않으면 요청을 보내지 않았다 

이러한 형태는 지금의 우리가 보아도 

라는 생각이 절로 난다(물론 웃자고 하는 이야기다)

이러한 설계는 동시 전송 문제와 다수의 정보를 처리하는데 문제가 있었다. 하지만 당시에는 큰 문제가 아니였는데

이유는 심플했다 

"사용자가 그걸 체감할만큼 인터넷이 빠르지않았고 많은 요청이 없었다" 

(나에게 이걸 알려준 사람은 IT업계를 발전시키는 방법은 개발자에게 로딩시간을 지연시켜 멍하니 화면 바라보게 하면 된다고 했다)

하지만 시대는 바야흐로 2023년이다.

많은 요청 더 빠른 속도 더 많은 처리 더 많은 응답을 갈구하고 있는 시대이다.

이를 개선시키고자 여러 시도가 있었으나 구조적인 문제(설계상 이슈)로 인해 크게 발전하지 못했고 결국 

이 문제는 HTTP 2.0이 등장하고 멀티플렉싱이라는 요청은 요청대로 응답은 응답대로 진행시키는 구조가 정착되며

해결되었다.

2. 절약 그리고 압축

1.1의 문제는 속도도 문제였지만 자원을 낭비하는 경향이 매우컸다.

그 원인은 두가지로 지목되었는데

첫번째는 모든 요청과 응답마다 헤더 정보를 중복해서 보내기에 문제가 되었고

두번째는 클라이언트가 요청하지 않은 자원을 서버에서 보내주는 경우가 문제를 일으켰다

첫번째는 우리가 이해할수있는 경우다. 그런데 아무리 돌이켜봐도 두번째는 이해할수없다.

두번째 경우에는 숨은 이유가 있다

1.1의 구조에서는 클라이언트가 서버에게 요청한 페이지와 함께 필요한 모든 파일들

(js,css 심지어 이미지까지!) 사용자가 보러갈지 말지도 모르지만 일단 주고 본다

아래를 보면 이것을 나타내는 용어가 adhoc이라는것을 알수있다

https://github.com/opentracing/opentracing.io/issues/158

이러한 불필요 자료(adhoc이라 부르는것들)는 분명 유용한 경우도 있었지만 대부분 그렇지 못했고

치명적인것은 이렇게 전달한것은 캐싱되지않은채 페이지를 떠나거나 이동하면 버려지고 새로 요청되는

악순환을 반복시켰고(개발자의 혈압도 오르게했다) 결국 2.0이 되면서

헤더 압축 그리고 서버 푸시 기능이 나오며 이러한 자원 낭비를 획기적으로 줄였다.

헤더 압축은 헤더 정보들(host,accept-language 등등..)을 텍스트에서 HPACK이라 불리는 압축방식으로

데이터를 인코딩하여 전달하는것이다. 표기상 50% 이상 줄이는데 성공했다는데...

예시를 한번 보고 넘어가도록 하자

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Safari/537.36

1.1은 이러한 형태의 청보들을 모두 담아 텍스트 형태로 전송하던것을...

\x0caccept\x1dtext/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8\x10accept-encoding\x0bgzip, deflate, br\x0faccept-language\x08en-US,en;q=0.5\x0fuser-agent\x86Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Safari/537.36

아래와 같이 인코딩하여 전달된다.

서버 푸시기능은 이름에서 알다시피 기존에 모든 파일이 전달되던것을 서버가

이 웹페이지에 필요한 자원들을 미리 클라이언트에게 보내서 웹페이지의 로딩속도를 개선시키는것이다.

마지막은 보안이다.

심플하다 여러분도 알고있다 http는 이제 1.1이다. https가 2.0이다

불철주야 SSL 혹은 TLS 인증과 싸우고 있는 사람들이 있다 

이 SSL/TLS가 1.1에서는 선택사항이였던것이 필수사항으로 변경되며 모든 통신이 암호화 되는 이점을 얻었다.

그리고 1.1에서 자주 악용되던 헤더 인젝션 공격이 있었는데 이를 통해 여러가지 악의적인 동작,개인정보 유출이

되는 취약점이였는데 2.0에는 이를 수정했다.

이로써 HTTP1.1과 2.0의 차이를 알아보았다.

도움이 되었길!