딕으닥
허밍 한 소절을 녹음하면 음표로 바꾸고, 그 멜로디에 맞는 키와 코드를 찾아 드럼, 베이스, 피아노, 기타 반주를 붙여 주는 웹 서비스입니다. 틀린 음은 피아노롤에서 고치고, 트랙 볼륨을 맞춘 뒤 WAV로 내보낼 수 있습니다.
지금은 개발 초기 단계입니다. 프로젝트 뼈대(Next.js, SongState 타입, store, 스튜디오 화면 틀)가 들어 있고, 기능은 역할별로 개발을 시작합니다.
실행 방법
Node.js 24 기준입니다.
npm install
cp .env.example .env.local # 값 채우기
npm run dev # http://localhost:3000, 스튜디오는 /studio/new
| 명령 | 내용 |
|---|
npm run dev | 개발 서버 |
npm run build | 프로덕션 빌드 |
npm run lint | ESLint |
npm run typecheck | 라우트 타입 생성 후 TypeScript 검사 |
npm test | Vitest 감시 모드 (npm run test:run은 한 번만 실행) |
npm run format | Prettier로 포맷 (format:check는 검사만) |
npm run db:push | supabase/migrations의 새 마이그레이션을 Supabase DB에 적용 |
npm run db:types | DB 구조로 src/types/database.ts 타입 다시 생성 |
테스트 하나만 돌릴 때는 npx vitest run src/store/songStore.test.ts처럼 파일 경로를 넘기거나 -t "테스트 이름"을 붙입니다. 테스트 파일은 대상 파일 옆에 *.test.ts로 둡니다.
DB 변경
DB 구조(테이블, RLS, Storage 정책)는 supabase/migrations/의 SQL 파일로만 바꿉니다. 대시보드 SQL Editor에서 직접 고치면 마이그레이션 기록과 실제 DB가 어긋납니다. 처음 한 번은 npx supabase login과 npx supabase link --project-ref <프로젝트 ID>가 필요하고, 마이그레이션을 적용한 뒤에는 npm run db:types로 타입을 다시 만들어 함께 커밋합니다.
PR을 올리기 전에 npm run lint, npm run typecheck, npm run test:run이 통과하는지 확인해 주세요.
만드는 이유
악기를 못 다루거나 DAW가 어려운 사람도 머릿속 멜로디를 곡으로 남기고 싶어 합니다. 작곡을 할 줄 알아도 멜로디가 떠오른 순간에 DAW를 켜기는 번거롭습니다. AI 음악 생성 서비스는 곡을 통째로 만들어 주지만, 사용자가 부른 멜로디를 반영하지 못하는 경우가 많습니다.
딕으닥은 사용자가 부른 멜로디를 그대로 두고 그 위에 반주를 얹습니다. 결과도 편집 가능한 음표 데이터로 저장되므로 나중에 다시 열어 고칠 수 있습니다.
사용 흐름
- 브라우저에서 최대 30초까지 허밍을 녹음합니다. 카운트인 메트로놈으로 박자를 잡습니다.
- 피치를 검출해 MIDI 음표로 바꾸고, 16분음표와 반음 단위로 맞춥니다. 인식이 틀린 음은 피아노롤에서 추가, 삭제, 이동, 길이 조절로 고칩니다.
- 멜로디를 분석해 키, 코드 진행, 어울리는 장르와 BPM을 제안하고, 왜 그렇게 판단했는지 설명을 붙입니다.
- 장르를 고르면 드럼, 베이스, 피아노, 기타 반주가 생성됩니다. MVP에서는 팝, 발라드, 록 정도로 2~3개 장르를 준비합니다.
- 트랙별 볼륨, 뮤트, 솔로로 소리를 맞추고, 멜로디와 기타는 악기 소리를 고를 수 있습니다.
- WAV로 내보내거나 프로젝트로 저장합니다.
녹음부터 믹싱까지는 로그인 없이 쓸 수 있습니다. WAV 다운로드와 프로젝트 저장을 할 때만 로그인(이메일, GitHub, Google)이 필요하고, 로그인하면 게스트로 작업하던 곡이 그대로 저장된 채 스튜디오로 돌아옵니다.
스튜디오 화면은 가운데 타임라인(코드 레인, 멜로디 피아노롤, 드럼, 베이스, 건반, 기타 줄)이 항상 보이고, 상단 진행 바의 단계(녹음, 보정과 AI 분석, 반주, 믹싱)에 따라 오른쪽 도구 패널만 바뀌는 구조입니다. 화면 구성은 딕으닥 화면 목업.html에서 볼 수 있습니다.
분석은 규칙 엔진, LLM은 설명 다듬기
키와 코드 진행은 외부 API 없이 브라우저에서 음악 이론으로 계산합니다.
- 키: Krumhansl–Schmuckler 알고리즘. 음별 사용 길이를 장조, 단조 24개 표준 분포와 비교합니다.
- 코드 진행: 마디마다 후보 코드에 점수를 매기고(멜로디 음과 구성음이 얼마나 겹치는지, 강박과 음 길이 가중치), 코드 전환이 자연스러운지까지 따져 Viterbi로 전체 진행을 고릅니다.
- 스타일: BPM, 장단조, 음 밀도로 정하고, 사용자가 장르를 직접 바꿀 수 있습니다.
- 설명: 분석 근거로 문장 틀을 채웁니다. 예를 들어 "C, E, G가 많이 쓰여 C장조로 판단" 같은 식입니다.
LLM은 이 설명 문장을 자연스럽게 다듬을 때만 부릅니다. 호출이 실패하거나 사용자별 한도를 넘으면 규칙 엔진의 기본 설명을 그대로 보여 주고, 곡을 만드는 흐름은 멈추지 않습니다. LLM 응답은 Zod로 검증하고, 형식이 맞지 않으면 한 번 다시 요청한 뒤 그래도 실패하면 규칙 엔진 결과를 씁니다.
이렇게 나눈 이유는 결과를 안정적으로 내고, 비용과 외부 API 의존을 줄이기 위해서입니다. 같은 이유로 반주 음표도 장르별 템플릿 엔진이 만들어 박자가 정확하게 맞도록 합니다.
오디오 처리도 모두 브라우저에서 합니다. Vercel의 요청 크기 제한(약 4.5MB)과 실행 시간 제한을 피하기 위해서입니다. 서버(/api/analyze)는 LLM API 키를 숨기는 역할만 합니다. 모든 화면은 SongState라는 JSON 하나를 함께 읽고 고치며, 프로젝트 저장도 이 JSON을 Supabase projects 테이블에 넣는 것으로 끝납니다.
기술 스택
| 영역 | 기술 |
|---|
| 프레임워크 | Next.js (App Router), TypeScript, Tailwind CSS |
| 상태 관리 | Zustand (SongState 전역 관리) |
| 녹음, 피치 검출 | Web Audio API, Pitchy |
| 재생, 렌더링 | Tone.js, smplr (샘플 악기) |
| 음악 분석 | 자체 규칙 엔진 (lib/music) |
| AI 보조 | LLM API (Claude, OpenAI 등), Zod 응답 검증 |
| DB, 인증, 저장소 | Supabase (Postgres, Auth, Storage) |
| 배포 | Vercel + GitHub (PR 미리보기 배포, main 자동 배포) |
| 선택 기능용 | wavesurfer.js (파형 편집), VexFlow (오선보) |
기준 환경은 데스크톱 Chrome입니다. iOS Safari 같은 브라우저는 오디오 호환성 문제가 있어 사용자 클릭 이후에 AudioContext를 시작하도록 처리할 계획입니다.
범위
MVP 이후 여유가 있으면 파형 표시와 구간 자르기, 트랙 이펙트(리버브, EQ, 컴프레서), 오선보 표시, 코드 수동 수정, "더 밝게, 더 슬프게" 같은 AI 재추천, 읽기 전용 공유 링크를 붙입니다. 재추천에서 LLM이 제안한 코드는 규칙 엔진 점수로 검사해 멜로디와 크게 부딪히면 버립니다.
MusicGen 같은 오디오 생성형 AI는 쓰지 않습니다. 비용과 속도, Vercel 실행 시간 제한 때문입니다. 가사 생성, 보컬 합성, 여러 사람이 동시에 편집하는 기능도 범위에서 뺐습니다.
팀 구성
세 명이 기능 흐름을 따라 나눠 맡습니다. 세 역할 모두 SongState를 중심으로 연결되기 때문에, 이 타입을 개발 시작 전에 확정해 두면 각자 따로 개발할 수 있습니다.
| 역할 | 맡는 일 |
|---|
| A. 입력, 타임라인 | 녹음, 피치 검출, 퀀타이즈, 피아노롤과 코드 레인이 들어간 타임라인 컴포넌트 |
| B. 음악 엔진 | 규칙 엔진 분석, 반주 템플릿, Tone.js 재생, 믹서 |
| C. 앱, 서버, 저장 | 페이지와 스튜디오 틀, 인증, Supabase 저장, /api/analyze, WAV 내보내기, 배포, SongState 타입 관리 |
main에는 직접 push하지 않습니다. feat/{기능명}, fix/{내용} 브랜치에서 작업하고, PR은 한 명 이상 리뷰한 뒤 Vercel 미리보기로 동작을 확인하고 병합합니다. 커밋 메시지는 feat:, fix:, refactor:, docs: 접두어를 씁니다. types/song.ts나 lib/schemas.ts를 고치는 PR은 변경 내용을 설명에 적고 팀원 전체를 리뷰어로 지정합니다.
문서와 파일
