[2026 Winter DEV] 기타 소리 분석을 통한 이펙트 종류 및 파라미터 값 예측 모델 ‘Boss Effector’, Queen팀

프로젝트 소개

Queen 팀원사진

Queen팀은 기타 사운드를 AI로 분석해 사용된 이펙터와 세부 파라미터를 찾아주는 서비스를 개발하였습니다 지금 바로 만나보도록 하시죠 !!

팀원 소개

Queen팀은 BE 정빈님, AI 봄님, AI 해서님으로 구성되어 있습니다!

인터뷰

Q. 프로젝트를 소개해주세요!

A. 해서(AI): 저희는 사운드 엔지니어가 이펙트 종류와 파라미터를 조정해 원하는 소리를 만든다는 점에 착안하여, Mix 음원을 넣으면 해당 음원에서 기타 소리만 분리하는 웹사이트를 만들고, 기타 소리를 넣으면 이펙트가 적용된 Wet 신호에서 이를 제거하고 Dry 신호까지 복원하는 모델을 만들었습니다. 원래는 AI를 이용해 여러 밴드가 섞인 음악에서 기타 소리를 분리하고, 만든 모델을 이용하여 분리한 기타 소리에 사용된 이펙터와 파라미터 정보를 추정하며, 해당 이펙터가 제거된 깨끗한 기타 소리까지 추정하는 웹사이트를 만드는 게 목표였지만, 만들어낸 모델을 웹사이트에 연결하는 과정에서 오류를 겪어 두 부분이 따로 만들어져 있는 상태입니다.

저희가 구현한 걸 정리하자면 다음과 같습니다.

모델을 연결하면 작동되는 웹사이트 구현 프론트엔드, 메인 API 서버, GPU 서버로 구성. 사용자로부터 파일 입력을 받아 여러 서버와 AI 모델이 협력하여 최종 결과를 만들어냄. 파일 업로드, 파일 검증, 원곡에서 기타 소리 추출, 이펙터와 파라미터 예측, 분석 완료 및 결과 전송의 과정을 거침. 또한, Server-Sent Events(SSE)를 통해 분석 진행률을 실시간으로 사용자에게 보여줌.
AI 기반 기타 소리 추출 Query-Bandit 모델을 활용하여 원곡과 기타 샘플(Query)을 기반으로 고품질의 기타 트랙을 분리. GPU 가속(A10G)을 통해 빠른 처리 속도를 제공.
이펙터 파라미터 예측 모델 추출된 기타 소리를 분석하여 사용된 이펙터 종류(Distortion, Delay, Chorus, Reverb)를 식별. 해당 이펙터의 주요 파라미터 (Gain, Tone, Level 등) 추천값을 제공

Q. 프로젝트 하면서 어떤 문제를 겪었나요?

A. 정빈(BE): “맨땅에 헤딩”이라는 말이 어울릴 정도로 연구부터 배포까지 모든 단계가 난관이었지만, 이를 기술적 우회와 소통으로 극복해 나갔습니다. 가장 먼저 직면한 문제는 ‘참고 자료의 부재’였습니다. 저희의 목표인 ‘기타 이펙터 체인 및 파라미터 추정’과 정확히 부합하는 선행 연구를 찾기 어려웠고, 어렵게 찾은 논문조차 코드가 공개되어 있지 않았습니다. 결국 논문의 수식과 아키텍처 구조도만 보고 코드를 밑바닥부터 직접 구현해야 했는데, 이 과정에서 모델 구조에 대한 깊은 이해를 얻을 수 있었습니다.

두 번째 난관은 ‘1.6TB에 달하는 방대한 데이터와 제한된 학습 환경’이었습니다. Google Colab은 24시간 런타임 제한과 디스크 용량 한계가 있어, 대용량 데이터를 한 번에 메모리에 올리는 것이 불가능했습니다. 이를 해결하기 위해 두 가지 전략을 도입했습니다. 체크포인트(Checkpoint) 시스템: 런타임이 끊겨도 이어서 학습할 수 있도록 에포크마다 가중치를 저장하고 자동 로드하는 로직을 구현했습니다. 청크(Chunk) 기반 데이터 로딩: 구글 드라이브의 데이터를 전체 로드하는 대신, 필요한 만큼만 잘라서(Chunk) 가져오는 커스텀 DataLoader를 작성하여 디스크 오버헤드를 해결했습니다.

마지막으로 가장 아쉬웠던 점은 ‘모델 배포 단계의 실패’였습니다. 학습된 모델을 웹 서버에 연결하는 과정에서 지속적인 텐서 Shape 불일치 오류가 발생했습니다. 밤을 새워가며 디버깅을 시도했지만, 결국 Dev 당일까지 완벽한 연동에는 실패했습니다. 하지만 이것은 단순한 실패로 끝나지 않았습니다. Dev 부스에서 시연하던 중, 우연히 방문해주신 AI 전공 석사 과정 선배님과 이 문제를 논의하게 되었습니다. 그분께서는 저희의 오류 로그를 보시고 “이건 모델 구조 문제가 아니라 배포 환경의 의존성 문제일 가능성이 높다”며 Hugging Face Spaces를 활용한 대안을 제시해 주셨습니다. 당장은 웹 연동을 보여주지 못해 아쉬웠지만, 이 경험을 통해 ‘왜 개발자 네트워킹 행사가 필요한지’ 몸소 체감했습니다. 혼자 끙끙 앓던 문제를 공유하고 해결하는 실마리를 얻은 것, 그것이야말로 이번 프로젝트와 Dev 행사가 준 가장 큰 순기능이라 생각합니다.

Q. 프로젝트 하기 전후 달라진 점이 있다면?

A. 봄(AI): 프로젝트를 하기 전에는 목표한 결과물을 내놓지 못하면 실패한 거라고 생각했었습니다. 그런데 이번 프로젝트를 하고 나니 결과물이 목표한 만큼 안 나왔더라도 결과물을 만들어내기 위한 과정 속에서 완성한 것들과 배운 것들이 많다는 걸 깨닫게 되었습니다. 최종 시연과 발표가 있기 전날에 오류가 나서 웹사이트에 저희가 만든 모델을 올리지 못하고 있었을 때는 ‘완성된 결과물을 내지도 못하고 난 뭘 한 걸까ʼ 등의 생각을 했었습니다. 결과물로만 보면 모델을 연결하지 못한 게 맞지만, 최종 발표가 끝나고 생각해 보니 저희는 웹사이트와 기타 소리만 추출하는 부분, 이펙터와 파라미터를 예측하고 Dry 신호도 반환하는 모델을 완성했고, 그 과정에서 논문을 분석하며, 큰 용량의 데이터를 불러오며, 모델을 만들며, 그리고 웹사이트를 만들며 정말 많은 것들을 배웠습니다. 이는 실패한 게 아니고 중간 목표를 달성하며 성장 과정에 있는 게 아닐까요?

Q. 프로젝트를 시작하는 팀에게 전해줄 꿀팁을 말해주세요!

A. 해서(AI): 진행 상황이나 힘든 부분이나 그 밖의 다른 말들도 그때그때 할 수 있는 자기 팀만의 의사소통 수단이 있으면 좋다고 생각합니다. 또 같이 프로젝트를 하다 보면 서로가 도움을 주고받거나 사소한 부분도 잘했다는 생각이 들 때가 많은데, 이때마다 고마움을 표현하고 칭찬하면 서로가 서로에게서 힘을 얻는 팀이 될 수 있다고 생각합니다. 모두 팀과 함께하는 즐거움을 경험하며, 자신도 팀도 성장해감을 느끼는 보람찬 프로젝트 하셨으면 좋겠습니다.

Q. 프로젝트 개발 중 어려움을 겪은 경험이 있나요? 어떻게 해결했으며, 그 과정에서 얻은 교훈은 무엇인가요?

A. 봄(AI): 이번 프로젝트를 하면서 다양한 오류를 경험할 수 있었습니다. 큰 데이터를 다운로드하고 이를 코랩 환경으로 불러오는 과정에서 생긴 오류, Demucs를 사용하며 겪은 버전 문제와 patch 오류, 모델을 학습시키는 과정에서 리소스가 부족해 생긴 오류, 모델을 알고리즘에 적용해서 코드를 짜는 과정에서의 오류 등을 겪었는데, 그중에서도 가장 해결하기 어려웠던 오류가 Demucs 오류였습니다. 이펙터를 예측하고 파라미터를 추정하는 모델을 코드로 만들 때 Demucs라는 라이브러리를 불러와 사용했는데, 이 Demucs는 구조가 유연하지 않아서 저희의 환경에서 돌리면 여러 오류가 날 수 있습니다. 저희도 실제로 많은 오류를 경험했으며, 처음에는 단순한 오류라고 생각하여 당장 오류가 난 부분만 수정하고 넘어갔으나, 같은 맥락에서 오류가 나는 것 같아 더 알아보니 Demucs를 불러오면 나는 오류의 종류들이라는 걸 알게 되었습니다. 그래서 해당 종류의 오류가 날 수 있는 부분을 전체적으로 코드에 반영해가며 다시 코드를 구상했고, 다른 부분은 해결을 했는데 계속 해결하지 못한 부분이 있었습니다. 저는 Demucs를 다르게 수정해서 patch를 해야 된다는 생각만 하고 있었고 계속 그 관점에서 코드를 수정하고 있었는데, 이때 팀원분이 제가 난항을 겪고 있는 것을 파악하고 같이 오류에 대해 알아봐 주셨었습니다. 팀원분이 알아봐 주신 방법으로 오류를 해결할 수 있었고, 이는 patch를 수정해야 되는 문제가 아닌 Demucs 모델을 다시 로드하는 과정을 거치는 코드를 추가해야 되는 문제였습니다. 이런 과정을 경험하고 나니, 어렵거나 막히는 부분이 있을 때는 팀원분들과 공유해야 된다는 것을 다시 한번 깨닫게 되었습니다. 우선 현재 오류를 겪어 다음 단계를 넘어가지 못하고 있는 것을 알리는 것도 진행 상황 공유에 해당된다는 생각이 들었습니다. 그리고 어려움을 겪고 있는 저 자신은 같은 측면에서만 바라보게 되기도 하고 해당 부분에 대해 많이 지쳐있는 상태가 되는데, 이를 팀원분들에게 말해보면 해결책을 같이 찾아볼 수도 있고, 다른 분들의 의견을 듣거나 같이 조사하는 과정에서 새롭게 배우는 것들도 많았습니다. 또한, 해결책 이외에도 팀원분들의 위로와 응원을 통해 큰 힘을 얻을 수 있었습니다. 그래서 저는 팀원들과 함께 프로젝트를 하고 있고, 그건 어려운 상황을 함께 헤쳐나갈 수 있다는 걸 의미한다는 교훈을 얻었습니다.

Q. 본인 팀만의 특별한 협업 방식이 있나요? 있다면 소개해 주세요

A. 정빈(BE): 우리 팀의 노션을 사용해서 협업의 효율을 높였습니다. 프로젝트를 진행할 때 진행 상황이 단절되는 문제를 해결하기 위해 노션을 공동 작업 공간으로 정하고, 모든 과정이 연결되도록 구성하였습니다. 우선 ‘회의록ʼ 페이지를 중심으로 매주 논의한 내용과 To-do 리스트를 기록했습니다. 이는 지난 회의 안건들을 확인하고 이번 회의에서 해야 할 일을 효율적으로 생각하는 데 큰 역할을 했습니다. 논문 조사 과정도 노션을 기반으로 진행했습니다. 기타 이펙터 체인 추정과 관련된 여러 논문을 읽으며 논문의 흐름과 내용, 데이터셋과 코드의 유무 등을 팀원과 쉽게 공유했습니다. 이는 이 논문 방식이 우리 프로젝트 조건과 부합한지 더 효율적으로 비교할 수 있었고 적절한 논문을 선택하는 데 큰 도움을 주었습니다. 또한 구글 코랩 계정 공유를 하여 하나의 실행 환경에서 작업했습니다. 모델 코드와 데이터 경로를 모두 통일하여 다른 팀원들도 바로바로 코드를 확인할 수 있고 서로 작업을 분담할 때도 효율적으로 이루어질 수 있도록 하였습니다.

Q. 프로젝트의 기술적인 도전과제나 혁신적인 부분은 무엇이었나요?

A. 해서(AI): 본 프로젝트는 딥러닝 기반의 음원 분리 및 이펙터 분석 기능을 포함하고 있어 고성능 GPU 연산이 필수적이었습니다. 하지만 AWS EC2나 GCP와 같은 전통적인 IaaS 방식을 사용하는 것은 두 가지 치명적인 문제가 있었습니다. 비용 비효율성(Over-provisioning): 트래픽이 없는 새벽 시간대에도 GPU 인스턴스를 유지해야 하거나, 반대로 비용 절감을 위해 인스턴스를 끄면 즉각적인 서비스 대응이 불가능했습니다. 인프라 관리의 복잡도: Docker 이미지 빌드, 컨테이너 레지스트리 관리, 오토스케일링 설정 등 인프라 세팅에 소요되는 리소스가 실제 비즈니스 로직(AI 모델링) 개발 시간을 잠식했습니다.

저는 이 문제를 해결하기 위해 Modal을 활용한 Serverless GPU 아키텍처를 설계하고 적용했습니다. 기존의 ‘Always-on’ 서버 방식 대신, 요청이 들어올 때만 수 초 내에 GPU 컨테이너를 프로비저닝하고 연산 후 즉시 종료하는 FaaS(Function as a Service) 모델을 채택했습니다. 이를 통해 트래픽이 불규칙한 초기 서비스 환경에서 불필요한 대기 비용(Idle Cost)을 100% 제거했으며, 사실상 무료(Free Tier 내)로 고성능 AI 모델을 서빙할 수 있는 구조를 완성했습니다. 일반적인 클라우드 배포 과정(Dockerfile 작성 → 빌드 → 레지스트리 업로드 → 배포)의 복잡성을 제거했습니다. Modal의 Pythonic Infrastructure 접근 방식을 통해, 파이썬 코드 내에서 라이브러리 의존성과 GPU 요구사항을 정의(@app.image, @app.function)했습니다. 그 결과, 로컬 개발 환경과 클라우드 배포 환경의 격차를 줄이고, 기능 추가부터 배포까지의 주기를 획기적으로 단축했습니다. 결과적으로 복잡한 DevOps 지식 없이도 안정적인 GPU 추론 API를 구축할 수 있었으며, 절약된 시간과 비용을 온전히 ‘Boss Effector’의 핵심 기능인 오디오 분석 알고리즘 고도화에 투자할 수 있었습니다.

너무 유익한 인터뷰 감사드립니다 지금까지 기타 소리 분석을 통한 이펙트 종류 및 파라미터 값 예측 모델을 만든 Queen 팀과의 인터뷰였습니다 앞으로도 Queen 팀의 더 큰 발전을 기대하며 오늘 인터뷰는 여기서 마치도록 하겠습니다 감사합니다