웹 서비스 만들기

02이 차시를 마치면

• 1.HTML·CSS·JS가 각각 어떤 역할을 맡는지 자신의 말로 설명할 수 있다.
• 2.07차시에서 만든 PRD와 화면 흐름도를 기준으로 오늘 만들 화면 단위를 정할 수 있다.
• 3.화면을 재사용 가능한 컴포넌트 단위로 나눠 AI에게 요청할 수 있다.
• 4.화면 크기(모바일·데스크톱)에 따라 자연스럽게 재배치되는 반응형 화면을 만들 수 있다.
• 5.입력 폼에 유효성 검사를 붙여 잘못된 입력을 걸러낼 수 있다.

03왜 필요한가

07차시에서 아이디어를 PRD 한 페이지와 화면 흐름도로 정리했다고 해보자. 문서로는 완벽해 보이지만, 그 상태 그대로는 누구에게도 보여줄 수 없다. 화면 흐름도의 네모 칸 하나하나가 실제로 브라우저에서 열리고, 버튼을 누르면 반응하고, 입력한 값이 확인되는 화면으로 바뀌어야 비로소 '만들었다'고 말할 수 있다. 이번 차시는 그 첫 번째 화면들을 실제로 띄우는 시간이다.

• ·PRD와 화면 흐름도가 아무리 정교해도 그 자체로는 아무도 눌러볼 수 없다.
• ·화면 전체를 한 번에 요청하면 AI 응답이 뒤섞여, 나중에 버튼 하나만 고치고 싶어도 어디를 건드려야 할지 알 수 없다.
• ·모바일 화면을 고려하지 않고 만들면, 정작 링크를 공유했을 때 스마트폰에서 화면이 깨져 첫인상을 망친다.
• ·입력 폼에 유효성 검사가 없으면 빈 값이나 형식이 다른 값이 그대로 들어가고, 다음 차시에서 데이터베이스에 저장할 때 문제가 그대로 쌓인다.

04개념 설명

05실습 가이드

1. 1. 07차시 산출물 다시 꺼내기

   • -07차시에서 저장한 PRD와 화면 흐름도 문서를 다시 연다.
   • -화면 흐름도에 그려둔 화면들 중, 오늘 실제로 만들 화면 2~3개를 고른다. 보통 '첫 화면(홈 또는 목록)'과 '입력 화면(폼)'을 우선순위로 잡으면 이후 실습이 자연스럽게 이어진다.
   • -고른 화면마다 그 화면에서 사용자가 할 수 있어야 하는 동작을 한 문장씩 적어둔다(예: '신청서를 작성해 제출한다').

   예상 결과 — 오늘 만들 화면 2~3개와, 각 화면의 핵심 동작이 한 줄씩 정리되어 있다.

   안 될 때 — 07차시 산출물이 아직 부실하다면 지금이라도 화면 흐름도를 러프하게 그려본다. 완벽한 문서가 없어도 '어떤 화면이 필요한가'만 정해지면 이번 차시를 진행할 수 있다.

2. 2. 화면을 컴포넌트 단위로 쪼개기

   • -P8-1 프롬프트로 방금 정한 화면을 어떤 컴포넌트로 나눌지 AI에게 물어본다.
   • -AI가 제안한 컴포넌트 목록(헤더, 카드, 폼, 버튼 등)을 훑어보고, 내 서비스에 맞게 이름과 개수를 조정한다.

   예상 결과 — 화면별로 3~6개 정도의 컴포넌트 목록이 정리된다.

   안 될 때 — 컴포넌트가 지나치게 잘게 쪼개져 있으면(예: 글자 한 줄까지 컴포넌트로 분리) '너무 잘게 나뉘었으니 묶어달라'고 다시 요청한다.

3. 3. 첫 화면 골격 만들기

   • -P8-2 프롬프트로 첫 화면(홈 또는 목록)의 HTML/CSS 골격을 요청한다.
   • -AI가 준 코드를 프로젝트 폴더에 저장하고, 브라우저에서 열어(또는 로컬 서버 실행) 화면이 실제로 보이는지 확인한다.

   예상 결과 — 브라우저에 화면 흐름도에서 그렸던 모양과 비슷한 화면이 뜬다.

   안 될 때 — 화면이 하얗게 비어 있으면 파일 저장 위치가 잘못됐거나 파일명이 코드가 참조하는 이름과 다른 경우가 많다. AI에게 어느 폴더에 어떤 이름으로 저장해야 하는지 다시 확인한다.

4. 4. 반응형 점검하기

   • -브라우저 창 너비를 손으로 줄여보거나, 개발자 도구의 모바일 화면 보기 기능을 켜서 확인한다.
   • -레이아웃이 깨지는 부분(글자가 화면 밖으로 나가거나 버튼이 겹치는 곳)을 찾는다.
   • -깨지는 부분이 있으면 P8-3 프롬프트로 반응형 처리를 요청한다.

   예상 결과 — 화면 너비를 스마트폰 크기까지 줄여도 내용이 잘리거나 겹치지 않는다.

   안 될 때 — 여전히 깨진다면 어느 화면 너비에서 어느 요소가 어떻게 깨지는지 스크린샷과 함께 P8-5(복구 프롬프트)로 구체적으로 설명한다.

5. 5. 입력 폼 화면 만들고 유효성 검사 붙이기

   • -P8-4 프롬프트로 두 번째 화면(입력 폼)의 코드와 유효성 검사를 함께 요청한다.
   • -필수 항목을 비운 채 제출 버튼을 눌러보고, 형식이 틀린 값(예: 이메일 자리에 'abc')을 넣고 제출해본다.
   • -두 경우 모두 안내 메시지가 뜨고 실제로 제출되지 않는지 확인한다.

   예상 결과 — 빈 값이나 잘못된 형식을 넣으면 화면에 안내 문구가 뜨고 제출이 막힌다.

   안 될 때 — 안내 문구 없이 그냥 제출되면 유효성 검사 코드가 폼과 연결되지 않은 것이다. 어떤 항목에 어떤 검사가 필요한지 표로 정리해 다시 요청한다.

6. 6. 6차시 디자인 원칙 적용해 다듬기

   • -P8-6 프롬프트로 6차시에서 정한 색·타이포·여백 원칙을 지금 화면에 적용해달라고 요청한다.
   • -두 화면(목록/폼)에 같은 색과 글꼴이 일관되게 쓰였는지 나란히 놓고 비교한다.

   예상 결과 — 두 화면이 서로 다른 프로젝트처럼 보이지 않고, 같은 서비스의 화면으로 보인다.

   안 될 때 — 색이나 글꼴이 화면마다 다르게 적용됐다면, 공통 스타일을 한 파일로 모아 두 화면이 함께 참조하도록 요청한다.

7. 7. 화면 간 이동 연결하기

   • -목록 화면의 버튼(또는 메뉴)을 눌렀을 때 입력 폼 화면으로 이동하도록 연결을 요청한다.
   • -실제로 버튼을 눌러 화면이 전환되는지 확인한다.

   예상 결과 — 목록 화면에서 버튼을 누르면 입력 폼 화면으로 이동한다.

   안 될 때 — 버튼을 눌러도 반응이 없으면 버튼에 동작(JS)이 연결되지 않은 '가짜 버튼'인 경우가 많다. 이것만은 주의 항목을 참고해 버튼마다 실제 동작이 있는지 확인한다.

8. 8. 전체 점검하고 정리하기

   • -만든 화면 2~3개를 처음부터 순서대로 눌러보며 전체 흐름이 07차시 화면 흐름도와 일치하는지 확인한다.
   • -이번 차시까지 만든 내용을 커밋해 되돌아갈 수 있는 지점을 남긴다.

   예상 결과 — 화면 흐름도에 그렸던 순서대로 화면이 이어지고, 변경 이력이 커밋으로 남아 있다.

   안 될 때 — 흐름이 어긋나면 화면 흐름도와 실제 화면 중 무엇이 맞는지 먼저 정하고, 화면 흐름도를 최신 상태로 갱신해 문서와 실제를 다시 맞춘다.

06실전 프롬프트

[내 서비스 이름]의 [목록 화면]을 만들려고 해.
이 화면에서 사용자는 [등록된 항목을 훑어보고 하나를 눌러 자세히 본다].

이 화면을 재사용 가능한 컴포넌트 단위로 나눠서
목록으로 보여줘. 각 컴포넌트가 화면의 어느 부분을
담당하는지도 한 줄씩 설명해줘.

너무 잘게 쪼개지 말고, 나중에 내가 "이 부분만 고쳐줘"라고
말했을 때 알아들을 수 있는 정도로 나눠줘.

방금 나눈 컴포넌트 구조로 [목록 화면]의
HTML과 CSS 코드를 만들어줘.

· 데이터는 아직 없으니 예시 항목 3~4개로 채워줘
· 파일은 어디에 어떤 이름으로 저장해야 하는지 알려줘
· 저장 후 브라우저에서 어떻게 열어서 확인하는지도 알려줘

나는 코딩을 모르니까 각 단계에서 화면에 무엇이
보여야 정상인지도 같이 알려줘.

지금 만든 [목록 화면]을 스마트폰 화면 너비로 줄이면
[카드가 겹치거나 글자가 화면 밖으로 잘리는] 문제가 있어.

화면 너비가 좁아지면 카드가 세로로 쌓이도록
반응형으로 고쳐줘.

데스크톱 화면에서 보이던 모습은 그대로 유지하면서
좁은 화면에서만 배치가 바뀌게 해줘.

[내 서비스 이름]에 [신청 정보]를 입력받는 폼 화면을 만들어줘.

입력 항목:
· [이름] — 필수, 빈 값 불가
· [이메일] — 필수, 이메일 형식이어야 함
· [신청 사유] — 선택, 최대 200자

각 항목이 조건에 안 맞으면 제출 버튼을 눌러도
제출되지 않고, 무엇이 잘못됐는지 화면에 문구로 보여줘.

방금 만든 화면이 이상하게 나와.

무엇이 이상한지: [예: 스마트폰 크기에서 버튼이 화면 밖으로 잘림 / 버튼을 눌러도 아무 반응 없음]
어떤 화면 크기·상황에서 그런지: [예: 창 너비 400px 이하]
스크린샷 설명(있다면): [화면에 보이는 모습을 그대로 설명]

무엇이 원인인지 먼저 설명하고, 고친 코드를 줘.
같은 문제가 다른 화면에서도 생기지 않으려면
뭘 확인해야 하는지도 알려줘.

지금 만든 [목록 화면]과 [입력 폼 화면]에
6차시에서 정한 디자인 원칙을 적용해줘.

· 메인 색: [정한 색]
· 본문 글꼴 / 제목 글꼴: [정한 글꼴]
· 여백은 넉넉하게, 화면에 정보를 욱여넣지 말 것
· 두 화면에 같은 색과 글꼴이 일관되게 쓰이게 해줘

바꾸기 전에 어떻게 바뀔지 한 문단으로 먼저 설명해줘.

07이것만은 주의

08자가 점검

09과제

07차시에서 만든 자신의 PRD와 화면 흐름도를 기준으로, 오늘 다루지 않은 나머지 화면 중 1개를 추가로 만들어본다. 반응형과 입력 폼이 없는 화면이라면, 최소한 6차시 디자인 원칙을 적용해 기존 화면과 통일감을 맞춘다.

제출 형식 — ① 완성한 화면의 데스크톱·모바일 크기 스크린샷 각 1장 ② 화면 소스가 담긴 저장소(또는 폴더) 링크 ③ 사용한 프롬프트와 AI 응답 요약을 하나의 문서로 정리해 제출한다.

10더 알아보기

• MDN 반응형 디자인 기초 — 미디어 쿼리와 유연한 레이아웃 원리를 더 깊이 볼 때
• 웹 폼 접근성·유효성 검사 가이드 — 표준적인 입력 검사 패턴을 참고할 때

컴포넌트

— 화면을 구성하는 재사용 가능한 단위. 같은 컴포넌트를 여러 화면에서 반복해 쓸 수 있다.

반응형(Responsive)

— 화면 크기에 따라 레이아웃이 자연스럽게 재배치되는 성질.

유효성 검사(Validation)

— 입력값이 기대한 형식과 조건을 만족하는지 확인하는 절차.

다음 차시 예고 — 지금 만든 화면은 새로고침하거나 브라우저를 닫으면 입력한 내용이 그대로 사라진다. 다음 차시에서는 이 화면에 데이터베이스(Supabase)를 연결해, 저장한 데이터가 사라지지 않고 로그인한 사용자를 구분할 수 있는 서비스로 만듭니다.