아제르바이잔어 모델을 아마존 사가메이커 AI에서 훈련하기

Azercell이 직면한 핵심 문제는 형태론적으로 풍부한(교착어 계열) 아제르바이잔어를 학습 데이터가 부족한 상황에서 LLM에 적응시키는 것이었다. 영어처럼 단어 단위가 명확한 언어와 달리, 아제르바이잔어는 어근에 여러 접사가 붙어 하나의 단어가 다양한 문법적 의미를 표현하기 때문에, 기존 영어 중심 토크나이저로는 토큰이 비효율적으로 잘게 쪼개져 학습 효율과 추론 품질이 동시에 떨어진다. AWS Generative AI Innovation Center와의 협업은 이 문제를 SageMaker AI 위에서 풀었다. 일반적으로 이런 작업은 기존 파운데이션 모델(FM)을 베이스로 삼아 도메인·언어 특화 코퍼스로 지속 사전학습(continued pre-training)을 수행하고, 필요 시 어휘(vocabulary)를 확장하거나 토크나이저를 재학습한 뒤, 분산 학습(데이터/모델 병렬화)과 체크포인팅, 실험 추적을 SageMaker의 관리형 인프라로 표준화하는 흐름을 따른다. 6주라는 짧은 기간에 '프로덕션 레디 프레임워크'를 만들었다는 점이 핵심으로, 일회성 모델이 아니라 재현 가능한 학습 파이프라인을 구축했다는 의미다.

엔지니어 입장에서 이 사례가 주는 실질적 시사점은, 저자원(low-resource) 언어나 특정 도메인 LLM 구축이 더 이상 빅테크만의 영역이 아니라는 점이다. 통신사 규모의 조직이 처음부터 모델을 새로 만드는(from scratch) 대신, 검증된 FM을 기반으로 언어 적응과 도메인 파인튜닝을 결합해 단기간에 고객 응대 챗봇과 사내 텔레콤 업무용 모델을 동시에 확보했다. 이는 한국어처럼 영어 대비 데이터·토크나이징 측면에서 불리한 언어를 다루는 국내 개발자에게 직접적인 참고가 된다. 특히 토크나이저 효율 문제, 제한된 양질의 코퍼스 확보, 평가 벤치마크 부재 같은 어려움은 한국어 LLM 프로젝트에서도 거의 그대로 반복되는 공통 과제다.

행동 관점에서 개발자가 챙겨야 할 것은 세 가지다. 첫째, 모델 아키텍처 선택보다 데이터와 토크나이저 전략이 저자원 언어 성능을 좌우하는 경우가 많으므로, 토큰화 효율(fertility, 단어당 토큰 수)을 먼저 측정하고 필요하면 어휘 확장을 검토해야 한다. 둘째, '처음부터 학습'이 아닌 '지속 사전학습 + 파인튜닝' 경로가 비용·기간 면에서 현실적이며, SageMaker처럼 분산 학습·체크포인팅·실험 관리를 묶어주는 플랫폼을 쓰면 인프라 구성에 드는 시간을 크게 줄일 수 있다. 셋째, 프로덕션 투입 전 해당 언어·도메인에 맞는 자체 평가셋을 반드시 구축해야 한다 — 기존 영어 벤치마크는 형태론적 정확성이나 도메인 용어 처리 능력을 제대로 측정하지 못한다. AWS가 이 프레임워크를 공개 사례로 정리한 만큼, 유사 프로젝트를 계획 중이라면 원문에서 제시한 학습 구성과 파이프라인 설계를 청사진으로 활용하는 것이 효율적이다.