할일 관리 앱(메모이제이션)

안녕하세요. 수코딩입니다.Codingbear님의 답변 내용이 맞습니다.해당 부분이 아니라 map() 메서드처럼 반복 렌더링 하는 부분의 코드가어떻게 되어있는지 확인해봐야 합니다.sucoding@naver.com으로 전체 코드를 압축해서 보내주셔도 됩니다.감사합니다!

Web 플랫폼 등록

안녕하세요.카카오 개발자 페이지가 리뉴얼된 이후 실습을 진행하시는 경우, 별도의 웹 플랫폼 등록 없이 애플리케이션만 생성하시면 됩니다.진행 순서아래 링크에서 앱을 생성해 주세요. https://developers.kakao.com/console/app앱 생성 후 바로 "258. (25.12.07) 카카오 개발자 페이지 변경 내용 적용하기" 강의를 따라해 주세요. (해당 강의는 앱 생성 직후의 상태에서 촬영되었습니다)참고 사항현재 시점에서 버튼 클릭 시 반응이 없는 것은 정상입니다. 버튼 클릭 후 페이지 이동 기능은 이후 강의에서 다룹니다."258. (25.12.07) 카카오 개발자 페이지 변경 내용 적용하기" 강의는 모든 개발 완료 후 촬영되어 카카오 로그인이 작동하는 모습을 보여줍니다. 이는 "리뉴얼된 사이트에서 이렇게 설정하면 나중에 카카오 로그인이 정상 작동합니다"를 안내하기 위한 영상입니다.해당 강의에서는 리뉴얼된 카카오 개발자 사이트에서 키 정보를 입력하는 방법만 참고하시고, 이후 학습을 단계적으로 진행해 주세요.

강의 수정이 좀 필요해보입니다.

안녕하세요, 5647kr님!with 키워드는 영상 촬영 당시에는 문제가 없던 키워드였으나,제보해주신 내용을 바탕으로 확인한 결과 현재는 deprecated된 스펙임을 확인했습니다.해당 영상에서는 with 부분을 삭제하고 in 부분만 남겨 수정 후 재업로드하였습니다.영상 시청에 불편을 드린 점 양해 부탁드리며,소중한 제보 감사드립니다.좋은 하루 보내세요!

함수 정의 기준

안녕하세요 정진 서님!리액트에서 함수를 어느 컴포넌트에 정의해야 하는지는 단순한 규칙보다는, 해당 함수가 어떤 역할을 수행하는지를 기준으로 판단하시는 것이 가장 적절합니다. 이를 이해하시기 쉽도록 설명 중간에 간단한 코드를 함께 섞어 설명드리겠습니다.우선, 상태를 변경하는 로직이나 애플리케이션의 핵심 동작과 관련된 함수는 보통 상위 컴포넌트에 정의하는 것이 일반적입니다. 예를 들어 상위 컴포넌트에서 count라는 상태를 관리하고 있다면, 이 값을 변경하는 함수 역시 상위 컴포넌트에 두는 것이 자연스럽습니다.function Parent() { const [count, setCount] = React.useState(0); const increaseCount = () => { setCount(count + 1); }; return ; } 이와 같이 상위 컴포넌트는 상태와 그 상태를 변경하는 함수를 함께 관리하고, 하위 컴포넌트에는 해당 함수를 props로 전달합니다. 이 구조는 리액트의 단방향 데이터 흐름 원칙에 잘 맞습니다.하위 컴포넌트에서는 이벤트가 발생했을 때 상위 컴포넌트에서 전달받은 함수를 호출하게 됩니다. 다만, 이 과정에서 하위 컴포넌트 전용 이벤트 처리 로직이 필요하다면, 하위 컴포넌트 내부에 함수를 정의하는 것도 매우 일반적인 패턴입니다.function Child({ onIncrease }) { const handleClick = () => { console.log("버튼이 클릭되었습니다."); onIncrease(); }; return 증가; } 위 코드에서 handleClick 함수는 하위 컴포넌트의 UI 이벤트를 처리하는 역할만 담당하고 있으며, 실제로 상태를 변경하는 책임은 상위 컴포넌트의 increaseCount 함수가 가지고 있습니다. 이러한 구조는 각 컴포넌트의 책임을 명확하게 분리해 줍니다.강의에서 하위 컴포넌트에도 함수가 정의되어 있는 것처럼 보이는 이유는 대부분 이와 같은 상황 때문입니다. 즉, 하위 컴포넌트에서 이벤트를 직접 처리하고, 필요한 경우 상위 컴포넌트의 함수를 호출하기 위해 중간 단계의 함수가 존재하는 것입니다.결론적으로, 상태를 변경하거나 여러 컴포넌트에 영향을 주는 로직은 상위 컴포넌트에 정의하는 것이 바람직하며, 이벤트 처리나 UI와 밀접한 로직은 하위 컴포넌트에 정의해도 전혀 문제가 없습니다. 결국 함수의 위치는 “이 로직이 어느 컴포넌트의 책임인가”를 기준으로 판단하시면 가장 혼란 없이 설계하실 수 있을 겁니다.

Exclude 이해

안녕하세요!Exclude는 객체의 속성을 비교하여 차이를 계산하는 타입이 아니라, 조건부 타입을 기반으로 T가 U에 할당 가능한지 여부를 판단하여 타입을 제거하거나 유지하는 역할을 합니다. 내부적으로 Exclude는 T extends U ? never : T 형태로 동작합니다.질문에 제시된 코드에서 T5는 name과 age 속성만을 가지고 있으며, U5는 여기에 더해 gender라는 필수 속성을 요구합니다. 따라서 T5는 U5에 할당될 수 없고, 이로 인해 T5 extends U5 조건은 성립하지 않습니다. 그 결과 Exclude의 결과 타입은 never가 아닌 T5가 됩니다.이 상황을 “두 객체의 속성이 모두 일치하지 않기 때문에 첫 번째 타입이 반환된다”라고 이해하는 것은 결과적으로는 맞을 수 있으나, 정확한 개념은 속성의 일치 여부를 비교하는 것이 아니라 할당 가능성(extends 관계)을 기준으로 판단한다는 점입니다.또한 Exclude는 주로 유니언 타입에서 특정 타입을 제거하기 위한 용도로 사용되며, 단일 객체 타입에 적용할 경우에는 실질적인 활용도가 크지 않습니다. 객체 타입에서 원하는 속성만 선택하거나 특정 속성을 제외하여 새로운 타입을 생성하고자 할 때에는 Pick이나 Omit을 사용하는 것이 적절합니다.따라서 질문에서 정리하신 것처럼, 객체 타입의 일부 속성만을 기준으로 새로운 타입을 만들고 싶을 경우에는 Pick이나 Omit을 사용한다고 이해하시면 올바른 방향입니다.

fetch는 사용되는가

안녕하세요.메인으로 사용하는 프레임워크가 리액트라면 fetch 보다는 axios를 더 많이 사용합니다.하지만 Next.js라면 axios 보다는 fetch를 더 많이 사용합니다.이는 두 프레임워크가 추구하는 방향이 다르기 때문인데요. 🙂이를 완벽히 이해하려면 결국 next.js까지 배워야 하기 때문에 지금 당장은 axios를 더 많이 사용하는구나라고 이해하고 계셔도 무방합니다!감사합니다.

전역상태 관리 선택 기준

안녕하세요.전역 상태 관리 방식에는 Redux Toolkit, Context API, Zustand가 있으며, 모두 전역으로 상태를 관리할 수 있다는 공통점을 가지고 있습니다. 다만 각 도구는 사용 목적과 적합한 프로젝트 규모, 그리고 상태의 복잡도에 따라 선택 기준이 달라집니다.먼저 Context API는 리액트에 기본으로 포함된 기능으로, 별도의 라이브러리 설치 없이 사용할 수 있다는 장점이 있습니다. 주로 다크 모드와 같은 테마 설정, 로그인 여부, 언어 설정처럼 구조가 단순하고 변경 빈도가 높지 않은 상태를 전역으로 공유할 때 적합합니다. 그러나 상태가 복잡해지거나 관리해야 할 데이터가 많아질 경우, 불필요한 리렌더링이 발생할 수 있고 유지보수가 어려워질 수 있다는 한계가 있습니다. 따라서 전역으로 공유해야 할 상태가 단순하고 규모가 작을 경우에 선택하는 것이 바람직합니다.Zustand는 비교적 가볍고 사용법이 간단한 전역 상태 관리 라이브러리로, 개인 프로젝트나 중소 규모의 프로젝트에서 자주 사용됩니다. 코드 작성량이 적고 직관적이며, 리렌더링 최적화가 기본적으로 제공되어 생산성이 높다는 장점이 있습니다. Context API로는 부족하지만 Redux Toolkit을 사용하기에는 부담스러운 경우에 좋은 대안이 될 수 있습니다. 다만 팀 규모가 크거나 엄격한 구조와 규칙이 필요한 프로젝트에서는 일관성을 유지하기가 다소 어려울 수 있습니다.Redux Toolkit은 대규모 프로젝트나 여러 명이 협업하는 환경에서 적합한 전역 상태 관리 도구입니다. 상태 구조와 흐름이 명확하게 정리되며, 비동기 처리, 미들웨어, 개발자 도구 등 다양한 기능을 제공하여 복잡한 상태 관리에 강점을 가집니다. 초기 설정과 학습 비용이 상대적으로 높다는 단점이 있지만, 장기적으로 유지보수가 중요한 서비스나 상태 로직이 복잡한 프로젝트에서는 가장 안정적인 선택이 될 수 있습니다.결론적으로 프로젝트에서 어떤 전역 상태 관리 도구를 선택할지는 상태의 복잡도, 프로젝트 규모, 협업 인원, 그리고 유지보수의 중요도를 기준으로 판단하는 것이 좋습니다. 단순한 전역 상태 공유에는 Context API가 적합하며, 빠른 개발과 높은 생산성이 필요한 경우에는 Zustand가 효과적입니다. 반면, 대규모 서비스나 복잡한 상태 흐름을 다뤄야 하는 프로젝트에서는 Redux Toolkit을 사용하는 것이 바람직합니다. 또한 모든 프로젝트에 반드시 전역 상태 관리가 필요한 것은 아니므로, 필요성을 충분히 검토한 후 도입하는 것이 중요합니다. (덧붙이자면 저는 대부분 zustand만 사용합니다. )

카카오 web플랫폼 등록

안녕하세요.이번 수업과 웹 훅은 관련이 없습니다. (웹 훅 기능 자체를 사용하지 않습니다)현재 리뉴얼된 카카오 개발자 센터 페이지에 대응하는 영상이"258. (25.12.07) 카카오 개발자 페이지 변경 내용 적용하기"에 올라간 상태입니다.해당 영상을 보시면 될 것 같습니다 (현재도 영상 내용과 다르지 않음을 확인했습니다.)감사합니다 🙂

tailwind css는 언제 사용되는가 또 다른 css와의 차이

안녕하세요.Tailwind CSS를 언제 사용해야 하는지에 대해 고민하시는 것은 매우 자연스러운 과정이라고 생각합니다. 리액트를 사용하다 보면 강의나 실무 예제에서 Tailwind CSS가 자주 등장하기 때문에, 마치 기본 선택지처럼 느껴질 수 있습니다. 실제로 최근 프론트엔드 개발 환경에서는 Tailwind CSS의 사용 빈도가 높은 편이지만, 그렇다고 해서 항상 정답이 되는 기술은 아닙니다.Tailwind CSS는 빠른 개발 속도가 중요한 상황에서 특히 적합한 선택입니다. 클래스 기반의 유틸리티 스타일을 JSX에 직접 작성함으로써 별도의 CSS 파일을 관리하지 않아도 되기 때문에, 디자인 수정이 잦거나 초기 단계의 프로젝트, MVP 개발과 같은 환경에서 생산성을 크게 높일 수 있습니다. 또한 디자인 규칙이 어느 정도 정형화되어 있고 반복되는 UI 패턴이 많은 경우에도 일관성을 유지하기 쉽다는 장점이 있습니다. 다만 JSX 코드가 길어질 수 있고, 스타일과 마크업이 강하게 결합된다는 단점도 함께 고려해야 합니다.CSS Module은 비교적 전통적인 CSS 작성 방식에 가깝기 때문에 협업과 유지보수가 중요한 프로젝트에 적합합니다. 컴포넌트 단위로 스타일 파일을 분리할 수 있고, 클래스 이름 충돌을 자동으로 방지해 주기 때문에 중·대규모 프로젝트에서도 안정적으로 사용할 수 있습니다. JSX 구조를 깔끔하게 유지하면서 스타일을 명확한 역할 단위로 관리하고 싶을 때 유용하며, 현재 실무에서도 여전히 많이 사용되고 있는 방식입니다.Styled Components는 스타일이 컴포넌트의 로직이나 상태에 따라 크게 달라지는 경우에 적합합니다. props를 기반으로 동적인 스타일을 적용할 수 있기 때문에 테마 전환이나 재사용 가능한 UI 컴포넌트를 설계할 때 강점을 가집니다. 다만 러닝 커브가 있고, 런타임 성능이나 번들 크기 측면에서 부담이 될 수 있어 최근에는 선택적으로 사용되는 추세입니다.실무에서는 특정 CSS 방식이 고정적으로 사용된다기보다는, 프로젝트의 성격과 팀 환경에 따라 선택이 이루어집니다. 빠른 개발과 생산성이 중요한 소규모 프로젝트에서는 Tailwind CSS가 적합한 경우가 많고, 장기적인 유지보수와 협업이 중요한 프로젝트에서는 CSS Module이 안정적인 선택이 될 수 있습니다. 또한 디자인 시스템이나 상태 기반 스타일링이 중요한 경우에는 Styled Components가 유용하게 활용될 수 있습니다.결국 중요한 것은 어떤 기술이 유행하고 있는지가 아니라, 해당 기술이 현재 상황과 목적에 적합한지 판단하는 기준을 갖는 것이라고 생각합니다. Tailwind CSS를 포함한 다양한 스타일링 방식을 경험해 보고, 각 방식의 장단점을 이해한 상태에서 상황에 맞는 선택을 할 수 있다면 실무에서도 충분히 경쟁력을 가질 수 있을 거라고 생각합니다.

컴포넌트 그리고 폴더 구조에 대해

안녕하세요!리액트에서 컴포넌트를 나누는 기준은 하나의 정답으로 정해져 있기보다는, 코드를 더 읽기 쉽고 이해하기 쉽게 만들기 위한 판단의 연속이라고 볼 수 있습니다. 처음 리액트를 공부하실 때 컴포넌트 분리가 어렵게 느껴지는 것은 매우 자연스러운 일이며, 대부분의 학습자들이 같은 고민을 겪습니다.컴포넌트를 나누는 가장 기본적인 기준 중 하나는 역할과 책임입니다. 하나의 컴포넌트는 가능한 한 하나의 역할에 집중하는 것이 좋으며, 서로 다른 역할을 하는 코드들이 한 컴포넌트 안에 섞여 있다면 분리를 고려해볼 수 있습니다. 또한 컴포넌트의 길이가 길어지고 JSX와 로직이 복잡하게 섞여 읽기 어려워진다면, 이 역시 분리가 필요하다는 신호로 볼 수 있습니다.컴포넌트 분리는 중복되는 UI가 있을 때만 하는 것은 아닙니다. 중복은 분리를 결정하는 강한 이유이긴 하지만, 가독성 향상이나 코드의 구조를 명확히 하기 위한 목적만으로도 충분히 컴포넌트를 나눌 수 있습니다. 특히 특정 부분의 코드가 “지금 이 컴포넌트의 핵심 역할과는 조금 다른 것 같다”는 느낌이 든다면, 그 부분을 별도의 컴포넌트로 분리하는 것이 전체 흐름을 이해하는 데 도움이 됩니다.처음부터 컴포넌트를 잘게 나누어 설계해야 한다는 부담을 가질 필요는 없습니다. 실제로는 하나의 컴포넌트로 구현을 시작한 뒤, 코드가 점점 길어지고 관리하기 어려워질 때 분리하는 방식이 더 자연스럽습니다. 컴포넌트 분리는 설계의 영역이기보다는 리팩토링의 과정에 가깝다고 생각하셔도 됩니다.폴더 구조 역시 정해진 정답은 없으며, 초보자일수록 본인이 찾기 쉽고 이해하기 쉬운 구조를 사용하는 것이 가장 좋습니다. 프로젝트의 규모가 커지기 전까지는 단순한 구조로 시작하고, 필요해질 때 점진적으로 정리해 나가도 충분합니다.마지막으로 컴포넌트 분리가 과한지 부족한지를 판단하는 가장 좋은 기준은 ‘읽기 쉬운가’입니다. 컴포넌트를 나누었을 때 오히려 흐름을 따라가기 어렵다면 과한 분리일 수 있고, 하나의 파일이 지나치게 길고 복잡하다면 분리가 부족한 상태일 수 있습니다. 결국 리액트에서 컴포넌트를 나누는 기준은 정해진 규칙이 아니라, 코드를 읽는 사람이 더 쉽게 이해할 수 있도록 만드는 방향이라고 정리할 수 있습니다.