changi1122

문제 배경

초기에는 Spring 기반 API 서버가 Python 음악 분석 모델에 소켓 통신을 통해 요청을 전달하도록 구성했음. 그러나 서버 간 실행 순서나 타이밍 문제로 인해 요청이 간헐적으로 누락되거나 처리되지 않는 불안정한 상황이 발생함.

Kafka 도입 이유

이러한 통신 신뢰성 문제를 해결하기 위해 Kafka를 메시지 브로커로 도입함. Kafka는 큐 기반의 안정적인 메시지 전달 방식을 제공하며, 요청이 유실되지 않고 정확하게 전달되도록 보장할 수 있음.

결과

Kafka 도입 이후 큐 역할을 통해 요청 유실 문제가 해결되었음. 또한 서버 간 실행 순서에 영향을 받지 않고 비동기적으로 안정적인 요청 전송이 가능해짐.

문제 배경

초기 추천 시스템은 한 번에 하나의 요청만 처리할 수 있는 구조로 개발함. 이로 인해 여러 사용자가 동시에 추천 결과를 요청할 경우, 대기 시간이 발생하고 상태를 확인할 수 없는 문제가 있었음.

개선 방법

Python에서 ThreadPoolExecutor를 활용하여 Kafka로부터 수신한 각 메시지를 별도의 쓰레드에서 처리하도록 구조를 변경함. 이를 통해 요청을 병렬로 처리할 수 있도록 하여 시스템의 응답성과 처리량을 향상시킴.

결과

하나의 요청이 완료될 때까지 다른 요청이 대기하던 병목 현상이 제거되었고, 동시에 다수의 추천 요청을 원활히 처리할 수 있게 되었음.

문제 배경

프로젝트 진행 중 기능 구현에 중점을 두고, 테스트 코드에 대한 고려가 부족해 테스트 코드에 부족한 점이 많았음. 이로 인해 테스트 누락이나 예기치 못한 오류로 이어질 수 있었음.

개선 방법

리팩터링 과정에서 테스트 코드를 작성하여 기능별 검증을 자동화하고, Github Actions를 도입하여 커밋 시 테스트가 자동으로 실행되도록 CI 환경을 구성함. 더불어, 테스트 환경을 통합하고 ApplicationContext의 중복 생성을 방지하는 방식으로 테스트 속도와 효율성을 높임.

결과

코드 변경 시 즉시 기능 정상 여부를 검증할 수 있어 협업 시 안정성이 크게 향상됨.

ApplicationContext 생성 횟수 4회 -> 2회

문제 배경

음악 분석 시스템은 음원의 보컬을 추출한 후 시간대별 음높이를 예측하는 구조였음. 그러나 SPICE 모델을 통해 얻은 음높이 예측값이 지나치게 들쭉날쭉하여 신뢰도가 낮았고, 특히 배경음이 남아 이상치를 유발하는 문제가 있었음.

개선 방법

소리가 작은 구간을 제거하여 배경음을 줄이고, SPICE 외에도 CREPE, PESTO 등 다양한 모델의 결과를 시각화하여 비교함. 그 중 SPICE 모델을 선택한 뒤, 출력값의 신뢰도를 높이기 위해 8개의 인접 값을 평균내는 방식으로 대표값을 도출하는 방법을 고안함.

결과

이상치가 줄어들며 예측값의 안정성이 향상되었고, 그래프 시각화 결과에서도 변동성이 줄어든게 확인됨. 결과적으로 보다 신뢰할 수 있는 음높이 분석 결과를 얻을 수 있었음.