강슬기
광고 인벤토리 판매를 전문으로 하는 매체사에 입사 후 처음 주어진 미션은 바로 데이터 대통합!
우리는 이 프로젝트를 '데통꿈'(데이터 통합의 꿈)이라고 부르기 시작했다. 꿈이라는 말이 내포하듯, 실현 가능성을 반신반의하며 시작했던 듯하다. 어느 정도 어려움을 예상했음에도, 생각보다 처음 쌓기 시작해야 하는 데이터와 연동 규격을 표준화해야 하는 데이터도 많아 프로젝트 초기에는 예상치 못한 벽에 부딪혀야 했다.
초반에 잘 끼우는 단추가 중요한 법! 미리 알았으면 좋았을 법한 키 러닝 포인트 들을 기록해본다.
시작부터 숲을 보라
일반적으로 데이터 프로젝트를 시작할 때 단기/단편적인 문제점에서부터 시작되는 경우가 많다. 하지만 장기적으로 보았을 때 하나의 데이터 프로젝트가 회사 내 다양하게 잠복 중(?)인 프로젝트들과 잠재적으로 연결되어 있다. 예를 들어 '매출 데이터를 효율적으로 관리하고 싶어요'라는 올해 목표가 내년, 내후년이 되면 '매출 데이터를 인사 데이터와 연동하여 효율적으로 인력을 평가하고 싶어요'라는 발제로 발전할 것이다. 그제야 데이터 연동을 고려하기 시작하는 것보다, 처음부터 각 팀에서 관리하고 있는 데이터와 데이터 적재 현황을 리스트업 하여 궁극적으로 데이터 언어를 통일하는 큰 그림을 미리 짜 놓는 것이 좋다.
무에서 유를 창조하는 것보다, 관습을 바꾸는 것이 더 힘들다
데이터를 설계하면서 종종 "아예 모든 과정을 처음부터 시작하는 것이 더 편했을까" 싶은 생각이 들 때도 종종 있을 것이다. 이미 데이터 자동화 작업을 실시하기 전에 수동으로 데이터를 관리하던 시절의 비효율적인 관습을 씻어내기가 많이 어렵기 때문이다.
이 경우,
- 뼈와 살을 깎아 새 습관이 베이게 하거나
- 데이터 설계 시 미처 비효율성을 발견하지 못하고 그대로 반영하는 상황이 발생한다.
1 번의 경우 대부분의 구성원들이 어려움을 느낀다. 이미 실무가 넘쳐나 잔업을 하는 경우도 있는 상황에서 갑자기 업무 패턴을 바꿔야 하는 상황을 받아들이기 힘들 것. 이 경우 전사 브리핑 자리를 마련하여 데이터 프로젝트의 큰 그림과 당위성(주로 '업계 내에서는 ~이렇게 하고 있고, 당장 실시하지 않으면 뒤쳐진다'는 내용), 목표, 예상 일정, 세부 계획을 공유하는 자리를 마련하여 공개적으로 경영진과 실무진의 공감을 득하는 과정을 선행하는 것이 큰 도움이 된다.
물론 브리핑 시 어려운 용어를 최대한 배제하고 청중의 언어로 난이도를 조절하는 부분도 중요하다. 개인적으로는 이 부분이 많이 어려웠는데 내용을 A to Z 이해받지 못해도 좋다. 대략 "오.. 꼭 해야 하는 일이구나…" 정도의 사내 반응만 득해도 실제 프로젝트 구현에 튼튼한 엔진을 달 수 있게 된다.
데이터를 쌓기 전 개념 정리 선행이 필수!
정리되어 있는 데이터를 쌓기만 하면 될 것이라고 예상한 경우, 프로젝트 중반에 개념 혼선에 부딪히게 되는 경우가 많다. 항목 별 정확한 정의를 하는 작업이 선행되어야 한다. 실제로 같은 용어도 팀별로 다르게 해석하고 있는 경우가 많고, 수칙적인 연산법이 다른 경우도 많다. 팀별로 Key Person을 불러 모아 데이터 항목 하나하나 해석과 단위를 통일하는 작업이 선행되어야 한다.
매뉴얼은 프로젝트 끝난 뒤에 쓴다고? Nope. 가장 먼저 써보자
대부분 데이터를 구축하거나 관련 솔루션을 개발할 때 하기 순서의 진행이 예상된다.
목표 수립 → 팀별 Needs 수렴 → 과업지시서 → 기획안 → 개발 단계 구체적인 요구사항 정리 → 개발 → 테스트 → 활용 매뉴얼 작성 → 매뉴얼 배포 및 실적용
사용자 입장에서는 실제 시스템을 사용하기 전, 이 '매뉴얼'이 전반적인 시스템에 대한 첫인상이 될 것이다. 이 매뉴얼을 개발이 시작되기 전 프로젝트 시작 초반에 시스템이 다 개발되었다고 가정하고 미리 작성할 경우 얻을 수 있는 장점이 많다. (물론 시스템이 어떻게 개발될지 미리 예측해야 한다는 어려움이 있겠다…)
장점 1. 기획안이 더 촘촘, 탄탄해진다.
: 매뉴얼을 시뮬레이션하는 과정에서 좀 더 사용자 시각의 업무 Flow / UI 편의성을 미리 검증해볼 수 있다.
장점 2. 커뮤니케이션이 더 수월해진다.
: 기획 초기에서 가장 어려운 부분은 기획자, 사내 의사 결정자(Director 레벨), 사용 예정 실무 담당자, 개발자가 같은 기대를 공유하는 것. 기획안 보다 한층 더 직접적이고 친절한 형태인 이 '매뉴얼'이 초반에 공유될 경우 상호 간의 이해도를 많이 끌어올릴 수 있다.
장점 3. 난이도 조절이 원활해진다.
: 데이터 기획자의 가장 중요한 덕목은 데이터 전문가와 비전문가(시스템 사용자) 사이에서 적절한 난이도를 제시하는 것이다. 프로젝트에 과몰입할수록 현재 기획 중인 솔루션의 난이도를 스스로 조정하는 것이 점점 어려워진다. 솔루션 사용법 안내를 미리 시뮬레이션 함으로써, 효율적인 개발에만 치중할 수 있는 초기 기획 단계에서 사용자의 편의성이라는 중요한 부분을 빼놓지 않고 챙길 수 있게 된다.
과업지시서는 구체적일수록 좋다
실제 개발은 내부 개발자 또는 외주 업체와 진행을 하게 될 텐데, 개인적으로 외주 업체와 개발을 진행하며 난항을 겪었다. 데이터 시스템 개발이 처음이라 업무 브리프 형식(a.k.a. 과업지시서)이 따로 있는지도 몰랐고, 그 결과 반복적인 요구 사항 설명을 위한 통화가 거듭되며 개발 기간의 대부분을 요구분석에 할애하게 되었다. 과업 지시서에는 하기 내용이 포함되면 좋겠다.
작업 로그 기록을 소중히 하자
개발을 진행하는 과정에서 Slack을 주로 사용했는데, Jandi나 이메일과 마찬가지로 Linear 한 커뮤니케이션 방식이라 딱히 만족스럽지 않았다. 논의한 내용이 축적되는 느낌이 들지 않았고 오고 가는 문서의 버전 관리나, 개발 오류 해결 여부 등의 이슈 트랙킹이 어려웠다. 개인적으로는 Google Sheet 공유를 통해 서로 개발 현황을 공유하거나 이슈 트래킹을 전문적으로 제공하는 솔루션(Jira 등)을 이용하는 것을 추천한다.
최초에 어떤 요구 사항이 상호 협의되었었는지, 요구 사항은 몇 월 며칠 몇 개의 버전을 거쳐 변해왔는지, 중간중간 발생했던 이슈 사항이 빠짐없이 모두 해결되었는지 확인 가능한 환경만 마련되어도 업무 효율성을 훨씬 높이고, 혹시라도 업체와의 분쟁 상황이 생길 경우 쉽게 해결할 수 있다.
데이터의 고유성이 보장되어야 한다
미리 숲을 그려봤더라도 먼 미래의 데이터 연동까지 미리 예측하기는 어렵다. 이를 예비하는 가장 좋은 방법은 DB에 고유한 ID를 부여하는 것. 적재하는 항목 중 중복/구분이 어려운 데이터가 많거나 주요하게 관리되어야 하는 것들은 개발 측에 ID 발급 기능을 요청하는 것이 좋다. 우리가 가장 싫어하는 것…? 데이터가 기껏 마련되었는데 Vlookup 걸었을 때 #N/A를 얻게 되는 것… ㅠ.ㅠ
이렇게 고유하게 부여된 ID를 Unique Identifier(UID)라고 부르는데, 데이터를 참조할 때 불필요한 혼동이나 의도하지 않은 덮어쓰기를 방지해준다.
네이밍 컨벤션에 유의하라
네이밍 컨벤션(Naming Convention)은 주로 개발 용어 상에서 소스 코드의 효율적인 가독성을 위한 변수 명명 규칙으로 널리 알려져 있는 듯하다. 반면 마케팅 쪽에서는 마케팅 툴에서 한정적인 기입 란이 주어졌을 때 주로 사용되고 있다. 예를 들어 Google Ads의 경우 광고 세팅/분석 시 Campaign, Ad Group명을 주로 사용하게 되는데 이 한정적인 2가지 칸에 담고 싶은 최대한의 정보들을 주로 언더바(_)로 구분하여 포함하게 된다. 예를 들어 아래 예시를 보면 캠페인 명이 [키워드의 성격(Brand/Product/Preowned/Competitive)_매체(Search)_키워드그룹(Roadster/Sedan)]으로 이루어져 있다.
이렇게 언더 바로 구분된 항목들은 엑셀에서는 텍스트 나누기로, 태블로, 파이썬, R 등에서는 Split 함수로 분리하여 다양한 분석 차원(Dimension)으로 활용하게 된다. 'Campaign Name'이라는 단일명이 키워드 성격, 매체명, 키워드 그룹 3가지의 정보를 담게 되는 것이다.
디지털 마케터들에게 가장 익숙한 형태의 네이밍 컨벤션은 아마 Google Analytics(GA)에서 제공하는 Campaign URL Builder일 것이다. GA 분석에 적용되길 원하는 각 데이터 항목들(URL, Campaign Source, Campaign Medium, Campaign Name 등)을 기입하면 이들을 조합하여 URL이 생성되는데 이미 세팅되어 있는 일정한 네이밍 컨벤션에 따라 생성된 일종의 네이밍 규칙으로 볼 수 있다.
입력한 값
- Campaign Source : google
- Campain Medium : search
- Campaign Name : datablogs
- Campaign Term : data
- Campaign Content : blogs
네이밍 컨벤션에 따라 생성된 URL
- https://brunch.co.kr/@sukistory/?utm_source=google&utm_medium=search&utm_campaign=datablogs&utm_term=data&utm_content=blogs
네이밍 컨벤션의 경우 미리 정한 규칙이 모든 네이밍 세팅에 적용되는 것이 가장 관건. 이 네이밍 컨벤션의 규칙을 기획한 사람이 실제 네이밍 세팅도 진행할 경우에는 큰 어려움이 없겠지만, 타 부서의 다수의 인원에게 네이밍 규칙 준수를 요청할 경우, 컨트롤이 많이 어려워진다. 이 경우, Google Sheet를 이용하여 위 Campaign URL Builder와 같은 네이밍 생성 기능을 자동화하고, 각 인원이 생성한 네이밍을 히스토리로 기록하게 하면 관리가 한층 더 쉬워진다. 네이밍을 구성하는 항목 항목을 "&" 연산자로 연결하는 형식의 함수를 활용한 형태이다.
네이밍 컨벤션 설명을 위해 GA URL을 주로 예시 들었지만, 일반적인 폴더명, 파일명을 포함한 다양한 데이터 항목에 네이밍 컨벤션을 빈번하게 사용하게 된다.
마무리
효율적인 데이터 자동화 프로젝트의 시작이 이렇게 어렵다. 큰 그림을 보고 시작할 수 있어야 하고, 경영진을 비롯한 내부 팀원들을 설득하는 피와 살을 깎는 노력이 필요하며, 개발 번복을 최소화하기 위해 내/외부 담당자들과 명확한 프로젝트 방향을 공유해야 한다. 적재하려는 데이터를 명확히 해야 하고 그 데이터의 고유성과 안정성을 고려한 초기 설계도 고안해야 한다.
이렇게 사후 정리된 TIP 들도 충분치 않거니와, 기본 개념도 없이 뛰어든 프로젝트였기에 우여곡절이 많았다. 개인적으로는 실제 프로젝트 런칭 및 사내 적용 후에 더 많은 러닝을 얻을 수 있기를 기대하고 있다. 이 글을 통해 다른 데이터 관련 프로젝트 담당자들과 더 풍부한 TIP을 나눌 수 있는 기회를 가졌으면 하는 바람이다 :D
Editor 선미’s comment
이 글의 원문은 포커스미디어 데이터전략팀 리더 강슬기님의 브런치에 업로드 된 '데이터프로젝트의 단단한 초석 쌓기’ 입니다.
“무에서 유를 창조하는 것보다, 관습을 바꾸는 것이 더 힘들다”라고 얘기한 것처럼 아예 새로운 데이터 시스템을 만든게 아니라, 기존에 시스템이 있는 상태에서(이라고 쓰고 레거시라고 발음하죠) 이 일을 했기 때문에 두 배, 세 배 어려웠을거라는 생각이 듭니다. ‘지금도 괜찮고 나는 바쁜데 꼭 이거 바꿔야해?’라는 반발에 부딪힐 수 밖에 없으니까요.
하지만 또 이런 레거시라는게 아예 없는 조직도 건강하지 않은 것 같아요. 비즈니스 속도에 맞춰 의사결정을 하기 위해 만들어진 완벽하지 않은 무언가가 있을 수 밖에 없습니다. 사족이지만, ‘심 시티’, ‘프로스트펑크’와 같은 도시 건설 게임에서도 자주 만나게 되는 상황입니다. 게임 팬 분들이라면 아실거예요!
결국 완전무결하게 돌아가는 시스템은 없기 때문에 이런 정비 작업과 적절하게 균형을 맞춰야 합니다. 혹시 우리 조직도 이런 정비가 필요한 시점이라고 생각하시는 분이 계시다면, 이 글을 정독해보시면 좋겠습니다.
