사내 데이터 플랫폼 개발, 처음이라면?

협업이 낯선 데이터 분석/사이언티스트와 엔지니어를 위한 가이드

Bonnie BK

Published in

Naver Search Data&Analytics Tech Blog

12 min readOct 12, 2023

데이터 엔지니어 및 소프트웨어 엔지니어, 그리고 데이터 분석/사이언티스트의 협업은 역사가 길지 않아서 Best Practice 라고 여겨질 만한 방법론이나 사례가 없는 듯 합니다.

오늘은 네이버 검색 Data&Analytics(DnA)의 팀원으로서 함께 했던 데이터 플랫폼 개발 협업 프로세스에 대해 글을 작성해 봅니다.

네이버 검색에서는 일상 업무에서 활용하는 다양한 플랫폼들이 있어요. 검색에서 자체 개발한 플랫폼 뿐 아니라, DnA 팀에서 자체 개발한 플랫폼들이 주된 데이터 추출 및 분석 업무 환경을 구성하고 있습니다.

2023년 1분기부터 DnA 팀 내에서 신규 데이터 분석 플랫폼 개발 PM을 맡았습니다. DnA 팀은 다양한 서비스 팀과 협업하는데, 서비스 팀의 반복되고 확장되는 분석 요구 사항을 플랫폼으로 해소하자는 취지였습니다.

요구 사항은 있지만, Zero-to-one으로 맞춤형 플랫폼을 개발해야 하는 상황이었어요. 하지만 유사 경험, 팀 내 전례, 다른 기업 사례 글 마저 없었습니다.

당시에 어떤 절차로 일을 이끌어가야 하나 막막 했던 마음이 떠올라 협업이 낯선 데이터 직무 분들에게 도움이 되길 바라며, 지난 프로세스를 정리하는 글을 남깁니다.

목차 
✔️ 자체 개발 데이터 플랫폼이 필요할 때
✔️ 데이터 분석 플랫폼 개발에 필요한 역할 
✔️ 데이터 분석 플랫폼 개발 프로세스 
✔️ 시행착오를 통해 깨달은 것들

자체 개발 데이터 플랫폼이 필요할 때

데이터 플랫폼이 필요한 경우는 다양합니다. 주로 큰 양의 데이터를 효과적으로 관리, 분석, 활용하고자 할 때 필요한데요. 데이터 플랫폼의 5가지 계층을 나눠본다면, 이번 사례는 아래 이미지 4단계의 BI/User Access 와 관련이 있습니다.

데이터 플랫폼의 5계층 (출처 : What is a Data Platform? And How to Build An Awesome One)

사내 다양한 팀에서 반복되고 패턴의 분석 및 추출 요청이 있었고, 단기/ 장기적으로도 중요한 분석이었습니다. DnA 팀에서 해당 분석을 중앙 집권화 하기에는 다른 업무도 이미 너무 많고, 무엇보다 도메인 지식이 많은 서비스 팀에서 직접 분석했을 때 더 깊이 있는 인사이트를 찾기에 좋은 구조였어요.

반복되는 요청에 대한 효율화가 필요했고, Self-service Analytics 를 늘리려는 팀의 방향성이 있었기에 데이터 분석 플랫폼이 필요했어요.

플랫폼이 필요하다고 판단이 되었을 때, 이번 사례는 자체 개발을 할 수 밖에 없었는데요. 그 이유는 엄격한 데이터 보안 정책, 비용 효율 문제도 있지만 무엇보다 ‘네이버 검색 서비스 모델에 맞는 맞춤형 플랫폼’이 필요했기 때문입니다.

🛠️ 어떤 데이터 플랫폼을 만들었나

QIP(Query Insight Platform, 큅)은 개선 및 모니터링 대상 질의셋을 등록하고 그 품질과 볼륨 지표를 모니터링할 수 있는 플랫폼입니다.

QIP을 통해 질의셋 뿐 아니라, 개별 질의 단위의 품질 및 사용자 행동 패턴 등의 다양한 정보를 한눈에 확인할 수 있습니다.

이번 글에서는 플랫폼의 구조가 아닌 플랫폼 개발 프로세스를 다루려고 합니다.

✔ 자체 개발 플랫폼이 필요한 상황

1. 특수한 요구 사항이 있는 경우: 이번 사례 ✔️

특정 업종이나 사업 모델에 맞춘 맞춤형 플랫폼이 필요할 때.
기존 상용 플랫폼이 만족시키지 못하는 특수한 기능이나 성능 요구 사항이 있을 때.

2. 데이터 보안 및 개인정보 보호:

엄격한 데이터 보안 및 개인정보 보호 정책을 준수해야 하는 경우.
데이터의 주권을 사내에 유지하고 싶은 경우.

3. 비용 효율:

장기적으로 봤을 때 자체 개발이 상용 플랫폼 사용에 비해 비용 효율적인 경우.

4. 기술 통합 및 커스터마이징:

다양한 사내 시스템과의 통합이 필요한 경우.
특정 비즈니스 프로세스에 최적화된 플랫폼을 구축하고 싶은 경우.

5. 자체 기술 역량 확보:

데이터 플랫폼에 대한 이해와 기술 역량을 사내에 확보하고 싶은 경우.

6. 데이터 관리 및 거버넌스:

데이터의 품질, 관리, 거버넌스를 사내 정책에 따라 수행하고 싶은 경우.

데이터 분석 플랫폼 개발에 필요한 역할

데이터 플랫폼 도입 또는 개발은 앞서 살펴본 데이터 플랫폼 5계층에서 Storage, Ingestion, Transformation 단계에서 먼저 선행되는 편이라, 데이터 엔지니어 및 소프트웨어 엔지니어 만으로 진행되는 경우가 많은데요.

이번 사례처럼 사내 다양한 팀에서 반복되고 패턴의 분석 및 추출 요청을 분석 플랫폼화하는 경우는 다릅니다. 사용자 타겟층과 해소하고자 하는 니즈가 명확할 때에는 사용자와 비즈니스 요구 사항에 대한 이해도가 중요합니다.

ChatGPT에게 데이터 분석 플랫폼 개발에 필요한 역할을 물어봤더니, 정말 다양한 역할을 알려주네요.

이처럼 최대한 다양한 전문가를 모셔서 함께할 수 있다면 이상적 이겠지만, 1인 다역을 훌륭하게 하실 수 있는 팀원 분들과 함께할 수 있어 수월하게 진행할 수 있었습니다.

역할이 항상 개인에게 1:1 대응되어 깔끔히 떨어지는 것은 아니라 Gray Area가 있기는 한데요. 위 ChatGPT의 답변을 이번 DnA 사례에 빗대어 본다면,

데이터 분석/사이언티스트 분들이 추가적으로 프로젝트 관리, 비즈니스 애널리스트, UI/UX 디자인 역할을 맡았습니다.
데이터 엔지니어 분들이 추가적으로 데이터 아키텍트, 소프트웨어 개발, 인프라 관리 역할을 맡았습니다.
다 함께 품질 관리, 문서화 및 지원을 도왔습니다.

데이터 분석 플랫폼 개발 프로세스

DnA 팀에서 진행했던 이번 프로세스를 돌아보며, 아래 프로덕트 개발 프로세스의 큰 6단계를 참고하여 설명합니다.

Step 1. Ideation

(1) 팀 외부 요구사항 수렴

팀 리더, Tech Lead와 충분한 1:1 대화를 기반으로 요구사항 이해도 향상
플랫폼 Scope를 프로젝트 Phase에 맞게 분배함
목표 일정 관련 얼라인 맞춤

(2) 팀 내부 요구사항 수렴

지난 요청들을 구조에 맞게 최대한 정리, 선행된 타 플랫폼을 통해 대응된 요구 사항인지 분류

다양한 요청들 및 내부에서 출발한 분석들을 기반으로 플랫폼의 요구사항을 정리함
뿐 아니라 팀 내에 공유하여 검토받거나 함께 요구사항을 받을 수 있도록 함

(3) 팀 외부/ 내부 사용자 인터뷰

요구 사항 수렴 후 구체적인 기획 단계에서 사용자 인터뷰
상세한 기능의 우선순위를 설정하는 데에 도움을 얻음
당시 진행하지 못했지만 회고하며 추가한 단계

Step 2. Product Definition

(1) Milestone 설정

전 단계에서 정의된 Scope들을 각 Milestone으로 쪼개고 필요한 Task를 예상하여 작성
Milestone의 진행 현황과 담당 파트를 배치하고 PM은 팀 내 리뷰, 틈틈이 잘 나아가고 있는지 확인하며 업데이트함

(2) 역할 분담, 이슈 관리 시작

프로젝트에 메인으로 참여하는 인원을 확정함
업무 이슈들을 모아 팔로업할 수 있는 대단위 이슈 생성 관리

(3) 화면 기획 및 스펙 작성

플랫폼의 화면을 기획하고, 실제 구현을 한다고 가정했을 때 미리 정의되어야 할 상세한 요소(메뉴, 페이지 별 상세 기능 작동 방식)들을 정리함
정리한 이후 공유 미팅을 진행해야 함, 문서로만 소통되면 문서를 아무리 친절하게 쓰더라도 싱크가 안 맞을 수 있음.

💁 디자인 하나도 모르는데 화면 기획해야 할 때
*파워포인트 도형으로 만들어도 충분하다. 할 수 있는 선에서 하자!
*구현하고 싶은 화면을 더 섬세하게 표현하고 싶다면, Figma Community에 있는 컴포넌트 가져다 쓰면 편하다.
*사내 Design System이나 Figma에서 쓰이는 아이콘이나 색상을 참고해보자.

(4) 구현 방법 서베이(리서치)

UX 및 화면 기획이 진행되고 있을 때, 동시에 기술적 구현 방법에 대한 서베이를 병행함 (엔지니어)

(5) 데이터 파이프라인 스펙 정의

어떤 스키마로 데이터 파이프라인이 생성되어야 하며
사용자 요구사항에 따라 Backfill 정책은 어떻게 가져갈 것인지
보안 정책에 맞게 어떻게 사용자에게 제한을 걸 것인지 등
가능한 모든 케이스들을 나열하고 논의할 필요가 있음

Step 3. Prototyping

(1) 프론트, 서버 개발

서베이(리서치)한 내용과 작성된 화면 기획 및 스펙 기반으로 Dev 버전 개발

(2) 데이터 파이프라인 샘플 데이터로 화면 프로토타입 개발

데이터 분석 플랫폼 특성상 데이터 시각화 화면이 있음
데이터 파이프라인을 개발하는 동안 프론트/ 분석 기능 구현 작업을 병행하기 위해, Mockup 데이터 또는 샘플을 미리 개발해 전달함
샘플 데이터를 기반으로 플랫폼에 분석 기능이 어떤 형태로 그려지고 작동할지 Prototype을 만들고 팀 내 공유, 피드백 받아 개선함

Step 4. Detailed Design

(1) 프론트, 서버 개발

프로토타입 단계에서 피드백 받아 개선하며 Production 버전 개발

(2) 데이터 파이프라인 개발

샘플 데이터에 대한 피드백을 받아 설계한 대로 데이터 파이프라인 개발

(3) 실제 파이프라인 데이터로 화면 개발

데이터 분석 플랫폼 특성상 데이터 시각화 화면이 있음
프로토타입 단계에서 만들어 둔 틀을 활용하되, 데이터만 갈아끼워서 실제 파이프라인의 데이터가 연동된 화면을 만듬

Step 5. Validation / Testing

(1) 팀 내부 QA 및 개선

프론트, 데이터 파이프라인 관련하여 PM이 검토하고 피드백
개선 사항 도출하여 반영함

(2) 팀 외부 User Testing 및 개선

향후 사용자가 될 수 있는 분들을 1:1 컨택하여 UT 진행
개선 사항 도출하여 우선순위 높은 것들 위주로 반영함

💁 사용자에게 어떤 질문을 했었나
*기존 분석 상황 및 니즈 파악
*플랫폼 사용 화면 공유 (태스크 있게, 없게도 해봄 e.g. 처음 플랫폼을 보는 사람이라고 생각하고 가장 먼저 어떤 것들을 눌러보실 것 같나요?)
-> 옆에서 사용 양상을 지켜보며 얻은 개선 포인트 정리

(3) 팀 내부 Final QA 및 Testing

(좌) Dogfooding 개념을 팀에 소개하면서 처음 도전해본 절차 (우) 개선 사항 리스트

기능적 완성도를 높인후 플랫폼 팀 내에서 태스크를 설정하여 미팅 시간에 각자 진행하고 공유
개선 사항 도출하여 우선순위 높은 것들 위주로 반영함

Step 6. Commercialization

(1) 사용자 가이드 작성

문서화에 힘을 쏟음 (생각보다 사람들은 교육 영상을 잘 보지 않음, 업무에 필요할 때 그 때 그 때 문서 찾아봄)

💁 가이드 문서에 유용하게 썼던 툴
*스크린샷 깔끔하게 뜨고 번호 매길 수 있는(유료 결제함) 크롬 익스텐션
*크롬에서 gif 뜨는 크롬 익스텐션(유료 결제해야 화질 좋아짐)

(2) 런칭 소식 공지

플랫폼의 주 사용자가 될 만한 구성원 분들이 모여있는 미팅을 활용해서 런칭 소식을 공지함
이 때 플랫폼을 기존 업무 프로세스에 어떻게 / 왜 녹여내야 하는지 위주를 추가하여 소개함 (아래 목차에서 활용 시나리오)

(3) 사용자 교육 진행

런칭 소식을 공지할 때, 교육 참석 희망자를 받음
채널이나 이메일 통해 공지함

(4) 운영 방식 정립

플랫폼 개발 이후 어떤 식으로 요청에 대응하고 운영할 것인지 논의하여 설정함
어떤 미팅, 채널에서 소통할 것인지 논의하여 정해 둠

시행착오를 통해 깨달은 것들

플랫폼 런칭을 마친 후, 팀원 분들과 회고를 진행했는데요. 회고 후 주요한 배움들을 정리하며, 크게 두 가지 키워드가 가장 중요하다고 여겨졌습니다.

사용자, 그리고 상용화

더 자세한 배움들은 아래와 같습니다.

플랫폼 개발의 목표는 ‘런칭’이 아닌 ‘상용화(Commercialization)’, 사용자 교육과 가이드의 중요성에 대한 공감대가 필요하다.
내부 사용자 의견을 적극적으로 청취하고 피드백을 내부 팀/ 엔지니어에 공유하는 것이 동기부여에 도움이 된다.
여건이 된다면 사용자 요구사항 수렴을 위한 인터뷰를 기획 단계, 개발 이후 UT 단계에서 모두 진행하는게 좋을 것 같다. (*자꾸 개발하는 입장에서 플랫폼을 어렵게 설계하게 됨)
데이터 플랫폼의 경우, 기획 단계에서 데이터 파이프라인 생성 및 백필 관련 가능한 케이스들을 최대한 나열하고, 케이스들을 최대한 대응할 수 있는 구조로 웹 화면 및 세부적인 옵션들을 설계할 필요가 있다.
데이터 파이프라인 개발 이전, 초기 Mockup 데이터 또는 간단한 템플릿으로 전체 모습을 미리 그려보는 것이 큰 도움이 된다.
서로의 역할 범위를 넘어서더라도, 프로젝트 전체적으로 효율적으로 나아가는 것인지의 관점에서 판단하는 게 좋다.

정리하며

본 글은 PM 입장이었던 제가 작성한 글이라 기술적 부분은 생략되었습니다. 협업 문화 및 프로세스를 다루는 콘텐츠를 남겨보고 싶기도 했고요.

최선의 협업 프로세스는 어떤 플랫폼을 개발하는지, 어떤 구성원과 함께 하는지, 주어진 시간이 어느 정도인지 등 상황마다 달라질 것입니다.

여러 변수로 인해 정답은 없으니 본 글에서 각자 상황에 맞게 필요한 부분들을 참고하시면 좋겠습니다.

더 이야기 나누고 싶은 분들은 링크드인으로 메세지 주세요!