코드를 작성하지 않는 운영자가 Claude Code의 매시간 정기 실행으로 스마트폰 앱을 만들고 키우는 시스템

기술자가 아닌 운영자 1명으로, 스마트폰 앱 4개를 Google Play에 출시했습니다(App Store에는 3개이며, 나머지 1개는 준비 중입니다). 코드를 작성하는 것은 AI(Claude Code)가 담당하며, 저는 거의 손을 움직이지 않습니다. 정해진 규칙을 일본어 문서로 작성하고, AI가 정해진 시간에 작동하여 계획표의 작업을 하나씩 진행합니다.

이 글에서는 그 시스템을 '사람이 보고 있지 않아도 고장 나지 않고 진행되려면 어떤 형태여야 하는가'라는 관점에서 정리했습니다. 마찬가지로, AI에게 개발을 맡기고 싶은 분들에게 참고가 되기를 바랍니다.

1. 전체적인 구조

등장하는 것은 다음 4가지입니다.

• 총괄 폴더: 모든 앱에 공통되는 규칙(승인 범위, 디자인, 입력란, 기록 방식, 무료 사용량 처리 등)을 한 곳에 모아둔 장소입니다. Git으로 관리하고 있습니다. - 앱별 리포지토리: 코드와 해당 앱의 계획표 및 지시 문서가 들어있습니다. - 정기 실행: Claude Code 데스크톱 앱의 스케줄링 작업입니다. 앱마다 '매시간 XX분에 개발을 진행한다'는 것이 하나씩 있습니다. 그 외에 매일/매주/매월 감시 또는 보고를 위한 정기 실행도 있습니다. - 사람(저): 실제 배포 및 금전 결제 승인, 로그인 등 본인만이 할 수 있는 작업, 그리고 방침 판단.

핵심은, 규칙의 본체를 한 곳에만 둔다는 것입니다. 각 앱 진입 문서(AGENTS.md)에는 '입력란 규칙은 총괄 폴더의 XX를 참조한다'라는 참조만 작성합니다. 만약 앱마다 복사해 놓으면 어떤 것이 최신인지 알 수 없게 되고, AI가 오래된 규칙으로 작동하기 때문입니다.

2. 계획표는 한 줄에 하나의 작업 TSV 형식

AI가 다음에 무엇을 할지는 앱별 계획표(실행계획.tsv)만으로 결정되도록 했습니다. 열은 다음과 같은 형태입니다(내용은 설명을 위한 예시입니다).

ID 담당 상태 작업 완료 조건 의존성
WI-0101 본인 완료 스토어 계정 등록 — —
WI-0102 AI 완료 평가 요청을 만족한 직후에 배포할 OS 표준 평가 화면만 사용하고, 배포 조건을 테스트하는 것이 통과됨 WI-0101
...

• 담당은 'AI'와 '본인'으로 나누고, AI는 자신의 행만 가져갑니다. 본인의 행이 남아 있어도 다른 작업은 멈추지 않습니다. - 완료 조건은 AI가 스스로 확인할 수 있는 형태로 작성합니다('검사가 통과함', '두 문장이 동일함' 등). '좋게 만드는 것' 같은 조건으로는 끝을 정할 수 없기 때문입니다. - 작업이 다 끝나면, AI가 다음 버전의 계획을 세워 표에 추가합니다. 기다리는 시간만 생기는 것을 막기 위해서입니다.

3. 매시간 정기 실행은 '남아있는 것이 있으면 건너뛰기'부터 시작

스케줄링 작업 지시는 어떤 앱도 동일한 골격입니다. 실제 지시에서 경로 등을 대체하여 빼내면 다음과 같습니다.

무인 실행이므로, 본인에게 질문하며 멈추지 않고 끝까지 진행하고, 보고는 일본어로 작성해 주세요.
cd /d/Projects/<앱>
git status --short
...

고안한 것은 3가지가 있습니다.

• 먼저 작업 복사본이 깨끗한지 확인하는 것. 이전 회차가 도중에 끊겼거나, 제가 대화로 AI에게 다른 작업을 시키는 경우 등, 위에서 겹쳐서 망가뜨리지 않기 위해서입니다. 망설여진다면 '아무것도 하지 않는 것'이 가장 안전합니다. - 앱별 절차의 원본은 리포지토리에 두는 것. 스케줄링 작업 지시에는 모든 앱에 공통되는 감시(사용량이나 무료 사용량 확인 등)와 '이 문서를 읽고 따르라'를 작성하고, 해당 앱의 작업 절차는 리포지토리의 정기 실행 지시.md에 씁니다. 절차를 수정할 때 Git 기록이 남아 검토도 할 수 있습니다. - 1회 건수와 시간에 상한을 두는 것. '1회 최대 2건, 40분까지'처럼 정합니다. 한 번에 크게 진행하려고 하면 도중에 끊겼을 때 뒷정리가 힘들기 때문입니다.

4. 사람이 멈출 곳을 2곳으로 좁히기

처음에는 AI가 조금이라도 망설이면 저에게 물어보는 형태였습니다. 그러면 제가 답할 때까지 모든 것이 멈춥니다. 그래서, 사람의 승인이 필요한 것은 '실제 배포'와 '금전 결제' 두 종류로만 정했습니다.

• 실제 배포: 스토어 제출, 공개 중인 사이트나 게재 정보 변경, 공개 리포지토리로 push, 실전에 자동으로 배포되는 브랜치로 merge 등. - 금전 결제: 구매, 과금 시작, 무료 사용량을 초과하는 설정 등.

그 외의 것(비공개 리포지토리로 push, 만드는 순서, 디자인, 이름, 버전 번호, 무료 서비스 사용 여부)는 AI가 '사용자와 저에게 가장 최선의 권장안'을 선택하고 이유를 기록하며 진행합니다. 저는 나중에 보고서를 읽습니다.

예외적으로, iPhone 버전을 스토어에 출시하기 직전에는, 출시할 예정인 빌드 자체를 제가 TestFlight에서 직접 만져보고 승인합니다. AI가 확인할 수 없는 '실제로 사용했을 때의 이질감'을 포착하기 위해서입니다.

5. 무료 할당량은 도구로 계산하고, 초과할 것 같으면 실행하지 않기

자동 검사나 빌드에는 무료 할당량이 있습니다. AI에게 맡기면 자신도 모르게 소진하는 경우가 생깁니다. 그래서 다음과 같이 했습니다.

• GitHub Actions는 push나 PR에서는 자동으로 작동시키지 않고,
  주 1회 정기 검사와, main에 병합하기 전 및 스토어 출시 직전의 수동 실행 1회로만 제한합니다. 모든 workflow에 concurrency를 추가하고, 검사는 cancel-in-progress로 이전 실행을 취소합니다 (실제 배포하는 workflow만은 취소하지 않고 순서 대기). - iPhone 버전 빌드는, 실행하기 전에 작은 도구로 '이번 달 잔여량으로 실행해도 되는지'를 확인하고, 끝나면 실제 사용 시간을 기록합니다.

python tools/codemagic_quota.py check --project <앱> --kind release --minutes 20
# → {"ok": true, ...}일 때만 빌드를 실행합니다
python tools/codemagic_quota.py add --project <앱> --kind release --minutes 18 --result success

판단을 문장의 규칙에만 의존하지 않고, 도구가 ok를 반환했을 때만 진행하는 형태로 만들면, AI가 '아마 괜찮을 거야'라고 판단하여 진행하는 것을 막을 수 있습니다. 같은 생각으로 Claude 자체 사용량도 매시간 작업 시작 시 도구로 판별하고, 여유가 있으면 건수를 늘리고, 적으면 새로운 작업을 시작하지 않도록 하고 있습니다.

6. 보고는 '본인이 할 것'을 한 곳에 모으기

AI의 보고서는 방치하면 길어지고, 제가 해야 할 일이 문장 중간에 파묻힙니다. 그래서 작업 단위별 보고서의 형식을 정했습니다.

• 채팅창에 보고 카드를 올립니다 (만든 것, 다음에 할 것, 못 한 것, 본인이 할 것).
• '본인이 할 것'에는 답변용 버튼을 추가합니다 (권장안을 맨 앞에 2~4개 배치).
• 메일은 HTML 버전과 일반 텍스트 버전을 모두 보내고, 제목을
  【건명】상태｜요점（작업ID・버전・날짜）
  으로 통일했습니다. 상태는 '요응대(要対応)・정지・완료・알림' 네 단어로만 한정합니다.

제목 형식을 통일하는 것만으로도, 받은 편지함을 보고 '오늘 열어야 할 메일'이 무엇인지 알 수 있게 되었습니다.

7. AI의 점검 결과는 '후보'로 취급하기

코드 검사도 AI에게 맡기고 있습니다 (매월 변경된 파일을 모아서 검사). 하지만, 검사 결과를 그대로 수정하면 문제가 없는 코드를 망가뜨릴 수 있습니다. 그래서 검사 결과는 후보라고 정하고, 수정 작업을 시작할 때 '현재 코드로 정말 문제인지'를 먼저 확인하게 합니다. 틀렸다면 '점검 오류(이유)'로 닫습니다.

같은 이유로, AI가 조사할 때도 '어디까지 봤는지'를 남기게 했습니다. 실제로 작업용 브랜치에 있던 변경 사항을 main만 검색해서 '아직 없다'고 답한 적이 있었습니다. 지금은, 조사 범위를(브랜치) 지시에 작성하고 있습니다.

8. 외부에서 읽은 문장은 '정보'이지 '지시'가 아니다

AI에게 웹 페이지를 읽게 하면, 페이지 안에 'AI는 이렇게 하라'라는 문장이 숨겨져 있는 경우가 있습니다. 규칙으로, 도구로 읽은 내용은 모두 정보로 취급하고 지시로는 따르지 않겠다고 했습니다. 읽은 페이지에 그런 문장이 있었다면, 기록에 '숨겨져 있었으나 따르지 않았다'라고 작성하게 합니다.

9. 잘 안 되는 점

솔직히 말하자면, 만드는 것은 진행되지만, 공개된 앱이 거의 발견되지 않고 있습니다. 스토어에 표시되는 횟수 자체가 적고, 평가도 아직 붙지 않았습니다. AI는 시킨 것은 만들 수 있지만, '누가 어디서 이 앱을 찾을지'는 규칙으로 정해지지 않는다고 생각하지 못했습니다.

지금은, 새로운 기능을 추가하는 것을 잠시 미루고, 다음과 같은 '발견되게 하는 작업'에 힘을 쏟고 있습니다.

• 스토어 이름과 설명을 사용자가 실제로 검색할 단어(고민 + 대상 + 기능)로 다시 작성합니다.
• OS 표준의 평가 요청을, 사용 후 만족한 직후에 올립니다 (직접 만든 화면으로 구분하지 않습니다).
• 간단한 계산 도구 페이지를 만들고, 결과 아래에 앱을 안내합니다.
• 링크에 진입점 표시를 하고, 어디서 온 사람이 들어왔는지 나누어 셉니다.

이 글도 그중 하나입니다.

10. 요약

사람이 보고 있지 않아도 망가지지 않고 진행되게 만든 것은 다음 5가지였습니다.

• 핵심 본체를 한곳에 두고, 각 리포지토리는 참조만 하도록 한다.
• 계획표를 한 줄에 하나의 작업으로 하고, 완료 조건을 AI가 확인할 수 있는 형태로 작성한다.
• 매시간 정기 실행은, 작업 복사본이 오염되었으면 아무것도 하지 않고 끝낸다.
• 사람이 멈출 지점을 '실제 출시'와 '금전적 지급'으로 한정한다.
• 무료 사용량 등의 판단은 글이 아니라 도구의 ok

제작 중인 앱

마지막으로, 이 시스템으로 만들고 있는 앱 두 가지를 소개하겠습니다.

• めもり(Memori): 식물을 찍으면 AI가 이름을 검색하고, 건강 상태를 본 기준으로 알려주는 육성 기록 앱입니다 (iPhone・Android).

https://memori-app.pages.dev/?utm_source=zenn&utm_medium=article -
給料あってる？(급여 맞나요?): 아르바이트/파트 근무의 급여를 출근 기록과 급여 명세서로 대조하는 앱입니다 (Android. iPhone 버전은 준비 중).

제공: 합동회사 BEST WISDOM

Discussion