AI 콘텐츠 자동화는 어디까지 맡겨야 할까 — 월 수만 건의 태깅·번역을 운영에 올린 방법

콘텐츠 태깅과 번역은 생성형 AI 데모를 만들기 쉬운 일이다. 문장을 넣으면 태그와 번역문이 바로 나온다. 몇 건을 눈으로 보면 그럴듯해 보여서 자동화가 가능하다고 결론 내리기 쉽다.

운영에서는 질문이 달라진다. 월 수만 건이 들어와도 같은 기준을 지키는가. 틀린 태그가 검색과 추천을 망가뜨릴 때 누가 발견하는가. 번역하기 곤란한 콘텐츠는 어디로 보내는가. 모델이나 분류 체계가 바뀌면 이전 결과와 비교할 수 있는가.

우리가 맡은 엔터·미디어 그룹의 콘텐츠 메타데이터 파이프라인도 여기서 시작했다. 기존에는 사람이 콘텐츠를 일일이 태깅하고 번역했다. 다국어를 동시에 처리하기 어려웠고 물량이 늘수록 검수 부담도 커졌다. 4주 PoC의 목적은 좋은 샘플 몇 개를 만드는 게 아니었다. 운영 데이터로 자동 처리의 경계를 찾는 일이었다.

자동화율 100%를 목표로 잡지 않았다

모든 콘텐츠를 AI가 처리하고 아무도 보지 않는 구조는 자동화율이 높은 만큼 운영 위험도 크다. 반대로 AI 결과를 사람이 전부 다시 보면 품질은 지켜도 처리량과 비용은 달라지지 않는다.

우리는 전건 자동화 대신 예외 중심 검수를 목표로 삼았다. 반복적이고 판정 기준이 분명한 작업은 파이프라인이 처리한다. 판단이 흔들리거나 업무 영향이 큰 결과는 사람이 본다. 사람의 역할은 AI 결과를 처음부터 다시 만드는 데서 경계에 걸린 결과를 판단하는 일로 바뀐다.

이 구분은 견적 스킬에서 사람이 숫자 승인과 발송만 쥐도록 설계한 방식과도 닮았다. 판단이 필요한 순간을 먼저 정하고 그 사이의 반복 작업만 자동화한다.

평가 스택을 시스템보다 먼저 만들었다

AI 파이프라인에는 두 시스템이 필요하다. 태깅과 번역을 수행하는 시스템, 결과가 운영 기준을 넘는지 확인하는 평가 시스템이다. AWS Responsible AI Lens도 AI 시스템 스택과 평가 스택을 논리적으로 분리하고 평가 데이터와 판정 방식, 출시 기준을 따로 설계하라고 설명한다.¹

평가 기준은 "좋아 보인다"여서는 안 된다. 태깅은 허용된 분류 체계를 따르는지, 검색·추천에 필요한 의미를 보존하는지 본다. 번역은 원문의 사실과 고유명사를 지키고 대상 언어에서 실제로 쓸 수 있는 문장인지 판단한다. 같은 모델을 쓰더라도 실패 방식이 다르므로 판정도 분리한다.

PoC에서는 운영 데이터를 평가 입력으로 사용했다. 잘 정리된 예제로는 실제 분포의 긴 꼬리를 볼 수 없다. 정보가 부족한 콘텐츠, 여러 주제에 걸친 항목, 번역하지 말아야 할 이름과 표현처럼 사람이 망설이던 사례가 평가에 들어가야 예외 경계가 드러난다.

Amazon Bedrock의 평가 기능은 사용자 정의 데이터셋과 자동 평가, LLM 평가자, 사람 평가를 각각 제공한다.² 어떤 도구를 고르느냐보다 중요한 것은 같은 입력을 다시 평가할 수 있는 계약이다. 그래야 모델이나 프롬프트를 바꿨을 때 회귀를 확인한다.

처리 경로를 세 갈래로 나눈다

이 사례에서 얻은 원칙을 다른 업무에 적용하면 처리 경로는 세 갈래가 된다.

모델의 확신 점수 하나로 경로를 정하면 안 된다. 실제 업무에서는 콘텐츠 유형, 필드의 쓰임, 오류가 다음 단계에 미치는 영향, 사람이 되돌릴 수 있는지를 함께 본다. 같은 번역이라도 내부 검색용 요약과 외부 게시 문구의 허용 오차는 다르다.

4주 PoC는 운영 전환을 위한 시간이었다

PoC에서 확인한 것은 모델의 문장 품질만이 아니었다. 입력이 어디서 오고 결과가 어느 시스템으로 가는지, 실패한 항목을 사람이 어떻게 넘겨받는지, 품질과 비용을 무엇으로 추적할지도 함께 정했다.

이 구조는 AI PoC를 운영으로 옮기는 여섯 게이트의 축소판이다. 가치와 책임자, 데이터 사용 범위, 실제 업무 평가, 실패 통제, 운영 구조, 롤백 준비가 한 흐름으로 이어져야 한다. 모델 호출이 성공했다고 운영 준비가 끝난 것은 아니다.

운영 적용 뒤 파이프라인은 월 수만 건을 여러 언어로 처리했다. 사람은 예외만 검수했고 검수 부담은 기존보다 70% 줄었다. 사람을 없앤 비율이 아니다. 전건을 반복 확인하던 시간을 예외 판단으로 옮긴 결과다. 콘텐츠 메타데이터 자동화 Work에는 이 프로젝트의 문제와 제약, 전환 결과를 함께 정리했다.

같은 결론이 나오지 않는 조건

이 사례의 결과를 모든 콘텐츠 업무에 그대로 적용할 수는 없다. 분류 체계가 자주 바뀌거나 정답 기준을 합의하지 못한 업무에서는 예외가 계속 늘어난다. 법률·의료·공시처럼 한 번의 오류가 미치는 영향이 큰 외부 콘텐츠는 사람 승인을 더 넓게 남겨야 한다. 처리량이 적고 매번 맥락이 다른 업무라면 파이프라인 운영 비용이 수작업보다 클 수도 있다.

모델과 프롬프트도 고정돼 있지 않다. 새 버전이 평균 품질을 높여도 특정 언어나 콘텐츠 유형에서 회귀할 수 있다. 그래서 자동화율만 보지 않는다. 예외율, 수정 유형, 재처리 비용과 실패가 발견된 시간도 함께 본다. AWS도 의도한 사용 범위와 한계, 실패 방식을 사용자에게 문서화하라고 권한다.³

자동화 전에 네 가지를 묻는다

콘텐츠 자동화를 검토할 때는 모델보다 아래 질문을 먼저 확인한다.

• 맞고 틀림을 업무 언어로 판정할 수 있는가.
• 실제 입력의 어려운 사례를 평가 데이터로 확보했는가.
• 사람이 봐야 할 예외와 자동화하면 안 되는 범위를 정했는가.
• 모델·분류 체계가 바뀌어도 같은 기준으로 회귀를 확인할 수 있는가.

하나라도 답이 없으면 자동화 범위를 줄인다. AI가 처리할 수 있는지보다, 틀렸을 때 운영이 알아차리고 되돌릴 수 있는지가 먼저다. 월 수만 건을 처리하게 만든 핵심도 모델의 속도가 아니라 이 경계를 정한 일이었다.

콘텐츠·업무 자동화를 PoC에서 운영으로 옮기려면 AX 컨설팅에서 범위와 책임, 평가 기준부터 정할 수 있다. 평가 파이프라인과 운영 아키텍처 구현은 데이터 & ML 엔지니어링으로 이어진다.

참고 자료