sodalive-backend-spring-boot/docs/20260506_번역언어감지효율화구상.md

번역/언어감지 효율화 구상

배경

• 현재 구조는 도메인별 번역 테이블과 이벤트 기반 Papago 호출이 혼재되어 있다.
• 생성/수정 이벤트 번역과 조회 시 캐시 미스 번역이 동시에 존재해 동일 원문이 중복 번역될 수 있다.
• 번역 저장 로직은 ContentTranslation, SeriesTranslation, AiCharacterTranslation, OriginalWorkTranslation, CategoryTranslation 등으로 분산되어 있으며, 조회/upsert 패턴이 반복된다.
• Papago 호출은 텍스트와 대상 locale 단위로 순차 실행되어 대상 하나가 여러 HTTP 요청으로 확장된다.

목표

• Papago 호출 수와 비용을 줄인다.
• 조회 API에서 Papago 호출로 인한 응답 지연을 줄인다.
• 번역 저장/조회 로직의 중복을 줄이고, 향후 번역 provider 교체가 가능하도록 한다.
• 기존 API 응답 스키마는 유지하고, DB 변경은 단계적으로 적용한다.

구현 항목

• TranslationProvider 인터페이스와 Papago provider 구현을 분리한다.
• translation_memory, translation_job, language_detection_result 테이블을 추가한다.
• 조회 fallback의 직접 Papago 호출을 제거하고 누락 번역 job 예약으로 전환한다.
• 생성/수정 이벤트 번역을 translation_job 기반 워커 처리로 전환한다.
• TranslationMemory 결과를 기존 JSON/scalar read model로 materialize한다.
• 목록 조회 병목 측정 후 필요한 도메인에만 hot column을 추가한다.

접근안 비교

접근안 A: 현재 구조 유지 + 중복 방지 보강

• 도메인별 번역 테이블은 유지한다.
• 번역 전 기존 번역 조회와 unique 제약을 강화한다.
• 조회 fallback에서 번역 생성 대신 번역 작업만 예약하도록 바꾼다.

장점:

• 변경 범위가 가장 작다.
• 기존 코드와 데이터 마이그레이션 위험이 낮다.

단점:

• 도메인별 중복 저장/로직 구조는 그대로 남는다.
• 원문이 같아도 도메인별로 재번역될 수 있다.

접근안 B: 원문 해시 기반 Translation Memory + 비동기 작업 큐 추가

• 원문 텍스트를 정규화하고 source_hash로 중복을 제거한다.
• translation_memory에 원문/언어쌍/번역 결과를 저장한다.
• 도메인 엔티티는 translation_job을 생성하고, 워커가 Papago를 호출해 결과를 저장한다.
• 조회 API는 Papago를 직접 호출하지 않고 기존 번역을 반환하거나 미번역 상태를 유지한다.

장점:

• 동일 원문 재번역을 줄일 수 있다.
• 조회 응답 지연을 안정적으로 제거할 수 있다.
• 기존 도메인별 번역 테이블을 당장 제거하지 않아도 단계 적용이 가능하다.

단점:

• 작업 큐, 상태 관리, 재시도 정책이 필요하다.
• 생성 직후 번역이 아직 없을 수 있으므로 UX/응답 정책을 정해야 한다.

접근안 C: 도메인별 번역 테이블을 공통 번역 저장소로 통합

• 모든 번역 결과를 translation_entry 같은 공통 테이블에 저장한다.
• resource_type, resource_id, field_key, locale, translated_text 또는 JSON payload로 도메인별 필드를 표현한다.
• 기존 도메인별 번역 테이블은 읽기 호환 기간 후 제거한다.

장점:

• 저장/조회/upsert 로직을 크게 단순화할 수 있다.
• 새 번역 대상 추가 비용이 줄어든다.

단점:

• 마이그레이션 위험이 가장 크다.
• 도메인별 payload 검증과 타입 안정성이 약해질 수 있다.
• 기존 조회 쿼리와 응답 조립 로직 영향 범위가 넓다.

권장 방향

• 최종 구현방식은 접근안 B를 중심으로 하되, 조회 성능을 위해 도메인별 read model을 유지하는 하이브리드 구조로 한다.
• 기존 번역 데이터를 배제할 수 있어도 모든 번역 결과를 정규화 row만으로 저장하는 방식은 채택하지 않는다.
• 이유는 Papago 호출 수 절감은 원문 해시 기반 TranslationMemory가 담당하고, API 조회 성능은 entityId + locale 단위 read model이 담당하는 분리가 가장 효율적이기 때문이다.
• 2차로 운영 안정화 후 도메인별 read model의 중복을 줄이되, 조회 경로가 복잡해지는 전면 통합은 실제 병목이 확인될 때만 진행한다.

최종 구현방식

설계 원칙

• 번역 원장은 정규화한다.
• 조회 결과는 도메인별로 materialize한다.
• Papago 호출은 사용자 요청 스레드에서 수행하지 않는다.
• JSON payload는 원장이 아니라 조회 최적화용 read model로만 사용한다.

저장 구조

translation_memory

• 동일 원문을 반복 번역하지 않기 위한 공통 번역 캐시이다.
• 원문은 의미가 바뀌지 않는 선에서 공백, 줄바꿈, Unicode 표현을 정규화한다.
• 주요 컬럼:
  • id
  • source_hash
  • source_text
  • source_language
  • target_language
  • translated_text
  • provider
  • provider_version
  • normalization_version
  • created_at
  • updated_at
• unique 제약:
  • (source_hash, source_language, target_language, provider, normalization_version)
• 역할:
  • Papago 호출 수 절감의 핵심 원장이다.
  • 도메인이 달라도 원문과 언어쌍이 같으면 같은 번역을 재사용한다.

translation_job

• 번역 실행 상태를 관리하는 durable job 테이블이다.
• 현재 @Async 이벤트만으로 처리하던 작업을 명시적인 상태 모델로 바꾼다.
• 주요 컬럼:
  • id
  • resource_type
  • resource_id
  • field_key
  • source_hash
  • source_language
  • target_language
  • status
  • retry_count
  • last_error_message
  • next_retry_at
  • created_at
  • updated_at
• 중복 방지:
  • 활성 상태 기준 (resource_type, resource_id, field_key, target_language, source_hash) 중복 생성을 막는다.
• 역할:
  • 중복 작업 방지, 재시도, 실패 추적, 운영자 재처리를 담당한다.

language_detection_result

• 언어 감지 결과를 원본 엔티티에만 저장하지 않고 별도 캐시/이력으로 관리한다.
• 주요 컬럼:
  • id
  • source_hash
  • source_text_sample
  • detected_language
  • provider
  • confidence
  • normalization_version
  • created_at
• 역할:
  • 짧은 문구나 반복 문구의 감지 호출을 줄인다.
  • 원본 엔티티의 languageCode는 기존 호환 필드로 유지할 수 있다.

도메인별 번역 read model

• ContentTranslation, SeriesTranslation, AiCharacterTranslation, OriginalWorkTranslation처럼 여러 필드가 묶인 응답은 JSON payload read model을 유지한다.
• CategoryTranslation, ContentThemeTranslation, SeriesGenreTranslation처럼 단일 문자열만 필요한 대상은 scalar column을 유지한다.
• JSON payload는 translation_memory를 조립한 결과를 저장하는 materialized cache로 본다.
• provider, retry, source hash 같은 실행/원장 메타데이터는 JSON payload에 넣지 않는다.

JSON 유지 여부

• JSON payload 저장은 유지한다.
• 단, JSON을 번역의 최종 원장으로 보지 않고 API 응답을 빠르게 만들기 위한 read model로 격하한다.
• 현재 조회 패턴은 JSON 내부 검색이 아니라 resourceId + locale로 1-row 조인 후 payload를 읽는 방식이므로, 정규화 row를 매번 pivot하는 것보다 조회 경로가 단순하다.
• 목록 API에서 제목이나 이름 하나만 자주 읽는데 payload가 커지는 도메인은 translated_title, translated_name 같은 hot column을 선택적으로 추가한다.
• 단일 문자열 번역 대상은 JSON으로 바꾸지 않는다.

처리 흐름

• 생성/수정 시 번역 대상 필드를 세그먼트로 추출한다.
• 세그먼트별 source_hash를 계산한다.
• 언어 정보가 없으면 language_detection_result를 조회하고, 없을 때만 감지 작업을 수행한다.
• 대상 언어별로 translation_memory를 먼저 조회한다.
• cache hit이면 Papago를 호출하지 않고 read model materialize 단계로 넘어간다.
• cache miss이면 translation_job을 PENDING으로 생성한다.
• 워커가 job을 가져와 Papago를 호출하고 translation_memory에 저장한다.
• 대상 resource의 모든 필드 번역이 준비되면 도메인별 read model JSON 또는 scalar row를 갱신한다.

조회 정책

• 조회 API에서는 Papago를 직접 호출하지 않는다.
• 번역 read model이 있으면 해당 번역을 반환한다.
• 번역 read model이 없으면 원문 또는 기존 fallback locale을 반환한다.
• 누락된 번역은 조회 요청에서 job만 예약할 수 있으며, 외부 API 응답을 기다리지 않는다.

최종 선택 요약

영역	최종 선택	이유
Papago 중복 호출 방지	translation_memory 정규화	동일 원문/언어쌍 재사용이 가능하다.
번역 실행	translation_job 비동기 큐	재시도와 실패 추적이 가능하고 조회 응답을 지연시키지 않는다.
다중 필드 응답 저장	JSON read model 유지	entityId + locale 1-row 조회가 가능해 API 조립이 단순하다.
단일 문자열 번역 저장	scalar column 유지	JSON보다 단순하고 불필요한 변환 비용이 없다.
자주 읽는 일부 필드	선택적 hot column 추가	큰 JSON payload 전체 로딩 비용을 줄일 수 있다.
provider 확장	TranslationProvider 인터페이스	Papago 의존을 낮추고 향후 교체를 쉽게 한다.

상세 정책

운영자 재처리

• 관리자/운영 API에서는 번역 상태를 확인하고 재번역을 요청할 수 있게 한다.
• 실패한 job은 원문, 대상 언어, provider, 실패 사유, 재시도 횟수를 함께 보여준다.

중복 방지 정책

• TranslationMemory는 (source_hash, source_language, target_language, provider, normalization_version)에 unique 제약을 둔다.
• TranslationJob은 활성 상태 기준 (resource_type, resource_id, field_key, target_language, source_hash) 중복 생성을 막는다.
• 동일 작업이 동시에 들어오면 기존 PENDING 또는 RUNNING 작업을 재사용한다.

오류와 재시도

• Papago 실패 시 TranslationJob.status = FAILED와 실패 사유를 저장한다.
• 일시 오류는 지수 백오프로 재시도한다.
• 영구 오류나 빈 원문은 재시도하지 않는다.
• 재시도 횟수를 초과하면 운영자가 재시도할 수 있도록 별도 상태로 남긴다.

운영 안정화 보완 작업

• 현재 TranslationJobWorker.claimNextJob()는 PENDING job을 조회한 뒤 RUNNING으로 변경한다.
• 다중 애플리케이션 인스턴스에서 같은 job을 동시에 조회할 수 있으므로 운영 반영 전 claim을 원자화한다.
• 권장 방식은 MySQL 기준 SELECT ... FOR UPDATE SKIP LOCKED 또는 UPDATE ... WHERE status = 'PENDING' ... LIMIT 1 기반 원자적 claim이다.
• job row를 여러 인스턴스가 나눠 처리하는 목적에는 FOR UPDATE SKIP LOCKED 또는 atomic update claim을 우선한다.
• ShedLock은 스케줄러 실행 자체의 중복을 막는 용도로는 적합하지만, job row 단위 분산 claim을 대체하지는 않는다.
• Papago 호출은 DB lock을 잡은 트랜잭션 밖에서 수행하고, claim/완료/실패 상태 변경만 짧은 트랜잭션으로 처리한다.
• FAILED로 즉시 종료하는 최소 구현에서 지수 백오프 기반 재시도 정책으로 보완한다.
• 재시도 정책은 retry_count, next_retry_at, last_error_message를 함께 갱신하고, 최대 재시도 초과 상태를 운영자가 확인할 수 있게 한다.
• worker 처리량과 부하를 운영 설정으로 제어할 수 있도록 fixed-delay-ms, tick당 처리 건수, 최대 재시도 횟수, Papago 호출 rate limit을 설정화한다.
• 운영 관측을 위해 pending/running/failed/completed count, oldest pending age, 처리 성공/실패 수, Papago 호출 시간, materialize 실패 수를 로그 또는 metric으로 남긴다.

번역 job 실행 주기 조정 검토

• 현재 구현은 sodalive.translation-job.fixed-delay-ms 설정이 없으면 기본 5000ms fixed delay로 실행된다.
• 콘텐츠가 지속적으로 올라오는 서비스 형태가 아니므로 기본 주기를 10분(600000ms)으로 늘리는 방향을 검토한다.
• fixedDelay는 작업 종료 후 다음 실행까지의 지연 시간이므로 실제 실행 간격은 처리 시간 + 10분이 된다.
• 정확히 벽시계 기준 10분마다 실행해야 한다면 cron + 스케줄 중복 방지 lock을 검토하고, 처리 후 10분 쉬는 정책이면 fixedDelay를 사용한다.
• 10분 주기의 장점은 불필요한 DB polling과 Papago 호출 burst 가능성을 줄이고, 낮은 트래픽 환경에서 백그라운드 작업 부하를 완화하는 것이다.
• 10분 주기의 단점은 번역 read model 반영 지연이 최대 10분 이상으로 늘어날 수 있다는 점이다.
• 조회 정책이 원문 즉시 반환 + job 예약 방식이므로 API 응답 실패로 이어지지는 않지만, 사용자는 첫 조회 후 최대 다음 worker 실행까지 원문을 볼 수 있다.
• 현재 tick당 최대 처리 건수가 20건이면 10분 주기에서 burst backlog 회복 속도가 느려진다.
• 10분 주기를 적용하려면 tick당 처리 건수를 운영 설정으로 조정하거나, pending backlog가 특정 기준을 넘을 때 수동/운영자 재처리 또는 임시 짧은 주기 전환이 가능해야 한다.
• 생성 직후 번역 노출이 중요한 리소스가 발견되면 해당 리소스만 별도 즉시 처리 정책을 두고, 일반 조회 fallback은 10분 주기를 유지한다.
• 1차 운영 기준은 fixed-delay-ms = 600000, 원문 fallback 허용, backlog/oldest pending age 모니터링으로 둔다.

단계별 적용

• 1단계: TranslationProvider 인터페이스를 만들고 기존 PapagoTranslationService를 provider 구현으로 감싼다.
• 2단계: translation_memory, translation_job, language_detection_result 테이블을 추가한다.
• 3단계: 조회 fallback의 직접 Papago 호출을 제거하고, 누락 번역 job 예약 방식으로 전환한다.
• 4단계: 생성/수정 이벤트 번역을 translation_job 기반 워커로 전환한다.
• 5단계: TranslationMemory 결과를 기존 JSON/scalar read model로 materialize한다.
• 6단계: 목록 조회에서 큰 JSON payload 로딩이 병목이면 hot column을 선택적으로 추가한다.

검증 관점

• 동일 원문을 여러 도메인에서 번역해도 Papago 호출이 한 번만 발생하는지 확인한다.
• 조회 API에서 Papago 호출이 발생하지 않는지 확인한다.
• 생성/수정 이벤트 후 번역 작업이 중복 생성되지 않는지 확인한다.
• Papago 장애 시 원 API 응답이 실패하지 않고 작업 상태만 실패로 남는지 확인한다.
• 기존 API 응답 스키마가 바뀌지 않는지 확인한다.

남은 결정사항

• 번역이 없는 조회 응답은 원문을 반환한다.
• 실시간 번역이 꼭 필요한 엔드포인트는 1차 구현 범위에 포함하지 않는다. 단, 생성 직후 번역 노출이 중요한 리소스가 확인되면 해당 리소스만 별도 즉시 처리 정책을 검토한다.
• JSON read model을 장기 유지하되, hot column이 필요한 목록 API를 측정으로 결정해야 한다.
• Papago 외 provider는 1차 구현에서는 인터페이스만 준비하고 실제 추가 provider는 범위에서 제외한다.

검증 기록

• 2026-05-06: 코드 탐색 결과를 바탕으로 현재 번역 저장 구조, Papago 호출 흐름, 외부 아키텍처 패턴을 비교해 설계 초안을 작성했다.
• 2026-05-06: 문서 내 미완성 placeholder, 상충되는 범위, 구현 전제 누락 여부를 점검했다.
• 2026-05-06: 기존 번역 데이터 보존 제약을 배제해도 TranslationMemory + TranslationJob + JSON read model 하이브리드가 최종 구현방식으로 적합한지 재평가하고 문서에 반영했다.
• 2026-05-06: TDD RED 확인: ./gradlew test --tests 'kr.co.vividnext.sodalive.i18n.translation.SourceTextNormalizerTest' --tests 'kr.co.vividnext.sodalive.i18n.translation.TranslationJobSchedulerTest' --tests 'kr.co.vividnext.sodalive.content.LanguageDetectionCacheServiceTest' 실행 시 SourceTextNormalizer, TranslationJobRepository, TranslationJobScheduler, LanguageDetectionResultRepository, LanguageDetectionCacheService 미구현으로 compileTestKotlin 실패를 확인했다.
• 2026-05-06: 구현 후 동일 targeted test 명령을 재실행해 BUILD SUCCESSFUL을 확인했다. 정규화/해시, 누락 번역 job 생성, 언어 감지 캐시 hit 시 provider 미호출 동작을 검증했다.
• 2026-05-06: 전체 회귀 검증으로 ./gradlew test와 ./gradlew build를 실행해 모두 BUILD SUCCESSFUL을 확인했다. build에는 ktlint main/test/sourceSet check가 포함되어 스타일도 함께 검증됐다.
• 2026-05-06: PapagoTranslationService|translationService\.translate|papagoTranslationService\.translate|TranslateRequest 검색으로 직접 번역 호출이 PapagoTranslationService, TranslationProvider, TranslationJobWorker, DTO, 지원 언어 목록 참조에만 남아 있음을 확인했다. 조회 fallback과 LanguageTranslationListener에는 직접 Papago 번역 호출이 남아 있지 않다.
• 2026-05-06: MySQL unique 제약은 활성 상태 partial unique를 표현할 수 없으므로 완료 job이 있는 동일 key 재예약 시 중복 insert가 발생하지 않도록 repository 파생 쿼리 기반 회귀 테스트를 추가했다. RED는 중복 job 조회 메서드 미구현으로 compileTestKotlin 실패, GREEN은 동일 테스트 BUILD SUCCESSFUL로 확인했다.
• 2026-05-06: 최종 확인에서 Kotlin LSP 서버가 설정되어 있지 않아 lsp_diagnostics는 No LSP server configured for extension: .kt로 실행할 수 없었다. 대체 검증으로 ./gradlew test, ./gradlew build, 신규 focused test --rerun-tasks를 실행했고 모두 BUILD SUCCESSFUL을 확인했다.
• 2026-05-06: 운영 안정화 보완 구현으로 TranslationJobWorker 기본 fixed delay를 10분(600000ms)으로 변경하고, MySQL FOR UPDATE SKIP LOCKED 기반 job id claim, 실패 시 PENDING 재전환 + next_retry_at backoff + 최대 재시도 후 FAILED 전환을 적용했다. RED는 TranslationJobWorkerTest에서 원자 claim 메서드 미구현으로 compileTestKotlin 실패, GREEN은 동일 focused test BUILD SUCCESSFUL로 확인했다.

2026-05-06 구현 DDL

운영 MySQL은 spring.jpa.hibernate.ddl-auto=validate이므로 아래 DDL을 선반영해야 한다. created_at, updated_at은 BaseEntity의 createdAt, updatedAt과 매핑된다.

CREATE TABLE translation_memory (
    id BIGINT NOT NULL AUTO_INCREMENT COMMENT '번역 메모리 ID',
    source_hash VARCHAR(64) NOT NULL COMMENT '정규화 원문 SHA-256 해시',
    source_text TEXT NOT NULL COMMENT '정규화 원문 텍스트',
    source_language VARCHAR(10) NOT NULL COMMENT '원문 언어 코드',
    target_language VARCHAR(10) NOT NULL COMMENT '대상 언어 코드',
    translated_text TEXT NOT NULL COMMENT '번역 결과 텍스트',
    provider VARCHAR(50) NOT NULL COMMENT '번역 provider 이름',
    provider_version VARCHAR(50) NOT NULL COMMENT '번역 provider 버전',
    normalization_version VARCHAR(20) NOT NULL COMMENT '정규화 규칙 버전',
    created_at TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP COMMENT '생성 시각',
    updated_at TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '수정 시각',
    PRIMARY KEY (id),
    UNIQUE KEY uk_translation_memory_source_target_provider (
        source_hash,
        source_language,
        target_language,
        provider,
        normalization_version
    ),
    KEY idx_translation_memory_source_hash (source_hash),
    KEY idx_translation_memory_target_language (target_language)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE translation_job (
    id BIGINT NOT NULL AUTO_INCREMENT COMMENT '번역 작업 ID',
    resource_type VARCHAR(50) NOT NULL COMMENT '번역 대상 리소스 타입',
    resource_id BIGINT NOT NULL COMMENT '번역 대상 리소스 ID',
    field_key VARCHAR(80) NOT NULL COMMENT '번역 대상 필드 키',
    source_hash VARCHAR(64) NOT NULL COMMENT '정규화 원문 SHA-256 해시',
    source_text TEXT NOT NULL COMMENT '정규화 원문 텍스트',
    source_language VARCHAR(10) NOT NULL COMMENT '원문 언어 코드',
    target_language VARCHAR(10) NOT NULL COMMENT '대상 언어 코드',
    status VARCHAR(20) NOT NULL COMMENT '번역 작업 상태',
    retry_count INT NOT NULL COMMENT '재시도 횟수',
    last_error_message TEXT DEFAULT NULL COMMENT '마지막 오류 메시지',
    next_retry_at TIMESTAMP NOT NULL COMMENT '다음 재시도 가능 시각',
    created_at TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP COMMENT '생성 시각',
    updated_at TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '수정 시각',
    PRIMARY KEY (id),
    UNIQUE KEY uk_translation_job_resource_field_target_hash (
        resource_type,
        resource_id,
        field_key,
        target_language,
        source_hash
    ),
    KEY idx_translation_job_status_retry (status, next_retry_at),
    KEY idx_translation_job_resource (resource_type, resource_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE language_detection_result (
    id BIGINT NOT NULL AUTO_INCREMENT COMMENT '언어 감지 결과 ID',
    source_hash VARCHAR(64) NOT NULL COMMENT '정규화 원문 SHA-256 해시',
    source_text_sample VARCHAR(500) NOT NULL COMMENT '정규화 원문 샘플 텍스트',
    detected_language VARCHAR(10) NOT NULL COMMENT '감지된 언어 코드',
    provider VARCHAR(50) NOT NULL COMMENT '언어 감지 provider 이름',
    confidence DOUBLE DEFAULT NULL COMMENT '언어 감지 신뢰도',
    normalization_version VARCHAR(20) NOT NULL COMMENT '정규화 규칙 버전',
    created_at TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP COMMENT '생성 시각',
    updated_at TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '수정 시각',
    PRIMARY KEY (id),
    UNIQUE KEY uk_language_detection_result_hash_provider_version (
        source_hash,
        provider,
        normalization_version
    ),
    KEY idx_language_detection_result_source_hash (source_hash)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;