native-data-fetching

native-data-fetching 스킬 개요

native-data-fetching가 실제로 도움 되는 일

native-data-fetching 스킬은 React Native 및 Expo 앱에서 네트워크 요청을 구현하고 디버깅할 때 쓰는 Expo 중심 가이드입니다. 단순히 “fetch 호출 하나 써줘” 수준을 넘어서야 할 때 특히 유용합니다. API 요청, auth 헤더, 캐싱 판단, 오프라인 동작, 환경별 base URL, Expo Router 데이터 로더까지 모두 이 스킬의 범위에 들어갑니다.

Frontend Development 팀에 특히 잘 맞는 경우

native-data-fetching for Frontend Development는 원격 데이터에 의존하는 모바일 기능이나 Expo web 기능을 만들고 있고, Expo 생태계에 맞는 관례를 따르고 싶을 때 좋은 선택입니다. 특히 plain fetch, React Query나 SWR 같은 데이터 라이브러리, 그리고 Expo Router의 route-level loader 사이에서 무엇을 선택할지 고민하는 개발자에게 적합합니다.

실제로 해결하려는 핵심 작업

사용자는 보통 아래 네 가지 중 하나를 하려는 경우가 많습니다.

• 안정적인 API 연동을 배포하려는 경우
• 깨졌거나 불안정한 네트워크 흐름을 고치려는 경우
• 특정 screen이나 route에 맞는 합리적인 fetching 패턴을 고르려는 경우
• config, auth, loader와 관련된 Expo 특유의 흔한 실수를 피하려는 경우

이 지점에서 native-data-fetching 스킬은 저장소를 대충 훑어보는 것보다 더 유용합니다. 네트워킹을 단순 코드 조각이 아니라 구현 방식의 선택 문제로 다루기 때문입니다.

핵심 차별점과 제약

가장 큰 차별점은 Expo에 맞춘 명확한 방향성입니다. 원문은 axios보다 expo/fetch를 선호한다고 분명히 밝히고 있고, 기본적인 요청 처리에서 끝나지 않고 캐싱, 오프라인 지원, 토큰 처리, Expo Router loader까지 다룹니다. 또한 SDK 55+ 기준 Expo web의 server/static 실행 모델과 useLoaderData에 대한 집중 참고 문서도 포함합니다.

주요 제약도 분명합니다. 이것은 완전한 네트워킹 프레임워크가 아닙니다. 가이드와 예제를 담은 스킬 문서이기 때문에, 결과물의 품질은 프롬프트의 구체성과 앱 아키텍처가 얼마나 정리되어 있는지에 크게 좌우됩니다.

native-data-fetching 스킬 사용 방법

native-data-fetching 설치 맥락

Expo skills 저장소에서 스킬을 설치합니다.

npx skills add https://github.com/expo/skills --skill native-data-fetching

설치 후에는 먼저 아래 파일부터 읽는 것이 좋습니다.

• SKILL.md
• references/expo-router-loaders.md

이 순서대로 보면 먼저 전반적인 네트워킹 가이드를 잡고, 그다음 Expo Router web 앱에서만 중요한 loader 특수 모델을 이해할 수 있습니다.

언제 native-data-fetching 스킬을 호출해야 하나

다음과 같은 작업이 포함되면 native-data-fetching skill을 사용하는 것이 좋습니다.

• 외부 API 호출
• form 또는 JSON 데이터 전송
• auth 헤더 추가 또는 토큰 갱신 로직 구현
• timeout, HTTP 오류, malformed response 디버깅
• plain fetch, React Query, SWR, loader 중 선택
• offline/cache 동작 처리
• 환경별 API URL 설정
• Expo Router의 route-level 데이터 로딩 구현

작업이 네트워크 상태, 요청 라이프사이클, 원격 데이터 아키텍처에 닿아 있다면 버그가 생긴 뒤가 아니라 초기에 native-data-fetching을 호출하는 편이 낫습니다.

native-data-fetching 스킬이 필요로 하는 입력 정보

다음 정보를 함께 주면 결과가 훨씬 좋아집니다.

• 만들고 있는 screen, route, 또는 feature
• 런타임 대상: iOS, Android, web, 또는 셋 다
• 요청 유형: GET, POST, mutation flow, polling, preload 등
• API 세부 정보: endpoint 형태, auth 모델, 기대 응답, 에러 계약
• 데이터가 cache, refresh, retry되어야 하는지 또는 offline에서도 동작해야 하는지
• Expo Router, React Query, SWR, plain React state 중 무엇을 쓰는지
• 앱 안에 이미 존재하는 환경 설정이나 base URL 규칙

이 맥락 없이도 스킬이 코드를 만들 수는 있지만, 잘못된 fetching 패턴을 고를 가능성이 큽니다.

막연한 목표를 좋은 프롬프트로 바꾸는 법

약한 프롬프트:

Fetch user data for my screen.

더 강한 프롬프트:

Use native-data-fetching to implement a profile screen in an Expo app.
Target platforms: iOS and Android.
Need: authenticated GET /me request with Bearer token, loading state, 401 handling, retry on network failure, and stale data shown while refetching.
Current stack: Expo Router + React Query.
Return: recommended pattern, code, and where to place config for the API base URL.

두 번째 예시가 더 잘 작동하는 이유는, direct fetch 로직을 쓸지, query 라이브러리를 쓸지, route-aware 패턴을 쓸지 판단할 수 있을 만큼 충분한 정보를 native-data-fetching에 주기 때문입니다.

native-data-fetching에서 올바른 fetching 패턴 고르기

실무적으로는 아래와 같이 결정하면 됩니다.

• 단발성 요청이나 단순한 흐름이라면 plain fetch 또는 expo/fetch
• cache invalidation, background refresh, request deduplication이 중요하다면 React Query 또는 SWR
• 특히 SDK 55+ 환경에서 Expo web에서 렌더 전에 route가 데이터를 먼저 불러와야 한다면 Expo Router loader

이건 native-data-fetching guide의 가장 가치 높은 활용법 중 하나입니다. 구현부터 시작하지 말고, 먼저 어떤 패턴을 써야 할지 추천받는 식으로 쓰는 것이 좋습니다.

Expo Router loader 사용 시 주의할 점

useLoaderData를 쓴다면 포함된 참고 문서가 중요합니다. Expo Router web의 loader는 이중 실행 모델을 가집니다.

• 초기 페이지 로드에서는 server-side에서 실행될 수 있음
• client-side navigation에서는 브라우저가 HTTP를 통해 loader 데이터를 가져옴

즉, 요청 컨텍스트, 호스팅 방식, 설정은 "server"와 "static" output mode에 따라 달라집니다. 작업에서 loader를 언급한다면 아래 정보를 꼭 포함하세요.

• Expo SDK 버전
• web output mode
• headers/cookies/request 접근이 필요한지 여부
• hosting model

이 정보가 없으면 생성된 해법이 현재 설정에서 지원되지 않는 기능을 전제로 할 수 있습니다.

시간을 아껴주는 저장소 읽기 순서

빠르게 native-data-fetching usage를 파악하려면 저장소를 무작정 뒤지지 말고 다음 순서를 따르세요.

1. 범위와 선호 사항은 SKILL.md
2. 앱이 Expo Router 데이터 로딩을 쓰면 references/expo-router-loaders.md
3. 그다음은 현재 앱의 API client, auth utilities, environment config 파일

상위 저장소의 스킬 자체는 짧기 때문에, 실제 병목은 읽는 시간이 아니라 현재 앱 아키텍처에 정확히 매핑하는 데서 생기는 경우가 많습니다.

구현을 위한 실전 워크플로

좋은 워크플로는 보통 이렇습니다.

1. 패턴 추천을 먼저 받기
2. 구체적인 요청 레이어나 hook 구현 요청하기
3. error/loading/empty 상태 추가하기
4. auth와 environment 처리 붙이기
5. 실패 케이스 테스트하기
6. 필요할 때만 cache/offline 개선 추가하기

이 순서를 따르면 과한 설계를 피할 수 있습니다. 많은 팀이 endpoint, auth, base URL 동작 검증도 끝나기 전에 고급 캐싱부터 들어가곤 합니다.

생성 코드에 영향을 주는 선호 사항

원문은 axios를 피하고 expo/fetch를 선호한다고 명시합니다. 그런데도 axios를 요청하면, 이는 스킬이 제시한 기본 방향과 어긋나는 셈입니다. 다만 코드베이스가 이미 axios를 표준으로 쓰고 있다면 그 사실을 분명히 말하세요. 그래야 출력이 현재 스택과 충돌하지 않고 맞춰집니다.

처음부터 명시하면 좋은 요청 세부 사항

바로 쓸 수 있는 첫 초안을 얻으려면 다음 구현 세부 사항을 포함하세요.

• JSON인지 multipart/form-data인지
• 필요한 헤더
• 토큰 소스와 refresh 동작
• timeout 또는 retry 기대치
• non-2xx 응답이 JSON 에러 바디를 반환하는지
• UI가 block되어야 하는지, stream해야 하는지, stale data를 먼저 렌더해야 하는지

이런 정보는 endpoint 경로 그 자체보다 더 중요한 경우가 많습니다.

native-data-fetching 스킬 FAQ

native-data-fetching는 Expo 앱 전용인가요?

가장 큰 가치는 Expo와 React Native 맥락에서 나옵니다. 특히 expo/fetch 선호와 Expo Router loader 참고 문서 때문입니다. 일부 fetch 패턴은 일반적인 웹 지식으로도 통하지만, 이 스킬은 분명 Expo 생태계에 맞춰 조정되어 있습니다.

native-data-fetching는 초보자도 쓰기 쉬운가요?

네, 목표가 구체적이라면 그렇습니다. 초보자도 screen, endpoint, 기대 동작을 명확히 설명하면 native-data-fetching skill을 충분히 잘 활용할 수 있습니다. 반면 완전히 열린 상태의 학습용 질문에는 상대적으로 덜 적합합니다. 이 스킬은 무언가를 실제로 구현하거나 디버깅하는 상황을 전제로 하기 때문입니다.

일반적인 코딩 프롬프트와는 무엇이 다른가요?

일반 프롬프트도 동작하는 fetch 코드를 줄 수는 있습니다. 하지만 expo/fetch를 우선할지, 어떤 데이터 로딩 모델이 맞는지, Expo Router loader 동작을 고려해야 하는지 같은 생태계 특화 선택을 놓치기 쉽습니다. 문법만큼 아키텍처와 프레임워크 적합성이 중요하다면 native-data-fetching guide가 더 적합합니다.

언제 native-data-fetching를 쓰지 말아야 하나요?

로컬 전용 state, UI 스타일링, 애니메이션, 데이터 fetch가 없는 navigation처럼 원격 데이터와 무관한 작업이라면 굳이 쓸 필요가 없습니다. 또한 완전한 backend API 설계나 고급 서버 인프라 계획이 필요하다면 이 스킬은 범위가 너무 좁습니다.

이미 React Query나 SWR을 쓰고 있어도 함께 써야 하나요?

네. 오히려 아주 좋은 활용 사례입니다. 현재 어떤 라이브러리를 쓰는지, 기존 query key, invalidation 전략, cache 규칙을 유지하고 싶은지 함께 알려주세요. 기존 데이터 레이어를 대체하는 것보다 확장하는 방향으로 쓸 때 가이드의 가치가 더 커집니다.

native-data-fetching는 Expo Router loader를 충분히 다루나요?

도입 판단에 필요한 중요한 포인트와 핵심 참고 문서는 제공합니다. 다만 모든 edge case를 다루지는 않습니다. loader가 앱의 중심이라면 실제 프로덕션 동작을 구현하기 전에 references/expo-router-loaders.md를 직접 읽고 설정과 실행 세부 사항을 확인하는 것이 좋습니다.

native-data-fetching 스킬을 더 잘 활용하는 방법

endpoint만 말하지 말고 native-data-fetching에 아키텍처 맥락까지 주기

결과 품질이 가장 크게 좋아지는 지점은, 요청이 앱 안에서 어디에 위치하는지 알려줄 때입니다.

• component
• custom hook
• query layer
• route loader
• shared API client

이 정보를 주면 구조와 동떨어진 코드 조각이 아니라 현재 구조에 맞는 결과를 만들 수 있습니다.

코드보다 결정을 먼저 요청하기

효과적인 패턴은 다음과 같습니다.

Use native-data-fetching to choose the best approach for this feature.
Compare plain fetch vs React Query vs Expo Router loader for my constraints.
Then implement the winning option.

이렇게 하면 첫 출력이 단순 생성 코드가 아니라 설계 결정이 되기 때문에, 이후 재작업이 줄어듭니다.

실제로 신경 쓰는 실패 모드를 포함하기

실패 처리 조건을 언급하지 않으면 지나치게 낙관적인 예시만 받기 쉽습니다. 아래처럼 현실적인 우려를 명시하면 결과가 좋아집니다.

• 401 token expiry
• offline device
• slow connections
• duplicate requests on screen focus
• bad JSON payloads
• server 500s with error messages

이런 제약을 주면 스킬이 프로덕션 수준에 가까운 방향으로 답하게 됩니다.

흔한 실패 원인: 플랫폼 가정이 모호한 경우

나쁜 네트워킹 조언의 상당수는 native와 web 가정을 섞어버릴 때 나옵니다. 아래 사항을 명확히 하세요.

• native only
• web only
• universal app
• Expo Router web with loaders
• static export vs server rendering

이 차이는 중요합니다. setup마다 loader 동작, 요청 컨텍스트, 호스팅 제약이 달라지기 때문입니다.

흔한 실패 원인: config와 base URL 처리 방식이 불명확한 경우

환경 정보를 빼면 생성된 코드가 URL을 하드코딩하거나 config를 잘못된 레이어에 둘 수 있습니다. 아래 정보를 제공하세요.

• dev/staging/prod base URL 규칙
• env vars가 이미 있는지 여부
• 현재 config가 어디에 있는지
• 플랫폼별로 요청이 달라지는지 여부

이 정보가 있으면 실제 앱에서 native-data-fetching install 이후 도입 과정이 훨씬 매끄러워집니다.

현실적인 응답 계약을 주면 결과 품질이 좋아진다

“user data를 반환함”이라고만 말하는 것보다 아래처럼 구체적인 편이 낫습니다.

GET /me returns 200 { id, name, avatarUrl }.
401 returns { error: "token_expired" }.
500 may return HTML from an upstream proxy.

이런 정보는 더 안전한 파싱과 에러 처리를 끌어내는 데 도움이 되며, 특히 불안정한 API를 디버깅할 때 유용합니다.

첫 답변 이후에는 반복해서 다듬기

초기 결과를 받은 뒤에는 아래처럼 후속 요청을 이어가세요.

• convert this to React Query
• adapt this to Expo Router loader usage
• add optimistic mutation handling
• refactor into a reusable API client
• harden error states for offline mode

첫 답변은 패턴을 잡는 역할을 하면 충분하고, 이후 턴에서 앱의 실제 제약에 맞춰 정교하게 다듬는 것이 좋습니다.

웹 렌더링이 중요하다면 loader 참고 문서를 직접 읽기

프로젝트에서 route-level 데이터 로딩을 쓴다면 가장 빠른 개선 방법은 references/expo-router-loaders.md를 읽고, 그 용어 그대로 프롬프트에 반영하는 것입니다. 예를 들어 useLoaderData, "server" vs "static", request 접근, hosting model 같은 표현을 포함하세요. 그러면 막연히 “렌더 전에 데이터 불러와줘”라고 요청하는 것보다 훨씬 날카로운 native-data-fetching usage 결과를 얻을 수 있습니다.

native-data-fetching는 네트워킹 작업에 집중시킬수록 좋다

이 스킬은 프롬프트가 원격 데이터 문제에 집중될수록 성능이 좋습니다. 네트워킹, 상태 관리, UI 리디자인, navigation 재구성을 한 번에 묶어 요청하면 결과가 대체로 얕아집니다. 먼저 native-data-fetching으로 API와 데이터 레이어를 깔끔하게 정리한 뒤, 나머지 작업은 분리해서 진행하는 편이 낫습니다.