6주차를 마치며..

회사를 퇴사한지 6주, 동시에 코드스테이츠의 블록체인 개발자 교육 6주차 수업이 끝낫다. 이번주에는 http/네트워크의 개념이해와 section.1에서 배운 react와 node js를 연결지은 실습 등이 진행되었다. http와 네트워크 분야는 컴퓨터 공학과가 아닌 이상 접해보기 힘든 개념이므로 다소 생소한 부분에 어려움을 느꼈다. react부분이야 뭐... 나에겐 너무나 중요한 부분이므로 열심히 했다. 핵심은 fetch를 이용하여 얻고자하는 정보를 uri를 이용하여 서버에 요청하고 받는 방법, 즉 요청과 응답의 과정을 postman으로 확인해가며 실제 프론트엔드, 백엔드 개발자 간의 업무 진행을 조금이나마 옅볼 수 있는 수업이었다. 나름대로는 전체적인 그림을 이해하고보니 어려운 개념은 아니었다. 추가적으로 배운 node js를 이용하여 마치 내 로컬 pc에 서버가 존재하는 것 마냥. 내가 직접 요청하고 정보를 받는 작업을 해볼 수 있었다. 신선했으나 이 과정에서 진행해본 백엔드 적인 개념이 나에게 맞는지는 아직까지 모르겠다. 확실히 눈에 보이는 프론트엔드가 나에게 조금 더 흥미를 주는 것 같기도 하다. 여전히 매일 아침 1시간씩 진행되는 toy(알고리즘 문제풀이)는 쉽지 않다. 대체 내가 이것을 왜 해야하는가?에 대한 의문이 들기시작하여 찾아보았다. 많은 고급진 회사들이 요구하는 역량중에 하나였다. 다양한 알고리즘 예제들이 코드 테스트에서 사용되는 것으로 보여진다. 이에, toy난이도는 아직 어려우니 나름대로의 학습 방법으로 https://programmers.co.kr/ 프로그래머스라는 사이트에서 제공하는 알고리즘 예제 풀이다. 난이도가 존재하며, 내 수준과 다양한 난이도의 알고리즘 문제를 접해보기 위해서 찾아낸 사이트다. 이제는 하루에 한문제 이상은 꼭 풀이를 해가며 차후 알고리즘을 풀어내야할 시기가 닥쳤을 때를 대비하고자 한다. 우선 6주차 후기는 여기까지하고 이번주에 기억하고 넘어가면 좋을 내용들을 정리해보고자 한다.

includes 메소드

이번 주 스프린트를 진행하면서 사용했던 메소드이다. 이전에 진행한 toy 예제에서도 언급된 메소드이기도 했고, 종종 알고있으면 요상한 알고리즘을 접했을 때, 해결책이 될 것 같아 블로깅해보고자 한다.
str.includes(검색 문자, [검색 할 위치])
작성법은 위와 같다. str에 작성된 문자열 중에, 검색할 문자가 포함되어 있는 경우와 그렇지 않은 경우를 구분하여 treu와 false로 반환한다. 유의할 점은 대소문자를 구분한다는 점이다. 아래 예시를 보면 이해에 도움이 될 듯 하다.

let str = My name is kimcoder

let a = str.includes(My)
let b = str.includes(my)
let c = str.includes(is)

console.log(a)   --> false
console.log(b)   --> true
console.log(c)   --> true

검색 할 위치의 경우는 어떻게 쓸까? 아래 예씨를 보면서 이해해 보자.

let str = aaa bbb ccc

let a = str.includes(a, 2)
let b = str.includes(a, 5)
let c = str.includes(a, -1000)

console.log(a)   --> true
console.log(b)   --> false
console.log(c)   --> true

검색할 위치는 생략이 가능하지만 만약 내가 원하는 위치부터 해당 단어의 존재 유무를 확인하고 싶다면 위처럼 작성하여 사용할 수 있다. 위에서 a변수는 a라는 문자가 2번 인덱스부터 끝 인덱스까지 존재하므로 true를 반환하고 b변수에 a라는 문자열은 5번 인덱스부터 존재하지 않으므로 false를 반환한다. 변수 c의 경우는 범위가 음수로 작성되었는데 이는 검색할 위치를 생략한 조건과 동일하다고 보면 되므로, 모든 인덱스에서의 a문자의 존재 유무를 확인한다. 결과적으로 true를 반환한다.

SSR과 CSR의 차이를 이해하자

ssr은 server side rendering으로 웹 페이지를 브라우저에서 렌더링하지 않고, 서버에서 렌더링 하는 것을 말한다. csr은 client side rendering으로 단순하게 ssr의 반대 개념이다. 이는 서버에서 렌더링 하는 경우 비교적 늦은 반응 속도와 사용자와의 잦은 상호 작용이 존재하는 웹페이지의 경우 강점을 보인다. 다만 최대의 단점으로 꼽히는 것이 바로 seo, 검색 약속에 불리하다는 것이다. 우리가 많이들 사용하는 구글은 강력한 검색 엔진을 자랑하는 만큼 많은 검색 소비자들이 존재하는데, csr을 사용하는 경우 이런 seo 방식에 매우 취약함을 보이기 때문이다. 결과적으로는 ssr, csr 모두 필요한 개념이며 우리 개발자들은 이를 유두리있게 선택하여 사용해야할 것이다.

cors 이해하기

Cross Origin Resource Sharing의 약자다. 매번 느끼지만, 약자만 봐서 바로 직역이 되는 것들은 생각보다 그리 많지는 않은 것 같다... cors도 나한테는 그런 존재였다. 아니 사실은 강의를 들었을 때에도 도무지 이게 뭔지 무엇을 하기 위해서 내가 이 개념을 배워야하는지 확신이 없었다. 그래서 유튜브를 뒤져보았다.
https://www.youtube.com/watch?v=bW31xiNB8Nc 현재로써는 나한테 가장 쉽게 이해시켜준 영상이어서 이렇게 남겨본다. 그리고 영상을 본 이해를 바탕으로 나 나름대로의 풀이를 끄적여 본다면, 단순하게 cors는 http의 요청과 응답 과정에서 요청자의 불순한 의도가 요청에 담겨 해킹으로 이어지는 일을 막기위한 조치라고 이해했다. 그럼 이를 어떻게 막을 것인가?에 궁금증이 생길텐데 일단 가장 중요한 기준은 origin, 즉 출처의 개념이 빠질 수 없다. 그리고 우리가 이전에 배운 url의 개념 안에는 이 출처처럼 사용되는 개념이 들어간다. 이는 http://www.naver.com 이라고하는 프로토콜, 도메인, 생략된 포트번호라고 볼 수 있다. 그리고 이전에는 이 출처를 이용하여 일명 sop 정책을 통해 동일한 출처가 아니면 요청을 보낼 수 없도록하는 것이 있었다. 하지만 수많은 api의 출현으로 개발자들은 이를 우회하는 방법을 선택해왔고, 누군가는 이러한 우회방법이 없어도 되는 새로운 약속이 필요하다고 생각했다. 그렇게 생겨난 것이 cors이다. 그럼 조금 이해가 쉬울수도 있는데 cors는 sop에 의해 막히게 되는 요청을 몇 가지 약속만 지키면 풀어주겠다라는 것과 같다. 그리고 이러한 검사 과정은 클라이언트 또는 서버가 하는 것이 아니라 브라우저가 진행한다.
즉 브라우저는 이 출처를 가지고 http 헤더에 요청자의 출처를 담아보내고, 서버는 헤더에 담긴 출처를 확인하여 자신들이 허용한 출처일 경우 이에 대한 답을 다시 헤더에 담아 보내는 방식을 취한다. 그리고 이를 확인한 브라우저는 요청자에게 요청한 리소스를 넘길 수 있다. 그리고 이 과정을 우리는 cors로 이해할 수 있다. 물론 cors에 좀 더 깊게 이해하고자 한다면, 단순 요청과, 프리플라이트 요청에 대해 공부할 필요가 있다.