앱인토스 실기기 테스트 — 폰 직결로 헤매다 ait deploy 로 풀었다

⚠️ 이 글은 처음엔 미해결이었다가 나중에 풀린 기록이다. 폰을 직접 연결하는 방식으로 삽질하다 실패했고, 한참 뒤에야 방법 자체가 틀렸다는 걸 알았다. 실패한 과정과 진짜 해결법(ait deploy)을 순서대로 남긴다.

8월 바이브코딩 챌린지를 시작했다. 앞으로의 실기기 테스트를 위해 맥북과 갤럭시 플립4를 연결했다.

앱이 안 뜬다 — “앱 실행도중 문제가 발생했습니다”

앱을 폰에서 실행하자, 이 창만 뜨고 실패했다.

“앱 실행도중 문제가 발생했습니다. 앱인토스 개발자 커뮤니티로 문의해주세요.” — 딱 여기까지고, 왜인지는 안 알려준다.

시도한 것들 — 다 실패

• 같은 와이파이 환경으로 맞춰서 다시 해봤다. → 실패
• 로그를 뜯어보고 tcp 관련 설정을 바꿔봤다. → 실패
• 앱인토스 개발자 커뮤니티에서 비슷한 사례를 찾아봤다. → 같은 증상의 질문 글만 있고, 해결책 답변은 없었다.

이 시점까지는 완전히 막혀 있었다. 그런데 문제는 이 오류 자체가 아니라, 내가 접근한 방식이 틀렸다는 데 있었다. (그건 나중에 알았다.)

놀란 것 — 클로드가 폰 화면을 보고 앱을 조종한다

막혀 있는 동안, 디버깅 과정에서 놀란 게 있었다. 폰을 연결해두니 클로드가 폰 화면을 직접 보고 앱을 조종하며 디버깅했다.

크래시 스택을 수집하고, “로그만으로는 부족하다”며 폰 화면을 직접 캡처해서 보고, 앱을 껐다 켰다 하며 예외를 좁혀갔다. GraniteActivity가 뜨자마자 파괴됐다는 것, appsInTossSignTossCert라는 이름이 스택에 보인다는 것까지 짚었다. 그런데도 못 풀었는데 — 애초에 폰에 직접 앱을 띄우는 것 자체가 앱인토스가 의도한 테스트 방식이 아니었기 때문이다.

해결 — 방법 자체가 틀렸다

정답은 삽질하던 방향이 아니라, 개발 환경에서 배포 명령 한 줄을 실행하는 것이었다.

npx ait deploy --api-key <발급받은_키>

API 키는 앱인토스 워크스페이스에서 발급받는다. <발급받은_키> 자리에 그 키를 넣어 실행한다.

🔴 API 키는 절대 공개 저장소·스크린샷·커밋에 노출하지 말 것. 유출되면 즉시 재발급(rotate).

deploy가 성공하면 번들이 하나 만들어진다.

이제 이 번들의 [테스트] 버튼을 누르고 푸시를 보내면 실기기에서 실행된다. 폰에 직접 띄우려 며칠 삽질한 게 무색하게, 정해진 배포 흐름을 타니 그냥 됐다.

AI 시대에 남는 것 — 경험과 문제 정의

결국 답은 명령어 한 줄이었다. 며칠 헤맨 게 딱 “경험 부족”의 값이었다 — 아는 사람은 5분이면 갔을 길이었다. 이 삽질을 하면서 확실해진 생각이 있다. AI가 이렇게까지 하는 시대에, 사람에게 남는 값어치는 경험과 문제를 정의하는 능력 두 가지 같다. (지난 글에서 “AI가 준 걸 그대로 받지 않고 고르는 감각”을 말했는데, 그 연장선이다.)

경험

막힌 걸 푸는 것 자체는 LLM이 충분히 한다. 문제는 엉뚱한 방향으로 시간이 소모된다는 점이다. 오늘이 딱 그랬다 — 클로드가 로그도 뜯고 폰도 보고 별짓을 다 했지만, 애초에 접근 자체가 틀렸으니 아무리 파도 안 풀렸다. “폰에 직접 띄운다”가 아니라 “배포해서 테스트 푸시를 보낸다”라는 걸 경험적으로 아는 사람은 이 며칠을 통째로 건너뛴다.

LLM은 처음부터 가장 좋은 방법을 고르기보다 눈앞의 증상을 풀려 든다. 그래서 “이 상황엔 접근을 바꿔야 한다”는 판단은 여전히 사람 몫이었다.

문제를 정의하는 능력

똑같은 문제를 만나도, 표면 증상만 서술하는 사람과 접근 자체를 의심하는 사람은 다르다. “앱이 안 켜져요”에 갇히면 크래시 로그만 며칠 판다. “혹시 테스트하는 방법 자체가 틀린 거 아닐까?”까지 가면 공식 배포 흐름을 찾아본다. 후자가 LLM에게 지시를 더 정확히 주고, 비슷한 상황에서 접근을 바꿔볼 근육이 길러진다.

결국 AI가 실행을 대신 해줄수록, 뭘 시킬지 — 그리고 애초에 방향이 맞는지 — 를 정하는 쪽의 값어치가 올라간다.

더 파볼 것

• 왜 폰 직결이 크래시났나 — 목표(실기기 테스트)는 ait deploy로 우회했지만, 폰에 직접 띄웠을 때 GraniteActivity가 즉시 파괴된 원인 자체는 여전히 모른다. appsInTossSignTossCert(인증서 서명 단계로 짐작)와 엮여 있는지 확인 필요. (짐작이라 검증해야 함.)
• ait CLI가 실제로 뭘 하나 — ait deploy가 번들을 만들어 올리는 과정. SDK 버전(3.0.1)·번들 버전 규칙, 검토 요청과 테스트 푸시의 차이.
• 테스트 푸시가 실기기에 어떻게 도달하나 — [테스트] 버튼 → 푸시 → 폰 실행의 경로. 이게 되는데 폰 직결이 안 됐던 이유와도 연결.
• API 키 관리 — 워크스페이스 발급 키의 권한 범위와 만료, 재발급. CI에서 쓸 때 환경변수로 어떻게 넣는지.