리액트 1,2부 이후 후속 강의나 준비 중인 다른 강의가 있으신가요?

강의를 좋게 평가해 주셔서 무척 고맙습니다. 리액트1부 강의를 마치셨다면 2부로 넘어가셔서 훅과 고급 주제를 학습하시길 추천 드립니다. 웹 개발의 기초 지식 중에 HTTP를 이해하고 익히는 수업이 있는데 이것도 같이 수강하시면 도움이 될거에요. https://inf.run/GFc3Z

브라우저 내부 보안 정책 스코프에 대한 질문

좋은 질문입니다. 이 내용은 HTTP 보안정책의 브라우져 내부 동작 원리에 해당되어, 수업 범위를 약간 넘어가긴 합니다. 방향을 잡을 수 있다록 핵심만 말씀드릴게요.브라우져의 보안 정책은 일반적으로 Origin 단위로 적용됩니다.단, 말씀하신대로 쿠키는 조금 넓은 단위로 적용됩니다.브라우져별로 세부 동작이 조금씩 다를수 있을 것 같습니다.

실무에서 웹개발자가 명시적으로 선언하는 보안 정책의 범위 및 보안 정책 설정 위임 라이브러리

Express.js를 예로 들면CORS: cors 공식 미들웨어를 통해 손쉽게 설정할 수 있습니다.예를 들어 app.use(cors({ /* 설정 옵션 */ }))쿠키 보안 속성: 프레임워크 자체의 res.cookie() 같은 API로 설정할 수 있습니다.CSP 헤더는 주로 서버 레벨(Nginx, CDN)이나 빌드된 HTML을 반환하는 구간데서 설정합니다.Express 환경이라면 helmet 같은 미들웨어를 통해 대부분의 보안 헤더를 쉽게 추가할 수 있습니다.

pushState로 주소를 바꾸면 렌더링이 안 되는 이유가 궁금합니다.

pushState는 브라우져의 히스토리 상태만 변경합니다. 리액트 컴포넌트는 이 상태와 전혀 상관없는 객체이고요. 그렇기 때문에 별도의 리액트 상태(path)를 두었는데요. 이를 변경해 리액트 컴포넌트가 다시 그려지도록(리렌더) 의도한 것입니다.정리하면,pushState: 히스토리 상태 변경 setState: 리액트 컴포넌트 상태 변경 → 리렌더 유발

2025년 기준 번들러 트렌드와 선택 기준이 궁금합니다 (Webpack, Vite, tsup 등)

정말 깊이 있는 질문을 주셔서 감사합니다. 말씀하신대로 요즘은 웹팩 뿐만 아니라 다양한 번들러가 나왔고 프로젝트마다 사용하는 도구가 다르긴 합니다. 최근에는 Vite가 거의 표준처럼 자리잡았다고 봅니다. 대부분의 신규 프로젝트에서 이 도구를 사용하고 있는데요. 개발 서버 속도가 매우 빠르고, 개발/프로덕션 빌드에 각 각 다른 번들러를 사용해 안정성도 유지하는 구조 덕분이라고 생각합니다. UI 컴포넌트 라이브러리, 예를 들어 디자인 시스템이나 내부 공용 컴포넌트를 제작할 때는 Rollup을 가장 많이 사용하고요. 오래된 프로젝트라면 여전히 웹팩을 많이 사용하고 있습니다. 다양한 생태계의 이점도 있고 수년간 유지해온 설정으로 쉽게 바꿀 수는 없더라고요. 강의 내용이 최신 트렌드와 다소 차이가 있긴해요. 하지만 "번들러의 동작 원리"를 이해하고 직접 최신 도구에 적용하는 과정에서 크게 성장할수 있다고 생각합니다. 실무 감감을 키우는 방법이기도 하고요. 소중한 의견 남겨주셔서 매우 감사합니다.

ETag 사용시 서버의 성능 향상

ETag를 활용한 캐싱 기법은 브라우져와 서버 모두 성능 향상에 영향을 줄 수 있습니다. 브라우져에서는 ETag를 이용해 이미 다운로드한 파일을 재사용함으로써 네트워크 요청을 덜 보낼 수 있습니다. 말씀하신대로 네트워크 대역폭을 아낄수 있어요.서버는 If-None-Match 요청헤더 값을 확인 한 뒤, 요청한 리소스와 같은 값이라면 "즉시" 응답을 보냅니다. 만약 이 값이 다르다면, 서버는 "리소스를 읽고 이를 응답 본문에 실어야"하는데요. ETag를 사용하면 이러한 서버 리소스를 아낄수 있는 이점이 있습니다.

super.show() 호출하는 이유가 궁금합니다.

부모 클래스의 show() 메소드를 호출하지 않아도 동작하는데요. 이는 SearchFormView가 화면에서 사라진(hide() 메소드 호출)적이 없이 때문입니다.그래도 부모 메소드를 오버라이딩하는 경우에는 부모의 메소드를 호출해 주는 것이 좋습니다. 부모 View 클래스는 css 속성 display를 변경하면서 화면의 노출여부를 제어하는 hide()와 show() 메소드를 제공합니다. 이를 상속한 자식 클래스 SearchFormView는 이 메서드를 이용해 화면에 숨기고 노출할 수 있는데요. 이런 효과를 얻으려면 부모의 메소드를 호출해 주어야합니다. 비슷한 질문super.show()에 대해 질문드립니다

next.js 와 SOP

네, 이해하신게 정확히 맞습니다. Next.js는 서버에서 정적파일(html/css/js)과 api를 함께 제공하는 구조인데요. 브라우져가 api를 호출할 때, 정정파일의 출처와 같기 때문에 SOP와 관련한 문제를 겪지 않으셨을 거에요.

사전 요청 관련 질문

좋은 질문입니다. 두 가지로 나눠서 말씀 드려볼게요.1) GET과 POST 요청만 사용하는 것Preflight를 피하려고 HTTP 메소드를 제한하는 것은 권장드리지 않습니다. PUT, PATCH, DELETE는 각자 자원의 수정, 부분 수정, 삭제를 의미하는 대표 메서드에요. 모든 요청을 GET/PUT으로만 구현하면 API 의미가 불분명해지고 유지보수 면에서 불리할 수 있습니다.Preflight 요청은 브라우져의 필수 안전장치에요. 요청을 보내기 전에 서버가 허용하는 확인하기 위해 OPTIONS를 사용하는데요. 이 과정은 보안상의 이유로 안쓰는 것 보다는 잘 다루는 게 중요합니다.2) GET/POST만 사전요청을 안하는 것안전한 요청일 경우에 Preflight 요청을 보내지 않는다고 설명드렸는데요. 강의에서 다뤘던 조건 외에도 Content-Type 헤더의 값도 검사합니다.application/x-www-form-urlencoded multipart/form-data text/plainPOST 메소드를 사용하면 Content-Type: application/json 를 주로 사용하는데요. 이 경우에는 단순 요청이 아니기 때문에 Preflight 요청을 보냅니다.참고: https://developer.mozilla.org/ko/docs/Web/HTTP/Guides/CORS

rest api 에서의 csrf

질문 주셔서 감사합니다. REST API를 사용하는 경우는 두 가지로 생각할 수 있을 것 같아요.1) 쿠키 기반 인증을 사용하는 API: 브라우져가 서버에게 받은 쿠키를 요청 헤더에 실어 보내는 구조이기 때문에 CSRF 공격에 취약할수 있습니다. 이를 보완하기 위해 CSRF 토큰으로 예방합니다.2) 토큰 기반 인증을 사용하는 API: 브라우져에서 실행되는 자바스크립트 어플리케이션이 서버에게 받은 토큰 값을 요청 헤더에 '직접' 실어 보내는 구조라서 CSRF 공격에 덜 취약합니다.하지만 브라우져에서 관련한 보안 조치를 지원하고(실습에서는 브라우져 설정을 변경함), 서버에서 쿠키를 발급할 때 보안 정책을 적용하기 때문에 어느정도 공격에 안전하다고 볼 수 있습니다.