개발 팀과의 테크니컬 소통법: 딥링크 라우팅(Routing) 테이블 구축을 위해 마케터가 개발진에게 제공해야 할 상품 ID 및 카테고리 코드 매칭 표

라우팅 테이블은 URL 경로나 파라미터 값을 앱 내부의 특정 화면·데이터로 연결하는 매핑 규칙표입니다. 예를 들어 /product/12345라는 경로가 들어오면 앱이 상품 ID 12345의 상세 화면을 열어야 한다는 규칙, /category/shoes가 들어오면 신발 카테고리 목록 화면을 열어야 한다는 규칙이 이 표에 정의됩니다. 이 표가 없으면 앱은 딥링크로 들어온 값을 어떤 화면과 연결해야 할지 판단할 근거가 없습니다.

개발팀이 라우팅 테이블을 구현하려면, 마케터가 캠페인에서 쓰는 상품 ID·카테고리 코드 체계가 실제 시스템(쇼핑몰 데이터베이스, 상품관리시스템)의 내부 식별자와 정확히 일치하는지부터 확인해야 합니다. 마케팅팀이 관습적으로 부르는 상품명과 실제 데이터베이스의 상품 ID가 다를 수 있으므로, 딥링크에 실을 값은 반드시 시스템이 인식하는 고유 식별자를 기준으로 정리해 전달해야 합니다.

가장 실무적인 형태는 스프레드시트로, 한쪽 열에는 마케팅팀이 캠페인에서 쓰는 표기(예: "여름 신상 원피스"), 다른 열에는 시스템의 실제 상품 ID·카테고리 코드, 그리고 이 값이 7강에서 다룬 딥링크 파라미터의 어느 슬롯(deep_link_value, sub1 등)에 들어갈지까지 함께 정리하는 방식입니다. 이 표 하나로 마케터·개발자·QA 담당자가 모두 같은 기준을 보고 작업할 수 있습니다.

카테고리가 대분류·중분류·소분류처럼 계층 구조로 돼 있다면, 딥링크가 어느 계층까지 지정할 수 있는지 개발팀과 명확히 합의해야 합니다. "여성의류 > 아우터 > 코트"처럼 세 단계까지 딥링크로 지정 가능한지, 아니면 최상위 카테고리까지만 가능한지에 따라 캠페인에서 만들 수 있는 딥링크의 정밀도가 달라지므로, 이 범위를 사전에 확인하지 않으면 원하는 것보다 훨씬 넓은 화면으로만 연결되는 딥링크를 만들게 됩니다.

신규 화면·카테고리가 추가될 때마다 이 매핑 표를 갱신하지 않으면 딥링크가 조용히 실패합니다. 예를 들어 새로운 상품 카테고리가 시스템에 추가됐는데 라우팅 테이블에는 반영되지 않았다면, 그 카테고리로 연결하려는 딥링크는 앱이 인식하지 못해 기본 화면(홈)으로 떨어지는 결과가 됩니다. 이 문제는 신제품 출시 캠페인처럼 시급성이 큰 상황에서 특히 치명적입니다.

이 라우팅 테이블 작성은 65강에서 다룬 데이터 레이어 스펙 문서 작성과 동일한 원리를 공유합니다 — 마케터의 요구사항을 개발자가 오해 없이 구현할 수 있는 형태로 문서화하고, 이 문서의 소유자를 명확히 정해 최신 상태로 유지하는 것입니다. 두 문서 모두 방치되는 순간부터 실제 시스템과 어긋나기 시작한다는 점도 동일합니다.

상품·카테고리 데이터가 자주 바뀌는 조직이라면, 이 문서의 소유자를 마케팅팀 단독이 아니라 상품관리팀·개발팀과 공동으로 지정해 신규 상품 등록 프로세스에 "딥링크 매핑 갱신" 단계를 아예 포함시키는 것이 이상적입니다. 마케팅팀만 이 문서를 관리하면, 상품팀이 새 카테고리를 만들 때 마케팅팀에 알리지 않아 매핑이 누락되는 사고가 반복될 수 있습니다.

개발팀 입장에서 라우팅 테이블 구축은 신규 기능처럼 눈에 띄는 작업이 아니라 우선순위에서 밀리기 쉽습니다. 마케터가 이 작업의 필요성을 설득하려면, 추상적으로 "전환율이 오를 것"이라 말하기보다 1강·2강에서 다룬 것처럼 딥링크 없이 유저가 겪는 재탐색 과정과 이로 인한 이탈을 구체적인 시나리오로 제시하는 편이 우선순위 확보에 더 효과적입니다.

여러 언어·지역으로 서비스를 운영한다면, 같은 상품이라도 지역별로 다른 카테고리 체계나 상품 코드를 쓸 수 있습니다. 이런 경우 라우팅 테이블에 지역·언어 구분 열을 추가해, 하나의 딥링크 값이 지역에 따라 다른 화면으로 연결되는 착오를 방지해야 합니다.

매핑 표를 문서로 완성했다고 해서 개발팀이 그대로 완벽하게 구현했다는 보장은 없습니다. 표에 정리된 상품 ID 몇 개를 골라 실제로 딥링크를 만들어 클릭해보고, 의도한 화면이 정확히 열리는지 6강(65강)에서 다룬 것과 같은 방식으로 직접 검증하는 절차를 문서 전달로 끝내지 말고 반드시 거쳐야 하며, 표본을 몇 개만 골라도 구현 전체의 신뢰도를 가늠할 수 있습니다.