데모도 Todo 앱도 아닌, 실제로 사용자가 결제하고 있는 AI 음악 생성 플랫폼의 개발 기록입니다.

2025년 말, AI 음악 생성 플랫폼 Music0 AI를 만들기로 했습니다.

「만들기로 했다」라고 말하면 조금 멋을 부리는 것 같지만, 솔직히 말하면 **「아이디어를 검증하고 싶지만, 3개월 동안 코드를 쓰고 싶지는 않다」**는 것이 본심이었습니다.

마침 그 무렵, Codex가 급격히 진화하고 있었습니다. 「코드 보완(Code Completion) 도구」가 아니라, 진정한 의미의 「페어 프로그래밍(Pair Programming)의 파트너」로 사용할 수 있을까? 라는 의문이 출발점이었습니다.

결과적으로, init부터 본방 출시까지, 65 커밋, 약 400개의 TS/TSX 파일, 58,000행 이상의 코드. 프론트엔드(Frontend)·백엔드(Backend)·결제·다국어·SEO·관리 화면까지 모두 커버하고 있습니다. 제가 한 일의 대부분은 「Codex에게 무엇을 원하는지 전달하는 것」과 「Codex가 작성한 코드를 리뷰(Review)하는 것」이었습니다.

이 기사는 AI의 홍보가 아니며, 「엔지니어가 불필요해진다」라고 말하고 싶은 것도 아닙니다. 프로덕션 레벨의 프로젝트에서 Codex로 무엇이 어디까지 가능하고, 무엇이 불가능했는지를 솔직하게 공유하고자 합니다.

Music0 AI는 텍스트 입력으로부터 음악을 생성할 수 있는 AI 플랫폼입니다.

• 🎵
  AI 음악 생성— 스타일과 가사를 입력하여 완성도 높은 악곡을 생성 - 🎤
  AI 랩— Rap / Hip-Hop에 특화된 제너레이터(Generator) - 🎧
  AI Lo-fi— Lo-fi / Chill 계열의 악곡을 생성 - 🎬
  AI 뮤직비디오— 생성한 음악에 영상을 자동으로 부여

레이어	기술 선정
프레임워크	Next.js 16 (App Router) + React 19
...
단순한 데모가 아닙니다. 다음과 같은 기능을 갖추고 있습니다:

• 완전한 사용자 인증·권한 관리 시스템 (RBAC)
• 크레딧제 + 구독(Subscription) + 단건 구매
• 관리 화면 (사용자 관리, 주문 관리, AI 태스크 관리 등)
• SEO 최적화 (sitemap, robots, OG Image, 다국어 SEO 페이지)
• 블로그 시스템·문서 시스템

Git 로그를 그대로 되돌아보겠습니다.

2025-12-15 init → 프로젝트 초기화
2025-12-15 update index → 탑 페이지 구축
2025-12-16 update studio → 스튜디오 페이지
...

1일차 (12/15): 템플릿으로부터 초기화, 탑 페이지와 기본 라우팅(Routing)을 구축.

2일차 (12/16): 스튜디오의 코어 페이지가 형태를 갖춤.

3일차 (12/17): AI 음악 생성의 코어 기능 동작 + CI/CD 배포 완료.

그렇습니다, 3일 만에 MVP가 동작했습니다.

그 이후는 지속적인 개선입니다. 랩 어시스턴트, 뮤직비디오 생성, 크레딧 시스템, 요금 조정, 게스트 제한, 다국어 대응, 공유 기능, 재생 가능한 작품 라이브러리……. 모든 기능 추가가 「Codex에게 전달 → 리뷰 → 조정 → 머지(Merge)」라는 사이클의 반복이었습니다.

이것이 가장 중요한 의식의 전환이었습니다.

많은 분이 AI Coding이라고 하면 「코드 보완」이나 「프롬프트(Prompt)를 던져 코드를 생성하는 것」을 상상할 것이라고 생각합니다. 하지만 프로덕션 레벨의 프로젝트에서는 「AI가 코드를 작성할 수 있는지」가 아니라, **「자신이 무엇을 만들고 싶은지를 명확하게 전달할 수 있는지」**가 핵심이 됩니다.

저의 워크플로우(Workflow)는 다음과 같습니다:

┌──────────────────────────────────────────────────────┐
│ 자신 (프로덕트 설계 + 아키텍처 + 리뷰) │
│ │
...

Music0 프로젝트에서는 AGENTS.md라는 파일을 항상 유지보수하고 있습니다. 이것은 프로젝트 전체의 「개발자 가이드」 같은 것으로, Codex가 기동될 때마다 읽어 들여집니다. 내용은 다음과 같습니다:

• 기술 스택과 프레임워크 규약
• 코딩 스타일 가이드
• 파일 구성 설명
• 빌드·배포 명령어
• 자주 빠지기 쉬운 함정과 주의점

가장 큰 배움은 이것입니다: Codex에 전달하는 컨텍스트(Context)의 질이 생성되는 코드의 질로 직결됩니다. AGENTS.md는 한 번 작성하고 끝내는 것이 아니라, 프로젝트 진행 상황에 맞춰 지속적으로 업데이트하고 있습니다.

예를 들어, 저의 AGENTS.md에는 다음과 같은 규칙이 있습니다:

js/ts/tsx/mjs 파일을 변경했을 경우, 작업 완료 전에 반드시 pnpm build를 실행하여 컴파일이 통과하는지 확인할 것.

이 규칙 덕분에 Codex는 매번 스스로 빌드 검증을 수행합니다. 컴파일이 통과하지 않는 코드를 전달받는 일이 없어졌습니다.

새로운 AI 음악 API 프로바이더(Provider) 연결을 예로 들어보겠습니다. Codex에 전달하는 프롬프트(Prompt)는 다음과 같습니다:

새로운 AI 음악 생성 프로바이더를 추가하고 싶다.
src/extensions/ai/ 에 있는 기존 provider의 구현 패턴을 참고해라.
필요한 사항:
...

Codex는 다음과 같이 동작합니다:

• 기존 provider의 코드를 읽고 인터페이스(Interface) 패턴을 이해
• 동일한 interface에 따라 새로운 provider 파일 생성
• index.ts에 등록
• pnpm build를 실행하여 컴파일 확인

제가 하는 일은 생성된 코드의 리뷰뿐입니다. API 호출 방식, 에러 핸들링(Error Handling), 응답 포맷(Response Format)이 올바른지 확인합니다. 소요 시간은 약 10분입니다. 직접 처음부터 작성했다면 1~2시간은 걸렸을 것입니다.

Music0은 6개 언어(중/영/일/한/스/프)를 지원합니다. 이런 종류의 작업이야말로 AI의 효율화 효과가 가장 현저하게 나타나는 부분입니다.

방법은 간단합니다:

• 먼저 중국어와 영어로 핵심 문구를 완성한다
• Codex에게 "en과 zh의 locale 파일을 참고하여, 모든 키(Key)를 일본어/한국어/스페인어/프랑스어로 번역해줘"라고 전달한다
• Codex는 번역뿐만 아니라 JSON 구조의 일관성이나 복수형(Plural) 처리까지 대응해 줍니다.

혼자서 6개 언어의 SaaS 프로덕트를 운영한다——이전에는 상상할 수 없던 일입니다.

프로젝트에 명확한 코딩 규약(Convention)이 있는 경우, "N번째 유사한 것"을 만드는 속도가 매우 빠릅니다. 예를 들어:

• 두 번째, 세 번째 AI 프로바이더 추가

• 기존 사용자 관리 페이지를 참고한 새로운 관리 화면

• 기존의 CRUD 패턴을 따른 새로운 API 엔드포인트(Endpoint)

• 다국어 번역

• SEO 관련 메타데이터(Metadata) 및 사이트맵(Sitemap) 생성

• 폼 검증(Form Validation, zod 스키마)

• 타입 정의(Type Definition)

"이 컴포넌트를 작은 서브 컴포넌트로 분할해줘", "이 파일이 너무 기니까 리팩터링(Refactoring)해줘"와 같은 지시에는 매우 잘 대응합니다. 리팩터링 규칙은 보통 명확하기 때문입니다.

AI가 작성하는 주석이나 문서는 사람이 작성하는 것보다 더 정중한 경우가 많습니다(사람은 대개 귀찮아서 쓰지 않으니까요).

에러 메시지를 전달하는 것만으로도 빠르게 원인을 특정해 줍니다. 특히 TypeScript의 타입 에러(Type Error)에 관해서는 AI의 대응 속도가 인간을 크게 앞섭니다.

"게스트 사용자에게 이용 제한을 두어야 할까?", "크레딧의 가격 책정은 어떻게 할까?", "랩(Rap)과 Lo-fi를 별도 페이지로 분리해야 할까?"

이러한 판단은 AI가 대신할 수 없습니다. 어떤 방침이든 구현은 해주지만, 어떤 방침이 사용자에게 최적인지는 알지 못합니다.

Music0에서는 여러 AI 프로바이더의 핫스왑(Hot-swap) 메커니즘, 여러 결제 채널의 통합 추상화, 크레딧과 구독(Subscription)의 혼합 과금 모델 등 아키텍처(Architecture) 수준의 설계가 필요했습니다. Codex는 설계된 아키텍처를 구현하는 데는 능숙하지만, 제로 베이스에서 좋은 아키텍처를 설계하는 것은 서툽니다.

기능적으로 완전한 페이지는 생성할 수 있지만, "이 버튼의 배치로 사용자가 혼란을 느끼지는 않을까?", "애니메이션의 지속 시간(Duration)은 200ms인가 300ms인가?", "이 색상 조합이 편안한가?"——이러한 판단에는 인간의 감성이 필요합니다.

Codex가 가진 API 지식이 항상 최신인 것은 아닙니다. 결제 서비스나 AI 프로바이더를 연결할 때는 직접 공식 문서를 읽고, 올바른 API 포맷을 Codex에 전달해야 합니다. Codex의 '기억'에만 전적으로 의존하는 것은 위험합니다.

「이 페이지의 첫 로딩이 왜 이렇게 느리지?」 「이 쿼리에 인덱스 (Index)가 필요할까?」 —— 일반적인 조언은 해줄 수 있지만, 실제 런타임 데이터 (Runtime Data)를 보고 있지 않는 이상 정확한 판단은 내릴 수 없습니다.

Music0는 ShipAny 템플릿을 기반으로 시작했습니다. Codex의 가장 큰 강점은 「제로에서 창조하는 것」이 아니라, **「기존의 기반을 고속으로 확장하는 것」**에 있습니다. 좋은 템플릿 + Codex = 압도적인 개발 속도입니다.

AGENTS.md

(또는 .cursorrules, CLAUDE.md 등)은 당신과 Codex 사이의 「커뮤니케이션 프로토콜 (Communication Protocol)」입니다. 그 품질이 출력 품질로 직결됩니다. 다음 내용들을 포함하는 것을 권장합니다:

• 기술 스택 (Tech Stack) 설명
• 코딩 규약 (Coding Convention)
• 파일 구조 설명
• 빌드 및 테스트 명령어
• 자주 발생하는 에러와 해결책

Codex와 페어 프로그래밍 (Pair Programming)을 할 때, 가장 효과적인 프롬프트 (Prompt) 패턴은 다음과 같습니다:

[무엇을 하고 싶은지]를 구현하고 싶다.
[어떤 기존 코드]의 패턴을 참고해라.
구체적으로 필요한 사항:
...

구체적이고 컨텍스트 (Context)가 풍부한 프롬프트일수록 생성되는 코드의 품질은 높아집니다.

AI가 생성한 코드를 무조건적으로 수용해서는 안 됩니다. 특히 다음 사항은 주의가 필요합니다:

• 보안 관련 코드 (인증, 권한, 결제)
• 데이터베이스 조작 (데이터의 안전성)
• 서드파티 API 호출 (포맷의 정확성)

Music0에서는 결제 관련 코드를 모두 한 줄씩 수동으로 리뷰했습니다.

「번거롭지만 필요한」 작업이야말로 AI가 활약할 차례입니다:

• 다국어 번역
• 테스트 케이스 (Test Case) 작성
• SEO 최적화
• 반복적인 CRUD 코드
• 코드 포맷팅 및 리팩터링 (Refactoring)

절약한 시간은 프로덕트 설계, 아키텍처 (Architecture), 사용자 경험 (UX) 개선에 투자하십시오.

지표	데이터
프로젝트 시작일	2025-12-15
...
Codex는 「코드를 쓰지 않아도 되게 만드는 도구」가 아니라, 정말로 중요한 것에 집중하기 위한 도구입니다.

Music0 개발을 통해 저의 역할은 테크 리드 (Tech Lead)에 가까웠습니다:

• 프로덕트 의사 결정
• 시스템 아키텍처 설계
• 요구사항을 Codex가 이해할 수 있는 태스크 (Task)로 분해
• 모든 아웃풋 (Output) 리뷰
• Codex로 처리할 수 없는 에지 케이스 (Edge Case) 처리

Codex는 최고의 「주니어 엔지니어 (Junior Engineer)」입니다. 실행력이 있고, 지치지 않으며, 불평도 없이 안정적인 아웃풋을 내놓습니다. 다만, 무엇을 만들어야 하는지 알고 있는 인간의 인도가 필수적입니다.

진정한 생산성 향상이란 「AI가 코드를 얼마나 많이 쓸 수 있는가」가 아니라, 「아이디어를 얼마나 빠르게 프로덕트로 전환할 수 있는가」에 있습니다.

만약 AI를 이용한 프로덕트 개발에 관심이 있다면, 지금 바로 시작해 보세요. 도구가 완벽해지기를 기다릴 필요는 없습니다. 실제 프로젝트에서 시행착오를 겪는 것이 가장 좋은 학습 방법입니다.

기술적인 세부 사항에 관심이 있으신 분은 언제든 편하게 댓글 남겨주세요.