오늘은 맛집 관리 API를 설계하고, Mock 서버와 프론트엔드를 연동해보는 과제를 진행했다.
이번 과제의 핵심은 단순히 API를 정의하는 것이 아니라,
실제 서비스에서 사용 중인 API를 직접 분석하고 그 구조를 바탕으로 API를 설계 -> Mock 서버로 검증 -> 프론트엔드까지 연결해보는 전체 흐름을 경험하는 것이었다.
강의를 통해 웹 프로젝트의 흐름을 개념적으로 이해했다면,
오늘은 그 개념들을 실제 화면, 요청과 응답, 코드와 실행 결과를 통해 하나씩 연결해본 날이었다.
필수 기능 (1) API 식별하기 – 실제 서비스 API 분석
과제의 첫 단계는 실제 서비스의 API를 직접 확인하는 것이었다.
카카오맵에서 명동교자 본점 상세 페이지에 접속한 뒤,
브라우저 개발자 도구(Network 탭)를 통해 해당 화면을 구성하는 API 요청을 하나씩 살펴봤다.
처음 Network 탭을 열었을 때는 요청이 너무 많아서
이 중에서 어떤 게 진짜 필요한 API인지를 구분하는 것부터 쉽지 않았다.
그래서 무작정 URL만 보지 않고,
Preview와 Response 탭을 번갈아 보면서
화면에 실제로 사용되는 데이터가 무엇인지 비교해가며 확인했다.
그중 장소 상세 정보를 가져오는 요청은 다음과 같은 형태였다.
- Method: GET
- URL:
https://place-api.map.kakao.com/places/panel3/10332413 - Status Code: 200 OK
- Content-Type: application/json
이 API는 Request Body 없이
URL 경로에 포함된 장소 ID를 기준으로 요청을 받고,
장소 이름, 주소, 전화번호, 카테고리, 평점 등의 정보를
JSON 형태로 응답해주고 있었다.
필수 기능 (2) API 명세서 만들기
(등록 / 전체 조회 / 삭제)
실제 서비스 API 구조를 확인한 뒤,
이를 참고해 맛집 관리 기능을 위한 API 명세서를 직접 작성했다.
설계한 API는 다음과 같다.
- POST
/places– 맛집 등록 - GET
/places– 맛집 전체 조회 - DELETE
/places/{id}– 맛집 삭제
각 API에 대해
Method, URL, Request Body, Response Body, Status Code를
하나씩 명세서 형태로 정리했다.
이 과정에서 가장 많이 고민했던 부분은
응답을 어디까지 정의해야 하는가 였다.
특히 DELETE API의 경우,
처음에는 삭제 후 어떤 데이터를 반환해야 하는지 헷갈렸다.
정리해보니,
삭제가 정상적으로 처리되었음을 표현할 때는
204 No Content 상태 코드만으로도 충분하다는 점을 이해하게 됐다.
명세서를 작성하면서
API는 코드보다 먼저 정리되어야 하는 약속이라는 말이
왜 중요한지 조금씩 와닿기 시작했다.
필수 기능 (3) Mock 서버 구축하기
작성한 API 명세서를 바탕으로
Postman을 이용해 Mock 서버를 구축했다.
- Postman Collection 생성
- 각 API 요청에 Example 응답 추가
- Mock 서버 생성
- baseURL 설정
- POST / GET / DELETE 요청 테스트
이 과정에서 가장 많이 막혔던 부분은
Example을 추가하지 않으면 Mock 서버가 응답을 주지 않는다는 점이었다.
처음에는 Mock 서버가 실제 서버처럼
요청을 받으면 알아서 응답해줄 거라고 생각했는데,
Mock 서버는 미리 정의된 요청과 Example 응답이 정확히 일치해야만
응답을 반환한다는 걸 알게 됐다.
또 요청을 보냈는데 계속 404 에러가 발생해서
URL과 Method를 다시 확인해보니,
Collection에 정의한 경로와 실제 요청 경로가
조금이라도 다르면 응답이 오지 않는 경우도 있었다.
이런 시행착오를 겪으면서
Mock 서버는 가짜 서버라기보다
요청과 응답 흐름을 검증하기 위한 도구라는 점을 확실히 이해하게 됐다.
도전 기능 (1) v0로 맛집 관리 프로젝트 프론트엔드 구현하기
도전 과제로 v0를 활용해
Mock 서버와 통신하는 맛집 관리 프론트엔드를 생성했다.
v0로 생성한 프론트엔드를 로컬 환경에서 실행했을 때,
처음부터 정상적으로 동작하지는 않았다.
Tailwind 및 shadcn 관련 설정이
로컬 환경과 맞지 않아 에러가 발생했고,
설정 파일을 하나씩 확인하면서 불필요한 참조를 제거해야 했다.
이 과정을 통해
AI가 생성한 코드라도 그대로 쓰는 게 아니라,
내가 이해하고 실행 환경에 맞게 수정해야 한다는 점을 다시 느꼈다.
도전 기능 (2) 완성된 프론트엔드와 Mock 서버 연동하기
프론트엔드를 실행한 뒤,
Mock 서버의 baseURL을 연결해 실제로 요청이 오가는지 확인했다.
프론트엔드는 다음과 같은 흐름으로 동작하고 있었다.
- 페이지 로드 시
GET /places요청 - 맛집 등록 시
POST /places요청 - 삭제 버튼 클릭 시
DELETE /places/{id}요청
Mock 서버가 미리 정의된 Example 응답을 반환하면,
프론트엔드는 그 응답을 기준으로 화면을 갱신하고 있었다.
이 과정을 통해
프론트엔드는 서버 내부 구현을 전혀 몰라도,
API 명세와 응답만 있으면 개발이 가능하다는 점이 명확해졌다.
실행 중 겪은 문제들
- 화면은 뜨지만 계속 로딩 상태로 멈추는 문제
- Mock 서버 응답이 오지 않아 Network 탭으로 요청을 직접 확인
- Mock 서버는 상태를 기억하지 않아 데이터가 실제로 변경되지 않는 점
여러 번 요청을 보내보고 직접 확인하면서,
Mock 서버와 실제 백엔드 서버의 차이를
개념이 아니라 경험으로 이해하게 됐다.
오늘의 정리
- API는 프론트엔드와 서버를 연결하는 약속이다
- Mock 서버는 협업과 초기 개발을 위한 도구다
- 프론트엔드는 요청을 보내고, 응답을 받아 화면을 그린다
- 백엔드는 데이터를 저장하고 로직을 처리한다
오늘 과제를 통해
실제 서비스 API 분석 → API 설계 → Mock 서버 구축 → 프론트엔드 연동이라는
웹 프로젝트 한 사이클을 처음부터 끝까지 직접 경험해볼 수 있었다.
중간중간 막히는 부분도 많았지만,
그 과정 덕분에
개념으로만 알고 있던 내용들이 실제 흐름으로 연결되기 시작했다.
