🚨 필독) 질문하시기 전에 꼭 읽어주세요 (10초 소요) 제목을 구체적으로 작성해 주세요 ✅ 좋은 예 : 감정일기장 Home 구현중 xx 이슈가 발생합니다. ⛔ ️ 나쁜 예 : 이거 왜 안되나요?, 오류나요 도와주세요 등 비슷한 궁금함을 갖고 계신 분들께 도움이 될 수 있어요! 코드의 이슈는 전체 프로젝트를 "링크 형태"로 올려주셔야 원인을 파악할 수 있습니다. 깃허브, 구글드라이브 등의 수단을 통해 링크 형태로 전달해주세요 직접 실행해보며 원인을 파악해야 하기 때문에 텍스트 형태로 붙여넣는건 삼가해주세요 🥲 답변이 도움이 되셨다면 답글 or 해결완료 버튼을 클릭해주세요 비슷한 궁금함을 갖고 계신 분들께 도움이 될 수 있어요! 제 답변이 여러분께 도움이 되었는지 저도 알고 싶어요 🥲 강의 내용에 궁금한 점이 있다면 몇 챕터의 몇 분 몇 초인지 알려주시면 더 좋아요 더 빠른 답변이 가능합니다! 7.2) 리뷰 추가 기능 구현하기 수강하고 있는데요 리뷰데이터를 보기 위해 npx prisma studio를 터미널에 치면 % npx prisma studio Need to install the following packages: prisma@6.17.1 Ok to proceed? (y) npm error code ETIMEDOUT npm error syscall read npm error errno -60 npm error network read ETIMEDOUT npm error network This is a problem related to network connectivity. npm error network In most cases you are behind a proxy or have bad network settings. npm error network npm error network If you are behind a proxy, please make sure that the npm error network 'proxy' config is set properly. See: 'npm help config' npm error A complete log of this run can be found in: /Users/minsu/.npm/_logs/2025-10-13T05_36_52_783Z-debug-0.log 라고 나오네요 혹시 해결법 알 수 있을까요? prisma 초기화 하고 prisma 클라이언트 생성해도 모델이 없다고 떠서 리뷰 데이터 확인이 불가합니다
[진도] 1주차 5강 [질문] Lovable에 superbase 연결이 없어졌습니다. 상황: lovable에 DB연결을 하려고 하는데, 업데이트가 된 건지 우상단 superbase 버튼이 없어지고, cloud라는게 추가된 것으로 보여요 해당 부분 강의 업데이트가 가능한가요?
안녕하세요, geek님. 강의 끝까지 잘 들었습니다. 해당 강의가 근본깃-기초 편의 마지막 강의인데, 영상이 끝날 때 "다음 강의에서는 이를 활용하여 동료와 협업하는 방법에 대해서 배운다" 라고 언급하셨더라고요. 이때의 '다음 강의'는 근본깃-완성 편으로 이해하면 될까요?
[VOD] 6주 완성! 개발 실무를 위한 고농축 바이브코딩 (Cursor AI, Figma)
안녕하세요 현직 디자이너입니다. 질문 1 2-1강듣고있는데 디자인 시스템 파운데이션 단계를 토큰화 해뒀는데 어떻게 적용할 수 있을까요? 네이밍이나 다크모드 컬러 폰트등 모두 토큰화 해둔 시스템이라서 여쭤봅니다. json을 뽑을 수 있는데 넣으면 해결될까요 질문 2 제가 지금 사내에서 피그마의 디자인 시스템을 그대로 바이브코딩으로 구축한 뒤 플러터의 스토리북인 위젯북에 담을 예정입니다. 개발자분이하면 좋겠지만 커서나 디자인시스템을 모른다고 하셔서 제가 진행중인데 혹시 위젯북에 대해서도 좀 아실까요? 스토리북과 다를게없나요
[VOD] 6주 완성! 개발 실무를 위한 고농축 바이브코딩 (Cursor AI, Figma)
2-1 강의를 듣고 있는데요. 수업 내용대로 피그마 마일을 드레프트로 올리고 mcp커넥트 하고 노드 id와 mcp채널을 입력하고 해도 안되네요 수업내용대로 새로 고침하고 새로은 노드 iD와 mcp채널을 입력해도 마찬가지로 figma mcp에 접근할 수 없다고 나오네요... 어떻게 해결해야 할까요 ?
섹션9. 이미지 최적화 수강중 궁금한 내용이 있습니다. 강의 내용은 넥스트에서 제공하는 image 컴포넌트를 사용할 경우 이미지 파일이 webp로 변환되어 성능 최적화 하는 것으로 이해했습니다. 혹시 이미지 확장자 중 webp와 jpg가 동시에 불러올 수 있도록 컴포넌트를 커스텀 할 수 있나요?
안녕하세요 제로초님 강의에서는 css module 사용하셨고, 왜 그걸 사용하셨는지 이유를 말씀해 주셨는데요 저는 tailwind나 vanilla extract로 css를 작성해가며 수강하려하는데요 현 시점 기준 시장에서는 어떤 라이브러리를 좀 더 활발하게 사용하는지, 제로초님은 어떤걸 더 선호하시는지, 그리고 이유가 있으시다면 무엇인지 궁금합니다
Next.js에서 서버 컴포넌트가 주로 데이터 페칭을 담당하는 것으로 알고 있습니다. 서버컴포넌트 외에 클라이언트 컴포넌트에서 fetch를 직접 호출하는 사례가 있는지 궁금합니다. 추가로 클라이언트 컴포넌트에서 fetch를 할 때도 Next.js의 request memoization 기능이 자동으로 동작하는지 질문드려요.
안녕하세요! 좋은 강의로 Next.js를 배울 수 있게 해주셔서 감사드립니다. Full Route Cache 관련해서 궁금한 점이 있습니다. 레이아웃 파일에서 cookies()나 headers() 같은 동적 함수를 사용하는 경우, 그 아래에 있는 페이지들도 영향을 받는지 궁금합니다..! 예를 들어서 블로그 레이아웃에서 사용자 테마를 쿠키로 가져오고 있고, 블로그 포스트 페이지 자체는 force-cache로 정적 데이터만 사용한다면, 이 경우 페이지가 Static으로 빌드될 수 있을까요? 아니면 상위 레이아웃이 Dynamic이면 하위 페이지도 함께 Dynamic으로 처리되는 건지 궁금합니다! 감사합니다.
안녕하세요, geek님. 영상 16:55~ 부분에서 설명해주시는 conflict를 해결할 수 있는 방법에 대해서 다음 네 가지를 설명해주셨습니다. main 브랜치 쪽 diff를 더한다. test 브랜치 쪽 diff를 더한다. (선택됨) 둘 다 더한다. 둘 다 더하지 않고, 아예 다른 내용을 적는다. 그리고 예제에서는 2번 방식을 선택해주셨고, 이에 따라서 머지 커밋은 다음과 같이 계산됩니다. base( red ) + main 최신 커밋과의 diff( green ) + test 최신 커밋과의 diff( blue ) 즉, 3개가 더해져서 만들어지는 커밋인데요. 이로 인해 3-way merge라는 이름으로 불린다고 이해했습니다. 여기서 질문이 생기는데요. 만약 1번 방식을 선택한다면, 머지 커밋이 다음과 같이 계산됩니다. base( red ) + main 최신 커밋과의 diff( green ) 즉, 2개가 더해져서 커밋이 만들어집니다. 그런데 앞서 말씀하신 내용을 고려하면 머지의 세부 명칭(예를 들어 3-way merge같은)에 영향을 주는 요소는 '커밋 히스토리의 모양'입니다. 따라서 2개가 더해져서 커밋이 만들어지는 이 상황도 여전히 3-way merge라고 부를 수 있습니다. 그래서 처음 들었던 의문은 "1번 방식을 택했을 때는 2개가 더해지는 건데, 이때도 3-way라고 부르는 것은 그냥 관례적인 표현인가?" 입니다. 그리고 질문을 작성하면서 제가 스스로 내린 답변은 "더하는 개수가 3개여야 하는 것이 아니고, 더할지 말지 고민하는 기준점이 3개 인 상황이라 3-way라는 이름이 붙은 것 같다" 입니다. 즉, 커밋 히스토리가 예제와 같은 상황에서는 다음 3가지 를 기준점으로 사용하게 됩니다. 두 브랜치의 공통 부모 (base) main 브랜치의 최종 커밋 test 브랜치의 최종 커밋 각 기준점에 대해 어떤 판단을 내리느냐에 따라 세 개를 더하는 2번 상황이 되거나 두 개를 더하는 1번 상황이 되거나, 또 다른 3번, 4번 상황이 될 수도 있습니다. 하지만 '기준점이 3개'라는 사실을 모든 상황에서 동일하기 때문에 3-way merge라는 이름이 붙여진 것으로 판단했습니다. 가르쳐주신 내용에 혼란을 느낀 부분을 서술하느라 글이 좀 길어졌는데, 결론적으로 '기준점이 3개라서 3-way merge라고 부른다'는 제 판단이 적절한지 여쭤보고 싶습니다.
안녕하세요, 강의 잘 듣고 있습니다. Git을 정리하는 데 큰 도움을 받고 있습니다. 다름이 아니라 GitHub에서 브랜치를 메인 브랜치로 병합할 때 사용하는 전략에 대해 궁금합니다. 기본 병합(merge), 스쿼시 & 머지(squash & merge), 리베이스 & 머지(rebase & merge) 방식이 있는데, 어떤 방식을 선호하시는지 여쭤보고 싶습니다. 개인적으로는 로컬에서 작업할 때는 리베이스 & 머지 를 선호합니다. 히스토리를 깔끔하게 유지할 수 있기 때문입니다. 반면에 메인 계열 브랜치(dev, prod 등)로 병합할 때는 기본 병합 을 사용해야 기능 추가 히스토리를 명확히 추적할 수 있다고 생각합니다.
