GitHub Copilot CLI와 대화를 통해 오디오 분석기 구축

발행: 2일 전 (2026년 2월 2일 오전 09:16 GMT+9)

9 min read

원문: Dev.to

Source: Dev.to

GitHub Copilot CLI와 대화를 통한 오디오 분석기 구축

이것은 GitHub Copilot CLI 챌린지 제출물입니다.

내가 만든 것

mixref는 음악 프로듀서를 위한 CLI 오디오 분석기입니다. 오디오 파일을 분석하고 다음을 제공합니다:

음량 메트릭
BPM 감지
음악 키 식별
스펙트럼 분석

문제

음악을 제작할 때 나는 종종 다음이 필요합니다:

다양한 스트리밍 플랫폼의 라우드니스 레벨(LUFS) 확인
BPM 및 음악 키를 빠르게 감지
내 믹스를 레퍼런스 트랙과 비교
주파수 분포 확인

나는 DAW나 여러 플러그인을 열지 않고 빠른 명령줄 도구가 필요했습니다.

무엇을 하는가

라우드니스 분석

LUFS 측정 (EBU R128 표준)
실제 피크와 라우드니스 범위 표시
플랫폼 목표와 비교 (예: Spotify: –14 LUFS, YouTube: –14 LUFS 등)

음악 분석

librosa를 사용해 BPM 감지
반절 감지를 위한 기본 보정 포함 (3 % 임계값 내에서 BPM을 두 배로)

데모

명령줄 인터페이스

분석 명령

비교 명령

예시 출력

$ mixref analyze track.wav

             Analysis: track.wav             
┏━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━┓
┃ Metric              ┃        Value ┃ Status ┃
┡━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━┩
│ Integrated Loudness │    -6.2 LUFS │   🔴   │
│ True Peak           │    -0.8 dBTP │   ⚠️   │
│ Loudness Range      │       5.2 LU │   ℹ    │
├─────────────────────┼──────────────┼────────┤
│ Tempo               │    174.0 BPM │   ❓   │
│ Key                 │ F minor (4A) │   ❓   │
├─────────────────────┼──────────────┼────────┤
│ Sub                 │   ■■■■■■■□□□ │ 35.2%  │
│ Low                 │   ■■■■■■■■■□ │ 28.4%  │
│ Mid                 │   ■■■■□□□□□□ │ 18.1%  │
│ High                │   ■■■■■■□□□□ │ 14.2%  │
│ Air                 │   ■□□□□□□□□□ │  4.1%  │
└─────────────────────┴──────────────┴────────┘

직접 해보기

# Install from PyPI
pip install mixref

# Analyze a track
mixref analyze my_track.wav

# Compare against a reference
mixref compare my_mix.wav pro_reference.wav --bpm --key

GitHub Copilot CLI 사용 경험

이 프로젝트는 GitHub Copilot CLI와 전적으로 대화를 통해 구축되었습니다. 코드를 입력하지 않았고—원하는 것을 평범한 언어로 설명했습니다.

Source:

개발 과정

1. 코딩 대신 설명하기

Python 코드를 직접 쓰는 대신 다음과 같이 요청했습니다:

Create a function that calculates EBU R128 loudness using pyloudnorm.
Return integrated LUFS, true peak, and loudness range.
Include type hints and error handling.

Copilot은 다음을 생성했습니다:

pyloudnorm을 이용한 작동 구현
완전한 타입 힌트
엣지 케이스에 대한 오류 처리
예시가 포함된 Docstring

2. 대화를 통한 디버깅

BPM 탐지 결과가 0.0이 나왔을 때 문제를 다음과 같이 설명했습니다:

"BPM detection returns 0.0. Librosa warning says:
'n_fft=2048 too large for input signal of length=2'
The stereo-to-mono conversion might be wrong."

Copilot은

버그를 식별 (np.mean(audio, axis=0)가 배열 형태에 맞지 않음)
올바른 포맷 감지를 적용해 수정
테스트를 업데이트 (모두 여전히 통과)

3. 개발 도구 구축

pre‑commit 품질 검사 스크립트를 요청했습니다. Copilot은 ./scripts/pre-commit-check.sh를 만들었습니다:

#!/usr/bin/env bash
echo "🔍 Running pre-commit quality checks..."
echo "1️⃣ Formatting with ruff"
echo "2️⃣ Linting"
echo "3️⃣ Type checking"
echo "4️⃣ Tests"
echo "🎉 All checks passed!"

이 스크립트는 GitHub Actions에 푸시하기 전에 문제를 잡아줍니다.

4. 테스트와 문서화

실제 파일 없이 합성 오디오를 이용한 테스트를 요청했습니다. Copilot은 다음을 제공했습니다:

154개의 테스트와 약 90 % 커버리지
사인파와 핑크 노이즈를 생성하는 Fixtures
실제 오디오 파일을 커밋하지 않음

문서화 측면에서 Copilot은 다음을 설정했습니다:

API 문서가 포함된 Sphinx
예제 갤러리
termtosvg를 이용한 터미널 녹화

Source: …

잘 작동한 점

Speed – 기능을 만드는 속도가 훨씬 빨라졌습니다. 몇 시간이 걸릴 일도 집중된 대화만으로 해결되었습니다.
Code Quality – 생성된 코드는 제가 놓쳤을 수도 있는 관례를 따릅니다:
- 전역에 걸친 타입 힌트
- 일관된 오류 처리
- 완전한 docstring
- 좋은 테스트 커버리지 (≈ 90 %)
Learning – 문서만 읽는 것이 아니라 직접 구현하면서 오디오 처리 개념(EBU R128, Camelot wheel)을 배웠습니다.
Context – Copilot이 세션 간에 결정을 기억했습니다:
- “Rich를 출력에 사용” → 모든 명령이 Rich 테이블을 사용함
- “테스트에서는 합성 오디오만 사용” → 레포에 실제 파일이 없음
- 전체에 걸친 일관된 코딩 스타일

도전 과제

Not Magic – 여전히 제가 해야 할 일이 있었습니다:
- 내가 무엇을 요청하는지 이해하기
- 생성된 코드를 검토하고 테스트하기
- 엣지 케이스 수정하기
- 아키텍처 결정 내리기
Iteration – 처음 솔루션이 완벽하지 않을 때가 있었습니다. 문제를 명확히 설명하고 반복하는 방법을 배웠습니다.
Testing Real Audio – 합성 테스트 신호만으로는 모든 엣지 케이스를 잡을 수 없습니다. 실제 오디오 파일로 테스트하면서 버그(예: BPM‑검출 문제)를 발견했습니다.

The Real Shift

Before: Think → Code → Debug → Test → Fix
With Copilot CLI: Think → Describe → Review → Test

나는 무엇을 만들지와 어떻게 작동해야 하는지에 더 많은 시간을 투자했고, 구문과 보일러플레이트에는 적은 시간을 썼다.

메트릭

750줄의 소스 코드
154개의 테스트 (≈ 90 % 커버리지)
19개의 모듈 (모두 타입‑체크됨)
3개의 CI/CD 워크플로 (테스트, 문서, 품질 검사)
Sphinx를 사용한 완전한 문서화

모든 것이 대화를 통해 구축되었으며, 수동 코딩이 아닙니다.

Lessons Learned

Clear descriptions matter – 내가 원하는 것을 더 잘 설명할수록 결과도 더 좋았습니다.
Review everything – 생성된 코드는 테스트와 검증이 필요합니다.
Iterate naturally – “사실, 만약 …”이라는 식으로 질문하면 Copilot과 잘 작동합니다.
Tests are essential – 좋은 테스트는 생성된 코드의 문제를 잡아냅니다.

결론

GitHub Copilot CLI는 제가 개발에 접근하는 방식을 바꾸었습니다. 코드를 직접 입력하는 대신 문제를 설명하고 솔루션을 검토하는 데 집중합니다.

mixref는 기능적인 오디오‑분석 도구입니다. 제가 필요로 하는 것을 정확히 수행하며, 흥미로운 점은 그것이 전적으로 대화를 통해 구축되었다는 것입니다.

사용해 보기

pip install mixref
mixref analyze your_track.wav

Source code

github.com/Caparrini/mixref

GitHub Copilot CLI와 AI‑지원 개발에 대한 호기심으로 구축했습니다.