예를 들어 1화에서 조직의 큰형을 "형님"이라 부르는 장면이 있다고 하자. 영어 자막은 이걸 "boss"로 옮겼다. 그런데 12화에선 "big bro", 40화에선 "brother"가 된다. 셋 다 뜻은 맞다. 그래도 시청자는 "저 사람 호칭이 왜 자꾸 바뀌지?" 하고 걸려 넘어진다. 번역이 회차를 거듭하며 조금씩 미끄러지는 이 현상을 drift(표류)라고 부른다.
문장 하나만 떼어 보면 셋 중 틀린 건 없다. 문제는 문장 바깥, 시리즈 전체를 가로지르는 일관성에 있다. SMART는 바로 이 지점을 겨냥한 자막 번역 시스템이다. 역할을 나눠 맡은 여러 AI가 협업하는 구조(멀티에이전트)이고, 핵심은 번역을 진행하는 도중에 스스로 작업 방식을 고친다는 데 있다. 저자들이 함께 공개한 평가 환경 Subtitle Arena에서 15개 번역 방향 전부 1위를 기록했다.
종합하면, SMART가 지목하는 병목은 번역 모델의 실력이 아니다. 쉬운 대사에는 과한 공정이 낭비되고, 어려운 대사에는 정작 필요한 전문가가 붙지 않는 구조적 불일치다. 이게 왜 생기는지는 기존 방식의 세 가지 한계에서 구체적으로 드러난다.
첫째, 긴 맥락을 끝까지 붙들고 일관성을 지키는 힘이 약하다. 단일 AI를 자막용으로 다듬거나 주변 대사와 줄거리 요약을 함께 넣어주는 방식이 있지만, 결국 문장 단위로 생각한다. 그래서 반복 등장하는 호칭과 고유명사가 앞의 "형님"처럼 회를 거듭하며 어긋난다.
둘째, 협업 공정이 장면 난이도와 무관하게 고정돼 있다. 여러 AI가 번역·검수·수정을 나눠 맡는 방식도 있는데, 역할과 절차를 미리 못 박아 둔다. 단순한 인사말이든 문화적 함의가 깊은 농담이든 똑같은 공정에 그대로 태운다.
셋째, 장르·시대 배경·문화 같은 제작 맥락을 그때그때 끌어와 반영하지 못한다.
여기에 자막만의 물리적 제약이 하나 더 붙는다. 한 줄에 들어갈 글자 수, 자막이 화면에 머무는 시간 대비 글자량(읽기 속도) 같은 화면 표시 규칙이다. 뜻만 맞아도 실패다. 번역문이 길어 화면을 벗어나면 그 자체로 탈락이다.
SMART의 핵심은 한 문장으로 요약된다. 바탕이 되는 거대언어모델(방대한 글로 학습해 문장을 생성하는 AI, LLM)을 다시 학습시키지 않고, 번역을 진행하는 도중에 스스로 작업 방식을 고쳐 나간다. 모델의 내부 수치(파라미터)를 건드리는 게 아니다. 모델에게 주는 지시문과 "어떤 문장을 누구에게 맡길지"의 규칙만 자연어로 바꾼다. 이렇게 서비스가 실제로 돌아가는 시점에 설정을 다듬는 것을 테스트 시점 학습(test-time training), 즉 본 작업을 하면서 하는 학습이라고 부른다.
SMART의 진화는 두 가지 활동으로 이뤄진다. 하나는 번역을 수행하는 일(번역 루프), 다른 하나는 그 결과를 바탕으로 작업 방식 자체를 개선하는 일(개선 루프)이다.
가장 밑에 깔린 장치는 번역팀이 함께 보는 한 권의 노트다. 저자들은 이걸 지속 시리즈 기억이라고 부른다. 노트에는 네 가지가 쌓인다. 용어 풀, 등장인물 프로필, 장면·도메인 지식, 관용표현 은행이다. 에피소드를 번역하기 전에 지금까지의 노트를 꺼내 읽고, 새로 확정된 정보는 번역이 끝난 뒤 다시 노트에 합친다. 모든 번역가와 도구가 이 노트를 들여다본다. 그래서 "형님"을 한 번 "boss"로 확정하면, 40화의 번역가도 매번 새로 고민하지 않고 노트에서 "지난번엔 boss였지"를 바로 꺼내 쓴다. 일관성이 문장 단위에서 시리즈 단위로 올라간다.
왜 노트를 따로 두는가? 모든 정보를 매번 프롬프트(모델에게 한 번에 건네는 지시문 묶음)에 욱여넣으면 세 가지 손해가 난다. 한 번에 넣을 수 있는 분량(문맥창)에는 한계가 있어 긴 시리즈 전체를 담을 수 없다. 설령 담아도 모델이 집중할 핵심을 놓치기 쉽다. 글자 수가 늘수록 비용도 커진다. 그래서 전체를 떠안기보다, 지금 이 문장에 필요한 조각만 골라 꺼내 쓰는 편이 낫다. 노트는 개별 호출의 문맥창을 넘어서는 장기 기억을 바깥에 따로 보관하는 장치인 셈이다.
여기에 시리즈의 장르·배경·주요 인물을 담은 가벼운 콘텐츠 프로필도 따로 둔다. 모호한 은어나 문화적 지칭은 외부 검색으로 사실을 찾아오되, 그 사실을 현재 장면 맥락에서 해석한 뒤 저장한다. 외부 지식의 "사실"과 자막에 맞는 "어투·표현"을 나눠 보관한다는 발상이다.
그 위에서 라우터가 일감을 나눈다. 라우팅이란 어떤 문장을 어느 번역가에게 보낼지 정하는 일이다. 문장마다 모든 번역가를 부르지 않는다. 문장 길이, 장면의 톤, 슬랭이나 욕설 같은 신호를 보고 부를 번역가를 고른다. 번역가들은 서로 다른 강점을 맡는다. 어떤 쪽은 의미 충실성, 어떤 쪽은 자연스러움, 또 어떤 쪽은 자막 길이 제어나 구어체 처리에 특화돼 있다. 쉬운 문장엔 적게, 까다로운 문장엔 전문가를 더 투입한다.
뽑힌 번역가들은 각자 후보 번역을 내놓는다. 이때 앞서 말한 노트에서 확정된 용어와 비슷하게 번역했던 과거 문장을 골라 꺼내 오고, 자막 제약 확인이나 목표 언어 유창성 점검 같은 도구도 호출한다.
후보가 모이면 심판 역할의 AI가 각 후보를 다섯 축으로 평가한다. 의미 정확성, 유창성, 문체·어조, 장거리 일관성, 자막 표시 제약이다. 점수와 함께 "무엇이 왜 아쉬운지"를 짚은 비평을 낸다. 가장 높은 점수의 후보를 고른 뒤 이 비평으로 한 번 더 다듬고, 확정된 번역을 노트에 반영한다. 에피소드가 끝나면 전체를 한 번 더 훑어, 문장 하나만 봐서는 잡기 어려운 잔여 일관성 오류를 손본다.
여기서 바로 짚어둘 맹점이 있다. 심판과 번역가가 같은 바탕 모델 위에서 돈다는 점이다. 그 모델이 애초에 못 보는 오류는 심판도 못 본다. 자기가 쓴 답을 자기가 채점하는 구조라, 모델 고유의 편향을 스스로 걸러내지 못할 위험이 남는다. 저자들이 더 약한 모델과 다른 평가자로 바꿔 시험한 것은 이 걱정에 대한 응답으로 보인다.
진화는 한 겹 더 올라간다. 학습 묶음이 끝날 때마다 후보 점수와 비평을 모아 두 가지를 고친다. 부진한 번역가의 지시문(반복되는 실패를 교정), 그리고 라우팅 규칙(점수가 높았던 구성 쪽으로 배분을 조정)이다. 둘 다 자연어로 다시 쓰이되, 마음대로 뜯어고치는 게 아니라 제약을 둔 재작성이다. 지시문은 부진한 번역가 것만 손보고 역할과 흐름은 그대로 둔다. 라우팅은 "한 범주당 번역가 최소 2명" 같은 바닥 조건을 지킨 채 배분표만 다시 쓴다. 자기 수정이 폭주하지 않게 거는 안전장치다. 적용은 문장마다가 아니라 학습 한 주기(에폭, 데이터를 한 바퀴 도는 단위)에 한 번만 한다.
마지막 설계 하나가 평가의 신뢰를 좌우한다. 시리즈를 두 묶음으로 쪼갠다. 앞 묶음에서 일부 문장을 실제로 번역하며 위의 진화를 돌리고, 그렇게 완성된 설정을 "얼린" 뒤 나머지 에피소드에 적용한다. 이유는 간단하다. 평가해야 할 뒷부분 결과를 다시 설정 수정에 쓰면, 시험 문제로 몰래 공부하는 셈이 되어 성적이 부풀려진다. 단, 노트만은 적용 중에도 계속 자란다.
정리하면 SMART가 다른 자기 개선 방식과 갈라지는 지점은 "무엇을 바꾸느냐"가 아니라 "언제, 무엇을 보존하며 바꾸느냐"다. 하나의 긴 번역 과제 안에서, 이미 쌓은 용어와 문체는 지키면서 다음 문장을 개선한다.
성능을 재려면 먼저 잴 자가 필요했는데, 기존 자막 데이터셋으로는 시리즈 일관성을 잴 수 없었다. 문장이 따로따로 흩어져 있어, 같은 호칭이 40화에서도 유지되는지를 측정할 방법 자체가 없었기 때문이다. 그래서 저자들은 평가 환경부터 새로 만들었다.
Subtitle Arena는 공개 자막 모음 OpenSubtitles2024에서 출발하되, 결정적 차이가 하나 있다. 문장을 늘어놓지 않고 에피소드·시리즈 단위로 다시 묶었다는 점이다. 영화 데이터베이스 식별자(IMDb)와 시즌·에피소드 번호로 두 언어의 대응을 복원하고, 타임코드를 보존하며 형식 오류를 바로잡고, 짝이 안 맞는 정렬은 버린 뒤 같은 시리즈끼리 묶어 긴 서사 구조를 살렸다. 규모는 192개 시리즈, 장르 14종, 목표 언어·지역(로케일) 15종이다. 영어 원본 6,267편을 15개 로케일로 옮긴 이중언어 에피소드 쌍이 모두 70,664쌍인데, 같은 회차가 언어별로 따로 집계되는 "쌍"의 수이지 에피소드 편수가 아니다. 제작연도는 1959년부터 2023년까지, 시리즈당 에피소드는 2편에서 198편까지 걸쳐 있다. 로케일별로는 중국어가 6,267쌍으로 가장 많고, 한국어는 3,243쌍이 담겼다.
점수를 매기는 자는 SubMQM이다. 번역 품질을 오류 감점으로 재는 국제 척도 MQM(다차원 품질 지표)을 자막용으로 각색한 것으로, AI 평가자가 7개 차원에 걸쳐 오류마다 감점을 매긴다. 점수는 낮을수록 좋다. 차원별 가중치는 정확성에 가장 큰 0.30을 두고 용어와 유창성에 각 0.20, 나머지를 작게 배분한다. 의미가 맞느냐를 가장 무겁게 본다는 뜻이다.
비교 상대는 세 부류다. 커뮤니티 자막(품질이 들쭉날쭉해 정답으로 취급하지 않음), 단일 호출 AI 여러 종, 그리고 역할을 나눈 에이전트 방식 TransAgent·DRT다. 공정성을 위해 두 에이전트 비교군은 SMART와 같은 상용 모델 위에서 다시 구현했다.
다만 SubMQM은 AI를 심판으로 쓰는 자동 평가다. 모든 시스템에 같은 평가자를 적용해 상대 비교의 공정성은 확보했지만, 평가자 자신의 편향 가능성은 자동 지표의 본질적 한계로 남는다. 숫자를 읽을 때 이 전제를 깔고 봐야 한다.
가장 또렷한 신호는 어려운 대사에 전문가를 더 붙이는 동적 배분이 실제로 통했다는 것이다. 앞서 말한 15개 방향 1위에 더해, 가장 강한 에이전트 비교군보다 평균 감점을 6.9% 줄였다. 별도 공개 벤치마크(MuSC)의 4개 언어쌍에서도 모두 최고였고, 사람이 매긴 종합 평가에서 5점 만점에 4.50으로 가장 높았다.
한국어가 걸린 대표 방향을 보면 숫자의 결이 보인다. 영어에서 한국어로 옮길 때 SMART의 종합 감점은 0.92로, 같은 방향 TransAgent의 0.97과 DRT의 0.99보다 낮다. 반대로 한국어에서 영어로 갈 때는 0.47로, TransAgent 0.52·DRT 0.57보다 낮다. 감점은 낮을수록 좋으니 두 방향 모두 앞선다.
그렇다고 모든 세부 차원에서 1등은 아니다. 영어에서 이탈리아어로 옮길 때, 글자 수와 줄바꿈 같은 기술 차원에서는 SMART가 2.37로 일부 비교군보다 오히려 높다. 종합 점수가 의미 충실성에 무게를 두기 때문에, 한 차원의 손해를 다른 차원에서 메워 종합 우위를 가져가는 구조로 읽힌다. "6.9% 줄였다"는 것도 가장 강한 에이전트 시스템과의 평균 비교이지, 모든 지표·모든 상대에 대한 전면 우위가 아니다. 이건 분리해서 읽어야 한다.
그래도 한 가지는 분명히 보여준다. 모델을 재학습하지 않고 지시문과 배분 규칙만 자연어로 진화시켜도, 긴 콘텐츠의 일관성 문제에서 공정이 고정된 에이전트를 앞설 수 있다는 실증이다. 여기까지가 근거가 받쳐주는 범위다. 운영 설계가 파인튜닝보다 낫다는 식의 일반화는 이 결과만으로는 말할 수 없다.
공짜는 없다. SMART는 문장마다 여러 후보를 만들고, 심판이 축별로 채점하고, 비평으로 한 번 더 고치고, 앞 묶음에서 설정을 진화시킨다. 이 단계가 전부 추가 호출이다. 단일 호출 한 번으로 끝나는 번역과 비교하면 호출 수가 여러 배로 늘고, 그만큼 비용과 응답 지연이 붙는다. 구체 수치는 논문이 부록에서 다루고, 여기서 없는 숫자를 지어내지는 않겠다. 방향만 짚으면, 일관성이 돈이 되는 긴 콘텐츠에는 값어치가 있고, 짧고 독립적인 작업에는 과하다.
전제도 하나 깔린다. 진화에 쓸 재료가 있어야 한다. SMART는 앞 묶음에서 설정을 진화시키므로, 에피소드가 충분히 긴 시리즈엔 유리하지만 짧은 콘텐츠는 진화에 쓸 데이터 자체가 적다. 과적합을 막아주는 학습-적용 분리가, 동시에 "진화할 재료가 있어야 한다"는 조건을 함께 깐다.
번역과 프로젝트 관리는 멀어 보여도 바닥에 깔린 문제는 하나다. 지난 결정을 뒤에서도 일관되게 재사용하는 것.
구체적인 장면으로 가보자. 고객사 담당자가 AI 프로젝트 관리자에게 메시지를 보낸다. "다음 주 금요일 납기를 그다음 주로 미뤄주세요." 관리자는 회신을 써야 한다. 그런데 석 달 전, 같은 고객과 "납기 변경은 발주서를 다시 발행해 확정한 뒤에만 반영한다"고 합의한 적이 있다. 매번 백지에서 판단하는 관리자라면 이 합의를 놓치고 "네, 조정하겠습니다"라고 답해버린다. 나중에 발주서 없이 일정이 틀어지면 책임 소재가 꼬인다.
SMART가 번역에서 긴 호흡의 일관성을 외부 기억으로 풀었듯, 프로젝트 관리도 매번 새로 판단하는 대신 지난 소통의 맥락과 용어, 합의를 체계적으로 쌓아두고 다시 꺼내 쓸 때 성공 확률이 올라간다. 위 장면에서 관리자가 그 합의를 노트에서 꺼내 "변경은 발주서 재발행 후 확정됩니다"라고 회신한다면, 열 번째 요청에서 세 번째 요청의 결정을 일관되게 재사용한 것이다.
검수 단계도 그대로 가져올 만하다. 고객에게 회신을 보내기 전에, 역할이 분리된 검수자가 용어 일관성·고객 말투·요청 충족을 축으로 자체 점검을 돌린다. 반복되는 실패가 보이면 역할은 그대로 두고 지시문만 제약적으로 고친다. 다만 그대로 들여오려면 조건이 붙는다. 학습분으로 쓸 초기 상호작용이 충분히 쌓여야 하고, 검수자가 회신 생성기와 같은 모델일 때의 사각지대는 교차 검증으로 메워야 한다. 번역의 공유 노트와 프로젝트 기억이 겹쳐 보인다고 해서, 둘이 똑같은 시스템인 것은 아니다. 가져올 것은 기능이 아니라 원리다.
그 위험을 줄이는 장치가 노트에 쓰는 시점에 있습니다. 번역은 심판이 다섯 축으로 채점하고 비평으로 한 번 다듬어 "확정"한 뒤에야 노트에 반영됩니다. 날것의 후보가 바로 저장되는 게 아닙니다. 게다가 에피소드가 끝나면 전체를 다시 훑어 잔여 일관성 오류를 손봅니다. 그래도 심판이 못 걸러낸 오류라면 뒤로 전파될 수 있는데, 이건 심판과 번역가가 같은 모델이라는 맹점과 맞닿은 지점입니다.
물리적으로 다른 모델 여러 개가 아니라, 하나의 바탕 모델에 서로 다른 역할과 지시문을 입혀 분업시킨 구조이기 때문입니다. 같은 사람이 상황에 따라 번역가 모자, 심판 모자, 배차 담당 모자를 바꿔 쓰는 셈입니다. 역할을 나눈 덕에 "후보를 내는 쪽"과 "그걸 채점하는 쪽"을 분리할 수 있지만, 바탕이 같은 머리라 공유하는 편향은 남습니다.
순서가 의미를 갖습니다. SMART는 앞 묶음에서 설정을 진화시킨 뒤 얼려서 뒤에 적용하고, 노트는 회차를 지나며 계속 쌓입니다. 앞선 회차에서 확정한 용어와 호칭이 뒤 회차 번역의 재료가 되는 구조라, 맥락이 축적되는 흐름을 지키는 편이 설계 의도에 맞습니다.