"버튼 눌렀는데 저장이 안 됐어요. 로그인했는데 페이지 넘어가면 로그아웃돼요. 좋아요 눌렀는데 새로고침하면 사라져요. 어디서 뭐가 잘못된 건지 모르겠어요."
맞아요. 기능은 만들었는데 제대로 작동하지 않는 거예요.
근데 왜 이런 일이 생길까요?
대부분 데이터 흐름을 몰라서 그래요. 사용자가 버튼 누르면 어떤 순서로 뭐가 일어나는지, 데이터가 어디서 어디로 가는지 모르니까 "왜 안 돼?" 상태에 빠져요.
데이터 흐름을 알면 "어디서 끊겼는지"를 파악할 수 있어요. 그러면 AI한테 "여기 확인해봐"라고 정확히 지시할 수 있죠.
오늘은 사용자 행동부터 DB 저장까지, 데이터가 어떻게 흐르는지 배워볼게요.
이 글을 읽고 나면
- 사용자 행동부터 DB 저장까지 데이터 흐름을 이해할 수 있어요
- "왜 안 돼?"를 "여기가 문제구나"로 바꿀 수 있어요
- AI한테 "이 단계 확인해봐"라고 정확히 요청할 수 있어요
데이터 흐름이란?
데이터 흐름은 사용자가 뭔가 했을 때 (버튼 클릭, 입력, 로그인 등) 데이터가 프로그램 안에서 어떤 순서로 어디를 거쳐가는지를 말해요.
가장 기본적인 데이터 흐름
14편에서 프론트엔드(웹 브라우저, 앱)와 백엔드(서버)를 배웠죠?
데이터는 이 둘 사이를 왔다 갔다 해요.
핵심:
- 프론트엔드(웹 브라우저, 앱)는 DB에 직접 접근하지 않아요
- 반드시 API를 통해서 백엔드(서버)와 대화해요
- 백엔드만 DB에 접근할 수 있어요
데이터 흐름의 3가지 패턴
실제로는 데이터 흐름이 3가지 패턴이 있어요.
패턴 1: 저장 (Create)
사용자가 뭔가 새로 만들 때.
예시: 게시글 작성
1. 사용자: 게시글 입력 후 "저장" 버튼 클릭
↓
2. 프론트엔드: 입력한 내용 수집
"제목: 바이브 코딩 후기, 내용: 너무 좋아요"
↓
3. API 호출: POST /api/posts
"백엔드야, 이 내용으로 게시글 저장해줘"
↓
4. 백엔드: DB에 INSERT
"posts 테이블에 새 행 추가했어"
↓
5. 응답: { id: 123, title: "바이브 코딩 후기", ... }
↓
6. 프론트엔드: "저장 완료!" 메시지 + 목록 페이지로 이동
패턴 2: 조회 (Read)
사용자가 뭔가 보려고 할 때.
예시: 게시글 목록 보기
1. 사용자: 게시판 페이지 방문
↓
2. 프론트엔드: 페이지 로딩되면서 데이터 요청
"게시글 목록 가져와야지"
↓
3. API 호출: GET /api/posts
"백엔드야, 게시글 목록 줘"
↓
4. 백엔드: DB에서 SELECT
"posts 테이블에서 최근 10개 가져왔어"
↓
5. 응답: [ { id: 123, title: "...", ... }, ... ]
↓
6. 프론트엔드: 받은 데이터로 화면에 목록 표시
패턴 3: 변경 (Update / Delete)
사용자가 뭔가 수정하거나 삭제할 때.
예시: 좋아요 누르기
1. 사용자: "좋아요" 버튼 클릭
↓
2. 프론트엔드: 이벤트 감지
"게시글 id: 123에 좋아요 눌렀네"
↓
3. API 호출: PATCH /api/posts/123/like
"백엔드야, 게시글 123번 좋아요 +1 해줘"
↓
4. 백엔드: DB에서 UPDATE
"posts 테이블의 id 123 행, likes 컬럼 +1 했어"
↓
5. 응답: { likes: 25 }
↓
6. 프론트엔드: 화면에 좋아요 개수 25로 업데이트
어디서 끊기는지 파악하는 법
"왜 안 돼?"가 아니라 **"어디서 끊겼지?"**를 생각해야 해요.
핵심: 단계별로 확인하면 어디가 문제인지 알 수 있어요.
AI한테 이렇게 요청하세요
데이터 흐름을 알면 AI한테 어디를 확인해달라고 정확히 말할 수 있어요.
❌ 나쁜 예 (막연하게)
나: "저장이 안 돼요"
→ AI가 뭘 확인해야 할지 몰라요.
✅ 좋은 예 (단계별로 확인 요청)
나: "게시글 저장 버튼 눌렀는데 DB에 안 들어가.
네트워크 탭 보니까 API 호출은 됐어.
백엔드에서 DB 저장하는 부분 확인해봐."
→ AI가 정확히 어디를 봐야 할지 알아요.
❌ 나쁜 예 (뭉뚱그려서)
나: "좋아요 기능 고쳐줘"
✅ 좋은 예 (흐름 단계 지정)
나: "좋아요 버튼은 잘 눌리는데 새로고침하면 사라져.
프론트엔드에서 화면 업데이트는 되는데
백엔드로 API 호출이 안 가는 것 같아.
프론트엔드에서 좋아요 클릭 시 API 호출하는 부분 확인해봐."
실제 대화 예시
AI랑 데이터 흐름 문제를 해결할 때 이렇게 대화해요.
┌────────────────────────────────────────────────────────────────┐ │ 상황: 할 일 추가했는데 화면에 안 나타남 │ ├────────────────────────────────────────────────────────────────┤ │ │ │ 나: "할 일 추가 버튼 눌렀는데 화면에 안 나타나." │ │ │ │ AI: "데이터 흐름 확인해볼까요? │ │ 1. 버튼 클릭 이벤트는 작동하나요? │ │ 2. API 호출은 됐나요? │ │ 3. 응답은 왔나요?" │ │ │ │ 나: "브라우저 개발자 도구 열어서... 네트워크 탭 보니까 │ │ POST /api/todos 요청이 200 OK로 왔어." │ │ │ │ AI: "응답까지 잘 왔네요. 그럼 화면 업데이트 문제예요. │ │ 프론트엔드에서 할 일 목록 state를 업데이트하는 부분 │ │ 확인해볼게요." │ │ │ │ [AI가 코드 확인] │ │ │ │ AI: "아, 문제 찾았어요. │ │ API 호출 후에 할 일 목록을 다시 가져오는 코드가 없네요. │ │ 추가할게요." │ │ │ │ 나: "추가하고 확인해봐." │ │ │ │ [기능 확인] │ │ - 할 일 추가 버튼 클릭 → 화면에 바로 나타남 ✅ │ │ │ │ 💡 이 과정에서 뭐가 중요했나요? │ │ "안 돼요"가 아니라 │ │ "API 호출은 됐는데 화면 업데이트가 안 돼" │ │ → 정확한 단계를 짚어줬어요 │ │ │ └────────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────────┐ │ 상황: 로그인했는데 페이지 이동하면 로그아웃됨 │ ├────────────────────────────────────────────────────────────────┤ │ │ │ 나: "로그인했는데 다른 페이지 가면 로그아웃돼." │ │ │ │ AI: "로그인 상태가 어디에 저장되나요? │ │ 1. 메모리(state)만? │ │ 2. localStorage? │ │ 3. 백엔드 세션?" │ │ │ │ 나: "모르겠는데? 확인해봐." │ │ │ │ AI: "코드 확인해보니 useState로만 관리하고 있네요. │ │ 페이지 이동하면 메모리가 초기화돼서 로그아웃되는 거예요." │ │ │ │ 나: "그럼 어떻게 해야 해?" │ │ │ │ AI: "Supabase Auth를 쓰고 있으니 │ │ onAuthStateChange로 로그인 상태를 감지하게 할게요. │ │ 그러면 페이지 이동해도 로그인 상태가 유지돼요." │ │ │ │ 나: "그렇게 해줘." │ │ │ │ [기능 확인] │ │ - 로그인 → 다른 페이지 이동 → 로그인 상태 유지 ✅ │ │ │ │ 💡 11편에서 배운 "데이터는 어디에 저장되나"가 여기서 나와요 │ │ 메모리(state) vs localStorage vs 백엔드 세션 │ │ → 어디에 저장하느냐에 따라 동작이 달라져요 │ │ │ └────────────────────────────────────────────────────────────────┘
크롬 개발자 도구로 직접 확인하기
⚠️ 이게 제일 중요해요: AI한테 만들라고만 하지 말고, 직접 확인하세요.
데이터 흐름을 이해했으면, 각 단계마다 직접 눈으로 확인해야 해요. AI가 "됐어요"라고 해도 진짜 됐는지는 여러분이 확인해야 해요.
크롬 개발자 도구가 여러분의 눈이에요.
Network 탭: API 호출 확인
API가 제대로 호출됐는지 확인하는 곳이에요.
Console 탭: 로그와 에러 확인
코드에서 뭐가 일어나고 있는지 보는 곳이에요.
왜 직접 확인해야 하나요?
데이터 흐름 디버깅 체크리스트
문제 생겼을 때 이 순서대로 확인하세요.
□ 1. 버튼/이벤트 작동하나?
→ console.log("버튼 클릭됨")으로 확인
□ 2. API 호출 가나?
→ 브라우저 개발자 도구 > Network 탭 확인
□ 3. 요청 데이터 제대로 보내나?
→ Network 탭 > Payload 확인
□ 4. 백엔드 에러 없나?
→ 응답 Status Code 확인 (200 OK? 500 Error?)
□ 5. DB에 저장됐나?
→ Supabase 대시보드에서 테이블 직접 확인
□ 6. 응답 데이터 제대로 왔나?
→ Network 탭 > Response 확인
□ 7. 화면 업데이트 됐나?
→ React DevTools로 state 확인
이 순서대로 확인하면 어디가 문제인지 찾을 수 있어요.
주의사항: 한 번에 여러 단계를 건너뛰지 마세요
⚠️ AI한테 이렇게 요청하면 안 돼요
나: "로그인부터 게시글 작성, 수정, 삭제까지 전부 만들어줘"
이렇게 하면:
- 어디서 뭐가 잘못됐는지 파악 불가
- 한 곳이 꼬이면 전체가 꼬임
- 고치려고 해도 어디부터 봐야 할지 모름
✅ 이렇게 단계별로 하세요
1단계: 로그인 화면만 만들기
→ 확인: 로그인 폼 잘 나오나?
2단계: 로그인 API 연결
→ 확인: 아이디/비번 입력하고 로그인 되나?
3단계: 로그인 상태 유지
→ 확인: 페이지 이동해도 로그인 유지되나?
4단계: 게시글 작성 화면
→ 확인: 입력 폼 잘 나오나?
5단계: 게시글 저장 API 연결
→ 확인: 게시글 저장되고 목록에 나타나나?
한 입 크기로 나눠서, 하나씩 확인하면서 가야 해요.
PART 3 마무리: 큰 그림을 배웠어요
오늘로 PART 3: 기술 개념 - 큰 그림이 끝났어요.
PART 3에서 배운 것:
10편: 프로그램의 종류
→ 웹앱, 모바일 앱, 자동화 스크립트 등
11편: 프론트엔드 vs 백엔드
→ 사용자가 보는 화면 vs 보이지 않는 로직
12편: 데이터는 어디에 저장되나
→ 메모리, localStorage, DB
13편: API
→ 프론트엔드와 백엔드가 대화하는 통로
14편: 프로젝트 구조
→ 파일을 역할별로 나눠서 정리
15편: 데이터 흐름 (오늘!)
→ 사용자 행동 → API → 백엔드 → DB → 화면 반영
이제 프로그램이 어떻게 돌아가는지 큰 그림을 알게 됐어요.
다음 PART 4에서는 설계 개념을 배워요. "이 패턴으로 해줘", "이 구조로 가자"처럼 AI한테 기술적으로 지시하는 수준으로 올라가요.
오늘의 핵심 정리
셀프체크
이 글을 이해했다면 아래 질문에 답할 수 있어요:
□ 사용자가 좋아요 버튼을 눌렀을 때, 데이터가 거쳐가는 순서는? □ "게시글 저장했는데 화면에 안 나타나요" → 어디부터 확인해야 하나요? □ 프론트엔드(웹 브라우저, 앱)가 DB에 직접 접근할 수 있나요?
(정답: 버튼 클릭 → 프론트엔드 → API → 백엔드 → DB / API 호출 여부와 응답 확인 / 아니요 - 반드시 API를 통해서)
다음 글 예고
PART 3에서 큰 그림을 배웠어요. 프로그램 종류, 프론트/백엔드, 데이터 저장소, API, 프로젝트 구조, 데이터 흐름까지.
이제 "프로그램이 어떻게 돌아가는지" 알게 됐죠.
근데 여기서 멈추는 사람이 많아요. "돌아가긴 하는데... 더 좋은 방법은 없을까?"
다음 PART 4에서는 설계 개념을 배워요.
16편: 자료구조 개념
- "데이터를 어떻게 정리할까?"
- 리스트, 트리, 객체... AI한테 "이 구조로 관리해줘"라고 말하는 법
- "할 일 목록은 배열로, 카테고리는 트리로 관리해줘"
설계 개념을 알면 AI한테 **"이 패턴으로 해줘"**를 말할 수 있어요. 그러면 AI가 더 좋은 구조로 만들어줘요.
이 시리즈 로드맵
PART 3: 기술 개념 - 큰 그림
[ 10편 ] 프로그램의 종류 ✅
↓
[ 11편 ] 프론트엔드 vs 백엔드 ✅
↓
[ 12편 ] 데이터는 어디에 저장되나 ✅
↓
[ 13편 ] 서비스들이 대화하는 방법: API ✅
↓
[ 14편 ] 프로젝트 구조 ✅
↓
[ 15편 ] 데이터 흐름 (지금 여기!)
↓
PART 4: 기술 개념 - 설계
↓
[ 16편 ] 자료구조 개념
↓
...
궁금한 점이나 다뤘으면 하는 주제가 있으면 댓글로 남겨주세요!