API와 JSON 역할 차이

API와 JSON 역할 차이

✅ API와 JSON 역할 차이 표

항목	API	JSON
정의	서버와 클라이언트 간 '데이터 요청 통신'을 위한 규칙/주소	요청/응답 시 실제로 오가는 '데이터 형식'
역할	데이터를 요청하고 받아오는 통로	요청 결과로 내려온 '데이터 본문'(내용물)
예시	[GET/api/products?type=sale] 요청 URL	{"productID":123, "price":499000}
기획자 관점	어떤 데이터를 가져오는지? 언제 호출되는지?	어떤 데이터가 필요 없는지? 얼마나 무거운지?

 

✅ 관계 흐름 요약

[화면진입] -> 프론트에서 API 호출 -> 서버에서 JSON 데이터 응답 -> 화면 렌더링

 

✅ 실무 기준 체크포인트

항목	점검 질문	이슈 발생 시
API 호출 시점	페이지 진입 시 전체 데이터를 다 받나?	초기 로딩이 느림
JSON 응답 크기	상품 1개당 데이터 필드 수? 이미지 크기?	렌더링 속도 저하
중복 호출 여부	스크롤/탭 전환 시 API 재호출이 계속되나?	불필요한 부하
캐시 사용 여부	자주 쓰는 데이터는 메모리 or CDN 캐시 되어 있나?	서버 부하 가중

 

✅ JSON이 크거나 과도한 렌더링의 원인을 파악하는 방법

개발자 도구(F12)에서 아래 내용 확인 가능

보기 항복	보는 이유	JSON 크기 관련성
Network 탭 > Payload / Preview	실제 API 응답(JSON)의 크기 확인	가정 직접적
Performance 탭 > CPU/스크립트 시간	JS가 너무 오래 실행되는지 체크	연관 있음
Memory 탭 > JS Heap Size	데이터가 메모리에 얼마나 올라왔는지	간접 확인 가능
Event Listeners	이벤트 중복이나 누수 확인	JSON 크기와 무관

 

JS Heap Size별 해석

• ~5MB 이하 : 가벼움 (정상)
• 5~20MB : 일반적 수준 (문제 없음, 무겁지 않음)
• 30MB 이상 : 다소 무거움 (성능 저하 유발 가능)
• 50MB~ : 매우 무거운 (적극적 최적화 필요)

30MB 힙이 의미하는 가능성들

• 상품 수 과다 : 가능성 높음(100개 이상일 가능성)
• 불필요한 데이터 유지 : 가능성 높음(리뷰, 혜택, 비노출 필드 포함)
• 비효율적 루프 렌더링 : forEach/map 등으로 전체 상품을 한 번에 렌더
• Lazy Loading 없음 : 스크롤 시에도 추가 JS 객체가 계속 쌓임
• 이벤트 중복 바인딩 : 가능성 X (하지만 이건 Heap보다 Event에서 감지)

 

✅ Lazy Loading이란?

스크롤할 때마다 화면이 보이는 상품만 '지연 로딩'하는 방식

구분	초기 로딩 수 제한	Lazy Loading
목적	첫 로딩 성능 향상	전체 페이지 스크롤 성능 유지
적용 위치	기획전 초기 진입 시	스크롤 되는 모는 리스트
UX 차이	"더보기" UX 가능	자연스러운 무한 로딩UX
구현 난이도	쉬움	중간~높음 (Intersection Observe 필요)

• Lazy Loading 안되는 경우 : 스크롤 이동 기능(앵커, map, 탭)이 전체 상품 로딩을 전제로 동작
• 위 경우의 기획자로서 대응 안 : Lazy 영역에 앵커 위치 pleceholder만 먼저 넣고, 클릭 시 로드

---

프로그래밍 관련된 내용은 스스로 노력하지 않으면 절대 알 수 없다.

개발자가 이런 내용을 하나씩 설명해줄 수 없다. 설명해주더라도 개발자 입장에서 설명해줄 것이라 이해가 쉽지 않다.

 

기획자가 모든 프로그래밍 내용을 알 필요는 없지만 구현할 줄은 몰라도 개념으로는 알 필요가 있다.