[내일배움캠프 Spring_3기] CH1 맛집 관리 API 설계하기

🍽️ 맛집 관리 API 설계 & Mock 서버 연동 과제 회고

오늘은 맛집 관리 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 에러가 발생해
확인해보니,
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 서버 구축 → 프론트엔드 연동이라는
웹 프로젝트 한 사이클을 처음부터 끝까지 직접 경험할 수 있었다.

중간중간 막히는 부분도 많았지만,
그 과정 덕분에
개념으로만 알고 있던 내용들이 실제 흐름으로 연결되기 시작했다.