싱송겜 음원 데이터셋 자동화 스크립트 설계 및 구현 총정리우리 팀이 만든 웹 게임인 '싱송겜'에서는 노래를 부르는 게임인 '키싱유' 뿐만 아니라, '랜덤 노래 맞추기'나 '평어 노래 맞추기'같은 노래를 듣는 게임 또한 존재한다. 그렇다면 근본적인 의문은, 과연 이 '게임에 사용할 노래를 어떻게 마련할 것인가?'일 것이다. 우리는 정상적인 서비스가 가능하려면 최소 500곡 이상의 데이터셋이 필요하다고 보았는데, 이를 위해 우리 팀 5명이 수작업으로 1시간 동안 매달려서 몇 곡의 음악 데이터셋을 만들었을까? 25곡이다. 한 명이 1시간 동안 이 작업에만 매달려서 5곡인데, 5명이 진행했으니 25곡이었다. 설계하고 구현해야 할 것이 산더미인 상태에서, 이 노래 데이터셋 제작에만 모든 팀원이 달라붙어 순수 시간..

키싱유 게임 설계 및 구현 총정리데모 데이에 앞서, 내가 개발한 내용들에 대한 질문이 들어왔을 때 대답을 잘하려면, 우선 나 스스로가 그것들을 잘 알고 있어야 한다고 생각한다. 물론 어떻게 돌아가는지는 지금도 설명할 수 있지만, 구체적으로 세세한 부분까지 명확하게 답을 내릴 수 있을까?에 대해서는 다시 한 번 돌아보면서 점검해야 할 필요성을 느꼈다. 그래서 키싱유 게임의 기술 스택과 구조부터 시작해 페이즈 타임라인, 라운드 오케스트레이션, 오디오 인식 및 스코어링 로직, 방/유저 관리 및 복구 전략 등을 정리해보는 시간을 가져보려고 한다. ⅰ. 기술 스택 및 구조프론트엔드: Next.js (App Router)게임 화면 렌더링, 오디오 녹음, 파형 시각화 및 Socket.IO-client로 실시간으로 ..

마지막 최종 리허설이 끝나다오늘은 드디어 마지막 최종 리허설이 끝나는 날이다. 장소도 실제 발표회 장소인 정글 스테이지에서 진행되었다. 우리 팀은 오디오를 사용하기 때문에, 오디오 체크를 위해 1시간 전에 미리 내려가서 확인을 마쳤다. 그리고 시간이 되자, 본격적인 리허설이 시작되었다. 역시나 우리 팀은 늘 그렇듯이 반의 첫 번째 순서로 발표를 마쳤다. 그런데 놀랍게도, 평소엔 한 마디도 듣기 어려웠던 칭찬들이 쏟아졌다. 물론 피드백도 함께 받았지만, 그래도 감동이었다. 칭찬의 물결은 다른 조 발표가 끝나고 나서도 이어졌다. 오늘은 칭찬을 듣는 날인가? 싶기도 했다. 요즘 '배드 캅 굿 캅'이 유행이라는데, 이게 떠오르기도 한다. 그렇게 마지막 최종 리허설은 모든 조가 칭찬을 들으면서 끝이 났다. 그래도..

두 번째 최종 발표 리허설, 첫 번째 차례의 무게는 무겁다오늘 이뤄진 두 번째 최종 발표 리허설은 반 교육장이 아닌, 203호에서 두 개 반이 모여서 진행했다. 그리고 공교롭게도 그 두 반 중 첫 번째 차례를 우리 팀이 맡게 되었다. 어제의 피드백을 반영해서 열심히 준비했기에 어느 정도 진전이 있지 않을까 싶었는데, 발표가 끝나고 나서도 어제와 같이 피드백 폭탄을 맞았다. 그래, 그런 자리니까 하면서도 쓴소리를 듣고 기분 좋은 사람은 없지 않을까. 그걸 감내하는 사람만 있을뿐. 그런데 다른 팀들 리허설을 진행하면서, 코치님들은 마찬가지로 피드백을 주시면서도 우리 팀과는 다르게 나아졌다고 하고, 좋아졌다고 하는 말을 아끼지 않으셨다. 그러면서 점점 드는 생각은, '우리 팀이 다른 조보다 별로인가?' 하는 ..

시연 및 발표 보완에 힘쓰자오늘부터는 중간 발표가 아닌, 최종 발표 리허설이 시작됐다. 이는 곧 정말 실제처럼 준비해서 발표를 해야 한다는 뜻이다. 우리 팀 역시 그렇게 준비를 해서 시연 및 발표를 진행했는데, 그렇게 만족스러운 평가를 받지는 못했다. 잘한 점은 이제 생략하고 진행하는 걸지는 모르겠지만 생각보다 피드백이 많이 들어왔고, 피드백이 길어질수록 뭔가 점점 작아지는 느낌을 받았다. 그래도 리허설이 끝난 다음, 피드백 받은 것들을 하나하나 다시 곱씹어보며 보완해보기로 했다. 당장 내일도 두 번째 리허설이 있기 때문에, 하루하루 개선을 통해 달라지는 모습을 보인다면 좋게 비춰질 것 같다. PPT 디자인을 갈아엎고, 우리가 보여주고자 하는 부분을 매우 크게 확대해서 보여주게 한다던지, 오디오 볼륨도 ..

마지막 중간발표를 마치다마지막 중간발표는 교육장에서 진행됐는데, 우리가 지난 한 주 동안 게임에 맞게 확연히 달라진 모습을 만든 UI를 가지고 시연을 진행했다. 많은 공을 들였기에 칭찬을 받지 않을까 기대했지만, 이 자리는 사실 칭찬보다는 피드백을 받는 자리였기에 이후 나오는 피드백들을 듣고, 겸허하게 수용하기로 했다. 다행히 기능 상에서 들어온 피드백은 없었고, 대부분 UI/UX적인 사소한 피드백들을 고치는 것들 위주였다. 우리가 착각하는 게 아니라면, 그만큼 우리가 잘 만든 것이라고 생각하기로 했다. 이외에도 발표 준비가 잘 안되어 있다는 피드백도 받았는데, 이는 준비를 많이 안했기 때문에 벌어진 일이라는 생각이 들었다. 그래서 팀장 형이 발표 흐름을 전달해주면 그걸 가지고 스크립트를 작성해서 넘겨주..

데이터셋 자동화 스크립트 재정비하기그동안 우리 프로젝트의 다른 게임모드들은 기존에 만들어 놓은 자동화 스크립트를 이용해 만들어진 데이터셋을 통해 게임을 진행하고 있었는데, 그 수는 약 800여 곡 정도 된다. 그런데 일부 곡은 노래가 나오지 않고, 간주 부분 등이 섞여 있는 경우들이 있었다. 또 스크립트 진행 중에도, 목표로 하는 노래 제목-가수의 음원을 제대로 찾지 못하고, 엉뚱한 음원을 가져다가 작업하는 경우들도 종종 발생했다. 이를 해결하기 위해서는 (1) 노래제목-가수에 따른 음원을 제대로 찾고, (2) 그 음원에 대해 하이라이트, 또는 적어도 노래가 나오는 부분 30초를 제대로 잘라내야 했다. 우선 어떻게 노래제목-가수명에 맞는 정확한 음원을 찾아낼 것인가에 대해서는, 검색 기준을 엄격하게 함으..

서버가 시작하면 데이터를 RDS에 넣도록 만들기현재 AWS RDS를 사용하고 있는데, 여기에 키싱유 게임에서 필요로 하는 키워드 데이터를 받아오려면 당연히 이 RDS에 데이터셋이 존재해야 한다. 이를 위해 csv 파일을 미리 만들어 놓았는데, 약 200여 개의 키워드 데이터셋이 나열되어 있다. 내가 처음에 생각했던 건 AWS RDS 인스턴스에서 직접 csv 파일을 통해 데이터셋을 추가하는 것이었는데, 그러면 현재 데이터셋이 확정되지 않은 상태에서 이 csv 파일이 바뀔 때마다 계속 RDS 인스턴스를 켜서 작업을 해줘야 하는 번거로움이 있을 것 같았다. 그래서 FastAPI 프로젝트 루트 디렉토리에 csv파일을 넣고, 서버 시작 시 일괄적으로 해당 csv 파일의 데이터셋을 RDS의 빈 테이블로 초기화된 k..