PART 2: AI에게 디자인을 설명하는 방법

    들어가기

    1편에서는 왜 숙련된 디자이너의 시안도 AI 구현 단계에서 어긋날 수 있는지를 다뤘어요.

    핵심은 단순히 “AI가 디자인을 못 읽는다”가 아니었어요. 더 정확히는, 디자이너가 머릿속에서 이미 끝낸 판단이 AI에게는 거의 전달되지 않는다는 점이었어요.

    • 이건 한 방향 흐름인가, 격자인가
    • 이건 반복되는 패턴인가, 지금 화면만의 묶음인가
    • 어떤 상태가 꼭 정의되어야 하는가
    • 어떤 규칙은 절대 흔들리면 안 되는가
    • 어디까지가 재사용 단위인가

    그렇다면 이제 이런 질문을 던져볼까요?

    그래서 실제로는 어떻게 설명해야 할까?

    여기 Part 2에서는 바로 그 부분을 다룰게요. 시안을 그냥 던지는 대신, AI가 덜 틀리도록 요청을 설계하는 방법과, 그 과정을 실제 Next.js 프로젝트에서 어떻게 밟아 가면 되는지를 함께 정리해 볼 거예요.

    바이브 코딩에서는 디자인 이미지를 보여주는 것 자체보다, 그 시안을 웹의 언어로 번역해서 전달하는 것이 더 빠를 수 있어요.

    이 글에서는 그 번역을 단계별로 설명할게요.

    1. 목표와 범위
    2. 레이아웃 구조
    3. 컴포넌트 경계
    4. 상태·의미·상호작용
    5. 시스템 규칙과 예외 케이스

    2. 요청에 들어가야 하는 것

    요청이 잘 작동하려면, 페이지를 바로 만들기보다 먼저 디자인 시스템과 작은 컴포넌트 단위를 고정하는 편이 훨씬 안정적이에요.

    준비
→ 디자인 시스템과 작은 컴포넌트부터 바이브 코딩
→ 페이지 조립
→ 반응형 / 예외 케이스 추가
→ 수정 루프
→ Vercel 배포

    왜냐하면 공통 규칙과 작은 단위를 먼저 고정해 두어야 그 위에 구조와 화면을 얹었을 때 임의 값이 섞이지 않고, AI도 무엇을 만들고 어디까지만 건드려야 하는지를 순서대로 판단할 수 있기 때문이에요.

    예를 들어 카드 리스트를 만든다고 할 때, 목표와 “색상·spacing은 토큰만 쓴다” 같은 기반을 먼저 두고, Button, Card, Tag 같은 작은 단위를 정한 뒤 레이아웃을 설명하면 세부 스타일이 나중에 붙어도 덜 깨져요.

    즉 설명은 아무 정보나 많이 주는 것이 아니라, AI가 판단해야 할 순서대로 주는 것이 중요해요.

    3. 실제 프로젝트에서

    이제 글의 내용을 실제 작업 순서로 바꿔 볼게요. 디자이너가 Next.js 프로젝트를 만들고, AI와 함께 바이브 코딩한다고 가정하면 이런 순서로 진행돼요.

    1. 준비하기

    처음 시작하는 분이라면, 코드를 만들기 전에 먼저 몇 가지 도구가 필요해요.

    Node.js와 npm

    Next.js 프로젝트를 만들려면 먼저 Node.js를 설치해야 해요. Node.js는 자바스크립트를 브라우저 밖에서도 실행할 수 있게 해 주는 실행 환경이에요. 설치하면 보통 npm도 함께 들어와요. npm은 자바스크립트 프로젝트에서 필요한 라이브러리와 도구를 설치하고 관리하는 패키지 매니저예요. 예를 들어 Next.js, React, Tailwind CSS 같은 것들을 설치할 때 npm을 사용해요.

    처음에는 이렇게 이해하면 충분해요.

    • Node.js: 자바스크립트를 실행하는 기반
    • npm: 필요한 도구를 설치하고 실행하는 매니저

    설치가 끝나면 터미널에서 아래 명령어로 확인할 수 있어요.

    node -v
npm -v

    Node.js 공식 다운로드 페이지에서는 LTS(Long-Term Support, 장기 지원) 버전을 제공하고 있고, 일반적으로 처음 시작할 때는 LTS 버전을 설치하는 편이 무난해요.


    어떤 에디터를 쓰면 좋을까?

    코드를 편집할 때는 VS Code나 Cursor 중 하나로 시작하면 돼요.

    • VS Code
      • 무료예요
      • macOS, Windows, Linux에서 사용할 수 있어요
      • 처음 시작하는 사람에게 가장 무난해요
    • Cursor
      • AI 기능이 더 전면에 나와 있는 에디터예요
      • 프로젝트를 읽고, 수정하고, 코드 생성을 돕는 흐름이 강해요
      • “AI와 바로 같이 만들고 싶다”면 더 잘 맞을 수 있어요.

    그래서

    • 가장 무난하게 시작하고 싶다 → VS Code
    • 이후 코드를 직접 건드리거나, Cursor Agent까지 사용할 생각이 있다 → Cursor

    둘 다 괜찮지만, 바이브 코딩에 익숙하지 않다면 VS Code로 시작해도 충분하고, AI 중심 작업을 빠르게 익히고 싶다면 Cursor도 좋은 선택이에요.

    왜 Next.js로 시작할까?

    Next.js는 React 기반 웹 앱을 만들 때 많이 쓰이는 도구예요. 프로젝트 뼈대를 한 번에 잡기 쉽고, 예제와 문서가 많아서 AI가 참고할 패턴도 풍부한 편이에요. 그래서 바이브 코딩으로 시작할 때 비교적 안정적으로 사용할 수 있어요.

    Next.js 공식 문서에서는 create-next-app으로 새 앱을 만들고 개발 서버를 띄우는 흐름을 기본 시작점으로 안내해요.

    npx create-next-app@latest my-project
cd my-project
npm run dev

    여기서 npx는 npm과 함께 쓰는 실행 도구라고 생각하면 돼요. 직접 설치하지 않은 프로젝트 생성 도구도 한 번 실행할 수 있게 도와줘요. Next.js 프로젝트를 빠르게 시작할 때 자주 써요.

    가능하다면 이 시점에 Figma MCP 서버도 연결해 두면 좋아요. 그러면 Auto Layout, gap, padding, 프레임 구조 같은 정보 전달이 더 수월해질 수 있어요.


    그래서 준비 단계는 보통 이렇게 보면 돼요.

    1. Node.js 설치 & npm 사용 가능 여부 확인
    2. VS Code 또는 Cursor 설치
    3. Next.js 프로젝트 생성
    4. 가능하면 Figma MCP 연결
    5. 로컬 실행 확인

    이런 설정이 귀찮거나 어렵다면, 2번까지 한 다음에 그냥 AI 켜서 "Next.js 프로젝트와 피그마 MCP 세팅해줘"라고 요청해도 괜찮아요.

    2. 디자인 시스템과 작은 컴포넌트부터 고정하기

    처음부터 페이지 전체를 한 번에 만들기보다, 버튼·태그·입력창·카드처럼 반복해서 쓸 작은 단위를 먼저 만드는 편이 훨씬 안정적이에요. 왜냐하면,

    • 공통 규칙을 먼저 고정할 수 있고
    • 상태를 한 번 정의해 여러 곳에서 재사용할 수 있고
    • 페이지를 조립할 때 임의 값이 섞일 가능성이 줄고
    • AI도 새로운 화면을 만들기보다 기존 단위를 재사용하는 쪽으로 유도할 수 있기 때문이에요.

    컴포넌트 → 섹션 → 페이지 순으로 올라가는 거예요.

    디자인 시스템 규칙 정하기
→ Button, Tag, Input, ...
→ Card
→ CardList / FeatureCards
→ Page 조립

    요청을 작성할 때는 아래 순서를 따르면 돼요.

    • 목표와 범위
    • 레이아웃 구조
    • 컴포넌트 경계
    • 상태·의미·상호작용
    • 시스템 규칙과 예외 케이스

    예를 들어 Button을 만들 때는 페이지 전체를 생각하지 않고 이렇게 요청하는 거예요.

    Button 컴포넌트를 만들어 주세요.

목표
- primary 버튼 컴포넌트 구현

수정 범위
- Button 컴포넌트만 생성
- 다른 컴포넌트는 건드리지 않음

디자인 시스템 규칙
- spacing은 8px scale 사용
- radius와 color는 기존 token만 사용
- variant는 primary / secondary / ghost만 허용

상태
- hover / focus / disabled 필요

    그리고 Tag에서는 Tag 규칙만 따로 잡고, Card에서는 기존 Button과 Tag를 재사용하는 식으로 점점 쌓아 올라갈 수 있어요.

    3. 페이지 조립

    작은 컴포넌트가 어느 정도 안정되면, 그다음에 /app/page.tsx나 /app/blog/page.tsx 같은 실제 페이지에서 조립해요.

    랜딩 페이지같은 경우에는 이런 영역으로 나눌 수 있어요.

    - Navbar
- Hero
- FeatureCards
- Footer

    블로그 페이지라면 이렇게 나눌 수 있어요.

    - PageHeader
- FilterBar
- PostCardList
- Pagination

    예를 들면 이렇게 요청할 수 있어요.

    /app/blog/page.tsx에서 PostCardList를 배치해 주세요.

레이아웃
- desktop 3열 / tablet 2열 / mobile 1열 grid
- gap 16px

범위
- PostCard 내부 구조는 바꾸지 말고, 리스트 배치와 섹션 조립만 수정해 주세요.

    4. 반응형과 예외 케이스 붙이기

    페이지가 조립되면, 이제는 깨지는 조건을 찾아서 덜 깨지게 만들어야 해요.

    예를 들면 이런 케이스를 고려해볼 수 있어요.

    예외 케이스 추가
- 제목 최대 2줄, 넘으면 말줄임표
- 이미지 없으면 placeholder
- 빈 리스트면 안내 문구와 CTA 중앙 정렬
- 태그 최대 3개, 초과 시 +N
- mobile에서는 보조 메타 정보를 줄이고 핵심 정보 우선 유지

    5. 검증과 반복

    이제 꼼꼼히 확인하면서, 수정 루프를 돌아야 해요.

    • 로컬에서 깨지는 부분 보기
    • Figma와 비교하기
    • 어긋난 부분만 좁혀서 수정 요청하기
    빈 리스트일 때 "등록된 항목이 없습니다" 문구가 왼쪽으로 치우쳐 보여요.
기존 카드 리스트 컴포넌트는 그대로 두고, 빈 상태 영역만 가운데 정렬해 주세요.

    이런 식으로 깨진 지점 + 유지할 것 + 고칠 것을 같이 말하면 좋아요.

    6. 배포

    Next.js는 공식적으로 다양한 배포 방식을 지원하고, Vercel은 Next.js에 대해 zero-config에 가까운 배포 경험을 제공해요.

    • Git에 올리기
    • Vercel로 연결하기
    • 배포 후 실제 디바이스에서 다시 보기

    4. Step 1: 먼저 목표와 수정 범위를 적는다

    이제 각 요청을 어떻게 채워넣을 수 있는지 살펴볼게요.


    예를 들어 이렇게 말하면 불안정해요.

    랜딩 페이지를 만들어줘.

    이 말은 너무 넓어요. AI는 전체 구조를 새로 짜도 되는지, 기존 컴포넌트를 재사용해야 하는지, 특정 섹션만 만들면 되는지 알 수 없어요.

    그래서 가장 먼저 적어야 하는 건 보통 이 두 가지예요.

    • 이번 요청의 목표
    • 이번 요청의 수정 범위

    예를 들면 이렇게요.

    목표
- 블로그 카드 리스트 섹션을 만든다

수정 범위
- FeatureCards 섹션만 구현한다
- Navbar, Footer, 기존 Card 내부 구조는 바꾸지 않는다

    혹은 이렇게 더 짧게 쓸 수도 있어요.

    이번 요청에서는 Hero와 FeatureCards만 만든다.
기존 Header와 Footer는 수정하지 않는다.

    5. Step 2: 레이아웃은 "모양"이 아니라 "배치 규칙"으로 설명한다

    1편에서 본 것처럼, 웹은 좌표보다 흐름과 규칙으로 배치돼요. 그래서 AI에게도 이렇게 설명해야 해요.

    • 세로 스택인가
    • 가로 정렬인가
    • grid 몇 열인가
    • gap은 얼마인가
    • 어떤 기준에서 줄바꿈되는가
    • 오버레이인가
    • 레이어 우선순위가 필요한가

    예를 들어 이런 요청은 약해요.

    카드가 예쁘게 정렬되게 해줘.

    이 말에는 실제 배치 규칙이 없어요. 그래서 AI는 가장 흔한 방식으로 대충 맞추려 해요.

    반면 이런 요청은 강해요.

    FeatureCards는 grid 기반이다.
desktop 3열 / tablet 2열 / mobile 1열로 배치한다.
gap은 16px이고, 카드 최소 폭은 320px을 유지한다.

    이렇게 쓰면 AI가 추정해야 할 부분이 줄어요.

    레이아웃을 설명할 때 체크할 질문

    다음 질문에 답할 수 있으면 레이아웃 설명이 훨씬 명확해져요.

    • 이건 한 방향 흐름인가, 2차원 격자인가
    • 줄바꿈이 자연스럽게 일어나야 하는가
    • 카드 수가 늘어나도 구조가 유지돼야 하는가
    • 모바일에서는 단순 축소가 아니라 열 수가 바뀌는가
    • 떠 있는 UI라면 오버레이와 레이어 규칙이 필요한가

    자주 쓰는 문장 패턴

    바로 복사해서 쓸 수 있는 문장으로 바꾸면 이런 식이에요.

    이 영역은 세로 스택입니다.
이 영역은 가로 정렬 flex입니다.
이 목록은 grid 기반이며 desktop 3열 / tablet 2열 / mobile 1열입니다.
이 요소는 오버레이이므로 본문 흐름 밖에 떠 있어야 합니다.
드롭다운은 트리거 아래에 열리고, 다른 카드 뒤로 숨지 않도록 레이어 우선순위를 유지해 주세요.

    6. Step 3: 화면을 바로 설명하지 말고 컴포넌트 경계부터 끊는다

    AI가 자주 틀리는 부분 중 하나가 어디까지를 하나의 컴포넌트로 볼 것인가예요.

    그래서 요청할 때는 현재 화면을 설명하기 전에 먼저 재사용 단위를 적는 편이 좋아요.

    이 섹션은 Card 컴포넌트를 반복해서 구성한다.
Card는 이미지 / 제목 / 설명 / CTA 버튼으로 이루어진다.

    컴포넌트 경계를 설명할 때 유용한 기준

    1) 재사용되는가

    여러 화면에서 반복된다면 공통 컴포넌트 후보예요.

    • Button
    • Card
    • Tag
    • Input
    • Modal

    2) 변형만 다른가

    같은 뼈대에 variant만 바뀐다면 하나의 컴포넌트 안에서 다루는 편이 좋아요.

    • Button: primary / secondary / ghost
    • Card: default / interactive / selected
    • Input: default / error / disabled

    3) 의미가 다른가

    시각적으로 비슷해도 역할과 동작이 다르면 다른 컴포넌트로 두거나, 같은 카드라도 규칙을 나눠서 적어 주는 편이 좋아요.

    • 링크 카드: 카드 전체가 한 개의 링크예요. 클릭하면 한 URL로 이동해요. <a>나 클릭 영역 하나로 다뤄야 하고, 포커스와 키보드 동작도 “링크 하나” 기준이에요.
    • 선택 카드: 목록 안에서 하나(또는 여러 개)를 고르는 용도예요. 선택됨/해제됨 상태가 있고, 라디오나 체크박스 같은 의미(role)가 필요할 수 있어요.
    • 단순 정보 카드: 보여주기만 하는 카드예요. 카드 자체는 클릭되지 않고, 안에 있는 버튼만 동작해요. 클릭 영역과 포커스 순서를 “카드 전체”가 아니라 “내부 버튼만”으로 두는 식으로 규칙이 달라요.
    • 토글형 카드: 클릭하면 카드가 펼쳐지거나 접혀요. 한 번 누르면 이동하는 링크 카드와는 동작이 다르고, 접근성(expanded/collapsed, aria-expanded)이나 키보드 동작도 따로 정의해야 해요.

    겉모양이 비슷해도 “전체가 링크인지, 선택용인지, 정보만 보여주는지, 펼치기용인지”를 구분해서 적어 두면 AI가 구현할 때 헷갈리지 않아요.

    7. Step 4: 상태, 의미, 상호작용 규칙을 같이 적는다

    예를 들어 카드 UI를 요청하면서도 아래를 말하지 않는 경우가 많아요.

    • hover/focus가 필요한가
    • disabled는 어떤 모습인가
    • 카드 전체가 클릭되는가
    • 버튼만 클릭되는가
    • Enter / Space로 동작해야 하는가
    • ESC로 닫히는가
    • 바깥 클릭 시 닫히는가

    상태를 설명하는 문장 예시

    버튼은 hover / focus / disabled 상태를 가져야 한다.
입력창은 default / error / readonly 상태를 가져야 한다.
드롭다운은 collapsed / expanded 상태가 있고, ESC와 바깥 클릭으로 닫힌다.
로딩 중에는 aria-busy를 적용하고 상호작용을 막는다.

    의미를 설명하는 문장 예시

    카드 제목은 heading 역할이다.
카드 전체는 클릭 가능한 링크가 아니라, 내부 버튼만 클릭 가능하다.
장식용 아이콘은 스크린리더에서 읽지 않게 처리한다.

    상호작용 규칙을 설명하는 문장 예시

    Enter와 Space로 버튼이 동작해야 한다.
모달이 열리면 초기 포커스가 첫 액션으로 이동해야 한다.
드롭다운은 트리거를 다시 누르거나 바깥 클릭 시 닫힌다.
탭 순서는 시각적 순서와 크게 어긋나지 않게 유지한다.

    8. 요청 템플릿

    아래 템플릿은 바로 붙여 넣고 수정해서 쓸 수 있어요.

    기본 템플릿

    프로젝트
- [예: Next.js / React / HTML]
- [버전이나 제약이 있으면 함께 적기]

목표
- 이번 요청에서 만들 것

수정 범위
- 수정할 영역
- 수정하지 말아야 할 영역

디자인 시스템 규칙
- spacing: [예: 8px scale]
- color: [token만 사용]
- typography: [heading / body / caption 위계]
- radius / shadow / border 제약

컴포넌트
- [반복되는 UI]는 [컴포넌트명]을 반복 사용
- [컴포넌트명] 구성: [이미지 / 제목 / 설명 / 버튼]
- [variant 또는 재사용 규칙]

레이아웃
- [영역 이름]: [세로 스택 / 가로 정렬 / grid]
- [정렬 방식]
- [gap / padding]
- [desktop / tablet / mobile 변화]
- [필요하면 overlay / layer 규칙]

상태 / 의미 / 상호작용
- [hover / focus-visible / disabled / error / loading]
- [버튼 / 링크 / heading / decorative icon]
- [ESC 닫기 / 바깥 클릭 / 탭 순서 등]

예외 케이스
- 텍스트 길이
- 이미지 없음
- 빈 상태
- 리스트 개수 변화
- 반응형 전환

출력 방식
- [예: 컴포넌트 코드만]
- [예: 기존 구조를 유지하며 수정]

    짧은 버전 템플릿

    목표
- FeatureCards 섹션 구현

범위
- FeatureCards만 수정
- Header, Footer는 유지

디자인 시스템 규칙
- spacing 8px scale
- token만 사용
- 임의 hex, px 금지

컴포넌트
- Card 컴포넌트 반복 사용
- CTA는 Button ghost variant 사용

레이아웃
- desktop 3열 / tablet 2열 / mobile 1열 grid
- gap 16px

상태
- hover / focus-visible / disabled 필요
- 카드 전체는 클릭되지 않고 버튼만 클릭 가능

예외
- 제목 최대 2줄
- 이미지 없으면 placeholder
- 태그 최대 3개 + 초과 시 +N
- 빈 상태 안내 문구 필요

    9. 구현 확인하고 수정하기

    AI가 코드를 생성한 뒤에는, “어디를 어떻게 고쳐야 하는지”를 빠르게 찾을 수 있으면 수정 루프가 짧아져요. Next.js 프로젝트의 기본 구조와, 브라우저 개발자 도구로 값을 확인하는 방법만 알아 두어도 충분해요.

    HTML, CSS, JavaScript 파일

    프로젝트를 열면 확장자마다 하는 일이 달라요. 어디를 고쳐야 할지 정할 때 "구조를 바꿀지, 모양을 바꿀지, 동작을 바꿀지"에 따라 열 파일이 달라져요.

    • HTML(또는 React/Next.js에서는 JSX·TSX 안의 마크업)

      • 역할: 화면의 뼈대예요. 제목, 단락, 버튼, 링크, 이미지처럼 “무엇이 있는지”를 태그로 나타내요.
      • 읽는 방법: <div>, <button>, <span> 같은 태그 이름과 **안에 무엇이 들어 있는지(계층)**를 보면 돼요. “이 버튼이 어떤 텍스트를 감싸고 있는지”, “이 카드 안에 제목과 본문이 어떻게 들어 있는지”를 따라가 보면 구조가 보여요.
      • 고칠 때: 요소를 추가·삭제하거나, 다른 컴포넌트로 바꾸고 싶을 때 이 부분을 수정해요.

    • CSS(.css 파일 또는 Tailwind 같은 유틸리티 클래스)

      • 역할: 모양을 정해요. 색, 글자 크기, 간격, 레이아웃(flex, grid), 여백, 테두리 등이 여기서 정해져요.
      • 읽는 방법: 선택자(어떤 요소에 적용하는지)와 속성(color, padding, font-size, display 등)을 보면 돼요. “이 클래스가 어떤 스타일을 주는지”만 읽어도 대부분 파악할 수 있어요.
      • 고칠 때: 색이 다르다, 간격이 다르다, 정렬이 어긋났다 싶으면 CSS(또는 해당 컴포넌트의 클래스/스타일)를 보면 돼요.

    • JavaScript(또는 TypeScript .ts, .tsx)

      • 역할: 동작을 담당해요. 클릭하면 무엇이 일어나는지, 폼을 보내는지, 화면이 바뀌는지 같은 로직이 들어 있어요.
      • 읽는 방법: 함수(function, const ... = () => {}), 이벤트(onClick, onSubmit), 상태(useState 등)를 보면 돼요. “이 버튼을 누르면 어떤 함수가 호출되는지”, “어떤 값이 바뀌면서 화면이 갱신되는지”를 따라가 보면 돼요.
      • 고칠 때: “클릭해도 반응이 없다”, “값이 기대와 다르게 바뀐다”처럼 동작이 어긋났을 때는 이 파일을 보면 돼요.

    Next.js 프로젝트에서는 한 컴포넌트 파일(.tsx) 안에 **구조(JSX)**와 **동작(JavaScript/TypeScript)**이 같이 들어 있고, 모양은 같은 파일의 클래스나 별도 .css 파일, 또는 Tailwind로 들어 있는 경우가 많아요.


    Next.js(App Router) 기본 폴더 구조

    create-next-app으로 만든 프로젝트는 보통 아래와 비슷한 구조예요.

    app/
├── layout.tsx        ← 전체 공통 레이아웃
├── page.tsx          ← 루트 경로(/) 페이지
├── login/
│   └── page.tsx      ← /login 페이지
├── blog/
│   ├── page.tsx      ← /blog 페이지
│   └── [postId]/
│       └── page.tsx  ← /blog/{postId} 페이지
├── globals.css       ← 전역 스타일

components/           ← 재사용 컴포넌트 폴더 (프로젝트에 따라 app/components나 src/components일 수도 있음)
├── Button.tsx
├── Card.tsx

    즉 URL 경로와 app/ 폴더 구조가 연결돼요. 버튼이나 카드처럼 여러 화면에서 반복해서 쓰는 UI는 보통 components/ 쪽에 따로 분리해 두는 편이에요.


    컴포넌트를 고치려면

    버튼, 카드, 입력창처럼 여러 페이지에서 쓰는 UI 단위는 보통 프로젝트 루트의 components/ 폴더에 있어요. 버튼 스타일을 바꾸고 싶으면 Button.tsx, 카드 내부 레이아웃을 바꾸고 싶으면 Card.tsx를 찾아 열면 돼요.

    혹은 그 페이지 안에서만 쓰는 컴포넌트인 경우에는, 해당 페이지 폴더 안에 components/ 또는 _components/ 폴더를 두고 그 안에서 불러오는 경우가 있어요. 예를 들어 /blog 페이지 전용 컴포넌트는 app/blog/components/(또는 app/blog/_components/) 안에 있고, app/blog/page.tsx에서만 import해서 써요. 이렇게 되어 있으면 “이 컴포넌트는 이 페이지에만 쓰인다”는 뜻이에요. 수정해도 다른 경로에는 영향이 없어요.

    즉 이런 경우예요.

    • 버튼 색, radius, padding을 바꾸고 싶다 → 루트 components/Button.tsx
    • 카드 안 제목 / 설명 / 버튼 배치를 바꾸고 싶다 → 루트 components/Card.tsx
    • /blog 페이지에만 쓰는 목록 헤더를 바꾸고 싶다 → app/blog/components/(또는 _components/) 안의 해당 파일

    공통으로 쓰는 컴포넌트를 수정하면 여러 페이지에 같이 영향을 줄 수 있어요. 그래서 루트 components/를 고칠 때는 “이 변경이 다른 페이지에도 적용돼도 괜찮은지”를 같이 확인하는 편이 좋아요. 페이지 폴더 안의 컴포넌트는 그 페이지에만 쓰이므로, 그 범위 안에서만 수정하면 돼요.

    페이지를 고치려면

    반대로 특정 화면의 배치나 조립만 바꾸고 싶다면 app/ 아래의 page.tsx를 보면 돼요.

    예를 들어:

    • / 경로를 바꾸고 싶다 → app/page.tsx
    • /login 화면을 바꾸고 싶다 → app/login/page.tsx
    • /blog 목록 화면을 바꾸고 싶다 → app/blog/page.tsx
    • /blog/123 같은 상세 화면을 바꾸고 싶다 → app/blog/[postId]/page.tsx

    즉 공통 UI 자체를 바꿀지, 특정 페이지에서 어떻게 배치되는지만 바꿀지를 먼저 구분하면 파일을 찾기가 쉬워져요.

    개발자 도구로 실제 화면 값 확인하기

    브라우저에서 우클릭 → 검사(또는 F12)로 개발자 도구를 열면, 지금 화면에 적용된 실제 값을 직접 볼 수 있어요.

    가장 자주 보는 건 이런 것들이에요.

    • width, height
    • padding, margin
    • font-size, line-height
    • display, flex, grid
    • border-radius
    • color, background-color

    특히 Computed 탭을 보면 Box model 그림에서 최종적으로 적용된 값을 볼 수 있어서, “이 간격이 몇 px인지”, “이 카드 높이가 왜 이렇게 나왔는지”, “이 텍스트가 몇 px인지”를 확인하기 좋아요.

    그래서 시안과 비교할 때, 실제 화면에 적용된 값을 개발자 도구에서 확인할 수 있어요.

    추가로 디버깅에 사용하기 좋은 도구

    • Console 탭
      에러 메시지나 JavaScript에서 출력한 console.log 결과를 보여줘요. 화면이 깨진 이유가 스타일이 아니라 자바스크립트 에러일 수도 있어서 같이 보는 편이 좋아요.

      JS 문법을 몰라도 괜찮아요. AI에게 현재 상황과, 문제의 원인을 추적할 수 있는 로그를 넣어달라고 하면 로그를 추가해줄 거예요. 콘솔에서 확인한 뒤, 출력 결과를 그대로 복사해서 AI에게 전달하면 돼요. 문제가 해결된 뒤에는 다시 로그를 지워달라고 하세요.

    • React Developer Tools
      React로 만든 앱이라면 컴포넌트 트리와 props를 볼 수 있어요. “이 화면 조각이 어떤 컴포넌트에서 나왔는지”를 찾을 때 도움이 돼요.

    수정 루프를 돌 때는 이렇게 보면 좋아요

    수정 루프는 보통 이렇게 돌면 돼요.

    1. 어디가 어긋났는지 화면에서 찾기
2. 개발자 도구로 실제 값 확인하기
3. 공통 컴포넌트 문제인지, 페이지 조립 문제인지 구분하기
4. 수정 범위를 한 파일 또는 한 컴포넌트 단위로 좁히기
5. 유지할 것 / 고칠 것을 같이 적어서 AI에게 다시 요청하기
6. 다시 브라우저에서 확인하기

    예를 들어 카드 너비가 비정상적으로 길어지는 상황이라면 이렇게 볼 수 있어요.

    • 개발자 도구로 카드 요소의 실제 width 확인
    • /blog 페이지의 grid 설정(grid-template-columns, minmax 등) 확인
    • Card.tsx에 max-width나 width 제약이 있는지 확인
    • grid 열 수는 맞는데 카드만 넓어지는지, grid 자체가 한 열로 넓게 잡혀 있는지 구분

    그리고 AI에게는 이렇게 요청할 수 있어요.

    문제
- /blog 페이지에서 카드 너비가 넓은 화면에서 비정상적으로 길게 늘어나요

유지할 것
- Card 내부 구조는 유지
- desktop 3열 / tablet 2열 / mobile 1열 grid는 유지
- gap 16px은 유지

고칠 것
- 카드 최대 너비를 제한하거나, grid 열이 균등하게 나누어지도록 수정해 주세요

    정리하면, 폴더 구조로 어디 파일을 열지 먼저 정하고, 개발자 도구로 지금 화면에 적용된 실제 값을 확인한 다음, 그 문제가 공통 컴포넌트 문제인지 / 특정 페이지 배치 문제인지를 구분해서 수정하면 돼요.

    그러면 AI에게도 훨씬 정확하게 “무엇은 유지하고, 무엇만 바꿔야 하는지”를 말할 수 있어요.