expo-dev-client

expo-dev-client 스킬 개요

expo-dev-client가 하는 일

expo-dev-client 스킬은 언제 Expo development client가 정말 필요한지 먼저 판단하게 해주고, 필요할 때는 EAS Build를 사용해 로컬 또는 TestFlight용 development client를 구성하고 빌드하는 과정을 안내합니다. 핵심은 단순히 “빌드를 만든다”가 아니라, Expo 문서를 더듬어 추측하지 않고도 실제 기기에서 동작하는 커스텀 네이티브 테스트 앱을 올바르게 배포할 수 있게 돕는 것입니다.

이 스킬이 잘 맞는 사용자

이 스킬은 특히 다음 경우에 잘 맞습니다:

• 네이티브 모듈을 추가하는 Expo 팀
• 로컬 Expo 모듈이나 커스텀 네이티브 코드를 테스트하는 개발자
• widget, app clip, extension 같은 Apple 전용 타깃을 사용하는 앱
• TestFlight를 통한 내부 iOS 테스트 경로를 반복 가능하게 만들고 싶은 팀

앱이 Expo Go에서 완전히 잘 동작한다면, 이 스킬은 대체로 필요하지 않습니다.

설치 전 가장 중요한 판단

도입 여부를 가르는 가장 큰 질문은 단순합니다. 정말 development client가 필요한가? expo-dev-client 스킬의 가치는 이 판단을 초기에 해준다는 데 있습니다. 이 스킬은 먼저 npx expo start로 Expo Go에서 확인해보라고 분명히 유도합니다. 덕분에 불필요한 빌드 시간 낭비와 과한 EAS 설정 복잡도를 피할 수 있습니다.

일반적인 Expo 프롬프트와 expo-dev-client의 차이

보통의 프롬프트는 에이전트에게 “Expo dev client를 설정해줘”라고만 지시할 수 있습니다. 하지만 이 스킬은 훨씬 더 의사결정 중심적입니다. 특히 다음에 초점을 맞춥니다:

• dev client가 필요해지는 기준점
• 필요한 eas.json 구조
• 로컬 빌드와 cloud/TestFlight 빌드의 차이
• 실제 기기 배포형 테스트를 위한 실무 명령 흐름

그래서 넓은 범위의 Expo 도우미 프롬프트보다, 설정 작업이나 릴리스 인접 워크플로우에서 더 실용적입니다.

expo-dev-client 스킬 사용 방법

expo-dev-client 스킬 설치

skills 호환 환경에서 다음 명령으로 설치합니다:

npx skills add https://github.com/expo/skills --skill expo-dev-client

이 스킬은 간결하고 핵심 내용이 SKILL.md에 집중돼 있으므로, 설치의 의미는 주로 Expo 네이티브 테스트 작업 때 재사용 가능한 상태로 준비해두는 것에 있습니다.

명령보다 먼저, 해결할 작업을 정의하세요

expo-dev-client 스킬을 호출하기 전에 실제 목표를 먼저 정리하세요:

• “네이티브 SDK를 추가했고 iPhone에서 테스트해야 한다”
• “QA용 브랜치별 dev client가 필요하다”
• “앱에 widget이 들어가서 이제 Expo Go만으로는 부족하다”
• “TestFlight를 통해 배포할 iOS development build가 필요하다”

이게 중요한 이유는, 이 스킬이 커스텀 네이티브 코드가 왜 필요한지 분명할 때 가장 강력하게 작동하기 때문입니다.

먼저 Expo Go로 충분한지 확인하세요

흔한 실수는 expo-dev-client를 너무 일찍 꺼내드는 것입니다. 권장되는 첫 번째 확인은 다음입니다:

npx expo start

앱이 Expo Go에서 잘 동작한다면 거기서 멈추세요. development client를 도입하면 빌드 시간, 서명 요구사항, 배포 오버헤드가 추가됩니다. 네이티브 기능 때문에 정말 필요한 경우에만 이 스킬을 쓰는 것이 맞습니다.

expo-dev-client가 특히 잘 맞는 신호

다음이 프로젝트에 포함되어 있다면 expo-dev-client를 쓰는 편이 맞습니다:

• 로컬 Expo 모듈
• 커스텀 네이티브 코드
• Expo Go에서 지원되지 않는 서드파티 네이티브 모듈
• widget, app clip, extension 같은 Apple 타깃

이런 경우에는 dev client가 “선택 사항”이 아니라 사실상 필수로 바뀝니다.

에이전트가 제대로 판단하려면 최소한 이 정보는 주세요

에이전트가 expo-dev-client 스킬을 제대로 활용하게 하려면 다음 정보를 함께 주는 것이 좋습니다:

• 대상 플랫폼: ios, android, 또는 둘 다
• 원하는 배포 경로: 로컬 설치, 내부 테스트, 또는 TestFlight
• 앱에 EAS 설정이 이미 되어 있는지 여부
• 현재 eas.json
• Expo Go에서 지원되지 않는 네이티브 모듈을 사용하는지 여부
• 버전 관리나 서명 관련 제약사항

이 정보가 없더라도 명령 자체는 제안할 수 있지만, 적절한 빌드 프로필을 놓치거나 과한 설정을 권할 가능성이 커집니다.

“set up expo-dev-client”보다 더 강한 프롬프트를 쓰세요

약한 프롬프트:

Set up expo-dev-client.

더 좋은 프롬프트:

Use the expo-dev-client skill to determine whether this Expo app needs a dev client. We added a third-party native iOS SDK and need a TestFlight-distributed development build for internal QA. Review this eas.json, identify missing settings, and give the exact commands for building and submitting.

이 프롬프트가 더 잘 작동하는 이유:

• 먼저 적합성 판단을 요구함
• 네이티브 도입 이유를 명시함
• 목표 워크플로우를 구체화함
• 실제 수정 가능한 설정 정보를 함께 제공함

eas.json을 올바르게 구성하세요

이 스킬이 가장 핵심적으로 드러내는 설정 포인트는 developmentClient: true가 포함된 development build profile이며, 보통 버전 자동화 설정과 함께 사용됩니다:

{
  "cli": {
    "version": ">= 16.0.1",
    "appVersionSource": "remote"
  },
  "build": {
    "production": {
      "autoIncrement": true
    },
    "development": {
      "autoIncrement": true,
      "developmentClient": true
    }
  },
  "submit": {
    "production": {},
    "development": {}
  }
}

중요한 필드는 다음과 같습니다:

• developmentClient: true: EAS가 development client를 포함해 빌드하도록 지정
• autoIncrement: true: 빌드 번호 관리에서 생기는 마찰 감소
• appVersionSource: "remote": EAS 기준으로 버전 관리를 일관되게 유지

원격 실제 기기 테스트가 중요하다면 TestFlight로 빌드하세요

iOS 팀에게 가장 가치가 큰 expo-dev-client usage 경로는 대체로 TestFlight입니다:

eas build -p ios --profile development --submit

이 흐름은 단순한 로컬 산출물이 아니라, 테스터에게 배포 가능한 dev-capable 앱이 필요할 때의 실전형 expo-dev-client for Deployment 패턴입니다. cloud build와 제출을 한 번에 묶기 때문에, 단계를 따로 쪼개는 것보다 보통 더 빠르고 운영상 깔끔합니다.

속도나 프라이버시가 중요하면 로컬 빌드를 쓰세요

TestFlight가 꼭 필요하지 않다면, 로컬 빌드가 더 적합한 워크플로우일 수 있습니다:

• 환경에 따라 더 빠른 반복 가능
• 로컬 툴링에 대한 통제력 증가
• 더 넓은 내부 배포 전에 기기 테스트하기에 유용

설정 자체를 디버깅하거나, 내 기기에서 네이티브 연동을 먼저 검증하려면 로컬 빌드를 선택하세요. QA나 비기술 직군 테스터와 협업해야 한다면 TestFlight가 더 적합합니다.

먼저 봐야 할 저장소 파일

이 스킬은 단순합니다. 가장 먼저 SKILL.md를 보세요. 이 스킬 경로에는 resources/, rules/, 헬퍼 스크립트 같은 추가 지원 디렉터리가 없기 때문에, 실제로 쓸 수 있는 가이드는 대부분 이미 거기에 모여 있습니다.

동시에 이것은 사용자가 과도한 자동화 로직을 기대하면 안 된다는 뜻이기도 합니다. 이 스킬은 기본적으로 실무적인 의사결정 + 워크플로우 안내서에 가깝습니다.

실제 프로젝트에서의 추천 expo-dev-client 워크플로우

신뢰할 수 있는 expo-dev-client guide 흐름은 다음과 같습니다:

1. Expo Go가 네이티브 이유로 실패하는지 확인한다.
2. eas.json을 검토하거나 새로 만든다.
3. developmentClient: true가 포함된 development profile을 추가한다.
4. 로컬 빌드와 TestFlight 배포 중 어느 쪽이 맞는지 결정한다.
5. 플랫폼에 맞는 정확한 EAS build 명령을 실행한다.
6. 실제 기기에서 테스트한다.
7. 버전 관리나 제출 동작이 어긋나면 profile 설정을 다시 조정한다.

이 순서를 따르면 불필요한 빌드 사이클을 줄일 수 있고, “사실 dev client가 필요 없었다”는 케이스도 초기에 걸러낼 수 있습니다.

expo-dev-client 스킬 FAQ

expo-dev-client는 고급 Expo 앱에만 필요한가요?

대체로 그렇습니다. 초보자도 쓸 수는 있지만, 이 스킬이 진짜 의미를 가지는 시점은 앱이 네이티브 요구사항 때문에 Expo Go를 넘어서는 단계에 들어섰을 때입니다. 아직 순수 managed workflow 범위라면, 당장은 큰 가치가 없을 수 있습니다.

expo-dev-client는 프로젝트에 expo-dev-client를 설치하는 것과 같은 의미인가요?

아닙니다. expo-dev-client 스킬은 development-client 빌드를 둘러싼 워크플로우 가이드입니다. 언제 써야 하는지, EAS를 어떻게 설정해야 하는지, 어떤 빌드 경로를 선택해야 하는지를 도와줍니다. 단순한 패키지 설치 안내와는 다릅니다.

언제 expo-dev-client 스킬을 쓰지 말아야 하나요?

다음 경우에는 쓰지 않는 편이 맞습니다:

• 앱이 이미 Expo Go에서 잘 동작하는 경우
• JavaScript 수준의 반복 개발만 필요한 경우
• development-client 설정이 아니라 전체 release build 가이드를 찾는 경우
• 문제가 네이티브 기능이나 빌드 배포와 무관한 경우

일반적인 Expo 트러블슈팅 프롬프트와는 무엇이 다른가요?

일반 프롬프트는 흔히 포괄적이고 모호한 빌드 조언을 내놓습니다. 반면 expo-dev-client skill은 범위가 더 좁기 때문에 설치/도입 판단 가이드에 더 강합니다. 특히 “정말 dev client가 필요한가?”라는 체크포인트와, 실제 도입을 막는 핵심 EAS profile 설정을 정확히 짚어주는 점이 차별점입니다.

expo-dev-client는 Android에도 유용한가요?

네, 유용합니다. 다만 현재 스킬 설명에서 가장 강하게 드러나는 가이드는 iOS와 TestFlight 중심입니다. 그래도 커스텀 네이티브 코드 때문에 Expo Go 대신 dev client가 필요한 상황이라면, 기본 논리는 Android development build에도 그대로 적용됩니다.

배포 워크플로우에도 적합한가요?

네, 다만 한계는 분명합니다. expo-dev-client for Deployment는 development build의 내부 배포, 특히 QA나 브랜치 테스트를 위한 TestFlight 배포로 이해하는 것이 가장 정확합니다. 이것이 전체 프로덕션 릴리스 계획을 대체하는 것은 아닙니다.

expo-dev-client 스킬을 더 잘 활용하는 방법

현재 프로젝트 상태를 처음부터 구체적으로 주세요

expo-dev-client 스킬에서 더 정확한 답을 얻으려면 다음을 함께 제공하세요:

• 현재 eas.json
• 대상 기기와 플랫폼
• 로컬 전용인지 TestFlight용인지
• 어떤 네이티브 모듈이나 타깃 때문에 변경이 필요해졌는지
• Expo Go를 이미 시도해봤는지 여부

이 정보가 있으면 에이전트가 일반론에서 머무르지 않고, 정확한 수정안과 실행 명령까지 제시하기 쉬워집니다.

단계 요청 전에 먼저 판단을 요청하세요

좋은 프롬프트는 이렇게 시작합니다:

First determine whether this app truly needs expo-dev-client.

이 한 줄만으로도 출력 품질이 좋아집니다. 이 스킬의 가장 큰 가치는 불필요한 dev-client 설정을 막는 데 있기 때문입니다.

검토할 설정 조각을 함께 넣으세요

기존 eas.json을 붙여주면, 에이전트는 다음을 더 정확히 할 수 있습니다:

• 빠진 developmentClient: true 감지
• 버전 관리 설정 수정 제안
• submit / build profile 정렬
• 필요하지도 않은 설정을 지어내지 않기

아무 정보 없이 처음부터 물어보는 것보다 훨씬 낫습니다.

배포 의도를 명확히 적으세요

올바른 명령은 다음 중 무엇을 원하는지에 따라 달라집니다:

• 로컬 development build
• 기기 설치용 cloud build
• TestFlight 제출까지 포함한 iOS build

이걸 명시하지 않으면, 첫 답변이 기술적으로는 맞아도 팀 운영 관점에서는 틀린 제안이 될 수 있습니다.

가장 흔한 실패 패턴을 경계하세요

가장 흔한 실패는 사실 Expo Go에 남아 있어야 할 앱에 expo-dev-client를 적용하는 것입니다. 두 번째는 EAS 설정 정보를 너무 적게 주고, 그 결과 나온 모호한 답변을 스킬 탓으로 돌리는 경우입니다. 두 경우 모두 네이티브 요구사항과 현재 설정을 함께 제시하면 충분히 예방할 수 있습니다.

첫 답변 뒤에는 후속 질문으로 좁혀가세요

첫 응답 이후에는 이런 식의 후속 질문이 좋습니다:

• “이 eas.json이 dev-client TestFlight 워크플로우에 맞는지 검증해줘.”
• “Android 전용으로 빌드 명령만 다시 써줘.”
• “앱에 widget extension이 있다고 가정하면 판단이 어떻게 달라져?”
• “가장 작은 동작 가능한 development profile만 남기도록 최소화해줘.”

이렇게 해야 expo-dev-client skill이 일반 설명에서 끝나지 않고, 실제 프로젝트 실행 단계로 내려옵니다.

팀 공용 프롬프트를 만들어 도입 마찰을 줄이세요

여러 개발자가 이 스킬을 쓴다면, 다음과 같은 재사용 가능한 내부 프롬프트 템플릿을 만들어 두는 것이 좋습니다:

Use expo-dev-client to assess whether this Expo app requires a development client. Here is our eas.json, target platform, distribution goal, and native dependency list. Return: 1) decision, 2) config changes, 3) exact commands, 4) likely blockers.

이렇게 하면 결과물의 일관성이 높아지고, 새 팀원이 적응하는 데 드는 비용도 줄어듭니다.

레시피가 아니라 게이트로 사용하세요

expo-dev-client usage를 개선하는 가장 좋은 방법은, 이 스킬을 빌드 전에 거치는 의사결정 게이트로 쓰는 것입니다. 팀이 이미 dev client 도입을 전제로 한 뒤에야 이 스킬을 사용한다면, 가장 큰 장점인 불필요한 네이티브 빌드 워크플로우 오버헤드를 미리 막는 기능을 놓치게 됩니다.