여러가지 활동/프리온보딩 프론트엔드 챌린지

프론트엔드의 React와 채용 과정 알아보기

홍수성찬 2024. 8. 15. 22:22

2024년 8월 프론트엔드 챌린지 간단 요약

 

  • Turn Over: 정원

T/O가 발생하는 이유는 기존 직원이 퇴사하거나, 신규 서비스 런칭으로 인해 신규 채용이 발생하는 경우입니다.

 

T/O에 따라 필요한 사람이 다릅니다.

  • 결원발생
    • 이전 사람과 비슷한 연차, 비슷한 연봉, 비슷한 실력
    • 팀에서 사용중인 Skill Tree를 벗어나지 않는 경우
    • 대부분 경력직 채용
  • 신규
    • 연차, 연봉에 비교적 자유
    • 많은 T/O를 가지고 있기 때문에 비교적 쉬운 도전

 

채용공고에서 '지원 자격', '우대 사항'과 관련되어 최대한 필요한 내용을 담으려고 노력해야 합니다.

 

주니어 지원자격에서의 프론트엔드 기술력은 다음과 같습니다.

  1. 최소한의 경력으로 작은 경력이어도 괜찮습니다.
  2. 팀에서 사용하고 있는 기술스택에 대한 기술력을 갖추고 있으면 좋습니다.
  3. 개발에 대한 진심, 회사에 대한 진심의 마인드를 갖춰야 합니다.

 

우대사항도 필수항목입니다.

가산점을 받을 수 있는 항목들이며, 반드시 갖춰야하지 않아도 되지만, 팀에서 사용중인 내용들입니다.

  1. 팀내 기술 스택을 배경으로 하는 경험이나 프로젝트가 있으면 좋습니다.
  2. 서버, 인프라 등 프론트엔드 개발 외 추가적인 기술 스택을 갖추고 있으면 좋습니다.
  3. 피그마, 지라 등 커뮤니케이션 스킬의 소프트 스킬을 갖추고 있으면 좋습니다.

 

이력서

이력서에서 중요한 것은 'Impact(임팩트)' 입니다.

눈길을 사로잡는 첫 문장, 좋은 회사에서의 경력, 좋은 프로젝트 경험을 잘 담아야 합니다.

 

눈길을 사로잡는 첫 문장으로 개발자가 된 계기, 회사에 지원하게 된 동기, 나의 핵심 역량을 담으면 좋습니다.

예를 들어, "첫사랑은 자바스크립트, 짝사랑은 리액트, 현재는 NextJS와 열애중인 지원자 ~입니다."

"복잡한 기술에 대응하는 챌린지적 요소를 좋아하는 개발자입니다."가 있습니다.

 

클리셰나 모호한 표현, 남들과 비교하는 표현, 자신감이 없는 표현은 삼가해야 합니다.

예를 들어, "저는 만 2년 만에 연봉 ~원을 달성하여 역량을 보여준 지원자 ~입니다.", "저는 어디서든 잘 녹아드는 사람이라고 생각합니다.", "저는 어려서부터 UI/UX와 프론트엔드 개발을 좋아해온 지원자 ~입니다."가 있습니다.

 

학력은 개발자 관련 내용이 아니더라도 모든 학력 사항은 기재해야 합니다. 지원자의 배경을 알아야 정확한 판단이 가능하기 때문입니다. 이는 신뢰도와 성실성의 기준이 됩니다.

 

그리고, 교육기관에서 어떤 교육을 이수했는지 내용이 중요합니다. 폭넓게 배울 수 있었던 점을 어필하는 것이 중요합니다. 상대적으로 짧은 시간을 보완하기 위해 어떤 노력을 했는지 준비해야 합니다.

 

반드시 전공자가 유리한 것은 아닙니다. 이력서를 작성할 때는 직무관련 스킬을 잘 채워주세요.

필수사항으로 이런 것을 작성해주면 좋습니다.

  • 라이브러리/프레임워크
    • React
    • Vue
    • NextJS
    • NuxtJS
  • 언어
    • JavaScript
    • TypeScript
    • Java
    • Python
  • OS
    • nixOS
    • Docker
    • Lunux
  • E2E Testing/Unit Testing
    • Cypress
    • Jest
    • Playwright
  • Module Bundler/Task Runner
    • Webpack
    • Npm
    • Yarn
    • Pnpm
    • Gulp
    • Grunt
    • Nix
  • JavaScript Runtime 환경
    • Bun
    • NodeJS

 

직무관련 스킬을 채울 때, 유틸성 라이브러리(React-Hook-Form, React-Infinite-Scroll, Lodash)를 피하는 것이 좋습니다.

 

경력 사항은 꼭 채우는 것이 좋습니다. 직무와 다른 경력도 좋고, 경력이 없다면 작은 경험이라도 좋습니다.

예를 들어, 숨고, 크몽에서 참여할 수 있는 프리랜서팀에서의 경험이나 교내 서버관리, 시스템 개발에 참여하는 것도 좋습니다.

이 때, 경력 사항은 최대한 자세하게, 그리고 읽기 쉽게 작성하는 것이 좋습니다.

사용한 기술 스택, 기술적 이슈, 해결 방법을 작성해야 합니다.

 

포트폴리오

포트폴리오에서 성과를 작성할 때, 매력적인 주요 성과를 작성하는 방법은 '성능 개선', '아키텍처 정리'를 담는 것이 좋습니다.

'페이지 개발', '프로세스 정리'는 기본적인 것으로 이를 담는 것은 의미가 없음에 가깝습니다.

 

프로젝트에서는 사용자 경험(UI/UX, Browser, ...), 네트워킹, CI/CD, 운영, 개발, 다양한 직군과의 협업을 담는 것이 좋습니다.

 

되도록, 혼자 진행한 개인 프로젝트, 포트폴리오, 교육기관 제출 과제는 피하는 것이 좋습니다. 그러나, 없는 것보다는 낫습니다. 또한, 클론 코딩을 할 경우, 새로운 기능을 개발하거나 추가 구현을 할 경우에만 괜찮습니다. 과제 링크를 꼭 달아주세요.

 

좋은 프로젝트는 실제 서비스중인 프로젝트, 다양한 직군과 협업한 프로젝트, 나의 개발 역량이 잘 표현된 프로젝트가 좋습니다. 더 간단하게, React 공식문서 번역 과제, 백준 코딩테스트 연습 과제를 담는 것도 좋습니다.

 

다수의 프로젝트 경험이 중요할까요?

멤버가 잘 구성된 프로젝트, 개발 시작부터 운영까지 경험할 수 있는 프로젝트, 기술 스택이 잘 짜여진 프로젝트

그렇지 않습니다. 실력을 증명할 수 있는 프로젝트가 중요합니다.

 

각종 Docs 번역 프로젝트, 실제 서비스 링크를 제공할 수 있는 마무리된 프로젝트, 할 수만 있다면 사용자들이 이용할 수 있는 서비스가 더 중요합니다. 혹시, 프로젝트를 하고 있다면 꼭 마무리해야 합니다.

 

실제 서비스와 프로젝트는 무엇이 다를까요?

사용자를 모을 수 있는 수준의 퀄리티, 경쟁 서비스들과 비슷하거나 나은 수준, 시작 버전을 마무리하고 서비스 경험이 있는 점에 따라 달라집니다. 규모, 기술의 퀄리티, 커뮤니케이션가 서비스를 만드는 행위 자체는 같습니다.

 

경력사항을 채우기 위해서 하면 좋을 것들은 학생이라면 산학연계 ICT 인턴십이 좋습니다.

또는, 프리랜서 그룹에서 실무를 진행하거나 오픈소스에 기여하는 게 좋습니다.

 

포트폴리오를 구축할 때, 무엇을 더 채우면 좋을까요?

여러 채용 공고를 보면서 어떤 기술 스택이 최근 많이 쓰이는지 찾아보고, 공부하고자 하는 기술 스택들을 선정합니다. 그리고 포트폴리오 프로젝트를 구축하면 좋습니다.

 

포트폴리오 구성

포트폴리오의 비중은 기업에 따라 다릅니다.

 

금융권은 망분리 이슈로 링크를 확인할 수 없고, 스타트업은 지원자의 개발적 역량을 확인하기 위한 지표로서 활용되며, 빅테크에서는 구현된 내용보다는 코드와 로직에 집중합니다.

 

여기서 중요한 것은 구현된 내용보다 코드와 로직에 집중하는 것입니다. 대부분의 기업은 코드와 로직에 집중하기 때문입니다. 그렇지만, 포트폴리오가 합격과 불합격 여부에 큰 영향을 주지는 않습니다. 지원자의 역량 확인 용도로 활용됩니다.

 

면접관들은 포트폴리오의 대략적인 내용 및 퀄리티를 파악하고, 포트폴리오 내용으로 면접 질문을 추가 구성합니다.

 

이력서 검토 시 중점 사항으로는 다음과 같습니다.

  • 포트폴리오 난이도
  • 구현 완성도
  • 아키텍처
  • 리뷰 포인트

 

포트폴리오 난이도에서는 두 개로 나눌 수 있습니다.

  • 구성 난이도
    • Repo 구조
  • 구현 난이도
    • 로직 복잡도
    • 관심사 분리
    • TypeScript 레벨
      • any 타입 사용해서 처리하지 않기
// 로직 복잡도 O
import React, { useCallback } from 'react';
import { debounce } from 'lodash';

function App() {
    const handleClick = useCallback(
        debounce(() => {
        	console.log('Button clicked with debounce!');
        }, 300),
        []
    );
    
    return (
        <div>
        	<button onClick={handleClick}>Click me (debounced)</button>
        </div>
    );
}
export default App;

// 로직 복잡도 X
import React from 'react';

function App() {
	const handleClick = () => {
		console.log('Button clicked!');
	};
    
	return (
		<div>
			<button onClick={handleClick}>Click me</button>
		</div>
	);
}
export default App;

 

포트폴리오를 준비할 때는, 경력사항/프로젝트/포트폴리오로 세 개의 준비를 하는 것을 추천합니다.

포트폴리오는 사업 프로젝트가 아닌 나를 위한 스테이지가 되어야 합니다. 본인이 가장 잘하는 것은 무엇인지 포트폴리오에 잘 담는 것이 중요합니다.

 

포트폴리오 작성 순서
목표 설정 및 타겟팅 → 프로젝트 선택 및 정리 → 포트폴리오 구조 잡기 → 포트폴리오 업데이트

 

목표설정 및 타겟팅

특정 회사의 채용에 특화된 포트폴리오로 특정 회사가 'Nixos 기반 개발'이라는 지원자격이 있다면?

일반적인 구직활동을 위한 포트폴리오로 특정 회사의 니즈와 상관없이 모두를 아우를 수 있는 포트폴리오를 구성할 수 있습니다.

 

프로젝트 선택 및 정리

개인 프로젝트 위주로 프로젝트를 선택할 수 있습니다. 클론 코딩, 창작 프로젝트, Getting Started 등이 있습니다.

또한, 나만의 엣지 포인트가 있어야 합니다. 아키텍처, 실시간 처리, CSS Animation, 상태관리에 집중해야 합니다.

 

라이브러리 사용 경험(React-Hook-Form, Emotion, Tailwind 사용)에 대한 항목은 엣지 포인트와 어울리지 않습니다.

 

포트폴리오 구조 잡기

포트폴리오에 담아야 할 것들은 '프로젝트의 설명 및 목적', '주요 성과', '아키텍처 및 프로세스', '러닝 포인트 및 회고'가 있습니다.

 

프로젝트 구조를 잡을 때 고려해야 할 것은 '현재 유행하는 아키텍처 적용 필요', '보편적으로 사용하는 기술 작성'입니다.

 

추천하는 포트폴리오 구조는 다음과 같습니다.

  • turbojs/yarn-workspace
    • apps/
      • app1 (based on nextjs)
      • app2 (based on nextjs)
      • app3 (based on nextjs)
    • workspace/
      • design system

 

배포는 AWS를 떠올릴 수 있지만, 이는 운영하는 서비스일 경우에 적합합니다. 포트폴리오에 적합한 배포는 'Vercel'입니다. 여러 개의 앱들을 따로 페이지를 구성해도 되고, 하나의 페이지로 구성해서 연결지어도 좋습니다.

 

포트폴리오를 통해서 보여줘야 합니다. 포트폴리오는 기회의 장이며, 잘 활용하면 면접관에게 좋은 인상을 줄 수 있습니다.

 

면접

면접 시 중점 사항은 기술 스택에 대한 질문, 최신 라이브러리들에 대한 질문, 코드의 로직에 대한 리뷰가 있습니다.

 

기술 스택에 대한 질문을 하는 이유는 기술에 대한 본인의 의사결정 과정을 이해하기 위해서 입니다.

사용중 어려웠던 점을 물어보는 이유는 어떤 수준까지 고도화해서 써봤는지 파악하기 위함입니다.

 

라이브러리에 대한 질문을 할 때, 어떻게 공부하는지 물어보는 이유는 Docs 기반으로 공부했는지, 인터넷 레퍼런스 기반으로 공부했는지, 평소 기술 공부를 어떻게 하는지 알기 위함입니다.

 

코드 로직에 대한 리뷰에 대한 질문은 실무에서 코드 리뷰 하듯 지원자에게 질문을 하게 되는데, 팀의 리뷰 문화와 잘 맞는지, 잘 적응할 수 있는지 확인하기 위함입니다.

 

자세하게

다시 돌아와서 이력서 부분을 조금 더 자세하게 다루어 봅니다.

이력서는 '간단 소개글', '경력 사항', '학력', '프로젝트', '직무스킬'로 구성할 수 있습니다.

 

  • 간단 소개글은 '개발자가 된 계기', '회사에 지원하게 된 동기', '나의 핵심 역량'을 담아야 합니다.
  • 학력은 '직무와 관련이 없는 사항도 기입'해야 하며, '교육기관에서 받았던 내용은 자세히' 작성해야 합니다.
  • 직무 스킬은 이전과 말했던대로 갖추고 있으면 좋습니다.
  • 경력사항은 '작은 경험이라도 직무관련 경험'을 갖추고 있으면 좋습니다. 그리고 '사회생활을 했던 이력'도 반드시 기입해야 합니다.
  • 프로젝트는 '너무 개인적인 프로젝트'는 피하는 게 좋습니다. 그보다 '실제 서비스'를 만들어 봅시다.
  • 포트폴리오는 '개인 프로젝트'도 좋고, '현재 유행하는 구조'도 좋습니다. 그리고 '보편적인 기술'을 활용해 만들어 봅시다.

 

포트폴리오와 프로젝트는 다릅니다. 포트폴리오는 개인적으로 실무에서 사용하는 기술을 활용해 개인적으로 만들어보고 싶은 것을 담은 것이고, 프로젝트는 개인적인 것을 넘어 1명이든 10명이든 100명이든 상관없이 서비스를 실제로 구현해보고, 문제를 해결해보는 등 운영해본 것을 말합니다. 프로젝트에는 1개를 담아도 좋습니다.

 

기술역량 확인

채용 프로세스는 굉장히 짧습니다. 기업은 지원자의 '코딩 스타일', '문제 풀이 과정', '기술적 지식', '면접 문제'에 대해 더 자세히 알고 싶어 합니다.

 

이는 어떻게 결정될까요? 회사에서는 너무 바쁘기 때문에, 빠른 의사결정과 작업속도, 원활한 의사소통, 자신감을 통해 결정됩니다.

 

기술적으로, '기술적 문제 해결 능력', '코딩 스타일', '기술적 깊이'를 통해 파악하려고 합니다.

기업은 '실무적 문제 해결 능력', '코딩 스타일', '경험적 지식 수준'을 평가하고 싶어 합니다.

 

기업들은 '플랫폼이 잘 되어있는 코딩테스트'와 '지원자의 역량을 모두 확인할 수 있는 사전과제' 중 무엇을 선호할까요?

아마도, '코딩테스트' 일 것입니다. 사전과제는 부족한 시간에 검토해야 할 것들이 너무 많기 때문이지 않을까요?

 

코딩테스트

면접관들은 '코딩테스트 등록' → '코딩테스트 결과 확인' 과정을 거쳐 지원자들의 테스트 결과를 확인합니다.

 

높은 테스트 통과율, 높은 점수, 어떤 것이 중요한 평가 항목이라고 생각합니까?

두 개의 항목은 크게 중요하지 않습니다.

중요한 것은 '문제 해결 방법', '언어의 사용 수준' 입니다. 단 한 문제를 풀더라도 어떤 방식으로 풀었고, 사용하는 기술을 얼마나 잘 사용했는지가 더 중요합니다.

 

모든 문제를 다 풀어야 하는 것도, 테스트를 모두 통과해야 하는 것도, 다른 언어로 테스트를 봐야하는 것도 중요하지 않습니다.

 

결국, 코딩테스트의 핵심 목적은 '기술 역량 평가', '논리적 사고 평가', '실제 업무 연계성' 이라고 볼 수 있습니다.

쉽게 말하자면, '언어 사용 수준', '문제 풀이 방법', '사용 언어' 라고 보면 됩니다.

 

코딩테스트 문제를 제출할 때, 고려해야 할 사항들은 다음과 같습니다.

 

명확성

요구사항과 입/출력 형식을 구체적으로 설명하는 것이 중요합니다.

예를 들어, 정렬된 배열에서 특정 요소를 찾는 문제에서 입력은 '정렬된 배열', 출력은 'index or value'로 내보내는 것 입니다.

 

적절한 범위(Appropriate Scope)

너무 복잡하지 않고 충분한 도전과제입니다.

예시로 모든 가능한 페어의 곱을 계산하는 문제로 페어의 개수를 제한하거나 특정 상황에서만 계산하는 것이 있습니다.

 

학습가치(Learning Value)

문제해결 과정에서 새로운 것을 배울 수 있도록 하는 것 입니다.

이는, 난이도를 높이는 요소입니다. 배열의 회전 문제도 해당됩니다.

 

코딩 테스트 활용

  • 면접 질문 수준 결정
  • 면접 문제로 활용
  • 피드백으로 학습 가능성 여부 판단

 

피드백

  • 학습 기회 제공: 자신의 강점과 약점을 파악할 수 있는 기회
  • 면접의 연장선: 지원자가 어떻게 개선할 수 있는지에 대한 구체적인 정보를 제공
  • 후보자의 경험 향상: 좋은 경험을 남기고, 회사에 대한 긍정적 인식 형성
  • 학습 태도 확인: 지원자가 새로운 기술과 방법을 학습하려는 의지 확인
  • 자기 개선 능력: 제시한 개선 사항을 반영할 수 있는 능력 평가
  • 커뮤니케이션 역량 평가: 대화를 통해 커뮤니케이션 능력을 추가적으로 파악

 

코딩테스트에서 완벽한 답을 찾는 것보다 본인의 솔직한 실력을 알리는 게 더 중요합니다.

 

코딩 테스트 준비

  • 문제 풀이: 프로그래머스, TopCoder, 백준
  • 알고리즘: 정렬, 탐색
  • 자료구조: 배열, 리스트, 해시, 트리, 그래프

 

사전과제

사전과제의 목적은 '기술적 역량', '실무 적용 능력', '문제 해결 능력'이 있습니다.

 

코딩테스트와 사전과제는 후보자가 실제 환경에서 어떻게 일하고, 문제 해결 능력, 논리적 사고력, 기본적인 코딩실력을 판단하는 것에 따라 다릅니다.

 

사전과제를 준비할 때, 고려해야 할 것은 '프로젝트 유형', '팀에서 사용하는 기술스택', '명확한 요구사항', '적절한 나이도'가 있습니다.

 

보통 프로젝트의 유형은 5~7일 정도 시간적으로 여유가 있는 프로젝트나 1시간 정도 시간적으로 여유를 주는 프로젝트가 주어집니다.

 

팀에서 사용하는 기술스택으로 지원자가 다룰 수 있는 기술 스택인지 확인하고, 지원자의 수준에 따라 초기 셋팅 차이가 발생할 수 있고, 대부분 사용중인 DS까지 제공하기도 합니다.

 

명확하게 요구하는 사항은 '사전 과제에 제공되는 시간안에 풀 수 있도록 하는 것'이며, '충분한 리소스를 제공(API, 기획서)하는 것'입니다.

 

적절한 난이도로 '적당한 난이도의 UI 로직'과 '라이브러리 제한'을 하기도 합니다.

 

보통 사전과제를 평가할 때는 1시간 정도로 시간적 여유를 주는 프로젝트로 가정할 때,

  • 주어진 과제를 모두 해결했나?
  • 추가로 사용한 라이브러리는 어떤 것인가?
  • 코드의 가독성은 어떤가?
  • 문제 해결 접근법은 어떠한가?

 

그리고 주어진 시간이 짧기 때문에 문제 해결에 집중하는 것이 좋으며, 그리고 문제 해결과 가독성을 유지하는 게 가장 좋습니다.

 

사전과제를 5~7일 정도로 시간적 여유를 주는 프로젝트로 가정할 때,

  • 주어진 시간이 길어 고려해야 할 부분 증가
  • 문제 해결★
  • 클린 코드★
  • 높은 수준의 React/Vue 사용 능력★

 

위의 네 가지는 필수적으로 수행해야 하지만, 추가적으로 테스트 코드를 작성해보거나, DX에 영향을 주는 요소들을 사용하거나, 데이터 로직과 UI 로직의 명확한 분리를 하거나, 타입스크립트를 사용하거나, 성능을 고려한 개발을 하는 것도 추가 점수가 될 수 있습니다.

 

사전 과제에서 옵션이기는 하지만, 필수사항인 것이 있습니다.

제출 기간이 길기 때문에 그만큼 기대하는 정도도 높습니다. 그리고 실무 개발자를 가정하고 문제에 접근해야 합니다. 또한, 코드 수준을 높게 보이는 게 중요합니다.

 

개발환경

  • Vanilla JavaScript/React → React
  • 순수 React는 필수? → X
  • 추가적으로 셋팅하면 좋은 것 → Eslint, Prettler, TypeScript, Axios, React-Query
  • State 관리 라이브러리 추가는 필수? → 구현 복잡도에 따라 다르며, 단일 페이지 개발 위주로 State, Props로 충분/State 관리 기술을 보여주고 싶다면 도전 가능
  • 마크업 → Figma로 디자인된 내용 마크업
  • 기능 → 무한 스크롤 적용, 토글 가능한 필터, 검색(자동완성 포함), 리스트

 

실제로 구현하게 된다면

Repo 구조

@types/ → @는 단순 옵션
hooks/
components/
services/
utils/
pages/

 

마크업

웹 접근성
CSS-IN-JS 또는 CSS/SASS
Style Module 또는 Global
Classcat

 

무한 스크롤

토글 가능한 필터

검색

리스트

 

이 외에, Image가 없을 때는 'Skeleton-UI'를 적용하거나, 'Data Fetching'에 대해 더 구체적으로 구현하는 것이 좋습니다.

이 때, 'Data Fetching' 처리는 'JSON Import'를 제외하고, 'Fetch' 또는 'Axios'로 처리하는 게 좋습니다. Axios를 잘 사용하지 못할 것 같다면, Fetch로 처리합시다.

 

왜냐하면, 보여주고 싶은 것에 따라 다르기 때문입니다.

실무 능력을 보여주고 싶다면 'Axios', 프론트엔드 기본기를 나타내고 싶다면 'Fetch'를 선택하여 처리하는 것을 고려해 봅시다.

 

만약, 여러 개의 JSON 파일의 데이터를 처리해야 한다면, 세 개 모두 한 번에 'Infinite-Scroll' 시 프론트엔드에서 처리하거나, 'Infinite-Scroll' 할 때마다 'Fetching'하도록 하는 방법이 있습니다.

 

State를 만드는 것도 기술입니다. 여러 개의 JSON 파일의 데이터를 처리할 때, 세 개의 JSON의 길이만 초기에 저장하고, 'Infinite-Scroll' 시 Length, Page 값에 따라 데이터를 'Fetching'하도록 할 수 있습니다.

 

때로, 'Hook'을 활용한 관심사를 분리하는 방법도 좋은 방법입니다.

 

면접

면접관의 면접 준비

실무자들은 사실 이력서를 추가로 검토하기는 힘들고, 항상 이력서 검토는 우선순위에서 밀려 있습니다.

보통 이력서 검토 원칙은 다음과 같습니다.

 

  • 면접 전날 오후 6시 전까지 검토 회의
  • 이력서, 포트폴리오에서 면접 질문
  • 지원자 수준에서 맞는 기술 질문 준비

 

면접관들은 이력서, 포트폴리오에서 어떻게 면접 질문을 만들어 내는지, 면접관의 구성, 구성에 따른 난이도 차이에서 면접을 준비합니다.

 

면접의 목적

  • 좋은 인재를 가려내는 마지막 과정
  • 역량 평가
  • 문화 적합성 확인

 

지원자 입장에서도 좋은 회사, 팀인지 확인하는 마지막 과정이며, 조직의 첫 인상을 제공하는 데 목적이 있습니다. 또한, 나와 함께 일 할 수 있는 사람들의 수준을 확인하는 데 목적을 가지고 있습니다.

 

지원자마다 채용공고의 내용에 따라, 지원자의 배경에 따라, 면접관의 수준에 따라 준비하는 내용이 다릅니다.

시니어, 주니어에 따라 기술 질문이 다른 것처럼 말입니다.

 

지원자가 SI, 퍼블리싱 업체에서 경력을 쌓았거나, 네이버에서 경력을 쌓았거나, 신입사원인지 배경에 따라 질문이 다를 수 있습니다.

또한, 면접관의 수준에 따라 비슷한 지원자들이라도 질문이 다를 수 있습니다.

 

면접질문을 만드는 과정

  1. 간단 소개글
    • 연차
    • 개발자가 된 과정
    • 회사에 지원하게 된 동기
  2. 경력사항
    • ★졸업 예정자, 현직자
    • 전/현직에서 참여했던 개발 내용에 대한 질문(80%)
    • 전/현 회사의 개발 내용과 비교하여 질문
  3. 직무스킬
    • 팀에 필요한 기술 스택에 대해서 사용 수준을 확인
    • 전/현직에서 참여했던 개발 내용과 엮어서 질문
  4. 프로젝트
    • 회사 다니던 기간 중 실무 프로젝트
    • 취업 준비 과정에서 경험했던 프로젝트(준비했던 경험에 따라 질문 수준과 내용의 차이 존재)
  5. 포트폴리오
    • 블로그(기억 못하는 내용은 삭제 또는 숨김 처리)
    • 포트폴리오(코드레벨 수준의 질문까지)

 

면접 준비

대부분 면접 시간은 5시 이후 지정, 너무 이른시간, 1시에 진행되지 않습니다.

면접장에 처음 들어간다면, 나이를 먼저 파악하는 것이 좋습니다.

나이대가 어릴수록 면접 난이도가 올라갈 수 있습니다.

 

이력서로 돌아가서, 이력서는 서류면접 통과와 면접 시 참고자료가 될 수 있습니다.

 

이력서의 역할에 대해 다시 생각해본다면,

서류면접 통과에 집중한다면 대답하지 못하는 질문들이 발생할 수 있습니다.

만약, 면접 시 참고자료에 집중한다면 이력서가 너무 담백해질 수 있습니다.

 

그렇기 때문에 적절한 조율이 필요합니다. 이력서를 최소 5번 검토하고, 외워야 할 내용은 외우고, 블로그를 점검하고, 제출한 포트폴리오를 점검해야 합니다.

 

대응가능한 면접 질문

  • SEO 성능 개선 프로젝트 진행 과정에서 본인의 역할에 대해 자세히 설명하라
  • 탭 기능 구현을 위해 `if-else` 문을 작성했는데, 삼항연산자를 사용하지 않은 이유를 설명하라
  • 프로젝트에서 장바구니 페이지를 개발했는데, 장바구니의 유지기간은 어떻게 되고, 어떤 기능을 사용해서 구현했는지 설명하라

 

면접 공식 질문

  • 했던 업무 기반으로 짧게 자기소개하라
  • 지원한 회사에 지원한 동기가 무엇인가
  • 지원한 회사 서비스를 경험하면서 불편했거나 개선할 수 있다고 생각한 포인트가 있었는가

 

공식 질문의 내용들은 간단 소개글에 작성하는 것이 좋습니다.

간단 소개글에 축약버전을 기록합시다. 소개 멘트, 지원동기, 서비스 경험 모두 이력서에 녹일 수 있도록 노력합시다.

이력서를 다시 보면서 어느 정도 소리내어 리딩하고 가는 것도 좋은 방법입니다. 면접관들도 만들어서 외워오는 것을 다 알고 있다.

 

이력서는 회사 별로 다른 것이 좋습니다.

회사별로 지원동기를 다르게 기록하면 좋습니다. 회사의 서비스에 대한 내용을 기록할 수 있습니다. 기술 수준에 따라 본인이 경험했던 내용들에 대해 다르게 기록할 수 있습니다.

 

꼬리질문

꼬리질문을 사전에 자르는 방법은 무엇일까요?

  • 전 회사의 SEO 성능 개선 프로젝트에서 본인의 역할에 대해 자세한 이야기를 질문할 때
  • 메타태그를 어떻게 개선할 지 질문할 때
  • SEO에 영향을 미치는 메타태그에는 어떤 종류가 질문할 때

 

이력서 작성

이력서는 길어도 됩니다.

본인의 경험한 프로젝트를 생각보다 더 길고 자세하게 작성할 필요가 있습니다.

면접관이 프로젝트에 대해 제대로 이해할 수 있게 말입니다.

 

이력서를 길게 작성해도 되지만!

다른 사람이 했던 경험까지 자세하게 작성할 필요는 없습니다. 쓰기 귀찮다는 생각과 이 정도면 괜찮을 것 같다는 생각도 이력서를 작성할 때는 잠시 내려두세요.

 

직무 스킬

'하' 수준의 스킬은 쓰지 않는 것이 오히려 좋습니다.

그리고 너무 자신감 넘치게 수준을 기록하지 마세요. 또한, 생각보다 직무 스킬은 다양하게 있습니다.

본인이 설명할 수 있는 기술 위주로 기록해 보세요.

 

상, 중, 하의 기준을 어떻게 나눌 수 있을까요?

구체적인 기준을 두고 나누기는 어렵습니다. 상대적 기준이 아니라 절대적 기준으로 나눕니다.

하지만, 주니어라면 '중' 수준에서 맘춰도 괜찮습니다.

 

면접은 잘 하는 사람보다 '어울리는 사람'을 찾는 것이 면접입니다.

 

타입스크립트

타입스크립트에 관해서는 많은 논란이 있을 것 입니다.

어느 정도 수준이 되어야 타입스크립트를 사용할 수 있다고 말할 수 있는 걸까요?

 

() => infer R ? R : undefined

 

만약, 위 코드처럼 `infer`를 이해하고 사용할 줄 아는 정도라면 말해도 괜찮다고 생각합니다.

 

  • infer: 조건부 타입에 사용되며, 조건식이 참으로 평가될 때 사용할 수 있는 타입을 추론하는 데 필요한 도구

 

기술면접

기술면접의 목적은 지원자의 기술적 역량을 파악하는데 두고 있습니다. 많은 지원자들이 미리 알 수 없는 질문들에 대해 준비하고, 이에 어려움을 느끼고 있지만, 별도로 준비하지 않는 것이 가장 좋습니다.

 

그렇지만, 기술면접을 준비하기 때문에 생기는 탐구력이 있습니다. 기술을 이해하려는 노력을 하게 됩니다.

이런 것들이 지원자의 역량을 더 발전시킬 수 있다고 생각해 반드시 준비하면 좋습니다.

 

기술면접에서 어떤 주제를 가지고 면접관들은 준비를 하게 될까요?

바로, '팀의 기술스택에 대한 깊이'와 '개발 전반적인 역량'에 대해 준비를 하게 됩니다.

 

또한, '워크 스페이스', '자바스크립트', '타입스크립트', 'React', 'NextJS' 등 기술에 대해 질문을 하게 됩니다.

그리고 개발 전반적인 역량으로 'TaskQueue', 'Call Stack', 'Event Loop', 'AWS', 'Jenkins', 'Actions', 'CI/CD', 'EKS', 'React', 'JavaScript', 'TypeScript', 'NextJS', 'Confluence', 'Figma', 'Jira', 'Notion' 등을 질문하게 됩니다.

 

준비

  1. 1단계
    • JavaScript
      • this 사용법에 대해 이야기하라
      • var, let, const 차이점에 대해 호이스팅까지 연결해서 이야기하라
  2. 2단계
    • JavaScript
      • Debounce, Throttle을 비교해서 설명하라
    • TypeScript
      • any, unknown의 공통점과 차이점을 설명하라
    • Web
      • cors는 브라우저의 어떤 정책을 위반한 것이며, 해결할 수 있는 방안을 모두 이야기하라 (FE, BE)
    • React
      • Virtual-DOM과 일반 DOM의 렌더링 관점에서 비교하고 성능의 차이점에 대해 이야기하라
  3. 3단계
    • Web
      • (언어적 특징에서 Single-Thread를 언급했다면) Single-Thread 환경에서 비동기 호출이 가능한 이유를 이야기하라
      • (비동기 호출이 가능한 이유에 대해 정확히 설명했다면) Event-Loop, Event-Queue, Call-Stack의 동작에 대해 이야기하라

 

모든 단계의 질문을 답할 수 있을 정도로 박식해야 할까요? 개발력이 좋아야 할까요? 이론을 잘 알고 있어야 할까요?

그렇다면 정말 좋습니다. 그렇다면 꼭 그럴 필요는 없습니다. 실무자한테 물어봐도 답하지 못할 사람들이 많을 것 입니다.

 

면접에서 중요한 것은 많이 아는지 물어보는 것이 아닙니다. 지원자가 어디까지 알고 있는지 파악해야 실무를 할 때 준비를 할 수 있을 것 입니다.

 

이는, 면접 당락에 중요한 요소는 아닙니다.

더 중요한 것은, '면접에서의 태도', '답변하는 자세', '개발에 대한 열정'이 더 중요합니다. 다른 것들이 면접에서 더 중요하다는 것 입니다.

 

그렇다면, 어디까지 알아야 할까요?

현대카드의 하나의 팀 기준으로 1단계의 레벨을 통과해도 좋습니다. 현재 팀과 함께 코딩을 할 수 있는 수준인지가 중요합니다. 그리고 기본만 안다는 것이 중요합니다. 많이 아는 것이 중요한 게 아닙니다.

 

기본기라는 건 어디까지를 말하는 걸까요?

  • 자바스크립트
    • ES6 기반의 기본 문법 (Vanilla JavaScript)
    • React, Vue 등 프레임워크 문법과 기본 문법의 구분
    • Class, Function과 같은 JavaScript 고유의 특성이 있는 부분들
    • (회사에 따라 다르지만) 직접 사용하지 않는 Symbol, Reflext 등과 같은 내용은 중요하지 않음
    • 현재 문법상 많이 사용하지 않는 클로저
  • React
    • Virtual-DOM으로 가지는 특성들 (Key 등)
    • Memoization
    • Hook
    • Hook 이전의 HOC, Class Component 등은 옵션
  • Web
    • CORS
    • Rest API
    • 브라우저 3대 스토리지 (Sesstion Storage, Cookie, Local Storage)

 

혹시, 내용들이 어렵다고 느껴질까요?

기본적으로 우리가 개발할 때, 체험하게 되는 내용들입니다. 그것들에 대해 얼마나 많이 탐구했는지 알아보는 게 기술면접입니다. 본인이 평소에 코딩을 하면서 계속 "물음표(?)"를 그려보는 연습을 하는 게 좋습니다.

 

기술면접 준비

어떤 순서로 준비해야 할까요?

 

  1. 기본 개념 정리
    • 어느 정도를 알고 개발하고 있는가
    • 어디까지 정리했는가
  2. 문제은행 풀이

 

자바스크립트 기본 개념 정리

  • 기본구조
    • var, let, const
      • var, let | const: 변수 선언, 상수 선언
      • let, const | var: 호이스팅 적용 여부
    • 기본 데이터 타입
      • string
        • 선언: " ", ' ', ` `
        • immutable
      • number
        • NaN
        • Infinity, -Infinity
      • boolean
      • null
        • 의도적으로 값이 비어있음을 나타낼 때 사용
        • 변수나 객체 값이 비어있음을 나타내주기 위해 사용
        • typeof null === 'object'
      • undefined
        • 변수가 선언되었으나, 아직 값이 할당되지 않은 상태
      • object
        • non-primitive type
        • 복합 데이터 타입, 여러가지 타입의 값을 속성으로 보유
        • 객체는 참조타입, 객체의 값을 다른 변수에 입력하면 변수는 객체의 참조 값만 보유
  • 함수와 스코프
    • 함수 선언
      • funtion helloWorld() {}
      • hoisting (O)
      • 별도 Scope
    • 함수 표현식
      • const helloWorld = function() {}
      • hoisting (X)
    • 화살표 함수
      • const helloWorld = () => {}
      • 통일된 Scope
      • 간략한 문법
    • 전역 스코프
      • 어디서나 접근가능한 변수
      • 웹 브라우저 환경에서의 Window
    • 지역 스코프
      • 함수 내 선언된 변수
    • 렉시컬 스코프
      • 함수가 정의된 시점에서의 스코프에 따라 변수 참조
    • 클로저(Closure)
      • 자신이 선언된 환경 외부 함수의 변수에 접근가능한 것
    • React에서의 클로저
      • Scope: 컴포넌트 별 지역 Scope
      • useState, useEffect와 클로저
  • 객체와 배열
    • 객체 리터럴 표기법
      • 객체를 생성하는 가장 간단한 방법 → {}
      • 객체에서의 `this`는 현재 객체
    • 배열의 메서드의 사용법과 사용 패턴에 대해 얼마나 알고 있는가?
  • 비동기 처리
    • 자바스크립트 특성 중 Single Thread 환경에서 비동기 처리가 가능한 이유

 

React

컴포넌트 기반 아키텍터로 단방향 데이터 흐름입니다. React는 가상의 DOM을 사용합니다.

 

현재 컴포넌트 기반 아키텍처의 정점에 위치하고 있다.

클래스 기반 컴포넌트 → HOC → Hook

 

컴포넌트 기반 아키텍처

애플리케이션을 독립적이고 재사용이 가능한 컴포넌트 단위로 나누어 구성하는 소프트웨어 설계 방식입니다.

이는, 네 가지 특징을 가지고 있습니다.

 

  • 독립성: 컴포넌트는 독립적으로 설계되며, 다른 컴포넌트에 영향을 주지 않고 독립적으로 동작, 유지보수성 향상
  • 재사용성: 동일한 컴포넌트를 애플리케이션 내 여러 곳에서 재사용 가능. 개발 효율성 향상
  • 모듈화: 코드를 논리적인 단위로 분리하여 관리, 각 컴포넌트는 특정 기능이나 UI의 한 부분을 담당하며, 변경이 필요한 경우 해당 컴포넌트만 수정
  • 캡슐화: 컴포넌트는 내부 로직과 데이터를 캡슐화하여 외부에서는 오직 필요한 인터페이스(Props)를 통해서만 접근 가능

 

프레젠테이셔널 컴포넌트와 컨테이너 컴포넌트

  • 프레젠테이셔널 컴포넌트: 주로 UI를 담당하며, 상태나 비즈니스 로직 없이 Props를 통해 데이터를 전달받아 렌더링
  • 컨테이너 컴포넌트: 상태 관리나 비즈니스 로직을 처리, 데이터를 가져와 프레젠테이셔널 컴포넌트에 전달
  • 컴포지션(Composition): React에서는 상속 대신 컴포지션을 사용하여 컴포넌트를 구성하는 것을 권장하며, 컴포넌트가 더 유연하고 재사용이 가능

 

그러나, 컴포넌트 기반 아키텍처의 한계점이 존재합니다.

 

코드 중복과 재사용의 부족해질 수 있습니다.

React 애플리케이션이 복잡해지면서, 여러 컴포넌트에서 유사한 기능이나 로직이 반복되는 경우가 발생합니다.

예를 들어, 인증 여부를 확인하여 컴포넌트를 렌더링하거나 로그인 페이지로 리다이렉트를 하는 경우가 있습니다.

 

이와 같이 반복적인 로직을 각 컴포넌트에 개별적으로 작성하면 코드 중복이 발생하고, 유지보수성이 떨어집니다. 이러한 공통 로직을 효율적으로 재사용할 수 있는 방법이 필요해질 것입니다.

 

HOC

컴포넌트를 인자로 받아서 컴포넌트를 리턴하는 컴포넌트를 말합니다.

 

이는, 세 가지의 특징을 가지고 있습니다.

 

  • 재사용성: HOC를 사용하면 특정 기능이나 로직을 한 곳에서 관리, 여러 컴포넌트에서 사용
  • 단일 책임 원칙: HOC는 컴포넌트의 주 책임을 유지하면서, 추가적인 기능을 별도의 HOC로 분리
  • 조합 가능성: 여러 개의 HOC를 조합하여 컴포넌트에 다양한 기능을 추가. 컴포넌트를 유연하게 확장 가능

 

면접에서 주요한 쟁점은 '컴포넌트 기반 아키텍처'의 원칙을 잘 지키는 개발을 하고 있는가 입니다.

예를 들어, 이와 같은 질문을 할 수 있습니다.

 

"컴포넌트를 분리할 때, 어떤 기준으로 분리를 하고 있습니까?"

"repository 구성을 어떻게 하고 있나요?"

 

단방향 데이터 흐름

데이터가 애플리케이션 내에서 '한 방향'으로만 흐르는 구조입니다.

React에서 부모 컴포넌트가 자식 컴포넌트로 데이터를 전달하는 방식을 생각하면 됩니다.

 

단방향 데이터 흐름은 데이터의 예측 가능성을 높이고, 애플리케이션 상태를 추적하기 쉽게 만들어 줍니다. 또한, React의 철학은 데이터 흐름을 명확하게 하고, 컴포넌트 간 의존성을 줄이는 데 있기 때문에 단방향 데이터 흐름은 중요합니다.

 

예측 가능성

단방향 데이터 흐름은 애플리케이션의 데이터 변화를 예측 가능하게 합니다. 어디서 시작되고, 어떻게 변경되며, 어디로 전달되는지가 명확하기 때문에 코드의 가독성과 유지보수를 하기 좋아집니다.

 

디버깅 용이성

데이터의 흐름이 명확하기 때문에, 애플리케이션에서 버그가 발생했을 때, 문제 원인을 찾기 쉬워집니다.

 

단일 진실의 원천(Single Source of Truth)

상태를 상위 컴포넌트에서 중앙집중적으로 관리할 수 있고, 애플리케이션의 상태를 한 곳에서 관리 추적이 가능합니다.

 

복잡한 상태 관리

컴포넌트 계층 구조가 깊어질수록 'props drilling' 문제를 일으킬 수 있습니다. 즉, 상태나 데이터를 하위 컴포넌트로 전달하기 위해 여러 중간 컴포넌트를 거쳐야 하는 문제가 발생할 수 있습니다.

 

이를 해결할 수 있는 방법으로, `Context API`, `useReducer`, `recoil`, `zustand`, `jotai`가 있습니다.

보통, `useReducer`는 잘 사용하지 않습니다. `Context API`도 잘 사용하지 않는 추세이지만, 한 번 사용해보는 것도 좋습니다.

 

전역 상태 관리 라이브러리와 `Context API`를 비교할 때, 내장된 기능을 사용하는가와 사용성이 높은 전역 상태 관리 라이브러리를 사용하는가는 사용자의 몫입니다.

하지만, 어떤 이유든 사용하는 이유에 대해 알고 있어야 합니다.

 

면접에서 중요한 것은 '단방향 데이터 흐름'을 통해 React에 어떤 특성이 생기는가 입니다.

예를 들어, "Props와 State의 차이점에 대해 이야기하라"와 "Props Drilling과 그것을 해결하는 방법은 무엇인가?" 질문을 받을 수 있습니다.

 

가상 DOM

'실제 DOM'은 브라우저가 HTML 문서를 파싱해서 만든 트리 구조의 객체로, UI를 렌더링합니다,

DOM 조작은 브라우저 렌더링 엔진에 직접 영향을 미치기 때문에 성능 비용이 큽니다. 특히, 대규모 애플리케이션에서 DOM 조작이 많아지면 성능 저하가 발생할 수 있는데 이것이 'Layout Shift'입니다.

 

'가상 DOM'은 브라우저의 실제 DOM과 동일한 구조를 가진 자바스크립트 객체입니다.

가상 DOM은 메모리 내에서만 존재하며, UI의 변경 사항을 빠르게 계산할 수 있습니다. React는 가상 DOM을 사용해 변경된 부분을 계산하고, 이를 실제 DOM에 반영하기 전에 최소한의 변경만 수행하도록 최적화합니다.

 

가상 DOM에서 빈번하게 그리게 되는 경우가 발생하는데 그 원인은 `Layout`으로 인해 발생합니다.

 

가상 DOM 동작 원리

변경 감지

컴포넌트가 상태(State)나 `Props`를 변경하면, React는 새로운 가상 DOM 트리를 생성합니다. 이전 가상 DOM 트리와 새로운 가상 DOM 트리를 비교(Diffing)하여 어떤 부분이 변경되었는지 감지합니다.

 

바뀐 부분만 업데이트

변경된 부분이 감지되면, React는 실제 DOM에 반영하기 위해 최소한의 업데이트만 수행합니다. 이를 통해, 전체 DOM을 다시 렌더링하는 비용을 줄이고, 성능을 최적화할 수 있습니다.

 

재조정(Reconciliation)을 하는 과정

React는 가상 DOM을 사용하여 변경 사항을 효율적으로 비교하고, 필요한 부분만을 실제 DOM에 적용합니다. 이 과정에서 React의 효율적인 알고리즘이 사용됩니다.

 

성능 최적화

가상 DOM은 변경 사항을 메모리에서 계산하고, 실제 DOM 조작을 최소화합니다.

그리고 크로스 브라우저 호환성으로 다양한 브라우저 환경에서 일관된 성능을 제공합니다.

 

개발자 경험 향상

React 개발자는 가상 DOM 덕분에 UI의 변경 사항을 직접 관리할 필요가 없습니다.

 

그렇지만, 단점도 존재합니다.

 

초기 렌더링 비용

가상 DOM을 사용하는 초기 렌더링은 추가적인 계산이 필요하며, 특히, 매우 간단한 애플리케이션에서 오히려 불필요한 복잡성을 도입할 수 있습니다.

 

복잡성

가상 DOM은 내부적으로 복잡한 비교(Diffing) 알고리즘을 사용하는데, 이를 완전히 이해하고 최적화하기 위해서 깊은 이해가 필요합니다.

 

특정 성능 이슈

가상 DOM이 모든 경우에 가장 빠른 방법이 아닐 수 있습니다. 매우 큰 리스트를 렌더링한다면? 예상하기 어려운 이슈가 발생할 수 있습니다.

 

가상 DOM에서 성능에 관해 사용할 수 있는 특징들이 있습니다.

 

Memoization(메모이제이션)

함수의 결과를 캐싱(Caching)하여 동일한 입력 값으로 함수가 호출될 때, 다시 계산하지 않고 캐시에 저장된 결과를 반환합니다. React에서는 리렌더링을 최소화하기 위해서 사용하고 있습니다.

 

  • React.memo
    • 일종의 HOC
    • 컴포넌트 전체의 리렌더링 방지
  • useMemo
    • 값을 Memoization
    • 의존성 배열의 값이 변경되지 않는 한 리렌더링 발생 X
  • useCallback
    • 함수 Memoization
    • 의존성 배열의 값이 변경되지 않는 한 동일한 함수 사용

 

그러나, 이 또한 단점이 존재합니다.

메모이제이션된 결과는 메모리에 저장되며, 불필요하게 메모리를 점유할 수 있습니다. 특히, 메모이제이션된 데이터가 많아지면 메모리 관리가 필요할 수 있습니다.

 

그리고, 모든 컴포넌트에 메모이제이션을 적용하는 것은 오히려 코드 복잡성을 높일 수 있습니다.

 

메모이제이션은 성능 최적화를 위한 하나의 도구로 필요할 때 적절하게 사용해야 합니다. 일반적으로, `useMemo`와 `useCallback`을 사용하게 되는 경우는 많지 않다고 합니다. 다른 방법을 활용해 메모리 관리를 하는 경우가 더 많습니다.

 

 

면접에서 주요 쟁점은 '가상 DOM 특징', '성능 최적화' 입니다.

예를 들어, "List 렌더링 시, index 값을 key로 사용하지 않는 이유는 무엇입니까?", "실제 DOM과 가상 DOM의 차이점은 무엇입니까?", "React의 Memoization에 대해 설명하세요."가 있습니다.

 

Web

  • 브라우저
    • 데이터 저장소
    • 데이터 통신 보안
    • Web API
    • Window, Document 객체
    • 3대 저장소
      • 쿠키
      • 로컬 스토리지
      • 세션 스토리지

 

쿠키

웹 브라우저와 웹 서버 간 상태 정보를 유지하기 위해 사용하는 작은 데이터 파일입니다.

쿠키는 클라이언트(브라우저)에 저장하고, 이 후 동일한 웹 사이트에 접속할 때 서버에 의해 읽혀서 상태 정보를 관리하는 데 사용됩니다.

주로 '세션 관리', '사용자 추적', '개인화된 사용자 경험 제공'을 합니다.

 

쿠키는 '이름-값'을 쌍으로 이루어져 있으며, 다양한 속성(유효 기간, 도메인, 경로 등)을 포함합니다.

기본 속성으로 'expires' or 'max-age'로 쿠키의 유효 기간을 설정할 수 있습니다.

.

쿠키를 생성하고 관리할 수 있습니다.

서버 측에서 설정하는 것은 HTTP 응답 헤더에 'Set-Cookie'를 포함시켜 쿠키를 클라이언트에 전달합니다.

클라이언트 측에서 관리하는 것은 자바스크립트를 사용해 쿠키를 설정하거나 읽을 수 있습니다.

 

쿠키는 다음과 같이 사용할 수 있습니다.

'세션 관리'로 사용자가 로그인 상태를 유지할 수 있도록 세션 ID를 쿠키에 저장할 수 있습니다.

'사용자 맞춤화'로 사용자의 설정(언어 선택, 테마)을 쿠키에 저장하고, 사용자가 사이트를 재방문할 때 동일한 설정이 유지되도록 할 수 있습니다.

'트래킹 및 분석'으로 광고 네트워크나 분석 도구는 쿠키를 사용하여 사용자의 웹 사이트 방문 패턴을 추적하고, 이를 통해 사용자 행동을 분석하고 맞춤형 광고를 제공할 수 있습니다.

 

세션 스토리지

웹 브라우저 내 데이터를 세션 단위로 저장할 수 있는 클라이언트 측 저장소입니다.

브라우저의 각 탭 또는 창에서 독립적으로 동작하며, 브라우저 탭이 닫히면 저장된 데이터가 자동으로 삭제됩니다.

 

특징으로 세션 스토리지는 쿠키와 달리 서버와 자동으로 전송되지 않으며, 자바스크립트를 통해서만 접근이 가능합니다. 브라우저 탭 간에는 데이터가 공유되지 않아 각 탭이 독립적인 데이터를 관리가 가능합니다.

 

일반적으로 일시적인 데이터를 저장하는데 유용합니다. 예를 들어, 사용자 세션동안 유지해야 할 데이터(필터 설정, 폼 데이터 등)를 관리할 때 사용합니다.

 

그러나, 브라우저 탭이 닫히면 데이터가 삭제되며, 영구적으로 데이터를 저장할 수 없습니다. 또한, 브라우저 별로 약 5MB 저장이 가능합니다.

 

로컬 스토리지

웹 브라우저 내 영구적으로 데이터를 저장할 수 있는 클라이언트 측 저장소입니다.

 

쿠키와 달리 서버에 자동으로 전송되지 않으며, 자바스크립트를 통해서만 접근이 가능합니다. 그리고 각 도메인 별로 로컬 스토리지가 독립적으로 관리할 수 있고, 데이터는 도메인 간 공유는 불가능합니다.

 

일반적으로 영구적인 데이터 저장이 필요할 때 유용합니다. 예를 들어, 장바구니 정보를 저장하는 용도가 있습니다.

 

그러나, 로컬 스토리지에 저장된 데이터는 클라이언트 측에서 접근이 가능해 보안 위험성이 있고, 일반적으로 약 5MB로 용량이 제한되어 있습니다.

 

동일 출처 정책(Same-Origin Policy)

동일 출처 정책(SOP)은 웹 보안 모델로 브라우저가 악의적인 스크립트로부터 사용자의 데이터를 보호하기 위해 설계된 규칙입니다. 이 정책은 서로 다른 출처(Origin) 간의 리소스 접근을 제한하여 보안을 강화합니다.

 

  • 출처(Origin)
    • 동일 출처
      • 프로토콜(HTTP/HTTPS)
      • 도메인
      • 포트 번호가 모두 동일한 경우

 

적용된 예시로, "https://example.com'에서 실행중인 스크립트, 'https://another-domain.com'의 데이터를 읽을 수 없는 것입니다.

 

동일 출처 정책은 '크로스 사이트 스크립팅(XSS)' 및 '크로스 사이트 요청 위조(CSRF)'와 같은 공격으로부터 사용자를 보호하는 데 중요한 역할을 합니다. 이러한 공격은 다른 출처에서 악성 스크립트를 삽입하거나, 사용자의 세션을 도용할 수 있습니다.

 

CORS(Cross-Origin Resource Sharing)

동일 출처 정책의 제약을 완화하기 위한 보안 메커니즘입니다.

이를 통해, 서버는 특정 도메인에서 오는 요청을 명시적으로 허용이 가능합니다. 브라우저와 서버 간 HTTP 헤더를 사용해 브라우저가 다른 출처의 리소스를 안전하게 요청합니다.

 

CORS의 동작 방식은 서버는 응답 헤더에 'Access-Control-Allow-Origin' 헤더를 포함시켜서 특정 출처에서의 요청을 허용합니다.

예. Access-Control-Allow-Origin: https://example.com

 

프리플라이트 요청(Preflight Request)

CORS는 복잡한 요청(PUT, DELETE, PATCH, 커스텀 헤더가 포함된 요청)을 보내기 전에 브라우저가 서버에 프리플라이트 요청을 보냅니다.

 

프리플라이트 요청은 `OPTIONS` 메서드를 사용해 서버에 이 요청을 허용할 지 여부를 확인합니다.

그리고, 서버가 `Access-Control-Allow-Methods`, `Access-Control-Allow-Headers`와 같은 헤더를 통해 이 요청을 허용하면, 실제 요청이 전송됩니다.

 

CORS는 웹 애플리케이션이 여러 도메인 간 상호작용을 할 수 있도록 합니다. 그러나, CORS 설정을 잘못하면 보안 취약점이 발생할 수 있습니다. 예를 들어, 모든 출처를 허용하는 '와일드카드(*)'를 사용하면, 보안에 위험이 증가할 수 있습니다. 그렇기 때문에, 설정할 때 특정 도메인을 작성해주는 게 좋습니다.

 

면접에서 "CORS 이슈를 해결하는 방법에 대해 말하라", "CORS 이슈가 발생하는 원인이 무엇인가?", "브라우저 스토리지를 비교해 설명하라"에 대한 질문을 받을 수 있습니다.

 

최종 정리 (Key Point)

이력서 간단 소개글

  • 개발자가 된 계기
  • 회사에 지원하게 된 동기
  • 본인 핵심 역량

 

학력

  • 직무와 관련이 없는 사항도 기입
  • 교육 기관에서 받았던 내용은 자세히 기입

 

직무 스킬

  • Library / Framework → React, Vue, NextJS, NuxtJS
  • Language → JavaScript, TypeScript, Java, Python
  • OS → nixOS, Docker, Linux

 

경력사항

  • 작은 경험이라도 직무 관련 경험은 작성
  • 사회생활했던 이력도 반드시 기입

 

프로젝트

  • 너무 개인적인 프로젝트는 피하기
  • 실제 서비스 만들기

 

포트폴리오

  • 개인 프로젝트
  • 현재 유행하는 구조
  • 보편적인 기술(실무)

 

테스트 (지원자 파악)

  • 코딩 스타일
  • 문제 풀이 과정
  • 기술적 지식
  • 면접 문제

 

코딩테스트 중요한 평가 항목

  • 모든 문제를 다 풀 필요 없음
  • 테스트를 모두 통과할 필요 없음
  • 다른 언어로 테스트를 볼 필요 없음

 

최소한의 코딩테스트 준비

  • 문제 풀이
    • 프로그래머스, TopCoder, 백준 알고리즘
  • 알고리즘
    • 정렬, 탐색
  • 자료구조
    • 배열, 리스트, 해시, 트리, 그래프

 

사전과제 유형

  • 5~7일 정도 시간적 여유를 주는 프로젝트
  • 1시간 정도 시간적 여유를 주는 프로젝트

 

면접질문 만드는 과정

  • 간단 소개글
  • 경력사항
  • 직무스킬
  • 프로젝트
  • 포트폴리오

 

이력서

  • 서류면접 통과
    • 서류면접 통과에 집중한다면, 대답 못하는 질문 발생
  • 면접 시 참고자료
    • 면접 시 참고자료에 집중한다면, 이력서가 담백해지는 가능성 증가

 

적절한 조율 필요

  • 이력서 최소 5번 점검
  • 블로그 점검
  • 외워야 할 내용 숙지
  • 제출한 포트폴리오 점검

 

개발 전반적인 역량

  • Task-Queue
  • Call-Stack
  • Event-Loop
  • AWS
  • CI/CD
  • Jenkins
  • Actions
  • EKS
  • React
  • JavaScript
  • TypeScript
  • NextJS
  • Confluence
  • Figma
  • Jira
  • Notion