TIL #65 React 기술 면접 준비 -1

DO YEON KIM·2024년 7월 24일
1

부트캠프

목록 보기
65/72

하루 하나씩 작성하는 TIL #65


1. 상태관리는 왜 할까요? 그리고 평소 상태관리는 어떻게 하시나요?

🧁 의도: 상태 관리의 목적과 평소 상태 관리 패턴 파악 및 전역 상태 관리에 대해서도 추가 답변(사용하는 라이브러리 등)을 기대하는 질문.

🧁 모범 답안:

상태관리의 필요성은 리액트의 MVVM 패턴과 관련지어 설명할 수 있습니다. Model-View-ViewModel 패턴에 따라 상태는 Model에, 화면 UI는 View에 역할을 위임함으로써 서로의 독립성을 확보할 수 있습니다. 이에 따라 개발자는 각각을 다른 관점에서 파악함으로써 각자의 기능에 집중해 개발할 수 있는 환경을 구축할 수 있습니다.

저의 경우에는 이를 실현하기 위한 방법의 하나로 커스텀 훅을 사용하여 Model 부분의 재사용성과 독립성을 향상시켰습니다. 또한 하나의 상태를 여러 컴포넌트가 바라볼 때 나타나는 props-drilling과 같은 문제를 해결하기 위해 Redux 등의 전역 상태 관리 도구를 사용한 경험이 있습니다.

🧁 한 줄 요약 : 독립성을 확보할 수 있습니다. 이에 따라 개발자는 각각을 다른 관점에서 파악함으로써 각자의 기능에 집중해 개발할 수 있는 환경을 구축


2. Redux 말고 다른 전역 상태 관리 라이브러리를 사용해 본 적이 있으신가요?

🧁 의도: 다양한 상태관리 라이브러리에 대한 지식과 경험 소개 및 해당 라이브러리를 선택하게 된 구체적인 이유를 설명할 수 있는지 확인하는 질문

🧁 모범 답안:

네 저는 Redux 외에 Zustand라는 전역 상태 관리 라이브러리를 사용한 경험이 있습니다. 기존 리덕스와는 다르게 Zustand는 보일러 플레이트가 단순하여 더욱 빠른 환경 설정이 가능하다는 장점이 있습니다. 예를 들어 리덕스에서 작성해야 했던 액션, 리듀서, 디스패치, 미들웨어 등 대신에, Zustand에서는 create 메서드를 통해 atomic 한 객체를 생성하는 것으로 앞선 과정을 단축할 수 있습니다.

또한 Redux에서 채택했던 Flux 아키텍처를 그대로 가져와 사용하였기에 이 또한 저에게 아주 큰 매력으로 다가왔습니다. 왜냐하면 Redux Tool Kit을 포함해 리덕스를 사용할 때의 가장 큰 장점으로 체감할 수 있었던 것은 바로 개발자 도구(devtool)의 유용함 덕분이었습니다. Zustand는 리덕스의 Flux 아키텍처를 그대로 채택하였기에 기존 리덕스의 개발자 도구를 이어서 사용할 수 있게 되었고, 이는 곧 저에게 있어서 더 이상 리덕스를 사용해야 할 이유를 모두 잃은 것과 다름 없었습니다.

🧁 한 줄 요약 : Redux 외에 Zustand라는 전역 상태 관리 라이브러리를 사용한 경험. Zustand는 보일러 플레이트가 단순하여 더욱 빠른 환경 설정이 가능하다는 장점


3. 리액트에서 가상 돔을 사용하는 이유에 대해 설명해주세요.

🧁 의도: 리액트의 기본 원리와 가상 돔의 핵심을 이해하고 있는지, 그리고 가능하면 useState와의 관계성도 설명할 수 있는지 확인하는 질문

🧁 모범 답안:

실제 돔은 HTML의 요소를 트리로서 가지고 있는 객체 기반의 모델이며, 브라우저는 실제 돔을 기반으로 화면을 렌더링합니다.

반면에 가상 돔은 실제 돔을 경량화한 복사본으로, 리액트의 최적화를 위해 사용됩니다. 실제 돔을 직접 조작하는 것은 성능 비용이 큰 작업이기 때문에, 리액트는 상태가 업데이트 될 때마다 우선 빠르고 가벼운 가상 돔을 업데이트하고, 결과를 실제 돔과 비교합니다. 이후 변경된 부분만 실제 돔에 반영함으로써 불필요한 리소스 사용을 최소화하고 성능을 향상시킵니다.

이 과정을 가장 쉽게 살펴볼 수 있는 리액트의 메서드는 바로 useState입니다. 이 상태관리 훅을 통해 상태를 업데이트하면 상태 값이 곧바로 반영되지 않습니다. 왜냐면 상태 업데이트는 그저 변수에 데이터를 담아내는 것이 아니라, 앞서 설명했던 가상 돔과 실제 돔의 비교 과정이 실행되기 때문입니다. 상태 값이 자기 자신을 참조하여 상태를 업데이트할 때 생기는 오류는 대부분 이 때문입니다. 이러한 문제를 해결하기 위해 useState 훅에 값이 아닌 콜백 함수의 참조를 인자로 전달할 수 있습니다.

🧁 한 줄 요약 : 실제 돔을 경량화한 복사본으로, 리액트의 최적화를 위해 사용. 변경된 부분만 실제 돔에 반영함으로써 불필요한 리소스 사용을 최소화하고 성능을 향상


4. useEffect의 실행 순서를 컴포넌트 라이프 사이클에 관련지어 설명해주세요.

🧁 의도: 컴포넌트 라이프 사이클과 useEffect의 이해도를 가지고 있는지, 각 라이프 사이클에서 어떤 작업을 처리해야 하는지 설명할 수 있는지 확인하는 질문.

🧁 모범 답안:

컴포넌트 라이프 사이클을 간단하게 설명하자면 create-mount-update-unmount로 함축할 수 있습니다. create는 컴포넌트가 말 그대로 생성된 것입니다. 중요한 것은 이 다음부터입니다.

mount는 컴포넌트가 생성된 후에 실제 돔에 렌더링 되는 순간을 뜻합니다. mount의 한글 뜻인 장착에서 유추할 수 있습니다. 그리고 이 순간이 바로 useEffect 내부의 코드가 실행되는 시기입니다. 컴포넌트가 화면에 렌더링 되었기 때문에 이때 HTML 태그를 가져와 이벤트를 등록하거나, 데이터를 fetching 해오는 등의 작업을 처리하게 됩니다.

update는 컴포넌트에 변화가 생겼을 때를 뜻합니다. useEffect의 의존성 배열을 사용하면 특정 값이 변경될 때마다 내부의 작업을 실행할 수 있도록 조절할 수 있습니다.

unmount는 컴포넌트가 실제 돔에서 사라지는 순간을 뜻합니다. mount의 반대라고 생각하시면 됩니다. useEffect에서는 내부의 return 값에 함수의 참조를 넘겨주어 unmount시 특정 작업이 실행되게 하는데, 이를 클린업 함수라고 합니다. 주로 mount시에 등록했던 이벤트를 제거하는 등 메모리 누수를 막기 위한 작업을 실행합니다.

🧁 한 줄 요약 : 라이프 사이클 -> create-mount-update-unmount.


5. 리액트의 리스트 렌더링에서 key는 왜 넣어줄까요? 그리고 key 값이 유니크해야 하는 이유는 뭘까요?

🧁 의도: 자칫 지나치기 쉬운 리액트의 기본 개념에 대해 확인하는 질문

🧁 모범 답안:

네, 리스트 렌더링에서 key 속성은 리액트에게 있어서 각 요소를 식별하는 데에 사용되는 값입니다. 이 key 가 있어야 리액트는 가상 돔에서 어떤 요소가 어디에 있고, 어떻게 순서가 바뀌었는지 등의 순서와 변화를 제대로 감지할 수가 있습니다. 그래서 저의 경우에는 보통 유니크한 id 값을 key에 할당하는 편입니다.

🧁 한 줄 요약 : 요소를 식별하는 데에 사용되는 값. key가 있어야 리액트는 가상 돔에서 어떤 요소가 어디에 있고, 어떻게 순서가 바뀌었는지 등의 순서와 변화를 제대로 감지. 유니크한id값을key`에 할당


6. 리액트의 개발 서버에서는 useEffect가 2번 실행되는 모습이 관찰되는데요. 그 이유가 무엇일까요?

🧁 의도: 자칫 지나치기 쉬운 리액트의 기본 개념을 확인하는 질문. 개발에 호기심이 많아야 알 수 있는 항목입니다.

🧁 모범 답안:

단도직입적으로 말씀드리자면 바로 리액트의 StrictMode 때문입니다. 이 모드를 켜게 되면 오류를 피할 수 있도록 엄격한 개발 환경을 제공해주는데요. 여기서 useEffect가 2번 실행되는 이유가 있습니다.

예를 들어서 개발자가 언마운트 상황을 테스트하려고 합니다. 언마운트 시에 클린업함수가 잘 작동하는지 여부를 확인하려고요. 이 상황을 테스트하려면 매번 컴포넌트를 마운트하고, 언마운트하고 수동으로 실행해줘야만 합니다. 당연히 번거롭겠죠. 그래서 리액트는 처음에 컴포넌트가 생성된 이후 마운트-언마운트-다시 마운트의 과정을 거치게 됩니다.

이렇게 함으로써 개발자는 따로 수동으로 작동해주지 않아도 언마운트 상황을 테스트 할 수 있게 됩니다. 물론 개발 서버 한정이고, 배포 서버에서는 자연스럽게 마운트-언마운트 한 사이클만 진행이 됩니다.

🧁 한 줄 요약 : 리액트의 StrictMode 때문. 이 모드를 켜게 되면 오류를 피할 수 있도록 엄격한 개발 환경을 제공. 개발자가 언마운트 상황을 테스트하려고 할 때 , 클린업 함수가 작동하는지 여부를 확인시, 마운트-언마운트-수동실행을 해줘야함.


7. 커스텀 훅을 사용해보셨나요? 사용해본 경험을 이야기해주세요.

🧁 의도: 커스텀 훅을 사용할 정도로 코드 퀄리티에 관심이 있는지 파악하려는 질문

🧁 모범 답안:

네 저는 최근 프로젝트에서 커스텀 훅을 사용한 경험이 있습니다. 개인적으로도 정말 잘 사용하고 있는 기술이기도 합니다. 커스텀 훅을 사용한다면 기존의 컴포넌트 내부에 작성된 코드를 커스텀 훅을 만들어 정리하는 것으로 컴포넌트 내부를 좀 더 클린하게 정리할 수 있을 뿐더러 만들어진 커스텀 훅을 좀 더 보편적으로 개선하여 다른 컴포넌트에서도 재사용할 수 있습니다. 또한 비즈니스 로직의 분리를 실현하여 의존성을 줄이고 유지 보수성을 높일 수 있는 등 다양한 장점이 많습니다.

사소한 단점으로는 커스텀 훅의 이름을 잘 지어줘야 다른 개발자들이 굳이 커스텀 훅의 내부를 들여다 보는 수고를 하지 않을 수 있다는 점이 있겠네요. 어찌보면 선언형 코드와 장단점을 공유하는 듯 합니다.

저 같은 경우에는 useLocalStorage 훅을 작성하여 기존에 로컬 스토리지에 저장하고 읽어올 때 반복되는 로직을 통합하여 재사용성을 목적으로 구현한 바 있습니다. 기존에는 JSON.parseJSON.stringify 같은 메서드를 매번 호출해서 읽고, 저장해야 했지만 이 커스텀 훅을 구현함으로써 기존의 useState와 같은 사용감을 만들어냈습니다.

🧁 한 줄 요약 : 컴포넌트 내부를 좀 더 클린하게 정리할 수 있을 뿐더러 만들어진 커스텀 훅을 좀 더 보편적으로 개선하여 다른 컴포넌트에서도 재사용.


8. 리액트 컴포넌트의 렌더링 성능 향상에 쓰이는 React.memo에 대해 설명해주세요.

🧁 의도: 성능 최적화에 관심이 있는지 확인하는 질문

🧁 팁: 사용 예시를 들면 좋습니다.

🧁 모범 답안:

리액트에서 컴포넌트가 리렌더링 되는 기준을 살펴보자면 대표적으로 받아온 props의 변경이 있습니다.

props가 변경되면 하위 컴포넌트 모두가 리렌더링됩니다. 그런데 만약 props의 변경과 하위 컴포넌트의 리렌더링과 관련이 없다면 어떨까요? 필요한 부분만 업데이트하고 나머지는 그대로 두기 위해 사용하는 것이 바로 React.memo입니다.

예를 들어서 리스트 렌더링에서 리스트 아이템에 React.memo를 붙여주게 되면 리스트에서 변경된 부분의 아이템만 리렌더링할 수 있습니다. 리스트 전체를 리렌더링하지 않음으로써 성능을 최적화하는 것이 가능해진 겁니다.

🧁 한 줄 요약 : 필요한 부분만 업데이트하고 나머지는 그대로 두기 위해 사용하는 것. 리스트 전체를 리렌더링하지 않음으로써 성능을 최적화하는 것이 가능


9. React.Suspense에 대해 설명해주세요.

🧁 의도: 비동기 데이터 로딩 및 렌더링 과정을 이해하고 Suspense를 사용할 수 있는지 확인하는 질문

🧁 모범 답안:

네 리액트의 Suspense는 비동기 데이터를 로딩할 때, 그리고 로딩 상태를 표시할 때 사용하면 좋은 선언형 코드의 일종입니다. Suspense에는 fallback 속성을 줄 수 있는데 이 속성이 바로 로딩 상태일 때 화면에 보여줄 요소가 됩니다.

선언형 코드이니만큼 기존에는 로딩 상태 표시를 위해 isLoading으로 상태를 관리해 로딩 화면을 조건부 렌더링을 해주었다면, 이제는 태그에 속성을 주는 것만으로 간결하게 구현할 수 있다는 장점을 가지고 있습니다. 다만 주의할 점은 특정 비동기 데이터 호출 라이브러리만 Suspense를 지원하기 때문에 잘 알아보고 적용해야 합니다.

🧁 한 줄 요약 : 비동기 데이터를 로딩할 때, 그리고 로딩 상태를 표시할 때 사용하면 좋은 선언형 코드의 일종


10. 리액트의 상태가 불변성을 유지하는 이유는 무엇일까요?

🧁 의도: 무의식적으로 사용하고 있던 개념에 대해 확인하는 질문

🧁 모범 답안:

네 리액트는 불변성을 유지하도록 설계되었습니다. 그래서 잘 아시다시피 상태를 변경하려면 직접 변경하는 것이 아니라, 새로운 객체를 만들어서 할당해주어야 합니다. 이러한 불변성을 유지하는 것에는 여러 이유가 있는데 그중 대표적으로 불변성 덕분에 리액트는 상태가 언제 어떻게 변경되었는지 추적하기가 쉬워집니다.

만약 직접 변경한다면 무엇이 언제 어떻게 변경되었는지 추적하기 쉽지 않을 것입니다. 리덕스나 리액트의 개발자 도구를 보면 상태가 어떻게 변화되었는지 찾아보는 게 굉장히 유용한데, 이게 다 불변성 덕분입니다.

다만 불변성을 유지하는 게 개발자 입장에서는 어려울 수도 있는 일이라 immer 같은 라이브러리를 이용해 대신 불변성을 유지할 수 있도록 위임하는 일도 가끔 있습니다. 오히려 리덕스 툴킷에는 내장되어 있는 기능이기도 하니 불변성을 유지하다보니 코드가 어지러워진다고 생각하면 도입을 적극 고려해야 한다고 생각합니다.

🧁 한 줄 요약 : 상태가 언제 어떻게 변경되었는지 추적하기가 쉬워짐.


11. 리액트의 제어 컴포넌트와 비제어 컴포넌트의 차이에 대해 설명해주세요.

🧁 의도: 리액트에 폼을 어떻게 다루었는지 확인하는 질문

🧁 모범 답안:

네, 저는 리액트에서 폼을 다룰 때 제어 컴포넌트와 비제어 컴포넌트에 대해 익혔습니다. 리액트에서 폼을 다루는 방법에는 크게 두 가지가 있습니다. 바로 제어 컴포넌트와 비제어 컴포넌트 방식입니다.

간단히 설명하자면 제어 컴포넌트는 폼의 데이터를 매번 상태에 저장해 관리하는 방식입니다. 말 그대로 onChange 이벤트를 통해 모든 입력 값을 제어하고 있는 것입니다. 그에 비해 비제어 컴포넌트는 폼의 데이터를 상태에 저장하지 않고, onSubmit 이벤트 같은 폼의 제출 때만 입력 값을 확인합니다. 제어 컴포넌트의 특징은 모든 데이터를 입력마다 제어할 수 있다는 것이고, 그 대신에 코드가 좀 길어질 수 있다는 점입니다.

반대로 비제어 컴포넌트의 특징은 제출 시에만 입력 값의 검증 등을 실행할 수 있는 대신 코드가 단순해진다는 점이 있습니다.

🧁 한 줄 요약 : 제어 컴포넌트는 폼의 데이터를 매번 상태에 저장해 관리하는 방식. onChange` 이벤트를 통해 모든 입력 값을 제어.

비제어 컴포넌트는 폼의 데이터를 상태에 저장하지 않고, onSubmit 이벤트 같은 폼의 제출 때만 입력 값을 확인


12. flux 아키텍처를 설명해주세요.

🧁 의도: 리덕스에서 쓰였던 flux 아키텍처의 작동 방식을 알고 있는지 확인하는 질문

🧁 팁: 마치 리덕스를 쓸 때처럼 순서대로 얘기하면 좋습니다.

🧁 모범 답안:

네 flux 아키텍처는 단방향 데이터 흐름을 기반으로하는 아키텍처입니다. 이러한 flux 아키텍처는 불변성 개념을 탑재하여 디버깅에 용이하다는 장점이 있습니다.

flux 아키텍처의 흐름을 순서대로 말씀드리겠습니다. 우선 유저는 View에서 Action을 Dispatch합니다. 그리고 Dispatch된 Action은 곧 Store로 전달됩니다. Store는 Reducer를 사용하여 Action을 판별하고 상태를 업데이트합니다.

그리고 상태가 업데이트 되면 Observing하고 있던 모든 View에게 내용을 알립니다. 마지막으로 View는 업데이트된 내용을 기반으로 리렌더링합니다. 확실히 과정이 좀 복잡하긴 해도 리덕스, Zustand 등 인기가 많은 전역 상태 관리 라이브러리에서 채택하고 있는 아키텍처인만큼 유용한 건 확실하다고 생각합니다.

🧁 한 줄 요약 : 단방향 데이터 흐름을 기반으로하는 아키텍처. 디버깅 용이.


13. 리액트의 Strict 모드는 왜 필요할까요?

🧁 의도: 개발 환경에 따른 모드에 대해 알고 있는지 확인하는 질문

🧁 모범 답안:

마치 ESLint가 필요한 이유와 같습니다. 우리는 사람이고 누구든지 완벽할 수는 없습니다. 그래서 linter가 안티 패턴을 잡아주는 것이구요.

비슷하게 Strict 모드도 개발 과정에서 발생할 수 있는 잠재적인 문제를 해결하는 데에 도움을 주는 도구입니다. 예를 든다면 잘못된 훅 사용이나 props 전달 등에 대해 경고를 줘서 해결할 수 있도록 돕습니다.

그중 대표적으로는 useEffect의 마운트가 2번 실행되는 효과가 있습니다. 마운트-언마운트-마운트의 과정을 거쳐서 개발자가 직접 수동으로 언마운트 해주지 않고도 언마운트를 테스트할 수 있도록 도와줍니다. 가끔 빠른 개발에 방해된다고 Strict 모드를 끄고 개발하시는 분도 계시지만... 저는 얻는 장점이 더 많다고 생각하여 항상 켜고 사용하고 있습니다.

🧁 한 줄 요약 : 개발 과정에서 발생할 수 있는 잠재적인 문제를 해결하는 데에 도움을 주는 도구. 대표적 예시로는 useEffect의 마운트가 2번 실행되는 효과가 있는데, 개발자가 직접 수동으로 언마운트 해주지 않고도 언마운트 테스트 가능.


14. SPA에 대해 설명해주세요.

🧁 의도: 최근 프론트엔드 패러다임인 Single Page Application에 대해 알고 있는지 확인하는 질문

🧁 팁: 장단점을 명확하게 제시하면 좋습니다.

🧁 모범 답안:

네, SPA는 Single Page Application의 약자로서 리액트나 뷰의 기반이 되는 기술입니다.

이 SPA를 사용한다면 여러 장단점이 있는데요. 우선 장점부터 말씀드리겠습니다. 기존에 MPA를 사용하면 페이지를 이동할 때마다 새로 고침이 계속 일어났는데, SPA를 사용하면 이런 일이 없습니다.

라우터로 페이지를 이동하기는 하지만 사실 내부적으로는 MPA의 개념처럼 페이지를 이동하는 게 아니기 때문입니다. 그저 URL을 바꿔주고, 그 URL 에 따라 화면의 컴포넌트를 바꿔치기 해주는 것으로 새로 고침 없이 새로운 화면을 볼 수 있게 해주는 것이 큰 장점입니다.

이외에 클라이언트 사이드 렌더링을 사용하여 서버의 부담을 줄이고 빠른 화면 전환 등 로딩 속도를 개선할 수 있습니다. 다만 대표적인 단점으로는 SEO에 취약하다는 점과 초기 로딩이 느리다는 점이 있습니다.

그래서 요즘은 SPA 기반 앱에서 SSR과 CSR을 모두 혼합하여 장점만 가져와 사용할 수 있는 Next.js 프레임워크가 인기있는 편입니다.

🧁 한 줄 요약 : SPA는 Single Page Application의 약자로서 리액트나 뷰의 기반이 되는 기술. 클라이언트 사이드 렌더링을 사용하여 서버의 부담을 줄이고 빠른 화면 전환 등 로딩 속도를 개선. 단점으로는 SEO에 취약하다는 점과 초기 로딩이 느리다는 점.


15. Redux Toolkit을 이해하고 Flux 패턴에 대한 이해를 가질 수 있습니다.

🧁 의도: 지원자가 Redux Toolkit을 통해 상태 관리의 기본 개념과 Flux 패턴을 이해하고 있는지 평가.

🧁 팁:

  • Redux Toolkit이 무엇인지, 상태 관리를 어떻게 단순화하는지 설명하세요.

  • Flux 패턴의 개념과 Redux가 이를 어떻게 구현하는지 설명하세요.

  • Redux와 Redux Toolkit의 차이점을 언급하세요.

🧁 모범답안:

  • Redux Toolkit은 Redux를 쉽게 사용할 수 있게 해주는 도구로, 상태 관리를 단순화하고 보일러플레이트 코드를 줄입니다.

  • Flux 패턴은 데이터의 흐름을 단방향으로 유지하는 패턴으로, 상태의 일관성을 유지하는 데 도움을 줍니다.

  • Redux는 Flux 패턴을 기반으로 하여 상태를 중앙에서 관리하고, 액션을 통해 상태를 업데이트합니다.

🧁 한 줄 요약 : 위와 같음.


16. RESTful API에 대해 이해하고 설명할 수 있습니다.

🧁 의도: 지원자가 RESTful API의 개념과 이를 사용하는 방법을 이해하고 있는지 평가.

🧁 팁:

  • REST의 정의와 원칙을 설명하세요.

  • RESTful API의 주요 특징과 HTTP 메서드(GET, POST, PUT, DELETE)의 사용 사례를 언급하세요.

  • RESTful API를 사용하는 예제를 떠올려 보세요.

🧁 모범답안:

  • REST는 Representational State Transfer의 약자로, 자원을 URI로 표현하고 HTTP 메서드를 통해 조작하는 아키텍처 스타일입니다.

  • RESTful API는 클라이언트와 서버 간의 통신을 위한 인터페이스로, 일관성과 예측 가능성을 제공합니다.

  • GET은 데이터를 조회할 때, POST는 데이터를 생성할 때, PUT은 데이터를 업데이트할 때, DELETE는 데이터를 삭제할 때 사용됩니다.

🧁 한 줄 요약 : 자원을 URI로 표현하고 HTTP 메서드를 통해 조작하는 아키텍처 스타일. GET은 데이터를 조회할 때, POST는 데이터를 생성할 때, PUT은 데이터를 업데이트할 때, DELETE는 데이터를 삭제


17. HTTP 프로토콜에 대한 기본 개념과 동작 방식을 이해합니다.

🧁 의도: 지원자가 HTTP 프로토콜의 기본 개념과 동작 방식을 이해하고 있는지 평가.

🧁 팁:

  • HTTP의 정의와 주요 특징을 설명하세요.

  • HTTP 요청과 응답의 구조를 설명하세요.

  • 상태 코드(200, 404, 500 등)의 의미를 언급하세요.

🧁 모범답안:

HTTP는 Hypertext Transfer Protocol의 약자로, 웹 브라우저와 서버 간의 데이터 통신을 위한 프로토콜입니다.

HTTP 요청은 메서드, URL, 헤더, 바디로 구성되며, 응답은 상태 코드, 헤더, 바디로 구성됩니다.

상태 코드는 요청의 결과를 나타내며, 200은 성공, 404는 리소스를 찾을 수 없음, 500은 서버 오류를 의미합니다.

🧁 한 줄 요약 : 웹 브라우저와 서버 간의 데이터 통신을 위한 프로토콜


➕ 튜터님께서 아침마다 올려주시는 면접에 좋을 참고 영상

CORS

토스의 Funnel

js 클로저

가상 돔

저장소

profile
프론트엔드 개발자를 향해서

0개의 댓글

Powered by GraphCDN, the GraphQL CDN