번역 API 제공자 비교 시 워크플로우 재작성을 피하기 위해 정규화된 작업 입력, 격리된 제공자 어댑터, 명시적 폴백 로직을 도입하는 아키텍처 패턴

Context

번역 API 제공자를 변경할 때 단순히 API 호출만 바꾸는 것이 아니라 인증 처리, 요청/응답 정규화, 재시도 전략, 폴백 로직, 콘텐츠 타입 처리, 다운스트림 애플리케이션 가정까지 수정해야 한다. 제공자별 세부사항이 CMS 파이프라인, 자막 워크플로우, 문서화 작업 등 여러 계층에 누출되면 제공자 비교는 단순 제품 결정이 아니라 미니 리팩토링이 된다.

Technical Solution

• 작업 입력 정규화: 애플리케이션 전체에서 제공자별 페이로드 대신 통일된 번역 작업 모델로 통신
• 제공자별 로직을 어댑터로 격리: API 간 차이점을 한 곳에 집중시키고 애플리케이션 전역에 분산되지 않도록 제한
• 폴백을 워크플로우 결정으로 전환: 페이지 코드나 빌드 스크립트에서 임시로 처리하지 않고 명시적 폴백 정책을 설정
• 콘텐츠 타입을 1등급 개념으로 취급: UI 문자열, 문서, 자막, CMS 콘텐츠를 동일하게 처리하지 않고 각각의 최적 제공자와 평가 기준 정의
• 비교 결과 저장소를 일관되게 유지: 번역 결과 저장 방식을 제공자 독립적으로 설계하여 제공자 변경 시 영향 범위 최소화

Key Takeaway

번역 API 제공자 통합의 진정한 잠금(lock-in)은 비용이 아니라 워크플로우 비용이다. 제공자 세부사항이 아키텍처 전역에 누출되지 않도록 설계하면 제공자 비교와 전환 시 재작성 없이 실험할 수 있다.