AI로 만든 첫 Mac 앱, 앱스토어 심사에서 무엇이 드러났을까요

핵심 요약 (TL;DR)

PCMag의 Edward Mendelson은 9월 5일 Claude Code와 Xcode로 KeyRun이라는 무료 Mac 앱을 만들어 앱스토어에 공개한 과정을 소개했습니다. 앱·문서·폴더를 단축키로 여는 작은 불편에서 출발했고, AI는 구현뿐 아니라 제출 과정도 안내했습니다. 그러나 첫 심사에서는 일반 알파벳 키 조합을 막지 못해 거절됐습니다. 수정 뒤 승인을 받았다는 결말은 초보자에게 중요한 기준을 보여 줍니다. AI가 빠르게 만든 첫 화면보다 실제 플랫폼의 심사와 사용자 행동이 제품을 완성합니다.

첫 앱은 왜 작은 불편에서 시작하는 편이 좋을까요?

KeyRun의 목표는 거대한 생산성 도구가 아니었습니다. 원하는 앱이나 문서를 키 조합 하나로 여는 기능이 중심이었습니다. 무엇을 해결할지 한 문장으로 말할 수 있었기 때문에 Claude에게도 드래그한 앱을 등록하고, 시스템 단축키와 충돌을 확인하며, 설정을 저장하는 식으로 다음 행동을 구체적으로 요청할 수 있었습니다.

바이브코딩을 처음 시작한다면 기능 개수보다 반복해서 겪는 불편 하나를 고르세요. ‘업무 앱을 만들어 주세요’보다 ‘매일 여는 폴더 세 개를 단축키로 불러오고 싶어요’가 검증하기 쉽습니다. 정상 동작뿐 아니라 파일이 삭제됐을 때, 같은 키가 이미 쓰일 때, 설정을 다른 기기로 옮길 때를 차례로 물으면 예외 상황도 제품의 일부가 됩니다.

AI의 빠른 해결이 언제 기술 부채가 될까요?

제작 과정에서 접근성 권한을 요구하는 문제가 생기자 Claude는 오래된 Carbon 프레임워크를 이용하는 방식으로 바꿨습니다. 현재 배포에는 도움이 됐지만 Carbon은 Apple이 폐기 예정으로 표시한 기술입니다. 지금 작동하는 해결책과 앞으로 유지하기 좋은 선택이 항상 같지는 않다는 뜻입니다.

이럴 때는 AI에게 ‘되나요?’만 묻지 말고 공식 문서 상태, 대안, 다음 운영체제에서 깨질 가능성을 함께 정리하게 해야 합니다. 임시 선택을 했다면 코드 근처와 프로젝트 메모에 이유를 남기세요. 빠른 우회가 나쁜 것은 아닙니다. 우회라는 사실을 잊는 순간부터 문제가 됩니다.

앱스토어 거절은 왜 실패가 아니라 테스트일까요?

KeyRun의 첫 제출은 사용자가 Shift-C 같은 평범한 입력 조합을 등록할 수 있다는 이유로 거절됐습니다. Claude는 시스템 전역 단축키 충돌을 고려했지만, 사람이 글자를 입력하는 기본 동작까지 충분히 막지 못했습니다. 제작자는 두 개 이상의 보조키나 기능키를 요구하도록 수정했고, 다시 제출해 승인을 받았습니다.

여기서 가져올 실무 순서는 단순합니다. 먼저 개인 컴퓨터에서 핵심 흐름을 시험하고, 다음으로 빈 값과 충돌 입력을 넣고, 마지막으로 플랫폼 심사 기준과 권한 문구를 확인하세요. 심사 결과는 AI의 점수가 아니라 사용자가 만날 경계 조건을 찾아 주는 외부 테스트입니다.

FAQ: 코드를 모르면 앱스토어 출시까지 맡겨도 될까요?

안내와 초안은 맡길 수 있지만 개발자 계정, 권한, 개인정보, 심사 답변은 직접 확인해야 합니다. 실제 제출 전에는 앱이 요청하는 시스템 권한과 저장하는 데이터를 설명할 수 있어야 합니다.

FAQ: 첫 앱에 기능을 어디까지 넣어야 할까요?

한 사람이 한 가지 불편을 끝낼 수 있는 범위면 충분합니다. 새 기능은 핵심 흐름을 세 번 안정적으로 끝낸 뒤 추가하는 편이 좋습니다.

FAQ: 심사에 통과하면 품질이 보장되나요?

아닙니다. 심사는 배포의 한 관문입니다. 출시 뒤에도 오류 보고, 운영체제 업데이트, 삭제된 파일 같은 실제 조건을 계속 확인해야 합니다.

사례 원문: https://www.pcmag.com/explainers/i-vibe-coded-the-one-mac-feature-apple-refuses-to-build-and-put-it-on-the
앱 확인: https://apps.apple.com/us/app/keyrun/id6788949614?mt=12
관찰 시점: 2026-09-06 07:02 KST