[멋사 FE 스쿨] 35일차 리뷰

멋쟁이사자처럼 프론트엔드스쿨 w/ 제주코딩베이스캠프 35일차

---

오전(09:00~11:50) 수업 w/ Wade

오늘은 모의 면접 수업

SOP란?

Same Origin Policy → 리소스가 서로 상호작용하지 못하도록 하는 것

태그를 통해 불러오는 것은 embedding이라고 한다.

외부 페이지에서 불러오는 iframe등의 document는 null로 반환. 접근 할 수가 없다. 이것이 SOP

동일한 리소스에 관해서만 상호작용이 가능하다.

CORS란?

access-control-allow-origin →자원을 공유해달라는 요청에 대한 응답으로 서버에서 공유할 지 안할지를 결정해서 알려주는 것

응답 헤더는 Back에서 Client에 준다.

그래서 CORS Error라는 것이 많이 발생한다. → 해법은? 서버에서 허용을 해줘야한다. BE에서 api 주소를 주면 어떤 형태의 데이터인지 알려줄 것. 사전에 약속을 할 것. 그런데 CORS 에러가 난다면 응답 헤더(response headers)에 Access-Control-Allow-Origin 값이 들어가 있는지 문의할 것

https://ui8.net/

카카오지도 가져온 것은 CORS랑 상관이 왜 없을까? → head에 script로 설정해주어서 → 이렇게하면 sop, cors 정첵에 위배되지 않는다.

cors는 브라우저가 발생시키는 에러

401등은 서버가 보내주는 에러

---

오후(13:00~18:00) 수업 w/ Wade

이해하고 정리한 내용 면접 연습을 반드시 해야한다.

브라우저가 웹 페이지를 랜더링하는 과정?

질문주신 브라우저 렌더링 과정은 크게 4단계로 나누어 설명 드릴 수 있을 것 같습니다 로 화두를 던지고

1.1 HTML 코드가 DOM 트리로 변환 → 1.2 외부 CSS 파일 코드가 CSSOM 트리로 변환 → 2. 렌더링 트리 생성(이 과정에서 페이지 렌더링에 필요한 노드만 포함) → 3. Layout 단계 → 4. 자리 잡힌 Layout에 페인팅 단계

좋은 답변

• 브라우저 렌더링 과정은 우선, 사용자가 페이지에 접속하고 HTML을 서버에서 내려받게 되면 이를 브라우저 렌더링 엔진에서 파싱(처리)합니다. 이렇게 "DOM 트리"를 만들고, link 태그를 통해 CSS 파싱을 해서 "CSSOM 트리"를 만듭니다. DOM 트리와 CSSOM 트리를 결합한 것이 "렌더 트리"가 되고, 레이아웃 작업을 통해 사용자에게 그려줄 영역을 계산해서 화면에 뿌려줍니다. 이 과정을 진행하다가 자바스크립트 런타임 환경에 수행권한을 넘겨 결과 값을 받으면 DOM 파싱은 중단됩니다. 모든 노드 수치를 재계산해서 렌더 트리를 재생성하는 과정을 "reflow"라 하고, 이후 재생성된 렌더 트리를 다시 그리는 것을 "repaint"라 합니다. 리페인트는 레이아웃 수치에 영향을 끼칠 때만 진행됩니다.

css에도 부모 자식 관계가 있다.

1. 파싱 2. 스타일 계산 3. 레이아웃 4. 페인트 5. 컴포지팅

GET 방식, POST 방식에 대해 설명?

→

GET과 POST는 HTTP 메서드로, 클라이언트에서 서버로 무언가를 요청할 때 사용합니다.
GET 은 클라이언트에서 서버로 어떠한 리소스로부터 정보를 요청하기 위해 사용되는 메서드입니다. 예를 들면 게시판의 게시물을 조회할 때 쓸 수 있습니다. GET을 통한 요청은 URL 주소 끝에 파라미터로 포함되어 전송되며, 이 부분을 쿼리 스트링(query string)이라고 부릅니다. 방식은 URL 끝에 "?" 를 붙이고 그다음 변수명1=값1&변수명2=값2... 형식으로 이어 붙이면 됩니다.
POST는 클라이언트에서 서버로 리소스를 생성하거나 업데이트하기 위해 데이터를 보낼 때 사용 되는 메서드입니다. 예를들면 게시판에 게시글을 작성하는 작업 등을 할 때 사용할 됩니다. POST는 전송할 데이터를 HTTP 메시지 body 부분에 담아서 서버로 보냅니다. GET에서 URL 의 파라미터로 보냈던 name1=value1&name2=value2 가 body에 담겨 보내진다 생각하시면 됩니다.

GET, POST 둘 다 HTTP 프로토콜을 이용해서 서버에 무엇인가를 요청할 때 사용하는 방식입니다. 하지만 둘의 특징을 제대로 이해하여 기술의 목적에 맞게 알맞은 용도에 사용해야합니다.

우선 GET 방식은 요청하는 데이터가 HTTP Request Message의 Header 부분에 url이 담겨서 전송됩니다. 때문에 url 상에 ? 뒤에 데이터가 붙어 request를 보내게 됩니다. 이러한 방식은 url이라는 공간에 담겨가기 때문에 전송할 수 있는 데이터의 크기가 제한적입니다. 또 패스워드와 같이 보안이 필요한 데이터에 대해서는 데이터가 그대로 url에 노출되므로 GET방식은 적절하지 않습니다. GET은 서버에서 어떤 데이터를 가져와서 보여주는 용도이지 서버의 값이나 상태를 변경하니 않으며 SELECT적인 성향을 갖습니다.

POST 방식의 request는 HTTP Request Message의 Body 부분에 데이터가 담겨서 전송됩니다. 때문에 바이너리 데이터를 요청하는 경우 POST 방식으로 보내야 하는 것처럼 데이터 크기가 GET 방식보다 크고 보안 면에서 더 좋습니다. GET과 달리 서버의 값이나 상태를 변경, 추가하기 위해 사용됩니다.

부수적으로 GET방식은 브라우저에 Caching할 수 있어서 기존에 Caching되었던 데이터가 응답될 가능성이 있으므로 보안상 문제 이외에도 목적과 용도에 맞게 GET/POST를 적절히 사용해야 합니다.

멱등성

GET과 POST는 HTTP프로토콜을 이용해서 서버에 무언가를 전달할 때 사용하는 방식입니다.
GET방식은 클라이언트에서 서버로 데이터를 전달할 때, 주소 뒤에 key와 value가 결합된 쿼리 스트링 형태로 전달됩니다. 주소창에 쿼리스트링이 그대로 보여지기 때문에 보안성이 떨어집니다. 길이에 제한이 있으므로 전송 데이터의 한계가 있습니다. POST 방식보다 상대적으로 전송 속도가 빠릅니다.
POST방식은 일정 크기 이상의 데이터를 보내야할 때 사용합니다. 서버로 보내기 전에 인코딩하고, 전송 후 서버에서는 다시 디코딩 작업을 합니다. 주소창에 전송하는 데이터의 정보가 노출되지 않아 GET방식에 비해 보안성이 높습니다. 전송 속도가 GET방식에 비해 느리며 쿼리스트링 데이터 뿐만 아니라 라디오 버튼, 텍스트 박스 같은 객체들의 값도 전송이 가능합니다.
GET,POST방식의 차이는, Get은 주로 웹 브라우저가 웹 서버에 데이터를 요청할 때 사용하고, 웹 브라우저에서 웹 서버로 전달되는 데이터가 인코딩되어 URL에 붙습니다. Post는 웹 브라우저가 웹 서버에 데이터를 전달하기 위해 사용하고, 전달되는 데이터가 보이지 않습니다. 웹 서버에 많은 데이터를 전달하기 위해서는 Post방식을 사용하는 것이 바람직합니다

• GET, POST
• 굳이 공개가 되어도 상관 없다 하면 get 방식 이용
• ajax로 get 방식 데이터 요청 때는 따로 query string으로 쓰이지 않는다.
• get → 요청하는 사람이 소리를 쳐서 알려주는 것
• post → 메모지에 적어서 전달하는 것
• GET - 만나서주문
  POST - 앱으로 주문
• post 방식으로 form 하면 payload로 쏴준다

우리 회사에 입사한다면 어떤 기여를 할 수 있다고 생각 하나요?

→

코드를 짜고 반복을 줄이고 리팩토링하는 일 자체에서 즐거움을 느낍니다. 그렇기에 현재 사내 존재하는 레거시 코드와 같이 개선이 필요한 코드를 살펴보고 수정 계획을 수립하겠습니다. 또한 계속해서 선임 분들께 조언을 구하고 아이디어를 제안 드리며 수정해나가겠습니다.

개발자는 결국 코드로 소통한다고 생각합니다.

일례로 semantic한 markup 작성을 통해 보다 더 분명한 html로 만들겠습니다.

유지보수하기에 좋은 깨끗한 코드를 작성할 것입니다. 다고 생각하지만 저에겐 하나의 즐거움이기 떄문에 기존

강사님 피드백

회사의 기여보다는 1인분 하겠다는 말은 별로
본인 능력치 올리겠다는 말에 치중이 된다면 좀 별로
당연히 해야할 얘기들을 하게 되면 애매하다

모든 신입이 가지는 속성과 관련된 이야기는 지양하자

회사의 서비스를 많이 사용하고 있는데 불편했던 부분에 관해서 이야기하고 개선 방향까지 이야기해보면 좋다.

본인을 너무 낮추는 것은 지양하도록 하자.

모자라다는 뉘앙스의 표현을 안하면 좋겠다.

조은님 제안

제가 쓰는 서비스인데 불편한 점을 몇가지 느꼈고, 그 불편한 점은 이런 것들인데 나의 주관이 아니라 객관적으로도 불편한 점이라 생각. 이 부분을 내가 개선해줄 수 있다. 나는 킹갓제너럴엠퍼러 충무공 개발자다

1. 원활한 커뮤니케이션

2. 어떻게든 일을 하겠다

'코딩에 열정이 있다'

‘나는 UI / UX 에 관심이 있다'

솔직히 필요 없는 말

면접 등 자기 어필에서 갖춰야할 태도

1. 본인을 낮추는 것은 지양
2. 구체적으로 어떻게 기여할 것인지 말하기
3. 적응할것이다 -> 빼기 당연한 말 / 어떻게 기여할 것인가가 질문의 요지
4. 본인의 강점 어필
5. 원활한 커뮤니케이션 -> 빼기
6. 구체적인 나의 강점 경험을 통해 어필

회사 서비스 반나절만 훑고 가도 티가 난다

당연한 얘기 하지 마라

어떤 서비스, 어떤 보완점

기여할 수 있는 것은 두가지다 이런 식으로 구체적으로 이야기해보면 좋다.

본인의 강점을 어필 할 수 있는 부분으로

자신감 중요하다 제발 자신의 단점을 말하지 말라

section 요소와 article 요소의 사용 용도에 대해 설명해 주세요.

→ 질문 주신 section 요소, article 요소 둘 다 html 내에서 한가지 구획을 가진다고 할 수 있겠는데요. 특별히 article은 독립적으로도 사용될수 있는 콘텐츠들을 담고 있을 경우 사용되고, section은 서로 연관된 내용으로 이루어진 콘텐츠들을 묶어줄 수 있습니다.
html 학습 초기에 저에게는 section이 더 포괄적인 의미로 사용된다고 생각해 서로 종속적인 관계로 오해했습니다. 하지만 다른 페이지들의 코드를 살펴보고 semantic한 markup 작성에 대해 더 고민하다보니 서로 종속적인 관계라 보기는 무리가 있다는 것을 깨닫게 되었습니다. 그 후로는 구현하고자 하는 페이지의 의미에 맞게 서로가 서로 안에 즉, article이 section 내부로 또는 section이 article 내에 사용하고 있습니다.

다른 수강생들 좋은 답변

• 은 대부분의 경우 제목이 있으며, **'구체적인 의미론적 요소가 없는'** 일반적인(포괄적인) 독립 섹션을 나타냅니다. 시멘틱 웹의 관점에서

  은 이를 나타내는 **더 구체적인 요소가 없는 경우에만** 사용해야합니다! 이 때, 더 구체적인 의미론적 요소가 있을 때 사용하는 것 중 하나가

  입니다. 요소의 콘텐츠가 독립적으로 배포되거나 재사용되도록 의도된 게시물, 댓글, 기사 형태 등의 단위일 때

  을 사용합니다.

CSS Sprite기법에 대한 정의와 장단점에 대해 설명해주세요.

→ html에서 img를 가져올 경우 이미지를 로딩하는 시간이 필요한데, 여러 img 태그에서 각자의 이미지 파일을 가지고 있다면 매번 새로운 파일을 로딩하게 됩니다. 하지만 css sprite를 통해서 여러 이미지로 나뉘어 저장될 수 있는 파일들을 하나의 파일로 묶어주어 한번의 로딩만으로 여러 태그에서 사용할 수 있어 로딩 속도를 개선하는 장점이 있습니다. 하지만 오히려 너무 많은 이미지가 들어가 용량이 커지는 경우 처음 화면 로딩시 시간이 너무 오래걸릴 수 있다는 단점을 말씀드릴 수 있습니다.
하나의 이미지 요소 크기가 변경되면 위치값을 재조정해야하기 때문에 잦은 수정이 있는 이미지는 sprite를 사용하지 않는 것이 좋습니다.

형상관리도구(버전 관리 시스템)에 대해 전반적인 설명을 해주세요.(주 사용 도구도 서술해주세요.)

→ 형상관리 도구에서 가장 유명하다고 생각하는 git을 통해 말씀드리겠습니다. 주로 git과 github을 통해 관리하고 있기도 합니다. 형상관리도구는 특정 시점에 작성되어 있는 소스코드 등의 프로젝트를 기록함으로써 유지 관리하는 시스템입니다.

하나의 블로그 글처럼 잘 정리해주신 글

• 형상관리란 한마디로 개발과정의 시작부터 끝까지 변하는 모든 사항을 관리하는 작업이라고 할 수 있습니다.
  많은 사람들이 개발자라면 형상관리 도구를 프로젝트에 필수적인 도구라 해서 사용하고 있지만 그 필요성을 제대로 알고 있는 사람은 많지 않을 것입니다.
  git이나 svn을 사용해보면 알 수 있듯이 단순히 말하자면 변경사항을 체계적으로 관리하는 것이라고 알 수 있습니다.
  소프트웨어 공학론을 공부하지 않는 이상 깊게 알기란 쉽지 않았지만 멋쟁이 사자처럼 부트캠프에서 공부했던 내용이기에 이렇게 깔끔하게 말씀드립니다.
  형상관리의 장점

1. 소스코드의 변경이력을 관리할 수 있어서 추적성이 높습니다.
2. 배포가 편리합니다.
3. 여러 사람이 동일한 소스코드를 공유해 개발할 수 있으며 공유할 때 생기는 버전 충돌 문제 등을 스무스하게 해결할 수 있습니다.
4. 기능상 필요하거나 장애가 생길 시 이전 버전이나 Baseline으로 소프트웨어를 되돌릴 수 있습니다.
   형상관리를 왜 사용할까요?
5. 가시성의 결핍 : 소프트웨어는 무형물이기 때문입니다.
6. 통제의 어려움 : 눈에 보이지 않는 상품의 제작은 통제하기 어렵기 때문입니다.
7. 추적의 어려움 : 프로젝트의 중간 목표들을 연결시키고 개발과정을 추적하기 어렵기 때문입니다.
8. 감시의 미비 : 가시성과 추적성의 결핍은 프로젝트의 진행을 감시하기 어렵게 합니다.
9. 무절제한 변경 : 통제되지 않고 관리되지 않는 소프트웨어의 무절제한 변경이 발생하기 때문입니다.

alt와 title의 차이에 대해서 설명해 주세요.

→ alt는 img 태그등의 “속성”으로 검색 엔진 등이 이해할 수 있도록 적어주는 중요한 text 입니다. 그렇기에 SEO에도 도움이 됩니다. 또한 대체텍스트의 역할로 스크린 리더가 읽어줄 수 있도록 웹 접근성에서 아주 중요한 역할을 합니다.

title 속성은 마우스 hover시 띄워주고 싶은 text를 적어줄 때 사용합니다.(tooltip) alt 만큼의 중요도를 가지고 있다고 보여지지는 않습니다. 보조적인 내용의 텍스트입니다.

프론트엔드 관련 공부는 어떻게 진행하고 계신가요?

이건 왜 물어볼까 어떤 사람인지 보려고. 진짜 FE에 뜻이 있는지 보고 싶어서. 성장가능성이 있나없나는 회사입장에서는 중요하지 않다. 회사에서도 계속 공부한다. 사내 스터디를 많이 한다. 컨퍼런스 진행도 많이 하고
우리회사에 입사하면 어떤 기여를 할 수 있나? 와 같은 질문
회사는 개인이 혼자 공부하기를 원하지 않는다. 지식을 적극적으로 공유하고 다른 직원들에게 자극을 주는 사람을 원한다. 다른 사람들과 공부를 하는지. 한다면 어떻게 하는지에 관심을 두고 볼 것
이런 질문은 항상 회사의 입장에서 생각해봐라

→ html, css 같은 경우 라인 채용 홈페이지, 참여했던 멋쟁이사자처럼 부트캠프에서 주어진 피그마 과제를 통해 스스로 구현해보는 과정으로 숙련도를 올리고 있고, JS 버

좋은 조언들

스터디를 꾸리는데, 스터디 운영하는 방법을 개선하면서 변화를 주도했다.

연봉 협상 때는 일을 얼마나 열심히 했느냐가 중요한 게 아니다. 열심히 하는건 당연한 거여서

주어진 미션보다 뭔가를 더 붙여야한다. 시킨 것만해서는 연봉이 오르지가 않는다. 플러스 알파가 중요하다. 개인의 경쟁력이 될 것