올해 해커톤의 대주제는 “AI·SW, Connecting Value : AI·SW로 가치를 연결하라” 였는데요. 저는 광주소프트웨어 마이스터고를 대표에 참가하였습니다. 마찬가지로 다른 학교에서 선발된 학생들과 함께 4인 1팀으로 구성되어 협업을 진행하였습니다.

기획 및 문제 정의

저희 팀은 이번 해커톤에서 ‘지역사회·문화’ 문화 분야를 선택하였는데요.

특히 다문화 가정 학부모님들이 학교와의 의사소통에서 겪는 언어적 장벽에 주목하였습니다. 현재 몇몇 학교에서는 가정통신문과 같은 주요 공지사항을 문자나 QR 코드 형태로 제공하고는 있으나, 문체가 공문서체, 한자어 중심의 문어체로 구성되어 있어 이해가 어렵다는 문제가 있었습니다. 또한 자동 번역 기능을 활용하더라도 의역·오역 문제가 자주 발생하고, 검수 절차가 없이 긴급 안내 시 오류가 발생할 가능성이 높다는 점도 확인하였습니다.

기존 번역 앱(예: 알번역, 파파고 등)은 단순히 문장 구조나 의미를 단순히 치환하는 수준에 그쳐, 다문화 가정의 학부모가 한국어를 익히거나 지역 사회에 진출할 기회를 제공하지 못하며, 문맥을 이해하는 데에도 한계가 있었습니다.

그 결과, 다문화 학부모들은 학교생활 참여에 제약을 받고, 나아가 지역 사회나 복지기관과의 연결이 단절되는 문제를 겪고 있었습니다.

솔루션

저희 팀은 이러한 한계를 극복하기 위해 ‘단순 번역이 아닌, 이해 가능한 언어로의 변환’이라는 새로운 방향을 제시하였습니다.

즉, 학부모가 단순히 문서를 읽는 데 그치지 않고, AI를 통해 문장을 이해하고, 직접 표현을 연습할 수 있는 상호작용형 플랫폼을 구축하였습니다.

이를 위해 국립국어원의 1단계 어휘 데이터를 기반으로, 공문서체로 작성된 문장을 초급 수준의 일상 언어로 변환하는 기능을 구현하였으며, 이를 통해 학부모가 문서를 쉽게 이해하면서도 동시에 한국어를 자연스럽게 학습할 수 있도록 유도하였습니다.

결과적으로 ‘학습 → 이해 → 참여’로 이어지는 언어 습득의 선순환 구조를 실현하였습니다.

저희 서비스명 ClipCat은 ‘Clip(요약)’과 ‘Cat(도움을 주는 고양이)’ 의 합성어로, 단순히 번역 도구가 아닌 외국인 학부모의 언어 습득을 돕는 지능형 조력자를 의미합니다.

ClipCat은 기존 번역 중심 서비스와 달리, 이해되지 않는 문장을 드래그하면 AI 가 쉬운 한국어와 모국어 번역을 함께 제공하고, 이를 통해 학부모가 자신의 언어로 이해하며 동시에 한국어 표현을 학습할 수 있는 환경을 제공합니다.

물론, “그렇다면 그냥 모든 문장을 모국어로 번역해서 보면 되는 것 아니냐?” 라는 의문이 생길 수 있습니다. 하지만 저희 팀은 ‘즉각적인 편의’보다는 ‘지속적인 학습’을 원하는 학부모님들에게 초점을 맞추었습니다. 따라서 ClipCat은 단순히 번역 제공에 그치지 않고, 사용자가 한국어를 직접 읽고 이해해 나가며 자연스럽게 언어 습득 경험을 쌓을 수 있도록 설계하였습니다.

또한 저희는 실질적인 수요와 접근성을 고려하여 통계청 2022년 기준 다문화 가정 내 상위 5개의 언어(베트남어, 러시아어, 우즈베키스탄어, 캄보디아어, 몽골어)를 우선적으로 지원하였습니다. 이를 통해 서비스의 초기 효용성과 실제 사용성을 높이고 언어권별 사용자에게 실질적인 도움을 줄 수 있도록 설계하였습니다.

또한, 일부 학교에서 운영 중인 QR 번역 서비스는 학교 재량과 번역 인력의 한계로 인해 일관된 품질을 제공하지 못하는 문제가 있었습니다. 이에 ClipCatsms AI가 직접 문서를 분석·요약·번역하는 방식을 도입하여, 교사나 외부 번역가의 개입 없이도 정확한 결과를 즉시 제공함으로써 학교와 학부모 간의 정보 불균형을 최소화하였습니다.

개발

이렇게 아이디어 구체화 이후, 본격적인 개발을 시작했습니다.

저는 프론트엔드 개발을 담당하였는데요. Next.js와 Axios를 중심으로 백엔드와의 통신 구조를 구현하고,UI 구성과 상호작용 로직을 Figma 디자인을 기반으로 직접 퍼블리싱하였습니다. 특히 챗봇 인터페이스와 업로드 화면의 주요 기능을 설계하며 사용자가 직관적으로 이용할 수 있도록 컴포넌트를 구조화하였습니다. 또한 웹페이지가 정적으로 보이지 않도록, ClipCat 캐릭터에 눈을 깜빡이는 애니메이션을 추가하여 자칫 단조로울 수 있는 화면에 생동감과 몰입감을 더하였습니다. 이 작은 움직임이 사용자에게 친근한 인상을 주어, AI 조력자라는 서비스의 정체성을 시각적으로 강화하는 효과를 주었다고 생각합니다. 특히 이러한 세심한 시각적 요소 덕분에, “세부적인 완성도와 감각적인 연출이 돋보였다”는 평가를 받으며 디자인적 완성도 측면에서 높은 평가를 받을 수 있었습니다.

협업 및 멘토 피드백

해커톤은 한정된 시간 속에서 기획, 개발, 디자인이 동시에 이뤄지기에 팀원간의 빠른 의사소통과 역할 분담이 무엇보다 중요했습니다. 저희 팀은 서로 다른 학교에서 처음 만났지만, 각자의 강점을 바탕으로 자연스럽게 협업 체계를 구축할 수 있었습니다.

개발이 예상보다 빠르게 진행되어 2일 차 오후에는 대부분의 핵심 기능이 완성되었고, 이후에는 멘토님들의 피드백을 바탕으로 프로젝트의 완성도와 방향성을 다듬는 데 집중하였습니다. 멘토님들이 각 팀을 돌아다니며 직접 조언을 해주셨는데, 저희 팀장이 직접 서비스를 소개하고 설명하는 동안, 저는 옆에서 멘토님들의 피드백을 빠짐없이 기록하며 즉시 반영할 부분을 정리했던 기억이 있습니다.

모두가 공감할 수 있듯이, 그때는 단순히 좋은 조언이네라고 듣지만, 막상 실제로 적용해보다보면 잊거나 놓치기 쉬운 내용이 많습니다. 때문에 모든 피드백을 노션에 정리해 팀 전체가 바로 참고할 수 있도록 시각화했습니다.

이러한 태도 덕분에 저희 팀은 수정 속도가 빠르고 방향성 있는 개선이 가능했습니다. 특히 “기존 번역 앱과의 차별점을 명확히 하라”, “단순 번역이 아닌 AI 기반의 학습적 접근을 강조하라” 등의 멘토 피드백을 적극 반영하여 서비스의 핵심 가치를 더욱 구체화할 수 있었습니다.

이러한 과정은 단순히 기술적 보완을 넘어, 서비스의 철학과 차별점을 명확히 정립하는 전환점이 되었다고 생각하는데요. 짧은 시간이었지만, 서로의 전문성을 존중하고 멘토님의 피드백을 빠르게 실험하며 발전시킨 점이 결국 수상으로 이어질 수 있었던 저희 팀의 가장 큰 강점이었다고 생각합니다.

결과 및 수상_1등

해커톤 마지막 날, 2박 3일간의 개발 결과물을 발표하는 시간이였습니다. 저희 팀 ClipCat은 단순한 번역을 넘어 “이해 가능한 언어로의 변환”과 “학습으로의 확장”이라는 새로운 접근 방식을 통해 사회적 가치와 기술적 완성도를 동시에 실현했다는 평가를 받았습니다. 그 결과, 심사위원들로부터 높은 호평을 얻을 수 있었는데요.

심사는 네이버클라우드, 니어네트웍스 등 5개 기업 관계자와 정보통신기획평가원(IITP) 심사위원단이 함께 진행하였으며, 대상 2팀, 최우수상 1팀, 우수상 5팀이 선정되었습니다.

중에서도 저희 팀 ClipCat은 과학기술정보통신부 장관상(대상) 을 수상하였습니다. 🎉

마치며..

이번 해커톤은 저에게 정말 의미있는 경험이였는데요. 이전에 1학년때는 운좋게 좋은 팀을 만나 수상을 하거나, 디자인 감각 덕분에 수상을 할수 있었던 경험이 있습니다. 하지만 이러한 경험들 속에서 언제나 마음 한켠에는 “진짜 내 실력으로 인정받고 싶다”는 갈증이 있었습니다. 그래서인지 그동안의 수상들은 기쁘면서도 어딘가 공허하게 느껴졌던 것 같습니다.

하지만 이번에는 달랐습니다. 기획 단계부터 직접 참여하고, 코드 한 줄 한 줄을 제 손으로 짜면서 결과물을 완성했기에 그 어느 때보다 큰 보람을 느꼈습니다. 짧은 시간 안에 오류를 해결하고, 구조를 다듬으며 완성도를 높여가는 과정 속에서 “내가 정말 개발자로 성장하고 있구나”라는 확신이 들었습니다.

무엇보다 이번 우승은 나 혼자만의 결과가 아닌, 각자의 강점을 살리며 함께 성장한 팀원들 덕분에 이룬 성과였다고 생각합니다. 서로 처음 만난 사이였지만, 기획, 디자인,개발 어느 한쪽도 소홀하지 않고 같은 목표를 향해 달려갔기에 이러한 결과를 얻을 수 있었다고 생각합니다.

이 경험을 통해 진짜 성장은 결과가 아니라 과정 속의 변화에서 비롯된다는 걸 배웠습니다. 이번 해커톤에선 그동안 제가 만들어왔던 모든 개발과 기획 방향을 다시 돌아보게 되는 계기가 되었으니깐요.☺️ 

앞으로 이 갈증을 성장의 원동력으로 삼아, 더 깊이 있는 개발 역량을 쌓고, 함께 일하고 싶은 믿은직한 프론트엔드 개발자로 성장해 나가고 싶습니다.

긴 글 읽어주셔서 감사합니다!

npx create-next-app로 프로젝트를 만들면서 Tailwind CSS를 선택했더니, postcss.config.mjs가 자동으로 생성되었고, 그 안에는 다음과 같은 설정이 있었음

const config = {
  plugins: ["@tailwindcss/postcss"],
};

export default config;

그런데 기존에 공식 문서나 블로그에서 봤던 예제들은 대부분 이랬다:

const config = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  },
};

export default config;

내가 봤던 예제와, 자동으로 생성된 설정의 코드가 달라 혼란이 생겼고, 챗 gpt 도 처음엔 @tailwindcss/postcss 방식이 잘못됐다라는 식으로 설명을 해서 더 헷갈리기 시작했다.

하지만 CNA에서 자동으로 생성되는 설정이 문제 있는 방식이라면 이미 이슈가 터졌을 테고, 공식에서 사용하는 템플릿이 틀릴 리가 없지 않은가?

그래서 더 챗gpt에 의존하지 않고 구글링을 더 해보기로 했다.

최신 Tailwind v4 및 Next.js의 변화

Tailwind CSS v4.1 이상 공식 문서에서 명시한 방식:

export default {
    plugins: {
        "tailwindcss/postcss": {}.
    }
}

Tailwind CSs v4부터는 새로운 공식 PostCSS 플러그인인 @tailwindcss/postcss를 사용하도록 설정 방식이 바뀌었다.

• 기존(v3): tailwindcss,autoprefixer를 직접 설정
• 변경(v4): @tailwindcss/postcss 하나로 통합 (내부적으로 처리)

이 플러그인은 Tailwind 설정, 변환, 최적화 과정을 모두 담당한다.

Next.js의 최신 템플릿

Next.js v15.2 이상에서 Tailwind를 포함해 생성한 프로젝트는 다음 설정을 자동으로 생성한다.

npx create-next-app my-app --tailwind

• postcss.config.mjs 파일 생성
• 내부에는 "@tailwindcss/postcss" 플러그인이 문자열로 등록됨
• 이는 Tailwind v4.1 기준의 공식 설정이다

하지만 Tailwind CSS 공식 문서에는 여전히 다음과 같은 예제가 많이 등장한다:

plugins: {
  tailwindcss: {},
  autoprefixer: {},
}

하지만 이건 Tailwind CSS v3 이하 의 설정 방식이며, v4부터는 더 이상 권장되지 않는다.

요약 비교

내가 얻은 인사이트

• Tailwind CSS는 v4.1부터 설정 구조가 확실히 바뀌었고, 이에 따라 문서도 공식적으로 업데이트되었다.
• 공식 문서만이 절대적인 기준이다. 오래된 블로그, GPT 답변, 커뮤니티 포스트는 참고하되 반드시 버전 기준 확인이 필수다.
• create-next-app으로 Tailwind를 선택한 경우, @tailwindcss/postcss가 자동으로 설정되는 건 정확하고 공식적인 동작이다.

개요

React + Tailwind 기반의 main-nav.tsx 컴포넌트에서, 모바일과 데스크탑은 서로 다른 방식으로 Navigation UI 를 구현하고 있다. 그리고 그 차이와 이유를 명확이 이해하고자 다음과 같은 포스터를 작성하였다.

💻 데스크탑 nav 구현 방식

사용 구조

{items?.length ? (
  <nav className="hidden gap-6 md:flex">
    {items.map((item) => (
      <Link href={item.href}>...</Link>
    ))}
  </nav>
) : null}

해석

• md:flex 는 데스크탑(medium ≥ 768px) 이상일 때만 메뉴 보이게 함
• hidden : 기본은 숨김 (모바일에서는 안 보이도록)
• 메뉴 항목은 <Link> 컴포넌트로 직접 나열
• 별도 state 관리 없이 항상 보이는 수평 메뉴

📱 모바일 nav 구현 방식

사용 구조

<button className="md:hidden" onClick={...}>
  {showMobileMenu ? <Icons.close /> : <Icons.logo />}
  <span>Menu</span>
</button>

{showMobileMenu && items && (
  <MobileNav items={items}>{children}</MobileNav>
)}

해석

• md: hidden : 데스크탑에서는 버튼 안 보이고, 모바일에서만 보임
• 햄버거 버튼 클릭 시 showMobileMenu 상태를 토글
• showMobileMenu === true 일 때만 <MobileNav> 렌더링
• <MobileNav /> 는 전체 화면을 덮는 오버레이 메뉴

📊 비교 요약

🎯 결론

반응형 디자인에서 Navigation은 단순히 숨기고 보이는 걸 넘어서,

기기 환경에 맞는 UX 구조 자체를 바꿔야 한다.

데스크탑은 공간이 넓으므로 메뉴를 펼쳐두고,

모바일은 공간이 좁기 때문에 토글 기반의 오버레이 메뉴로 구현하는 것이 표준 패턴이다.

처음엔 flex 를 단순히 가로 정렬하는 속성이라고 이해했었고, md: flex는 그저 반응형 정렬용이라고 생각음 그래서 nav 메뉴를 보여주기 위해 굳이 md: flex가 필요한 이유가 잘 이해되지 않았음

핵심 정리

1. display가 본질

• HTML 요소가 보이냐 / 안 보이냐, 어떻게 배치되느냐를 결정하는 핵심 속성이 display
• display: none → 요소 자체가 화면에서 사라짐 (보이지 않음 + 공간도 차지하지 않음)
• display: flex → 요소가 보이고, 자식 요소들이 flexbox 방식으로 배치됨

2. flex는 "정렬 방법"이지, "보이게 만드는 속성"은 아님

• flex는 실제로는 display: flex를 의미하고,
• 자식 요소들을 가로 or 세로 방향으로 정렬하는 도구일 뿐임
• 단, 기본값이 flex-direction: row라서 보통 가로 정렬로 보임 → 그래서 흔히들 "flex = 가로 정렬"로 착각함

3. Tailwind에서의 hidden, md:flex는 결국 display 제어

→ 즉, Tailwind는 display 속성을 조건부로 적용하는 래퍼일 뿐이다.

실전 적용: nav 메뉴 예시

<nav className="hidden md:flex">...</nav>

• 모바일에서는 display: none → 메뉴가 숨겨짐

• 데스크탑에서는 display: flex → 메뉴가 보이고, 자식들이 가로로 정렬됨

• 메뉴의 보임 여부 자체가 flex 때문에 결정된 것처럼 보이지만,

  실제 핵심은 display: none → display: flex라는 display 상태의 전환이었다.

오늘의 교훈

Tailwind의 hidden, flex, md:flex 등은 전부 결국 display 속성을 조작하는 방식임

요소가 보이느냐 안 보이느냐는 display가 결정하며, flex는 정렬 도구일 뿐임

반응형 조건부 렌더링도 display의 on/off 개념으로 이해해보자

Tailwind를 CLI로 설치할 때 다음 명령어를 입력했다:

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

그런데 npx tailwindcss init -p 명령어에서 다음과 같은 에러가 발생함:

npm ERR! could not determine executable to run

또한, node_modules/.bin/tailwindcss가 존재하지 않음.

📌 원인 분석

이 문제는 Tailwind CSS v4부터 공식적으로 CLI 기반 init 명령어를 제거했기 때문이다.

🚨 Tailwind CSS v3 vs v4 차이

🔧 해결 방법 (Tailwind CSS v4 기준)

1. 필요한 패키지 수동 설치

npm install -D tailwindcss postcss autoprefixer

참고: 사실 v4에서는 autoprefixer, postcss는 없어도 동작은 가능. Vite처럼 특정 빌드 툴을 쓰는 경우엔 더 단순화됨.

2. 설정 파일을 직접 작성

• tailwind.config.js 예시:

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [
    "./src/**/*.{html,js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

• postcss.config.js 예시:

module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  },
}

3. 글로벌 CSS 파일 설정 (globals.css 등)

@tailwind base;
@tailwind components;
@tailwind utilities;

💡 결론 및 배운 점

• Tailwind v4부터는 더 이상 npx tailwindcss init 명령어를 사용할 수 없다.
• 대신 설정 파일을 직접 작성하는 방식으로 변경되었으며, 이는 불편해 보이지만 더 유연한 커스터마이징을 위한 구조이다.
• 문서와 커뮤니티 블로그에서 보던 예전 설치법을 그대로 따라하면 위와 같은 오류가 생기므로, 버전에 맞는 공식 문서를 참고하는 습관이 중요하다.

💬 참고 링크

https://tailwindcss.com/docs/installation/framework-guides/nextjs

localStorage 란?

localStorage 는 브라우저가 제공하는 클라이언트 측 저장소이다.

HTML5에서 도입된 Web Storage API 중 하나이며, key-value 형태의 데이터를 브라우저에 영구적으로 저장할 수 있다.

💡 주요 특징

사용 예시

// 저장
localStorage.setItem('nickname', '김봄');

// 불러오기
const name = localStorage.getItem('nickname');

// 삭제
localStorage.removeItem('nickname')l

// 전체 삭제
localStorage.clear();

❓ 그런데 객체/배열은 왜 안 되는가?

localStorage는 문자열만 저장 가능하므로,

자바스크립트의 객체나 배열을 바로 저장할 수 없다.

이럴 때 사용하는 것이 바로:

• JSON.stringify() : 객체 → 문자열
• JSON.parse(): 문자열 → 객체

🔄 JSON.stringify / JSON.parse 흐름

🔷 저장 시 (객체 → 문자열)

const post = { title: "안녕", content: "첫 글이얌" };

localStorage.setItem('posts', JSON.stringify([post]));

• [post] 는 자바스크립트 배열
• JSON.stringify() 로 변환 시, 아래처럼 JSON 문자열로 바뀜:

"[{\"title\":\"안녕\",\"content\":\"첫 글이야\"}]"

🔶 꺼낼 때 (문자열 → 객체)

const saved = localStorage.getItem('posts');

if (saved) {
  const parsed = JSON.parse(saved);
  console.log(parsed[0].title);  // "안녕"
}

• JSON.parse() 는 문자열을 다시 자바스크립트 객체 배열로 복원
• 이후 배열처럼 다루기 가능

📦 전체 흐름 정리

[ JS 객체/배열 ]
    ↓ JSON.stringify
"문자열" (localStorage에 저장됨)
    ↑ JSON.parse
[ JS 객체/배열 복원 ]

🔥 핵심 요약

✅ 실전에서 적용한 코드 예시 (React 게시판 프로젝트)

// 저장
useEffect(() => {
  localStorage.setItem('posts', JSON.stringify(posts));
}, [posts]);

// 불러오기
useEffect(() => {
  const saved = localStorage.getItem('posts');
  if (saved) {
    setPosts(JSON.parse(saved));
  }
}, []);

posts 상태가 바뀌면 자동으로 localStorage에 저장

페이지가 새로고침되면 localStorage에서 다시 불러와 복구됨

💬 느낀점

이번 학습을 통해 단순히 데이터를 저장하는 것만이 아니라,

자바스크립트 객체와 문자열 간의 변환 로직이 왜 필요한지,

그리고 그 과정에서 어떤 데이터 형상이 오가는지 구체적으로 이해하게 되었다.

프론트엔드 개발에서 localStorage를 활용할 때는 무조건 JSON.stringify / JSON.parse가 함께 사용된다는 점을 명확히 인지하게 되었다.

드래그 앤 드롭 리스트를 만들다가 궁금한 점이 생김:

• ul 태그 (Droppable)에는 그냥 style={{ padding: 20 }} 이렇게 간단하게 스타일을 줘도 되는데,
• li 태그 (Draggable)에는 ...provided.draggableProps.style처럼 복사해서 스타일을 덧붙여야 작동함

왜 그런 차이가 생기는 걸까?

✅ 핵심 개념 요약

🔹 Draggable에는 라이브러리 내부에서 계산한 style이 있다!

style={{
  ...provided.draggableProps.style,
  padding: '8px',
}}

• provided.draggableProps.style에는 드래그 중 위치 이동, 애니메이션, 트랜지션 등을 위한 내부 계산된 스타일이 담겨 있음
• 이 스타일을 유지하지 않으면 드래그 기능이 깨짐!
• 그래서 기존 스타일을 복사(...)하고, 내가 원하는 스타일을 덧붙여야 함

🔹 Droppable에는 별도로 제공되는 style이 없다

<ul style={{ padding: 20 }}>

• provided.droppableProps는 드롭 이벤트를 위한 속성만 제공 (data-*, role 등)
• 별도로 계산된 style은 없음 → 내가 자유롭게 스타일 지정해도 기능에 영향 없음

🔹 JSX에서 style={{}} 중괄호가 두 번 쓰이는 이유

• JSX에서는 JavaScript 표현식은 {}로 감싸야 하고,
• style은 JS 객체니까 {{ ... }} 형태가 됨

📌 예:

<div style={{ color: 'red', margin: '10px' }} />

📊 정리 표

✅ 한 줄 요약

Draggable은 라이브러리 내부 style을 유지해야 하므로 ...style로 복사해서 써야 하고,Droppable은 자유롭게 스타일을 지정해도 된다. JSX의 {{}}는 JS 객체를 넘기기 위한 문법상 구조다.

@hello-pangea/dnd 라이브러리에서

Droppable, Draggable 컴포넌트가 드래그 기능을 동작시키기 위해

자식 함수(children)에 넘겨주는 필수 도구 세트 객체

🧭 왜 존재하는가?

React에선 DOM 요소를 직접 조작하지 않기 때문에,

라이브러리가 드래그 기능을 위해 꼭 필요한 값들 (ref, props 등)을

우리가 직접 붙일 수 있도록 제공해주는 방식이 바로 provided.

✅ Droppable의 provided

<Droppable droppableId="myList">
  {(provided) => (
    <ul
      ref={provided.innerRef}
      {...provided.droppableProps}
    >
      {items.map(...)}
      {provided.placeholder}
    </ul>
  )}
</Droppable>

🔹 DroppableProvided 구조

🔸 중요 포인트

• provided.placeholder는 반드시 <ul> 안에 있어야 한다.

  → <ul> 바깥에 두면 React가 HTML 구조 에러로 판단함!

✅ Draggable의 provided

![](https://velog.velcdn.com/images/bom_0320/post/82e0c9f6-2702-4b21-9816-c970916259fc/image.png)
<Draggable draggableId={item} index={index}>
  {(provided) => (
    <li
      ref={provided.innerRef}
      {...provided.draggableProps}
      {...provided.dragHandleProps}
      style={{
        ...provided.draggableProps.style,
        ...
      }}
    >
      {item}
    </li>
  )}
</Draggable>

🔹 DraggableProvided 구조

🧠 Droppable vs Draggable 비교

💡 헷갈렸던 점 & 배운 것

🎯 한 줄 요약

provided는 드래그 기능을 DOM에 정확히 연결하기 위해 라이브러리가 넘겨주는 “도구 세트”이고, 이걸 제대로 붙여야만 드래그 앤 드롭이 정상 작동한다. Droppable과 Draggable은 각각 전혀 다른 provided 구조를 가진다!

ref는 React가 HTML 요소(실제 DOM)를 직접 찾을 수 있게 해주는 도구다.

🧭 정리

⭐️ ref는 왜 필요한가?

평소엔 React가 가상 DOM을 관리하지만,

정말 필요한 경우, 내가 직접 진짜 DOM을 만질 수 있게 해주는 “예외 통로”가 바로 ref다.

💡 실제 코드 예시

import { useRef, useEffect } from 'react';

function MyComponent() {
  const myBoxRef = useRef(null);

  useEffect(() => {
    console.log(myBoxRef.current); // 실제 DOM 요소가 출력됨
    myBoxRef.current.style.backgroundColor = 'lightblue';
  }, []);

  return (
    <div ref={myBoxRef}>
      Hello
    </div>
  );
}

✅ 위 코드에서 벌어지는 일

• myBoxRef는 div를 가리키는 ref 객체
• myBoxRef.current는 실제 HTML <div> 요소
• 여기에 직접 스타일을 주거나 포커스를 줄 수 있음

🧠 ref를 쓰는 대표적인 상황

🧲 Drag and Drop에서 왜 꼭 ref가 필요할까?

드래그 앤 드롭은 요소의 위치를 직접 추적해야 해.

• 예: "지금 이 박스 위에 마우스를 놓고 있어?"
• 이걸 알려면 실제 DOM의 위치 정보를 가져와야 해

const rect = element.getBoundingClientRect();

이 함수는 실제 HTML 요소의 화면 위치(px 단위)를 알려줌 → 가상 DOM으로는 절대 불가능

그래서 드래그 라이브러리들은 <li>, <ul> 같은 DOM 요소를 ref로 직접 가리켜서,

브라우저에게 위치 정보를 묻고 → 거기에 드롭해도 되는지 판단함.

❗️그렇다면 가상 DOM만 쓰면 어떤 문제가 생길까?

✅ 결론

가상 DOM은 구조(설계도)만 알고,

위치, 크기, 충돌 같은 화면 위의 정보는 모른다.

그래서 드래그 앤 드롭처럼 화면에서 정확한 위치를 계산해야 하는 기능은

반드시 실제 DOM을 ref로 직접 조작해야 한다.

📦 핵심 요약

✅ 정말 중요한 한 줄 요약

ref는 "React야, 이 DOM 여기 있어!" 하고 알려주는 표시자야.

드래그 앤 드롭처럼 실제 위치, 크기 등을 계산해야 할 땐

가상 DOM으론 부족하니까 → ref로 실제 DOM을 직접 가리켜야 해.

현재 Redux가 압도적으로 많이 사용되고 있지만 문법이 더러운편이라 학습에 시간이 필요하다고 한다. Post Redux로서 사용자가 빠르게 늘고 있는 Zustand에 대해 알아보도록 하자

사용하는 이유

기본적으로 React의 데이터 흐름은 State & Props를 사용해 단방향으로 이루져야 한다는 원칙이 있다.

이러한 데이터 흐름은 단순하고 예측 가능하며 컴포넌트 간의 관계를 명확히 정의하기 때문에 유지보수성을 향상시킨다.

하지만.. 데이터를 전달하는 과정에서 거쳐야 하는 컴포넌트가 너무 많은 상황이면 어떨까?

⚠️Props Drilling 발생!!!!!

1. 최상위 부모 컴포넌트에서 상태나 데이터를 가지고 있다.
2. 중간에 위치한 하위 컴포넌트가 해당 데이터에 접근할 필요가 있다.
3.  하지만 중간에 있는 다른 컴포넌트들은 그 데이터를 사용하지 않음에도 불구하고, 
   React 구조상 자식에게 전달하려면 무조건 props로 받아야 하므로, 
   그냥 “전달만 하는” 역할을 하게 된다. 
4. 결과적으로 데이터는 여러 컴포넌트를 통과하여 목적지에 도달한다. 
5. 이 과정을 “props drilling”이라고 함

코드로 보자면..

// 👑 App (최상위)
function App() {
  const user = { name: "봄김" };
  return <Parent user={user} />;
}

// 👩 Parent (데이터 안 씀) → 그냥 전달
function Parent({ user }: { user: { name: string } }) {
  return <Child user={user} />;
}

// 👧 Child (데이터 안 씀) → 또 전달
function Child({ user }: { user: { name: string } }) {
  return <TargetComponent user={user} />;
}

// 🎯 TargetComponent (여기서만 사용)
function TargetComponent({ user }: { user: { name: string } }) {
  return <div>{user.name}님 환영합니다!</div>;
}

Parent, Child는 user라는 데이터가 필요 없음에도 불구하고, 하위 컴포넌트에 전달하기 위헤 props를 계속 받아서 넘겨야함

이게 바로 props drillling의 문제의 핵심이다.

😵 문제점 요약

• 중간 컴포넌트가 필요 없는 데이터를 계속 전달해야 함
• 컴포넌트 구조가 복잡해질수록 코드 유지보수가 어려워짐
• 구조가 바뀔 경우 관련된 컴포넌트 모두를 수정해야 함
• 불필요한 렌더링 유발 가능성 존재

그래서 Zustand!

👉 Zustand는 이런 props drilling을 막기 위한 "전역 상태 관리 라이브러리"!

즉, 필요한 컴포넌트는 Zustand stord에서 직접 가져와서 사용하면 된다.

중간 단계 컴포넌트를 거칠 필요가 없는것!!!!!

✨ Zustand로 바꾼다면?

📦 상태 저장소 정의

// store/userStore.ts
import { create } from 'zustand'

export const useUserStore = create(() => ({
  user: { name: '봄김' },
}));

🧾 컴포넌트에서 바로 사용

function UserInfo() {
  const user = useUserStore((state) => state.user);
  return <div>{user.name}님 환영합니다!</div>;
}

➡️ 이제는 중간에 있는 Parent, Child 컴포넌트가 전혀 신경 쓸 필요 없음!

📌 마무리 요약

entities 폴더에는 데이터 중심 개념이 들어간다.

• User, Post, Comment, Product, Team, Ranking 등
• 이들은 앱 내에서 "핵심 객체(주체)" 로 존재하며,
• 관련된 모델, API, 상태 등을 포함한다.

features 폴더에는 기능 중심 개념이 들어간다.

• 예: login, signup, writeComment, likePost 등
• 사용자의 행위(시나이로) 를 담당하며,
• 보통 UI와 로직 이 함께 들어있다.

그렇다면 "데이터 중심"이란?

현실 세계에 존재하는 개체를 앱 안에서 고유한 데이터 구조로 모델링한 것

• 앱에서 어떤 대상을 표현하거나 저장하려면 데이터를 기반으로 구조화해야 한다.
• 이런 구조는 다양한 화면인 기능에서 재사용 가능하다.

🔍 예시로 이해하기

🔷 User → 데이터 중심 개념 (✅ entities에 들어감)

{
  id: 1,
  name: "봄김",
  email: "bom@dev.com"
}

• 사용자라는 대상을 표현하는 객체
• 여러 화면에서 보여지고, 상태로도 저장됨 → 데이터 중심

🔷 signin → 기능 중심 개념 (✅ features에 들어감)

• 로그인을 한다는 건 행위이지, 어떤 대상을 표현하는 건 아님

• POST /login 요청을 보낼 뿐, 이 자체는 데이터로 저장되지 않음

  → 따라서 기능 중심 개념

✅ 개념 비교 정리

💡 더 쉽게 기억하는 법

🔄 기억용 요약 문장

"데이터 중심이라는 건, 화면에 보여지고 저장되는 정보 자체를 중심으로 생각하는 거야.User는 어떤 대상(사람)이지만, signin은 행동이잖아?"

📌 추가로 알아두면 좋은 점

❓ entities 폴더에 signin 같은 기능이 들어가도 될까?

• FSD 원칙에 따르면,

  • 데이터 중심 개념은 entities/,
  • 행동 중심 기능은 features/에 넣는 것이 가장 이상적이다.

• 하지만 실제 프로젝트에서는 규모나 팀 스타일에 따라

  features/를 따로 만들지 않고, 작은 기능들을 entities/ 안에 넣는 경우도 많다.

• 즉, entities/signin처럼 구성된 경우도 잘못된 건 아니며,

  작은 기능을 "하나의 도메인처럼" 다룬 유연한 구조라고 이해하면 된다.

코드 포맷터 내가 작성한 코드를 일정한 규칙에 맞게 자동으로 정리해주는 도구이다.

예시

// 포맷팅 전
function hello ( ){console.log("hi")}

// 포맷팅 후 (Prettier 적용 시)
function hello() {
  console.log("hi");
}

🛠️ Prettier의 장점

• 팀원 간 코드 스타일 통일
• 저장할 때마다 자동 정리 → 시간 절약
• 리뷰 때 불필요한 스타일 논쟁 줄어듦

⚙️ Prettier 설정 방법 (2가지)

① .prettierrc 파일로 설정

설정 전용 파일을 루트 디렉토리에 만들어서 사용

파일명 예시: .prettierrc, .prettierrc.json, .prettierrc.yaml 등

{
  "semi": true,
  "singleQuote": true,
  "printWidth": 100
}

→ 이 파일이 있으면 Prettier는 여기 설정을 따름

② package.json 안에 "prettier" 항목으로 설정

따로 파일 안 만들고, 프로젝트 설정 파일 안에서 설정

{
  "name": "my-project",
  ...
  "prettier": {
    "semi": true,
    "singleQuote": true}
}

→ 이 경우에도 동일하게 작동함

✨ 결론 요약

📌 주제: Next.js 프로젝트 생성 – 수동 설치 vs create-next-app 자동 설정

✅ 1. 내가 처음 사용한 방식 – 수동 설치

처음에는 강의에서 알려준 대로 아래처럼 수동으로 Next.js 프로젝트를 구성했다:

mkdir my-next-app
cd my-next-app
npm init -y
npm install react react-dom next
mkdir app
touch app/page.tsx

그리고 package.json을 아래처럼 수정했다:

"scripts": {
  "dev": "next dev",
  "build": "next build",
  "start": "next start"
}

이 방식은 모든 구조와 설정을 직접 만져보면서 학습할 수 있다는 장점이 있었다.

하지만 실제 협업 프로젝트에 들어가면서 여러 치명적인 단점을 겪었다.

🧨 2. 겪은 문제들

• .eslintrc.json은 있는데 eslint가 설치되어 있지 않음

  → 설정만 있고 작동은 안 되는 상태

• .prettierrc 파일도 수동으로 만들었지만 관련 패키지가 없었음

• TypeScript는 설치했지만 tsconfig.json 설정은 직접 만들어야 했음

• 팀원들마다 환경이 달라서 코드 스타일이 달라지고 충돌 발생

• Tailwind CSS도 수동 설치해야 해서 공식 문서를 계속 참고해야 했음

✅ 3. 협업에서는 create-next-app이 훨씬 낫다는 걸 깨달음

나중에 npx create-next-app@latest를 써보면서 다음과 같은 장점을 느꼈다:

npx create-next-app@latest .

. 을 붙이면 현재 폴더에 세팅됨

생성 중 질문 예시 & 추천 답변:

이렇게만 선택하면 모든 설정이 자동으로 되어, 실수 없이 바로 개발에 들어갈 수 있다.

💡 4. 도구들에 대한 이해

• ESLint: 코드 문법 검사기. 실수를 방지하고 일관된 코드 스타일을 유지해준다.
• Prettier: 코드 포맷터. 줄 정리, 들여쓰기, 세미콜론 자동 정리 등.
• Tailwind CSS: CSS를 유틸리티 클래스 기반으로 빠르게 작성할 수 있게 해주는 프레임워크.
• TypeScript: 자바스크립트에 타입을 추가해 주는 언어. 코드 안정성과 자동완성 기능 향상.

🌱 5. 깨달은 점

• 수동 설치는 배우는 데는 좋지만, 협업이나 실무에서는 자동 설정(create-next-app)이 훨씬 안정적이다.
• 필수 설정들을 빠뜨리면 작동이 안 되거나 버그가 생길 수 있다.
• create-next-app은 단순히 편한 게 아니라, "실무 기준의 안정적인 개발 환경을 만들어주는 도구"라는 걸 알게 됐다.
• 앞으로는 자동 설치로 시작한 후, 필요한 설정만 커스터마이징하는 방식으로 효율적으로 개발할 계획이다.

📁 6. 내가 만든 폴더 구조 예시

src/
├── entities/   # 핵심 도메인 모델
├── shared/     # 공통 유틸, 타입, 훅 등
├── views/      # 페이지 뷰
├── widgets/    # 재사용 가능한 UI 조각

🏁 마무리

이 경험을 통해, 단순히 코드를 작성하는 것이 아니라 개발 환경을 어떻게 구성하느냐도 실력이라는 걸 깊이 깨달았다.

수동 설치도 분명 도움이 되었고, 그 덕분에 자동 설치의 강력함도 제대로 느낄 수 있었다.

📎 관련 학습 기록

• 처음에는 아래와 같이 수동으로 Next.js 프로젝트를 설정하는 방법을 학습했었다.

  👉 TIL: Next.js 수동 프로젝트 생성법

• 이번에 협업 경험을 통해 자동 생성 방식(create-next-app)의 강력함과 효율성을 깨닫게 되었고,

  앞으로는 이 두 가지를 모두 이해하고 상황에 맞게 선택할 수 있게 되었다.

npm install --save-dev @types/react-query 명령어 실행 시, 아래와 같은 에러가 발생함:

npm error ERESOLVE could not resolve
...
Conflicting peer dependency: typescript@5.8.3
peerOptional typescript@"^3.2.1 || ^4" from react-scripts@5.0.1

원인 분석: 세 가지 버전 충돌 중 하나

TypeScript 프로젝트에서는 다음 세 가지 버전이 서로 영향을 주고 받는다:

🔥 에러 발생 구조 요약

타입스크립트 버전이 너무 높음
→ react-scripts가 이걸 감당하지 못함
→ @types/react-query 같은 타입 선언 설치도 실패

CRA가 왜 이 문제를 만들었을까?

CRA의 핵심 빌드 툴 = react-scripts

• CRA는 내부적으로 react-scripts라는 패키지를 사용해

  빌드, 테스트, 타입 검사 등을 자동으로 해준다.

• 그런데 현재 사용하는 react-scripts@5.0.1은

  TypeScript 5버전을 아직 지원하지 않는다.

• react-scripts가 허용하는 TypeScript 버전 범위는 다음과 같다:

    ^3.2.1 || ^4 (즉, TS 3 또는 TS 4.x까지만 가능)

😵‍💫 그래서 무슨 일이 벌어졌냐면?

너는 최신 버전인 TypeScript 5.8을 설치했는데,

CRA 내부의 react-scripts는 이렇게 말하는 거야:

react-scripts: "나 TS 4까지만 쓸 수 있어!"
TypeScript 5.8: "난 최신 버전이야!"

→ 둘이 버전이 안 맞아서 싸움 발생 → npm install 실패

✅ 해결 방법

🔧 방법 1: TypeScript 버전을 낮춰서 CRA에 맞춘다 (가장 쉬움)

npm uninstall typescript
npm install --save-dev typescript@4.9.5
npm install --save-dev @types/react-query

• 이렇게 하면 react-scripts@5.0.1과 TypeScript 버전이 일치하므로 충돌 없이 설치 가능!

🔧 방법 2: CRA를 탈출하고 Vite나 Next.js 같은 현대적인 도구로 전환한다

• CRA는 2024년 이후로 유지보수가 사실상 중단된 상태이다.
• 많은 개발자들이 더 빠르고 가벼운 빌드 도구인 Vite, Next.js, Parcel 등으로 넘어가는 중이다.
• 최신 TypeScript 기능을 무리 없이 사용하고 싶다면 장기적으로는 전환을 고려하는 것이 좋다.

느낀 점 및 교훈

• TypeScript 프로젝트에서는 세 가지 버전의 호환성을 꼭 확인해야 한다:
  1. 라이브러리 버전 (ex. react-scripts)
  2. 타입 선언 버전 (ex. @types/react-query)
  3. 타입스크립트 자체 버전 (ex. typescript@5.8)
• 하나라도 어긋나면 “설치가 안 되거나”, “엉뚱한 곳에서 에러가 터지는” 문제가 생긴다.
• CRA는 더 이상 최신 스택을 따라가지 못하고 있으며, 새로운 프로젝트에서는 대체 도구(Vite, Next.js 등)를 사용하는 것이 더 좋다.

컴포넌트에 전달되는 props의 타입은 interface를 사용해 지정한다.

interface TextProps {
  text: string;
  active?: boolean; // optional (선택적 props)
}

• text → 필수 props
• active? → 선택적 props

📌 2. 선택적 props vs 필수적 props

• :만 쓰면 필수
• ?:를 쓰면 선택적

interface ExampleProps {
  requiredProp: string;       // 필수
  optionalProp?: number;      // 선택
}

📌 3. props에 기본값 설정

기본값은 함수 파라미터에 직접 설정한다:

function Dummy({ text, active = false }: TextProps) {
  return <h1>{text}</h1>;
}

이렇게 하면 active를 전달하지 않아도 자동으로 false가 된다.

📌 4. Boolean props는 true일 때 생략된 형태로 작성 가능

<Dummy text="hello" active />

• 위 코드는 active={true}와 완전히 동일하다.
• 이는 boolean 타입 props의 특징으로, true일 경우 속성 이름만 작성해도 된다.

✅ 실습 예시 요약

interface TextProps {
  text: string;
  active?: boolean;
}

function Dummy({ text, active = false }: TextProps) {
  return <h1>{text}</h1>;
}

// 사용 예시
<Dummy text="hello" active />           // ✅ active는 true
<Dummy text="world" />                 // ✅ active는 false (기본값)

💡 마무리 요약

필요한 경우 defaultProps 방식도 있지만, 함수형 컴포넌트에선 파라미터 기본값 방식을 더 권장한다고 한다.

animation:
  name               → 어떤 애니메이션 쓸 건지
  duration           → 몇 초 동안 할 건지
  timing-function    → 속도가 어떻게 변할 건지
  delay              → 언제 시작할 건지
  iteration-count    → 몇 번 반복할 건지
  direction          → 방향은 어떻게 될 건지
  fill-mode          → 끝나고도 스타일 유지할 건지
  play-state         → 재생할지 멈출지

🔍 Step 1: animation-name

✅ 개념

@keyframes로 만든 애니메이션의 이름을 지정

🧠 예제

@keyframes fadeIn {
  from { opacity: 0; }
  to { opacity: 1; }
}

.box {
  animation-name: fadeIn;
}

🔍 Step 2: animation-duration

✅ 개념

애니메이션이 한 번 완전히 실행되는 데 걸리는 시간

💡 단위

• s → 초 (2s = 2초)
• ms → 밀리초 (500ms = 0.5초)

🧠 예제

.box {
  animation-name: fadeIn;
  animation-duration: 1.5s;
}

🔍 Step 3: animation-timing-function

✅ 개념

애니메이션의 속도 곡선 (느려졌다 빨라졌다 같은)

💡 대표 값

🧠 예제

.box {
  animation-name: fadeIn;
  animation-duration: 2s;
  animation-timing-function: ease-in-out;
}

🔍 Step 4: animation-delay

✅ 개념

애니메이션이 얼마 후에 시작될지 지정

🧠 예제

.box {
  animation-name: fadeIn;
  animation-duration: 1s;
  animation-delay: 2s; /* 2초 뒤에 시작 */
}

🔍 Step 5: animation-iteration-count

✅ 개념

애니메이션을 몇 번 반복할지 정함

💡 값

• 숫자 (1, 2, 3 등)
• infinite → 무한 반복

🧠 예제

.box {
  animation-name: fadeIn;
  animation-duration: 2s;
  animation-iteration-count: infinite;
}

🔍 Step 6: animation-direction

✅ 개념

애니메이션 반복 시 방향을 바꿀지 말지

🧠 예제

.box {
  animation: fadeIn 2s ease-in-out infinite alternate;
}

🔍 Step 7: animation-fill-mode

✅ 개념

애니메이션 시작 전/끝난 후의 스타일을 유지할지

🧠 예제

.box {
  animation: fadeIn 2s ease forwards;
}

→ 이걸 쓰지 않으면, opacity는 1이 되었다가 다시 0으로 돌아가 😅

🔍 Step 8: animation-play-state

✅ 개념

애니메이션을 재생할지, 일시정지할지

🧠 예제

.box {
  animation-play-state: paused;
}
.box:hover {
  animation-play-state: running;
}

✅ 요약 표 (정리용)

CSS 애니메이션(Animation) 이란,

"시간에 따라 요소의 스타일을 바꾸는 것" 이다.

즉, 요소를 움직이게 하거나 크기를 바꾸고, 색깔을 바꾸는 등의 동작을 자동으로 부드럽게 만들어주는 도구이다.

2. 왜 animation이 필요할까?

👉 스타일 변경 중심이면 CSS 애니메이션!

👉 사용자 상호작용/복잡한 로직이 필요하면 JavaScript!

3. CSS 애니메이션이 작동하는 원리

1. 애니메이션의 단계(keyframes)를 정의함

@keyframes myAnimation {
    from { opacity: 0 }
    to { opacity: 1 }
}

2. 애니메이션을 요소에 적용함

.box {
    animation-name: myAnimation;
    animation-duration: 2s;
}

3. 브라우저가 이걸 해석해서 시간에 따라 스타일을 자동으로 변화시킴

4. CSS 애니메이션 vs 트랜지션

5. 시각 예제: opacity 애니메이션

<style>
@keyframes fadeIn {
  from {
    opacity: 0;
  }
  to {
    opacity: 1;
  }
}

.box {
  width: 100px;
  height: 100px;
  background: pink;
  animation: fadeIn 2s ease-in-out forwards;
}
</style>

<div class="box"></div>

👉 결과: 박스가 천천히 나타나는 느낌

강의에서 사용된 이미지 레이아웃 스타일이 매우 유연하고 깔끔했는데,

그 방식이 단순히 width, height 설정이 아니라 max-width, min-height, grid, transition, opacity 등을 활용한 고급 반응형 CSS 패턴이라는 것을 이해했다.

✅ 패턴 예시 코드

.movie {
  display: grid;
  grid-template-rows: 1fr auto;
  gap: 25px;
}

.movie img {
  max-width: 100%;
  min-height: 100%;
  object-fit: cover;
  border-radius: 20px;
  transition: opacity 0.2s ease-in-out;
  opacity: 0.7;
}

.movie img:hover {
  opacity: 1;
}

.movie a {
  text-align: center;
}

🧠 각 속성의 의미 정리

🔹 .movie (부모 요소)

🔹 .movie img (이미지 요소)

✅ 핵심 특징

• 카드형 디자인에 적합한 레이아웃
• 이미지 비율 유지, 반응형 대응, 미려한 시각 효과
• 다양한 화면 크기에서도 레이아웃이 안정적

💡 실무 팁

• object-fit: cover + max-width: 100% 조합은 이미지를 꽉 채우면서도 예쁘게 보여주는 필수 패턴
• min-height는 카드 내부 요소들의 높이 균형을 맞추는 데 효과적
• 이미지가 다양한 크기일 때도 레이아웃이 깨지지 않도록 설계됨

💬 기억할 문장

반응형 이미지를 자연스럽게 보이게 하려면, max-width로 제어하고, object-fit으로 모양을 다듬자.

이 패턴은 카드, 갤러리, 영화 목록, 상품 리스트, 블로그 썸네일 등 실무에서 자주 쓰이는 고급 CSS 기법이다.

CSS에서 요소의 크기를 설정할 수 있는 다양한 속성들이 있다.

특히 width, height 와 max-width, min-height 는 이름이 비슷하지만 동작 방식이 매우 다르다.

이번에 그 차이를 실제 코드 예제와 함께 명확히 이해했다.

✅ 각 속성의 의미

✅ 예제 비교

🎯 width vs max-width

1. width: 300px

img {
  width: 300px;
}

• 이미지 너비는 항상 300px
• 부모가 더 작아도 넘쳐버릴 수 있음 → 깨짐 가능성

2. max-width: 100%

img {
  max-width: 100%;
}

• 이미지가 부모보다 커지지 않도록 제한
• 부모가 작으면 그에 맞게 자동으로 줄어듦

✅ 실전 코드에서의 차이

❌ 이렇게 하면 강제로 꽉 채움

.movie img {
  width: 100%;
  height: 100%;
}

• 부모 요소 크기만큼 무조건 꽉 채움
• 이미지 비율 깨질 위험 있음
• 높이도 강제로 맞추기 때문에, 넘치거나 늘어지는 경우 생길 수 있음

✅ 이렇게 하면 유연하게 반응

.movie img {
  max-width: 100%;
  min-height: 100%;
}

• max-width: 부모보다 커지지 않게 제한
• min-height: 최소한 부모 높이만큼은 차지하도록 보장
• 이미지의 비율도 유지되며, 부드러운 반응형 UI 구성 가능

💬 기억 문장

width는 명령, max-width는 제한, min-width는 최소한의 배려.

🧠 언제 어떤 걸 쓰면 좋을까?

이번 정리를 통해 이미지, 카드, 버튼 등 다양한 요소들의 유연한 크기 제어 방법을 명확하게 이해할 수 있었다.