[31기 3차 세미나] 연동 세미나 : REST API부터 React 화면 렌더링까지

 

어느덧 솔룩스 31기 세미나도 3주차에 접어들었습니다!
지난 6월 29일(월)부터 7월 5일(일)까지 진행된 3차 세미나에서는,
[연동 세미나 - REST API부터 React 화면 렌더링까지]를 다루었습니다.

 

이번 세미나에서는 어떤 내용을 배우고 실습했는지 함께 확인해볼까요?

 

 

 

주제

---

 

기간

 

6 / 29 (월) ~ 7 / 5 (일)

 

---

 

세미나 소개

 

송하은 멘토님께서 진행해 주신 이번 세미나에서는
API 명세서를 보고, 화면에 필요한 데이터 및 API를 안정적으로 연결하는 방법을 학습해보았습니다.

이번에는 실제로 프론트엔드와 백엔드가 어떻게 데이터를 주고받고,
그 데이터가 React 화면까지 이어지는지 전체 흐름을 따라가보는 시간이었습니다.

 

 

내용

---

1. 프론트엔드와 백엔드의 연동 과정

 

* 왜 API 연동이 어렵게 느껴질까?

 

API 연동이 낯설게 느껴지는 이유는 문제 발생 시 원인을 체계적으로 정리하며 접근하는 훈련이 부족하기 때문입니다.

주소를 잘못 보냈는지, 응답 형식과 실제 데이터 구조가 다른지, undefined나 CORS 에러가 어느 단계에서 발생했는지, 필요한 데이터가 props로 제대로 전달되지 않았는지, 흐름을 하나씩 짚어보는 습관이 중요합니다.

 

 

* 프론트엔드와 백엔드, 각자의 역할

 

프론트엔드는 사용자가 접하는 화면을, 백엔드는 데이터 저장과 관리를 담당합니다.

두 영역은 API라는 약속을 통해 데이터를 주고받는데, 서로의 코드를 공유하지 않고도
API라는 인터페이스만으로 데이터를 주고받을 수 있다는 점이 핵심입니다.

 

 

---

 

2. REST API 읽는 법과 기본 구조 

 

* REST API는 무엇을 읽는 것일까?

 

REST API는 HTTP Method와 URL로 표현되는 '요청의 목적'을 읽어내는 것에서 시작합니다.

Method를 먼저 확인해 요청의 목적(조회 / 생성 / 전체 수정 / 부분 수정 / 삭제)을 파악하고,
URL을 통해 리소스와 조건을 구분하는 순서로 접근하면 훨씬 수월하게 API 명세서를 읽어낼 수 있습니다.

 

 

* 요청값은 어디에 넣을까?

 

서버에 데이터를 보내는 방법에는 Path Variable, Query Params, Body 세 가지가 있습니다.

특정 데이터를 지정할 땐 Path Variable을, 검색·필터·정렬 조건을 지정할 땐 Query Params를,
생성·수정에 필요한 데이터를 실을 땐 Body를 사용한다는 차이를 이해하는 것이 중요합니다.

 

---

 

3. API 명세서 읽기와 필수 작성 요소

 

* API 명세서는 무엇을 위한 문서일까?

 

API 명세서는 프론트엔드와 백엔드가 서로 다르게 이해하고 있던 부분을 줄여주는,
협업의 기준이 되는 문서입니다.

주소(URL), 요청/응답 구조, 데이터 타입, 에러 코드까지 함께 확인해야
실제 연동 시 발생하는 불일치를 줄일 수 있습니다.

 

 

* 에러와 상태 코드 읽기

 

응답이 실패했다면, 화면에 어떤 메시지와 상태 코드를 함께 안내할지도 정해두어야 합니다.

200/201 성공, 400/401/403/404/500 등 상태 코드별 의미를 정리해두면

에러 상황에서도 당황하지 않고 원인을 좁혀갈 수 있습니다.

 

 

---

 

4. JSON 데이터가 React 화면에 나오기까지

 

* JSON 데이터로 화면 렌더링하기

 

JSON 데이터가 화면에 나타나기까지는

① 응답 구조 확인 및 저장 → ② 화면 속 State 반영 → ③ props 전달, 총 세 단계를 거칩니다.

response.data 전체가 항상 배열은 아니라는 점, 실제로 배열이 담긴 위치(예: response.data.products)를
|정확히 확인하는 습관이 중요하게 강조되었습니다.

 

 

* State에서 Props로 전달하기

 

상위 컴포넌트가 데이터를 관리하고,
하위 컴포넌트는 이를 화면에 그려주는 역할을 분리해서 설계합니다.

 

이 과정에서 Props Drilling을 주의해야 하며, 데이터를 내려주는 단계가 많아진다면
Context, Zustand, React Query 같은 확장 도구도 고려해볼 수 있다는 팁도 함께 다뤄졌습니다.

 

 

---

 

5. CORS와 협업 시 확인할 사항

 

* CORS는 무엇일까?

 

CORS는 다른 출처의 요청을 제한하는 브라우저 보안 정책으로,
Origin(Protocol + Domain + Port) 중 하나라도 다르면 다른 출처로 판단됩니다.

같은 localhost라도 포트가 다르면(예: React 5173, 백엔드 8000)
다른 출처로 인식되어 CORS 에러가 발생할 수 있다는 점을 확인했습니다.

 

 

 

연동 중 에러가 발생하면 프론트엔드만의 문제도, 백엔드만의 문제도 아닌 경우가 많습니다.

 

주소 URL, 요청/응답 구조, 상태 코드, 에러 코드까지
API 명세서를 기준으로 함께 짚어나가야 한다는 점이 이번 세미나의 핵심 메시지였습니다.

 

 

 

과제

---

* Recipe API 연동하기

- 사용자의 행동을 HTTP 요청으로 바꾸고, 서버 응답을 화면 상태로 연결
- 상품 API 실습에서 익힌 흐름을 레시피 서비스에 그대로 확장하는 과제 수행

 

 

이번 과제는 버튼·폼 제출 → 알맞은 HTTP Method 선택 → state 갱신 및 화면 반영까지,

한 사이클을 스스로 완성해보는 데 초점을 맞췄습니다.

 

제출 자료는 실행 화면 캡처와 전체 코드이며,

각 기능을 롤별로 나누어 하나씩 검증한 뒤 제출하는 것이 주의사항으로 안내되었습니다.

 

 

 

마무리

---

이번 세미나를 통해 API 명세서를 읽는 법부터, JSON 데이터가 React 화면까지 이어지는 흐름,
그리고 CORS 등 협업 시 반드시 확인해야 할 사항까지

 

현업에서 자주 마주치는 연동 과정을 미리 경험해볼 수 있었던 유익한 시간이 되셨을 거라고 생각합니다.

 

이번 경험을 바탕으로 실제 프로젝트에서 API를 연동할 때도 한결 수월하게 진행하실 수 있을 거예요! 😊

다음 세미나에도 많은 관심 부탁드립니다.