계정이 늘어날수록 광고 소재가 꼬입니다 — 대행사의 소재 버전 관리법

소재가 아니라 "어느 버전인지"가 문제였습니다

저희 팀은 클라이언트별로 인스타와 유튜브 계정을 나눠 운영합니다. 계정이 열 개 안쪽일 때는 별문제가 없었습니다. 소재를 만들고, 올리고, 성과를 보고 수정하면 됐으니까요.

문제는 계정이 스무 개를 넘어가면서 생겼습니다. 어느 날 성과가 좋은 소재를 다른 계정에도 적용하려고 파일을 찾는데, 폴더에 비슷한 파일이 일곱 개 있었습니다. "최종", "최종2", "최종_수정", "진짜최종". 다들 겪어보셨을 겁니다.

더 곤란했던 건 그 다음이었습니다. 클라이언트가 "지난주에 반응 좋았던 그 영상으로 다시 돌려주세요"라고 했는데, 그게 일곱 개 중 어느 것인지 아무도 확신하지 못했습니다. 성과 데이터는 계정 쪽에 있고, 파일은 드라이브에 있는데, 둘을 잇는 연결고리가 없었던 겁니다.

소재 이름에 정보를 넣기로 했습니다

가장 먼저 바꾼 건 파일 이름 규칙입니다. 거창한 도구를 도입하기 전에 이름만 정리해도 상당 부분 해결됐습니다.

저희가 쓰는 형식은 이렇습니다.

클라이언트_캠페인_소재유형_버전_제작일

예를 들면 "ABC_가을신상_영상15초_v3_1002" 같은 식입니다. 규칙은 단순한데 지키는 게 어렵습니다. 그래서 팀에 두 가지를 못 박았습니다.

첫째, "최종"이라는 단어를 쓰지 않습니다. 버전은 숫자로만 올립니다. 최종은 영원히 오지 않는다는 걸 모두가 인정했습니다.

둘째, 계정에 올린 소재는 파일명을 바꾸지 않습니다. 수정이 필요하면 새 버전 번호를 붙여 새 파일을 만듭니다. 이미 집행된 소재의 이름이 바뀌면 성과 데이터와 연결이 끊기기 때문입니다.

어느 계정에 무엇이 올라갔는지는 따로 적습니다

파일 이름만으로는 "이 소재가 지금 어느 계정에서 돌고 있는지"를 알 수 없습니다. 그래서 집행 기록을 따로 남깁니다.

저희는 시트 하나에 계정별로 행을 만들고, 집행 중인 소재 버전과 시작일을 적습니다. 복잡한 구조는 오래 못 갑니다. 열은 다섯 개 정도로 제한했습니다. 계정, 캠페인, 소재 버전, 집행 시작일, 비고.

비고에는 "같은 소재 B계정에서도 집행 중" 같은 메모를 씁니다. 이게 나중에 중요해집니다. 여러 계정에서 똑같은 소재를 동시에 돌리면 도달이 서로 갉아먹는 경우가 있는데, 기록이 없으면 왜 성과가 떨어졌는지 원인을 못 찾습니다.

계정을 넘나들며 소재를 재활용할 때 조심할 것

성과가 좋은 소재를 다른 계정에 그대로 올리고 싶은 마음은 늘 듭니다. 저희도 그렇게 합니다. 다만 몇 가지는 반드시 바꿉니다.

썸네일과 첫 문구는 손봅니다. 완전히 동일한 이미지와 카피가 여러 계정에서 동시에 노출되면, 보는 사람 입장에서도 어색하고 플랫폼 쪽에서도 좋게 보지 않는 경우가 있었습니다. 핵심 구성은 유지하되 표현을 바꾸는 선에서 재활용합니다.

집행 시작 시점을 띄웁니다. 같은 날 동시에 올리기보다 며칠 간격을 둡니다. 이건 성과 비교에도 도움이 됩니다. 동시에 올리면 어느 계정의 변수가 영향을 줬는지 구분이 안 됩니다.

계정의 기존 톤을 봅니다. 계정마다 지금까지 올려온 콘텐츠의 결이 있습니다. 갑자기 성격이 다른 소재가 들어가면 기존 팔로워 반응이 눈에 띄게 떨어지는 걸 몇 번 봤습니다.

소재를 내리는 기준도 같이 정했습니다

올리는 규칙만 있고 내리는 규칙이 없으면 계정마다 오래된 소재가 쌓입니다. 저희는 이것 때문에 한동안 고생했습니다. 성과가 떨어진 소재를 아무도 내리지 않아서, 예산은 계속 나가는데 반응은 없는 상태가 몇 주씩 이어진 계정이 있었습니다.

지금은 집행 기록에 "점검일"을 하나 더 적습니다. 보통 집행 시작 후 2주 뒤로 잡아두고, 그날이 되면 담당자가 유지할지 내릴지 판단합니다. 자동으로 내리지는 않습니다. 시즌성이 있는 소재는 잠깐 성과가 떨어져도 유지해야 하는 경우가 있어서, 판단은 사람이 합니다.

중요한 건 "언젠가 보겠지"가 아니라 날짜를 정해두는 것이었습니다. 날짜가 없으면 아무도 안 봅니다.

수정 요청이 들어왔을 때의 흐름

클라이언트 수정 요청이 가장 많은 혼선을 만듭니다. "저번 영상에서 자막만 바꿔주세요" 같은 요청이 오면, 어느 버전을 기준으로 바꾸는지가 불분명해지기 때문입니다.

저희는 수정 요청을 받으면 먼저 기준 버전을 확인해서 회신합니다. "현재 집행 중인 v3 기준으로 자막 수정하겠습니다. 맞을까요?" 이 한 줄이면 대부분의 오해가 사라집니다.

그리고 수정본은 v4로 올리되, v3를 삭제하지 않습니다. 수정 후 성과가 더 나빠져서 되돌린 적이 몇 번 있었는데, 그때 원본이 남아 있지 않으면 처음부터 다시 만들어야 합니다.

담당자가 바뀔 때를 기준으로 만들었습니다

이 규칙들을 정착시킨 결정적 계기는 팀원 한 명이 휴가를 간 주였습니다. 그 주에 클라이언트 요청이 들어왔는데, 담당자가 아니면 어느 소재가 어디에 올라가 있는지 아무도 몰랐습니다.

그래서 기준을 이렇게 잡았습니다. "담당자가 내일 출근하지 않아도 다른 사람이 30분 안에 파악할 수 있는가."

이 기준으로 보면 머릿속에만 있는 정보는 전부 문제입니다. 소재 이름, 집행 기록, 수정 이력이 모두 글로 남아 있어야 합니다. 저희는 이걸 맞추는 데 두 달 정도 걸렸습니다.

도구보다 습관이 먼저였습니다

처음에는 전용 협업 도구를 도입하려고 했습니다. 몇 개 비교해보다가 결국 쓰던 드라이브와 시트로 돌아왔습니다. 이유는 단순합니다. 도구를 바꾸면 팀 전체가 새 도구에 적응해야 하는데, 정작 문제는 도구가 아니라 "기록을 남기지 않는 습관"이었기 때문입니다.

지금도 가끔 규칙을 어긴 파일이 올라옵니다. 그럴 때마다 지적하기보다 그 자리에서 이름을 고쳐둡니다. 규칙을 지키는 게 지적받는 것보다 편하다는 걸 느끼면 자연스럽게 따라오더라고요.

정리하면

계정이 늘어나면 소재의 양보다 소재의 상태를 관리하는 게 어려워집니다. 어떤 버전이, 어느 계정에, 언제부터 올라가 있는지. 이 세 가지만 기록해도 대부분의 혼선이 사라졌습니다.

거창한 시스템은 없어도 됩니다. 다만 그 기록이 담당자 머릿속이 아니라 팀이 볼 수 있는 곳에 있어야 합니다.