AI가 만드는 콘텐츠 말고, AI가 돌리는 엔터 회사

AI가 음악을 만들고 영상을 만든다는 이야기는 이제 새롭지 않다. 업계 사람이라면 한 번씩 써봤고, 어디까지 되고 어디부터 안 되는지도 대충 감이 있다. 그래서 "AI가 콘텐츠를 만든다"로 시작하는 글은 더 읽을 이유가 없다.

정작 조용히 진행 중인 변화는 다른 곳에 있다. AI가 콘텐츠가 아니라 회사 일을 하기 시작했다. 발매 메타데이터를 입력하고, 플랫폼마다 콘텐츠를 올리고, 정산 자료를 취합하고, 불법 업로드를 찾아내는 일. 기획사 직원의 하루를 실제로 채우는 그 업무들이다. 올해 글로벌 테크 업계에서 돈과 인력이 몰리는 곳도 생성 모델이 아니라 이쪽, 이른바 에이전트다.

그런데 엔터 업계는 이 변화를 아직 콘텐츠 관점으로만 보고 있다. "AI가 창작을 대체하나"는 수없이 물으면서 "AI한테 우리 업무를 맡길 수 있나"는 잘 묻지 않는다. 기획사의 하루는 창작보다 운영으로 채워져 있는데도 그렇다. 그래서 이번 리포트에서는 그 이야기를 해보려고 한다.

에이전트는 챗봇이 아니다

용어부터 정리하고 가자. 에이전트는 질문에 답하는 챗봇이 아니라, 목표를 주면 브라우저나 파일, 스프레드시트, 외부 플랫폼 API 같은 도구를 직접 다루면서 여러 단계의 일을 끝내는 소프트웨어다. "이번 싱글 발매 정보를 플랫폼별 규격에 맞게 정리해서 올려줘"라고 하면 파일을 열고, 규격을 확인하고, 폼을 채우고, 문제가 생기면 보고한다.

챗봇은 답변이 좋으면 그만이지만 에이전트는 일이 실제로 끝나야 가치가 있다. 그리고 일이 끝나려면 모델이 똑똑한 것만으로는 부족하다. 데모와 실운영의 차이가 여기서 벌어지는데, 뒤에서 자세히 다룬다.

어떤 업무를 맡길 수 있나

기획사 업무를 두 가지 기준으로 나눠보면 그림이 나온다. 얼마나 자주 반복되는 일인가? 명문화된 규칙에 기반한 일인가? 아니면 맥락과 감각을 통해 판단해야 하는 일인가?

가장 먼저 맡길 수 있는 건 반복되면서 규칙이 정해진 일이다. 음원 발매 메타데이터 입력과 검수, 플랫폼별 업로드와 배포, 정산 자료 취합과 대사, 불법 업로드 모니터링, 커버나 리액션 영상 수집 같은 것들. 이런 일은 규칙이 이미 있다. 플랫폼 규격이 있고 정산 포맷이 있다. 지금까지 사람이 해온 이유는 판단이 어려워서가 아니라 맡길 데가 없어서였다.

그 다음은 반복되지만 가벼운 판단이 섞인 일이다. 팬 문의 1차 분류, 커뮤니티 모더레이션 1차 필터, 데모나 지원서 1차 스크리닝, SNS 성과 리포팅. 네 가지 모두 "1차"가 붙는다. 에이전트가 다 처리하는 게 아니라, 사람이 봐야 할 것과 아닌 것을 걸러서 사람 시간을 판단이 필요한 곳에 몰아주는 역할이라서 그렇다.

맡기면 안 되는 일도 분명하다. 아티스트와의 관계, 캐스팅 최종 판단, 크리에이티브 디렉션, 위기 대응. 이런 일은 판단 근거가 규칙이 아니라 관계와 맥락에 있고, 무엇보다 잘못됐을 때 되돌릴 수 없다. 에이전트가 못 해서가 아니라 책임이 성립하지 않아서 맡기면 안 되는 영역이다.

이렇게 나눠 놓고 보면 질문이 달라진다. "AI가 A&R을 대체하나"를 물을 게 아니라 "A&R이 스크리닝에 쓰는 세 시간을 빼줄 수 있나"를 물어야 한다. 에이전트 도입은 사람을 대체하는 일이라기보다 사람의 시간을 옮기는 일에 가깝다.

스택 뜯어보기

에이전트 스택은 크게 세 층이다. 상황을 읽고 다음 행동을 정하는 모델, 큰 일을 단계로 쪼개고 순서를 관리하고 실패하면 다시 시도하는 오케스트레이션, 그리고 실제 시스템을 조작하는 도구 연결. 브라우저를 움직이고 API를 호출하고 파일을 읽고 쓰는 부분이 마지막 층이다.

실제로 만들어보면 금방 알게 되는 게 있다. 데모에서 눈에 띄는 건 모델인데, 실운영을 좌우하는 건 아래 두 층이라는 사실이다. 모델이 "이 발매 정보를 이 폼에 넣어야 한다"고 판단하는 것까지는 쉽다. 어려운 건 그 폼이 있는 시스템에 실제로 접속하고, 규격이 안 맞는 아트워크를 걸러내고, 서버가 응답하지 않으면 적절히 다시 시도하고, 그래도 안 되면 어디까지 했고 어디서 막혔는지 사람한테 정확히 보고하는 쪽이다. 운영 비용 대부분이 여기서 나온다.

설계에서 제일 중요한 결정도 하나 있다. 사람 승인을 어디에 두느냐다. 되돌릴 수 있는 일은 에이전트가 알아서 하게 두고, 되돌릴 수 없는 일, 그러니까 대외 발행이나 송금이나 팬에게 나가는 답변 앞에는 반드시 사람 승인을 둔다. 승인 지점이 너무 많으면 자동화하는 의미가 없고, 너무 적으면 사고가 난다. 에이전트 도입이 성공하고 실패하는 갈림길은 대부분 모델 선택이 아니라 이 승인 설계에 있다.

모델은 어디서 빌리고 에이전트는 어디에 올리나

여기서부터는 기술 선택 얘기다. 정해야 할 것부터 보자. 판단을 맡길 모델을 어디서 가져올지, 에이전트 본체를 어디서 돌릴지, 회사 시스템과는 어떻게 연결할지다.

모델. 선택지는 클로드나 GPT 같은 프런티어 모델을 API로 쓰는 쪽과, 오픈소스 모델을 자체 GPU에 올리는 쪽으로 나뉜다. 결론부터 말하면 중소 기획사의 기본값은 API다. 에이전트 업무는 여러 단계를 스스로 판단하며 가야 해서 모델 지능이 조금만 떨어져도 중간에 길을 잃는데, 로컬에 올릴 만한 크기의 모델은 아직 이 신뢰도가 안 나온다. GPU를 사고 관리하는 비용까지 치면 중소 규모에서는 API 요금이 훨씬 싸게 먹힌다. 예외는 대량 반복 작업이다. 수천 개의 댓글이나 영상을 훑는 모니터링처럼 판단이 단순하고 물량이 많은 일은 작고 싼 모델로도 충분해서, 판단은 프런티어 API에 맡기고 대량 필터링은 저가 모델로 돌리는 이원 구성이 실무에서 자주 나온다.

실행 환경. 에이전트 본체, 그러니까 오케스트레이션과 도구 연결이 도는 곳은 모델과 별개로 정해야 한다. 크게 개인 PC에 올리는 셀프호스팅, 클라우드 서버, 업체가 관리해주는 매니지드 서비스로 나뉜다.

요즘 화제인 오픈클로(OpenClaw) 계열, 그러니까 내 컴퓨터에 상주시켜 놓고 메신저로 부리는 셀프호스팅 에이전트를 회사 업무에 써도 되느냐는 질문을 많이 받는다. 개인 생산성 도구로는 훌륭하다. 리서치, 스크래핑, 초안 작성처럼 잘못돼도 내 선에서 끝나는 일에는 지금도 잘 쓴다. 다만 회사 업무는 얘기가 다르다. 이 계열은 한 프로세스가 넓은 권한을 쥐는 개인 비서 구조라서, 정산 데이터와 아티스트 계정을 만지는 업무에 붙이려면 권한 분리와 감사 기록을 직접 만들어 붙여야 한다. 그런 보강 작업을 해낼 역량이 있는 회사라면 애초에 클라우드에 제대로 올리는 게 낫다.

셀프호스팅의 약점이 보안 같은 거창한 데서만 오는 것도 아니다. 사무실 맥미니에 에이전트를 올려 쓰던 어느 회사에서는, 자리를 정리하던 실무자가 본체를 옮기면서 전원을 뽑는 바람에 챗봇과 에이전트가 통째로 죽었다. 장애 원인이 '전원 코드 뽑힘'인 시스템 위에 회사 업무를 올릴 수는 없다.

그래서 회사 업무의 기본값은 클라우드 서버다. 에이전트를 클라우드에 올리고, 처리 내역이 전부 기록으로 남고, 계정 권한이 업무 단위로 쪼개진 구성. 앞에서 말한 승인 게이트도 이 위에 올라간다. 개발 인력이 전혀 없는 팀이라면 이미 쓰고 있는 협업 도구에 들어온 내장 에이전트나 매니지드 서비스로 파일럿을 돌려보고, 업무가 검증된 다음에 자체 구성으로 옮기는 순서가 안전하다.

연결. 엔터 업무 자동화에서 진짜 발목을 잡는 건 모델이 아니라 API 없는 시스템들이다. 유통사 어드민, 정산 포털, 팬 커뮤니티 상당수가 API를 제공하지 않는 웹 화면이다. 이런 곳에는 에이전트가 브라우저를 사람처럼 조작하는 방식으로 붙는데, API 호출보다 느리고 화면이 바뀌면 깨진다. 그래서 API가 있는 시스템부터 자동화하고, 브라우저로만 붙는 시스템은 깨졌을 때 알아차리는 장치까지 같이 만들어야 한다. 도구 연결 규격은 MCP라는 표준으로 수렴하는 중이라, 지금 새로 만든다면 MCP 기준으로 맞춰두는 게 나중에 갈아탈 때 편하다.

데이터. 미발매 음원, 아티스트 개인정보, 정산 내역이 외부 모델 API로 나가도 되는지부터 정리해야 한다. 주요 업체의 API는 입력 데이터를 모델 학습에 쓰지 않는 조건을 계약으로 제공하니 확인하고 쓰면 되고, 정작 흔한 구멍은 다른 데 있다. 직원들이 개인 챗봇 계정에 정산 파일을 올려서 요약시키는 일이 이미 곳곳에서 벌어지고 있다. 회사 계정과 API로 통로를 만들어주지 않는 것 자체가 보안 취약점이다. 에이전트한테 주는 계정도 마찬가지다. 사람 계정을 그대로 넘기지 말고 업무 범위만큼만 권한을 가진 별도 계정을 만들어 주고, 무엇을 했는지 남게 한다.

안 되는 것부터 알아야 한다

여기까지 읽고 바로 도입하고 싶어졌다면, 안 되는 것들을 먼저 봐야 한다. 사실 이 글에서 제일 중요한 부분이다.

첫째, 에이전트는 자신 있게 틀린다. 제일 위험한 건 시끄러운 오류가 아니라 조용한 오류다. 작곡가 이름 하나, 지분율 숫자 하나가 잘못 들어가면 입력 시점에는 아무도 모른다. 몇 달 뒤 정산에서 터진다. 그래서 검증 절차 없는 자동화는 효율이 아니라 부채다. 에이전트가 처리한 걸 다른 방식으로 한 번 더 확인하는 구조까지 만들어야 도입이 끝난 거다.

둘째, 팬을 직접 상대하는 일은 아직 이르다. 팬 입장에서 자기는 상담원이 아니라 "우리 아티스트 회사"와 대화하는 거다. 톤이 어긋난 답변 하나는 CS 실수가 아니라 브랜드 사고가 되고, 스크린샷으로 박제되어 돈다. 팬 대면 업무에서 에이전트가 할 수 있는 건 응대가 아니라 분류와 초안까지다.

셋째, 예외가 시간을 다 잡아먹는다. 업무의 8할이 자동화돼도 나머지 2할의 예외 처리에 사람 시간이 다 들어가면 전체 시간은 줄지 않는다. 에이전트 설계에서 제일 저평가된 부분이 여기다. 잘하는 것보다, 못 하는 일을 사람한테 잘 넘기는 것. 어디까지 시도했고 어디서 막혔는지 정확히 넘겨주지 못하는 시스템은 결국 사람이 처음부터 다시 확인하게 만든다.

넷째, 권리 정보는 문서 밖에 있다. 엔터 업무는 상당수가 권리 확인을 거치는데, 그 정보가 계약서와 시스템에만 있지 않다. 관행에 있고, 구두 합의에 있고, 담당자 기억에 있다. 에이전트는 문서화된 것만 안다. 권리가 얽힌 업무를 자동화하려면 그 전에 권리 정보부터 문서로 만들어야 하는데, 사실 많은 회사에서 진짜 병목은 이거다.

다섯째, 플랫폼은 에이전트를 반기지 않는다. 인스타그램이든 틱톡이든, SNS 플랫폼들은 자동화된 조작을 적발해서 계정을 제재한다. 포스팅 자동화를 테스트하다 계정이 차단되는 사고는 실제로 일어난다. 기획사에게 공식 계정은 팬과 만나는 채널 그 자체라서, 계정 정지는 데이터 사고보다 무거운 사고다. 복구는 안 되거나 오래 걸린다. 말 그대로 되돌릴 수 없는 일이다. 그래서 발행 자동화는 플랫폼이 열어준 공식 API 경로가 있을 때만 하고, 브라우저로 포스팅을 밀어 넣는 실험은 본계정과 완전히 분리된 계정으로만 해야 한다.

정리하면 에이전트 도입의 성패는 모델 성능이 아니라 업무 설계에서 갈린다. 그리고 업무 설계는 그 업무를 아는 사람만 할 수 있다.

대형사보다 중소 기획사가 먼저다

자동화는 조직이 클수록 효과가 크다는 게 지금까지의 상식이었다. 에이전트는 이 상식을 뒤집는다.

대형사는 이미 분업이 돼 있고 전산화도 돼 있다. 정산팀이 따로 있고 배포 담당이 따로 있다. 여기에 에이전트를 넣으면 절감되는 건 한 부서 인건비의 일부다. 의미는 있지만 구조가 바뀌지는 않는다.

한국 중소 기획사는 사정이 다르다. 한 사람이 마케팅과 정산과 CS와 배포를 다 한다. 이런 구조에서 에이전트가 해주는 일은 감원이 아니다. 한 사람이 혼자 떠안고 있던 일 몇 가지를 덜어주는 쪽이다. 다섯 가지 일을 하던 사람이 두 가지에 집중하게 되면, 이건 비용 절감이라기보다 조직 구조의 변화다. 같은 인원으로 더 많은 아티스트와 더 많은 발매를 돌릴 수 있게 되기 때문이다. 효과는 일손이 제일 빠듯한 곳에서 제일 크게 난다.

문제는 중소 기획사에 이걸 설계할 사람이 없다는 점이다. 대형사야 팀을 뽑아 내재화하면 되지만 중소는 그럴 수 없다. AI 업계가 키우고 있는 범용 AI 인력은 앞으로 계속 늘어날 텐데, 엔터 도메인, 그러니까 권리 구조와 팬 문화와 플랫폼 관행을 아는 설계자는 그 속도로 늘지 않는다. 도구는 흔해지는데 설계는 귀한 상태. 당분간 이 간극이 병목이고, 뒤집어 말하면 먼저 움직이는 회사한테는 기회다.

도입 전에 정할 것들

도입을 검토하고 있다면 이 순서로 접근하면 된다.

먼저 업무 하나를 고른다. 잘못돼도 사고가 아니라 재작업으로 끝나는 일, 주 단위 이상으로 반복되는 일, 신입한테 매뉴얼로 넘길 수 있을 만큼 규칙이 문서로 정리되는 일. 이 세 가지를 모두 만족하는 업무여야 한다. 그런 업무가 없다면 에이전트 도입보다 업무 문서화가 먼저다.

성공 기준을 "몇 명 줄었나"로 잡으면 안 된다. 그렇게 시작한 도입은 조직 저항에 부딪혀 죽는다. 그보다는 담당자의 일주일에서 몇 시간이 어떤 일에서 어떤 일로 옮겨갔는지를 봐야 한다. 스크리닝에서 아티스트 커뮤니케이션으로, 데이터 입력에서 캠페인 기획으로. 시간이 옮겨간 만큼이 성과다.

파일럿은 3개월이면 충분하다. 업무 하나를 에이전트에 맡기고, 처리 내역을 전부 로그로 남기고, 사람한테 넘어온 비율을 잰다. 이 비율이 떨어지는 추세면 승인 지점을 한 단계 늦추고, 안 떨어지면 그 업무는 아직 때가 아니다.

예산은 액수보다 구조를 먼저 잡는 게 맞다. 비용은 처음 업무를 분해하고 시스템을 붙이는 설계비, 매달 나가는 모델 사용료, 그리고 에이전트를 지켜보고 예외를 처리하는 사람의 시간으로 나뉜다. 이 중에 제일 과소평가되는 항목이 마지막이다. 모델 사용료는 업무량에 비례해서 예측이 쉬운 반면, 예외 처리에 들어가는 사람 시간은 설계 품질에 따라 몇 배씩 벌어진다. 구체적인 액수는 업무마다 달라서 여기 적는 게 의미가 없고, 대신 상한선 하나만 기억해 두면 된다. 파일럿에 들어가는 총비용이 그 업무를 사람이 그냥 계속 했을 때의 비용을 넘어서면, 업무를 잘못 골랐거나 설계가 잘못된 것이다.

내재화가 나을지 외주가 나을지는 업무 성격에 따라 달라진다. 자사 고유 프로세스에 묶인 일이면 내재화할 가치가 있고, 업계 공통 업무라면 설계는 밖에서 받고 운영만 안에서 하는 쪽이 빠르다. 다만 어느 쪽이든 그 업무를 아는 사람이 설계에 참여하지 않으면 실패한다. 여기엔 예외가 없다.

설계를 밖에서 받기로 했다면 고르는 눈도 필요하다. 데모를 보여달라고 하는 대신 실패담을 물어봐라. 뭐가 안 되느냐는 질문에 구체적인 사고 이야기가 바로 나오는 쪽이 실제로 운영을 해본 쪽이다. 승인 게이트와 처리 기록을 화면으로 보여달라고 해라. 보여줄 게 없다면 데모용 시스템이다. 마지막으로 SNS 계정이나 정산처럼 되돌릴 수 없는 지점을 어떻게 막는지 물어봐라. 세 질문에 답이 시원치 않은 벤더와는 계약하지 않는 게 맞다.

생성 AI가 콘텐츠를 바꾸는 기술이었다면 에이전트는 회사가 굴러가는 방식을 바꾸는 기술이다. 그래서 이 결정은 크리에이티브 팀이 아니라 경영진의 몫이다. 먼저 움직인 회사는 비용을 아끼는 데서 그치지 않고, 같은 인원으로 더 많은 아티스트를 돌리는 구조를 남들보다 먼저 갖추게 된다.