메인 콘텐츠로 건너뛰기
2026-06-20ArchitectureMetadataDesign

의미론적 키 (Semantic Key) 기반 다국어 태그 시스템 설계

기존의 음악 태그 변경 매커니즘이 왜 중복된 쓰기(Writeback)를 쉽게 생성하는지 탐구하고, AI Music Organizer가 아키텍처 리팩토링을 통해 의미론적 키와 다국어 표시 매핑을 분리함으로써 진정한 언어 교차 음악 태그 시스템을 어떻게 구축했는지 설명합니다.

의미론적 키 (Semantic Key) 기반 다국어 태그 시스템 설계

수십만 곡의 음악에 자동으로 태그를 지정하는 것은 단순한 문자열 쓰기를 실행하는 것처럼 보일 수 있지만, 궁극적인 데이터 일관성과 다국어 지원을 추구할 때 우리는 종종 매우 고통스러운 리팩토링에 직면합니다. AI Music Organizer의 3세대 태그 아키텍처(V3)가 탄생한 것은 초기 아키텍처의 책임 혼란으로 인해 발생한 딜레마를 끝내기 위해서였습니다.

I. 기존 태그 아키텍처가 실패하는 이유

과거의 구현 파이프라인에서는 완전히 다른 몇 가지 책임을 혼동했습니다.

  1. 분류기가 출력하는 원시 value (예: 모델이 내뱉는 “Rock”)
  2. 시스템 내부 비교를 위한 Key
  3. 최종적으로 파일(ID3/FLAC)에 다시 기록되는 문자열
  4. 프론트엔드 UI에 표시되는 현지 텍스트

이로 인해 매우 심각한 비즈니스 문제점이 발생했습니다.

  • 불안정한 Key: /, ,, &와 같은 특수 문자는 무해화(Sanitize) 과정에서 반복적으로 다시 작성되어 동일한 태그가 다른 파이프라인에서 다른 문자열이 되어버립니다.
  • 오판으로 인한 중복 쓰기: 기본 오디오 파일의 태그가 실제로는 이미 “摇滚”(중국어로 Rock)이고 분석 엔진이 "Rock"을 생성한 경우 단순한 문자열 비교는 중복 패치("摇滚"을 "Rock"으로 변경 요청)를 생성합니다.
  • 사용자 지정의 어려움: "무해화된 문자열이 키"이기 때문에 사용자가 원래 영어 태그를 모국어로 하드 매핑하려는 경우 로직이 매우 취약해졌습니다.

II. V3 아키텍처의 핵심: Semantic Key

V3 아키텍처에서는 의미론적 키(Semantic Key) 개념을 도입하여 위의 네 가지 책임을 명확히 분리했습니다.

1. Semantic Key가 유일한 진실의 기준이 됨
시스템 내부는 더 이상 "摇滚"이라는 문자열 자체에 신경 쓰지 않습니다. 모든 비교와 흐름은 분류기가 제공하는 안정적인 기준선(즉, raw classifier value)을 완전히 기반으로 합니다. 강력한 계단식 관계를 가진 데이터(예: Funk / Soul---Contemporary R&B)에 대해서는 전역 무해화를 포기하고 독립적인 장르(Genre) 및 스타일(Style) Semantic Key로 분할하기만 했습니다.

2. 로캘 매핑을 통한 2계층 스토리지 도입
데이터베이스를 tag_value_catalog(기본 의미 테이블)와 tag_value_locale(다국어 매핑 테이블)로 구성했습니다.

  • Catalog는 "이 태그의 개념은 무엇인가?"에만 관심을 둡니다(예: id: 12, semantic_key: 'Rock').
  • Locale은 이 의미론적 개념을 중국어, 영어, 한국어 등 다양한 로캘에서 어떻게 렌더링할지에 중점을 둡니다(예: display_value: '록', write_value: '록').

[!IMPORTANT]

  • Semantic Key는 표시 책임을 지지 않습니다.
  • 로캘 매핑은 신원(고유 식별) 책임을 지지 않습니다.

III. 비교의 예술: 언제 다시 써야 하는가

V3 아키텍처에서 "이번에 정말 파일 메타데이터를 수정해야 하는가"를 결정하는 프로세스는 두 가지 핵심 단계로 나뉩니다.

단계 A: 의미론적 정렬 (Merge)

현재 분석 중인 raw classifier value가 몇 개이든 관계없이 시스템은 먼저 해당 semantic key를 추출하여 중복을 제거하고 기록되지 않은 초안(Draft)과 병합합니다.

단계 B: 쓰기 결정 (Diff)

이것이 가장 중요한 단계입니다! 파일 수정 패치를 생성할지 여부는 더 이상 semantic key에 의존하지 않습니다. 대신 desired write value(현재 사용자 환경 설정에서 기록될 것으로 예상되는 문자열)를 추출하고 file current value(현재 파일에서 읽은 실제 문자열)와 직접 비교합니다.

실제 시나리오의 예:

  • 시나리오 1: 파일에 원래 영어 Rock이 저장되어 있었고 현재는 한국어 인터페이스와 한국어 태그를 사용하도록 설정되어 있습니다.
    • Semantic Key: Rock
    • 파일 현재 값: Rock
    • 쓰기 희망 값: 록
    • 결론: 패치를 생성합니다! 시스템은 원본 파일을 완벽하게 다시 작성합니다.
  • 시나리오 2: 파일이 이미 록으로 다시 작성되었으며 시스템은 다시 Rock의 Semantic Key를 스캔합니다.
    • Semantic Key: Rock
    • 파일 현재 값: 록
    • 쓰기 희망 값: 록
    • 결론: 패치를 생성하지 않습니다! 이를 통해 디스크 I/O가 크게 절약되고 기록 로그의 순도가 보장됩니다.

결론

의미론적 키(Semantic Key) 분리를 기반으로 하는 태그 시스템은 다소 전통적으로 들릴 수 있지만 이는 이후의 “사용자 정의 매핑 규칙” 및 "복잡한 LLM 벡터 통합"을 지원하는 기반이 됩니다. 소프트웨어 엔지니어링은 종종 이와 같습니다. 결합된 책임을 정리하면 비즈니스 로직이 다시 상쾌할 정도로 명확해집니다.