코딩 에이전트로 앱을 스토어 제출 준비 상태로 만들기

시작하기 전에

Claude Code와 AppFoyer 계정이 필요합니다. 무료 플랜으로 충분합니다: 계정 만들기. 만들어야 할 키는 없습니다. 에이전트가 처음 연결할 때 브라우저에서 승인해 달라고 요청합니다.

코딩 에이전트가 아예 없나요? 브라우저의 입력란 여섯 개로 플러그인 없이 같은 다섯 페이지를 얻을 수 있습니다.

Claude Code를 쓰지 않나요? 플러그인에는 Claude Code가 필요하지만, 개인정보처리방침과 이용약관 페이지에는 필요하지 않습니다. 대시보드의 두 편집기에는 앱 정보가 채워진 프롬프트가 있으며, 어떤 어시스턴트에서든 실행하고 결과를 붙여 넣으면 됩니다. 전문은 개인정보처리방침 가이드와 이용약관 가이드에 실려 있습니다.

설치

claude
/plugin marketplace add appfoyer/claude-plugin
/plugin install appfoyer@appfoyer

시작할 때 계정은 필요 없습니다. 에이전트는 개발자의 컴퓨터에서 빌드를 읽고, 찾은 내용을 보여 주고, 질문을 한 뒤, 저장할 것이 생겼을 때 비로소 연결을 요청합니다. 처음 AppFoyer를 호출하면 브라우저에 승인 페이지가 열립니다. 로그인하거나 무료 계정을 만들고, 이름과 브라우저가 돌아갈 곳을 확인한 뒤 승인하세요. Claude Code가 연결을 유지하고 스스로 갱신합니다. 아무것도 복사하지 않으며, 셸에 아무것도 저장되지 않습니다. 브라우저가 열리지 않으면 /mcp를 실행하고 appfoyer를 고른 뒤 Authenticate를 선택하세요. Claude Code 데스크톱 앱에서는 터미널에서 이 방법으로 한 번 연결한 뒤 그곳에서 새 세션을 시작하세요. 이미 실행 중이던 세션은 새 연결을 인식하지 못합니다. 대시보드의 Agent 페이지에서 연결을 해제하면 다음 호출은 즉시 실패합니다. Claude Code는 서드파티 마켓플레이스를 스스로 새로 고치지 않습니다. 새 버전을 받으려면 /plugin → Marketplaces → appfoyer에서 Enable auto-update를 선택하세요.

그 컴퓨터에 브라우저가 없나요? 원격 서버, 컨테이너, 스크립트 실행이라면 대신 API 키를 쓰세요. Agent → API key — for CI and headless use에서 키를 만들고, 워크플로를 위해 위와 같이 플러그인을 설치한 뒤, 헤더에 키를 넣어 서버를 한 번 더 추가하세요:

export APPFOYER_API_KEY=cpk_…
claude mcp add --transport http appfoyer-key https://app.appfoyer.com/mcp --header "Authorization: Bearer $APPFOYER_API_KEY"

플러그인은 그 환경 변수에서만 키를 읽습니다. 스킬은 키를 보지 못하며, 키는 Claude Code가 채우는 Authorization 헤더에만 실려 전송됩니다.

다른 MCP 클라이언트(claude.ai, Claude Desktop, Cursor, VS Code)도 같은 방식으로, 같은 승인 페이지를 거쳐 https://app.appfoyer.com/mcp에 연결할 수 있습니다. 도구는 그대로 쓸 수 있지만, 빌드 파일을 읽는 단계별 워크플로는 Claude Code 플러그인에 들어 있습니다.

무엇이라고 말하나

빈 디렉터리가 아니라 앱의 저장소 안에서 실행하세요:

예시

자신의 말로 하면 됩니다. 아래는 스킬이 처리하는 경우들입니다.

앱 하나, 첫 실행

> Make this app store-ready

• 빌드 파일에서 찾은 것(SDK, 권한, 번들 ID)을 각각 파일과 줄 번호와 함께 나열합니다.
• 찾지 못한 것만 묻습니다: 회사 이름, 지원 이메일, 관할 지역, 스토어 링크. 최대 두 차례입니다.
• 앱을 만들고, 저장소에서 아이콘을 업로드하고, 다섯 페이지 전부의 초안을 작성합니다.
• 검토 링크로 끝납니다. 그곳에서 게시하기 전까지는 아무것도 공개되지 않습니다.

변경 후 다시 실행

> Make this app store-ready

• 애플리케이션 ID로 기존 앱을 찾고, 새 사실을 저장된 사실과 비교합니다.
• 변경의 영향을 받는 페이지만 다시 작성합니다. 예를 들어 새 분석 SDK가 추가되면 개인정보처리방침을 다시 씁니다.
• 요청하지 않는 한 아이콘과 주소는 그대로 둡니다.

여러 flavor, 프롬프트에서 지정

> Make com.acme.weather.free and com.acme.weather.pro store-ready

• 앱 두 개를 만들고, 선택에 대해서는 아무것도 묻지 않습니다.
• 각 flavor 자체의 폴더, 이름, 의존성을 읽습니다. free flavor에서만 쓰는 광고 SDK는 pro flavor의 개인정보처리방침에 들어가지 않습니다.
• flavor마다 검토 링크와 콘솔 URL 표를 돌려줍니다.

여러 flavor, 지정하지 않음

> Make this app store-ready

• flavor를 애플리케이션 ID와 함께 모두 선택된 상태로 나열하며, 어떤 flavor에 사이트를 만들지 개발자가 고릅니다.
• debug, staging 같은 빌드 유형은 제안되지 않고 제외 항목으로 나열됩니다.

브랜드 × 환경 차원

> Make every brand store-ready

• 단일 flavor가 아니라 조합(brandAProd, brandBProd)을 나열합니다.
• 프로덕션 환경만 제안합니다. dev와 qa는 스토어에 출시되지 않습니다.
• 빌드가 앱 이름을 Gradle(resValue, manifestPlaceholders)이나 옮겨진 소스 세트에 두는 경우 그곳에서 읽습니다.
• 차원이 환경인지 브랜드인지 판단할 수 없으면 묻습니다.

맞춤 주소(Pro와 Advanced)

> Make this app store-ready

• 앱의 영어 이름으로 주소를 만듭니다. 예: weather-now.
• 그 주소가 이미 사용 중이거나 브랜드 이름과 너무 비슷하면 다음 후보(weather-now-app, acme-weather)를 시도하며, 최대 다섯 번까지 시도한 뒤 개발자에게 묻습니다.
• 무료 플랜에서는 app-… 주소를 유지하고, 맞춤 주소는 Pro에서 제공된다고 알려 줍니다.
• app-… 주소는 같은 사이트를 계속 제공합니다.

이미 쓰고 있는 주소 바꾸기

> Change the address to weather-radar

• 먼저 묻습니다. 이전 맞춤 주소는 즉시 해제되며, 아직 그 주소를 적어 둔 스토어 등록정보는 동작하지 않게 됩니다.
• 개발자가 동의한 뒤에만 바꿉니다.

아이콘 업데이트

> Update the app icon

• 런처 아이콘을 찾습니다: Play 512 아이콘, 가장 큰 mipmap 이미지, 또는 iOS AppIcon 마케팅 이미지. flavor 자체의 아이콘을 먼저 찾습니다.
• 512 KB를 넘으면 임시 폴더에서 사본을 줄입니다. 저장소는 건드리지 않습니다.
• 어떤 파일을 업로드했는지 알려 줍니다. 게시된 앱에서는 새 아이콘이 즉시 적용됩니다.

광고가 있는 앱

> Make this app store-ready. AdMob publisher id pub-0000000000000000

• 개발자가 준 줄로 app-ads.txt를 작성합니다. 퍼블리셔 ID는 코드에 없으므로 절대 추측하지 않습니다.
• 스토어 등록정보의 개발자 웹사이트에 사이트를 설정하라고 알려 줍니다.
• AdMob은 저희 주소의 app-ads.txt 파일을 확인(verify)했습니다. 크롤링에 최대 24시간을 기다리세요.

페이지를 빌드와 동기화하기

> Add the AppFoyer drift check

• “make this app store-ready”를 실행할 때마다 저장소 루트에 appfoyer.json을 씁니다. 페이지를 작성할 때 바탕이 된 SDK, 데이터 유형, 권한의 기록입니다. 검사가 실행하는 것과 같은 스캐너가 쓰며, 손으로 쓰는 일은 없습니다.
• 이 프롬프트는 무료 appfoyer/check-action을 위한 GitHub 워크플로를 보여 주고, 개발자가 동의하면 .github/workflows/appfoyer.yml을 씁니다. 이미 있는 파일은 절대 덮어쓰지 않습니다.
• 그때부터 모든 풀 리퀘스트는 페이지 작성 이후 추가되거나 제거된 것을 파일과 줄 번호와 함께 나열합니다. 플러그인을 다시 실행하면 초안과 appfoyer.json이 업데이트됩니다.
• 개발자 대신 커밋하는 것은 없습니다. 개인정보처리방침을 빌드와 동기화하는 가이드에 자세한 내용과 다른 CI 시스템용 설정이 있습니다.

아무것도 바꾸지 않고 점검하기

> Is this app store-ready?

• 일치하는 각 앱에 대해 체크리스트를 실행하고 무엇이 빠졌는지 보고합니다. 아무것도 쓰지 않습니다.
• 아직 앱이 없는 flavor는 누락으로 보고됩니다.

링크를 앱에 넣기

> Wire the store-ready links into the app

• 게시된 페이지가 필요합니다.
• 설정 화면이나 문자열 리소스에 넣을 개인정보처리방침 및 지원 링크를 diff로 제안합니다. 개발자가 동의할 때만 적용하며, 커밋은 절대 하지 않습니다.

개발자의 컴퓨터 밖으로 나가는 것

도출된 사실만 나갑니다:

• 앱의 이름, 플랫폼, 번들 ID 또는 애플리케이션 ID
• 빌드 파일에서 찾은 SDK와 권한의 이름
• 개발자가 확인한 답변: 회사 이름, 지원 이메일, 관할 지역, 스토어 URL
• 에이전트가 작성한 페이지 텍스트(계정에 초안으로 저장됨)
• 앱 자체의 아이콘(일회용 업로드 링크로 한 번 전송)

그 밖의 파일은 보내지 않으며, 소스 코드나 저장소에서 발견된 시크릿과 키는 절대 보내지 않습니다. 에이전트가 보내는 것은 어차피 개인정보처리방침에 적어야 하는 내용입니다.

저장소 안에 파일 하나가 쓰이며 그대로 남습니다. 바로 appfoyer.json으로, 페이지를 작성할 때 바탕이 된 내용의 기록이며 플러그인에 포함된 스캐너가 만듭니다. 어디에도 전송되지 않습니다. 에이전트는 이 파일도, 다른 어떤 것도 커밋하지 않습니다. 커밋은 개발자가 합니다.

에이전트가 할 수 없는 것

브라우저로 연결하든 API 키로 연결하든, 플러그인이 가진 것은 에이전트 자격 증명입니다. 그래서 게시 기능은 아예 쓸 수 없습니다. 이는 에이전트에게 정중히 부탁하는 방식이 아니라 서버에서 강제됩니다:

• 게시 도구가 없습니다. 에이전트는 초안을 씁니다. 게시 중인 페이지는 바뀌지 않습니다.
• 초안이 없는 것이 두 가지 있습니다: 아이콘과 맞춤 주소. 게시된 앱에서는 이 둘이 게시 중인 사이트를 즉시 바꾸며, 에이전트는 이를 설정했을 때 알려 줍니다. 이미 쓰고 있는 맞춤 주소는 개발자의 동의 없이 바꿀 수 없습니다.
• 페이지를 게시하는 REST 경로는 에이전트 자격 증명을 아예 거부합니다. 세션 전용입니다.
• 모든 페이지는 게시할 때 손으로 쓴 편집과 똑같은 콘텐츠 심사를 거칩니다.
• 모든 에이전트 호출은 그 호출을 한 연결 또는 키와 함께 계정의 감사 로그에 기록됩니다.

따라서 연결이나 키가 탈취되었을 때 최악의 경우는 버려야 할 초안, 잘못된 아이콘, 새 주소입니다. 개발자의 이름으로 페이지가 공개되는 일은 아닙니다.

에이전트가 쓰는 도구

플러그인은 정확히 다음 도구만 제공하는 MCP 엔드포인트에 연결합니다:

문제가 생겼을 때

이것으로 바뀌지 않는 한 가지

초안은 코드를 바탕으로 완성한 템플릿이며, 법률 자문이 아닙니다. 에이전트가 빨리 썼다고 해서 내용이 사실이 되는 것은 아닙니다. 게시하기 전에, 특히 앱이 수집하는 항목 목록을 꼭 읽어 보세요. 스토어가 책임을 묻는 사람은 개발자입니다.

문의: support@appfoyer.com.