[나만무] 250704 일지

FastAPI로의 전환

그동안 Spring과의 처절한 사투를 벌이고 있었는데, 폴더 구조도 너무 복잡했고 코드 분석 및 이해도 쉽지 않았다. 더군다나 AI를 활용하려면 내가 코드를 이해하고 볼 줄 알아야 하는데, 거기에 너무나도 많은 시간이 들었다. 현재 우리 팀이 기획한 웹 게임의 데모 페이지를 만들어보려 했으나, 단순한 웹소켓 연결, API 호출조차 잘 되지 않았다.

 

그래서 고민 끝에 내가 알고리즘 문제를 풀 때에도 자주 사용하는 Python 기반의 FastAPI를 이용하기로 결정했다. 물론 이미 Spring으로 프로젝트가 세팅되어 있고, 작업도 진행해온 상태라 내가 만들 게임 모드에 대해서만 MSA(Microservice Architecture) 형식으로 FastAPI를 사용해보려고 한다.

 

Socket.io와의 만남

Spring을 사용할 때에는, 팀원 중 하나가 며칠동안 만들어 놓은 웹소켓을 가져다가 사용했는데, 설정 파일도 복잡했고, 경로가 자꾸 어긋나는지 연결도 잘 안되고 자잘한 문제가 많이 발생했다. 반면 FastAPI에서는 Socket.io를 이용해서 쉽고 빠르게 웹소켓을 구현할 수 있었다. Socket.io에서는 클라이언트-서버 간 emit을 통해 발신하고, on을 통해 수신하는 구조였는데, 매우 직관적이어서 이해하기가 편했다. 

 

웹소켓을 통한 데모 게임 구현

웹소켓을 통해 클라이언트-서버 간 메시지를 보낼 수 있는데, 이 메시지에 타입을 다르게 하여 타입마다 특정한 이벤트를 처리하게 만들 수 있다. 예를 들어 대기실의 방장이 모든 유저 준비 완료 후 게임 시작을 누르면 'Game Start' 형식의 메시지가 서버에 전송되고, 이를 받은 서버가 해당 형식에 맞는 이벤트를 동작하게 만드는 식이다. 서버 주도 하에, 모든 게임 중 유저의 화면을 동기화할 수 있다. 이때 유저 측에서는 timer 상태변수를 통해 대기 시간 등을 제어한다.

 

사용자의 노래 한 소절에서 실제 노래를 매칭하기까지

사용자가 키워드(아이유, 장범준 등)에 맞춰 부른 10초 분량의 노래 녹음 파일을 바탕으로, 현재는 ACRCloud Music Recognition을 활용해 인식된 곡이 실제 키워드와 맞는지를 비교하여 성공 여부를 판단하고 있다. 그런데 인식률이 '와! 잘 인식된다!' 싶으면서도 기깔나게 불렀는데도 실패하는 경우가 꽤 있었다. 맞게 불렀는데 실패 판정을 받으면 사용자 입장에서 굉장히 억울하고 화날 것이다.

 

따라서 하나의 api에 의존하기보다는, 다양한 fallback 방안을 마련해야 할 것 같다. 현재 생각하고 있는 방법은 사용자의 노래를 가사 텍스트로 바꿔 LLM에 질의를 보내는 것이다. large 모델을 쓰면 굉장히 정확하게 텍스트를 추출해준다고 하는데, python에서 모델을 깔아서 사용하면 노트북에서는 굉장히 느리다고 한다.. 그래서 openAI의 whisper api를 활용해야 할 것 같은데 비용이 나름 합리적인 편인 듯해 이를 고려해보고 있다. (100건 당 130원 정도)