서론

최근, 연속 드라마를 분기(Cool) 단위로 관리·기록·랭킹화하는 「드라마의 시간(ドラマのじかん)」이라는 앱을 출시했습니다.

아이디어를 떠올린 것이 2026년 6월 11일이었고, 출시한 것이 2026년 7월 17일입니다. 주말 + 평일 밤을 활용해 약 1개월 동안 131 커밋(Commit)을 했습니다. 기획·키 비주얼 결정·UI 디자인·아키텍처 설계·구현·스토어 소재 제작·LP 제작까지, 거의 모든 과정을 Claude와 함께 진행했습니다.

어렵거나 새로운 기술을 사용한 것은 아니지만, 어떻게 개발을 진행해 나갔는지 남겨두고 싶어 이 글을 쓰게 되었습니다.

왜 만들었는가

예전부터 일본 드라마를 좋아해서 한 분기에 5편 전후로 연속 드라마를 병행해서 보고 있습니다. 이 정도 편수가 되면 무슨 요일 몇 시에 무엇을 하는지 기억하기 어려워, 실시간으로 보려고 했는데 방송 시간이 지나버린 적이 몇 번 있었습니다.

가볍게 찾아본 바로는 드라마에 특화된 앱을 찾을 수 없었고, 저에게 맞는 것이 없었기에 직접 만들기로 했습니다. 제가 매일 사용하는 것이기에, 사양(Specification) 결정에 고민이 생길 때 "나라면 어느 쪽이 더 기쁠까"로 결정할 수 있어 개인 개발의 소재로도 적합하다고 생각했습니다.

다만, 드라마 리마인더 기능만 있으면 단조로운 앱이 될 것 같아, 기획 단계부터 Claude에게 상담해 보기로 했습니다.

기획은 스마트폰 채팅으로 끝났다

처음 상담한 것은 2026년 6월 11일로, Claude 앱의 채팅을 통한 대화였습니다. 에디터는커녕 PC도 켜지 않았습니다. 스마트폰으로 보낸 것은 다음 세 문장이었습니다.

내가 보고 있는 TV 드라마가 무슨 요일 몇 시인지 잘 모르게 되는 경우가 많아서, 그것을 관리하는 스마트폰 앱을 만들고 싶습니다.

다만, 평범하게 만들기만 하면 재미없는 단조로운 앱이 될 것 같으니, 원래의 요구사항을 베이스로 하여 사용하고 싶어지는 앱을 제안해 주세요.

개인적인 취미 개발 범위이므로, 고가의 API나 서버 비용은 쓰고 싶지 않습니다.

"하고 싶은 것", "고민", "제약 사항"을 바탕으로 상담했습니다. 개인 개발이라 돈을 쓰고 싶지 않았기에, 특히 제약 사항을 처음에 정의해 두길 잘했다고 생각합니다.

그리고 돌아온 답변은 아래의 3가지 안이었습니다.

1. 「오늘 밤의 드라마」 알림 특화형 — 방송 30분 전 로컬 알림과 홈 화면 위젯을 주역으로 함
2. 컬렉션형 — 매 에피소드를 볼 때마다 기록하며, 책장이나 달력이 채워져 감. 완주율이나 "쌓여있는 드라마"를 시각화
3. 분기 종료 후 「랭킹(番付)」 생성 — 이번 분기에 본 드라마를 순위 매겨 이미지 한 장으로 정리하여 SNS로 공유

이 시점에서 제가 처음에 생각했던 "방송 시간을 관리하는 앱"에서는 조금 비약되어 있었습니다. 특히 2번과 3번은 제 생각에는 없던 것이었습니다. 기획부터 상담하기를 잘했습니다.

AI의 권장안을 따르지는 않았다

세 가지 안을 제시한 후, Claude는 다음과 같이 덧붙였습니다.

"개인적으로는 '1번의 알림·위젯을 토대로 2번의 기록 요소를 조금 얹는 것'이 개발량과 만족도의 밸런스가 좋다고 생각합니다."

즉, 3번인 랭킹 기능은 제외하자는 제안입니다. 개발량을 고려하면 타당한 판단이라고 생각합니다.

하지만 저는 여기서 따르지 않고 세 가지를 모두 넣기로 했습니다. "랭킹(番付)"이라는 단어의 독자성이 강해, 앱의 개성이나 공유로 이어질 수 있다고 생각했기 때문입니다. 단조로운 앱이 되고 싶지 않다는 우려에 대한 해결책도 될 것이라 믿었습니다.

결과적으로 랭킹 기능이 이 앱의 특징이 된 것 같습니다. 공유용 이미지도 나름대로 공을 들여 만들었습니다.

AI는 타당한 안을 내놓지만, 판단 재료는 가지고 있지 않기에 인간이 결정해야 하는 부분이라고 생각합니다. 특히 개인 개발에서는 자신이 만들고 싶은 것을 만드는 것이 무엇보다 중요합니다!

디자인, UI 방향성 결정

기획서 작성 후, 동일한 채팅창에서 와이어프레임, 배색, 키 비주얼을 결정해 나갔습니다.

먼저 총 7개 화면의 와이어프레임을 작성했고, 다음으로 메인 화면의 배색 안을 세 가지 방향으로 제안받았습니다.

A. 프라임 타임 — 밤 9시의 불 꺼진 방. 짙은 남색에 오늘 밤의 시각만 램프 색으로 밝게 빛남

B. 라테란(신문 TV 편성표) — 신문의 TV 편성표를 빨간 펜으로 동그라미 치던 경험. 신문지 색상 + 명조체 + 손글씨 느낌의 빨간 원

C. 분기 옷 갈아입기 — 포인트 컬러가 분기마다 계절 색상으로 전환되는 밝은 라운드 고딕체

시각화되니 단번에 텐션이 올라가네요...!

B는 세계관 측면에서 가장 강렬하고, 랭킹이라는 종이 문화와의 궁합도 좋은 안이었지만, 신문의 TV 편성표는 요즘 세대에게는 너무 생소할 것이라 판단하여 제외했습니다.

A안을 선택하여 그대로 키 비주얼 (Key Visual)까지 제작했습니다. "밤거리의 곳곳에 켜진 창문 = 모두가 드라마를 기다리는 시간"이라는 모티프로, 창문과 같은 램프 색상으로 "21:00"이 빛나는 구도입니다.

이 키 비주얼은 앱의 베이스가 되었습니다. 앱의 UI, 아이콘, 스토어 캡처, LP, OGP 이미지까지 모두 이 "밤에 켜지는 불빛"에서 파생되었습니다. 초기 단계에서 톤이 한 장의 그림으로 고정되어 있었기에, 이후 단계에서 디자인을 결정하는 데 큰 도움이 되었습니다.

경쟁 조사

이어서 채팅을 통해 경쟁 조사도 진행했습니다.

정리하자면, 경쟁 서비스는 "기록·리뷰형", "에피소드 트래커형", "편성표·스트리밍형"의 3가지 타입으로 나뉘어 있었으며, 방송 시간 관리와 시청 기록을 하나의 앱에서 다루는 서비스는 없다는 결론을 얻었습니다. 이 내용은 사전에 제가 가볍게 조사했던 결과와도 일치했습니다.

약점도 동시에 파악되었습니다. 비용을 들이지 않는 방식으로 진행할 경우 데이터 소스가 부족하여, 공식 편성 데이터를 통한 방송 시간 변경에 대한 자동 추종은 재현할 수 없다는 점이었습니다. 최종적으로는 이 약점에 대한 해답으로서, 휴방일을 직접 등록하거나 나중에 서버상의 데이터를 업데이트할 수 있는 기능을 구현했습니다.

Claude Code로의 인수인계

마지막으로, 지금까지의 자료를 Claude Code에 전달하기 위한 프롬프트를 만들어 달라고 했습니다. 요구사항 정의 → 기술 설계 → 화면 사양 → API 정의 → 테스트 계획 → 출시 계획 → CLAUDE.md를 순서대로 만들게 하는 7단계의 장문 프롬프트가 나왔습니다.

다만, API 정의와 테스트 계획은 취미 수준의 개인 개발에서 API 정의서나 테스트 사양서까지 엄격하게 준비할 필요는 없다고 느꼈기에(애초에 이 정도 수준의 개발에 API 정의가 필요한지도 잘 모르겠어서), 중간에 생략했습니다. 최종적으로 남은 것은 기획서, 경쟁 조사, 아키텍처, 개발 계획의 4가지입니다.

여기까지가 6/11부터 6/13까지의 3일간의 기록이며, 아직 코드는 한 줄도 작성하지 않았습니다.

Pencil로 모든 화면을 디자인하기

기획이 확정된 다음으로 한 일은 구현이 아니라 UI 디자인입니다. 채팅으로 만든 목업 (Mockup)만으로 구현에 들어가면, 구현 후 디자인 조정 과정에서 재작업이 발생할 것이라 판단하여 먼저 모든 화면을 만들기로 했습니다.

처음에는 Figma를 검토했으나, 얼마 전 지인이 이야기했던 Pencil이 생각나 조사해 보았고, 이를 선택했습니다. 아래의 3가지 점이 좋아 보였습니다.

• 2026년 6월 시점에서 무료로 사용할 수 있다는 점
• MCP를 통해 Claude Code에서 조작하기 쉬워 보인다는 점
• 디자인 파일을 리포지토리(Repository)에 두고 Git으로 관리할 수 있다는 점

무료이면서 Claude Code에서 직접 디자인을 읽고 쓸 수 있다는 점이 결정적인 이유였습니다.

Git 관리에 대해서는, .pen 파일의 내용이 JSON이므로 git diff를 통해 그대로 읽을 수 있습니다. 디자인을 변경한 커밋에서 어떤 노드의 어떤 값이 바뀌었는지 차이(diff)로 나타납니다 (컨플릭트(Conflict) 해결 등은 역시 어려울 것 같지만, 차이를 확인할 수 있다는 것만으로도 어느 정도 안심이 됩니다).

- "fontSize": 12,
+ "fontSize": 14,

디자인 파일도 용도에 따라 분할

designs/라는 디렉토리를 만들고, .pen 파일을 용도별로 여러 개 만들었습니다.

designs/
├── dorama_wireframe.pen # 저충실도 (화면 요소 도출)
├── dorama_app.pen # 고충실도 (실제 UI)
...

가장 먼저 만든 것은 dorama_wireframe.pen입니다. 본격적으로 앱 화면을 만들기 전에 어떤 화면들이 있는지 대략적으로 결정하고 싶었기에, 우선 와이어프레임 (Wireframe) 수준의 디자인을 만들었습니다.

그 후, 사전에 결정해 두었던 키 비주얼에 따라 dorama_app.pen에서 앱의 UI를 결정해 나갑니다.

조작은 모두 Claude Code 상의 채팅으로 이루어집니다. MCP를 통해 Pencil을 조작하게 하고, 기획서나 와이어프레임을 참조하게 하면서 "이 화면을 만들어줘"라고 지시하는 방식이었습니다. 디자인 도구는 스스로 거의 만지지 않았습니다.

막히는 부분도 있었지만, Claude 스스로 해결

순조롭게만 진행된 것은 아니었으며, MCP를 통한 조작 과정에서 트러블도 있었습니다. 대표적인 것은 만든 디자인이 데이터상에는 존재하는데 그려지지 않는 현상과, 특정 조건에서 이미지 내보내기가 실패하는 현상입니다. 이 부분의 상세 내용과 회피책은 툴 고유의 문제이므로 별도의 기사로 정리하겠습니다.

※ 별도 기사를 작성하면 여기에 링크를 걸겠습니다.

이러한 문제 및 회피책에 대해서는 사실 제가 거의 파악하지 못하고 있기도 했습니다. Claude Code가 막히면서도 스스로 해결하고 그 결과를 메모리(Memory)에 기록해 두었기에, 동일한 증상이 재발했을 때는 메모리를 참조하여 회피책을 실행했습니다. 이번에 이 글을 쓰면서 Claude에게 물어보고 나서야 비로소 그런 것이었구나 하고 이해했을 정도입니다.

(디자인을 만들 때, '왠지 Claude가 고전하고 있네—' 정도로는 생각하고 있었습니다.)

구현 전 일단 디자인 완료

전체 화면 디자인을 끝내면 구현 단계입니다. 재작업(手戻り, rework)을 피하고 싶었기에, 기본적으로 디자인을 먼저 확정해 두었습니다.

그렇다고 구현 중에 디자인을 전혀 건드리지 않은 것은 아니며, 실제로 구동해 보면서 조정한 부분은 있습니다. 그럼에도 화면 구성 자체를 구현 후에 다시 만드는 일은 없었기에, 재작업을 줄이고 싶다는 최초의 목표는 달성할 수 있었던 게 아닌가 생각합니다.

개발 전 환경 구축

구현에 들어가기 전 마지막 준비는 Claude Code의 작업 환경 구축입니다. CLAUDE.md와 에이전트 스킬(Agent Skill) 두 가지를 준비했습니다.

CLAUDE.md는 최소한으로

이 프로젝트의 CLAUDE.md는 공백을 포함해 27줄이며, 구성은 다음과 같이 되어 있습니다.

# 드라마의 시간
## 앱 개요 … 어떤 앱인지, 로컬 완결·서버 비용 제로 방침
## 아키텍처 … docs/아키텍처.md 참조
...

흔히 말하는 베스트 프랙티스(Best Practice)에 따라, CLAUDE.md에는 어떤 작업에서도 반드시 필요할 정보만을 넣었습니다.

예를 들어 아키텍처의 상세 내용은 구현 타이밍에만 사용하므로 본체에는 "상세 내용은 docs/아키텍처.md"
라고 참조만 적어두고, 내용은 별도 파일로 분리했습니다. 디자인 등도 마찬가지로 취급합니다. 필요한 때에 Claude가 스스로 읽으러 갈 것입니다.

(지금 생각하면, 코드 수정 후의 리뷰 방침에 대해서도 구현 시 참조할 파일로서 별도로 두었어도 좋았을 것 같습니다.)

에이전트 스킬은 공식 목록에서 Claude가 직접 선택하게 함

Flutter/Dart에는 공식 에이전트 스킬 집합이 있지만, 전부 넣을 필요는 없으므로 공식 에이전트 스킬 목록을 Claude에게 제시하고 이 프로젝트에 맞는 것을 선택하게 했습니다.

결과적으로 아래의 7가지가 Claude에 의해 선택되었습니다.

• flutter-apply-architecture-best-practices
• flutter-add-widget-test
• flutter-add-widget-preview
• flutter-fix-layout-issues
• flutter-implement-json-serialization
• flutter-setup-declarative-routing
• flutter-use-http-package

솔직히 이 부분에 대해 얼마나 효과가 있었는지는 잘 모르겠지만, 왠지 모를 안심감은 있었습니다.

코드 리뷰는 AI에게 시킨다를 규칙으로 설정

평소 업무에서도 코드를 보고 있기 때문에, 취미인 개인 개발에서는 가급적 코드를 보고 싶지 않았습니다.

그래서 기본적으로 AI 에이전트가 작성한 코드는 다른 에이전트에게 리뷰를 시키는 운용 방식을 취하고 있었는데, 매번 같은 지시를 하고 있다는 사실을 깨닫고 CLAUDE.md에 규칙으로 추가했습니다.

코드 수정을 수행했을 때, 플래그 전환이나 경미한 문구 수정 등 명백히 영향 범위가 작은 변경을 제외하고, 커밋(Commit) 전에 code-review skill(별도 에이전트에 의한 리뷰)을 실행할 것.

규모가 큰 기능 구현 시에는 꽤 지적이 들어왔던 것으로 기억합니다.

규칙으로 정해도 가끔 지켜지지 않음

다만, CLAUDE.md에 적어 두었음에도 리뷰가 실행되지 않는 경우도 가끔 있었습니다.

이번에는 그렇게까지 하지 않았지만, 확실하게 강제하고 싶다면 hooks 등을 사용하는 편이 좋을 것 같습니다.

아키텍처와 개발 계획을 파일로 남기기

코드를 쓰기 시작하기 전에, docs/아키텍처.md

및 docs/開発計画.md

두 개를 만들었습니다.

아키텍처

구성은 클린 아키텍처 (Clean Architecture) + Riverpod 입니다. 이 부분은 Claude에게 선택하게 하지 않고, 직접 지정했습니다. Flutter는 업무에서 사용했었기에 익숙한 구성을 그대로 채택했습니다. 그렇다고는 해도 Flutter의 공식 문서가 레이어 분리 (Layer Separation)를 권장하고 있으므로, 지시하지 않았더라도 유사한 제안이 돌아왔을 것 같다는 생각은 듭니다.

작성한 アーキテクチャ.md에는 레이어와 의존 방향, 디렉토리 구성, Riverpod을 이용한 DI (Dependency Injection), 유스케이스 (Use Case) 운용 규칙, 테스트 방침까지 포함되어 있어, AI 에이전트가 안정적으로 코드를 작성할 수 있는 기반이 되었다고 생각합니다. 95개 파일까지 늘어난 지금도 레이어 구성은 무너지지 않았을 것입니다...! (아마도)

개발 계획은 페이즈별로

開発計画.md는 페이즈 0~4로 구성되어 있습니다.

• 페이즈 0 — 기반 (프로젝트 설정, DB, 테마)
• 페이즈 1 — 관리 (실시간 시청 중심의 MVP)
• 페이즈 2 — 기록·소비
• 페이즈 3 — 순위(番付)·회고
• 페이즈 4 — 마무리·릴리스 준비

기획 단계의 3가지 안(알림·기록·순위)이 그대로 페이즈 1~3에 대응합니다. 퍼스트 릴리스(First Release)에서 전부 수행하지 않더라도 성립할 수 있도록, 기획 당시의 정리가 계획에 그대로 이어지는 형태입니다.

코드의 레이어 단위가 아니라 기능 단위로 진행하도록 함으로써, 조금씩 앱에서 만져볼 수 있는 기능이 늘어나 즐거웠습니다.

구현은 계획 파일의 업데이트와 함께

開発計画.md의 git 이력을 보면, 거의 모든 기능 커밋과 함께 계획 파일도 계속 업데이트되고 있었습니다. Claude가 성실하게 "기능을 하나 구현하면 계획의 해당 항목에 체크를 표시하고 동일한 커밋에 포함한다"라는 운용을 계속했습니다. 기특합니다!

세션이 바뀌더라도 "어디까지 끝났고, 다음에 무엇을 할지"가 항상 파일에 남아 있기 때문에, 새로운 세션을 열고 "개발 계획의 다음부터"라고 말하는 것만으로 재개할 수 있습니다. 평일 밤처럼 머리를 쓰고 싶지 않을 때도 기계적으로 지시를 내릴 수 있어 편했습니다.

결정하지 않을 것도 적어둔다

그렇다고는 해도, 개발 계획에는 "미결 사항 (착수 시 판단)"이라는 부분도 있었습니다. 예를 들어 알림과 위젯의 구현 범위는 OS별 대응 비용을 가늠할 수 없었기에 "페이즈 2에서 필요 여부 판단"이라고만 적어두고 진행했습니다.

만들고 만져본 뒤에 결정한 것도 있습니다. 알기 쉬운 예로 순위(番付)가 있는데, 처음에는 1위부터 순서대로 나열하는 선형 순위로 구현했지만, 실제로 사용해 보니 어색하여 도중에 S/A/B 티어(Tier)형으로 다시 만들었습니다.

feat: 순위를 선형 순위에서 티어(S/A/B)형으로 다시 만듦

계획 단계에서 무리하게 결정하지 않고, 동작하는 것을 만져본 뒤에 결정한다. 이번에는 결과적으로 이것이 잘 맞아떨어졌습니다.

구현 페이즈에서는 판단을 매일 수행한다

구현 직전의 벽

구현에 들어가기 직전, 기획 시 결정했던 방침이 뒤집혔습니다. 작품 데이터의 취득원입니다.

기획 시에는 "TMDB API를 무료로 사용할 수 있다"라는 전제였으나, 본격적인 착수 전에 실제로 TMDB를 조사해 보니 원하는 일본 연속 드라마 데이터가 거의 없었습니다. 해외 드라마는 충실하지만, 일본의 분기별 드라마(쿠르 드라마)로 들어가면 전혀 없었습니다.

그래서 다시 Claude에게 상담했더니, Wikipedia를 참조한다는 제안이 돌아왔습니다. 아마 스스로는 떠올리지 못했을 안입니다. 하지만 과연 그렇다 싶어 시제품 데이터 취득 스크립트를 만들어 실행해 보니, 생각 이상의 정밀도로 가져올 수 있어서 그대로 채택했습니다.

최종 구성은 다음과 같습니다.

• GitHub 상에서 스크립트를 정기 실행하여 Wikipedia로부터 분기별 작품 정보를 취득하고 JSON으로 정형화
• 해당 JSON을 리포지토리에 두고, GitHub Pages로 배포
• 앱은 작품 추가 시에만 해당 JSON을 참조

데이터를 가져오지 못해 묻혀버릴 뻔한 앱이었지만, 어떻게든 해결되었습니다.

코드는 쓰지 않는다, 읽지 않는다

최근에는 드문 일이지만, 이 프로젝트에서 저는 코드를 거의 쓰지 않았고 읽지도 않았습니다. 개발 계획에 따라 "다음 항목을 진행해 줘"라고 지시하고, 구현이 끝나기를 기다리며, 동작하는 것을 만져보고 확인하는 과정을 반복했습니다. 원래 코드 자체를 쓰는 것보다 생각하고 만드는 것을 좋아하기에, 참 좋은 시대가 되었다고 생각하기도 합니다.

판단은 여전히 인간이 해야 할 일

실제로 고민했던 것은 다음과 같습니다.

• 등록 후의 드라마 데이터는 원본 데이터의 업데이트를 따라가야 하는가
• 편성표를 보여주는 방식
• 랭킹(番付) 디자인

모두 코드 안에 정답이 없는 문제로, 어떤 사양이 좋을지는 AI가 결정할 수 없습니다. 무엇보다 나를 위한 앱이기에, 내가 기쁜 사양으로 만들었습니다.

실기(実機)로 사용하며 발견되는 문제

실제로 직접 사용하기 시작하니 버그가 여기저기서 나타났습니다...

• 방송 시간이 지난 드라마가 홈 화면 위젯에 계속 남아 있음
• 선택한 분기(クール) 이외의 드라마까지 표시됨

둘 다 「시간의 경과」나 「분기를 넘나드는 데이터」가 얽힌 문제로, 짧은 시간의 동작 확인으로는 재현하기 어려운 것들입니다. 이 부분은 사전에 엄격하게 정의해 두는 것이 어렵기 때문에, 실제로 사용해 본 뒤 인간의 위화감 센서에 의존해야 하는 부분일지도 모릅니다.

스토어 소재도 Pencil로 만든다

구현이 안정된 후에는 스토어 신청에 필요한 소재를 만들 차례입니다. 앱 아이콘, 스토어 캡처, Google Play용 피처 그래픽(Feature Graphic) 모두 Pencil로 만들었습니다.

앱 아이콘은 50안 이상 만들었다

가장 고민했던 것이 앱 아이콘으로, 미세한 차이를 포함하면 50안 이상 만들었습니다. 솔직히 지금의 아이콘도 완전히 마음에 쏙 드는 것은 아니라서, 다른 그래픽 출력에 특화된 AI 모델이 더 나을지도 모르겠습니다.

그렇긴 해도, 디자인 감각이 없는 엔지니어인 제가 이 정도의 안을 생각하는 것은 도저히 불가능하기에 도움이 된 부분이기도 합니다.

스토어 캡처

스토어 캡처는 실기 스크린샷이 아니라 Pencil 상에서 구현을 충실히 재현하여 만드는 방식을 택했습니다. 화면 내의 드라마를 가상의 작품으로 만들고 싶었기에, 디자인 툴로 구성하는 편이 조정하기 쉽기 때문입니다.

그리고 AI가 내놓은 결과물에 대해 추가 지시를 내려, 다소 개성을 살려보았습니다.

개인정보 처리방침과 서포트 페이지

스토어 신청에 필요한 개인정보 처리방침(Privacy Policy)과 서포트 페이지는 Claude로 작성된 것을 별도로 사실 여부만 정밀 조사했습니다. 솔직히 개인정보 처리방침 같은 건 무엇을 써야 할지 잘 모르겠으니까요.

스토어 신청

타임라인은 다음과 같습니다.

iOS 버전이 리젝트(Reject)되다

iOS에서 한 번 리젝트되었는데, 내용은 Guideline 2.1 「Information Needed」였습니다. 버그나 규약 위반이 아니라, 심사를 진행하기 위한 추가 정보 요청입니다. 실기 화면 녹화, 테스트 완료 기기 목록, 앱의 목적, 외부 서비스 목록 등 7개 항목을 요구받았습니다.

이 대응도 Claude와 상담하며 진행했기에 수월했습니다. 예전에는 내용을 번역해서 이해하고 대책을 생각하고... 하는 식이었으니까요.

다만, 내용상으로는 「잘 모르겠으니 앱 조작 영상을 보내줘」 같은 느낌이었던 것 같아서, 「직접 조작하면 되는 것 아닌가」 하는 생각도 들었습니다. AI의 영향으로 스토어 신청이 늘어나 심사가 힘들어지니 간략화하고 싶은 걸까요...?

Android 버전은 심사가 길다

Android 심사가 통과될 때까지 1주일...

출시는 양 OS를 맞추고 싶었기에 Android 심사를 기다렸다가, 최종적으로 7/17에 양 OS 동시에 공개했습니다.

LP를 만든다

마지막으로 앱의 LP(Landing Page)를 만들었습니다 (실제로는 개발 여유 시간 등에 조금씩 진행했습니다).

개인 개발자가 LP를 만드는 사람이 다수는 아닌 것 같지만, 저의 경우 개인의 성과물을 한곳에 모아두고 싶은 마음이 있어서 매번 만들기로 했습니다. 1년 전에 만든 다른 앱(しょくめも)에서도 LP를 만들었습니다.

Claude용 프롬프트를 Claude에게 쓰게 한다

단순히 써보고 싶다는 단순한 동기로, LP는 Claude Design으로 만들어 보기로 했습니다.

먼저 Claude Design용 프롬프트를 Claude Code로 만들었습니다. 앱 리포지토리에는 기획서도 키 비주얼 정의도 갖춰져 있으므로, 「그것들을 바탕으로 LP 생성용 프롬프트를 만들어줘」 같은 지시를 하니 그럴듯한 아웃풋이 나올 법한 프롬프트가 나왔습니다.

다만, Claude Design에 익숙하지 않기도 해서 최종적인 조정은 Claude Code 측에서 수행했습니다.

참고로 AI가 만들었다는 것이 너무 티 나는 디자인은 피하고 싶었지만, LP에 너무 많은 시간을 쓰는 것은 본말전도이기에 타협했습니다.

요약

소요 비용

이 개발을 위해 새로 지불한 비용은 0엔입니다. 모두 기존 비용 범위 내에서 해결되었습니다.

• Claude Pro 플랜: 월 $22 (계약 완료)
• Apple Developer Program: 연 $99 (계약 완료)
• Google Play 개발자 등록: 일회성 결제이며, 과거에 등록 완료
• 도메인: 연 ¥2,000 정도 (취득 완료)
• 서버 비용 (GitHub Pages): 0엔
• LP (Firebase hosting): 무료 이용 범위 내

다음에도 계속하고 싶은 것

기획부터 AI와 대화 (Wall-hitting)

하고 싶은 것, 고민, 제약 사항이라는 세 가지를 전달한 덕분에, 더욱 다듬어진 기획을 현실적인 방법으로 정리할 수 있었습니다.

키 비주얼을 빠른 단계에서 작성

처음에 대충 의뢰해서 만든 비주얼이 마지막까지 디자인의 중심축이 되었습니다.

진행 상황과 결정 사항을 파일로 남기기

특히 개발 계획을 파일로 만들어 구현할 때마다 업데이트했기 때문에, 1개월 동안 계속해서 동일한 흐름으로 개발을 이어갈 수 있었습니다.

다음에는 개선하고 싶은 것

(Pencil을 사용한다면) pen 파일은 하나로

Pencil은 MCP를 통해 활성화된 탭만 읽을 수 있어 파일을 매번 전환하는 것이 번거로우므로, 하나의 파일로 통합하는 것이 좋아 보입니다.

마치며

돌이켜보면, 제가 했던 일은 "문서를 정리하기", "규약을 명문화하기", "결정과 진행 상황을 남기기"와 같이 팀 개발에서 예전부터 강조되어 온 것들이었습니다. 상대가 인간에서 AI로 바뀌어도, 원활하게 협업하기 위한 방법은 변하지 않는 것이군요.

그렇게 만든 "드라마의 시간"은 지금 제 스마트폰에서 매일 작동하고 있습니다. 드라마를 좋아하시는 분들은 꼭 한번 사용해 보세요!

후기

이 기사 자체도 물론 Claude와 함께 작성하고 있습니다.

"이런 기사를 쓰고 싶다"라고 전달한 후, 필요한 정보를 적절히 확인하도록 했습니다. "드라마의 시간" 자체의 리포지토리(Repository)에서 시작한 세션이라 정보도 갖춰져 있었고, 인터뷰 형식으로 질문에 답해 나가는 것만으로 이 긴 글의 기사를 완성할 수 있었습니다.

그대로 두면 확실히 AI 느낌이 너무 많이 났기에 문체는 상당히 조정했지만, 집필 비용과 허들이 상당히 낮아진 기분이 듭니다.

Discussion