백오피스를 개발할 때 아키텍처 구성에 대한 질문

안녕하세요 gaabi1204님, 제가 너무 늦게 확인했네요. 많이 기다리셨을텐데 이제야 답변드려서 정말 죄송합니다.리액트 기반으로 백오피스를 개발하셔야하는 상황인 것 같네요. 회사 표준 기술스택이 없다면 오픈소스 라이브러리를 적극 활용하시게 될텐데, 무엇을 선택할지 고민이 많으실 것 같아요.저는 이런 상황에 보통 대중적인 Ant Design이나 Material UI을 사용하긴 합니다. 가장 많이 쓰이고 있고 자료도 많아서 무난하게 사용했던 것 같습니다. 특히 라이브러리를 선택할 때는 문서나 커뮤니티의 트러블슈팅 자료가 많은 게 문제 해결에 도움이 되었어요. 어려움을 겪으셨던 Quasar는 아직 사용해 보지 않아서 정확한 답변을 드리기 어려울것 같습니다.검증 라이브러리도 Formik이나 React Hook Form을 이용하면 대부분의 요구사항을 구현하실 수 있을 거에요. 추후 스키마 기반의 검증 구조(yup, zod 등)로 전환하실 수도 있구요. 답변이 충분한지 모르겠네요. 라이브러리 선택에서 가장 중요한 건 안정성이라고 생각합니다. 사용자 층이 많고 관련 트러블슈팅 자료가 충분하다면 바꾸지 않고 오랫동안 사용할 수 있었던 것 같았어요.

useEffect 의존성 질문

안녕하세요 dev.mingyo님. 영상에서 useEffect 의존성 배열에 path 를 넣은 것에 대해 질문 주셨네요. 결론부터 말씀드리면, 안 넣는 것이 맞습니다. 부수 효과는 "popstate" 이벤트 핸들러를 등록하는 역할이고요. path는 history 객체에 전달하는 용도로 사용되는데요, 마운트 시점의 값으로도 충분해서 한 번만 실행되어도 됩니다. 오히려 path를 의존성으로 전달하게되면 path 변경에 따라서 이벤트 등록/해지 과정이 불필요하게 반복되는 낭비가 있긴해요.영상에서는 놓쳤지만, 실습 코드에서는 의존성이 없는 점도 참고해 주시면 수업을 따라오시는 데 덜 헷갈리실 것 같습니다.

잘못된 useEffect 사용?

안녕하세요 dev.mingyo님. 리액트의 핵심원리를 날카롭게 지적해 주셨네요.결론부터 말씀드립니다. 네, 맞습니다. 해당코드는 useEffect를 오용한 사례가 맞습니다. 불필요한 렌더링리액트는 상태가 변하면 렌더링을 수행하는데요. 사용자가 값을 입력 함 → setValue 호출 (1차 렌더링)렌더 직후 useEffect 실행 → setErrors 호출 (2차 렌더링)한 번만 입력해도 브라우져는 매번 두 번씩 화면을 그리는데요, 서비스가 커질수록 성능 저하의 원인이 될수 있습니다.개선 방향 errors 상태를 두었지만 실은 values를 통해 파생될수 있는 값입니다. 공식 문서에서 강조하듯, 기존 상태를 조합해서 만들 수 있는 값은 별도의 상태로 두지 않는 것이 유지보수에 훨씬 유리해요. errors를 직접 렌더링 내의 변수로 선언하는 것이 '리액트다운' 해결책입니다.// ❌ 기존 방식: 불필요한 렌더링 발생 // const [errors, setErrors] = useState({}); // useEffect(() => { setErrors(validate(values)) }, [values]); // ✅ 파생된 상태로 처리 (useState/useEffect 제거) const errors = validate(values);이렇게 작성하면 values가 바뀔 때 리액트가 렌더링을 시작하고, 최신 errors 값을 계산하여 화면에 그립니다. 코드도 훨씬 간결해지고 성능도 최적화될 수 있습니다.

orderableProductItem 에 관하여...

안녕하세요 컴포넌트 구조에 대한 질문을 주신것 같네요. 컴포넌트는 어플리케이션이 성장하면서 그 구조도 달라질수 있는데요. ProductItem과 OrderableProductItem을 이러한 관점으로 이해하시면 좋습니다.상품 상세: ProductItem으로 상품 정보와 주문하기 버튼을 렌데링합니다. 이후 장바구니에서도 비슷한 UI를 렌더 하는데요. 상품 상세와 비슷해 ProductItem을 재사용하려는 판단에서 시작합니다.장바구니: 상품상세에서는주문하기버튼이있지만장바구니에서는없어서이러한조건부렌더링을 ProductItem 역할로두었습니다. 상품상세에서는버튼까지렌더하도록조합할수있고요(onClick 전달). 장바구니에서는버튼이렌더되지않도록사용할수있게됩니다(onClick 생략). 마지막엔가독성을위해서이러한조합으로 OrderableProductItem이란컴포넌트를신설한것입니다.

강의 자료, 블로그, 깃 주소

강의 본문에 링크가 제대로 연결되어 있지 않았네요. 샘플 어플리케이션 코드 | 깃헙요구사항 문서 | 깃헙강의 노트 | 김정환블로그본문도 수정해 두었습니다.

React 훅 구현 원리와 실무 패턴 관련 질문 (useState, useEffect 순서 및 핸들러 구조)

기능을 구현하다보면 상태가 늘어가는 경우는 빈번한데요. 이때 상태 관리로 인해 파생되는 핸들러나 이펙트도 늘어나 코드 관리가 어려운 순간이 있습니다. 이에 대한 질문을 주신 것 같아요. 저는 상태 관리가 많아져 한 컴포넌트에서 관리하기 어렵다면, 별도의 역할을 하는 컴포넌트로 분리하거나, 커스텀 훅으로 분리해 사용합니다. 관련된 리액트 앨리멘트 반환로직까지 컴포넌트로 분리한다면, 이를 JSX 문법으로 간편히 가져다 사용할수 있을겁니다. 커스텀 훅으로 분리한다면, 추상화 계층으로 복잡한 로직을 숨기고 컴포넌트에서는 이를 통해 관련된 상태와 핸드러를 제공 받을 수 있어요. 다른 사람이 작성한 코드를 많이 보고, 여러 번의 시행착오 경험을 겪으면 균형잡힌 컴포넌트 설계 기법을 갖추실 수 있을거에요.

지금 시점에서 해당 강의를 듣는 것에 대하여

안녕하세요, 강의 수강 관련해 문의 주셔서 감사합니다.최신 개발환경에 비해 수업에서 사용하는 라이브러리 버전이 맞지 않긴합니다. 하지만 버전과 무관한 기본 원리에 대한 내용을 배우실수 있을 거에요. 개념을 탄탄히 이해하고 나시면 다른 도구를 만나더라도 훨씬 자신감 있게 다루실수 있을 겁니다. 이와 관려한 후기들도 올려주셨는데요, 참고해 보시면 강의 수강을 결정하는 데 도움이 되실 것 같습니다.https://inf.run/8XzcVhttps://inf.run/2N6rehttps://inf.run/VSRZc

리액트 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 같은 미들웨어를 통해 대부분의 보안 헤더를 쉽게 추가할 수 있습니다.