[면접 스터디] 프론트엔드 브라우저와 네트워크 그리고 렌더링 질문

 

친구들과 함께 모의면접 스터디 과제를 수행한다.

이번주 진행하는 기술 면접 주제는 아래와 같다.

1. 기술 면접을 위해 다음 키워드 공부해오기
- 브라우저 렌더링 과정 (CRP)
- URL 구조
- 주소창에 URL 입력 시 동작 과정
- http와 https
- 브라우저 저장소 (Local Storage, Session Storage, Cookie)
- CORS, SOP
- REST API
- SSR, CSR, SSG, ISR

2. (내가 뽑은) 인적성 면접 질문 2개 정리
- 공백기가 존재하는데 왜 발생했고, 공백기 동안 무엇을 했나요?
- 앞으로 성장해 나가며 3년 뒤, 본인만의 비전이나 성장 방향에 대해 말해주세요.

 

 

1. 기술 면접 키워드 공부

---

답변은 20초 답변을 기준으로 작성한다. 

1-1. 브라우저 렌더링 과정 (CRP, Critical Rendering Path)

브라우저 렌더링 과정은, 우선 웹 서버로 부터 HTML, CSS, JS 등 리소스를 로드하는 것으로 시작합니다. 브라우저 렌더링 엔진은 로드된 HTML, CSS을 파싱하여 DOM tree와 CSSOM tree를 생성하고, 이 두 tree를 결합하여 Render tree를 생성합니다. Render tree는 최종적으로 화면에 표시될 node와 스타일 정보를 포함하고 있습니다. 마지막으로 브라우저에는 Render tree를 이용해 계산된 크기와 위치에 맞게 화면에 Layout - Paint - Composite(합성) 세 단계를 거쳐 화면에 출력합니다.

1-2. URL 구조

인터넷에서 자원을 식별하는 문자열 표현 방식으로 URI, URL, URN이 있습니다. URI(Uniform Resource Identifier)는 자원을 식별하는 문자열이고 URL과 URN을 포함하는 상위 개념입니다. URL(Uniform Resource Locator)은 리소스의 위치를 나타내는 문자열이며 항상 리소스에 접근하는 프로토콜(http, ftp, mailto 등)을 포함하며 가장 구체적이며 정확합니다. URN(Uniform Resource Name)은 자원의 이름을 나타내는 문자열이며 특정 명명 체계를 사용합니다.

URL은 프로토콜, 도메인, 포트, 경로, 쿼리, 해시(또는 fragment)로 구성 되어 있습니다. URL은 웹에서 데이터를 찾기 위한 주소로, 웹 브라우저의 주소창에 입력하거나 링크를 클릭하여 접근할 수 있습니다.

URL 구조

1-3. 주소창에 URL 입력 시 동작 과정

웹 브라우저 주소창에 URL을 입력하면, DNS 프로토콜을 통해 URL에 매칭되는 IP 주소를 알아냅니다. 그리고 해당 IP 주소로 HTTP request를 송신하여, 서버로부터 웹 페이지 리소스를 수신합니다. 이후 브라우저는 리소스를 파싱하여 DOM tree와 CCSOM tree를 생성하고, 이를 기반으로 다시 Render tree를 생성하여 Layout - Paint - Composite 과정을 포함하는 렌더링 과정 수행하여 브라우저 화면에 웹 페이지를 출력합니다.

1-4. http와 https

[HTTP]

HTTP(HyperText Transfer Protocol)란 WWW(World Wide Web) 상에서 정보를 주고 받기 위한 통신 규약으로, 웹 브라우저와 웹 서버가 HyperText 문서나 이미지, 비디오 등의 리소스를 교환할 수 있습니다. HTTP의 핵심 특징에는 서버에서 클라이언트의 상태 정보를 저장하지 않는 무상태성, 서버에서 요청 응답 후 연결을 끊는 비연결성, 사람이 읽고 쓸 수 있는 구조와 언어로 되어 있는 단순성, 헤더에 새로운 필드나 새로운 HTTP 메서드 추가 할 수 있는 확장성이 있습니다.

 

[HTTPS]

HTTPS는 HTTP에 SSL/TLS라는 보안 계층을 추가한 프로토콜입니다. SSL/TLS는 통신 내용을 암호화하고, 상대방의 신원을 인증하며, 데이터의 무결성을 보장하는 기능을 제공합니다.

1-5. 브라우저 저장소

모두 key-value 스토리지 형태의 저장소입니다. 로컬 스토리지는 브라우저를 종료나 새로고침을 해도 유지되는 영구성을 가지고 있고, 세션 스토리지는 브라우저 세션(탭)이 유지되는 동안에만 유지되는 데이터 저장소입니다. 두 스토리지는  Storage 객체를 상속받기 때문에 메서드가 공통적으로 존재하며 도메인(프로토콜, 호스트, 포트)이 같으면 스토리지를 공유합니다. 브라우저나 기기별로 다르긴 하지만 모바일은 2.5 MB, 데스크탑은 5 ~ 10 MB 의 용량 제한을 갖습니다. 로컬 스토리지와 세션 스토리지가 나오기 (HTML5) 이전부터 브라우저 저장소 역할을 하던 쿠키는 만료기간이 있는 4 KB 용량의 저장소입니다. 로컬/세션 스토리지와 달리, 쿠키 데이터는 서버 (http) 요청 시 서버로 함께 자동 전송됩니다.

 

[Local Storage] window.localStorage

브라우저의 로컬 스토리지는 사용자 프로필이나 기본 설정 등과 같은 클라이언트 측에서 데이터를 저장하는데 이용할 수 있습니다. 로컬 스토리지의 특징으로는 브라우저를 종료해도 데이터가 유지됩니다. 로컬 스토리지에 저장된 데이터는 동일 도메인에서만 접근할 수 있습니다. 그렇기 때문에 악성 스크립트가 삽입된 공격(XSS, Cross Site Scripting)으로부터 잠재적 보안 위험을 가지고 있습니다. 이에 대한 대안으로 HttpOnly 플래그를 활성화한 쿠키로 저장하는 것이 좋습니다. HttpOnly 쿠키는 JavaScript 코드로 접근할 수 없으므로 XSS 공격에 안전합니다.

 

[Session Storage] window.sessionStorage

세션 스토리지는 동일한 도메인에 대해서만 접근할 수 있는 로컬 스토리지와 유사점이 있지만, 저장된 데이터는 브라우저 세션이 유효한 상태에서만 유지됩니다. 하지만 로컬 스토리지와 달리 브라우저(브라우저 탭)가 종료되면 세션 스토리에 저장된 데이터는 모두 삭제됩니다. 그렇기 때문에 세션 스토리지는 일회성 로그인이나 인증 토큰 등의 정보를 저장하는 데 사용됩니다.

 

[Cookie] document.cookie

쿠키는 클라이언트 측 브라우저에서 4 KB의 용량 제한을 갖는 저장소입니다. 처음부터 Http 요청의 무상태성을 보완하고, 서버와 클라이언트 간의 지속적인 데이터 교환을 위해 설계되어, 매번 서버 요청마다 서버 응답에 필요한 클라이언트 정보를 쿠키에 담아 전송합니다. 서버는 쿠키를 읽고 클라이언트가 누군지 파악합니다. 쿠키는 일반적으로 사용자 식별, 개인 설정, 장바구니 등의 정보를 저장하는 데 사용됩니다.

res.cookie('accessToken', accessToken, { httpOnly: true, secure: true, sameSite: 'Strict' });
res.cookie('refreshToken', refreshToken, { httpOnly: true, secure: true, sameSite: 'Strict' });

1-6. CORS, SOP

[CORS]

CORS(Cross-Origin Resource Sharing)란 웹 애플리케이션이 다른 출처의 리소스에 접근할 수 있도록 브라우저와 서버가 협력하는 방식입니다. 브라우저는 XMLHttpRequest나 Fetch API와 같은 웹 통신 API를 사용하여 교차 출처 요청을 보냅니다. 이때 요청 헤더에 protocol과 host(hostname, port)를 포함하는 Origin 필드에 허용을 희망하는 출처를 담습니다. 서버는 요청에 대한 응답 헤더에 Access-Control-Allow-Origin 필드에 허용하는 출처를 담아 보냅니다.

클라이언트 측에서 발생할 수 있는 CORS Error는 보안을 위해 동일 출처 정책(SOP, Same Origin Policy)를 따르는 브라우저에서 교차 출처 요청을 제한하기 때문에 발생합니다. CORS Error의 대처는 서버 측에서 허용하는 Origin, 메서드, 헤더 등을 응답 헤더에 명시해 주는 것 입니다. 우회하는 방법은 프록시 서버를 사용하거나 JSONP(JSON with Padding)와 같은 기법이 있습니다.
* JSONP: CORS 정책의 제약을 받지 않는 HTML scrip 태그에 JSON 데이터를 콜백 함수로 감싸서 전달한다.

URI 내 Origin

* 출처: minukang Velog, https://weniv.link/YGCJJ1

1-7. REST API

REST API는 클라이언트와 서버 간의 통신 방식을 정의한 REST(REpresentational State Transfer) 아키텍처 스타일을 따르는 웹 API입니다. 이 중에 REST 아키텍처 스타일을 완벽하게 준수하는 API의 경우 RESTful API라고 부릅니다. REST 아키텍처는 프로토콜이나 표준이 아니라 제약 조건이기 때문에 필요에 따라 다양한 방식으로 구현할 수 있습니다.

REST API의 주요 특징은, HTTP 요청을 통해 클라이언트와 서버 간에 리소스를 주고 받을 수 있습니다. 리소스는 JSON, XML, HTML 등의 다양한 방식으로 표현될 수 있고, URI(Uniform Resource Identifier)로 식별됩니다. REST API는 상태가 없으므로 각 요청이 독립적이고 자기 서술적인 특징을 가집니다. 또한 캐싱, 계층화 시스템, 주문형 코드(Code on Demand) 등의 특징을 통해 시스템의 성능과 확장성을 향상할 수 있습니다.

1-8. SSR, CSR, SSG, ISR

[CSR, Client Side Rendering]

CSR은 클라이언트 측에서 페이지를 렌더링하는 방식입니다. 브라우저 렌더링 엔진이 웹 서버로부터 받은 HTML, CSS, JavaScript 등의 리소스를 사용하여 페이지를 생성합니다. 브라우저 중심의 동적 페이지 처리 및 관리 방식으로, SNS나 대화형 웹 애플리케이션과 같이 사용자 인터랙션에 따른 실시간 페이지 갱신에 유리합니다. 이를 통해 더 나은 사용자 경험을 제공할 수 있으며 반응형 디자인이 가능합니다. 또한 브라우저에서 렌더링을 처리하기 때문에 SSR에 비해 서버 요청 최소화로 서버 부하가 감소합니다.

단점으로 웹 서비스의 크기와 복잡성에 비례해 초기 로딩 시간 지연되며 SEO 최적화에 어려움이 있습니다.

대표적인 CSR 프레임워크 및 라이브러리로 React.js, Anguar.js, Vue.js 가 있습니다.

 

* 브라우저 엔진의 종류

• Blink Engine (Chrome, Opera, Samsung Internet, MS Edge, Whale, Brave)
• WebKit Engine (Safari)
• Servo Engine (Firefox), Gecko Engine (Firefox)

[SSR, Server Side Rendering]

SSR은 서버에서 페이지를 미리 렌더링하여 완성된 HTML 페이지를 클라이언트 측 브라우저로 전송하는 방식입니다. 특히 매 사용자 요청 시 마다 페이지를 새롭게 렌더링 하므로 Fetching 하는 데이터가 비번하게 변경될 때 사용합니다. 서버 중심의 페이지 생성 및 관리 방식으로, CSR에 비해 초기 로딩 속도가 빠르며 검색 엔진이 쉽게 크롤링하고 색인 생성이 가능하여 SEO 최적화 효과를 갖습니다.

주로 대형 eCommerce 사이트나 뉴스 포털 사이트, 블로그 플랫폼에 유리합니다.

단점으로는 페이지 이동 시 새로고침되어 화면이 깜빡이고, 동적 상호작용의 제한과 서버 과부하로 사용자 경험의 질이 떨어질 수 있습니다.

대표적인 SSR 프레임워크로는 Next.js(React), Nuxt.js(Vue)가 있습니다.

 

[SSG, Static Site Generation]

SSG는 클라이언트가 요청하는 시점이 아닌, 빌드 시점에서 페이지를 모두 미리 생성해 두었다가 페이지를 요청 받으면 완성된 파일을 반환하는 방식입니다. SEO 최적화가 필요하고 업데이트를 거의 하지 않아도 되는 위키나 블로그와 같은 서비스에 적용할 수 있습니다. Next.js에서 페이지 생성 시 렌더링 방식의 기본 설정입니다.

 

[ISR, Incremental Static Regeneration]

ISR은 SSR과 SSG의 단점을 보완한 방식으로, SSG와 마찬가지로 빌드 시점에 페이지를 모두 만들어 두지만, 설정된 주기에 따라 페이지를 재생성하여 업데이트된 데이터를 반영하는 방식입니다. 그렇기 때문에 SSG는 빌드 시에 페이지를 생성하기 때문에 fetching 데이터가 변경되면 다시 빌드해야 하지만 ISR은 일정 시간마다 알아서 페이지를 업데이트 해줄 수 있습니다.

2. 인적성 면접 질문

---

2-1. 공백기가 존재하는데 왜 발생했고, 공백기 동안 무엇을 했나요?

[공백기 존재 이유 - 역량 확보]

해당 공백기는 프론트엔드 개발자로 본격적인 커리어 전환을 위해 전문교육 이수 및 전문성 확보를 위한 시간을 투자했습니다.

[공백기 동안 활동 - JD분석 결과 우대 항목을 어필]

공백기 동안 지원한 직무에 필요한 역량 및 경험을 확보했습니다. 대표적인 최신 버전의 프레임워크, 차트/애니메이션 UI 인터렉션 역량을 확보했고, 오픈소스 프로젝트 기여 경험을 확보했습니다.

 

2-2. 앞으로 성장해 나가며 3년 뒤, 본인만의 비전이나 성장 방향에 대해 말해주세요.

저는 프론트엔드 개발자로써 3년차 그리고 5년차 비전을 가지고 있습니다.

[3년차 비전 - 주니어]

3년차 비전은 차트 UI 인터랙션에 전문성을 가진 프론트엔드 개발자입니다. 실시간으로 분석 데이터를 조회할 수 있는 다양한 형태의 차트 UI를 실무에 적용하고, 실무 데이터에 적절한 새로운 형태의 차트 UI를 개발할 수 있는 개발 역량 향상이 목표로 하고 있습니다.

 

[5년차 비전 - 시니어]

5년차 비전으로는 AI 웹 앱 UI 인터랙션 개발에 전문성을 가진 프론트엔드 개발자입니다. 현재도 다양한 LLM 이 만들어지고 있는데요. 사용자가 필요한 언어 모델을 플러그인 형태로 바꿔가면 쓸 수 있는 웹 서비스에 특화된 UI와 인터랙션을 개발하고자 합니다. 이를 위해서 꾸준한 학습과 사이드 프로젝트를 진행하며 관련 역량을 확보할 계획입니다.

 

 

 

 

 

참고 1. 눈떠보니 기술 면접 전날 with JS, Python - Ridi Books

참고 2. 로컬 스토리지, 세션스토리지 - 제로초 블로그

참고 3. [Next js] SSR, SSG, ISR 이해하기 - 안광의 Velog