불변성을 지키며 수정 삭제를 할때도 Map이 유리한가요?

안녕하세요 깊은 생각을 하고 공부에 임하고 계시군요. 결론부터 말씀드리자면 1초에 1번 수준에서는 Map와 Object의 성능 차이는 무의미합니다. 그래서 질문의 전제를 살짝 교정해 설명드리도록 하겠습니다. 불변성 패턴 자체의 비용Map의 경우setState(prev => new Map(prev).set(key, value)) Object의 경우setState(prev => ({ ...prev, [key]: value })) 둘 다 매번 새로운 객체와 맵을 생성하는 것은 동일하며, 맵이 메모리를 더 사용하지만 1초에 1번 수준이면 GC가 여유롭게 처리하기 때문에 실질적 차이는 없습니다. 그렇다면 더 맵이 더 많은 메모리를 차지한다는 말의 맥락이 무엇인지 생각해볼 필요가 있는데, 이건 수백만개 이상의 엔트리를 다루는 수준에서 입니다. React를 통한 일반적 데이터에서는 신경 쓸 필요는 없습니다. 이 부분에 있어서 "어떤 게 더 빠른가" 라는 부분은 과도한 사전 최적화에 해당합니다. 오히려 "이 데이터가 Map의 특성(동적 키, 순서 보장, non-string 키)이 필요할까?" 라는 기준으로 선택하면 됩니다. 만약 빈번한 업데이트가 병목이 된다면 그것은 데이터 타입의 문제가 아닌 상태 관리 도구를 어떤 식으로 활용할지 고민해보는게 더 좋습니다.

3장 디자인패턴에 프롭스 컬렉션과 슬롯 부분 강의 누락

안녕하세요 확인해보니 2개의 강의가 어떤 이유에선지 비공개 처리가 되어 있었네요. 수정해뒀습니다. 감사합니다.

추천패턴

좋은 질문입니다. 채팅은 구조상 최초에 테이블 구조를 잡아두더라도 시간이 지나면서 기능이 추가됨에 따라 데이터가 optional하게 추가되는 경향이 생깁니다. 가령 예를 들면 채팅 메시지로 처음 제품은 만들겠지만 채팅에 대해 이모지 응답, 읽은 사람 숫자 등의 메타 데이터, 첨부 파일, 링크 형태, 링크가 있을 때 미리보기를 제공해줄 수 있는 경우 등 온갖 경우의 수가 계속 생기게 됩니다. 그렇다면 생각해볼 점은 서버에 해당 데이터가 어떤 식으로 저장될까라는 점입니다. 그게 중요한 이유는 프론트에서는 결국 서버에 저장된 데이터의 형태를 따라서 후처리하는 방식으로 구현되기 때문입니다. 만약 새로운 기능이 스키마의 컬럼으로 추가되는 형태라면 프론트에서는 매번 해당 컬럼을 추가해주는 방식으로 타입은 맞춰줄 수 있지만 UI에 적합한 표시를 만들기에는 어색할 수 있을 겁니다. 저장된 데이터에 따라 조건부 렌더링이 매우 다양하게 발생하는 경우가 되는 셈이겠네요. 이와 같은 이유로 채팅과 같은 데이터를 프론트에서 표시할 때는 많은 조건부 렌더링을 대응할 수 있도록 구현하고, 이를 어댑터 패턴으로 구현해 맞춤형 디자인을 매칭해줄 수 있습니다. 다만 채팅은 단순히 어댑터를 이용해서 여러 상태에 맞춰 처리되도록 끼워넣기로만 구현하기에는 깔끔하지 않은 측면이 있습니다. 제 생각에는 조건부 렌더링에 대해 "어댑터 패턴 + compound 패턴"을 복합적으로 활용해 처리하는게 복잡한 경우의 수를 대응해줄 수 있을 것 같습니다.

원시 데이터 할당 방식

안녕하세요. 말씀주신 내용이 맞습니다. 질문하신 내용과 제가 설명한 내용 사이에 차이점이 있어서 질문해주신걸까요? 아니면 질문인걸까요? 제가 강의 내용이 워낙 많아 어떤 부분에 대한 것인지 헷갈리네요. 만약 강의 내용 중에 제가 이와 다르게 설명했다면 몇 강인지, 몇 분에서 설명이 잘못됐는지 알려주시면 감사하겠습니다.

좋아요 배치 처리 로직과 실제 API 동작 차이에 대해 질문드립니다

안녕하세요 클라이언트단 구현과 서버단 구현은 사실 정답이 있는 주제는 아닙니다. 클라이언트에서 막는 것은 서버까지 가는 요청의 총 숫자를 줄여 원천 차단에 의의가 있지만 반대로 정상적인 활동까지 막을 수도 있습니다. 또는 복잡한 예외 처리가 생길 수도 있겠죠. 제가 강의에서 이야기했는지 제 유튜브에서 얘기 했는지 정확히 기억은 나지 않지만, 대표적으로 farming 게임이 클라이언트단에서 모아서 처리하는 예에 해당합니다. 클래시오브클랜과 같은 게임을 해보셨을지 모르겠으나, 해당 게임은 접속하면 광산에 쌓인 골드를 클릭해 수집하고, 엘릭서를 수집합니다. 사용자의 대부분이 그 활동을 하죠. 아주 극소수의 사용자만 몇몇 광산의 골드와 엘릭서를 누락해서 수집할 수 있지만 대부분은 접속하자마자 그동안 쌓인 자원을 수집합니다. 그게 가장 효율적인 패턴이라 그렇죠. 그럴 때 여러번의 클라이언트 요청이 아닌 모아서 처리하는게 오래전부터 사용됐던 패턴이고, 이를 웹 클라이언트에서도 전략적으로 활용할 수 있습니다. 생각하신대로 서버측에서도 처리해도 괜찮은 전략입니다. DB에 너무 많은 짧은 I/O를 발생시키는 것은 서비스가 커질 수록 치명적일 수 있기 때문에 캐시 서버를 둬서 캐시된 데이터를 일정 사이클마다 처리한다던지 하는 방향으로 해결할 수도 있습니다. 인스타그램에서 테스트해보신 건 매우 좋은 습관입니다. 여러 서비스를 탐방하시면서 어떤 시점에 어떤 요청이 발생하는지, 묶어서 발생하는 경우가 있는지, 지속적으로 보시다보면 더 높은 수준의 자신만의 통찰을 얻으시리라 생각합니다. 감사합니다.

섹션 1 Props collections & getters 제목의 의미가 궁금합니다

안녕하세요, 강좌 제목이 들어가는 부분인데 오타가 들어갔네요. 무시하셔도 됩니다.감사합니다.

배포 관련 내용 추가될 예정이 있을까요?

안녕하세요 Eun님 예정된 강의 추가는 없습니다. 배포는 데스옵스 영역이라고 보고 프론트에서 굳이 다루지 않았습니다. 감사합니다.

학습자료는 따로 공유가 안되는건가요?

안녕하세요 영민님, 강의 설명란에 보시면 나오는데 1강에 강의 자료 링크 있습니다!

이벤트 루프 실행 관련

안녕하세요 동군님. 단순히 배우는 것을 넘어 실제 시스템에서 심도 깊은 이해를 위해 고민을 많이 해보신 거 같네요. 정말 훌륭한 자세라 생각합니다. 질문에 대해 결론부터 말씀드리면 macroTask()는 randeringPipelineTask()가 요청한 브라우저의 페인트(Paint) 작업이 완전히 완료된 후에 실행될 가능성이 매우 높습니다. 이유는 자바스크립트의 이벤트 루프의 명확한 작동 순서 덕분입니다.질문하신 mySchedule 메서드 시나리오를 이벤트 루프 주기 관점에서 분석해 보겠습니다.const mySchedule = async () => { await randeringPipelineTask(); // ① 랜더링파이프라인 (≒ 한 프레임의 작업) await macroTask(); // ② 매크로 태스크 }randeringPipelineTask()가 완료되고 Promise가 resolve될 때까지 JS 엔진은 대기합니다.이 대기 시간 사이에 브라우저는 렌더링 업데이트를 수행합니다.randeringPipelineTask()가 resolve되고, 그 콜백(macroTask()로 이동하는 로직)이 Microtask Queue로 들어갑니다.이 Microtask Queue가 비워진 후, 브라우저는 렌더링 파이프라인(Layout, Paint)을 수행합니다.렌더링이 완료된 후, 이벤트 루프는 다음 Macrotask를 큐에서 꺼내 콜스택으로 넣습니다.핵심은 이벤트 루프는 매 주기마다 반드시 렌더링을 처리한 후에 다음 매크로태스크를 처리한다는 점입니다. 따라서 macroTask()가 다음 주기(cycle)의 Macrotask로 실행된다면, 그 전에 발생해야 할 렌더링 작업은 모두 완료됩니다. 수강생님의 혼란은 "JS 엔진은 부탁까지만 하고 다음을 실행할까?"라는 부분에서 기인합니다. 일반적인 DOM 조작은 '부탁까지만' 하는 것이 맞습니다. 예를 들어, element.remove()를 수백 번 호출해도, 실제 레이아웃 계산과 페인트는 콜스택이 완전히 비워진 후(혹은 requestAnimationFrame 같은 특정 지점)에 단 한 번의 렌더링 스텝에서 배치(Batch)로 처리됩니다. 그래서 이벤트 루프의 표준 주기를 살펴보면JS 엔진: 현재 MacroTask 실행JS 엔진: MicroTask Queue 비우기브라우저: Update the rendering 과정으로 Layout, Paint, Composite 실행이벤트 루프: 다음 MacroTask 선택렌더링은 마이크로태스크가 비워진 후에 이뤄지기 때문에 구체적인 함수에 대해 코드가 있지는 않지만 randeringPipelineTask 함수를 추정해본다면 다음과 같습니다. 만약 randeringPipelineTask()가 다음 렌더링 완료를 기다리는 역할을 하려면, 가장 표준적이고 강력한 방법은 requestAnimationFrame (RAF)과 Promise를 조합하는 것입니다.randeringPipelineTask() 내부에서 DOM을 변경하고, RAF를 요청합니다.RAF 콜백은 렌더링 바로 직전에 실행됩니다.RAF 콜백 내에서 setTimeout(0)이나 다른 Macrotask를 이용하거나, 혹은 Microtask를 한 번 더 사용하여 Promise를 resolve 시켜 다음 프레임 경계를 넘기는 방식으로 페인트 완료 후에야 비로소 randeringPipelineTask()의 await가 해제되도록 구성해야 합니다.결론적으로, await가 걸려있다는 것은 브라우저의 한 프레임(주기) 경계를 넘기도록 설계된 비동기 로직을 사용했다는 의미이며, 이벤트 루프의 설계상 이 경계를 넘으면 렌더링은 이미 완료된 상태입니다. 이러한 이유로 DOM 조작을 빈번하게 해야하는 경우라면, 매우 특수한 경우가 되겠지만! requestAnimationFrame(RAF)MutationObserver: 강의에서는 설명하지 않음setTimeout(0)등을 통해 렌더링 완료를 명확히 확인하실 수 있을 겁니다. 답변이 되셨길 바랍니다. 감사합니다.

이벤트루프 설명에 대한 질문입니다.

안녕하세요. 답변해드리려고 했는데 ai 인턴의 답변이 생각보다 정확하게 답변이 됐네요.강의 자료에서 설명된 내용은 전체적인 자바스크립트의 동시성 모델을 설명하기 위한 개념적 설명입니다. 첨부하신 링크에서 설명한대로 정확한 구성 및 소유 위치는 엔진과 브라우저입니다. 각 구성요소의 위치는 다음과 같습니다.자바스크립트 엔진 (예: V8 엔진)콜스택힙 브라우저/런타임 환경Web API태스크 큐마이크로 태스크 큐이벤트루프 이를 한 문장으로 요약해서 설명하자면 콜스택과 힙은 V8 엔진의 구성 요소이고, 이벤트 루프는 브라우저 환경에서 이 엔진을 감시하고 비동기 작업을 조율하는 별도의 메커니즘 이라고 볼 수 있습니다. 심도 깊은 고민 응원드립니다! 감사합니다.