화면에 보이는 데이터는 전부 서버에서 가져온 것입니다. 그런데 그 과정은 눈에 보이지 않습니다.
Chrome DevTools의 Network 탭은 브라우저가 서버와 주고받는 모든 대화를 실시간으로 보여주는 창입니다. 쉽게 말하면 화면 뒤에서 어떤 일이 벌어지는지 들여다보는 도구입니다.
항상 DevTools 내에 Elements 탭 영역만 업무에 활용했기에 다른 부분은 아직 모든 게 낯설지만, 이번 실습은 코드를 짜는 게 아니라 이미 작동하는 서비스의 구조를 읽는 것이라 따라가 볼 수 있었습니다.
DevTools로 API를 보려고 한 이유
PM 관점에서 API 확인이 업무에 필요한 맥락은 크게 세 가지였습니다.
1. 기획할 때 데이터 구조를 파악하는 용도
“이 화면에 작성자 이름을 추가하고 싶은데 API에 그 값이 이미 있나?”를 직접 확인할 수 있다는 것입니다. 있으면 프론트 작업만 요청하면 되고, 없으면 백엔드까지 건드려야 하는 거라 개발 공수 차이가 크게 난다고 합니다.
2. 경쟁사 분석
“이 서비스는 무한 스크롤을 어떻게 구현했나, 한 번에 몇 개씩 가져오나” 같은 걸 직접 관찰할 수 있습니다.
3. 개발팀과의 기술적 커뮤니케이션의 이해
“API 응답에 이 필드가 없던데요”라고 말할 수 있는 것과 없는 것의 차이가 크다는 것이 공부하면서 점점 체감되고 있습니다.
LinkedIn을 실습 대상으로 고른 것은 자주 방문하는 서비스라 무한 스크롤·피드 로딩 같은 기능을 직접 눈으로 확인하면서 배우기 좋을 것 같아서였습니다.
1단계: DevTools 열기
LinkedIn에 로그인한 상태에서 홈 화면으로 이동합니다. F12 키를 눌러 화면 오른쪽이나 하단에 DevTools 창을 확인합니다.
Elements, Console, Sources, Network 등 탭마다 역할이 다릅니다.
Elements는 화면의 HTML 구조를 보는 탭이고, Console은 에러 메시지나 로그를 확인하는 탭입니다. Sources는 자바스크립트 코드 파일을 보는 탭입니다. 이번 실습에서 사용할 부분은 Network 탭 하나입니다.
Network 탭은 브라우저가 서버와 주고받은 모든 요청과 응답을 기록하는 탭입니다.
페이지를 열거나 스크롤하거나 버튼을 누를 때마다 브라우저는 서버에 무언가를 요청합니다. 그 요청들이 Network 탭에 실시간으로 쌓입니다.
여기서 확인할 수 있는 게 크게 네 가지입니다. 어떤 URL로 요청이 갔는지, 요청 방식이 GET인지 POST인지, 서버가 무엇을 돌려줬는지(Response), 응답이 성공인지 실패인지(Status Code)입니다.
2단계: Network 탭 열기
DevTools 상단에 Elements / Console / Sources / Network 탭이 있습니다. Network 탭을 클릭합니다.
3단계: Fetch/XHR 필터 적용
Network 탭 안에 All / Fetch·XHR / JS / CSS 같은 필터 버튼이 있습니다.
처음엔 All로 두면 요청이 너무 많이 쌓여서 뭘 봐야 할지 몰랐습니다. Fetch/XHR을 클릭하면 API 요청만 걸러져서 훨씬 보기 쉬워집니다. HTML이나 이미지 파일은 제외되고 데이터 요청만 남습니다.
Fetch와 XHR은 둘 다 서버에 데이터를 요청하는 방식인데, 최신 방식이 Fetch, 예전 방식이 XHR이라고 합니다. LinkedIn은 두 가지를 혼합해서 사용한다고 해서 이 필터를 쓰면 한꺼번에 볼 수 있습니다.
4단계: 피드 스크롤해서 요청 발생시키기
필터 적용한 상태에서 LinkedIn 피드를 아래로 스크롤합니다. 스크롤할 때마다 Network 탭 왼쪽 목록에 새로운 요청들이 생겨납니다. voyager/api 또는 feed 같은 키워드가 포함된 항목을 찾습니다.
처음엔 항목이 너무 많아서 어떤 걸 봐야 할지 혼란스러웠습니다. Network 탭 상단 검색창에 feed라고 입력하면 관련 요청만 걸러져서 훨씬 찾기 쉬웠습니다.
요청 목록을 보면 Name 컬럼 맨 왼쪽에 아이콘이 두 종류 보입니다. 처음엔 무슨 차이인지 몰랐는데 찾아보니 역할이 달랐습니다.
1. 문서 모양 (□) : “내가 필요할 때 불러오는 데이터, Fetch/XHR”
- XHR (XMLHttpRequest): 예전부터 쓰이던 전통적인 방식입니다. 이름에 ‘XML’이 들어가지만, 실제로는 JSON 데이터도 아주 잘 나릅니다.
- Fetch: XHR의 단점을 보완해서 나온 최신 방식입니다. 요즘 만들어지는 서비스(링크드인 등)는 대부분 이 Fetch 방식을 사용합니다.
pagination?sduid=...mainFeed 와 같이 특정 시점에 필요한 데이터를 불러오는 요청입니다. 페이지 전체를 새로고침하지 않고, 필요한 데이터만 부분적으로 서버에 요청해서 가져올 때 나타납니다.
“내가 요청할 때만 데이터를 가져오는” Pull 방식의 통신으로, 서버 부하가 적어 효율적인 것이 장점입니다.
예를 들면, 서버에 “사용자가 밑으로 내렸으니까 다음 게시물 데이터 좀 더 줘!”라고 요청하는 겁니다. 페이지 전체를 새로고침하지 않아도 되니까 사용자에게 편리합니다.
또한 사용자가 어떤 동작을 할 때(예: 스크롤, 버튼 클릭) 이 요청이 발생하는지 체크해서 ‘사용자 시나리오’를 검증할 수 있습니다. 기획서에 ‘무한 스크롤’이나 ‘더보기 버튼’을 넣을 때, 뒷단에서는 이런 문서 모양의 요청이 바쁘게 오가겠구나 생각하게 됐습니다.
2. 중괄호 세미콜론 아이콘 {;}: “데이터가 담긴 상자, JSON”
통신 방식이 아니라 서버와 클라이언트가 주고받는 데이터 그 자체(JSON 형식)를 의미합니다. 주로 ‘Fetch/XHR’이나 ‘WebSocket’을 통해 전달되며 피드에 들어갈 글자, 숫자, 이미지 URL 등의 ‘정보 뭉치’가 이 규격에 담겨 전달됩니다.
내용물이 어떻게 생겼는지(이름, 날짜, 본문 등)를 규정하는 형식이라, “어떤 데이터를 주고받을지” 논의할 때 핵심이 됩니다. 그 안에 들어있는 id, name, content 같은 필드들이 기획서에 정의해야 할 ‘데이터 항목’들입니다.
실시간 알림이나 메시지가 올 때도, 그 안에 담긴 실제 내용은 이 ‘주황색 상자’에 담겨서 온다는 걸 알게 되었습니다.
3. 실시간 연결: “항상 열려있는 통로, WebSocket / SSE“
한 번 연결해두면 서버가 발생한 이벤트를 즉시 밀어 넣어 주는 방식입니다.
서버가 나에게 먼저 알려주는 Push 방식의 통신입니다. 문서 모양은 “줘!”라고 해야 주지만, 이건 서버랑 연결 통로를 계속 열어두고 있어서 서버가 “야, 새 소식 있어!” 하고 바로 알려주는 방식입니다.
링크드인에서는 이 부분을 즉시 확인할 수 없었는데, 그 이유는 메시지처럼 ‘특정한 이벤트’가 있을 때만 데이터가 오가기 때문이었습니다. 주식, 코인 거래소는 0.1초마다 시세가 변해야 하므로 WebSocket(Push 방식)을 무조건 사용한다고 해서, 바이낸스(Binance) 사이트로 대체하여 해당 부분을 확인했습니다.
왼쪽 Name 목록에서 stream 또는 market?... 를 선택합니다. 시세 정보가 실시간으로 쏟아지는 통로이며 이걸 클릭하면 초 단위로 데이터가 업데이트되는 ‘진짜 실시간’을 볼 수 있습니다.
항목 하나를 클릭하면 우측에 상세 창이 뜨는데 거기서 Messages라는 탭을 눌러보면 데이터들이 표시됩니다.
- 화살표의 의미: 빨간색 화살표(↓)는 서버가 나에게 보내주는 데이터(Push), 초록색 화살표(↑)는 내가 서버에 보낸 데이터입니다.
- “내가 서버에 보낸 데이터” 의미
- 내 브라우저가 서버와 약속된 규칙에 따라 자동으로 보낸 ‘신호’인 경우를 의미
- ‘사용자가 페이지에 머물고 있음’을 서버에 알리거나, ‘필요한 데이터만 골라서 보내달라고 요청’하는 전략적인 대화
- “내가 서버에 보낸 데이터” 의미
- 내용물 확인: 화살표 옆에 적힌 깨진 글자 같은 것들을 클릭해 보면,
{ "s": "BTCUSDT", "p": "50000.00" ... }같은 JSON({ ; }) 상자들이 쉴 새 없이 도착하는 모습을 확인할 수 있습니다.
일반적인 ‘Fetch/XHR(문서 모양)’은 내가 한 번 요청하면 응답을 주고 끝나는 일회성 관계라면, 지금 보는 ‘WebSocket(Socket)’은 전화기를 계속 붙들고 있는 것과 같습니다.
- Pull(Fetch/XHR): “지금 비트코인 얼마야?” (물어봐야 대답함)
- Push(Socket): (가만히 있어도) “지금은 5천만 원!”, “지금은 5천 10만 원!” (서버가 계속 알려줌)
요약:
- 네트워크 탭의
Socket항목을 클릭하고Messages를 보면, 서버가 나에게 실시간으로 JSON({ ; }) 데이터를 밀어넣어 주는 것을 확인 가능 - WebSocket(Socket)은 전화 통화를 연결하는 것과 같아서, 네트워크 탭을 미리 열어두고 ‘새로고침’을 해야 연결되는 과정을 볼 수 있음
- 연결된 후에는
Messages탭을 봐야 진짜 실시간 데이터를 확인할 수 있음
알림 기능을 기획할 때 무조건 ‘실시간’이 좋다고 생각했는데, 사실은 서버랑 계속 연결되어 있어야 해서 “어떤 방식으로 구현할지” 꼭 논의를 통해서 결정해야 하는 중요한 포인트라는 걸 깨달았습니다.
기획 관점에서 보면, 중요한 것은 ‘사용자에게 데이터가 도달하는 방식’의 결정이라는 것을 체감했습니다.
- Pull 방식: 사용자가 요청할 때만 데이터를 가져오는 방식 (효율적 리소스 관리)
- Push 방식: 서버가 변경사항을 자동으로 알려주는 방식 (실시간성 보장)
실시간 알림 기능을 기획할 때 이 두 가지 통신 방식의 차이를 알고 서버 부하와 사용자 경험 사이에서 어떤 구조로 구현할 것인지 개발자와 논의해야 할 포인트가 된다는 걸 이해했습니다.
이번 실습에서는 문서 모양 아이콘의 pagination?...mainFeed 항목을 클릭합니다.
5단계: 요청 클릭해서 내부 살펴보기
목록에서 항목 하나를 클릭하면 오른쪽에 상세 정보가 펼쳐집니다. 탭이 여러 개 있는데 순서대로 살펴봤습니다.
Headers 탭
요청 방식(GET/POST), URL, Authorization 같은 인증 정보가 담겨 있습니다.
Payload 탭
요청할 때 같이 보낸 파라미터가 있습니다. start=0&count=10 같은 단순한 형태를 예시로 봤는데, 실제 LinkedIn에서 열어보니 구조가 훨씬 복잡했습니다.
Request Payload 안에 paginationRequest라는 항목이 있고, 그 안에 페이지네이션 관련 값들이 들어 있었습니다. 화살표를 눌러 펼쳐야 나옵니다.
start=0&count=10처럼 URL에 바로 붙어서 오는 게 Query String 방식이고, 지금처럼 별도 객체 안에 담겨서 오는 게 Request Payload 방식이라고 합니다. LinkedIn은 더 복잡한 데이터를 주고받아야 해서 Payload 방식을 쓴다는 걸 이때 처음 이해했습니다.
Payload 안에 확인해야 하는 값들이 있었습니다.
retryCount: 1
요청이 실패했을 때 자동으로 재시도하는 횟수입니다. 1이면 실패 시 한 번 더 시도한다는 의미입니다.
기획 관점에서 보면 네트워크가 불안정할 때 사용자가 “왜 안 불러와지지?”라고 느끼기 전에 자동으로 재시도하는 구조입니다. “재시도 몇 번까지 할 건지, 그래도 실패하면 어떤 에러 메시지를 보여줄 건지”가 기획 사항이 된다는 걸 처음 인식했습니다.
trigger: itemDistanceTrigger
스크롤이 특정 지점에 도달했을 때 다음 데이터를 요청하는 트리거라고 합니다. “몇 번째 아이템에 가까워지면 미리 불러올지”를 정의하는 값입니다.
무한 스크롤에서 사용자가 끝에 닿기 직전에 미리 데이터를 가져오는 구조인데, 이 타이밍을 잘못 잡으면 사용자가 로딩을 기다리거나 불필요한 요청이 많아질 수 있다는 걸 이해했습니다.
clientArguments vs requestedArguments
이 두 값의 차이가 처음엔 헷갈렸습니다. clientArguments는 클라이언트(브라우저)가 처음 설정한 요청 조건이고, requestedArguments는 실제로 서버에 전달되는 최종 요청 값이라고 합니다. 둘이 같아 보이는 건 이 경우에는 별도 가공 없이 그대로 전달됐기 때문입니다.
“서버가 어떤 조건으로 데이터를 가져왔나”를 확인할 때는 최종 전달값인 requestedArguments를 기준으로 봐야 한다는 걸 배웠습니다.
Payload에서 핵심 값만 정리하면 payload: {startIndex: 0, count: 3, feedSortOrder: "FeedSortOrder_RELEVANCE"}입니다. count: 3은 피드 게시물을 3개씩 묶음으로 가져온다는 의미이고, 정렬 기준은 관련성(RELEVANCE)입니다. 일반적으로 10~20개씩 가져오는 서비스가 많다고 하는데 LinkedIn은 3개 단위로 자주 요청하는 구조를 쓴다는 게 흥미로웠습니다.
preloadDistance: 5, preloadLength: 2000도 보였습니다. 5번째 아이템에 가까워지면 다음 데이터를 미리 불러온다는 의미인 것 같습니다. 정확한 단위는 LinkedIn 내부 구현이라 외부에서 확인할 방법이 없었지만, “사용자가 끝에 닿기 전에 미리 불러오는 설계가 있다”는 구조 자체는 이해할 수 있었습니다.
Response 탭
여기서 막혔습니다. 서버가 돌려준 실제 데이터를 볼 수 있다고 했는데, 어떤 항목을 클릭해도 JSON이 아닌 알 수 없는 문자들만 보였습니다. 처음엔 제가 뭔가 잘못한 줄 알고 한참 헤맸습니다.
찾아보니 LinkedIn이 응답 데이터를 protobuf라는 형식으로 인코딩해서 보내기 때문에 외부에서는 JSON으로 읽을 수 없다고 합니다. 보안 때문에 의도적으로 그렇게 설계한 것이었습니다.
그래서 JSONPlaceholder라는 테스트용 API 사이트로 우회해서 Response 구조를 확인했습니다. 브라우저 주소창에 아래 URL을 입력하면 됩니다.
https://jsonplaceholder.typicode.com/postsNetwork 탭 필터를 All로 바꾼 뒤, 목록에서 posts 항목을 클릭하고 Response 탭을 확인합니다. LinkedIn에서는 못 봤던 JSON 데이터가 깔끔하게 보입니다.
userId, id, title, body 키값으로 게시물 데이터가 담겨 있고, 그게 여러 개 반복되는 구조입니다.
Payload 탭이 없는 건 정상입니다. GET 요청이라 서버에 별도로 보낼 데이터가 없기 때문입니다.
실습하면서 이해한 것들
1. Method: GET / POST
처음엔 GET은 조회, POST는 저장이라고 단순하게 외웠습니다. 그런데 LinkedIn 피드를 직접 보니 조회 목적인데도 POST를 쓰고 있었습니다.
찾아보니 요청할 때 같이 보내야 하는 조건값이 복잡하면 POST를 쓰는 경우가 있다고 합니다. paginationRequest, feedSortOrder 같은 복잡한 데이터를 함께 보내야 해서 POST를 쓴 게 그 예입니다. 원칙은 있지만 실무에서는 예외가 있다는 걸 직접 보고 나서야 이해가 됐습니다.
GET은 조건값을 URL에 바로 붙여서 보내는 방식이라 단순한 조회에 적합하고, POST는 별도 공간(Payload)에 데이터를 담아서 보내는 방식이라 복잡한 조건이 필요할 때 씁니다.
GET 방식의 전형적인 예를 들면 이렇습니다.
게시물 1개 조회: /posts/1
검색: /search?keyword=재택근무
목록 조회: /posts?page=1&count=102. 인증과 보안 (Headers & Cookies)
Headers 탭을 확인해 보니, 이 서비스는 Authorization이라는 별도 항목 대신 하단 ‘Request Headers’ 영역 내 Cookie 항목 안에 인증 정보를 담아 서버와 대화하고 있었습니다. 상단 우측의 Cookies 탭을 누르면, 이 복잡한 쿠키 값들이 어떤 이름과 유효기간을 가졌는지 표 형태로 더 자세히 볼 수 있다는 것도 알게 되었습니다.
어떤 방식이든 브라우저가 서버에 ‘나 로그인된 사용자야’라는 증표를 몰래 보내고 있다는 것입니다. 이 증표가 없거나 만료되면 서버는 데이터를 보내주지 않고 에러(401 Unauthorized)를 냅니다.
기획 관점:
- 보안의 중요성: 인증 정보(Cookie)가 털리면 다른 사람이 내 계정인 척 데이터를 요청할 수 있다는 걸 알게 되었습니다.
- 로그아웃 기획: 사용자가 로그아웃을 누르면 브라우저 보관함(Cookies 탭)에 있는 이 신분증들을 삭제하거나 무효화하는 로직이 왜 필수적인지 이해했습니다.
- 비로그인 정책: 신분증(Cookie)이 없는 사용자에게 어디까지 데이터를 열어줄지(예: 채용 공고는 공개하되, 지원하기는 로그인 유도 등) 정책을 세우는 것이 기획자의 몫임을 다시 한번 느꼈습니다.
- 권한 관리: 인증 정보를 통해 확인된 사용자가 ‘일반 등급’인지 ‘프리미엄 등급’인지에 따라 어떤 유료 데이터를 더 보여줄 것인가?
기획 관점에서는 비로그인 사용자에게 어떤 데이터를 보여줄 건지를 명확하게 정의해야 한다는 걸 이해했습니다. 또한 기획 내용이 실제로 이런 인증 시스템을 통해 기술적으로 구현된다는 것을 체감할 수 있었습니다.
3. Query Parameters: start=0, count=10
URL 뒤에 붙는 조건값입니다. start=0은 “처음부터”, count=10은 “10개만 줘”라는 의미입니다.
무한 스크롤은 보통 스크롤을 내리면 start=10, start=20으로 바뀌면서 다음 묶음을 요청하는 방식으로 작동한다고 배웠습니다.
첫 번째 스크롤: start=0, count=10 → 1~10번째 게시물
두 번째 스크롤: start=10, count=10 → 11~20번째 게시물
세 번째 스크롤: start=20, count=10 → 21~30번째 게시물실제 캡처한 Payload 영역에서는 startIndex: 0, count: 3 이라는 숫자 형태의 조건을 확인할 수 있었습니다. 전형적인 Offset 방식으로, 처음(0)부터 3개의 게시물을 요청하는 구조입니다.
그런데 LinkedIn에서는 startIndex가 바뀌지 않고 스크롤 시 token 값이 매번 바뀌는 걸 발견했습니다. 처음엔 뭔가 잘못 작동되는 줄 알고 찾아보니 토큰 방식이라는 페이지네이션 방법이 따로 있었습니다.
페이지네이션 방식의 이해 (Offset vs Cursor):
- 숫자 방식 (Offset): “11번째부터 10개 줘”라고 요청하는 방식
- 문제점: 내가 1페이지를 보는 동안 누군가 새 글을 1개 올리면, 2페이지로 넘어갈 때 1페이지에서 봤던 마지막 글이 또 나오는 중복 현상이 발생
- 페이지 경계에서 데이터 중복이 발생할 위험이 있음
- 문제점: 내가 1페이지를 보는 동안 누군가 새 글을 1개 올리면, 2페이지로 넘어갈 때 1페이지에서 봤던 마지막 글이 또 나오는 중복 현상이 발생
- 토큰 방식 (Cursor): “이 글(토큰) 다음부터 10개 줘”라고 요청하는 방식
- 장점: 사이에 새 글이 아무리 추가되어도 내가 보고 있던 지점(토큰) 이후를 정확히 찾아가므로 중복 발생 없음
- 데이터가 추가되어도 사용자가 보던 시점을 정확히 유지함
- 장점: 사이에 새 글이 아무리 추가되어도 내가 보고 있던 지점(토큰) 이후를 정확히 찾아가므로 중복 발생 없음
데이터가 실시간으로 추가되는 피드에서 숫자 방식을 쓰면 페이지 경계가 어긋날 수 있어서 토큰 방식을 쓴다고 합니다. 기획 의도에 따른 설계였다는 걸 알고 나서야 납득이 됐습니다.
결국 서비스의 성격(정적인 목록 vs 실시간 피드)에 따라 어떤 기술적 방식을 선택할지 정의하는 것이 기획자의 중요한 의사결정임을 깨달았습니다.
4. Status Code
서버가 요청에 응답할 때 결과를 숫자로 알려주는 코드입니다.
| 코드 | 의미 | 상황 예시 |
|---|---|---|
| 200 | 성공 | 요청한 데이터를 정상적으로 돌려줌 |
| 401 | 인증 실패 | 로그인 안 됐거나 세션 만료 |
| 403 | 권한 없음 | 로그인은 됐지만 해당 데이터 접근 불가 |
| 404 | 없는 데이터 | 요청한 리소스가 서버에 존재하지 않음 |
| 500 | 서버 오류 | 클라이언트 문제가 아닌 서버 내부 문제 |
Network 탭 목록에서 각 요청 옆 Status 컬럼에 숫자가 바로 보입니다. 정상적으로 작동하는 서비스에서는 200이 대부분이라 에러 코드는 직접 확인하기 어려웠습니다.
그래도 기획 관점에서는 에러 상황마다 사용자에게 보여줄 메시지가 달라진다는 게 중요합니다. 항상 해당 화면 기획 시 관련 내용을 마주했을 때만 이 부분을 정의했는데 401이면 “다시 로그인해 주세요”, 404면 “존재하지 않는 페이지입니다” 같은 케이스를 기획 단계에서 미리 정의해두는 것이 필요하다는 걸 배웠습니다.
5. Response Body (JSON)
JSONPlaceholder에서 본 Response 구조입니다. 중괄호 {}와 대괄호 []로 이루어져 있고, 키(key)와 값(value) 쌍으로 구성됩니다.
{
"posts": [
{ "id": 1, "content": "게시물 내용", "author": "홍길동" },
{ "id": 2, "content": "두 번째 게시물", "author": "김철수" }
]
}화면에 보이는 모든 텍스트와 데이터는 이 JSON에서 나옵니다. “이 화면에 작성자 이름을 보여주고 싶다”고 기획하면 API Response에 author 값이 있어야 한다는 게 연결되기 시작했습니다. 없으면 추가 기획이나 요청을 해야 합니다.
DB 실습을 먼저 했던 게 여기서 연결됐습니다. DB에서 만들었던 테이블 컬럼명이 JSON의 key값과 같은 역할을 합니다.
Table posts {
id int [pk]
content text
author varchar
}서버가 그 테이블에서 데이터를 꺼내서 JSON으로 변환해 돌려주는 것이 Response Body입니다. 그래서 key값이 테이블 컬럼명과 일치하는 경우가 많다고 합니다. DB 설계 → API Response → 화면 표시가 하나로 연결된 구조라는 게 이번 실습에서 가장 크게 와닿은 부분이었습니다.
정리
처음엔 Elements 이외의 탭을 보면서 생소한 값들을 확인하는 것이 낯설었습니다. 그래도 하나씩 따라가다 보니 LinkedIn이 어떻게 피드를 불러오는지 조금씩 읽히기 시작했습니다.
이번 실습에서 이해한 것들입니다.
- Network 탭의 역할: 브라우저와 서버가 주고받는 모든 요청·응답을 실시간으로 기록
- Fetch/XHR vs JSON vs WebSocket
- GET vs POST: 원칙은 있지만 실무에서는 예외가 있다는 것을 직접 확인
- Payload 구조: retryCount, itemDistanceTrigger, count, feedSortOrder의 의미
- 페이지네이션 방식: offset(숫자) vs 토큰 방식의 차이
- Response JSON: DB 설계 → API → 화면 표시가 하나로 연결된 구조
다음 편에서는 검색 기능 API를 분석합니다. 검색어를 입력할 때 서버에 어떤 요청이 전달되고, 필터와 정렬 옵션이 URL 파라미터에 어떻게 담기는지 직접 확인해봅니다.
— Lane
