태깅 작업이 하루에 끝나는 조건과 몇 주로 길어지는 조건

📖 약 3분 읽기

태깅 작업을 맡기려고 업체 몇 곳에 문의해 보면 제시하는 기간이 서로 다르다는 점에 놀라게 됩니다. 어떤 곳은 하루 이틀이면 끝난다고 안내하고, 어떤 곳은 몇 주를 예상해야 한다고 말합니다. 작업 범위가 비슷해 보이는데도 기간 차이가 크다면, 그 이유를 짚어볼 필요가 있습니다.

작업을 가르는 변수는 작업량이 아니라 준비 상태

태깅 작업은 보통 네 단계로 진행됩니다. 현재 상태를 점검하는 단계, 설계안을 정리하고 합의하는 단계, 실제로 구현하고 검증하는 단계, 마지막으로 결과를 보고하는 단계입니다. 각 단계를 들여다보면 시간이 늘어나는 지점이 작업 자체가 아니라 그 사이사이에 있다는 것을 알 수 있습니다.

구현 단계만 놓고 보면 태그를 심고 변수를 매핑하고 테스트하는 작업은 실무자가 손을 움직이는 시간입니다. 반면 계정 접근 권한을 받거나, 전환 정의를 합의하거나, 검수 담당자의 확인을 기다리는 시간은 손을 움직이지 않고 대기하는 시간입니다. 같은 작업 범위라도 이 대기 시간이 얼마나 끼어드는지에 따라 전체 일정은 하루로 끝날 수도 있고 몇 주로 늘어날 수도 있습니다.

실제 작업 시간과 대기 시간의 차이

전환 이벤트 하나를 추가하는 작업이 대표적인 예입니다. 태그를 설정하고 테스트하는 데 드는 실제 작업 시간은 길지 않습니다. 하지만 이 이벤트가 어떤 행동을 기준으로 전환으로 잡힐지 담당 부서 간 합의가 끝나지 않았다면, 구현 자체는 기다릴 수밖에 없습니다. 결제 흐름을 확인하는 과정에서 결제 담당자의 답변을 기다려야 하는 경우도 마찬가지입니다. 작업자가 바쁜 것이 아니라 답을 기다리는 시간이 길어지는 구조입니다.

이 구조를 이해하면 업체가 제시하는 기간을 다르게 읽을 수 있습니다. 작업 범위가 비슷한데 기간 차이가 크다면, 업체가 얼마나 많은 일을 하느냐의 문제가 아니라 고객사의 준비 상태를 어떻게 가정하고 일정을 짰는지의 차이일 가능성이 높습니다.

태그맨이 공개한 처리 기준

현재 상태를 확인하는 1회 점검의 경우, 자료를 전달받은 뒤 영업일 기준으로 하루 안에 결과를 전달하는 것을 처리 기준으로 두고 있습니다. 구현이 필요한 작업은 착수 전에 예상 소요 기간을 먼저 안내하고, 승인을 받은 다음에 작업을 시작합니다. 이렇게 순서를 정해두면 작업이 시작된 이후에 기간이 갑자기 늘어나는 상황을 줄일 수 있습니다.

[asset:0]

기간을 늘리는 다섯 가지 요인

현장에서 기간을 늘리는 요인은 대체로 다섯 가지로 정리됩니다. 계정 권한을 받는 데 시간이 걸리는 경우, 담당자 쪽 개발 일정이 확보되지 않은 경우, 무엇을 전환으로 볼지 정의가 끝나지 않은 경우, 결제 흐름 확인이 늦어지는 경우, 검수를 맡을 담당자가 정해지지 않은 경우입니다.

이 중에서도 계정 권한 하나가 전체 일정을 좌우하는 경우가 흔합니다. GA4나 광고 매체 계정에 접근 권한을 받는 절차가 조직 내부 승인을 거쳐야 한다면, 이 승인 하나 때문에 다른 모든 준비가 끝나 있어도 작업 착수 자체가 미뤄집니다. 전환 정의도 마찬가지입니다. 마케팅팀과 영업팀이 생각하는 전환의 기준이 다르면, 그 기준을 맞추는 논의 자체가 구현보다 오래 걸릴 수 있습니다.

짧게 끝나는 경우와 길어지는 경우 비교

구분	준비가 되어 있는 경우	준비가 되어 있지 않은 경우
계정 권한	요청 전에 이미 부여됨	내부 승인 절차를 거치며 대기
전환 정의	부서 간 합의가 끝난 상태	논의 과정에서 기준이 바뀜
담당자 지정	창구가 한 명으로 정리됨	문의마다 응답자가 달라짐
검수 일정	미리 일정이 확보됨	검수 담당자를 기다림
전체 기간	하루 안팎으로 마무리	몇 주로 늘어남