Day 8 — 프론트-백 첫 연동 + Block 1 점검 🚩

오늘의 목표

  1. 화면과 서버를 실제로 연결한다 (가짜 → 진짜 데이터)
  2. 자주 막히는 연동 문제(CORS 등)를 이해한다
  3. Block 1(1~4주)을 회고하고 다음 단계를 점검한다

준비물: 동작하는 화면 뼈대 + CRUD API

이 회차는 첫 스프린트의 마무리이자 첫 멘토링입니다.


0. 복습 — 우리가 만든 두 반쪽

  • 프론트(Day 6): 화면은 있지만 데이터가 가짜
  • 백엔드(Day 7): 진짜 데이터는 있지만 화면이 없음

오늘 이 둘을 잇습니다. 풀스택이 처음으로 "하나로" 동작하는 날입니다.


1. 연동의 원리 — 화면이 서버를 부른다

프론트-백 연동: 프론트가 fetch로 백엔드를 호출하고 백엔드가 DB와 주고받는다

화면(프론트)에서 서버로 요청을 보내고, 받은 데이터를 화면에 그립니다.

[화면 시작]
   │  "할 일 목록을 보여줘야 하는데..."
   ▼
GET /todos 요청 전송  ──────────►  [서버] DB 조회
   │                                  │
   │  ◄─────── 데이터 응답 ────────────┘
   ▼
받은 데이터로 화면 그리기
   │  가짜 데이터 삭제 → 진짜 데이터로 교체!
   ▼
[완성된 목록 표시]

가짜 → 진짜 교체

Day 6에서 화면에 박아둔 가짜 데이터를, API 호출로 바꿉니다.

// Before: 가짜 데이터
const todos = [{ id: 1, title: "예시" }];

// After: 진짜 데이터 (서버에서)
const [todos, setTodos] = useState([]);
useEffect(() => {
  fetch('http://localhost:____/todos')
    .then(res => res.json())
    .then(data => setTodos(data));
}, []);

💡 이 코드도 AI에게 시킵니다: "이 화면의 가짜 데이터를 GET /todos API에서 받아오도록 바꿔줘."


2. 자주 막히는 지점 — 미리 알아두기

연동할 때 거의 모두가 겪는 문제들입니다. 미리 알면 안 당황합니다.

① CORS 에러

Access to fetch ... has been blocked by CORS policy

CORS = 서버가 "이 화면에서 오는 요청을 허락"해야 통신이 됨

브라우저 보안 정책입니다. 서버에서 "내 프론트 주소는 허용"이라고 설정하면 해결됩니다. → AI에게: "백엔드에 CORS 설정을 추가해서 프론트(localhost:____)의 요청을 허용해줘."

② 주소/필드명 불일치

  • 프론트는 /api/todos로 부르는데 서버는 /todos
  • 프론트는 name을 기대하는데 서버는 title을 줌

💡 그래서 지난 숙제가 "주소·필드명 대조"였습니다. Day 3 API 명세를 하나의 기준으로 삼아 양쪽을 맞추세요.

③ 비동기 타이밍

데이터가 도착하기 전에 화면을 그리려다 에러. (Cannot read property 'map' of undefined) → "데이터 로딩 중일 때는 '불러오는 중...'을 보여주도록 처리해줘."


3. 실습 — 연동 완성하기

핵심 기능 하나를 끝까지(조회 → 생성) 연결해봅니다.

🛠 실습 순서

1. 두 서버를 동시에 실행 (백엔드 + 프론트)

2. 목록 조회(GET) 연동
   "메인 화면의 가짜 목록을 GET /todos에서 받아오게 바꿔줘.
   로딩 중 표시도 추가해줘."
   → 화면에 진짜 데이터가 뜨면 성공!

3. 생성(POST) 연동
   "추가 버튼을 누르면 POST /todos로 새 할 일을 만들고,
   목록을 새로고침하도록 연결해줘."
   → 추가한 게 바로 목록에 나타나면 성공!

4. CORS 등 에러가 나면 → 위 2번 참고해서 해결

5. 동작하면 commit & push 🎉

🎯 오늘의 성공 기준: 화면에서 할 일을 추가하면 → DB에 저장되고 → 새로고침해도 남아있다. 이게 되면 여러분은 풀스택 앱을 만든 겁니다!


4. Block 1 회고 — 첫 스프린트 돌아보기 🚩

4주(8회)를 달려왔습니다. 멘토와 함께 점검하세요.

회고 템플릿 (KPT)

## Keep (잘된 것, 계속할 것)
- 
- 

## Problem (어려웠던 것, 문제)
- 
- 

## Try (다음에 시도할 것)
- 
- 

진도 점검 체크리스트

  • 명세서 / ERD / API 명세가 docs/에 정리돼 있다
  • GitHub에 코드가 꾸준히 커밋돼 있다
  • 핵심 기능 1개가 프론트-백 연동까지 동작한다
  • 바이브코딩으로 코드를 만들고 검토할 수 있다

멘토와 이야기할 것

- 내 프로젝트 범위가 4개월에 적절한가? (너무 크면 지금 줄이기!)
- 핵심 기능 3개가 여전히 맞는가?
- 막히는 부분은 어디인가?
- 다음 스프린트(5~6주) 목표는?

💡 범위 조절은 지금이 최적기입니다. 너무 크다 싶으면 멘토와 상의해 과감히 줄이세요. 작게 완성하는 게 크게 미완성보다 100배 낫습니다.


5. 오늘의 체크리스트

  • 프론트가 서버를 호출해 데이터를 받는 흐름을 이해했다
  • CORS·필드 불일치 등 흔한 문제와 해결법을 안다
  • 화면에서 추가한 데이터가 DB에 저장되고 유지된다 ← 가장 중요!
  • KPT 회고를 작성했다
  • 멘토와 프로젝트 범위·다음 목표를 점검했다

6. 다음 시간 예고 — Block 2 시작!

Day 9 — 인증 기능 ①: 회원가입/로그인

  • 본격적인 핵심 기능 개발 블록(5~8주)에 들어갑니다
  • 사용자 인증 / 비밀번호 암호화 / JWT·세션
  • 준비물: 연동까지 완성된 내 프로젝트

📌 숙제: KPT 회고에서 나온 "Try" 항목을 다음 스프린트 계획에 반영해 오세요.


축하합니다. 오늘부로 여러분은 "동작하는 풀스택 웹앱"을 가졌습니다. 이제 살을 붙일 차례입니다. 🎊