마케터와 개발자 사이 병목을 줄이는 태깅 요청서 양식

📖 약 3분 읽기

전환 태깅을 위해 개발팀에 데이터 전달을 요청했는데 몇 주째 진행되지 않는 경우가 있습니다. 요청이 백로그에서 밀리기도 하고, 담당자가 화면을 다시 확인해 달라고 되묻는 일이 반복되기도 합니다. 이런 지연의 원인은 흔히 요청서 자체의 정보 부족에 있습니다. 개발자가 코드를 작성하기 전에 스스로 판단해야 할 부분이 많을수록 착수는 늦어지고, 판단이 애매한 지점마다 질문이 오가면서 왕복 횟수가 쌓입니다.

되물음이 반복되는 이유

개발자가 요청서를 받고 나서 가장 먼저 되묻는 항목은 대체로 정해져 있습니다. 어느 화면에서 데이터를 수집해야 하는지, 그 값이 발생하는 정확한 시점은 언제인지, 전달할 값의 종류는 무엇인지, 그리고 그 값이 어떤 형식으로 넘어와야 하는지입니다. 예를 들어 결제 완료 시점의 매출액을 전달해야 한다고만 적혀 있으면, 개발자는 결제 승인 시점인지 주문 완료 시점인지, 부가세 포함 금액인지 아닌지를 다시 확인해야 합니다. 이런 확인 과정이 요청서 한 건마다 반복되면 실제 개발 착수 시점은 요청일보다 한참 뒤로 밀립니다. 결국 요청서에 판단이 필요한 여지를 남겨 두지 않는 것이 지연을 줄이는 가장 확실한 방법입니다.

요청서에 담아야 할 항목

개발자가 다시 묻지 않고 바로 작업에 들어가려면 요청서에 다음 항목이 모두 포함되어야 합니다. 목적은 이 데이터를 왜 수집하는지를 한두 문장으로 밝히는 부분이고, 대상 화면은 데이터레이어가 삽입될 정확한 페이지나 컴포넌트를 가리킵니다. 발생 시점은 클릭인지 페이지 로드인지 특정 이벤트 완료 시점인지를 명시하는 항목이며, 전달할 값과 형식은 필드명과 자료형을 함께 적는 부분입니다. 예시 값은 실제로 어떤 값이 들어오는지 견본을 보여주는 항목이고, 예외 상황은 정상 흐름을 벗어나는 케이스를 미리 정리한 것입니다. 검수 방법은 완료 여부를 확인할 기준이며, 희망 일정은 요청자가 필요로 하는 시점을 알리는 항목입니다. 이 여덟 가지가 빠짐없이 채워지면 개발자는 별도의 확인 없이 작업 범위를 확정할 수 있습니다.

값의 형식을 지정하는 방법

값의 형식을 지정하지 않으면 같은 항목이라도 사람마다 다르게 넘길 수 있습니다. 금액을 예로 들면 숫자만 전달할지, 통화 기호를 포함할지, 소수점을 몇 자리까지 남길지에 따라 뒤에서 이 값을 집계하는 로직이 달라집니다. 따라서 단위를 함께 적어야 하고, 문자열인지 숫자인지 자료형을 구분해야 하며, 값이 비어 있을 때 null로 둘지 빈 문자열로 둘지 아니면 특정 기본값으로 채울지도 미리 정해야 합니다. 이런 규칙을 요청서 단계에서 정리해 두면 개발 이후 데이터를 검증하는 단계에서 형식이 맞지 않아 되돌아가는 일이 줄어듭니다.

예외 상황을 명시하는 방법

정상적인 구매 흐름만 가정하고 작성된 요청서는 실제 서비스에서 발생하는 다양한 케이스를 놓치기 쉽습니다. 주문 취소가 일어났을 때 이미 전달된 값을 어떻게 처리할지, 부분 환불이 발생했을 때 매출액을 원래 값 그대로 둘지 조정할지, 비회원으로 주문한 경우 식별값을 무엇으로 대체할지, 그리고 여러 상품을 한 번에 구매했을 때 값을 상품별로 나눠 전달할지 합계로 전달할지를 미리 적어 두어야 합니다. 이런 예외 상황을 개발 착수 전에 정리해 두면, 개발이 끝난 뒤 특정 케이스에서 값이 비거나 중복되는 문제를 뒤늦게 발견하는 상황을 피할 수 있습니다.

검수 기준과 우선순위 표기

개발이 끝났다고 알려 와도 요청한 쪽에서 무엇을 확인해야 완료로 볼지 모르면 검수 단계에서 다시 대화가 오갑니다. 그래서 요청서에는 어떤 화면에서 어떤 값이 어떤 형식으로 찍히면 완료로 인정할지를 미리 합의해 적어 두어야 합니다. 예를 들어 개발자 도구의 콘솔에서 특정 이벤트 값이 지정된 필드명과 형식으로 확인되면 완료로 본다는 식의 구체적인 조건을 남기는 방식입니다. 아울러 여러 요청이 동시에 쌓여 있는 상황이라면 우선순위를 근거와 함께 표기하는 것이 작업 순서를 정하는 데 도움이 됩니다. 이 요청이 지연되면 어느 정도 규모의 광고 예산 집행이 영향을 받는지, 혹은 어느 매출 구간의 측정이 막히는지를 한 줄로 덧붙이면 개발팀 입장에서도 우선순위를 판단할 근거가 생깁니다.

요청서 전문

이 여덟 항목을 채운 요청서는 개발자가 별도의 확인 없이 작업 범위를 정하고 착수할 수 있는 최소한의 조건을 갖춘 것입니다. 요청서 양식을 조직 내에서 표준화하는 작업은 태그맨이 지원하는 범위에 포함될 수 있습니다.