Spiaminto
일본어 곡 제목, 가수 명 한글 검색 구현 후기 본문
현재 운영 중인 제이노티 서비스에는 일본 곡을 한국어로 검색하는 기능이 있습니다. 이 기능의 목표는 일본어로 작성된 곡명 및 가수명을 한국어로 검색할 수 있도록 하는 것이며, 부정확한 번역 데이터와 다양한 입력 방식에 대해 가능한 직관적이고 정확한 결과를 제공하는 데 주된 관심을 두었습니다.
노래방 기계는 자체적으로 일본곡을 검색하는 기능을 제공하지 않으며, 각 브랜드 홈페이지에서도 한글 검색은 제한적으로만 가능했기 때문에 해당 기능을 개발하게 되었습니다.
1. 문제
1.1 부정확한 번역 데이터
현재 데이터베이스에 저장된 곡 데이터는 약 11000개 이며, 이 모든 곡을 단시간에 번역하는것은 불가능하다고 판단했기 때문에 GPT 를 이용 하여 번역 데이터를 생성하였습니다.
사용한 모델은 gpt-4o-mini 이며 현재 새로 추가되는 곡은 AWS 람다 내부에서 바로바로 번역 데이터를 생성하여 저장하고 있습니다.
번역 데이터의 경우 '만찬가', '무지개', '네, 기꺼이!', '귀신의 잔치' 와 같이 거의 정확한 결과도 있는 반면, '벚꽃 맑은날' 같은 아쉬운 (원제: 벚꽃맑음) 결과나 '노려보는 소녀' (원제: 눈싸움) 등 부정확한 결과도 상당수 존재 하였기 때문에 이 점을 고려하여 검색방식을 설계해야 했습니다.
1.2 번역의 비일관성
위 표의 첫번째 곡인 'ずうっといっしょ!' 란 곡의 경우 '쭉 함께', '평생 함께', '계속 함께' 등 여러가지 곡명으로 번역될 수 있음을 알 수 있습니다. 더욱이 해당 번역명이 아닌 '즛토 잇쇼' 라는 일본어 발음(이하 발음명)으로 기억하는 사람들도 있을수 있다고 생각하였습니다.
검색 대상이 '한국어 단어' 가 아닌, '일본어 단어 또는 문장이 한국에서 불리는 방식' 인 이상 검색 입력 데이터가 일관되지 않고, 부정확할 수 있습니다. 저는 가능한 모든 입력 방식에 대해 납득 가능한 결과를 제공하고 싶었습니다.
2. 유사도 검색
위의 문제 상황을 해결하기 위해 다음과 같은 방안을 도출하였습니다.
- 곡의 제목을 유사도 기반으로 검색한다.
- 인기곡은 수기입력 데이터를 통해 검색 결과를 보정한다.
해당 방안의 구현은 다음과 같습니다.
2.1 pg_bigm 을 사용한 유사도 검색 구현
https://github.com/pgbigm/pg_bigm (리포지토리)
https://github.com/pgbigm/pg_bigm/blob/REL1_2_STABLE/docs/pg_bigm_en.md (리드미)
postgreSQL 에서 영, 한, 일본어에 대한 GIN 인덱싱 및 유사도 검색을 지원하는 모듈인 pg_bigm 을 통해 유사도 검색을 구현할 수 있습니다.
유사도 검색을 사용하면 '벚꽃 맑음' 키워드로 '벚꽃 맑은 날' 을 검색할 수 있게 되어 부정확한 번역 데이터의 단점을 어느정도 메꿀 수 있습니다. 검색 속도도 이정도면 괜찮다고 생각합니다.
하지만 유사도 검색을 도입함에 따라 LIKE 검색과 다르게 연관성 있는 모든 검색결과를 반환하므로 보다 더 정확한 검색결과만을 남길 방법이 필요했습니다.
pg_bigm의 유사도 검색시, 일정 유사도 이하의 결과를 제외하는 '유사도 한계값 (similarity_limit)' 의 기본값은 0.3 입니다. 현재 저의 DB 에서는 이 값을 0.4 로 올려 사용하고 있으며, 필요한 경우 더 높은 값으로 검색 결과를 제한하기도 합니다.
발음명 검색의 경우 위와같이 유사도 한계값을 0.5로 제한하고 있습니다.
2.2 수기 입력 데이터를 통한 검색 결과 보정
현재 노래방 인기곡 차트및 기타 정보를 참고하여 일부 곡에 추가로 수기입력 데이터를 입력하였습니다. 수기입력 데이터의 경우 노래제목과 가수명에 따라 검색방법이 다릅니다.
제목의 경우 유사도 검색을 그대로 사용하나 가수명의 경우 한 가수가 여러개의 곡을 가지는점, 가수명이 노래제목보다 정확하게 기억하기 쉬운점, 가수명의 약칭이 존재하는점 (녹황색사회 - 료쿠샤카) 을 고려하여 별도 컬럼으로 분리후 LIKE 연산자를 통해 별도로 검색하여 기존의 유사도 검색결과와 합쳐 중복제거후 검색결과를 반환합니다. LIKE 연산자의 경우 유사도 검색과 달리 데이터의 길이 등에 검색 결과가 영향을 받지 않기때문에 예상 결과를 늘어놓아 작성할 수 있었습니다.
매주 추가되는 신곡은 기존DB에 해당 곡 제목 또는 가수명의 수기 데이터가 존재할 시 해당 값을 바로 사용하여 저장하도록 하였습니다. 현재 한쪽 브랜드 노래방에 추가된 신곡은 높은 확률로 다른 브랜드 노래방에도 추가되기 때문에 곡 제목의 경우 해당 처리를 통해 수기입력 횟수를 줄일 수 있었습니다.
3. 유사도 검색에 따른 누락 결과 보완
유사도 검색 도입후 검색 대상의 길이가 긴 경우, 대상의 일부만 입력할 경우 유사도 수치가 낮게나와 검색 결과가 누락되는 문제가 발생했습니다.
'에어맨' 을 입력하여 '에어맨이 쓰러지지 않아' 를 검색하고 싶을때는 유사도가 0.23 이기 때문에 결과를 얻을 수 없습니다. '에어맨이 쓰' 까지 입력하면 유사도가 0.4를 넘어 검색할 수 있지만 사용자 입장에서 명확한 기준을 알 수 없기 때문에 원하는 검색결과를 얻기위해 여러번 검색을 시도해야 하는 상황이 발생할 수 있습니다. 일본곡의 경우 문장의 형태를 가지는 긴 노래 제목이 종종 있기 때문에 해당 상황 발생시 재시도 횟수를 줄일 수 있도록 '추가검색' 기능을 넣었습니다.
추가검색기능은 유사도가 아닌 LIKE 연산자를 통해 검색합니다. 일종의 보험 같은 기능으로 버튼 클릭 한번에 즉시 검색하여 검색어를 수정하지 않고 바로 결과를 확인할 수 잇도록 하였습니다.
4. 결론
이 외에도 대소문자구별, 독음우선순위 등 다양한 상황을 고려해가며 만든 기능이지만 이렇게 정리하여 작성하다보니 부족한 부분이 많이 보이네요. 애창곡을 저장하는 기능이 검색기능을 기반으로 만들어져있기 때문에 보다 직관적으로 사용할 수 있고 정확한 결과를 제공할 수 있도록 많이 고민했습니다. 애초에 번역 데이터가 부정확해 쓰러지기 쉬운 모래성을 억지로 쌓아올리는 듯한 느낌이 드는건 어쩔수 없네요. 사용자가 많지 않아 피드백을 받을 기회가 적었던것이 아쉽지만 앞으로 계속 개선해나가려 합니다.
'학습정리(공개)' 카테고리의 다른 글
ElasticBeanstalk 배포 서비스에 Cloudflare https 적용 및 보안관련 수정 (0) | 2025.02.20 |
---|---|
Selenium Java 의 java.util.concurrent.TimeoutException 문제와 Playwright (0) | 2024.09.25 |
Supabase 무료플랜 임베딩 데이터 용량 초과 대응후기 (0) | 2024.09.12 |
JPA 쓰기 지연 저장소 flush 시점 관련 테스트 및 정리. (0) | 2024.06.06 |
아마존 리눅스 2023 Cloudwatch 로그 스트리밍 구성 설정 마이그레이션 후기 (0) | 2024.04.23 |